CLM5

[Chengyun]

Dear,

Sorry to bother you. I try to simulate GPP from 1980 to 2010 and the future GPP(SSP585) from 2020 to 2050 using CLM5-FATES to run compset I2000Clm50FatesGs and res f05_g16. Here is my confusion about the steps.

(1) First create a spin-up case (I2000Clm50Fates_spinup) to evaluate the model's equilibrium and change CLM_ACCELERATED_SPINUP=on, CLM_FORCE_COLDSTART=on.
The query I have is to carry on such an experiment do I require to Spin-up the model for over 600 years? Would it be sufficient to recycle 30 times form 1960 to 1979 for spinup in I2000Clm50FatesGs, then is it reasonable to use the 600-year spunup file as initial file to simulate GPP for 1980-2010(I2000)?

(2) Then create a common case (I2000Clm50Fates) running from 1980 to 2010, and set the finidat in user_nl_clm as the output of spin-up case.
Is this the right approach for simulating GPP from 1980 to 2010? The CLM-FATES model doesnot have IHISTClm50Ftates--compset, and the CO2 is constant. I wonder to know whether I need to change the amount of co2 to simulate the history GPP?

(3) When I try to simulate the future GPP(SSP585) from 2020 to 2050 using CLM5-FATES to run compset I2000Clm50FatesGs and res f05_g16, I am not sure how to choose the surfacedata, domain data, and finiidat.
So at first, I want to build a case ISSP585Clm using compset ISSP585Clm50BgcCrop, The ISSP585 compset would give domain, surface, and finidar data containing transient landcover, CO2, aerosol and nitrogen deposition, year-specific atmospheric forcing, etc. Then I want to use the inputdata from compset ISSP585ClmBgcCrop to compset I2000Clm50FatesGs to simulate the future GPP(SSP585).

Is it reasonale for I to use the inputdata from ISSP585ClmBgcCrop to run compset I2000Clm50FatesGs using CLM5-FATES model?
If it works, what should I pay attention to? If it doesnot, What should I do to simulate the future GPP?

Any suggestions will be appreciated! Thanks in advance.

Quote Reply
Report

 

[oleson]

First of all, it's worth noting that "Please note also that the current paramétrisation of FATES is not considered scientifically supported for global runs, pending calibration...." as posted here:

Get CROP to function separately from natural vegetation mode · Issue #1046 · ESCOMP/CTSM

Currently the modes for crop and natural vegetation are tied together (SP, BGC, CN, BGC-CROP, FATES etc.). You can ONLY turn CROP on if use_cn is being turned on. So you can't use it with SP or FAT...

github.com

Second of all, if you are just starting out I'd recommend using the latest CTSM code to get all of the latest features, bug fixes, etc.

git clone GitHub - ESCOMP/CTSM: Community Terrestrial Systems Model (includes the Community Land Model of CESM)

That said I can try to answer some of your questions in the context of exploratory-type simulations that you may wish to do. I've also contacted some FATES experts who may be able to help further.
(1) Based on my recent experience (limited) in conducting FATES spinup simulations, I can say that GPP spins up to equilibrium fairly quickly (within 50 years) as does leaf area index. The carbon stocks take longer (e.g., total soil organic matter and total vegetation carbon), those seemed to be coming close to equilibrium in about 400 years in accelerated mode. I would think you could then use the restart file at the end of the accelerated mode spinup as an initial file to run 1980-2010.
(2) Right, there doesn't seem to be a FATES historical compset available out of the box. Perhaps the FATES people can comment on that.
(3) Choosing a compset and resolution will provide you with surface data, domain data, and finidat if that compset/resolution combination is supported. In particular, I'm not sure that all of the inputdata is available at that relatively high resolution (f05), you could try it, but I would recommend starting with the workhorse resolution (f09_g17).

Regarding (2) and (3), one way to approach these would be to try compset longnames.
For example, for (2), the compset alias doesn't exist, but maybe you could construct a FATES historical by using a compset longname, i.e.,

--compset HIST_DATM%GSWP3v1_CLM51%FATES_SICE_SOCN_SROF_SGLC_SWAV

A possible compset longname for the SSP585 would be:

--compset SSP585_DATM%GSWP3v1_CLM51%FATES_SICE_SOCN_SROF_SGLC_SWAV

