Feature/aoloso/load balance

[aoloso]

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[atrayano]

Should we change line 87 in MAPL_LoadBalance.F90 from real to real(MAPL_r4). My concern is that if we ever compile MAPL with -r8 flag (probably many other pieces will break too. Fortunately, we never do this), the overload won't work

[tclune]

Definitely a case that screams for templates in the language.

[tclune]

Should we change line 87 in MAPL_LoadBalance.F90 from real to real(MAPL_r4). My concern is that if we ever compile MAPL with -r8 flag (probably many other pieces will break too. Fortunately, we never do this), the overload won't work

I am not worried about anyone using -r8 on MAPL; we'll never support that in our CMake, and I cannot imagine anyone rolling their own build.

But a closely related question on which we (I) never really come to a firm conclusion: what is the right/best way to declare such things. We have these choices:

1. REAL*4 vs REAL*8
2. REAL32 vs REAL64
3. SELECT_REAL_KIND(...) (of which MAPL_R4 and MAPL_R8 are proxies)
4. C_FLOAT vs C_DOUBLE

None of these is strictly guaranteed to work with all compilers. (1) is not standard conforming. For (2), compilers can return a value of -1 if they don't support a given precision. (3) may return the same KIND for both precision and therefore make the overload illegal. And (4) the compiler may not have a "companion" C compiler. Since all extant machines are IEEE and have companion compilers, (2-4) are effectively equivalent (assuming smart choices for the args in (3).)

@mathomp4 and I have tended towards choosing (2) as it standardizes where the named constants come from rather than each package defining their own (MAPL, ESMF, FMS, ...) ala (3). But (4) has that and in theory is necessary for C interoperability, which is not a high priority. (And in practice is equivalent to (2) anyway.)

Ugh.