cnrwil004@myuct_ac_za
New Member
Hi all
I'm not sure whether this is the correct forum to be posting this topic in; I have looked at the location of posts that seem similar and they appear in various different sections of the forum. Hence, I apologise if this an inappropriate place to posting this topic---please let me know if I need to move it.
Firstly, it is probably necessary to supply some background as context for the question. We are trying to run a number of ensembles of fully coupled (B compset) cases of CESM at f45_g37 resolution (very coarse, in an attempt to reduce computational cost). The proposed experiment involves running a 1300 year control run with fixed year 2000 forcing (using the B_2000 compset), and then using restart/initial files from different years of the spun-up state of this run as initial conditions for ensembles of hybrid runs with slightly different atmospheric initial conditions (ICs), obtained by varying the value of pertlim in the file user_nl_cam. Each of these ensembles is to be run both with fixed external forcing, as a control, and with RCP8.5 transient forcing.
Initial multi-centennial control run has been successfully completed. Additionally, two fixed forcing ensembles with 50 members each have been successfully run for 60 years. However, starting up the corresponding transient forcing runs has proved to be more challenging. The errors appear to result from there not being a provided default fpftdyn input file for CLM when running an RCP scenario. When running "cesm_setup" for a case created with "create_newcase -case ${CASENAME} -res f45_g37 -compset BRCP85CN -mach ${MACHNAME}" on a local (unsupported) machine (the same one on which the other cases where run successfully), the following appears in the output:
> "CLM adding use_case 1850-2100_rcp8.5_transient defaults for var use_case_desc with val Simulate transient land-use, aerosol and Nitrogen deposition changes with historical data from 1850 to 2005 and then with the RCP8.5 scenario from MESSAGE
CLM build-namelist ERROR: No default value found for fpftdyn.
Are defaults provided for this resolution and land mask?
ERROR: clm.buildnml.csh failed"
I looked the error up and found reference to what appears to be an almost identical error in the CLM userguide for CLM4 in CESM1.1.1 (chapter 6, pg. 137). In reference to this difficulty the authors comment:
>"In the example, the error is that the CLM XML database does NOT have a finidat for the given resolution, rcp scenario and ocean mask."
I found the comment confusing, as it makes reference to the input file "finitdat", rather than "fpftdyn", which is what the error appears to be referring to. Additionally the authors suggest:
"See Chapter 2 for more information on creating files, and see Chapter 3 for more information on adding files to the XML database."
Initially I tried to resolve the problem by, as the first comment above appears to suggest, investigating the use of the CLM tools to produce a "finitdat" file for "the given resolution, rcp scenario and ocean mask". However, it appears that such a file does in fact already exist in the namelist. I thus decided to try to use the "mkmapdata" ( mkmapdata.sh --res 4x5 --phys clm4_0 ) script instead, using grids produced with "mksurfdata_map" ( run with "mksurfdata.pl -res usrspec -usr_gname 4x5 -usr_gdate $DATE -dinlc $DIN_LOC_ROOT -exedir $PWD -mv -years 1850-2100 -rcp 8.5", because "mksurfdata.pl -res 4x5 ..." produced errors: "ERROR: mapping file for this resolution does NOT exist" ). The fsurdat and fpftdyn files produced thus, were then entered into the xml database as explained in the userguide. Subsequently the previously created test case ran successfully, provided that the case xml variable "CLM_FORCE_COLDSTART" is set to "on". If not, the following errors are obtained:
> "$DIN_LOC_ROOT/lnd/clm2/initdata/clmi.BCN.1949-01-01_4x5_gx3v7_simyr1850_c100322.nc 589824
check_dim ERROR: mismatch of input dimension 2168 with expected value 2291 for variable landunit
ENDRUN: called without a message string"
This appears to be the crux of the current problem, because it also implies that the program complains when restart files from the previously mentioned multi-centennial control run are used. Practically this problem can be resolved by using interpinic to interpolate the restart files to the, for some reason, slightly different resolution of the fpftdyn and fsurdat files produced as described above ( as suggested in numerous other posts, e.g. https://bb.cgd.ucar.edu/b40t31x3037-restart-files-dont-work, https://bb.cgd.ucar.edu/node/1001998 and https://bb.cgd.ucar.edu/node/1001422 ).
However, this would imply changing the initial conditions used by the land model, which will no longer allow for attribution of differences in the output of the constant forcing and RCP ensembles to the differences in forcing only. Additionally, it implies spread in these ensembles can no longer directly be attributed to the differences in atmospheric ICs applied to the output of the model run and direct comparison with the continuation of the control run will no longer be meaningful. While these are not catastrophic problems, they do limit the potential value of the investigation we are pursuing.
The previously noted forum entries suggest to me that these problems are unlikely to be resolvable. However, if anyone has any suggestions to make or comments on the matter, these would be greatly appreciated.
Thank you in advance
I'm not sure whether this is the correct forum to be posting this topic in; I have looked at the location of posts that seem similar and they appear in various different sections of the forum. Hence, I apologise if this an inappropriate place to posting this topic---please let me know if I need to move it.
Firstly, it is probably necessary to supply some background as context for the question. We are trying to run a number of ensembles of fully coupled (B compset) cases of CESM at f45_g37 resolution (very coarse, in an attempt to reduce computational cost). The proposed experiment involves running a 1300 year control run with fixed year 2000 forcing (using the B_2000 compset), and then using restart/initial files from different years of the spun-up state of this run as initial conditions for ensembles of hybrid runs with slightly different atmospheric initial conditions (ICs), obtained by varying the value of pertlim in the file user_nl_cam. Each of these ensembles is to be run both with fixed external forcing, as a control, and with RCP8.5 transient forcing.
Initial multi-centennial control run has been successfully completed. Additionally, two fixed forcing ensembles with 50 members each have been successfully run for 60 years. However, starting up the corresponding transient forcing runs has proved to be more challenging. The errors appear to result from there not being a provided default fpftdyn input file for CLM when running an RCP scenario. When running "cesm_setup" for a case created with "create_newcase -case ${CASENAME} -res f45_g37 -compset BRCP85CN -mach ${MACHNAME}" on a local (unsupported) machine (the same one on which the other cases where run successfully), the following appears in the output:
> "CLM adding use_case 1850-2100_rcp8.5_transient defaults for var use_case_desc with val Simulate transient land-use, aerosol and Nitrogen deposition changes with historical data from 1850 to 2005 and then with the RCP8.5 scenario from MESSAGE
CLM build-namelist ERROR: No default value found for fpftdyn.
Are defaults provided for this resolution and land mask?
ERROR: clm.buildnml.csh failed"
I looked the error up and found reference to what appears to be an almost identical error in the CLM userguide for CLM4 in CESM1.1.1 (chapter 6, pg. 137). In reference to this difficulty the authors comment:
>"In the example, the error is that the CLM XML database does NOT have a finidat for the given resolution, rcp scenario and ocean mask."
I found the comment confusing, as it makes reference to the input file "finitdat", rather than "fpftdyn", which is what the error appears to be referring to. Additionally the authors suggest:
"See Chapter 2 for more information on creating files, and see Chapter 3 for more information on adding files to the XML database."
Initially I tried to resolve the problem by, as the first comment above appears to suggest, investigating the use of the CLM tools to produce a "finitdat" file for "the given resolution, rcp scenario and ocean mask". However, it appears that such a file does in fact already exist in the namelist. I thus decided to try to use the "mkmapdata" ( mkmapdata.sh --res 4x5 --phys clm4_0 ) script instead, using grids produced with "mksurfdata_map" ( run with "mksurfdata.pl -res usrspec -usr_gname 4x5 -usr_gdate $DATE -dinlc $DIN_LOC_ROOT -exedir $PWD -mv -years 1850-2100 -rcp 8.5", because "mksurfdata.pl -res 4x5 ..." produced errors: "ERROR: mapping file for this resolution does NOT exist" ). The fsurdat and fpftdyn files produced thus, were then entered into the xml database as explained in the userguide. Subsequently the previously created test case ran successfully, provided that the case xml variable "CLM_FORCE_COLDSTART" is set to "on". If not, the following errors are obtained:
> "$DIN_LOC_ROOT/lnd/clm2/initdata/clmi.BCN.1949-01-01_4x5_gx3v7_simyr1850_c100322.nc 589824
check_dim ERROR: mismatch of input dimension 2168 with expected value 2291 for variable landunit
ENDRUN: called without a message string"
This appears to be the crux of the current problem, because it also implies that the program complains when restart files from the previously mentioned multi-centennial control run are used. Practically this problem can be resolved by using interpinic to interpolate the restart files to the, for some reason, slightly different resolution of the fpftdyn and fsurdat files produced as described above ( as suggested in numerous other posts, e.g. https://bb.cgd.ucar.edu/b40t31x3037-restart-files-dont-work, https://bb.cgd.ucar.edu/node/1001998 and https://bb.cgd.ucar.edu/node/1001422 ).
However, this would imply changing the initial conditions used by the land model, which will no longer allow for attribution of differences in the output of the constant forcing and RCP ensembles to the differences in forcing only. Additionally, it implies spread in these ensembles can no longer directly be attributed to the differences in atmospheric ICs applied to the output of the model run and direct comparison with the continuation of the control run will no longer be meaningful. While these are not catastrophic problems, they do limit the potential value of the investigation we are pursuing.
The previously noted forum entries suggest to me that these problems are unlikely to be resolvable. However, if anyone has any suggestions to make or comments on the matter, these would be greatly appreciated.
Thank you in advance