PBL utils transfer

[mwaxmonsky]

Originator(s): @mwaxmonsky

Summary (include the keyword ['closes', 'fixes', 'resolves'] and issue number): Adds pbl_utils capability from CAM.

Describe any changes made to the namelist: N/A

List all files eliminated and why: N/A

List all files added and what they do:
M phys_utils/atmos_phys_pbl_utils.F90

• Transferred all functionality (except for compute_radf(...)) from ESCOMP/cam/src/physics/cam/pbl_utils.F90

M .github/workflows/unit-tests.yaml

• Added phys_utils to code coverage.

M test/unit-test/CMakeLists.txt
M test/unit-test/tests/CMakeLists.txt
M test/unit-test/tests/phys_utils/CMakeLists.txt
M test/unit-test/tests/phys_utils/test_atmos_pbl_utils.pf

• Creating CMake target library for phys_utils and adding sample unit tests.

List all existing files that have been modified, and describe the changes: N/A
(Helpful git command: git diff --name-status development...<your_branch_name>)

List any test failures: N/A

Is this a science-changing update? New physics package, algorithm change, tuning changes, etc? No

[jimmielin]

Thanks @mwaxmonsky! I did not review the equations themselves as I assume they match bit-for-bit as used in current CAM.

I had one comment about one of the private functions since you noted hb_diff which I hope to be working on soon.

All the other comments are about unit comments - sorry in advance if I'm being too annoying about this - I noticed that only some of the functions had input/outputs' units noted in the comments, but not all of the unnoted quantities are unitless. Since this file does not have a .meta file attached, I think it would be good for future reference to note down the units while this file is still fresh. I went through the file and worked out the units (hopefully correctly) and added review comments where relevant. I'm happy to discuss if this is too much trouble!

[jimmielin]

vriable -> variable

I looked in hb_diff.F90 and the other files in the companion PR in ESCOMP/CAM (https://github.com/ESCOMP/CAM/pull/1235/files) and couldn't find where neutral_exchange_coefficient was being used, except through calc_eddy_flux_coefficient.

Additionally hb_diff.F90 still names the shear squared variable as s2 and not shear_squared.

I was wondering if you intended for there to be any further changes on trbintd in hb_diff.F90 in the future?

[mwaxmonsky]

Fixed the typo!

In terms of uses of neutral_exchange_coefficient, yup, it's only a helper function (though probably named a little too long) to prevent us from having to copy/paste the ml2*sqrt(s2). It's only used twice so it is right on that edge of probably not needing it but I'm happy to discuss whether it's useful enough to pull out or not.

Updated the comment to reference s2.

In an ideal world, yes, I would like to update and pull some of the functions in trbintd into the physics utils as they are completely standalone and also follow CCM1/other documents that might be useful in other schemes. There was already enough in this PR so we decided it best to add it to review and follow up in the next step with possibly refactoring trbintd.

In theory, there may be some improvements to doing so as well since the computed data is done every time step anyway, moving it into atmos_phys would allow for a cleaner API for the host so that the temporary data is computed by the physics layer and used directly instead of the host doing physics calculations.

[jimmielin]

Thank you for explaining @mwaxmonsky! This sounds great. All the updates will greatly help eventually CCPPizing hb_diff.F90 (when I was first scoping it out months ago I kept thinking how to deal with these pbl_utils...) so I really appreciate this work.

[mwaxmonsky]

@nusbaume Actually, after closer inspection, would it be worthwhile to remove trbintd in this PR? It computes s2, n2, and ri and we actually don't use n2 from what I can tell. So we could at least remove the n2 part and I could look at cleaning up the API right now and I don't think there's be that much of a lift to pull that into atmos_phys. Would this be reasonable at the moment?

[nusbaume]

We'll definitely want to split-up trbintd into separate functions at some point, as many of those calculations (including n2) are general equations which may be used in various places throughout the physics code, including MMM physics.

However, I would say let's hold off on worrying about it for this PR, especially because I don't think that particular subroutine will cause any problems with CCPP-ization (as it looks entirely under hb_diff itself). Maybe instead let's just make an issue to remember to "functionalize" it later?

[mwaxmonsky]

Sounds good, just wanted to double check, I'll open an issue!

[jimmielin]

Thanks @mwaxmonsky!

[nusbaume]

Great work @mwaxmonsky! Just had a few (hopefully minor) change requests.

[nusbaume]

We'll definitely want to split-up trbintd into separate functions at some point, as many of those calculations (including n2) are general equations which may be used in various places throughout the physics code, including MMM physics.

However, I would say let's hold off on worrying about it for this PR, especially because I don't think that particular subroutine will cause any problems with CCPP-ization (as it looks entirely under hb_diff itself). Maybe instead let's just make an issue to remember to "functionalize" it later?

[nusbaume]

Everything looks great to me now. Thanks @mwaxmonsky!