Another tracer index issue - in the pwat calculation #699

egrell · 2021-07-15T18:49:38Z

egrell
Jul 15, 2021

I think there is an issue with the calculation of pwat in GFS_MP_generic_post_run, which sums over tracer indices using
do ic = ntcw, ntcw+nncl-1
which translates to: do ic=2,6
for the GFSv16 suite.
The problem is that ozone is index 4 in the gq0 array (I think!), so it would be included in the pwat calculation. Also graupel is index 7, for the GFSv16 suite, so it would be omitted. This is not a high priority, as I think pwat is just a diagnostic variable, but it might be better to omit it than calculate it incorrectly.

climbfuji · 2021-07-15T18:52:22Z

climbfuji
Jul 15, 2021
Maintainer

Again, thanks, Evelyn. @SMoorthi-emc FYI

1 reply

SMoorthi-emc Jul 15, 2021
Collaborator

I am just now looking at my run and my output has
" ntoz : 12
ntcw : 2
ntiw : 3
ntrw : 4
ntsw : 5
ntgl : 6

SMoorthi-emc · 2021-07-15T18:57:37Z

SMoorthi-emc
Jul 15, 2021
Collaborator

Sorry, I was using MG3 in this run. But I think it should be the similar for GFDL MP.
The location of ozone is defined in the field_table, so it should not be mixed with cloud condensates.

0 replies

egrell · 2021-07-15T19:04:42Z

egrell
Jul 15, 2021
Author

That would be good if it were corrected. Perhaps my code is old. I was using the SCMv5, with GFSv16beta suite. My tracer indices are: ntqv : 1 ntoz : 4 ntcw : 2 ntiw : 3 ntrw : 5 ntsw : 6 ntgl : 7 ntclamt : 8 ntke : 9 And the tracer_config file has: "sphum","water_vapor_specific_humidity","kg kg-1" "liq_wat","cloud_condensed_water_mixing_ratio","kg kg-1" "ice_wat","ice_water_mixing_ratio","kg kg-1" "o3mr","ozone_mixing_ratio","kg kg-1" "rainwat","rain_water_mixing_ratio","kg kg-1" "snowwat","snow_water_mixing_ratio","kg kg-1" "graupel","graupel_mixing_ratio","kg kg-1" "cld_amt","cloud_fraction","frac" "sgs_tke","turbulent_kinetic_energy","m2 s-2"

…

On Thu, Jul 15, 2021 at 12:57 PM SMoorthi-emc ***@***.***> wrote: Sorry, I was using MG3 in this run. But I think it should be the similar for GFDL MP. The location of ozone is defined in the field_table, so it should not be mixed with cloud condensates. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMPXGKDSGOZU57UORLTBG3TX4VSZANCNFSM5AODXI2Q> .

0 replies

SMoorthi-emc · 2021-07-15T19:09:29Z

SMoorthi-emc
Jul 15, 2021
Collaborator

Ozone is supposed to after all condensate variables. As MG3 is a double moment scheme, the numbers are " ntrac : 13 nqrimef : -99 ntqv : 1 ntoz : 12 ntcw : 2 ntiw : 3 ntrw : 4 ntsw : 5 ntgl : 6 ntclamt : -99 ntlnc : 7 ntinc : 8 ntrnc : 9 ntsnc : 10 ntgnc : 11 ntke : 13 nto : 0 nto2 : 0 ntwa : -99 ntia : -99 ntchm : 0 ntchs : -99 ntche : -99 ndchm : 0 ndchs : -99 ndche : -99" So, ozone is after graupel number concentration ntgnc and before ntke.

…

On Thu, Jul 15, 2021 at 3:05 PM egrell ***@***.***> wrote: That would be good if it were corrected. Perhaps my code is old. I was using the SCMv5, with GFSv16beta suite. My tracer indices are: ntqv : 1 ntoz : 4 ntcw : 2 ntiw : 3 ntrw : 5 ntsw : 6 ntgl : 7 ntclamt : 8 ntke : 9 And the tracer_config file has: "sphum","water_vapor_specific_humidity","kg kg-1" "liq_wat","cloud_condensed_water_mixing_ratio","kg kg-1" "ice_wat","ice_water_mixing_ratio","kg kg-1" "o3mr","ozone_mixing_ratio","kg kg-1" "rainwat","rain_water_mixing_ratio","kg kg-1" "snowwat","snow_water_mixing_ratio","kg kg-1" "graupel","graupel_mixing_ratio","kg kg-1" "cld_amt","cloud_fraction","frac" "sgs_tke","turbulent_kinetic_energy","m2 s-2" On Thu, Jul 15, 2021 at 12:57 PM SMoorthi-emc ***@***.***> wrote: > Sorry, I was using MG3 in this run. But I think it should be the similar > for GFDL MP. > The location of ozone is defined in the field_table, so it should not be > mixed with cloud condensates. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #699 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADMPXGKDSGOZU57UORLTBG3TX4VSZANCNFSM5AODXI2Q > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYRKAIWAWZ4465SHZ73TX4WNJANCNFSM5AODXI2Q> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

