Interface: CanopyFluxes calls EDPhotosynthesis in a complicated loop

[rgknox]

Attention stake-holders. Let do some cross-project agree-afication:

Summary of Issue:

One of our goals for the CLM/ALM <-> FATES interface is to constrain the interface points during time-stepping to a single file and subroutine, ideally clm_drv().

@bishtgautam and I see one location where this is proving a little more difficult.

clm_drv() calls CanopyFluxes(), which optionally calls EDPhotosynthesis or non-ED Photosynthesis within a complicated loop.

This complicated loop is trying to converge on surface aerodynamics stability factors (Monin-Obhukov stuff), which are co-dependent with conductance calculated by the photosynthesis scheme. So it does not appear to be something we can pull out of the loop.

Options I see:

1. create some super nifty way to use object oriented programming so that either the fates and non-fates photosynthesis is called from clm_drv() but is also somehow wrapped by the iterator without having two sets of iterator code.

2. just leave the positioning of the calls "as-is" and accept the fact that not all of the clm_fates interface calls can be though clm_driv(). In this case we would have an interface call from CanopyFluxes.

3. copy the iterator code and put it in the interface when ed photosynthesis is used (I don't like this option, the iterator performs a great deal of land-model physics.)

4. Obviously we are not going to copy all of that stability iterator stuff into clm_drv, that would be just sad.

I propose to move ahead with option 2, unless we can brain-storm a clean awesome way to do option 1.

CLM5'ers. Is this iterative loop changing in any way?

[bishtgautam]

Here are some relevant links to the source code:

• The Newton-Raphson ITERATION-loop for energy balance
• The use_ed within the iteration loop.

[billsacks]

This is an interesting question. I'm sure it warrants more thought than the time I have to give it right now, so I'll answer based on gut feelings and a quick skim through the code. So take this with many grains of salt 😄

First off: I'd be okay with (2), particularly in the short-term, and maybe even in the long-term. It doesn't feel ideal, but it seems acceptable if the cost:benefit ratio is too high for the alternatives.

As for (1): Maybe I'm missing something, but at a glance I'm thinking you could do something relatively simple IF you have FATES and non-FATES (i.e., CN?) both implement some common interface. This follows the vision I started to lay out with CNVegetationFacade.F90 (in CLM: src/biogeochem/CNVegetationFacade.F90 - see the comment at the top of that file). In that case, you would have a Photosynthesis routine in the interface. FATES would provide one implementation and non-FATES (CN) would provide another. You would then pass the veg instance (either an instance of FATES or an instance of CN) to CanopyFluxes, which would call veg%Photosynthesis(...). But I fully acknowledge that it might take a while to get to a place where that is possible, and furthermore that my vision may not be the direction you want to take this.

However, writing out all of that made me see things that don't smell right here. In particular, if we say we have a FATES version of Photosynthesis, and if the options in the system are to have FATES or CN (or SP), then that implies that we have a CN version of Photosynthesis. But I don't think we've ever thought of Photosynthesis as being CN-specific. So that led me to wonder why we have these two versions in the first place.

Looking quickly at the diff of the two versions of Photosynthesis, it looks to me like the FATES/ED version began life as a copy of CLM's Photosynthesis routine, and then evolved in ways necessary for the differences in the ED data structures. It looks to me like the two are fundamentally still doing the same science, just with different structures.

If this is the case, then I would ask a more fundamental question: Is it really desired, long-term, to have a separate FATES version of Photosynthesis, or should FATES use the Photosynthesis scheme implemented by the host model? My gut feeling would be the latter. (So, if FATES were plugged in to a host model with a fundamentally different Photosynthesis operation, FATES would use that version.) Then the question becomes: How would CLM's photosynthesis routine need to be rewritten so that it could accommodate either FATES or non-FATES canopies?

My understanding is that we will need to tackle this question in CLM soon anyway, when Gordon's multi-layer canopy comes in. My rough understanding (possibly wrong, or at least incomplete) is that much of the difference between Photosynthesis and EDPhotosynthesis comes down to the fact that Photosynthesis is written to operate on sunlit vs. shaded fractions of the canopy, whereas EDPhotosynthesis is written to operate on a multi-layer canopy. I have talked a little bit with Rosie and Danica about how we could rewrite this so that a single set of code could operate on either structure. e.g., could we have some general notion of "multiple canopy elements" (which could mean either multiple layers or sunlit vs. shaded elements), and have the photosynthesis routine loop over each of these canopy elements?

I encountered a specific instance of this problem with Danica's ozone code: She wrote the code with the assumption that there are sunlit and shaded canopy fractions, so right now it doesn't play nicely with ED/FATES, nor will it play nicely with Gordon's multi-layer canopy scheme (I think). At least in that context, it seemed like it could be relatively straightforward to have N instances of the ozone stress variables, one for each canopy element; N would be 2 for the standard CLM sunlit/shaded, and equal to the number of layers in the canopy for FATES. Without this sort of generalization, note that EDPhotosynthesis does not currently allow for ozone stress. In my mind, that is an undesirable divergence, and an argument for reconciling the two schemes.

[rosiealice]

Bill's point is a good one. There is a lot of duplication between the two
schemes. However, I think

1. Separating the similar from the different parts of the code might be a
   rather larger project
   and
2. It might be orthogonal to the loop issue, in that it would still be part
   of the iteration (right?)

I'm good with forging ahead with option 2, and not the need for greater
modularization later on.
I'm in a bit of a hurry though, so apologies if I missed something.
-Rosie

On 16 June 2016 at 20:08, Bill Sacks [email protected] wrote:

This is an interesting question. I'm sure it warrants more thought than
the time I have to give it right now, so I'll answer based on gut feelings
and a quick skim through the code. So take this with many grains of salt
😄

First off: I'd be okay with (2), particularly in the short-term, and maybe
even in the long-term. It doesn't feel ideal, but it seems acceptable if
the cost:benefit ratio is too high for the alternatives.

As for (1): Maybe I'm missing something, but at a glance I'm thinking you
could do something relatively simple IF you have FATES and non-FATES
(i.e., CN?) both implement some common interface. This follows the vision I
started to lay out with CNVegetationFacade.F90 (in CLM:
src/biogeochem/CNVegetationFacade.F90 - see the comment at the top of that
file). In that case, you would have a Photosynthesis routine in the
interface. FATES would provide one implementation and non-FATES (CN) would
provide another. You would then pass the veg instance (either an instance
of FATES or an instance of CN) to CanopyFluxes, which would call
veg%Photosynthesis(...). But I fully acknowledge that it might take a while
to get to a place where that is possible, and furthermore that my vision
may not be the direction you want to take this.

However, writing out all of that made me see things that don't smell right
here. In particular, if we say we have a FATES version of Photosynthesis,
and if the options in the system are to have FATES or CN (or SP), then that
implies that we have a CN version of Photosynthesis. But I don't think
we've ever thought of Photosynthesis as being CN-specific. So that led me
to wonder why we have these two versions in the first place.

Looking quickly at the diff of the two versions of Photosynthesis, it
looks to me like the FATES/ED version began life as a copy of CLM's
Photosynthesis routine, and then evolved in ways necessary for the
differences in the ED data structures. It looks to me like the two are
fundamentally still doing the same science, just with different structures.

If this is the case, then I would ask a more fundamental question: Is it
really desired, long-term, to have a separate FATES version of
Photosynthesis, or should FATES use the Photosynthesis scheme implemented
by the host model? My gut feeling would be the latter. (So, if FATES
were plugged in to a host model with a fundamentally different
Photosynthesis operation, FATES would use that version.) Then the question
becomes: How would CLM's photosynthesis routine need to be rewritten so
that it could accommodate either FATES or non-FATES canopies?

My understanding is that we will need to tackle this question in CLM soon
anyway, when Gordon's multi-layer canopy comes in. My rough understanding
(possibly wrong, or at least incomplete) is that much of the difference
between Photosynthesis and EDPhotosynthesis comes down to the fact that
Photosynthesis is written to operate on sunlit vs. shaded fractions of the
canopy, whereas EDPhotosynthesis is written to operate on a multi-layer
canopy. I have talked a little bit with Rosie and Danica about how we could
rewrite this so that a single set of code could operate on either
structure. e.g., could we have some general notion of "multiple canopy
elements" (which could mean either multiple layers or sunlit vs. shaded
elements), and have the photosynthesis routine loop over each of these
canopy elements?

