Refactor Axis Information Handling for Improved Performance in ocean_sponge

[yichengt900]

This PR addresses issue #644 by introducing a logic change when calling get_external_field_info in MOM_interp_infra.F90. Since the axis, dimension, and missing value information for nudging are time-independent, there is no need to read this information from the NetCDF file at every time step when using FMS2. With this fix, the runtime of nudging experiments with FMS1 and FMS2 are now comparable:

FMS2 with new fix one year run:

                                      hits          tmin          tmax          tavg          tstd  tfrac grain pemin pemax
Total runtime                            1   9425.780744   9425.898127   9425.820889      0.036968  1.000     0     0  1645
(Ocean sponges)                      17520    445.104094   1139.163714    580.620263     63.931211  0.062    31     0  1645

FMS1 with new fix one year run:

                                      hits          tmin          tmax          tavg          tstd  tfrac grain pemin pemax
Total runtime                            1   9400.495175   9400.592062   9400.525483      0.031271  1.000     0     0  1645
(Ocean sponges)                      17520    446.976279   1156.951049    594.715797     65.370447  0.063    31     0  1645

Keep in mind, this is just a simple fix to allow users to run MOM6 with both the sponge option and FMS2 simultaneously. It would probably be better to refactor FMS2/MOM_interp_infra.F90 in the future to fundamentally solve the issue.

[Hallberg-NOAA]

Although these changes appear to fix the specific problem with FMS2 being incredibly slow when reading the sponge data, the way that they do so are problematic. Specifically, by saving this information via the save attribute, these changes would preclude the use of the horizontal regridding with multiple files with different axis information. Moreover, the save attribute is essentially the same as adding module data, which is not permitted in MOM6 as described at https://github.com/NOAA-GFDL/MOM6/wiki/Code-style-guide#global--module-data.

One acceptable way to accomplish what is being attempted here this would be to add a type as an optional argument to store this information between calls, with the actual storage of this type occurring at a higher level (probably in the control structure for the sponges). This would allow this code to be reused with multiple files.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 37.00%. Comparing base (9059671) to head (3fa9388).

❗ Current head 3fa9388 differs from pull request most recent head f7aef94

Please upload reports for the commit f7aef94 to get more accurate results.

Additional details and impacted files

@@             Coverage Diff              @@
##           dev/gfdl     #653      +/-   ##
============================================
+ Coverage     36.92%   37.00%   +0.07%     
============================================
  Files           271      271              
  Lines         81545    81214     -331     
  Branches      15244    15149      -95     
============================================
- Hits          30112    30050      -62     
+ Misses        45791    45534     -257     
+ Partials       5642     5630      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yichengt900]

@Hallberg-NOAA,

Thank you for the detailed feedback. I have updated this PR to address the issues you mentioned.

Specifically, I have removed the save attribute and instead added an axis_info type as an optional argument in horiz_interp_and_extrap_tracer_fms_id to pass the preloaded axis information. This storage now occurs in set_up_ALE_sponge_field, allowing the axes_data to be reused. With these changes, the runtime of ocean_sponge has been reduced from 0.042s to 0.012s, an improvement of approximately 71.43% in a 1D test case.

Please feel free to review the changes and let me know if any further adjustments are needed.

[Hallberg-NOAA]

This is now an elegant solution to the performance problems that had been noted, and it all looks good to me.

[marshallward]

@yichengt900 For reasons I still don't understand, we're not able to rebase or squash PRs from organizations. Somehow or another, we need to allow NOAA-GFDL (or NOAA-GFDL/MOM6) to modify PRs from NOAA-GFDL-Regional-Ocean's MOM6. I tried to work this out with @kshedstrom but did not get very far.

There are three options here:

1. Figure out the settings which allow for others to manipulate PRs. We may need to somehow restrict this to NOAA-GFDL. And, it may not even be possible.
2. Resubmit from your personal account
3. We do the rebase/squash on our end and submit internally (i.e. command line).

Typically we have done option 3, but this might be a good opportunity to finally get option 1 working.

[yichengt900]

Hi @marshallward, hmm I haven't figured out how to make option 1 work yet and will need to spend more time on it. In the meantime, I have squashed the commits, so please feel free to merge if you see fit.

[marshallward]

Of course I forgot option 4: Do the rebase on your end 🤣

Really appreciated, thanks. We can look more into it when it happens next time.

[marshallward]

Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/mom6ci/MOM6/-/pipelines/23703 ✔️