0 replies

egrell · 2021-07-15T20:00:13Z

egrell
Jul 15, 2021
Author

I just checked some output from the SRWapp, for a run with GFSv16 physics, and there ntoz = 7. So perhaps this is just an SCM issue? Sorry if I caused any confusion. It certainly makes much more sense to have the index for ozone after all the hydrometeors. Indices from the SRWapp run are: ntqv : 1 ntoz : 7 ntcw : 2 ntiw : 4 ntrw : 3 ntsw : 5 ntgl : 6 ntclamt : 9 ntke : 8 On Thu, Jul 15, 2021 at 1:09 PM SMoorthi-emc ***@***.***> wrote:

…

Ozone is supposed to after all condensate variables. As MG3 is a double moment scheme, the numbers are " ntrac : 13 nqrimef : -99 ntqv : 1 ntoz : 12 ntcw : 2 ntiw : 3 ntrw : 4 ntsw : 5 ntgl : 6 ntclamt : -99 ntlnc : 7 ntinc : 8 ntrnc : 9 ntsnc : 10 ntgnc : 11 ntke : 13 nto : 0 nto2 : 0 ntwa : -99 ntia : -99 ntchm : 0 ntchs : -99 ntche : -99 ndchm : 0 ndchs : -99 ndche : -99" So, ozone is after graupel number concentration ntgnc and before ntke. On Thu, Jul 15, 2021 at 3:05 PM egrell ***@***.***> wrote: > That would be good if it were corrected. Perhaps my code is old. > I was using the SCMv5, with GFSv16beta suite. > My tracer indices are: > ntqv : 1 > ntoz : 4 > ntcw : 2 > ntiw : 3 > ntrw : 5 > ntsw : 6 > ntgl : 7 > ntclamt : 8 > ntke : 9 > And the tracer_config file has: > "sphum","water_vapor_specific_humidity","kg kg-1" > "liq_wat","cloud_condensed_water_mixing_ratio","kg kg-1" > "ice_wat","ice_water_mixing_ratio","kg kg-1" > "o3mr","ozone_mixing_ratio","kg kg-1" > "rainwat","rain_water_mixing_ratio","kg kg-1" > "snowwat","snow_water_mixing_ratio","kg kg-1" > "graupel","graupel_mixing_ratio","kg kg-1" > "cld_amt","cloud_fraction","frac" > "sgs_tke","turbulent_kinetic_energy","m2 s-2" > > On Thu, Jul 15, 2021 at 12:57 PM SMoorthi-emc ***@***.***> > wrote: > > > Sorry, I was using MG3 in this run. But I think it should be the similar > > for GFDL MP. > > The location of ozone is defined in the field_table, so it should not be > > mixed with cloud condensates. > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > < > #699 (comment) > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/ADMPXGKDSGOZU57UORLTBG3TX4VSZANCNFSM5AODXI2Q > > > > . > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #699 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ALLVRYRKAIWAWZ4465SHZ73TX4WNJANCNFSM5AODXI2Q > > . > -- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMPXGLZUS4CZ3OPBBXP6CDTX4W7LANCNFSM5AODXI2Q> .

4 replies

climbfuji Jul 15, 2021
Maintainer

The problem could be specific to SCM, maybe it orders the indices differently. @grantfirl

climbfuji Jul 15, 2021
Maintainer

Grant is on leave this week with limited access to emails, and completely out next week.

climbfuji Sep 13, 2021
Maintainer

@grantfirl A reminder, just in case this slipped ...

grantfirl Sep 22, 2021
Maintainer

