Extend diag_mediator to allow the piecemeal posting of diagnostics #809
Conversation
Some quantities in MOM6 are calculated in subroutines which expect slices of the model's 2d or 3d arrays. Diagnosing these quantities can be challenging because the usual post_data calls expect whole arrays. To solve this problem, the changes here introduce a dynamic buffer that can grow as needed over the course of an simulation. This buffer keeps track of the diagnostic IDs and the index in the buffer. When a slot in the buffer is no longer needed, for example if the whole array has been computed and posted, the slot is marked as "available" for overwriting. The buffer is only allowed to grow if all the currently allocated slots are in use. Any computational cost associated with growing this buffer will only happen in the first few steps of the model as post_data for requested diagnostics is called for the first time in that run.
The diag mediator has been extended to add a dynamic buffer to each axes group. Three new methods have also been added to enable the piecemeal posting (by column, by point) of a diagnostic and a 'final' method to allow the buffer to be reused later.
ePBL calculates the vertical diffusivity column by column. This provides a convenient sanity check of the new piecemeal posting of diagnostics. The original diagnostic Kd_ePBL is done by posting the full 3d prognostic array, whereas a new diagnostic Kd_ePBL_col_by_col posts the same array from within ePBL but does so column by column.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev/gfdl #809 +/- ##
===========================================
Coverage ? 21.81%
===========================================
Files ? 137
Lines ? 33019
Branches ? 5850
===========================================
Hits ? 7202
Misses ? 25260
Partials ? 557 ☔ View full report in Codecov by Sentry. |
Fixes failures in the CI due to some procedures and type members not having docstrings.
src/framework/MOM_diag_buffers.F90
Outdated
| class(diag_buffer_2d), intent(inout) :: this !< This 2d buffer | ||
|
|
||
| integer :: n | ||
| real, allocatable, dimension(:,:,:) :: temp |
There was a problem hiding this comment.
Please add comments describing the purpose and units of this real variable. (Perhaps the units are [arbitrary] or '[A ~> a]if it might be rescaled later using the contents of aconversionargument to aregister_diag_field()` call.)
The same comment applies to lines 47, 165, 179, 193, 258, 281, 368 and 390.
There was a problem hiding this comment.
Comments have been added to indicate that these temporary arrays and the primary buffer in the type are arbitrary. The values (and their accordant units) assigned to these buffers will depend on their actual use within the codebase. Whether these represent scaled arbitrary units, depends on how they are filled from within the codebase. As you point out, in the case of their use as part of post_data, this may be the case, but may not in general hold.
There was a problem hiding this comment.
I think that this capability should be extended to include the ability to initialize a diagnostic buffer to land values to avoid the need to call the piecemeal posting for all columns, even over land.
Also, this PR should be revised to adhere to the guidance in the MOM6 style guide at https://github.com/NOAA-GFDL/MOM6/wiki/Code-style-guide, as described in specific comments.
|
@Hallberg-NOAA Thank you for the comments. I have added descriptions of the units (see the inline response) and made the if-statements conform the to the style guide. Additionally, the fill value for the arrays can now be specified; for the purposes of the piecemeal posting of the diagnostics these are set to the |
Some quantities in MOM6 are calculated in subroutines which expect slices of the model's 2d or 3d arrays. Diagnosing these quantities can be challenging because the usual post_data calls expect whole arrays. To solve this problem, the changes here introduce a dynamic buffer that can grow as needed over the course of an simulation.
This buffer keeps track of the diagnostic IDs and the index in the buffer. When a slot in the buffer is no longer needed, for example if the whole array has been computed and posted, the slot is marked as "available" for overwriting. The buffer is only allowed to grow if all the currently allocated slots are in use.
Any computational cost associated with growing this buffer will only happen in the first few steps of the model as post_data for requested diagnostics is called for the first time in that run.
This new piecemeal posting of a diagnostic was implemented for
Kd_ePBL. The new diagnosticKd_ePBL_col_by_colis the same as the the original field in theBaltic_OM4_05case.@adcroft @marshallward: Two points in particular that I'd like your feedback on:
post_datacall to be done without an extra copy. I have included astoresubroutine that could be used if we made it private, but otherwise those should be deleted.