Bad month index=36; help, you prawns!

Recall we are trying to get a sensitivity to 2xCO2; the public thinks of this as the primary use case.

Most of what was hanging me up for the past week was building a 6Mb one-time data file (containing climatological mixed layer depth, clamped at 200m; the magic number is somewhat arbitrary and hard-wired, but we suppose others have put thought into it.) It would have been nice if I could just download the file. It turned out I needed a c compiler compatible with the Fortran compiler that built netcdf. The magic word was "icc", specifically

setenv CC=icc

Once that was done, it turned out I had some other data file to dig up. I had trouble tracking down my ncar UID/password (as if this data needed to be kept under wraps for some reason). Then I found that the URL specified in the README was incorrect! Eventually tracked the file down with Google. Built (huzzah) the heat flux boundary condition. Thought I was done.

Today I tried to submit the job. Well, still a use case I;ve never run. I was hung up for some time on the error messsage "BNDDYI: Bad month index=36" which is not mentioned in CAM documentation but is mentioned in the CCM3.6 documentation! (an ancestor)

It seems the month number should be a number between 1 and 12 (reasonable). No idea where the number 36 came from. I look into my data file and see the following for dates:

time = 116.5, 215, 316.5, 416, 516.5, 616, 716.5, 816.5, 916, 1016.5, 1116, 1216.5 ;

There are twelve of them as needed, but...

Those are indeed months in a peculiar sense. Consider it a puzzle, and here is your clue:

double time(time) ;
time:units = "day as %m%d.%f" ;
time:axis = "T" ;

Go figure. No clue where the 36 comes from. Charles advises, though, that I should not specify a start and end date for a slab run. So I make no effort to surgically fix the month numbers and remove the start and end date, specifying a duration instead. (Because I specify in days rather than seconds, I use a negative number...)

The 36 BNDDYI message goes away! Apparently the error "month number is 36" really means "you can't specify dates on a slab run".

The model gets considerably further now. It starts to run the first time step and then proffers this droll message a few times

sublimate away all sea ice
something is probably seriously wrong
ice state at dh stop nstep = 0

amid some other unexpected output, and then aborts.

Three weeks and counting. We wanted a result by next Monday and this will take 48 hours to run. Groan.

Somebody else has come to this pass, describing it as "display the seriously error". Note the useful assistance provided by the community. There's also something in Chinese that Google translates as follows:

help you prawns, the slab ocean model CAM operations serious mistake!

-=-=-=-=-=> Turn CCM and CAM counterparts all know, by adding a simple ocean model (slab ocean model) running CAM, but regardless CAM3.0, or CAM3.1, there are the same mistakes can not continue to run, the Daxia Please help!

Any prawns out there have any advice for me?

Update: Running at last! The last hurdle was knowing that you have to replace the file

cami_0000-09-01_64x128_L26_c030918.nc

with the file

cami_0000-01-01_64x128_T42_L26_SOM_c030918.nc

Unlike the mixed layer depths, this is actually distributed in the initial conditions dataset. I am also using a topography file that differes from the standard one. Not sure why, this is based on lore and not knowledge. It's called

topo-from-cami_0000-01-01_64x128_T42_L26_SOM_c030918.nc

I don't know its provenance, but possibly the name is correct. If that's the case, though, it isn't clear why there are two different files at all. Some totally undocumented use case perhaps?

This is actually consistent with the message from "seriously message" guy. It is not documented as part of the procedure for the use case in the documents. There is a tiny clue in the redme for defineqflux:

Another executable available (but hopefully unnecessary) in the definesomic
module is (also) called definesomic. It adds necessary SOM fields to an
initial dataset if they are not already there.

If there are fields missing from the initial conditions, you'd think something better than "something is seriously wrong" and lots of numerical output would be possible.

Not sure how much further to investigate.