@climbfuji I'm taking a look at this now. The tracer files (including the order of tracers) used in the SCM for a given suite were originally copied from FV3 field tables. I'll revisit and check these, since I think that is the root of the issue. I would, however, argue that the calculation of pwat would probably be better to sum over tracers using their actual indices (index_of_cloud_liquid_water_mixing_ratio_in_tracer_concentration_array...) rather than using something like ntcw, ntcw+nncl-1 which assumes a particular order of tracers in the field_table (and by extension the SCM tracer file). Likely not everybody is aware that such an order needs to be followed (I certainly wasn't until Moorthi just mentioned it in this issue).

grantfirl · 2021-09-23T20:35:47Z

grantfirl
Sep 23, 2021
Maintainer

@egrell Please see NCAR/ccpp-scm#273 that addresses the change in tracer order for the SCM to match the FV3. @climbfuji, are you aware if the FV3_input_data files are under revision control? Had I been aware that field_tables had changed, those changes could have been propagated to the SCM's tracer config files at that time.

2 replies

climbfuji Sep 23, 2021
Maintainer

The input data is not under revision control. Whenever an update is needed, the date tag associated with the input data in the ufs-weather-model rt.sh gets updated. However, we are moving towards adding the smaller files (field_table, diag_table) into the ufs-weather-model repository and only keep the large files (initial conditions etc) in the input directories on disk.

grantfirl Sep 23, 2021
Maintainer

OK, sounds good. Putting the field_table files in ufs-weather-model would help the SCM to stay in sync for sure (as long as I pay attention to PRs there!).

climbfuji · 2021-09-23T20:44:44Z

climbfuji
Sep 23, 2021
Maintainer

On the long run I would like to automatically generate field_table based on the physics choices in the SDF (because these define the tracers needed).

…

On Sep 23, 2021, at 2:42 PM, grantfirl ***@***.***> wrote: OK, sounds good. Putting the field_table files in ufs-weather-model would help the SCM to stay in sync for sure (as long as I pay attention to PRs there!). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RJ5LM27SZAUHAJTDH3UDOGMZANCNFSM5AODXI2Q>. 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>.

1 reply

grantfirl Sep 23, 2021
Maintainer

Even better. I remember this being discussed previously and will move the SCM over to that method when the time comes. I'm assuming that since the field_table file is needed at runtime (so are the SCM tracer config files) that the automatic generation would happen alongside the CCPP cap generation and not in some other manner (e.g. in a run script)?

climbfuji · 2021-09-23T20:56:12Z

climbfuji
Sep 23, 2021
Maintainer

That would be completely outside of CCPP, part of the host model (why should MPAS for example care about field_table). I can explain at the next DTC CCPP meeting, if you want.

…

On Sep 23, 2021, at 2:51 PM, grantfirl ***@***.***> wrote: Even better. I remember this being discussed previously and will move the SCM over to that method when the time comes. I'm assuming that since the field_table file is needed at runtime (so are the SCM tracer config files) that the automatic generation would happen alongside the CCPP cap generation and not in some other manner (e.g. in a run script)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RPAXV5I4W4O7ZX6MNLUDOHMTANCNFSM5AODXI2Q>. 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>.

1 reply

grantfirl Sep 23, 2021
Maintainer

Ah yes, that makes sense that it wouldn't be a CCPP thing (yet still relies on the SDF). It's not important that I understand the details until it's implemented for FV3, which I can then copy for the SCM.

grantfirl · 2021-09-23T20:59:47Z

grantfirl
Sep 23, 2021
Maintainer

@SMoorthi-emc Do you know if there is documentation for the order that tracers should be listed in the field_tables somewhere? From this thread, in order not to break the code, it seems like it needs to be something like:

water vapor
2:N. all water condensate species and all condensate number concentrations (if used)
N+1:M-1. ozone, cloud amount, aerosols in whatever order
M. TKE

where there are M total tracers?

0 replies

SMoorthi-emc · 2021-09-23T23:37:56Z

SMoorthi-emc
Sep 23, 2021
Collaborator

Hi Grant, That seems correct, although I have never run with aerosols. It is important to have all water vapor and cloud condensate together. While it is possible to generalize, then summing over condensate species gets complicated. I think such summation is done in the dynamics too but I haven't looked at dynamics recently; so I am not certain. Moorthi

…

On Thu, Sep 23, 2021 at 5:00 PM grantfirl ***@***.***> wrote: @SMoorthi-emc <https://github.com/SMoorthi-emc> Do you know if there is documentation for the order that tracers should be listed in the field_tables somewhere? From this thread, in order not to break the code, it seems like it needs to be something like: 1. water vapor 2-N. all water condensate species and all condensate number concentrations (if used) N+1:M-1. ozone, cloud amount, aerosols in whatever order M. TKE where there are M total tracers? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYRT25TXRPQBHWAJTKDUDOIM3ANCNFSM5AODXI2Q> . 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>.

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

1 reply

SMoorthi-emc Sep 24, 2021
Collaborator

In the dynamics, the "MULTI_GASES" option indeed assumes that vapor and condensates are together. For example
" rdx = rdx + rzx*q0(i,kk,sphum)/(1.0-sum(q0(i,kk,sphum+1:sphum+nwat-1)))"

climbfuji · 2021-09-24T02:18:19Z

climbfuji
Sep 24, 2021
Maintainer

Note that, in the UFS which uses the dnats logic for the dycore instead of splitting the tracers into prognostic and diagnostic, cloud amount MUST be the last tracer in the file. That is because dnats =1 means that the last tracer in the file will not be advected by the dycore (if dnats where two, then the last two tracers wouldn't be advected).

…

On Sep 23, 2021, at 6:09 PM, SMoorthi-emc ***@***.***> wrote: In the dynamics, the "MULTI_GASES" option indeed assumes that vapor and condensates are together. For example " rdx = rdx + rzx*q0(i,kk,sphum)/(1.0-sum(q0(i,kk,sphum+1:sphum+nwat-1)))" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RMIM4OWNFBRKDM573TUDO6TDANCNFSM5AODXI2Q>. 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>.

3 replies

SMoorthi-emc Sep 24, 2021
Collaborator

Yes, it appears that cloud_amount should be the last one, not TKE.
In the physics, for vertical diffusion, TKE is the last tracer.

SMoorthi-emc Sep 24, 2021
Collaborator

Also, note that this cloud_amt exists only for GFDL MP. For example, there is no such variable with MG3.

climbfuji Sep 24, 2021
Maintainer

We should consider switching from the dnats logic to the new logic that separates tracers in the dycore into diagnostic tracers and prognostic tracers.@bensonr explained to me here - this may need a little extra work as Rusty pointed out in this comment, but it would be far cleaner than relying on the user to put cloud amount at the end of field_table and setting dnats=1. @junwang-noaa @DusanJovic-NOAA FYI

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Another tracer index issue - in the pwat calculation #699

{{title}}

Replies: 11 comments 13 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Another tracer index issue - in the pwat calculation #699

egrell Jul 15, 2021

Replies: 11 comments · 13 replies

climbfuji Jul 15, 2021 Maintainer

SMoorthi-emc Jul 15, 2021 Collaborator

SMoorthi-emc Jul 15, 2021 Collaborator

egrell Jul 15, 2021 Author

SMoorthi-emc Jul 15, 2021 Collaborator

egrell Jul 15, 2021 Author

climbfuji Jul 15, 2021 Maintainer

climbfuji Jul 15, 2021 Maintainer

climbfuji Sep 13, 2021 Maintainer

grantfirl Sep 22, 2021 Maintainer

grantfirl Sep 23, 2021 Maintainer

climbfuji Sep 23, 2021 Maintainer

grantfirl Sep 23, 2021 Maintainer

climbfuji Sep 23, 2021 Maintainer

grantfirl Sep 23, 2021 Maintainer

climbfuji Sep 23, 2021 Maintainer

grantfirl Sep 23, 2021 Maintainer

grantfirl Sep 23, 2021 Maintainer

SMoorthi-emc Sep 23, 2021 Collaborator

SMoorthi-emc Sep 24, 2021 Collaborator

climbfuji Sep 24, 2021 Maintainer

SMoorthi-emc Sep 24, 2021 Collaborator

SMoorthi-emc Sep 24, 2021 Collaborator

climbfuji Sep 24, 2021 Maintainer

egrell
Jul 15, 2021

Replies: 11 comments 13 replies

climbfuji
Jul 15, 2021
Maintainer

SMoorthi-emc Jul 15, 2021
Collaborator

SMoorthi-emc
Jul 15, 2021
Collaborator

egrell
Jul 15, 2021
Author

SMoorthi-emc
Jul 15, 2021
Collaborator

egrell
Jul 15, 2021
Author

climbfuji Jul 15, 2021
Maintainer

climbfuji Jul 15, 2021
Maintainer

climbfuji Sep 13, 2021
Maintainer

grantfirl Sep 22, 2021
Maintainer

grantfirl
Sep 23, 2021
Maintainer

climbfuji Sep 23, 2021
Maintainer

grantfirl Sep 23, 2021
Maintainer

climbfuji
Sep 23, 2021
Maintainer

grantfirl Sep 23, 2021
Maintainer

climbfuji
Sep 23, 2021
Maintainer

grantfirl Sep 23, 2021
Maintainer

grantfirl
Sep 23, 2021
Maintainer

SMoorthi-emc
Sep 23, 2021
Collaborator

SMoorthi-emc Sep 24, 2021
Collaborator

climbfuji
Sep 24, 2021
Maintainer

SMoorthi-emc Sep 24, 2021
Collaborator

SMoorthi-emc Sep 24, 2021
Collaborator

climbfuji Sep 24, 2021
Maintainer