You would need to modify that last compset to get atmospheric forcing appropriate for 2015-2100. We offer an anomaly forcing option for this. More information can be found by searching the Forum and some information is also provided here:

1.5.9. Running with anomaly forcing — ctsm release-clm5.0 documentation

Another thing to note is that I don't think the crop model is supported in combination with FATES.
If you haven't found this yet, there is quite a bit of documentation on FATES available here:

Home

repository for the Functionally Assembled Terrestrial Ecosystem Simulator (FATES) - NGEET/fates

github.com

Support is available through the FATES discussions board and the FATES google group.

 

[Chengyun]

First of all, it's worth noting that "Please note also that the current paramétrisation of FATES is not considered scientifically supported for global runs, pending calibration...." as posted here:

Get CROP to function separately from natural vegetation mode · Issue #1046 · ESCOMP/CTSM

Currently the modes for crop and natural vegetation are tied together (SP, BGC, CN, BGC-CROP, FATES etc.). You can ONLY turn CROP on if use_cn is being turned on. So you can't use it with SP or FAT...

github.com

Second of all, if you are just starting out I'd recommend using the latest CTSM code to get all of the latest features, bug fixes, etc.

git clone GitHub - ESCOMP/CTSM: Community Terrestrial Systems Model (includes the Community Land Model of CESM)

That said I can try to answer some of your questions in the context of exploratory-type simulations that you may wish to do. I've also contacted some FATES experts who may be able to help further.
(1) Based on my recent experience (limited) in conducting FATES spinup simulations, I can say that GPP spins up to equilibrium fairly quickly (within 50 years) as does leaf area index. The carbon stocks take longer (e.g., total soil organic matter and total vegetation carbon), those seemed to be coming close to equilibrium in about 400 years in accelerated mode. I would think you could then use the restart file at the end of the accelerated mode spinup as an initial file to run 1980-2010.
(2) Right, there doesn't seem to be a FATES historical compset available out of the box. Perhaps the FATES people can comment on that.
(3) Choosing a compset and resolution will provide you with surface data, domain data, and finidat if that compset/resolution combination is supported. In particular, I'm not sure that all of the inputdata is available at that relatively high resolution (f05), you could try it, but I would recommend starting with the workhorse resolution (f09_g17).

Regarding (2) and (3), one way to approach these would be to try compset longnames.
For example, for (2), the compset alias doesn't exist, but maybe you could construct a FATES historical by using a compset longname, i.e.,

--compset HIST_DATM%GSWP3v1_CLM51%FATES_SICE_SOCN_SROF_SGLC_SWAV

A possible compset longname for the SSP585 would be:

--compset SSP585_DATM%GSWP3v1_CLM51%FATES_SICE_SOCN_SROF_SGLC_SWAV

You would need to modify that last compset to get atmospheric forcing appropriate for 2015-2100. We offer an anomaly forcing option for this. More information can be found by searching the Forum and some information is also provided here:

1.5.9. Running with anomaly forcing — ctsm release-clm5.0 documentation

Another thing to note is that I don't think the crop model is supported in combination with FATES.
If you haven't found this yet, there is quite a bit of documentation on FATES available here:

Home

repository for the Functionally Assembled Terrestrial Ecosystem Simulator (FATES) - NGEET/fates

github.com

Support is available through the FATES discussions board and the FATES google group.

Dear Oleson,
Thanks for your help! I have been configuring the clm5.1 environment since last week by the latest CTSM code GitHub - ESCOMP/CTSM: Community Terrestrial Systems Model (includes the Community Land Model of CESM).
(1) But when i submit the case, it reports the fllowing
I have checked many times for the error, I donot find the answer, Do you know why? The followiing is the log..

(2) Then I use the clm5.0.35 code to running the compset that you may suggested HIST_DATM%GSWP3v1_CLM50%FATES_SICE_SOCN_SROF_SGLC_SWAV, but when I build the case, it reports the fllowing:

Need I change the dynamic PFT's or others?

(3) I can submit the 2000_DATM%GSWP3v1_CLM50%FATES_SICE_SOCN_SROF_SGLC_SWAV but I can not submit the 2000_DATM%GSWP3v1_CLM51%FATES_SICE_SOCN_SROF_SGLC_SWAV, I wonder to ask if there are many differences between them, I do not find the documents about clm5.1.

Best wishes for you.

 

[oleson]

(1) You should be able to find the error in the cesm log file that is identified by "See log file for details". You can also attach that log file here if you don't understand the error. I see you said "The following is the log..." but I don't see anything after that.
(2) That compset doesn't appear to be supported in clm5.0.35. I tried it using the development code, e.g., ctsm5.1.dev115, and it compiled. So you could try that.
(3) CLM51 is the latest development code, while CLM5 is the release code that has been fully tested, documented, and vetted from a software engineering and science viewpoint. CLM51 is functional and tested from a software engineering viewpoint, but not fully tested/understood/described scientifically. There are many differences between CLM51 and CLM50 and I don't know of a good short summary of those at this point. If you want to work with FATES and the configurations you've described then it looks like you will need to work with the development code, keeping in mind that it is not fully scientifically vetted.

 

[Chengyun]

(1) You should be able to find the error in the cesm log file that is identified by "See log file for details". You can also attach that log file here if you don't understand the error. I see you said "The following is the log..." but I don't see anything after that.
(2) That compset doesn't appear to be supported in clm5.0.35. I tried it using the development code, e.g., ctsm5.1.dev115, and it compiled. So you could try that.
(3) CLM51 is the latest development code, while CLM5 is the release code that has been fully tested, documented, and vetted from a software engineering and science viewpoint. CLM51 is functional and tested from a software engineering viewpoint, but not fully tested/understood/described scientifically. There are many differences between CLM51 and CLM50 and I don't know of a good short summary of those at this point. If you want to work with FATES and the configurations you've described then it looks like you will need to work with the development code, keeping in mind that it is not fully scientifically vetted.

Dear Oleson,

Thanks for your suggestions.

(1) Today I simulated global GPP (f09_g16) with Fates on my machine (12 nodes, 192 cpus), but I ran it and found that it took almost 30 minutes to simulate GPP for a day. I was very worried that if we spinup for hundreds of years or if we simulate GPP for decades, It takes a long, long time. Although I ultimately want to calculate the GPP of the region, this will take a long time.

(2) I used CLM4.0-CNDV to simulate GPP, but the time has not been greatly improved. I would like to ask whether all dynamic vegetation models take such a long time, and whether my machine cannot meet it. I'm panicking about my next step.

(3) I'm sorry, but do you have any dynamic vegetation models to recommend?

Best wishes for you.

 

[oleson]

(1) Right, FATES is generally slower than CLM without FATES. For global simulations at that spatial resolution we generally use 51 nodes (1836 cpus) on our HPC. Your options are to run at lower spatial resolution globally or run regionally.
(2) CLM4.0-CNDV is no longer supported so I wouldn't use that.
(3) DGVMs are not my area of expertise unfortunately, I don't have a recommendation sorry.

 

[Chengyun]

(1) Right, FATES is generally slower than CLM without FATES. For global simulations at that spatial resolution we generally use 51 nodes (1836 cpus) on our HPC. Your options are to run at lower spatial resolution globally or run regionally.
(2) CLM4.0-CNDV is no longer supported so I wouldn't use that.
(3) DGVMs are not my area of expertise unfortunately, I don't have a recommendation sorry.

Dear Oleson,
Sorry to bother you again. These days I am simulating the trend of GPP for China. But I meet some questions:

(1) For spinup, I recycle 70 times form 1960 to 1975 (total 1050years) [S1] and recycle 210 times form 1960 to 1965 (total 1050years) [S2] to simulate the trend of GPP from 1961 to 2015. But I found these two settings get different results.
The S1 shows a decreased trend of GPP and the S2 shows a increased trend of GPP in China.
Dear Oleson, could you tell me if there are some important details for the choosen of Spinup years, please?

Have a nice day!
Best wishes
Chengyun Wang

 

[oleson]

I don't see S1 or S2 attached here.
Regardless, you would have to provide more information for me to be able to help:

Information to include in help requests

When you are posting to the forums because you want help with an issue, please include as much of the following information as possible. Please read the following before submitting a help request: Check the CESM support policy, and particularly the list of currently-supported versions at the...

bb.cgd.ucar.edu