SCM with 127 vertical levels #305
-
Hello, am I right that the CCPP SCM can support n_levels = 127? If so, can we simply change this parameter in *.nml to 127 using the top branch of ccpp-scm? Anything else is needed, e.g., do we need to add anything in scm/src/scm_vgrid.F90? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
This should be sufficient, although I've been needing to check for changes in fv_eta.F90 in FV3 (upon which most of scm_vgrid.F90/get_FV3_grid is based). Right now, the relevant lines for using n_levels = 127 in get_FV3_grid should be: Again, this was taken straight from FV3, but it was awhile ago, and I'm not sure that they're still doing it this way for 127 levels. I'll check. |
Beta Was this translation helpful? Give feedback.
-
@bluefinweiwei @mzhangw Could one of you give me the hard-coded ak/bk values that you were using for 127 levels (either copy/paste here or via email)? I'd like to check to see if the algorithm being called in the SCM for 127 levels is producing the same coefficients. |
Beta Was this translation helpful? Give feedback.
-
Grant,
I did this nearly a year ago, so definitely check on a newer file..... but
I used a GFS input file that a colleague produced. I just did an "ncdump
-h" on the file and the a_k and b_k values were shown at the end as global
attributes. I simply copied those and added them to my scm_vgrid.F90
code. The file I used to get the values is here:
/scratch2/BMC/ome/egrell/hurr_supp/ATOMIC/SCM/UFS_IC_generator/input/
gfs.t00z.atmanl.nc
I did this because when I tried using the default code to compute the
vertical grid for 127 levels, the vertical distribution of the data was not
the same in the SCM input and the t=0 SCM output. After adding the ak,bk
data, the soundings looked the same.
…On Mon, Mar 7, 2022 at 4:51 PM Grant Firl ***@***.***> wrote:
Thanks. @egrell <https://github.com/egrell> Where did these coefficients
for 127 levels come from? I'm working on updating the SCM code to use
changes in fv_eta.F90 in the latest FV3 code, and I can't reproduce these
exact numbers when specifying 127 levels, regardless of the value of
"npz_type".
—
Reply to this email directly, view it on GitHub
<#305 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMPXGN3BJYDKKBJ5CFOTQDU62I57ANCNFSM5PSJ66UQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
This should be sufficient, although I've been needing to check for changes in fv_eta.F90 in FV3 (upon which most of scm_vgrid.F90/get_FV3_grid is based). Right now, the relevant lines for using n_levels = 127 in get_FV3_grid should be:
ptop = 1.
pint = 75.E2
call var_gfs(km, scm_state%a_k, scm_state%b_k, ptop, ks, pint, 1.028)
Again, this was taken straight from FV3, but it was awhile ago, and I'm not sure that they're still doing it this way for 127 levels. I'll check.