I encountered a specific instance of this problem with Danica's ozone
code: She wrote the code with the assumption that there are sunlit and
shaded canopy fractions, so right now it doesn't play nicely with ED/FATES,
nor will it play nicely with Gordon's multi-layer canopy scheme (I think).
At least in that context, it seemed like it could be relatively
straightforward to have N instances of the ozone stress variables, one for
each canopy element; N would be 2 for the standard CLM sunlit/shaded, and
equal to the number of layers in the canopy for FATES. Without this sort of
generalization, note that EDPhotosynthesis does not currently allow for
ozone stress. In my mind, that is an undesirable divergence, and an
argument for reconciling the two schemes.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#77 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AMWsQ785lHj4Dup3bB5zD_VAFQysai-Lks5qMgGKgaJpZM4I37qt
.

---

Dr Rosie A. Fisher

Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706

http://www.cgd.ucar.edu/staff/rfisher/

[billsacks]

@rosiealice : I don't think this is orthogonal: If we did away with EDPhotosynthesis, instead coming up with a single, unified Photosynthesis routine that lives in CLM (not FATES), then my understanding is that this whole original question goes away.

That said, the unified photosynthesis routine would presumably need to have some information from FATES (regarding canopy structure), so whatever information it needs would need to be queried through the FATES interface, I guess. I'm not sure what these queries would look like; maybe they would happen at a higher level and the information then passed down?

But I'm fine with the idea of deferring this merge of the two photosynthesis versions.

[bchristo]

#2 sounds good to me!

[bishtgautam]

I too agree with others that option-2 is the best way to proceed.

A side note on single vs multi-layer canopy model with/without sunlit and shaded leaves. Few things to consider:

• Dimensionality (N) and type (linear/nonlinear) of the system of equations to be solved
  • For a single-canopy model (N=1), it is "_trivial_" to find a solution to the non-linear equations (eq. 5.129 and 5.130 from CLM45 tech note).
  • For multi-canopy model (N > 1), depending on temporal discretization, one would be solving a system of linear or nonlinear equations.
• Mixing physics formulations within the system of equations to be solved
  • Photosynthesis from big-leaf model with sunlit + shaded leaves
  • Photosynthesis from ED without sunlit + shaded leaves
  • Photosynthesis from ED with sunlit + shaded leaves

[billsacks]

single vs multi-layer canopy model with/without sunlit and shaded leaves
Photosynthesis from ED with sunlit + shaded leaves

I know this is going off on a tangent, but does it really make sense to have sunlit vs. shaded leaves in a multi-layer canopy model? I thought the point of separating sunlit vs. shaded was to get a crude representation of different parts of the canopy without going so far as having a multi-layer model. With a multi-layer model, my understanding is that there is a natural continuum from sunlit to shaded.

[bishtgautam]

Excuse my ignorance on the motivation for moving towards a multi-layer canopy model and "ED with sunlit+shaded leaves" might not make sense scientifically.

[rosiealice]

Hi all,
I'm just on the bike ride, by agree we could review the sun\shade thing....
Rosie
On Jun 17, 2016 10:39 AM, "Gautam Bisht" [email protected] wrote:

Excuse my ignorance on the motivation for moving towards a multi-layer
canopy model and "ED with sunlit+shaded leaves" might not make sense
scientifically.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#77 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AMWsQ_ECvFd30wcvxSgOMancq4oaIvYTks5qMs3fgaJpZM4I37qt
.

[rgknox]

I'm trying to catch back up with you guys now!
@billsacks: I anticipate some of our leaf scientists on NGEE-T creating new photosynthesis modules over the next few years. Its possible that we will have several options for FATES and non FATES canopy simulators, maybe these will even evolve into a library of options?

The issue I see with a unified photosynthesis (ie the same code used for different forest simulatores, non-fates and fates), is that if we care about where it the subroutine for photosynthesis lives and restrict where it can be called, we will end up having these complicated tasks of passing complex canopy structure from FATES to the host. I'm not against it, just thinking out loud and there are probably good solutions to this.

In the two-stream multi-layered radiation model you can indeed parse out the amount of light absorbed in each leaf/stem layer by direct (beam,sunlit) and indirect (diffuse/shaded). We had traditionally just added the two, at least in ED2. What previously ended up happening was that the beam radiation intensity attenuates over depth. But another way to cast it, is to maintain the light intensity over the depth of the canopy and attenuate the fractional coverage of the beam. I think the latter is more physically realistic, and especially seeing how photosynthesis is a non-linear process, it would (I expect) yield different results, even if energy is conserved.

I will start moving forward on option 2 until we come up with a new game-plan.

[billsacks]

@rgknox : Yes, if you envision FATES developing its own Photosynthesis schemes then I think that's a good argument against my suggestion.