[Feature] `delnflux` all nord

[FlorianDeconinck]

The original port of DelnFlux used the 3 first values of the nord_dictionary to compute. The original code reads the nord value for all K-levels and decides to execute the code or not.

GEOS use case showed that the assumption in pyFV3 is incorrect. On top of that, the time "optimized" by the strategy is minimal and by virtue of the DSL should not lie in the hands of the modelers.

In this PR:

• We add version.py to introduce a IS_GEOS switch that can be used to differentiate between numerical choices between NOAA and NASA
• Full nord coverage for DelnFlux
• Add check on column calculation taken as hypothesis for downstream calculations

• FV3GFS/GEOS differences solving:

  • d2_high_order_stencil as a difference of orders operations
  • nord & damp column calculation goes all the way to the n_sponge layer in GEOS

  NOTE: to do FV3GFS/GEOS swap we use the constant file in ndsl, a known refactorable entity.

[lharris4]

Hi, Florian. Thank you for letting me know. We hadn't seen these changes in the GEOS fork of FV3 before; I know GMAO had been working on some order-of-operation changes to avoid rounding-error mass loss at single precision but hadn't heard whether they were successful. This would potentially be useful for the GFDL main branch too.

Lucas

On Wed, Feb 21, 2024 at 9:47 AM Florian Deconinck @.***> wrote:

@.**** commented on this pull request.

In pyFV3/stencils/delnflux.py https://github.com/NOAA-GFDL/PyFV3/pull/3#discussion_r1497712332:

@.*** -def d2_highorder(fx: FloatField, fy: FloatField, rarea: FloatField):

• d2 = (fx - fx[1, 0, 0] + fy - fy[0, 1, 0]) * rarea
• return d2 +def d2_highorder_stencil_GEOS(
• fx: FloatField,
• fy: FloatField,
• rarea: FloatFieldIJ,
• nord: FloatFieldK,
• d2: FloatField,
• current_nord: int, +):
• with computation(PARALLEL), interval(...):
• if nord > current_nord:
• d2 = ((fx - fx[1, 0, 0]) + (fy - fy[0, 1, 0])) * rarea

At double floating precision, this has minimal to no impact. At single precision, however the order of the subtraction has measurable impacts (especially because of close-to-zero behavior of a lot of those codes).

A large amount of those diff pattern have been corrected in the GEOS fork of FV3.

— Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/PyFV3/pull/3#discussion_r1497712332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUQRVCDHVYMVT2PM3STD4LYUYCGJAVCNFSM6AAAAABDAOETFKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQOJTGQYTENRTGU . You are receiving this because you were mentioned.Message ID: @.***>

[FlorianDeconinck]

Hi, Florian. Thank you for letting me know. We hadn't seen these changes in the GEOS fork of FV3 before; I know GMAO had been working on some order-of-operation changes to avoid rounding-error mass loss at single precision but hadn't heard whether they were successful. This would potentially be useful for the GFDL main branch too. Lucas

My pleasure. If this project can have the side effect of updating people on work that hasn't been diffused then I am doubly glad! I'll chat with Bill about it before we merge this.

[FlorianDeconinck]

@oelbert / @lharris4

As expected, those changes were part of the work to keep mass conservation at single precision. GEOS is running single precision by default for a while with good results on that side.

Going forward I'll push those changes in as fixes rather than code differences between the two agencies.

[FlorianDeconinck]

@oelbert Ready for merge (once tests come back happy)