Validating SCAM-SE

[adamrher]

This thread deals with issues related to the new SCAM-SE ESCOMP/CAM#958

[adamrher]

@jtruesdal @PeterHjortLauritzen @JulioTBacmeister @swrneale

[adamrher]

I did some runs looking at the gateIII iop in John's PR branch (136_scamse).

There's two issues and I can't rule out user error for either at this point. (1) The OMEGA output in the L58dev run is not plotting (more likely this is user error), and (2) that the SCAM-SE runs tend to be 'elongated' in time compared to the EUL runs (I'm more confident this is real). SE and EUL have different ATM_NCPL's, but that shouldn't change the calendar timing of the IOP forcing data, as seems to be occurring here.

ncl script here /glade/work/aherring/CESM2/EDMF/scam/curtain_tend.ncl

[jtruesdal]

It is a bug, and in the interpolation routine as you surmised. I've uploaded a fix to the branch. The IOP forcing was not being updated correctly for the case where the forcing is on a shorter timescale than the model time step. Just a clarification there is no IOP interpolation to the current model time step, it just picks the closest IOP time before the current model time. If the IOP forcing is days apart SCAM will just hold the forcing constant until the model time is greater than or equal to the next IOP time step.

[adamrher]

Thank you for looking into this and resolving it. I realize now this is not related to the new dycore, but rather a long standing bug when the time-step is longer than the iop dt, as u note (the iop dt is 1200 s and I was comparing dtime=900 s to dtime=1800 s). We actually realized this bug in a email thread last year. Ill probably dig it up just to let others on the thread know you've fixed. it.

Thanks again!

[jtruesdal]

Thanks for forwarding the thread, new plots and the followup emails. Hopefully the T and Q tendencies now also show good agreement between EUL and SE. I'll look into the OMEGA issue next.

[adamrher]

Updated the gateIII plot to include the tendencies. There are some differences but I would've expected differences due to the different vertical advection algorithm. And there would also be differences in the solution just from the changing physics time-steps.

To provide some broader context to the OMEGA issue, this cropped up in my pursuit to try to make the FSCAM compset default to CAM7. And I did want to ask you whether this PR would be the the best place to do this.

For the actual issue of problematic OMEGA output, note that particular run came after a considerable amount of mucking around in the config_comp* files, the FSCAM entries, and I could very well have broken the thing. The run is here, but I will try to recreate it more cleanly when I have time.

/glade/derecho/scratch/aherring/cam6_3_136_scamse_FSCAM7_gateIII_ne3_ne3_mg37_L58_1pes_240110_coldstart_test.001

[adamrher]

@jtruesdal sorry it took all week to re-test this OMEGA thing. Turns out it was me. I can plot OMEGA from the cam.h0 files just fine in the L58 runs. I hope you didn't spend much time working on this.

[swrneale]

@jtruesdal @PeterHjortLauritzen @JulioTBacmeister @adamrher just as an aside here has anyone got the togaII IOP working with a recent tag (#cam6_3_139) on derecho, even with the ice code mod? I can get gateIII to work, but not togaII.

[jtruesdal]

From the logs (PET0.ESMF_LogFile and ice.log) it looks like the cice clock is out of sync with the start time for togaII. I have no idea why these IOPs start in the middle of the day. I was able to get it to run starting at 0z on the next day. start_ymd = 19921219 and start_tod=0. You'll also have to shorten the amount of steps or hours that it runs by 6 hours. Those changes seem to work for me. I'm not sure what changed in cice that is not allowing it to sync up now. If it works for you I'll follow up with Dave and maybe Jim Edwards.