using PORT (offline radiative transfer tool) on WACCM output

[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!

 

[eaton]

The error is:CAM build-namelist - ERROR: No default value found for ncdata
user defined attributes:
key=ic_md  val=00010101I think that when running PORT the only role of the initial file (specified by the ncdata variable) is to provide grid information to the dycore.  So you should be able to set ncdata in the user_nl_cam file to any waccm initial file using the correct grid. 

 

[eaton]

The error is:CAM build-namelist - ERROR: No default value found for ncdata
user defined attributes:
key=ic_md  val=00010101I think that when running PORT the only role of the initial file (specified by the ncdata variable) is to provide grid information to the dycore.  So you should be able to set ncdata in the user_nl_cam file to any waccm initial file using the correct grid. 

 

[gchiodo@fis_ucm_es]

Ok, thank you all.So,I was getting errors due to the fact that the PC4 compset is invoking the 2000_CAM4 namelist file (with CAM-only BCs), but then by using the -chem waccm_mozart flag in the CAM_CONFIG_OPTS, I was forcing a WACCM build in order to get the correct CAMRT effect above 19mb, as suggested by Sean. In this way, the cesm_setup command was creating an incomplete WACCM namelist. Then, WACCM kept crashing in the initialization process because WACCM-specific BCs were missing in the atm_in namelist, and because of some incosistencies between CAM and WACCM namelists (for example, a co2vmr value is set for CAM, but WACCM uses CO2 from the flbc files, so I just set co2vmr value to 0.00001 so that the flbc input "overrides" the externally set co2 value).Following the F2000_WACCM standard namelist as a guide, I then added the missing WACCM specific options in the user_nl_cam file, such as solar inputs, sulphate aerosols, and the ncfile... and that was it. PORT is now running!However, I still do not quite understand why WACCM specific fields are required in the initialization process, such as sulphate aerosols and surface emissions, if it is an offline calculation using O3 and other fields from my baseline case (so no chemistry, only CAMRT radiation with 66 levels). Are these BCs only "read in" for the initialization, but are then ignored in the actual calculations...? If they are, then the only way to get PORT running is to "mimic" a free-running WACCM configuration in the namelists, right?The only problem now is that my baseline case from which the radiatively active fields are taken as input for the PORT calculation is a 1850 WACCM control run. Therefore, the baseline case and the PORT calculation (configured for 2000_CAM4+WACCM4 compset) are not consistent. However, if BCs and WACCM-specific fields are only required in the initialization but are then ignored by PORT, then as long as my offline_driver_fileslist points to the "right place", I should be fine, right?Let me know,thanks! 

 

[gchiodo@fis_ucm_es]

Ok, thank you all.So,I was getting errors due to the fact that the PC4 compset is invoking the 2000_CAM4 namelist file (with CAM-only BCs), but then by using the -chem waccm_mozart flag in the CAM_CONFIG_OPTS, I was forcing a WACCM build in order to get the correct CAMRT effect above 19mb, as suggested by Sean. In this way, the cesm_setup command was creating an incomplete WACCM namelist. Then, WACCM kept crashing in the initialization process because WACCM-specific BCs were missing in the atm_in namelist, and because of some incosistencies between CAM and WACCM namelists (for example, a co2vmr value is set for CAM, but WACCM uses CO2 from the flbc files, so I just set co2vmr value to 0.00001 so that the flbc input "overrides" the externally set co2 value).Following the F2000_WACCM standard namelist as a guide, I then added the missing WACCM specific options in the user_nl_cam file, such as solar inputs, sulphate aerosols, and the ncfile... and that was it. PORT is now running!However, I still do not quite understand why WACCM specific fields are required in the initialization process, such as sulphate aerosols and surface emissions, if it is an offline calculation using O3 and other fields from my baseline case (so no chemistry, only CAMRT radiation with 66 levels). Are these BCs only "read in" for the initialization, but are then ignored in the actual calculations...? If they are, then the only way to get PORT running is to "mimic" a free-running WACCM configuration in the namelists, right?The only problem now is that my baseline case from which the radiatively active fields are taken as input for the PORT calculation is a 1850 WACCM control run. Therefore, the baseline case and the PORT calculation (configured for 2000_CAM4+WACCM4 compset) are not consistent. However, if BCs and WACCM-specific fields are only required in the initialization but are then ignored by PORT, then as long as my offline_driver_fileslist points to the "right place", I should be fine, right?Let me know,thanks! 

 

[eaton]

I think most if not all your initialization problems would be solved simply by specifying a use case that was designed for a waccm run, e.g., waccm_1850_cam4.In the future we will be improving CAM's initialization procedure to allow parameterizations that are not used in a particular configuration to not be initialized.  At the current time the entire initialization is run even though only the dycore, radiation, and some infrastruce code is needed for PORT.The offline driving dataset produced by setting rad_data_output=.true. contains all the inputs needed by the radiation code.  No additional boundary data is used.  Of course you should check that the heating rates computed in the original run are identical to those computed in the offline run before making any changes to the input data for the purpose of evaluting forcings.

 

[eaton]

I think most if not all your initialization problems would be solved simply by specifying a use case that was designed for a waccm run, e.g., waccm_1850_cam4.In the future we will be improving CAM's initialization procedure to allow parameterizations that are not used in a particular configuration to not be initialized.  At the current time the entire initialization is run even though only the dycore, radiation, and some infrastruce code is needed for PORT.The offline driving dataset produced by setting rad_data_output=.true. contains all the inputs needed by the radiation code.  No additional boundary data is used.  Of course you should check that the heating rates computed in the original run are identical to those computed in the offline run before making any changes to the input data for the purpose of evaluting forcings.

 

[gchiodo@fis_ucm_es]

Ok. So I created a P_1850_WACCM compset using the following configuration 1850_CAM4%WCCM%PORT_SLND_SICE_SOCN_SROF_SGLC_SWAV...and it seems to work. I only had to add the offline_driver_fileslist to the user defined namelist and that was it. Now it runs OK without having to change any BCs or ICs. I will now run 10 years and then I will compare the radiative fluxes from the free-running (F1850) and PORT (P1850) simulations at the tropopause, as well as heating-rates. They should be almost identical.Then, if they are indeed identical, I can run a perturbed WACCM case (F1850pert), and use the rad_O3 field from that run to drive a PORT experiment (P1850pert) using all inputs from the unperturbed (F1850) run except for rad_O3 (which comes from F1850pert). So, by comparing P1850 and P1850pert at the tropopause I can quantify the radiative forcing from the O3 change. Is the procedure correct?Thank you!

 

[gchiodo@fis_ucm_es]

Ok. So I created a P_1850_WACCM compset using the following configuration 1850_CAM4%WCCM%PORT_SLND_SICE_SOCN_SROF_SGLC_SWAV...and it seems to work. I only had to add the offline_driver_fileslist to the user defined namelist and that was it. Now it runs OK without having to change any BCs or ICs. I will now run 10 years and then I will compare the radiative fluxes from the free-running (F1850) and PORT (P1850) simulations at the tropopause, as well as heating-rates. They should be almost identical.Then, if they are indeed identical, I can run a perturbed WACCM case (F1850pert), and use the rad_O3 field from that run to drive a PORT experiment (P1850pert) using all inputs from the unperturbed (F1850) run except for rad_O3 (which comes from F1850pert). So, by comparing P1850 and P1850pert at the tropopause I can quantify the radiative forcing from the O3 change. Is the procedure correct?Thank you!

 

[gchiodo@fis_ucm_es]

Hi again,I did the validation step with a 4 years long integration and found that radiative fluxes in the free-running and PORT experiment are exactly identical (on a global + annual mean). I know they should be very close, but is it possible that they are identical...?I also noticed that mean RESTOM (net SW - net LW at top of the model) is 0.73 W/m2 using a f1850 case in both the free-running and PORT calculation. This indicates that the model is not in radiative equilibrium, which should not be the case, as the model system is tuned to be in equilibrium in preindustrial BCs...Is this behavior normal, or may that indicate some problem in CESM-WACCM, when the PORT settings are used in a pi-industrial control case? Let me know, thanks

 

[gchiodo@fis_ucm_es]

Hi again,I did the validation step with a 4 years long integration and found that radiative fluxes in the free-running and PORT experiment are exactly identical (on a global + annual mean). I know they should be very close, but is it possible that they are identical...?I also noticed that mean RESTOM (net SW - net LW at top of the model) is 0.73 W/m2 using a f1850 case in both the free-running and PORT calculation. This indicates that the model is not in radiative equilibrium, which should not be the case, as the model system is tuned to be in equilibrium in preindustrial BCs...Is this behavior normal, or may that indicate some problem in CESM-WACCM, when the PORT settings are used in a pi-industrial control case? Let me know, thanks

 

[santos]

> I know they should be very close, but is it possible that they are identical...?I am not surprised. As I understand it, PORT is taking the same inputs, bit-for-bit, and running them through a radiation code compiled in the same way as in regular WACCM. Unless you change the way that the radiation is configured, I think that the results should be the same. Even if I'm wrong and there are minor changes, they could easily be roundoff-level, too small to affect the global+annual mean at all due to floating-point rounding error.I can't really tell you about the the RESTOM of this particular case. It's not going to be exactly 0, but you're right that 0.73 W/m^2 seems too high. I wonder if the problem is that the WACCM settings are chosen for a spun-up coupled ocean, and maybe that doesn't work as well for the SST file you are using. (Also, what is RESSURF?)

 

[santos]

> I know they should be very close, but is it possible that they are identical...?I am not surprised. As I understand it, PORT is taking the same inputs, bit-for-bit, and running them through a radiation code compiled in the same way as in regular WACCM. Unless you change the way that the radiation is configured, I think that the results should be the same. Even if I'm wrong and there are minor changes, they could easily be roundoff-level, too small to affect the global+annual mean at all due to floating-point rounding error.I can't really tell you about the the RESTOM of this particular case. It's not going to be exactly 0, but you're right that 0.73 W/m^2 seems too high. I wonder if the problem is that the WACCM settings are chosen for a spun-up coupled ocean, and maybe that doesn't work as well for the SST file you are using. (Also, what is RESSURF?)

 

[gchiodo@fis_ucm_es]

Hi Sean,RESSURF is also positive  ~ 1.2 W/m2 (meaning heat is going into the ocean, which is an infinite reservoir in docn mode). As you suggest, this might indicate a problem with the SST file that is used by default in the F1850 case (sst_HadOIBl_bc_1.9x2.5_clim_pi_c101028.nc).Therefore, I guess a closer balance will be obtained in the coupled compset B1850W (i.e., WACCM is presumably tuned to be in equilibrium in that compset), right?Thank you!

 

[gchiodo@fis_ucm_es]

Hi Sean,RESSURF is also positive  ~ 1.2 W/m2 (meaning heat is going into the ocean, which is an infinite reservoir in docn mode). As you suggest, this might indicate a problem with the SST file that is used by default in the F1850 case (sst_HadOIBl_bc_1.9x2.5_clim_pi_c101028.nc).Therefore, I guess a closer balance will be obtained in the coupled compset B1850W (i.e., WACCM is presumably tuned to be in equilibrium in that compset), right?Thank you!

 

[santos]

That would be my guess, yes. Mike Mills would know better than I do, though.

 

[santos]

That would be my guess, yes. Mike Mills would know better than I do, though.