GPP can't change with GDD

[niuhanlin]

Hello, everybody!
I changed the GDD to fit the local area. The goal was to get the onset and offset of the observed GPP.
But GPP does not change with GDD.
I wonder if it is possible that GDD and GPP are not linked?
Does anyone have any ideas?
If anyone can offer advice, I would be very grateful!

version: sci.1.59.3_api.24.1.0

[rosiealice]

So, I guess the thing to do is to look at the LAI timeseries before and after the change, to check whether your modifications have successfully shifted the growing season. What part of the GDD calculation did you modify?

[niuhanlin]

So, I guess the thing to do is to look at the LAI timeseries before and after the change, to check whether your modifications have successfully shifted the growing season. What part of the GDD calculation did you modify?

The LAI Timeseries also remained unchanged after modification.

The following is what I changed:

1. I changed ncdstart from 270 to 240 in the Northern Hemisphere in the subroutine phenology in EDPhsiologyMod.F90.

2. Add 3°C to ED_val_phen_chiltemp and ED_val_phen_coldtemp, respectively, according to site observation.

3. Change temp_in_C greater than 0°C to greater than 3°C at line 810 in EDPhsiologyMod.F90.

4. currentSite%cleafoffdate and currentSite%cleafondate were changed from 300 to 270,100 to 105, respectively, based on site observation analysis.

[rgknox]

The LAI series should be changing with those modifications. @niuhanlin could you post your lnd_in file so we can check your namelist settings?

[niuhanlin]

The LAI series should be changing with those modifications. @niuhanlin could you post your lnd_in file so we can check your namelist settings?

If there are any documents needed, I can provide them.

In addition, I would like to know what modifications should be made to LAI?
lnd_in.zip

[rgknox]

@niuhanlin I don't see any issues with your lnd_in file. Could you also upload your parameter file?
What history variable are you using to report GPP? Note, I would not use the CLM GPP estimate while running FATES, use the FATES specific history variables, such as:

'FATES_GPP' , units='kg m-2 s-1', long='gross primary production in kg carbon per m2 per second'
or
'FATES_GPP_PF' , units='kg m-2 s-1', long='total PFT-level GPP in kg carbon per m2 land area per second'

[niuhanlin]

@niuhanlin I don't see any issues with your lnd_in file. Could you also upload your parameter file? What history variable are you using to report GPP? Note, I would not use the CLM GPP estimate while running FATES, use the FATES specific history variables, such as:

'FATES_GPP' , units='kg m-2 s-1', long='gross primary production in kg carbon per m2 per second' or 'FATES_GPP_PF' , units='kg m-2 s-1', long='total PFT-level GPP in kg carbon per m2 land area per second'

We have GPP site observations by eddy- tower, it can be easily compared with simulation results.
And I note that the FATES GPP output variable is different from the CLM GPP, and the units I have converted.
But one thing I noticed is that the site is located in the grassland and the PFT of 'FATES_GPP_PF' is concentrated below 5. Is that the right result?

The default parameter file is not changed and all the above operations are achieved by changing EDPhsiologyMod.F90.

fates_params_api.24.0.0_12pft_c220608.zip

[rgknox]

There could be many reasons why the first five PFTs are the particularly productive ones, but my sense is that your simulation will require the filtering and calibration of the PFTs relevant to your simulation, as well as site level meteorological and soils data. Here is the list of PFT names in the parameter file you posted (which I see you noted was the default) for reference (grasses are PFTs 10-12).

 "broadleaf_evergreen_tropical_tree          ",
  "needleleaf_evergreen_extratrop_tree        ",
  "needleleaf_colddecid_extratrop_tree       ",
  "broadleaf_evergreen_extratrop_tree         ",
  "broadleaf_hydrodecid_tropical_tree         ",
  "broadleaf_colddecid_extratrop_tree        ",
  "broadleaf_evergreen_extratrop_shrub        ",
  "broadleaf_hydrodecid_extratrop_shrub       ",
  "broadleaf_colddecid_extratrop_shrub       ",
  "arctic_c3_grass                            ",
  "cool_c3_grass                              ",
  "c4_grass                                   " ;  

The lnd_in file indicates that this is not an inventory initialized simulation, so the simulation is starting with a density of new recruits, correct? If this is the case, and you simulation is not showing dynamic LAI or GPP, it sounds like perhaps the calibration or met data is creating a scenario where there is no growth? But it could be other things too. We could continue to trouble shoot this here, but it would be good to see some timeseries plots of things like FATES_GPP, FATES_NPP, sum(FATES_NPLANT_PF), FATES_VEGC, FATES_LEAFC,

Also, I would turn off fates hydro (set use_fates_hydro = .false.) in the user_nl_clm file to start. It adds more parameters and complications. Once you get a simulation that is generated reasonable and sensible output, then hydro is something that can be turned on. This will also make the model run faster which helps to solve problems rapidly.

[niuhanlin]

Thank you for your patient reply. I am trying to solve the problems related to PTF.
I can provide some information about the current operation, as follows:

I use the surface file generated by CESM2.1.3, in which the PFT of grass is 13.
Do I need to use CTSM to regenerate it? Does the build process set the PFT number to 12? If I set it to 12, will FATES be able to tell if it's a grass?
Is there a document documenting the PTF conversion between CLM and FATES?

To answer your questions:

The simulation started with the restar file and was spin-up for 500 years.
LAI and GPP showed dynamic changes over time, but their onset was too early and offset was too late in each year.
FATES_GPP and FATES_LEAFC are shown below:

[rgknox]

When FATES is active, and not using Satellite Phenology Mode or No Competition mode (which is the case here) , the PFT definitions in CTSM and CLM are completely ignored. The only PFT definitions that are relevant, are those that are in the FATES parameter file.
When fates is active, the surface file information regarding soils and the fraction of natural vegetation is used, but the PFT information is ignored.

[rosiealice]

Which I guess is to say that if you want to. Have FATES use the PFTs on the surface dataset, you should set the use_fates_fixedbiogeog and use fates_nocomp to true. Then you will get only the PFTs in the fates pft file that are mapped onto the CTSM PFTs with the hlm_pft map matrix (in the fates pft file).

Noting, to myself primarily, that the user manual on these modes is on my to do list.

Otherwise the LAI is going down here. Looks like something might be throttling productivity. Is the soil very dry?

[niuhanlin]

@rgknox @rosiealice Hello! These Settings have solved my earlier problem. Thank you so much!
But I have a new problem. I want to keep the dynamic vegetation competitive and use the prescribed pft in the study site or area. So I use the fsurafce file during spin-up and turn on fixed biogeography mode. But when I use the restar file after spin-up and the previous fsurface file, keeping the fixed biogeography mode on, the GPP will always remain at 0 and the LAI has a strange change. Do you have any suggestions? By the way these problems don't happen with FATES-SP, but that's not what I want.

@rosiealice The site is in a sub-humid area where the soil is not very dry, but its results are slightly overestimated compared to observations.

[rgknox]

Is that GPP and LAI from all PFTs, or one specific PFT?
If the latter, its possible that after the simulation switched from fixed biogeography to non-biogeography, a different PFT started to out-compete the PFT you are plotting here?
I personally have not tried spinning up with biogeography and then turning it off. But, I see no reason it would not work, and we did add it with the intention of this type of workflow.

[niuhanlin]

Is that GPP and LAI from all PFTs, or one specific PFT? If the latter, its possible that after the simulation switched from fixed biogeography to non-biogeography, a different PFT started to out-compete the PFT you are plotting here? I personally have not tried spinning up with biogeography and then turning it off. But, I see no reason it would not work, and we did add it with the intention of this type of workflow.

I may not have been clear. I keep fix_biogeography turned on all the time. I first did a 500 year spin-up and applied its output *.r file to the new case. In the new case, the weird change of GPP and LAI as shown above happens.
For now, what I want to do is to keep fix_biogeography on, and I want to conduct a study on regional dynamic vegetation under the prescribed PTF. Do I need to do a spin-up? Or do you have any workflow suggestions?

[rgknox]

The issue could be this bug: #894
Are you using the latest tag: https://github.com/NGEET/fates/releases/tag/sci.1.59.4_api.24.1.0 ? it does fix the bug.

[niuhanlin]

The issue could be this bug: #894 Are you using the latest tag: https://github.com/NGEET/fates/releases/tag/sci.1.59.4_api.24.1.0 ? it does fix the bug.

Thankfully this problem was solved by using sci.1.59.4_api.24.1.0. But it seems as if the model enters another situation.
GPP changes abruptly at onset and offset. The change in GPP is chaotic, with no tapered change, between 2013 and 2017.
I guess the conditions for GDD to exist have become more demanding.

I attach GDD and GPP for your reference.

[rgknox]

It looks to me like the GDD is growing from zero, and once it passes a threshold, the leaves flush. Before the leaves flush, the GPP is 0, and then when they drop, it returns to zero again. So the leaf flushing and dropping should explain the abrupt changes in GPP. I'm noticing that the once the leaves flush, the GDD is reset to zero, thats why it spikes. ALso, the GDD reset matches the start of non-zero GPP.
I'm not sure if the timing is correct, but the patterns seem sensible.

[rosiealice]

Yeah, this looks like the intended behaviour more or less. We start counted GDD after jan/July 1st, I think, (depending on hemisphere) and so it rapidly goes up, the leaves come on, and it is zeroed out again until next year.

GPP goes up rapidly as we don't have a gradual lead ramp up yet, they all flush at once. Adding this is an aspiration, but it is a big coding headache in terms of restarting etc...

Are your trees growing now?

[niuhanlin]

The reason I think it is incorrect is that the dynamics of the GPP are more consistent with observations when the MODE is in FULL COMPLEXITY MODE.
I am also trying to modify the MODE to make it more accurate in FIXED BIOGEOGRAPHY MODE, but it is still difficult for me.
So I'm going to have to run a few tests that we can analyze.

@rosiealice The tree hasn't been tested yet.

[niuhanlin]

The issue has now been resolved.