How to run an ocean-only simulation for SSP585 (using BSSP585 forcing)?

[yujiezhang]

Hi everyone,


I would like to run an ocean + sea-ice only simulation under the SSP585 scenario. The default compset for this scenario seems to be BSSP585, but it activates all components.


My goal is:

• POP + CICE active
• ATM / LND / ROF as data components
• Forcing consistent with SSP585

Is there an existing compset for this? Or a recommended way to modify BSSP585 (e.g., switching to DATM while keeping SSP585 forcing)?


Any guidance would be appreciated. Thanks!

 

[mlevy]

Unfortunately there is not an existing compset for this -- there was discussion about including future scenarios in the Ocean Model Intercomparison Project, but creating atmospheric forcing datasets for those runs is difficult. Switching the BSSP585 to use DATM isn't sufficient, you need to generate datasets for DATM to pass to POP2 and CICE.

I asked a few people I thought might have experience with this, and one recommendation would be to follow the steps in Alexander et al (2020); they were running the ROMS ocean model, but I think discuss how to generate forcing files from a fully coupled simulation to use in the forced ocean sea-ice run. Note that there is no guarantee of scientifically valid results if you run CESM in this manner...

 

[yujiezhang]

Dear Michael,Thank you very much for your clear and detailed explanation, and for the helpful reference. I will carefully consider the steps you mentioned and continue exploring this approach.

 

[Coupe]

I have some notes that may be helpful in making sure your fully-coupled BSSP585 case will produce the required outputs to then force a G case (POP2 + CICE only).

Assuming that you can get a fully coupled BSSP585 case up and running, you need to add the following lines to user_nl_cpl to produce the coupler output necessary to force an offline simulation:

 histaux_a2x24hr = .true.
 histaux_a2x3hr = .true.
 histaux_a2x1hri= .true.
 histaux_a2x1hr = .true.
 histaux_r2x = .true.

In CESM2.1.3, this will produce files in /cpl/hist/ with the format
CASENAME.cpl.ha2x1d.YYYY-MM-DD.nc
CASENAME.cpl.ha2x3h.YYYY-MM-DD.nc
CASENAME.cpl.ha2x1h.YYYY-MM-DD.nc
CASENAME.cpl.ha2x1hi.YYYY-MM-DD.nc
CASENAME.cpl.hr2x.YYYY-MM-DD.nc

where the ha2x{1d,3h,1h,1hi} correspond to data which is read in by the coupler at different intervals (day, 3 hourly, 1 hourly avg, 1 hourly instantaneous). This data will force your G case and enables a recreation of the fully coupled simulation as long as the coupling intervals (OCN_NCPL) and ocean timestep (dt_count) are identical and the data isn't modified. I would recommend running a test case where no modifications are made to ensure the fully coupled and G case look the same. Check ATM_CO2, IRON_FLUX, photoC_TOT_zint, and SSTs to verify.

These files can be used to force the G case. Note there isn't really a G case compset for SSP585. I typically use an 1850 compset such as 1850_DATM%CPLHIST_SLND_CICE_POP2%ECO_DROF%CPLHIST_SGLC_SWAV and then replace the contents of user_nl_pop in the G case with some fields listed in CaseDocs/pop_in from your fully coupled BSSP585 case. If they are not already the same, everything in the block &ecosys_forcing_data_nml in CaseDocs/pop_in from BSSP585 should be added to your G case user_nl_pop file as it includes important nutrient forcing files that will correspond to the time period you want (fesedflux_input%filename, feventflux_input, riv_flux_shr_stream_file are notable nutrient inputs).

This will give the ocean model the necessary boundary conditions to repeat the fully coupled simulation. To point your G case to your CPLHIST files, you will need to modify a couple of env_run.xml variables to set up DATM and DROF to use your files. The below assumes the files run from 2020 to 2025:

./xmlchange DATM_MODE=CPLHIST
./xmlchange DATM_CPLHIST_DIR={directory to CPLHIST files}
./xmlchange DATM_CPLHIST_CASE={fully coupled case name}
./xmlchange DATM_CPLHIST_YR_START=2020
./xmlchange DATM_CPLHIST_YR_END=2025
./xmlchange DATM_CPLHIST_YR_ALIGN=2020

./xmlchange DROF_CPLHIST_DIR={same as DATM_CPLHIST_DIR}
./xmlchange DROF_CPLHIST_CASE= {same as DATM_CPLHIST_CASE}
./xmlchange DROF_CPLHIST_YR_START=2020
./xmlchange DROF_CPLHIST_YR_END=2025
./xmlchange DROF_CPLHIST_YR_ALIGN=2020

For the G case to use the CO2 fluxes that are written to the files in CASENAME.cpl.ha2x3h.YYYY-MM-DD.nc, these env_run.xml variables also need to be set:
./xmlchange CCSM_BGC=CO2A
./xmlchange OCN_CO2_TYPE=diagnostic

One last note is that I've often run into unpredictable issues when the G case tries to ingest the CPLHIST files which are automatically created as YYYY-MM-DD. The G case will also read in files that are YYYY-MM. A post-processing step that will help avoid issues is to concatenate all of the YYYY-MM-DD files into YYYY-MM using something like ncrcat. I have code that does this post-processing step and can clean it up and post it here if you run into this issue.

 

[yujiezhang]

I have some notes that may be helpful in making sure your fully-coupled BSSP585 case will produce the required outputs to then force a G case (POP2 + CICE only).

Assuming that you can get a fully coupled BSSP585 case up and running, you need to add the following lines to user_nl_cpl to produce the coupler output necessary to force an offline simulation:

 histaux_a2x24hr = .true.
 histaux_a2x3hr = .true.
 histaux_a2x1hri= .true.
 histaux_a2x1hr = .true.
 histaux_r2x = .true.

In CESM2.1.3, this will produce files in /cpl/hist/ with the format
CASENAME.cpl.ha2x1d.YYYY-MM-DD.nc
CASENAME.cpl.ha2x3h.YYYY-MM-DD.nc
CASENAME.cpl.ha2x1h.YYYY-MM-DD.nc
CASENAME.cpl.ha2x1hi.YYYY-MM-DD.nc
CASENAME.cpl.hr2x.YYYY-MM-DD.nc

where the ha2x{1d,3h,1h,1hi} correspond to data which is read in by the coupler at different intervals (day, 3 hourly, 1 hourly avg, 1 hourly instantaneous). This data will force your G case and enables a recreation of the fully coupled simulation as long as the coupling intervals (OCN_NCPL) and ocean timestep (dt_count) are identical and the data isn't modified. I would recommend running a test case where no modifications are made to ensure the fully coupled and G case look the same. Check ATM_CO2, IRON_FLUX, photoC_TOT_zint, and SSTs to verify.

These files can be used to force the G case. Note there isn't really a G case compset for SSP585. I typically use an 1850 compset such as 1850_DATM%CPLHIST_SLND_CICE_POP2%ECO_DROF%CPLHIST_SGLC_SWAV and then replace the contents of user_nl_pop in the G case with some fields listed in CaseDocs/pop_in from your fully coupled BSSP585 case. If they are not already the same, everything in the block &ecosys_forcing_data_nml in CaseDocs/pop_in from BSSP585 should be added to your G case user_nl_pop file as it includes important nutrient forcing files that will correspond to the time period you want (fesedflux_input%filename, feventflux_input, riv_flux_shr_stream_file are notable nutrient inputs).

This will give the ocean model the necessary boundary conditions to repeat the fully coupled simulation. To point your G case to your CPLHIST files, you will need to modify a couple of env_run.xml variables to set up DATM and DROF to use your files. The below assumes the files run from 2020 to 2025:

./xmlchange DATM_MODE=CPLHIST
./xmlchange DATM_CPLHIST_DIR={directory to CPLHIST files}
./xmlchange DATM_CPLHIST_CASE={fully coupled case name}
./xmlchange DATM_CPLHIST_YR_START=2020
./xmlchange DATM_CPLHIST_YR_END=2025
./xmlchange DATM_CPLHIST_YR_ALIGN=2020

./xmlchange DROF_CPLHIST_DIR={same as DATM_CPLHIST_DIR}
./xmlchange DROF_CPLHIST_CASE= {same as DATM_CPLHIST_CASE}
./xmlchange DROF_CPLHIST_YR_START=2020
./xmlchange DROF_CPLHIST_YR_END=2025
./xmlchange DROF_CPLHIST_YR_ALIGN=2020

For the G case to use the CO2 fluxes that are written to the files in CASENAME.cpl.ha2x3h.YYYY-MM-DD.nc, these env_run.xml variables also need to be set:
./xmlchange CCSM_BGC=CO2A
./xmlchange OCN_CO2_TYPE=diagnostic

One last note is that I've often run into unpredictable issues when the G case tries to ingest the CPLHIST files which are automatically created as YYYY-MM-DD. The G case will also read in files that are YYYY-MM. A post-processing step that will help avoid issues is to concatenate all of the YYYY-MM-DD files into YYYY-MM using something like ncrcat. I have code that does this post-processing step and can clean it up and post it here if you run into this issue.

Hi Joshua,


Thank you very much for the detailed and extremely helpful explanation — it clarified several key points for me.

I have now tested a G case using the compset
1850_DATM%CPLHIST_SLND_CICE_POP2%ECO_DROF%CPLHIST_SGLC_SWAV,
forced by CPL history output generated from a standard fully coupled BSSP585 run. For the initial conditions, I used the BSSP585 CMIP6 restart files for POP and CICE.

I ran a one-year simulation and compared the G case results with the corresponding fully coupled BSSP585 simulation. I do see small differences between the two, on the order of a few per mille, which I believe are acceptable and likely related to adjustment and coupling differences.

I plan to continue checking whether there are any remaining configuration details or forcing fields that I may have overlooked.

Thanks again for your guidance — it has been very helpful.


Best regards！

 

[yujiezhang]

Hi Joshua,


I realized that there was an issue in my previous reply, so I wanted to follow up with a clarification and a question.

After carefully re-checking the magnitude, I reran the experiment using CPLHIST forcing generated from a fully coupled SSP585 case, and set up a G case with

1850_DATM%CPLHIST_SLND_CICE_POP2%ECO_DROF%CPLHIST_SGLC_SWAV at f09_g17,
using the same restart files as the BSSP585 case (both initialized in 2020).

With this configuration, I first compared IRON_FLUX and surface dissolved Fe between the fully coupled SSP585 simulation and the G case forced by CPLHIST. I found that IRON_FLUX and the resulting Fe concentrations differ substantially (after converting Fe to nmol/L).

I am wondering whether this indicates a mistake in my setup, or whether this is an expected consequence of how iron deposition is reconstructed in a G case (e.g., driver-derived iron from dust/BC/OC versus the fully coupled CAM–CPL–POP pathway).

Any insight you might have on this would be greatly appreciated. Thanks again for your guidance — it has been extremely helpful.