FAQ: Data ocean slab mode (DOCN-SOM)
- Thread starter dbailey
- Start date
I'm curious about this. I've been using the same forcing files in my simulations -- with some local modifications.
Do we know if pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc is the best option for a CESM2 preindustrial control slab ocean run?
A TOA imbalance of 0.15 Wm-2 does not seem negligible.
Michelle
This one is from a retuned sea ice albedo run (Kay et al. 2022). So, it might be off because you are using the out of the box sea ice tuning. I would recommend setting the following in user_nl_cice:
r_snw = 1.50
dt_mlt = 1.00
This might help with the TOA a bit. After how many years did you evaluate the TOA? Might have to run at least 30 years before it starts to come down.
r_snw = 1.50
dt_mlt = 1.00
This might help with the TOA a bit. After how many years did you evaluate the TOA? Might have to run at least 30 years before it starts to come down.
I am not sure how many years this is from -- I am quoting this from Will Kranz's earlier post.
Given that I've already run experimental simulations with this Qflx file without that sea ice change, I wonder if it's sufficient to run a new PI with this Qflx file but also without the sea ice parameter change, to correct for this bias? Or would you suggest re-running the experimental simulations with a different (CMIP6 PI) Qflx file?
I'm not sure we have another Qflx file that would suit your needs here. You are welcome to continue running the experiment you have to see if the TOA bias comes down more? I should note that we not consider a TOA imbalance of 0.2 or less to be "small enough".
Hi,
I am running CESM2.1.2 with slab ocean aquaplanet simulation (Qflx is zero) with the seasonal cycle. I am encountering an asymmetry in the north-south SOLIN with a value of 0.74w/m^2 increase in the southern hemisphere. This is very similar to this queries North ITCZ. I have used different compiler gcc/7.5m,gcc/9 and gcc/12 to compile the model all of them gives exactly same asymmetry. I also tried with cesm 2.1.0. Does anyone have a comment on this please let me know?
The changes I done are :
./create_newcase --case Testing_SOLIN_intel --compset QSC6 --res f19_f19_mg17 --compiler intel --mpilib impi
I introduced seasonality by including orbital parameters in user_nl_cpl:
orb_eccen = 0.
orb_obliq = 23.5
orb_mvelp = 0.
orb_mode = "fixed_parameters"
And commented these two lines in the following block in seq_infodata_mod.F90 file and put it into SourceMods/src.drv/:
if ( infodata%aqua_planet ) then
infodata%aqua_planet_sst = 1
!infodata%perpetual = .true.
!infodata%perpetual_ymd = aqua_perpetual_ymd
endif
For sanity check. I made the obliquity to -23.5 which make the asymmetry 0.74w/m^2 increase to northern hemisphere.
If anyone has encountered this issue, any suggestions or resolutions would be greatly appreciated.
I am running CESM2.1.2 with slab ocean aquaplanet simulation (Qflx is zero) with the seasonal cycle. I am encountering an asymmetry in the north-south SOLIN with a value of 0.74w/m^2 increase in the southern hemisphere. This is very similar to this queries North ITCZ. I have used different compiler gcc/7.5m,gcc/9 and gcc/12 to compile the model all of them gives exactly same asymmetry. I also tried with cesm 2.1.0. Does anyone have a comment on this please let me know?
The changes I done are :
./create_newcase --case Testing_SOLIN_intel --compset QSC6 --res f19_f19_mg17 --compiler intel --mpilib impi
I introduced seasonality by including orbital parameters in user_nl_cpl:
orb_eccen = 0.
orb_obliq = 23.5
orb_mvelp = 0.
orb_mode = "fixed_parameters"
And commented these two lines in the following block in seq_infodata_mod.F90 file and put it into SourceMods/src.drv/:
if ( infodata%aqua_planet ) then
infodata%aqua_planet_sst = 1
!infodata%perpetual = .true.
!infodata%perpetual_ymd = aqua_perpetual_ymd
endif
For sanity check. I made the obliquity to -23.5 which make the asymmetry 0.74w/m^2 increase to northern hemisphere.
If anyone has encountered this issue, any suggestions or resolutions would be greatly appreciated.
Hi David,
I noticed pretty significant differences in the Arctic heat flux convergence between this and another SOM-PI simulation that is more consistent with the surface heat fluxes from the CMIP6 PiControl simulation. Due to the snow cover tuning you mentioned previously.
I have gone ahead and re-run the simulations with this other qflx file.
Michelle
Hello all,
I want to run a F2000climo compset with SOM forcing (2000_CAM60_CLM50%SP_CICE_DOCN%SOM_MOSART_SGLC_SWAV) in CESM2.2.0 at f09_f09_mg17 resolution. I have gone through the FAQs regarding the setup and the issues with a present-day SOM forcing file, and just had a couple of questions.
1) Is it still recommended to use the 1850 forcing file to answer science questions? (using the present day F compsets?)
2) The pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc file should suffice for my case?
3) I also noticed the svn repo has this file pop_frc.b.e10.B2000CN.f09_g16.test_ice.011m.160513.nc which I'm assuming is based on a present day fully coupled run, but because it specifies "test" it would not really be appropriate to use scientifically? I'm curious about whether I can still run it with my setup, since this is f09_g16, I'm not sure if there will be some resolution mismatch?
I want to look at the effect of external forcing on monsoon seasonal/sub-seasonal variability, so I need some SST coupling/feedback but I'm not overly concerned about very realistic sea-ice extent etc. Any help regarding this would be appreciated thanks!
Best,
Sanya
I want to run a F2000climo compset with SOM forcing (2000_CAM60_CLM50%SP_CICE_DOCN%SOM_MOSART_SGLC_SWAV) in CESM2.2.0 at f09_f09_mg17 resolution. I have gone through the FAQs regarding the setup and the issues with a present-day SOM forcing file, and just had a couple of questions.
1) Is it still recommended to use the 1850 forcing file to answer science questions? (using the present day F compsets?)
2) The pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc file should suffice for my case?
3) I also noticed the svn repo has this file pop_frc.b.e10.B2000CN.f09_g16.test_ice.011m.160513.nc which I'm assuming is based on a present day fully coupled run, but because it specifies "test" it would not really be appropriate to use scientifically? I'm curious about whether I can still run it with my setup, since this is f09_g16, I'm not sure if there will be some resolution mismatch?
I want to look at the effect of external forcing on monsoon seasonal/sub-seasonal variability, so I need some SST coupling/feedback but I'm not overly concerned about very realistic sea-ice extent etc. Any help regarding this would be appreciated thanks!
Best,
Sanya
I think there is some confusion here. The SOM is not active in F compsets. You need an E compset if you want to run the SOM. You should really not use f09_f09 with an E compset. In terms of what forcing is appropriate, the compset string is what you should be closest to. So, b.e10.B2000CN.f09_g16 means a CESM1.0 configuration with a 2000 like forcing and the atmosphere is 1-degree resolution FV grid with the ice and ocean on the 1-degree Greenland pole grid.
Ah okay, it seems I've mixed up a few things, thanks for clarifying! For some reason I confused the E and F compset longnames.
I'm still a little confused about the forcing file - b.e10.B2000CN.f09_g16 would be the closest match and I just want to confirm it wont be an issue since its a CESM1.0 configuration and I want to run CESM2 (it also says test_ice so is it okay for science purposes)? Also, sorry if I'm missing something here, but in some of the previous discussion you said it's better to use the 1850 forcing file since that comes from a well equilibrated climate, so I'm wondering whether that's what I want to use?
I'm still a little confused about the forcing file - b.e10.B2000CN.f09_g16 would be the closest match and I just want to confirm it wont be an issue since its a CESM1.0 configuration and I want to run CESM2 (it also says test_ice so is it okay for science purposes)? Also, sorry if I'm missing something here, but in some of the previous discussion you said it's better to use the 1850 forcing file since that comes from a well equilibrated climate, so I'm wondering whether that's what I want to use?
It is definitely better to use a SOM forcing file from a B run that is closest to your E configuration. The main point is it needs to be a long fully-coupled control run that is reasonably equilibrated. The 2000 control run is probably equilibrated, but the TOA is likely non-zero and this sometimes causes issues in SOM runs. You don't want to use the test_ice configuration. This uses an interpolated 1x1d SOM forcing file for testing purposes only. So, i would leave that out and make sure you set DOCN_SOM_FILENAME correctly.
Hi all, I am running a 1850_CAM60_CLM50%SP_CICE_DOCN%SOM_MOSART_SGLC_SWAV compset but with f19_g17 resolution. I created my own slab ocean forcing file from a control run with compset 1850_CAM60_CLM50%BGC-CROP_CICE_POP2%ECO%ABIO-DIC_MOSART_CISM2%NOEVOLVE_WW3_BGC%BDRD with f19_g17 resolution. I have set DOCN_SOM_FILENAME to this forcing file but the simulation is failing with the error:
ERROR: component_mod:check_fields NaN found in OCN instance: 1 field So_t 1d global index: 733
This error is occurring at multiple grid cells, however these grid cells are all land points that I believe should be set to NaN anyway.
I experimented and tried using pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc as the forcing file which ran successfully. If I use this forcing file and sub in the q-flux variable from my forcing file it also runs fine. But if I sub in my temperature or salinity variable to this forcing file it leads to the same error. The error makes me think it is a mask issue, however, when I compare the temperature variable from the pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc file to the one from my forcing file the location of cells set to NaN are the exact same.
Has anyone encountered this issue before?
Thanks,
Lucy
ERROR: component_mod:check_fields NaN found in OCN instance: 1 field So_t 1d global index: 733
This error is occurring at multiple grid cells, however these grid cells are all land points that I believe should be set to NaN anyway.
I experimented and tried using pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc as the forcing file which ran successfully. If I use this forcing file and sub in the q-flux variable from my forcing file it also runs fine. But if I sub in my temperature or salinity variable to this forcing file it leads to the same error. The error makes me think it is a mask issue, however, when I compare the temperature variable from the pop_frc.b.e21.B1850.f09_g17.CMIP6-piControl.001_branch2.012120.nc file to the one from my forcing file the location of cells set to NaN are the exact same.
Has anyone encountered this issue before?
Thanks,
Lucy