Need documentation for how to modify/use compset longnames for future CAM5 and CAM6 use.

[nusbaume]

Running CAM (either using the cam_development or cam_cesm2_1_rel branch) with an F1850 compset at f09_f09 resolution with the -phys cam5 configure option fails with the following error:

 open_trc_datafile: cycle year not found :         1850
 ERROR:
 open_trc_datafile: cycle year not found /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/trop_mozart_aero/emis/aerocom_mam3_dms_surf_2000_c120315.nc

I know CAM5 is in a "weird" state at the moment when it comes to support, but I am getting forum questions about it, so it would be nice to either figure out a fix for this issue, or officially decide that CAM5 is no longer supported in the current versions of CAM. Either option is fine with me. Thanks!

[cacraigucar]

@cecilehannay Reported back via email: He is trying to run the year 1850 but he is using a 2000 dataset.

[nusbaume]

@cecilehannay @cacraigucar Just FYI, this error occurs if the only change is adding -phys cam5 to CAM_CONFIG_OPTS when using the F1850 compset. One does not need to do any direct modifications to the input datasets or namelist to cause this failure.

Hope that helps clarify the issue!

[cecilehannay]

We could try to set the dataset for F1850 similar to the B1850 dataset. Does the B1850 work for cam5? In theory, F1850 is not a supported compset and I haven't run it in years.

What is the purpose here? Do we have people who need to run F1850 that or is it because some tests are failing.

[nusbaume]

Just adding some additional info to this issue after the discussion in the AMP SE projects meeting:

1. Apparently one can create an F1850 compset without needing the --run-unsupported flag. I know @cecilehannay mentioned in the AMP SE meeting that this compset isn't really supported, so should we think about making it "officially" unsupported and require the run-unsupported flag?

2. I tried a B1850 compset out-of-the-box with the CESM2.1.3 release code, with the only difference being the addition of -phys cam5 to CAM_CONFIG_OPTS. This run also crashed due to a mismatch in the number of vertical levels between the model and the ncdata file. Sadly I am not sure if the other input files were configured correctly as well, but I can try and find out if need be.

[brianpm]

Another CAM5 issue which is probably a cousin to this issue is that setting -phys cam5 with SCAM cases currently fails; @Isaaciwd noticed this and brought it to my attention. The model builds, but fails at runtime with an error saying lev does not match. This can be circumvented by bumping the vertical grid by also including -nlev 32 in CAM_CONFIG_OPTS (and it looks like changing other boundary condition files). For most applications of SCAM, that should be fine, but it isn't the expected behavior. I think it boils down to an issue with the default files being for CAM6 instead of CAM5, which seems related to what is going on with the F1850 compset too. (maybe?)

[adamrher]

Relatedly, I'm getting an error running F2000climo with the -phys cam5 config flag.

 trcdata_init: data type: CYCLICAL file: tracer_cnst_CAM6chem_2000climo_3D_month
 ly_c171004.nc
 (GETFIL): attempting to find local file
 tracer_cnst_CAM6chem_2000climo_3D_monthly_c171004.nc
 (GETFIL): using
 /glade/p/cesmdata/cseg/inputdata/atm/cam/ozone/tracer_cnst_CAM6chem_2000climo_3
 D_monthly_c171004.nc
 open_trc_datafile:
 /glade/p/cesmdata/cseg/inputdata/atm/cam/ozone/tracer_cnst_CAM6chem_2000climo_3
 D_monthly_c171004.nc
 trcdata_init: file%has_ps =  T
 There are no offline tracer sources

 airpl_src: NO and CO do not have external source --> no aircraft sources will b
 e applied
 chemini: after airpl_src on node            0
 srf_emis_inti: spc_name bc_a4            is not included in the simulation
 ERROR: srf_emis_inti: invalid surface emission specification

[WillyChap]

Echoing @adamrher 's comment from above. We are running into the same issue with the F2000climo compset and -phys cam5 . Error message is identical (see below). Has there been any update/work around?

 ly_c171004.nc
 (GETFIL): attempting to find local file
 tracer_cnst_CAM6chem_2000climo_3D_monthly_c171004.nc
 (GETFIL): using
 /glade/p/cesmdata/cseg/inputdata/atm/cam/ozone/tracer_cnst_CAM6chem_2000climo_3
 D_monthly_c171004.nc
 open_trc_datafile:
 /glade/p/cesmdata/cseg/inputdata/atm/cam/ozone/tracer_cnst_CAM6chem_2000climo_3
 D_monthly_c171004.nc
 trcdata_init: file%has_ps =  T
 There are no offline tracer sources

 airpl_src: NO and CO do not have external source --> no aircraft sources will b
 e applied
 chemini: after airpl_src on node            0
 srf_emis_inti: spc_name bc_a4            is not included in the simulation
 ERROR: srf_emis_inti: invalid surface emission specification```

[adamrher]

I was able to get -phys cam5 to run with F2000climo, using the cesm2.1.3 branch. The problem is that it is setting aerosol species emissions files in srf_emis_specifier for species that are not on the dynamics tracers list. After removing the problematic entries (bc_a4, num_a4, pom_a4), the model completes a 9 time-step run.

My user_nl_cam:

srf_emis_specifier             = 'DMS ->    /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_DMS_bb_surface_2000climo_0.9x1.25_c20170322.nc',
         'DMS ->    /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_DMS_other_surface_2000climo_0.9x1.25_c20170322.nc',
         'num_a1 -> /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_num_so4_a1_bb_surface_2000climo_0.9x1.25_c20170322.nc',
         'num_a1 -> /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_num_so4_a1_anthro-ag-ship_surface_2000climo_0.9x1.25_c20170616.nc',
         'num_a2 -> /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_num_so4_a2_anthro-res_surface_2000climo_0.9x1.25_c20170616.nc',
         'SO2 ->    /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_SO2_anthro-ag-ship-res_surface_2000climo_0.9x1.25_c20170616.nc',
         'SO2 ->    /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_SO2_anthro-ene_surface_2000climo_0.9x1.25_c20170616.nc',
         'SO2 ->    /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_SO2_bb_surface_2000climo_0.9x1.25_c20170322.nc',
         'so4_a1 -> /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_so4_a1_anthro-ag-ship_surface_2000climo_0.9x1.25_c20170616.nc',
         'so4_a1 -> /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_so4_a1_bb_surface_2000climo_0.9x1.25_c20170322.nc',
         'so4_a2 -> /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_so4_a2_anthro-res_surface_2000climo_0.9x1.25_c20170616.nc',
         'SOAG ->   /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_SOAGx1.5_anthro_surface_2000climo_0.9x1.25_c20170608.nc',
         'SOAG ->   /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_SOAGx1.5_bb_surface_2000climo_0.9x1.25_c20170322.nc',
         'SOAG ->   /glade/p/cesmdata/cseg/inputdata/atm/cam/chem/emis/CMIP6_emissions_2000climo/emissions-cmip6_SOAGx1.5_biogenic_surface_2000climo_0.9x1.25_c20170322.nc'

[update. I verified using the above namelists gets F2000climo to run in cam6_3_097. The namelists worked for f09 and ne30pg3. The namelist defaults for F2000climo point to the same f09 emissions files regardless of dycore, which is how I understood the emissions files to work ... (I'm aware Simone et al have started adding emissions on the se's native grids for some configurations).

My approach of excluding certain species from emissions is just a work around. It's not clear to me if this is the correct way to "fix" cam5, as it's open to interpretation what -phys cam5 should look like on cam_development. But I do suspect that the actual problem is that cam5 and cam6 got their wires crossed at some point in cime_config/config_components.xml, suggesting that my hack is just that, a hack.]

[adamrher]

@swrneale @brianpm @JulioTBacmeister I ran this hacked cam5 for 6 years and the diagnostics are here. Does this look cam5-like? The clouds are pretty thick across the Tropics.

[swrneale]

@adamrher What's the control run you have here CAM5 or CAM6?

[adamrher]

The control is L58 cam_dev. Perhaps comparing cam5 to L32 cam6 is more meaningful, but I don't have a L32 cam6 control.

[swrneale]

Agreed. Otherwise you're left pondering whether the change is vres based, cam6-based or even cam5-L32, vs cam5-L30? So many possibilities!

[adamrher]

This is L30 cam5. I'm just trying to verify it looks like cam5 as it's been broken since at least cesm2.1. Even if I had a proper L32 cam6 control, the amwg diagnostics may not be the best way to get at that.

[swrneale]

Oh right. L32 in the name threw me.

[brian-eaton]

This issue has meandered since Jesse's original post. I'll respond to his post first, regarding running F1850 with cam5. There is a mistake which is common to all these posts and it's the idea that you can change the physics to cam5 simply by using xmlchange to change CAM_CONFIG_OPTS from -phys cam6 to -phys cam5. Setting CAM_CONFIG_OPTS is only part of what the compset name is specifying. Another critical part is the setting of CAM_NML_USE_CASE which sets the use case file that enables the build-namelist utility to customize namelists for particular use cases. Currently F1850 is going to set CAM_NML_USE_CASE to 1850_cam6 which means that a lot of boundary datasets meant for cam6 (and trop_mam4) will end up in the namelist. So, if one uses xmlchange to change the value of CAM_CONFIG_OPTS, then a corresponding xmlchange command is needed to set the correct value of CAM_NML_USE_CASE. Alternatively, one can specify CAM50 as the cam component in the compset definition. For example, the cesm2.1.3 code defines F1850 to be

1850_CAM60_CLM50%SP_CICE%PRES_DOCN%DOM_MOSART_CISM2%NOEVOLVE_SWAV

If instead of using xmlchange one uses the compset name

1850_CAM50_CLM50%SP_CICE%PRES_DOCN%DOM_MOSART_CISM2%NOEVOLVE_SWAV

with create_newcase, then CAM_CONFIG_OPTS and CAM_NML_USE_CASE are set to the values -phys cam5 and 1850_cam5 respectively. Now things would work out of the box except for the small problem that the 1850_cam5.xml use case file was removed from cesm2.1.3. I imagine that was done since changes to the other components will probably prevent F1850 with cam5 from producing the 1850 climate. Nonetheless, I recovered the 1850_cam5.xml file from cesm1_2_2 which is the last public release using cam5, and put this file in the user source mods directory where build-namelist can find it. This configuration runs successfully (I only ran 9 timesteps). Interestingly, the DMS emissions dataset specified in 1850_cam5.xml is aerocom_mam3_dms_surf_2000_c090129.nc even though all the other emission datasets do have '1850' in their names.

In the current cam_development branch (I tested with cam6_3_107) F1850 is defined to be

1850_CAM60_CLM50%SP_CICE%PRES_DOCN%DOM_MOSART_SGLC_SWAV

If instead of using F1850 the compset name

1850_CAM50_CLM50%SP_CICE%PRES_DOCN%DOM_MOSART_SGLC_SWAV

is supplied to create_newcase then again CAM_CONFIG_OPTS and CAM_NML_USE_CASE are set correctly, and since 1850_cam5.xml is missing from the source code adding the cesm1_2_2 version of the file to user source mods is necessary. I ran this configuration successfully for 9 steps.

If we want to allow (not support) an F1850/cam5 configuration to run out of the box the easy fix is to add a new compset definition, perhaps with the alias F1850C5, and return the 1850_cam5.xml file to the source.

Moving on Adam's adventure with F2000climo, the first issue, again, is that setting -phys cam5 is not sufficient since the use case file will be set to 2000_cam6.xml. This will provide lots of boundary datasets meant for trop_mam4 as Adam discovered, and I agree with his guess that just eliminating emissions files for species in mode4 is probably not a correct solution. This case is more complicated than the 1850 case because cam5 was never set up to run with a 2000 climatology, only 1850 and historical. So there is no old 2000_cam5.xml file to use, and no emissions datasets for the trop_mam3 constituents and 2000 climatology. Moving forward with this configuration is more than a software engineering exercise.

Finally a note on running FSCAM with cam5. FSCAM is defined as

2000_CAM60%SCAM_CLM50%SP_CICE%PRES_DOCN%DOM_SROF_SGLC_SWAV

Just using xmlchange to set -phys cam5 is not sufficient. The 2000_CAM60 part of this definition sets the use case file to 2000_cam6.xml. This in turn adds boundary datasets that are appropriate for a 32 level model. Brian's workaround to add -nlev 32 to the configure options gets around the problem of boundary datasets with the wrong number of levels, but doesn't really give a cam5 configuration which was tuned to be a 30 level model. In this case if we specify the following compset to create_newcase,

2000_CAM50%SCAM_CLM50%SP_CICE%PRES_DOCN%DOM_SROF_SGLC_SWAV

then what happens is there is no use case specified (i.e. CAM_NML_USE_CASE will be set to '') because there's no match in the config_components.xml file for 2000_CAM50 in the code that sets CAM_NML_USE_CASE. That results in the namelist settings coming from the namelist defaults file, and hence appropriate 30 level files are chosen. Whether or not these are the best files to use needs to be examined. But I was able to successfully run this case using cesm2.1.3.

[adamrher]

This case is more complicated than the 1850 case because cam5 was never set up to run with a 2000 climatology, only 1850 and historical. So there is no old 2000_cam5.xml file to use, and no emissions datasets for the trop_mam3 constituents and 2000 climatology. Moving forward with this configuration is more than a software engineering exercise.

Oh. @swrneale curious on your thoughts on how to move forward with CAM5 functionality. This comment from Brian is interesting. I don't think we need to invent datasets that make F2000climo work with CAM5, but rather if you run with CAM5, you can only run 1850 and HIST. And Brian is stating (I think) that the correct way to run CAM5 is to modify the long name compset; you can't just set -phys cam5 since the compset definition will still be pointing to trop_mam4 / cam6 emissions.

Now things would work out of the box except for the small problem that the 1850_cam5.xml use case file was removed from cesm2.1.3. I imagine that was done since changes to the other components will probably prevent F1850 with cam5 from producing the 1850 climate. Nonetheless, I recovered the 1850_cam5.xml file from cesm1_2_2 which is the last public release using cam5, and put this file in the user source mods directory where build-namelist can find it.

OK thanks @brian-eaton! I think we're all fine with not reproducing the official CAM5 climate; we just want to retain the functional ability to run CAM5 physics. Do we need to also dig up the xml file to run CAM5 in a historical compset?

[brian-eaton]

It turns out the use case file for HIST_CAM50_CLM50%SP_CICE%PRES_DOCN%DOM_MOSART_SGLC_SWAV (which is FHIST with CAM60 replaced by CAM50) is present in the current code base. The file is bld/namelist_files/use_cases/1850-2005_cam5.xml. So just providing the correct compset long name is sufficient to run FHIST with cam5. To make it easier to run this case out of the box we could provide an alias to the longname above, e.g. FHISTC5. Note that the use case filename indicates that the boundary datasets are only valid to year 2005, not to present day.

[adamrher]

As we are starting to think about how to integrate the new compsets (FLT/FMT) into CESM3, and what this means for the existing compsets (F2000climo,FHIST), I had proposed renaming these existing ones to make clear they are only for cam6. But then I spoke with @jtruesdal who provided more background on those compsets. He relays to me that they were intended to be general enough that they aren't tied to any particular version of cam physics. He thought that just specifying the config option -phys is all you should need to do to run an older physics version, with the logic in config_components able to key the right set of config options from the -phys config option. I think we've more recently gotten away from that (e.g., QPC6,QPC5,QPC4), and that we should probably have a discussion to decide whether we should be introducing these more narrowly focused compsets going forward, or if it is easier for us to support, and for the user to run, these more generic compsets. I'd like to eventually have a meeting that includes @jtruesdal, @brian-eaton, @PeterHjortLauritzen, @cacraigucar @nusbaume and myself to sort this out. Does that seem reasonable?

[cacraigucar]

Adding @cecilehannay to the list as she and I collaborated a lot last time around on compset names.

Yes, our intention last time was that we would come up with names that would move ahead with future releases. The problem is that with this release we will be releasing two FHIST for example - the LT and MT versions. These generic names no longer work as we need two versions. The QPC4, QPC5 and QPC6 intentionally fell outside the generic names that we adopted. These names were all determined at the last CESM release.

[cacraigucar]

Adding @brianpm also as he was the one who proposed the QP compset names

[adamrher]

The problem is that with this release we will be releasing two FHIST for example - the LT and MT versions.

To expand this out a bit more; we used to have 3 different model tops (CAM, WACCM and WACCM-X). So now with MT, we have 4. This suggests we should replace FHIST with FLTHIST, entirely. F2000climo should maybe be named FLT2000climo (I think the "climo" part is too much nuance at the short-name compset level, IMO), as it implicitly referred to the low top version, since MT didn't exists before. If someone tries to run FMTHIST with -phys cam5, it should tell the user there is no such thing.

The reason I posted this convo to this thread, is b/c it's this thread where we realized that running F2000climo or FHIST, and setting -phys cam5, doesn't work. And so we've lost the generality of these compsets as they were originally intended.

[brianpm]

This boils down to asking "what is a compset?" The word "compset" would suggest that it specifies a unique set of component models, but in practice this is not how we have used it. The "2000", "1850", "hist", etc. all complicate the naming by blending forcing along with the components. The "W" has been used to distinguish WACCM, which comes with more than just a change in the vertical grid. An idealistic view would be that since we specify the horizontal resolution (and dycore) with the res argument, we should also specify the vertical grid as part of res. I'm not sure whether that is a practical solution, so falling back to the proposed "W", "L", and "M" specifiers would make sense. The actual differences that come with these vertical grid specifiers are in the default initial conditions and the use_case, right? The differences within the use_cases for these are tuning parameters that might differ between "L" and "M", but additional physics specifications for "W" (and "X"), right? So it seems like if we don't want to make larger changes to how we specify cases, the logic here is that a compset name indicates a vertical grid, tuning parameters, and possibly physics/chemistry options. If that's the correct, then I think our only option is to have compsets named as proposed. It looks like that would mean having "L", "M", "W" (and "X"?) versions of:

• F2000climo
• FHIST
• FHIST_BGC
• F2010climo
• F1850
• F1850_BDRD
• FHIST_BDRD
• FHIST_DARTC6

And then some decision needs to be made for how to deal with idealized configurations:

• FDABIP04
• FKESSLER
• FSCAM
• FHS94
• QPC6
• QSC6
• FADIAB
• FTJ16
• QPC4
• QPC5
• QSC4
• QSC5
• QPRCEMIP

And also what will we do with the SPCAM compsets (%SPCAMM, %SPCAMS, %SPCAMCLBS, %SPCAMCLBM).

And also what about the %PORT, %CCTS, %CVBSX, %CFIRE, %CCTS%SDYN, %SDYN configurations?

And I didn't look at the B compsets.

[gold2718]

This is a great discussion but I worry that other compset discussions are potentially being forgotten. Maybe take the compset name part of this issue conversation along with #475, #692, and #842 and move it to a discussion until things settle?

[brianpm]

Good point, @gold2718 !