FATES doesn't work with MEGAN for normal FATES competitive modes #115
Comments
|
Erik Kluzek < erik > - 2015-05-12 15:19:59 -0600 These are the two tests that failed. ERS_D_Mmpi-serial_Ld5.1x1_brazil.ICLM45ED.yellowstone_intel.clm-edTest There are some tests that actually passed even with the issue. So it must be partially dependent on the compiler. But, I'm having build-namelist to make sure MEGAN is off if ED is on, and the ED tests will now be with MEGAN off. And there was an issue in clm.buildnml that didn't allow MEGAN to be off, so I fixed that as well. |
|
Erik Kluzek < erik > - 2015-05-12 16:12:09 -0600 The SMS gnu test still fails with the following error... That is with MEGAN turned off. |
|
Erik Kluzek < erik > - 2015-05-14 10:50:41 -0600 By turning off a bunch of history fields, I got it to run further. Then it stopped in RTM, so I turned RTM off... Change user_nl_clm hist_fincl1 to... hist_fincl1 = 'GPP','BTRAN','H2OSOI','LITTER_IN', And make a bunch of those fields inactive... Index: ../../components/clm/src/ED/main/EDCLMLinkMod.F90
===================================================================
--- ../../components/clm/src/ED/main/EDCLMLinkMod.F90 (revision 70648)
+++ ../../components/clm/src/ED/main/EDCLMLinkMod.F90 (working copy)
@@ -221,19 +221,23 @@
call hist_addfld2d (fname='PFTbiomass', units='kgC/m2', type2d='levgrnd', &
avgflag='A', long_name='total PFT level biomass', &
- ptr_patch=this%PFTbiomass_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%PFTbiomass_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld2d (fname='PFTleafbiomass', units='kgC/m2', type2d='levgrnd', &
avgflag='A', long_name='total PFT level biomass', &
- ptr_patch=this%PFTleafbiomass_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%PFTleafbiomass_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld2d (fname='PFTstorebiomass', units='kgC/m2', type2d='levgrnd', &
avgflag='A', long_name='total PFT level biomass', &
- ptr_patch=this%PFTstorebiomass_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%PFTstorebiomass_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld2d (fname='PFTnindivs', units='kgC/m2', type2d='levgrnd', &
avgflag='A', long_name='total PFT level biomass', &
- ptr_patch=this%PFTnindivs_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%PFTnindivs_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld1d (fname='FIRE_NESTEROV_INDEX', units='none', &
avgflag='A', long_name='nesterov_fire_danger index', &
@@ -249,7 +253,8 @@
call hist_addfld1d (fname='FIRE_TFC_ROS', units='none', &
avgflag='A', long_name='total fuel consumed', &
- ptr_patch=this%TFC_ROS_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%TFC_ROS_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive')
call hist_addfld1d (fname='FIRE_INTENSITY', units='kJ/m/s', &
avgflag='A', long_name='spitfire fire intensity: kJ/m/s', &
@@ -261,27 +266,33 @@
call hist_addfld1d (fname='SCORCH_HEIGHT', units='m', &
avgflag='A', long_name='spitfire fire area:m2', &
- ptr_patch=this%scorch_height_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%scorch_height_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld1d (fname='fire_fuel_mef', units='m', &
avgflag='A', long_name='spitfire fuel moisture', &
- ptr_patch=this%fire_fuel_mef_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%fire_fuel_mef_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld1d (fname='fire_fuel_bulkd', units='m', &
avgflag='A', long_name='spitfire fuel bulk density', &
- ptr_patch=this%fire_fuel_bulkd_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%fire_fuel_bulkd_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld1d (fname='fire_fuel_eff_moist', units='m', &
avgflag='A', long_name='spitfire fuel moisture', &
- ptr_patch=this%fire_fuel_eff_moist_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%fire_fuel_eff_moist_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld1d (fname='fire_fuel_sav', units='m', &
avgflag='A', long_name='spitfire fuel surface/volume ', &
- ptr_patch=this%fire_fuel_sav_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%fire_fuel_sav_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive' )
call hist_addfld1d (fname='TFC_ROS', units='m', &
avgflag='A', long_name='spitfire fuel surface/volume ', &
- ptr_patch=this%TFC_ROS_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%TFC_ROS_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive')
call hist_addfld1d (fname='SUM_FUEL', units=' KgC m-2 y-1', &
avgflag='A', long_name='Litter flux in leaves', &
@@ -293,7 +304,8 @@
call hist_addfld1d (fname='LITTER_OUT', units=' KgC m-2 y-1', &
avgflag='A', long_name='Litter flux out leaves', &
- ptr_patch=this%litter_out_patch, set_lake=0._r8, set_urb=0._r8)
+ ptr_patch=this%litter_out_patch, set_lake=0._r8, set_urb=0._r8, &
+ default='inactive')
call hist_addfld1d (fname='SEED_BANK', units=' KgC m-2', &
avgflag='A', long_name='Total Seed Mass of all PFTs', &
@@ -347,7 +359,8 @@
this%storvegc_patch(begp:endp) = spval
call hist_addfld1d (fname='STORVEGC', units='gC/m^2', &
avgflag='A', long_name='stored vegetation carbon, excluding cpool', &
- ptr_patch=this%storvegc_patch)
+ ptr_patch=this%storvegc_patch, &
+ default='inactive')
this%leafc_patch(begp:endp) = spval
call hist_addfld1d (fname='LEAFC', units='gC/m^2', &
@@ -377,7 +390,7 @@
this%npp_patch(begp:endp) = spval
call hist_addfld1d (fname='NPP', units='gC/m^2/s', &
avgflag='A', long_name='net primary production', &
- ptr_patch=this%npp_patch)
+ ptr_patch=this%npp_patch, default='inactive')
end subroutine InitHistory
Index: ../../components/clm/src/biogeophys/CanopyStateType.F90
===================================================================
--- ../../components/clm/src/biogeophys/CanopyStateType.F90 (revision 70648)
+++ ../../components/clm/src/biogeophys/CanopyStateType.F90 (working copy)
@@ -168,7 +168,7 @@
this%tlai_patch(begp:endp) = spval
call hist_addfld1d (fname='TLAI', units='none', &
avgflag='A', long_name='total projected leaf area index', &
- ptr_patch=this%tlai_patch)
+ ptr_patch=this%tlai_patch, default='inactive')
this%tsai_patch(begp:endp) = spval
call hist_addfld1d (fname='TSAI', units='none', &
Index: ../../components/clm/src/main/atm2lndType.F90
===================================================================
--- ../../components/clm/src/main/atm2lndType.F90 (revision 70648)
+++ ../../components/clm/src/main/atm2lndType.F90 (working copy)
@@ -255,7 +255,7 @@
this%forc_wind_grc(begg:endg) = spval
call hist_addfld1d (fname='WIND', units='m/s', &
avgflag='A', long_name='atmospheric wind velocity magnitude', &
- ptr_lnd=this%forc_wind_grc)
+ ptr_lnd=this%forc_wind_grc, default='inactive')
! Rename of WIND for Urban intercomparision project
call hist_addfld1d (fname='Wind', units='m/s', &
avgflag='A', long_name='atmospheric wind velocity magnitude', & |
|
Erik Kluzek < erik > - 2015-05-14 13:28:37 -0600 In clm4_5_1_r106 when ED is on, MEGAN is NOT allowed to be on in the build-namelist. |
ekluzek
added
bug
|
I'm assigning this as a WONTFIX for now, and closing. This is a recognized problem that will take some effort to solve. Right now it doesn't seem needed, so we will wait until it does seem to be needed. |
ekluzek
added
the
FATES
|
Since there is discussion of moving to FATES as a default configuration, it seems like this will need to be worked on. |
|
thanks for bringing this up @billsacks I will mention it in my "data" talk as a needed development |
billsacks
removed
the
closed: wontfix
|
I'm adding a simple test for this so that we'll keep this in mind. It's now being setup so that turning MEGAN on with FATES is a warning that you can bypass, which will allow for us to test this. |
|
Similar to #1044 MEGAN is setup based on PFT types, so we should be able to get it to work with FATES-SP, but it will require more effort to get working for general FATES. |
|
In theory it should also work whenever theb NOCOMP switch is on, (which includes SP mode) since that forces one PFT per patch... |
|
@rosiealice thanks for pointing that out. The important thing there will be to update the Patch vegetation itype array (i.e. ivt), which other than SP mode is currently just wrong for FATES. But, it could be updated each time that FATES is called. As a matter of fact as a first pass for FATES you could fill it with whatever veg type was the dominant type in the patch, and then use that for these things that need ivt to be functional. In the end the right way to do it will be evaluate each veg type in the patch and then aggregate it up to the patch level. It's not completely clear how to that in FATES though since vegetation types overlap each other unlike in CTSM. Could you evaluate what percent of the patch each veg type covers in FATES looking down over the patch? One way to look at this would be to just use what veg types you can see when looking down over the patch. |
|
Hi Erik, So, before we had SP mode, the intention with the FATES implementation we to reproduce everything the HLM indexes with ivt in FATES. I.e. there should be no instances where the host model needs to know the vegetation type in each patch because FATES should pass back the relevant quantities instead. That at least is the j te toon. So, it would be interesting to note if and where there are instances where patches having an IVT identity remains necessary. I know this is the case for MEGAN, but have you noticed this elsewhere? It's difficult to say we will map the identity of the dominant PFT back to the HLM as there is not a 1:1 correspondence between the fates and HLM PFTs. I.e. FATES might well include PFTs that do not exist in the HLM. My experience has been that making the code pass back the relevant vegetation quantities is typically a matter of providing a weighted average of the property across PFTs, or something specifically tailored (as in the case of roughness length). So yes, where were you thinking of that might need an IVT identity? Thanks! Rosie |
ekluzek
added
next
|
@rosiealice thanks so much for the discussion. As far as I can tell IVT is only needed for MEGAN and dry-deposition. I actually think it might be good to set IVT to bad values so that we can detect if it's used anywhere else. The problem is that the algorithms for both of these (MEGAN and drydep) are very hardwired to only be dependent on vegetation type. They actually do another mapping of veg-type, which as you point out means we map from FATES to CLM to something else and like in language translations each of these steps could be wrong. I think the reason for this is that the whole basis of the work in MEGAN and drydeposition must have been very dependent on vegetation type. The datasets that are at the heart of each have data that is binned by their vegetation types. Since the current science was developed to be based on veg-type, it's a big science research project to base it on something else. But, you are right long-term FATES scientists need to sit down with CAM-Chem people as well as developers of MEGAN and dry-deposition and figure out a method that wouldn't be dependent on veg-type. I think that's a big project that likely requires funding though. Also note that for nocomp mode this will be straightforward. And I think fixed biogeography is a bit simpler as well right? Now, another part of this that we should think about is "what communities are going to be using MEGAN and dry-deposition"? It's required for the CAM-Chem community who could probably be happy with only running FATES-SP (at least to start with). I think they could also be OK if there are known limitations, errors and requirements for running with FATES when you want to output MEGAN and dry-deposition. This community is also not going to be messing with the FATES parameter file, so we could put restrictions on the parameter file to make sure the translation of veg-types is reasonable. The other consideration is that we only need FATES and dry-deposition and MEGAN to all work together robustly is when FATES becomes the only way to run CTSM. Since that's at least a few years out, the schedule for this can be somewhat longterm. All of this makes we want to suggest the following path forward (and I'd love to get feedback on this plan):
How does that sound for a plan for going forward? The first few steps could/should be done pretty soon. But, the final one is likely several years out (unless funding could be found sooner). @rosiealice @wwieder @ckoven @jkshuman @dlawrenncar @danicalombardozzi and others do you want to give feedback on that plan? I also added "next" so we'd discuss at the next CTSM-Software meeting and the FATES community should also discuss as well. |
|
I don't have many comments, other than to add that VOC emissions (in real life) vary by plant type. I'm not sure if this is included in MEGAN and if that is the reason why IVT is important. I am relatively confident that MEGAN uses LAI and stomatal conductance to calculate emissions, and I thought there was some new work by Alex Gunther's group to add in a photosynthesis component. |
|
The latest backtrace for how this is failing in what will be ctsm5.1.dev099 is as follows: |
|
@danicalombardozzi MEGAN bins veg-types into broad classes, this is where the vegetation type comes into play. It also uses things like fraction that's sunlit, canopy temperature, LAI, and stomatal conductance as you point out. We can use FATES to get the averaged quantities for those things on each patch, the sticky part is the vegetation type bins that are used. There is an update to use a newer version of MEGAN that adds more input variables into the mix see #1323 The type bins are: crops, Also see NGEET/fates#879 |
|
By the way I think what needs to happen to get this to work for FATES-SP is to add a "prep_megan" subroutine to clmfates_interface... if (use_fates) then
call clm_fates%prep_meganfluxes(nc, fn, filterp, canopystate_inst, temperateure_inst, photosyns_inst )
end ifthat will fill the temperature, canopystate, and photosyns type arrays that are used for input with values from FATES. Once that is done I think FATES-SP should work with MEGAN. |
|
It looks like we'll get FATES to work with MEGAN when in FATES-SP mode in #1766. At least for a dead simple single point test we added. We should still look at the code to make sure that's correct and that it's creating reasonable output. |
|
@jkshuman and I met and talked about plans forward. I'm going to edit the plan above based on our conversation. We think that the near term things will be to do a little work with FatesSP and nocomp mode. We think we should hold off on getting this to work in general for FATES, and put it at a low priority until there are people that want to work on this (and possibly get funding for this as it's really a research question). |
billsacks
removed
the
next
|
@ekluzek thanks for updating the plan in the comments above. We discussed this amongst the FATES folks today and, instead of limiting the FATES parameter file to match MEGAN, @rosiealice and @adrifoster suggested adding a FATES parameter that would associate the FATES PFT with a defined MEGAN emissions factor. This way users can modify the FATES file, and the emissions will be associated existing information in MEGAN. This does not address the reality that there are more emissions factors for specific plants, and so limits the association to what is defined in MEGAN. @ekluzek do you see any problems with this approach of having FATES provide the MEGAN emission factor associated for a specific FATES PFT? |
|
@jkshuman in principle I like that idea. Then what you do is match the FATES parameter file with the MEGAN dataset for consistency checking. And as you point out you could expand both the FATES PFT types and MEGAN emission factor PFT types at the same time. But, I do see problems with actually doing that. The two things I'm not sure about though is the need for this to also work with dry deposition, which has the same six large bins as done in MEGAN, but unfortunately the dry deposition bins are hardcoded in rather than in a dataset. But, I can check with @fvitt if they have an intention of getting away from that. Since, dry-deposition is something that only CAM-Chem people care about this difference might be OK as well, as long as we have default datasets that work together. I think what it means is that the consistency checking for FATES with dry-deposition would need to compare to a hardcoded list of PFT types So MEGAN and FATES can compare their lists and make sure they are the same, and then FATES could make sure it's list is the same as for the dry-deposition hard-coded list (which effectively means if you turn on both MEGAN, FATES, and dry-deposition that you'd need to use the default datasets). But, it does perhaps mean that MEGAN and FATES could be made to have custom veg-types that could work together. The other thing I'm not sure about is in looking at the current MEGAN dataset, I see it uses the 78-PFT's Now, it still lumps the emission factors for 78 PFT's into the six broad veg classes that MEGAN uses internally. And it does for example make sure that the number of PFT types agrees with the 78 used in CTSM. And it assumes the PFT names are from the CTSM parameter file. So you couldn't immediately do the coordination of MEGAN and FATES as you want, but with some work we could be able to get it to work. What it probably needs is to move the six vegetation categories that MEGAN assumes to be described in the dataset rather than hard-coded into the MEGAN model. Here's the current MEGAN file: $DIN_LOC_ROOT/atm/cam/chem/trop_mozart/emis/megan21_emis_factors_78pft_c20161108.nc |
|
@lkemmons should be able to provide advice on how MEGAN emissions should be implemented |
|
@ekluzek ok. we can talk more about it, but it sounds like this should work. To be clear the intention is that in the FATES parameter file a new field (FATES_MEGAN_PFT or something descriptive that would also work with dry deposition) would be added that provide the MEGAN vegetation class for each FATES PFT. This can be whatever makes sense (an integer, the PFT name or abbreviation, etc) to pass to MEGAN for these calculations. The intention is that, similar to what it sounds your describe is happening with CTSM, there can be more PFTs but they are associated with MEGAN via the known vegetation categories. |
|
@ekluzek ok. I understand better your comment after looking at the file. it looks like as you said the MEGAN file is created for the 78 CTSM pfts and as you indicated uses the "PFT_name" and "PFT_number". I add here the PFT names and then file details from this MEGAN file. We would need to confirm if these broad veg class categories are consistent across all the PFTs (there really are only 6 emissions classes) or if we should just associate a FATES PFT with an existing PFT in the MEGAN dataset. For example, a user could have a simulation with PFTS for spruce and pine which would both be classified as FATES_MEGAN_PFT = needleleaf_evergreen_boreal_tree and be associated with that emissions profile
// global attributes: |
|
I am happy to be part of this development - connecting FATES to MEGAN and dry dep. |
|
thanks @lkemmons I will get in touch with you, and we can also set up a meeting with Alex Guenther. I will check in with a group of FATES folks to see who might join the call depending on availability. (@rosiealice @ckoven @adrifoster ?) It will be good to discuss a plan with existing data and resources and future capabilities with expanded information and additional funding. |
|
The conversion from the fine grained PFT categories (the 78 PFTs) to the six emission categories is here: https://github.com/ESCOMP/CTSM/blob/master/src/biogeochem/VOCEmissionMod.F90#L700 Right now that is done based on the CTSM parameter PFT list, to make this more general we should move that mapping onto the MEGAN dataset. For FATES users will modify their list of PFT's on the FATES parameter file and we'll want to ensure that the PFT's on the FATES parameter file is what agrees with the MEGAN dataset. That would allow someone to make a custom list of FATES PFT's and still use the MEGAN file with it. I think we also want to allow people to make a custom FATES parameter file to modify their PFT list, as well as a custom MEGAN dataset that goes along with it. That might be a bigger lift though, I think MEGAN might be pretty hard-coded to just handle those six vegetation classes. And everything I say here also applies to dry-deposition, so when dry-deposition has a dataset (rather than hardcoded constants in the FORTRAN code) the same sort of thing could be done for it. So I'm glad that @lkemmons said you are getting away from the hard-coded constants for dry-deposition. Also a couple of us are meeting Friday to go over this, which will be good to clarify some of this. |
ekluzek
changed the title
ekluzek
added
the
closed: wontfix
|
To get this to work with competition in FATES is going to be a long term goal, and will require science support and research. We have this working for FATES-SP mode. And I will create a new issue for no-comp mode. |
jkshuman
moved this from In Progress
to Close for now, won't fix
in CTSM-FATES priorities
Erik Kluzek < erik > - 2015-05-11 16:17:41 -0600
Bugzilla Id: 2176
Bugzilla CC: rfisher, sacks,
MEGAN at least functioned before clm4_5_1_r106, but in clm4_5_1_r106, MEGAN fails here...
if ( (cisun_in .eq. cisun_in) .and. (cisha_in .eq. cisha_in) .and. (forc_pbot_in > 0._r8) .and. (fsun_in > 0._r8) ) then
ci = ( fsun_in*cisun_in + (1._r8-fsun_in)*cisha_in )/forc_pbot_in * 1.e6_r8
cisun_in and cisha_in are still set to missing value (-999.) and hence the calculation fails.
Definition of done: FATES works with MEGAN for standard FATES mode with competition
The text was updated successfully, but these errors were encountered: