Nudging on a different number of levels

[thibaut_lurton@cnrs-orleans_fr]

Hello to all,
Using WACCM, does anyone know where the number of levels awaited in the nudging files is coded? Is there a way to modify it? (I'm not talking about the nlev 88 induced by WACCM, rather the number of levels in the met nudging files, which is inferior).I'm using the FSDWSF compset, and after having changed my nudging met data to some I compiled myself, my results were not coherent. I'm pretty sure of my met data, and all IC and configuration were the same in both runs, so my guess is that a different number of levels between GEOS (awaited by FSDWSF, 72 levels) and my files (60 levels) was the source of the problem (though it was not reported as an error).Can anyone confirm my guess, and possibly indicate how I could change the awaited number of nudging levels to 60? Thanks in advance,Thibaut.

 

[mmills]

SD-WACCM is set up so that the levels in the nudged region match the levels in the met fields. We support using  GEOS5 and MERRA, which share the same 72 vertical levels. So the lowest 72 of the 88 levels in SD-WACCM match the 72 levels used by GEOS5 and MERRA.If you want to nudge with different levels, you should change the levels in your WACCM initial condition file (ncdata) so that the levels in the nudged region match your 60 levels. There is a tool called interpic which can be used to interpolate initial condition files.

 

[thibaut_lurton@cnrs-orleans_fr]

Thank you for your quick answer.I have been interpolating my IC files.My run now fails with an error stating that "Lagrangian levels are crossing". I read that increasing NSPLTVRM (along with NSPLIT and NSPLTRAC) could fix that kind of error, although it did not work in my case (I tried increasing gradually from 2 to 2048).My guess is now that something might be wrong with my pressure coordinate system (hyam, hybm, hyai and hybi), though I did interpolate them as well to match the new vertical resolution.Do you know what kind of problem might cause the "crossed Lagrangian levels" error?Thanks,Thibaut.

 

[mmills]

Generally, increasing NSPLTVRM does solve this issue, which is not uncommon. However, if you have increased it all the way to 2048 without luck, it sounds like there is something pathological in your levels. I could see how that might happen due to interpolation of hyam, hybm, hyai and hybi. These coordinates vary in ways that are not linear with altitude, pressure, or level number. You might investigate the CAM documentation to see how this coordinate system is set up. I will try to see if can find someone who knows how to set up alternative vertical levels in the model.

 

[thibaut_lurton@cnrs-orleans_fr]

According to the atm.log file, the issue appears when trying to read the first met file. So maybe there is some kind of conflict between definition of levels in the IC and in the met data?Thank you very much Mike if you can find someone to sort out the problem.Thibaut.

 

[thibaut_lurton@cnrs-orleans_fr]

I'm progressing in my understanding of the issue: I came to identify that the "crossing Lagrangian levels" problem appears on the last ilev of my data (i.e. bottom ilev).

In te_map.F90, line 468, a comparison of two subsequent pe's is made that should not be below 1e-7 lest the error is declared. It appears that my configuration gives a negative number there (around minus several hundreds), which is logically spotted as inferior to the 1e-7 limit. This happens for the last ilev index only.

I vaguely understand that the pe's compared must be pressures at the edges of levels, though I double-checked my lev's and ilev's and they all do increase strictly, so I don't know where that negative difference could come from.

Any help would be greatly appreciated.

Thanks,

Thibaut.