Tracer rework + Updates to work with PBL schemes needed in Lulin's DOE ASR project #190
Conversation
…dices to GFS_typedefs; add tracer_names to gmtb_scm_input.f90 (call get_tracers before scm_state_create); change state_create in gmtb_scm_type_defs to handle externally configured tracers; change run_gmtb_scm.py script to specify tracer file, or to use default tracers connected to specific SDFs, and link the tracer file to the run directory; add SDFs and physics namelists for ACM, YSU, and saYSU suites (prescribed surface versions only)
… ccpp-physics right now)
There was a problem hiding this comment.
The PR itself is good to go, but I wish we had discussed this beforehand. If anything I would like the UFS to move away from specifying tracers (redundantly) in field_table. If we look at it, there is only one valid set of tracers that one can use for a chosen physics suite and some runtime flags (e.g. Thompson with/without aerosols), so specifying them redundantly in a field_table or other file isn't particulary useful, or? Sorry if I missed something, happy to stand corrected.
| "ice_nc","ice_number_concentration","kg-1" | ||
| "rain_nc","rain_number_concentration","kg-1" | ||
| "o3mr","ozone_mixing_ratio","kg kg-1" | ||
| "liq_aero","water_friendly_aerosol_number_concentration","kg-1" |
There was a problem hiding this comment.
How do you envisage using the Thompson non-aerosol aware version (ltaerosol = .false.)? A separate tracers_gsd_no_aero.txt?
There was a problem hiding this comment.
The PR itself is good to go, but I wish we had discussed this beforehand. If anything I would like the UFS to move away from specifying tracers (redundantly) in
field_table. If we look at it, there is only one valid set of tracers that one can use for a chosen physics suite and some runtime flags (e.g. Thompson with/without aerosols), so specifying them redundantly in afield_tableor other file isn't particulary useful, or? Sorry if I missed something, happy to stand corrected.
I'm not necessarily advocating for specifying them redundantly via an external file, and would certainly be open to these being controlled via a suite, e.g. via its SDF. This implementation was a response to some logic in GFS_typedefs that was dependent on the number of tracers. For the SCM, I had been using a superset of all tracers needed by all physics (that I have been tested with supported suites and some experimental suites). Automatically running with more tracers for some suites was causing the vertically-diffused tracer array to be unnecessarily large for some suites (and actively causing problems in some PBL schemes). By putting in this logic, I can run the SCM with "just enough" tracers. Once someone implements something different for tracers for FV3 (that is potentially CCPP suite-based), I'd love to switch to that. That definitely makes more sense to me too. It just doesn't exist today.
There was a problem hiding this comment.
How do you envisage using the Thompson non-aerosol aware version (
ltaerosol = .false.)? A separatetracers_gsd_no_aero.txt?
Yep, a separate tracer config file.
There was a problem hiding this comment.
The PR itself is good to go, but I wish we had discussed this beforehand. If anything I would like the UFS to move away from specifying tracers (redundantly) in
field_table. If we look at it, there is only one valid set of tracers that one can use for a chosen physics suite and some runtime flags (e.g. Thompson with/without aerosols), so specifying them redundantly in afield_tableor other file isn't particulary useful, or? Sorry if I missed something, happy to stand corrected.I'm not necessarily advocating for specifying them redundantly via an external file, and would certainly be open to these being controlled via a suite, e.g. via its SDF. This implementation was a response to some logic in GFS_typedefs that was dependent on the number of tracers. For the SCM, I had been using a superset of all tracers needed by all physics (that I have been tested with supported suites and some experimental suites). Automatically running with more tracers for some suites was causing the vertically-diffused tracer array to be unnecessarily large for some suites (and actively causing problems in some PBL schemes). By putting in this logic, I can run the SCM with "just enough" tracers. Once someone implements something different for tracers for FV3 (that is potentially CCPP suite-based), I'd love to switch to that. That definitely makes more sense to me too. It just doesn't exist today.
Got it - in this case we should proceed with your PR, so that when the UFS gets cleaned up we do the same for the SCM.
There was a problem hiding this comment.
Would it help to open an issue in fv3atm or ccpp-framework or somewhere else regarding migrating away from the field_table for tracers and implementing something in ccpp-framework to create a tracer array based on CCPP suites and other namelist options? I'm not sure 1) who would be responsible for implementing something and 2) which repo(s) it would need to touch - potentially all of them. Plus, there could definitely be non-physics tracers, so the physics isn't the only "controller," so to speak.
There was a problem hiding this comment.
My understanding is that NCAR (Steve Goldhaber) would be implementing the functionality of creating a tracer array based on CCPP suites in capgen (if the NCAR collaboration with NRL is finalized). In today's CCPP-Framework meeting, Steve said this is captured in an issue in the ccpp-framework repository, but I cannot find which issue.
There was a problem hiding this comment.
Tracer rework + Updates to work with PBL schemes needed in Lulin's DOE ASR project
Major changes:
Notes on new tracer functionality:
"sphum")
"o3mr")
"liq_wat")
"ice_wat")
"rainwat")
"snowwat")
"graupel")
"cld_amt")
"water_nc")
"ice_nc")
"rain_nc")
"snow_nc")
"graupel_nc")
"sgs_tke")
"liq_aero")
"ice_aero")
"q_rimef")
Minor changes: