Updates to MYNN-EDMF with additional output for downdrafts

[joeolson42]

This PR provides a significant update to the downdraft component of the MYNN-EDMF with minor tweaks elsewhere. Addition 2d output field have been added to expedite tuning/debugging. The following list overviews the changes:

1. Blend the downdrafts with the analytical profile specification of TKE production to provide one fairly well tested option.
2. Extend the analytical profile method to single-layer fog as well as clouds aloft that are decoupled from the surface. This allows this method to be used in tandem (and consistently) with the downdraft component.
3. Add 5 2d diagnostic variables that have been extremely useful in developing the downdraft component.
4. Related to forecasting clouds in the marine boundary layer, change the max for qnwfa in the common file to have no impact above the marine pbl while still limiting it to reasonable values within the marine pbl--a useful hack to not allow the poor qnwfa specifications from the climatology to create excessive fog over cold coastal waters (i.e., near NY and Boston).
5. many of the changes in the pbl driver are simply spacing changes.

This updated code has been tested in both MPAS , WRF, and CI tests.

Mandatory Questions

• Does this PR include any additions or changes to external inputs (e.g., microphysics lookup tables, static data for gravity-wave drag -- things like that)?
  • no
• Does this PR require updating one or more baselines for the CI tests? If so, what?
  • yes, we currently don't test the downdrafts (config_mynn_edmf_dd = 1) in our MPAS CI testing.

Reviews

• Is this PR currently draft, still being worked on, or ready for review?
  • ready for review, but if it persists in queue for more than 2-3 days, minor tweaks may be added.
• For when this PR begins review, please list the developers/collaborators you'd like to prioritize for review; e.g.,:
  • @clark-evans
  • @AndersJensen-NOAA
  • @XiaSun-Atmos

[joeolson42]

Please submit your reviews asap!

[AndersJensen-NOAA]

@joeolson42 @clark-evans Are we going to put this code into a dev?

[clark-evans]

@joeolson42 @clark-evans Are we going to put this code into a dev?

We should. OK to take the TEMPO hail mods out of dev2 for now? (Longer term, assuming these mods look good, I presume we'd want to put them into dev1 to inform the prog cloud scheme?)

[dustinswales]

These changes look good to me. Thanks!

[dustinswales]

@joeolson42 Can you update your branch with develop?

[joeolson42]

@joeolson42 Can you update your branch with develop?

done

[AndersJensen-NOAA]

Will approve but would like to see cloudiness changes in a dev.

[dustinswales]

@AndersJensen-NOAA I think I'm starting to understand the group lingo.
"See it in a dev" means validation. I added a label to the project board, "needs evaluation".
IMO. This step should be integrated into the development cycle.

[clark-evans]

@AndersJensen-NOAA I think I'm starting to understand the group lingo. "See it in a dev" means validation. I added a label to the project board, "needs evaluation". IMO. This step should be integrated into the development cycle.

Thanks for adding that label, @dustinswales. Running major developments in a dev (referring to MPAS_physics_dev1 and MPAS_physics_dev2, in case others were wondering) is a standard practice. The challenge arises when we have multiple developments needing real-time evaluation, such as we do now with the prog cloud scheme, other TEMPO updates, and now the v8.4 merge, this PR, and the prognostic aerosol emissions.

[clark-evans]

Approved pending spacing changes. OK to merge after real-time testing.

In module_bl_mynnedmf.F90, I see several changes related to hurricane/higher wind speed tuning. As best as I can tell, at least for the new code in lines 1978-1980 (which are just one of the changes), it looks like they would primarily foster higher wind speeds. Is that correct? If so, I’d like to test this code in a Melissa retro before the 2026 HFIP.

[dustinswales]

@clark-evans Understood.
I'm working on a figure explaining the various labels and how they fit into the development cycle.
Currently, there is a bot automatically moving things from "Needs evaluation" to "Ready to Merge" ever time we get another approval. Grrr!

[clark-evans]

@clark-evans Understood. I'm working on a figure explaining the various labels and how they fit into the development cycle. Currently, there is a bot automatically moving things from "Needs evaluation" to "Ready to Merge" ever time we get another approval. Grrr!

I think that's the "Code review approved" workflow. I just disabled that. We enabled it at the code discussion meeting a couple of weeks ago as a test, to see if it would apply whenever an approval came in or only after all requested approvals had come in. Since it appears to be the former, I don't think we want it enabled.

[clark-evans]

@joeolson42 could you update the repo for this PR to the top of noaa/develop? There are also a couple of nitpicky spacing change requests from me above. I think we should be able to merge this at tomorrow's code meeting if it's updated by then.

[dustinswales]

@joeolson42 @clark-evans I think this one is ready. Let's merge this at our meeting in a few minutes.