Move snowfall to IFluxCalculation

[einola]

For my work on issue #127 having the shared variable snowfall in IFluxCalculation makes more sense than having it in AtmosphereState. I think this is true in general. Can we move snowfall?

[timspainNERSC]

Snowfall makes sense to me as something the atmosphere itself is doing. Instead, might it make sense to have a total precipitation flux or even E-P areal mass flux in the implementations of IFluxCalculation? This seems more 'flux-y' and would parallel the existing subl sublimation mass flux.

[timspainNERSC]

Also, you can just define an array that provides snowfall data within your own module implementation. Since the AtmsophereState code is never called, it will never overwrite snowfall values provided from elsewhere.

    HField snowfall;
…
    registerProtectedArray(ProtectedArray::SNOW, &snowfall);

[einola]

Yes, the problem is that snowfall kind of belongs in both places. You get either

• Fluxes (total radiative and turbulent and evaporatoin) + precipitation (rain + snow)
• Atmosphere state (2 m temp, etc) + precipitation (rain + snow) -> then calculate fluxes and evaporation

It doesn't make much difference where the snowfall sits, as long as both the flux and atmosphere state codes can modify it.

But can I do that when it's a ProtectedArray? A simple

    registerProtectedArray(ProtectedArray::SNOW, &snowfall);

in the header and

    snowfall[i] = 1.;

doesn't work.

[timspainNERSC]

But can I do that when it's a ProtectedArray? A simple

registerProtectedArray(ProtectedArray::SNOW, &snowfall);

in the header and

snowfall[i] = 1.;

doesn't work.

In what way doesn't work? A ProtectedArray is only protected against anything that accesses it as a ModelArrayRef from writing to the array. In the ModelComponent where it is defined as a ModelArray, there is no concept of protected or shared or write-protected.

What does need to be the case is that the ModelArray is persistent, such as being a class member variable in a class that is still alive. It won't work on variables only defined within a function. (Assuming that's what is going on.)

[einola]

I was trying to modify a protected array - which probably should not be allowed anyway :)

This all becomes a bit annoying and contorted because there are a few layers where information may be coming into the model. What we've done so far is

AtmosphereState <= 2 m temp, etc + precipitation from file or coupler
         ||
         \/
FluxCalculation
         ||
         \/
IceThermodynamics <= Fluxes (total radiative and turbulent and evaporation) + precipitation (rain + snow) from file or coupler

So, whether the fluxes that IceThermodynamics receive comes from AtmosphereState + FluxCalculation or directly from file/coupler depends on the setup. If we consider what's provided we can write it down like this:

Provided by AtmosphereState:

• wind speed
• 2 m temperature
• 2 m dewpoint OR mixing ratio OR specific humidity
• surface pressure
• incoming long- and shortwave radiation
• precipitation (snow + rain)

Provided by FluxCalculation or fluxes from file/coupler:

• total ice-atmosphere heat flux
• the derivative of total flux w.r.t. temperature
• sublimation flux
• precipitation (snow + rain)
• incoming shortwave radiation
• non-solar heat flux over the ocean
• evaporation from the ocean

The IceThermodynamics needs everything ice/snow related, while the (bulk) ocean needs the last two ocean-related points. The idea was that you could read from a file or receive from the coupler either fluxes or atmospheric state. If you read/receive atmospheric state, then you can have flexibility in choosing a FluxCalculation implementation.

The problems we have now are:

• There's an overlap, where both AtmosphereState and FluxCalculaton provide precipitation and shortwave radiation. So, in which module should those live?
• If we read/receive fluxes only, are we forcing ourselves to reserve memory for all of AtmosphericState?

[einola]

After some thinking and discussion, @timspainNERSC and I have tentatively agreed on the following:

We'll replace AtmosphereState and FluxCalculation modules with an AtmosphereBoundaryConditions module, which will have the following characteristics:

• It will hold the fluxes currently held by FluxCalculation (plus some we missed), i.e.
  • total ice-atmosphere heat flux
  • the derivative of total flux w.r.t. temperature
  • sublimation flux
  • precipitation (snow + rain)
  • incoming shortwave radiation
  • non-solar heat flux over the ocean
  • evaporation from the ocean
  • wind u & v
• An implementation of AtmosphereBoundaryConditions can consist of, e.g.,
  • Setting the module variables (above) to some fixed or tabulated values
  • Setting the module variables to values received from the coupler
  • Reading atmospheric state from file and using a flux calculation implementation to calculate the fluxes
  • Something even more complicated (like an atmospheric boundary layer model)

We will then replace the OceanState and bulk ocean module and routines with a similar OceanBoundaryConditions module

• It will hold
  • Ice-ocean sensible heat flux
  • SST
  • SSS
  • ocean u & v
• An implementation of OceanBoundaryConditions can consist of, .e.g.,
  • Setting the module variables (above) to some fixed or tabulated values
  • Setting SST, SSS, and ocean u & v to values received from the coupler and calculating the flux using an implementation of IIceOceanHeatFlux
  • Using a slab ocean model to calculate SST and SSS, use values read from file to nudge those towards observations or the results of another model, and calculate the flux using an implementation of IIceOceanHeatFlux

[brodeau]

Hi guys, since the flux stuff is my thing I couldn't help and had to catch up on this discussion. I think the proposed merge into a single module is definitively a sound move!
/laurent