search

NGEET / fates

repository for the Functionally Assembled Terrestrial Ecosystem Simulator (FATES)
Other
99 stars 91 forks source link

Interface: CanopyFluxes calls EDPhotosynthesis in a complicated loop #77

Closed rgknox closed 8 years ago

rgknox commented 8 years ago

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 commented 8 years ago

Here are some relevant links to the source code:

billsacks commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/NGEET/ed-clm/issues/77#issuecomment-226663213, 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 commented 8 years ago

@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 commented 8 years ago

2 sounds good to me!

bishtgautam commented 8 years ago

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:

billsacks commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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" notifications@github.com 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 https://github.com/NGEET/ed-clm/issues/77#issuecomment-226819056, or mute the thread https://github.com/notifications/unsubscribe/AMWsQ_ECvFd30wcvxSgOMancq4oaIvYTks5qMs3fgaJpZM4I37qt .

rgknox commented 8 years ago

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 commented 8 years ago

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