using PORT (offline radiative transfer tool) on WACCM output

[gchiodo@fis_ucm_es]

Dear WACCM & CESM support team,I would like to use the PORT offline radiative transfer code to quantify radiative forcing in WACCM. More specifically, I would like to diagnose the instantaneous / adjusted forcing from ozone fields calculated by WACCM.The PORT documentation is found here:https://wiki.ucar.edu/display/port/PORT PORT is part of CESM1.2.2. However, the easiest way to use it seems to be by compiling and running CAM as a "standalone", turning on the "offline mode" in the configure script. I have been able to do so on the YELLOWSTONE machine (compile CAM, using the -offline_drv rad options indicated in the wiki website).Now, I need to build the correct namelist. For this purpose, I need to use the "correct" offline_driver_infile for the radiative calculations. If I am not mistaken, this file should contain all radiatively active species, including O3, coming e.g. from a previous WACCM integration. However, since PORT is part of CAM, I am not sure it can be fed with WACCM fields. Is that possible? Or are PORT and WACCM indeed incompatible, due to their different vertical resolutions?In case the latter applies, how could I perform the offline radiation calculations? Should I interpolate WACCM fields onto the CAM levels?Any help would be greatly appreciatedBest regards,Gabriel

 

[mmills]

I have run PORT within CESM(WACCM). There is no problem with vertical levels. You can include a list of files as text file pointed to by offline_driver_fileslist in the namelist.I have asked Andrew Conley to respond to this post if he can provide further clarification.

 

[mmills]

I have run PORT within CESM(WACCM). There is no problem with vertical levels. You can include a list of files as text file pointed to by offline_driver_fileslist in the namelist.I have asked Andrew Conley to respond to this post if he can provide further clarification.

 

[eaton]

WACCM is a configuration of CAM.  You do a WACCM run and output the data needed for PORT (via setting the namelist variable rad_data_output=.true.)  Then a subsequent run configured just like the original WACCM run, but with the addition of the argument "-offline_drv rad", will read the file produced by the original run. 

 

[eaton]

WACCM is a configuration of CAM.  You do a WACCM run and output the data needed for PORT (via setting the namelist variable rad_data_output=.true.)  Then a subsequent run configured just like the original WACCM run, but with the addition of the argument "-offline_drv rad", will read the file produced by the original run. 

 

[gchiodo@fis_ucm_es]

Hello,I have performed (1) a short WACCM run with the standard f1850 compset from the CESM1.2.0 package, with the rad_data_output variable set to true, and I have got the h1 history files with the radiation data needed for the offline calculations. Then, in order to run PORT, I configured another WACCM run using the same composet as in (1) as suggested by you, but adding -offline_drv rad in the CAM_CONFIG_OPTS field (env_build.xml file), along with some other few changes (rad_data_output = .true., and the offline_driver_fileslist pointing at a txt file containing the list of h1 outputs from (1). Unfortunately, it builds OK but it crashes while initializing the clm model with the following error (I am attaching all the relevant log files from the execution, and I am extracting a piece of the cesm log file to identify the problem):5: aerodynamic parameter error in UrbanFluxes
   5: h_u - z_d

 

[gchiodo@fis_ucm_es]

Hello,I have performed (1) a short WACCM run with the standard f1850 compset from the CESM1.2.0 package, with the rad_data_output variable set to true, and I have got the h1 history files with the radiation data needed for the offline calculations. Then, in order to run PORT, I configured another WACCM run using the same composet as in (1) as suggested by you, but adding -offline_drv rad in the CAM_CONFIG_OPTS field (env_build.xml file), along with some other few changes (rad_data_output = .true., and the offline_driver_fileslist pointing at a txt file containing the list of h1 outputs from (1). Unfortunately, it builds OK but it crashes while initializing the clm model with the following error (I am attaching all the relevant log files from the execution, and I am extracting a piece of the cesm log file to identify the problem):5: aerodynamic parameter error in UrbanFluxes
   5: h_u - z_d

 

[eaton]

When PORT is running the model should be configured to use stubs for all components except CAM, i.e., clm should not be running.  I see that my earlier post is misleading because I was referring to a cam standalone build which produces a correct configuration simply by giving configure the option that the offline radiation driver is to be used.  I don't know the best way to modify the CESM scripts to make this happen.  Since Mike said he had done this perhaps he can provide some hints here. 

 

[eaton]

When PORT is running the model should be configured to use stubs for all components except CAM, i.e., clm should not be running.  I see that my earlier post is misleading because I was referring to a cam standalone build which produces a correct configuration simply by giving configure the option that the offline radiation driver is to be used.  I don't know the best way to modify the CESM scripts to make this happen.  Since Mike said he had done this perhaps he can provide some hints here. 

 

[santos]

We now have a PORT compset in the CIME scripts, but we did not define one for the CESM 1.2.X releases. You can try simply copying all lines containing the word "PORT" from the XML file here:https://github.com/CESM-Development/cime/blob/57662f6a7718a0c1e43968caa05ac13eed2b0d0c/scripts/Tools/config_compsets.xmlThese lines should be added to scripts/ccsm_utils/Case.template/config_compsets.xml, and will add a compset called "PC4" to run PORT with the CAM4 radiation code. This compset will have a stub land model instead of CLM, so it should work.

 

[santos]

We now have a PORT compset in the CIME scripts, but we did not define one for the CESM 1.2.X releases. You can try simply copying all lines containing the word "PORT" from the XML file here:https://github.com/CESM-Development/cime/blob/57662f6a7718a0c1e43968caa05ac13eed2b0d0c/scripts/Tools/config_compsets.xmlThese lines should be added to scripts/ccsm_utils/Case.template/config_compsets.xml, and will add a compset called "PC4" to run PORT with the CAM4 radiation code. This compset will have a stub land model instead of CLM, so it should work.

 

[gchiodo@fis_ucm_es]

Thank you very much, Sean and Eaton. @eaton, correct. I was trying to run PORT using the standard CESM scripts, feeding it with WACCM data (not CAM4), just as Mike suggested. However, it's probably not working because of the fact that the F compset I am using invokes an "active" CLM, and this component should be stub, instead. Hence, I guess another workaround would be to configure WACCM as a standalone with the offline flag, pointing it to the output data from the "online" WACCM run. Is that correct? @sean, I see the new compsets have only been created for CAM4 and CAM5.  However, I need to drive PORT with WACCM4 data (e.g. by changing the ozone field on a WACCM grid). Are you going to add a P_2000_WACCM compset? Otherwise, should I somehow create the compset on my own (e.g., using your P_2000_CAM4 as a "guideline")?... or simply try to use WACCM as a "standalone"? If so, what are the steps to use WACCM as standalone within CESM1.2.2?
I could only find some guidance for running CAM4 as standalone, but not WACCM.
Thanks!

 

[gchiodo@fis_ucm_es]

Thank you very much, Sean and Eaton. @eaton, correct. I was trying to run PORT using the standard CESM scripts, feeding it with WACCM data (not CAM4), just as Mike suggested. However, it's probably not working because of the fact that the F compset I am using invokes an "active" CLM, and this component should be stub, instead. Hence, I guess another workaround would be to configure WACCM as a standalone with the offline flag, pointing it to the output data from the "online" WACCM run. Is that correct? @sean, I see the new compsets have only been created for CAM4 and CAM5.  However, I need to drive PORT with WACCM4 data (e.g. by changing the ozone field on a WACCM grid). Are you going to add a P_2000_WACCM compset? Otherwise, should I somehow create the compset on my own (e.g., using your P_2000_CAM4 as a "guideline")?... or simply try to use WACCM as a "standalone"? If so, what are the steps to use WACCM as standalone within CESM1.2.2?
I could only find some guidance for running CAM4 as standalone, but not WACCM.
Thanks!

 

[santos]

I believe that if you are using WACCM4 initial conditions, you can simply use the CAM4 compset and add "-nlev 66" to CAM_CONFIG_OPTS. Maybe Mike Mills has more insight, since he has run this code on WACCM data before. But I don't think that WACCM changes the settings for the radiation code used by PORT, so simply configuring the CAM4 compset for a different number of levels should be fine.The WAWG decided several years ago that it would not officially support "standalone" builds of WACCM, only builds using the CESM scripts. It should be possible to produce a standalone build, since we do so for testing purposes, but I never do so for actual science runs, and I have trouble thinking of anyone else who still does.

 

[santos]

I believe that if you are using WACCM4 initial conditions, you can simply use the CAM4 compset and add "-nlev 66" to CAM_CONFIG_OPTS. Maybe Mike Mills has more insight, since he has run this code on WACCM data before. But I don't think that WACCM changes the settings for the radiation code used by PORT, so simply configuring the CAM4 compset for a different number of levels should be fine.The WAWG decided several years ago that it would not officially support "standalone" builds of WACCM, only builds using the CESM scripts. It should be possible to produce a standalone build, since we do so for testing purposes, but I never do so for actual science runs, and I have trouble thinking of anyone else who still does.

 

[eaton]

I'll just add that it is not difficult to run waccm from a standalone script.  The cesm scripts rely on a small number of CAM configure options for build configurations, and on the use case files to get correct runtime settings.  The same can easily be done using a standalone script.  Nonetheless, I recommend doing it the way the waccm folks want to do it since they're the ones who support running WACCM. 

 

[eaton]

I'll just add that it is not difficult to run waccm from a standalone script.  The cesm scripts rely on a small number of CAM configure options for build configurations, and on the use case files to get correct runtime settings.  The same can easily be done using a standalone script.  Nonetheless, I recommend doing it the way the waccm folks want to do it since they're the ones who support running WACCM. 

 

[santos]

Francis Vitt tells me that when PORT is used with WACCM, it disables the WACCM-specific chemical heating code anyway (mostly active in the M/LT region), so there should not be any WACCM-specific physics or chemistry code that you need to turn on. However, WACCM also has a transition region where both CAMRT and the M/LT radiation code are active (a weighted average of the two is used). So if you just use the CAM compset with extended levels, you'll get an overestimation of the tendency due to CAMRT above about 19 mb.You can prevent this by triggering a WACCM build (the simplest way is to add config option "-chem waccm_mozart"), and then the effect of CAMRT will be correct, but you will still not get the M/LT chemical heating as in a normal WACCM run, since PORT doesn't seem to support this.

 

[santos]

Francis Vitt tells me that when PORT is used with WACCM, it disables the WACCM-specific chemical heating code anyway (mostly active in the M/LT region), so there should not be any WACCM-specific physics or chemistry code that you need to turn on. However, WACCM also has a transition region where both CAMRT and the M/LT radiation code are active (a weighted average of the two is used). So if you just use the CAM compset with extended levels, you'll get an overestimation of the tendency due to CAMRT above about 19 mb.You can prevent this by triggering a WACCM build (the simplest way is to add config option "-chem waccm_mozart"), and then the effect of CAMRT will be correct, but you will still not get the M/LT chemical heating as in a normal WACCM run, since PORT doesn't seem to support this.

 

[gchiodo@fis_ucm_es]

Thanks for your help,I followed the few steps (copy-paste PORT config lines in the scripts/ccsm_utils/Case.template/config_compsets.xml) for cesm1_2_0, then run create_newcase with the PC4 compset. Unfortunately, cesm_setup fails with the following error:Creating Macros file for yellowstone
/glade/u/home/gchiodo/code/cesm1_2_0/scripts/ccsm_utils/Machines/config_compilers.xml intel yellowstone
Creating batch script f2000.wcm.port.baseline.001.run
Locking file env_mach_pes.xml
Creating user_nl_xxx files for components and cpl
Running preview_namelist script
 infile is /glade/p/work/gchiodo/cases/port/f2000.wcm.port.baseline.001/Buildconf/cplconf/cesm_namelist
CAM build-namelist - ERROR: No default value found for ncdata
user defined attributes:
key=ic_md  val=00010101
Died at /glade/u/home/gchiodo/code/cesm1_2_0/models/atm/cam/bld/build-namelist line 3379.
ERROR: cam.buildnml.csh failed
ERROR: /glade/p/work/gchiodo/cases/port/f2000.wcm.port.baseline.001/preview_namelists failed: 25344Is there some intermediate step I am missing to get PORT running using the CESM120 scripts and the PC4 compset?Thanks!