FAQ: Data ocean slab mode (DOCN-SOM)

[dbailey]

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]

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?

 

[dbailey]

This should be fine. Look under the Buildconf/docnconf directory too.

 

[cpatrizio]

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]

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]

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]

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]

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]

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]

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]

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]

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!

 

[dbailey]

That is exactly right. The SST in the sea ice output is the prognostic field sent from the SOM.

 

[cpatrizio]

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]

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]

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]

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.

 

[cpatrizio]

Hello there,

I would like to produce my own q-flux forcing file based on observations. I tried using the following link to do so (as indicated in the FAQ), but it requires a login/password:

https://svn-ccsm-release.cgd.ucar.edu/model_versions/cesm1_1_1/models/ocn/docn/tools/pop_som_frc/

Are these tools no longer publicly available?

 

[dbailey]

You need to register for the subversion server here:

CESM | User Registration

www.cesm.ucar.edu

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]

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?.