-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_table
or 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_table
or 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: