ckoven
commented
7 years ago @rosiealice do we assume currently that if use_ed is true, then use_cn is false?
Closed rosiealice closed 7 years ago
ckoven
commented
7 years ago @rosiealice do we assume currently that if use_ed is true, then use_cn is false?
rgknox
commented
7 years ago self assigning
I think main/controlMod.F90 is where module incompatibility is handled @ckoven. And yes, it will gracefully abort if both are true.
rgknox
commented
7 years ago Following Rosie's list, I will add new logic to controlMod.F90:
if(use_ed)then
if(use_hydstress) fail ! Is this PHS @rosiealice ?
if(use_voc) fail
if(use_lch4) fail
endstill looking through this module...
@billsacks , could you comment on what flags relevant to dynamic LU and should be on/off with ed? or other?
ckoven
commented
7 years ago @rgknox great, thanks. given that, there ought to be no issue with the soilbiogeochem/SoilBiogeochemVerticalProfileMod.F90. that subroutine (SoilBiogeochemVerticalProfile) is called by CNDriverMod.F90 (which assumes use_cn==.true.), and in clm_driver.F90, (in a use_cn == .true. bracket).
the functionality of that block of code is duplicated in flux_into_litter_pools in EDPhysiologyMod.F90
billsacks
commented
7 years ago @rgknox - search for use_ed in the CLM source: src/dyn_subgrid/dynSubgridControlMod : check_namelist_consistency. At least, I think that's what you're asking about....
rgknox
commented
7 years ago thanks @billsacks . Let me learn more about what goes on in dyn_SubgridControlMod, and then I will retro-actively decide what I was asking about!
rgknox
commented
7 years ago I have a new branch working on cleaning some of these up. It is partial progress.
There are a few things going on. First, we need FATES to determine the leaf characteristic length (dleaf), the roughness length (z0m) and the displacement height (displa) for its patches. Currently, the model is estimating these values on the HLM side, using the itype associated with the pft number, which is kinda-nonsense from the FATES perspective. My plan is to get the new system to transfer meaningful values over from fates, but maintain b4b.
I would also like fates to set the patch%itype on patches under its juristiction to a force fail value, so it does not accidentally get used when its not supposed to. Although, without debug flags, gnu just chuggs along without complaint when I request variables using an index of -999 from patch%itype. Although I am pretty confident tests will detect this no-problemo, as we have plenty of bounds checking flags turned on.
https://github.com/NGEET/ed-clm/compare/master...rgknox:rgknox-clean-itypes
bandre-ucar
commented
7 years ago Force fail should probably be nan or spval for consistency.
rgknox
commented
7 years ago got it, I found ispval in clm_varcon which should do the trick
rgknox
commented
7 years ago I checked through your list @rosiealice , thanks, that was a very helpful guide. I should have a PR soon that addresses each of these issues. I also double checked dynSubgridControlMod and indeed there is a check to make sure use_ed is not true if the "do_transient_pfts" flag is true.
As part of the solution I added a new logical filter on the HLM side: patch%is_fates. This filter is true for all patches that are under fates jurisdiction. This was also suggested by the NCAR engineering team, to help filtering on how soil to root water fluxes are handled in hydraulics.
In cases where the HLM was using itypes in a process that FATES had an alternative implementation for, the HLM process was simply checked against the is_fates logical filter, and asked for a boundary condition from fates as an alternative if true.
In cases where FATES could provide no alternative implementation of a process and the process assumed that patches = pft, (such as methane, ozone, dry-deposition, luna, and voc'), a check on the namelist flags in controlMod.F90 forces the user to set these flags to false.
In some of the cases lists, such as the harvesting, it was not being called anyway, because it was being called via CN.
Compatibility with PHS will be covered in a later changeset.
@ckoven : the stuff in soilbiogeochem/SoilBiogeochemVerticalProfileMod.F90 is not called for FATES, but I think we still need to identify if we need something similar implemented in FATES. Could you help with that?
rosiealice
commented
7 years ago Just cleaning up my messages. This sounds like a very robust scheme to me. Should help a great deal for the more complicated interactions we discussed (crops, etc)
On 19 March 2017 at 22:43, Ryan Knox notifications@github.com wrote:
I checked through your list @rosiealice https://github.com/rosiealice , thanks, that was a very helpful guide. I should have a PR soon that addresses each of these issues. I also double checked dynSubgridControlMod and indeed there is a check to make sure use_ed is not true if the "do_transient_pfts" flag is true.
As part of the solution I added a new logical filter on the HLM side: patch%is_fates. This filter is true for all patches that are under fates jurisdiction. This was also suggested by the NCAR engineering team, to help filtering on how soil to root water fluxes are handled in hydraulics.
In cases where the HLM was using itypes in a process that FATES had an alternative implementation for, the HLM process was simply checked against the is_fates logical filter, and asked for a boundary condition from fates as an alternative if true.
In cases where FATES could provide no alternative implementation of a process and the process assumed that patches = pft, (such as methane, ozone, dry-deposition, luna, and voc'), a check on the namelist flags in controlMod.F90 forces the user to set these flags to false.
In some of the cases lists, such as the harvesting, it was not being called anyway, because it was being called via CN.
Compatibility with PHS will be covered in a later changeset.
@ckoven https://github.com/ckoven : the stuff in soilbiogeochem/ SoilBiogeochemVerticalProfileMod.F90 is not called for FATES, but I think we still need to identify if we need something similar implemented in FATES. Could you help with that?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/ed-clm/issues/196#issuecomment-287678024, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ826YsPXH1_ThzZkJ3OgiZQ2wttWks5rngPcgaJpZM4MYffF .
Dr Rosie A. Fisher
Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706
VOCs SHOULD BE INCOMPATIBLE WITH ED
METHANE SHOULD BE INCOMPATIBLE WITH ED
DO NOT USE ENTIRE ROUTINE
DO NOT USE ENTIRE ROUTINE (This is potentially already done. Is within a use_cn in CLM_driver and use_cn is false if use_ed is true...)
LAND USE SHOULD BE INCOMPATIBLE WITH ED
LUNA SHOULD BE INCOMPATIBLE WITH ED
THIS NEEDS PROPERLY FIXING WITH A PATCH PROPERTY FOR DLEAF SENT FROM FATES
OZONE SHOULD BE INCOMPATIBLE WITH ED
DO NOT USE ENTIRE ROUTINE. Might have to be careful with this one incase the root profiles show up somewhere unexpected. --
THIS NEEDS PROPERLY FIXING WITH A PATCH PROPERTY FOR z0m AND displa SENT FROM FATES
PHS SHOULD BE INCOMPATIBLE WITH ED
PHS SHOULD BE INCOMPATIBLE WITH ED -This usage is within a PHS-specific routine.
THINK THIS SHOULD BE REPLICATED BY ED. ASK @ckoven TO CONFIRM
DYN LU SHOULD BE INCOMPATIBLE WITH ED. (ask Bill where to turn off)
DEFINITION OF ITYPE
DEFINITION OF ITYPE
DEFINITION OF ITYPE
DEFINITION OF ITYPE
DEFINITION OF ITYPE