Conversation
Adds two single level diagnostics giving the ICAO standard atmosphere height, in kft, of the base and the top of the lowest convective cloud in the column: convection__lowest_conv_cloud_base_icao_height convection__lowest_conv_cloud_top_icao_height These are the "lowest cloud" counterparts of the existing convection__conv_cloud_base_icao_height and convection__conv_cloud_top_icao_height diagnostics, and are computed in exactly the same way: icao_heights_kernel is applied to the existing convection__pres_lowest_cv_base and convection__pres_lowest_cv_top pressure diagnostics, which are activated as dependencies when either of the new heights is requested. Those pressures are already set to the missing data indicator in columns with no convective cloud, which icao_heights_kernel passes straight through, so unconverged columns are flagged as missing rather than given a spurious height. Both the Gregory-Rowntree and the CoMorph diagnostics paths are updated, and the new fields are added to the three hourly standard level output stream alongside the existing ICAO heights. Some of the content of this change has been produced with the assistance of Anthropic Claude Opus 5 (Claude Code).
Adds a single level diagnostic, convection__cape_undilute, giving the convective available potential energy of an undilute parcel ascent in J/kg. The quantity is already computed by conv_diag, which in LFRic is called from bl_exp_kernel rather than from the convection scheme, so the diagnostic is plumbed out of the explicit boundary layer kernel following the pattern of the existing zht and oblen diagnostics: a new write-only single level field is added to the kernel metadata and is only filled when the field has been requested. The field is added to the three hourly standard level output stream, and to the coupled atmosphere field definitions alongside the existing diluted CAPE. Some of the content of this change has been produced with the assistance of Anthropic Claude Opus 5 (Claude Code).
github-actions
Bot
added
the
cla-modified
MichaelWhitall
left a comment
MichaelWhitall
left a comment
There was a problem hiding this comment.
Hi thanks for this;
I'm slightly nervous that this change has been written by AI and sci/tech reviewed by someone (me) who doesn't really understand the LFRic diagnostic system in-which the changes are made? But I've had a go, hopefully code-owners who are more in-the-know can check this over too?
Cheers!
Mike
| "parcel_buoyancy", "qsat_at_lcl", "bl_type_ind", "visc_m_blend", | ||
| "visc_h_blend", "zh_2d", "zhsc_2d", "ntml_2d", "cumulus_2d", | ||
| "rh_crit", "mix_len_bm", "dsldzm", "wvar", "zht", "oblen", | ||
| "cape_undilute_2d", |
There was a problem hiding this comment.
Can you explain what this is doing? Why are we telling PsyClone to "ignore dependencies" specifically for the undilute cape diagnostic output by conv_diag?
There was a problem hiding this comment.
I'm not sure - I'm hoping Hacka Fett (@christophermaynard) is going to say whether this is correct or not (it is at least consistent with what happens for the other diagnostic fields!)
Don't worry, the AI has very much been supervised to produce exactly what I would have done if hand-coding it! |
MichaelWhitall
left a comment
MichaelWhitall
left a comment
There was a problem hiding this comment.
I think this all looks OK to me, given the extra info provided in replies to my comments :) Still pending an explanation on the optimisation change in "script_options.py" (just done as the same was done for other diagnostics in the BL explicit kernel), but Chris can cover that in his code-owner review for optimisation...
sci/tech review approved
|
Just grabbing this one back, as another request has come out of the woodwork that it seems sensible to add to this rather than a separate PR... |
Adds a 3-D diagnostic, convection__ccw_unadjusted, giving the in-cloud convective cloud condensed water in kg/kg before the scheme dependent scaling that is applied to the value passed on to the radiation and cloud schemes. The Gregory-Rowntree scheme returns two convective cloud water profiles: the raw in-cloud value, and a copy scaled by the deep, mid-level and shallow tuning knobs. Only the scaled profile is currently available in LFRic, as convection__ccw, so the raw value is plumbed out of conv_gr_kernel following the pattern of the existing convection__cca_unadjusted diagnostic, and named to match it: a new field is added to the kernel metadata, is accumulated over the convection sub-steps only when it has been requested, and is only accumulated on the last outer iteration. The diagnostic is not added to the CoMorph path because CoMorph copies its convective cloud water through unadjusted, so there the new diagnostic would be identical to convection__ccw. The field is added to the lfric_atm field definitions, and to the convection kernel PSyclone transmute scripts alongside the other optional convection diagnostics. Some of the content of this change has been produced with the assistance of Anthropic Claude Opus 5 (Claude Code).
|
MichaelWhitall c658fef adds the "section 5" CCW diagnostic (i.e. unadjusted for radiation), which is required for some OS use (but not one currently tested in rose-stem, hence not added to the file there) - can you give it a quick check and pass on to Ed if you're happy. I've added a plot of it working from the SCM. |
MichaelWhitall
left a comment
MichaelWhitall
left a comment
There was a problem hiding this comment.
Thanks; this looks fine to me :)
Re the decision to leave the new unadjusted CCW diagnostic out of comorph (since comorph doesn't have separate adjusted / unadjusted fields anyway)... I guess my main concern is what happens if we switch to running comorph and some downstream thing is expecting ccw_unadjusted to be set?
A crucial question is, does the lfric_apps diagnostics system have anything equivalent to STASH option codes for diagnostics in the UM? i.e. if I switch to a model configuration in-which an existing diagnostic I've requested is no-longer available, what happens? In the UM I'd get a warning telling me the STASH request has been rejected, and the field wouldn't be there in the output file, so I'd soon find out if my downstream thing tried to use the unavailable field. In LFRic, is the field similarly non-existent in the output file if I run a configuration that doesn't calculate it? Or is the field there but contains zero or junk? (that would be worrying!)
| "detrain_up", "detrain_down", "dd_dt", "dd_dq", "deep_massflux", | ||
| "deep_dt", "deep_dq", "shallow_massflux", "shallow_dt", "shallow_dq", | ||
| "mid_massflux", "mid_dt", "mid_dq", "cca_unadjusted", | ||
| "mid_massflux", "mid_dt", "mid_dq", "cca_unadjusted", "ccw_unadjusted", |
There was a problem hiding this comment.
Again, it'd be nice to know / understand what the changes in these optimisation files actually do, given I'm meant to be reviewing this! (stick it to "separation of concerns"!) Are we really meant to just let AI copy/paste what's done for existing variables without understanding it?
| end do | ||
| end do | ||
| end if | ||
| if (.not. associated(ccw_unadjusted, empty_real_data) ) then |
There was a problem hiding this comment.
Yep I've confirmed that "it_ccw0" (which is copied into the array passed to radiation) is scaled by the ccw tuning knobs in glue_conv_6a, whereas "it_ccw" (which is copied into the new diagnostic) does not. All looks good :)
Thanks Mike - I've opened #718 to answer this question - I believe it would be better to implement a proper solution here rather than force ccw_unadjusted to be unnecessarily written when Comorph is active. Ed Hone (@EdHone) over to you for code review (you might also have some useful thoughts on #718) |
|
Your CLA signature was found on the base branch, but you appear to have modified the CONTRIBUTORS.md file in this PR. Please do not edit the CONTRIBUTORS.md file. If you have already signed the CLA, revert changes to the file and your signature will be picked up. |
3 participants
PR Summary
Sci/Tech Reviewer: MichaelWhitall
Code Reviewer: Ed Hone (@EdHone)
Some plots of the new diagnostics:
closes #643
Code Quality Checklist
Testing
trac.log
Test Suite Results - lfric_apps - conv_icao_cape_diags/run1
Suite Information
Task Information
✅ succeeded tasks - 1221
Security Considerations
Performance Impact
AI Assistance and Attribution
Documentation
PSyclone Approval
Sci/Tech Review
(Please alert the code reviewer via a tag when you have approved the SR)
Code Review