Welcome to the new DiscussCESM forum!
We are still working on the website migration, so you may experience downtime during this process.

Existing users, please reset your password before logging in here: https://xenforo.cgd.ucar.edu/cesm/index.php?lost-password/

FAQ: Data ocean slab mode (DOCN-SOM)

dbailey

CSEG and Liaisons
Staff member
The procedure has changed a bit, but it still works in a similar way:

Here you will need to modify the docn.streams.txt.som file to manually point to the directory you wish. As of CESM 1.1, you can copy $CASEROOT/CaseDocs/docn.streams.txt.som to $CASEROOT/user_docn.streams.txt.som and edit it.

Note the addition of the .som suffix. Type ./preview_namelist and it should pick up your change.
 

cpatrizio

Casey Patrizio
New Member
Thanks!

After following the instructions above, the directory has now updated in $CASEROOT/CaseDocs/docn.streams.txt.som, however the input directories have disappeared from $CASEROOT/Buildconf/docn.input_data_list (except for the domainfile directory).

Is that expected behavior?
 

cpatrizio

Casey Patrizio
New Member
Thanks, the above instructions worked.

I'm now trying to solve a different issue:

I would like to perform some experiments with a modified q-flux forcing file (where I have added some variability in the q-flux over the year). I am working with the the following q-flux file: pop_frc.b.e11.B1850LENS.f09_g16.pi_control.002.20190923.nc, which runs without error.

However when I run the model with a modified version of the above file, I encounter the following error when the CICE model is being initialized:

Warning: Departure points out of bounds in remap
my_task, i, j = 0 9 7
dpx, dpy = 5.072942220258205E+028 -7.018545912672618E+030
HTN(i,j), HTN(i+1,j) = 29661.2715820699 29661.2715820699
HTE(i,j), HTE(i,j+1) = 59395.4550164216 59395.4550164216
istep1, my_task, iblk = 1664403 0 1
Global block: 1
Global i and j: 8 6
remap transport: bad departure points
ERROR: remap transport: bad departure points

I've read elsewhere that this error is typically suggestive of a CFL violation, however, the error is occurring at initialization and makes me wonder if it is an error in my forcing file. But I'm not exactly sure. Does anyone know what this error might suggest?

I can provide more information about the modifications I am adding to the forcing file if needed. In one experiment, I added very small variations (a maximum magnitude of 4 W/m2), so I was surprised to see that the model was unable to run. I should also mention that the format of the file is (from what I can tell) identical to the format of pop_frc.b.e11.B1850LENS.f09_g16.pi_control.002.20190923.nc.
 

dbailey

CSEG and Liaisons
Staff member
Yes, this is pretty much a CFL violation. What are the ocean currents in your SOM forcing file? There might be a units issue, i.e. cm/s instead of m/s.
 

cpatrizio

Casey Patrizio
New Member
The currents are identical to those provided in pop_frc.b.e11.B1850LENS.f09_g16.pi_control.002.20190923.nc, which runs without error.

I've only changed qdp in the new file. Could this cause the error?
 

dbailey

CSEG and Liaisons
Staff member
I suppose it is possible, if you changed qdp by a lot. Try changing ndtd to 2 to reduce the dynamic timestep and see if this gets you through.
 

cpatrizio

Casey Patrizio
New Member
Yes, I've tried changing ndtd to 2 in the CICE model and still the same error.

One strange thing is that if I double qdp in the original forcing file or even add spatially uniform 100 W/m^2, it runs just fine.

In my modification, I have only added a small forcing (much smaller than 100 W/m^2) that varies in space and from one month to the next (essentially the non-seasonal variability from single year of a pre-industrial run).
 

dbailey

CSEG and Liaisons
Staff member
Try doing an ncdiff on the original SOM forcing file and your modified one. Then use ncview to look at the differences. Make sure it is only qdp and then check the min/max values. Do you have missing values?
 

cpatrizio

Casey Patrizio
New Member
Great suggestions -- at first glance it looks like there may be some missing values in the modified forcing file that are not present in the original file. I think I may need to set those values to zero so that the model can handle them. I'll try that and report back... thanks for your help!
 

cpatrizio

Casey Patrizio
New Member
Looks like that was the issue after all! I replaced all of the 'unmasked' missing values with zero (according to the mask specified in the original forcing file). I should have thought of this earlier! Thanks again for the help.
 

cpatrizio

Casey Patrizio
New Member
Forgive me for another (potentially silly) question...

Is the SST in the CICE hist output equivalent to the mixed-layer temperature of the SOM? In other words, is the SST the temperature that is forced by the prescribed q-fluxes in the SOM?

Thanks!
 

cpatrizio

Casey Patrizio
New Member
Hello! It's me again (with yet another question).

I would like to run some SOM experiments with historical forcing. I am wondering if I can just specify HIST compset along with DOCN%SOM and run normally, or would the SOM first require spin-up with, say, pre-industrial forcing? I guess I am a bit confused about how the historical runs are normally initialized.

Thanks in advance!
 

dbailey

CSEG and Liaisons
Staff member
I would not recommend running a historical simulation with a SOM. Generally, we only do this with climates that will be equilibrated within 30-60 years. A transient climate is by definition not equilibrated. You can do a present day control where the CO2 is set at year 2000 levels for example. For our fully-coupled historical runs, we run a fully-coupled pre-industrial simulation for at least 1000 years. Then we sample the different "1850" states from the 1000 years to initialize different 20th century integrations from year 1850.
 

ppolonik

ppolonik
New Member
Hello,

This FAQ is really helpful. Sorry if my question is naive, but I'm looking for some help getting started with SOM.
I would like to run CESM2 with CAM6 and SOM on a regular (non-aqua) planet, but there do not seem to be any tested compsets that meet that requirement. ETEST looks like what I want, but it is only "defined" and is clearly labeled TEST. Is this compset currently recommended? Similarly, are there upcoming releases or potential pitfalls that I should be aware of before I start using ETEST?

Thanks!
 

dbailey

CSEG and Liaisons
Staff member
I defined ETEST as a part of our software engineering test suite, but it was not intended for science. There are two compsets that are fully-active except the DOCN-SOM in CESM2:

ETEST : 2000_CAM60_CLM50%SP_CICE_DOCN%SOM_MOSART_SGLC_SWAV_TEST
E1850L45TEST : 1850_CAM60_CLM45%SP_CICE_DOCN%SOM_MOSART_SGLC_SWAV_TEST

So, you can use the long name here without the "TEST" extension. Then as the FAQ states you need to set DOCN_SOM_FILENAME.
 

dbailey

CSEG and Liaisons
Staff member
You need to register for the subversion server here:


However, as we say in the FAQ we do not recommend creating Q-flux forcing from observations any longer. There is no information under the sea ice.
 

cpatrizio

Casey Patrizio
New Member
I have another quick question about the Q-flux forcing files found at:

/glade/p/cesmdata/cseg/inputdata/ocn/docn7/SOM//

I am comparing the mixed-layer depth from a fully-coupled run (the HMXL_DR variable) to the mixed-layer depth that is specified in the Q-flux forcing file. It appears that the mixed-layer depth specified in the Q-flux files (at least all of the files I have checked) is systematically more shallow than that in the fully-coupled run (see plots below for an example using pop_frc.b.e11.B1850LENS.f09_g16.pi_control.002.20190923.nc and fully-coupled data from CMIP6). Is there a reason for this? Or is HMXL_DR not the correct variable to be comparing to?Screen Shot 2020-10-15 at 12.33.36 PM.png.
 
Top