Feature/wdboggs/mapl3 freq aspect ts reftime 3358

[darianboggs]

Types of change(s)

• 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)
• Refactor (no functional changes, no api changes)

Checklist

• Tested this change with a run of GEOSgcm
• Ran the Unit Tests (make tests)

Description

FrequencyAspect has a timestep and reference time now. Conversion between FrequencyAspect objects requires a check that considers timestep and reference_time. This PR implements a fuller test of compatibility in the supports_conversion_specifc function for FrequencyAspect.

Related Issue

#3358 (part 2)

[tclune]

See one inline question. Otherwise is fine.

Note that there will be some conflicts with my big PR that I started today. (#3403) Ideally yours will go in first. One thing that changed is that I used refTime in most places in deference to ESMF argument spelling. (Also tried to use esmf capitalization for timeStep, but that is not crucial to be consistent.)

[tclune]

Alas, my PR got in first (#3403). Ping me if you need a second set of eyes to merge yours.

[darianboggs]

See one inline question. Otherwise is fine.

Note that there will be some conflicts with my big PR that I started today. (#3403) Ideally yours will go in first. One thing that changed is that I used refTime in most places in deference to ESMF argument spelling. (Also tried to use esmf capitalization for timeStep, but that is not crucial to be consistent.)

Do we want the reference time procedure argument to be called refTime? The ESMF variable names make sense to me once I know what the variables are, but when I look for a variable without knowing the variable name, the names are not obvious. I am learning the conventions, like timeStep and refTime, but I still use the ESMF documentation.

As a general policy, are we using the ESMF conventions where they overlap with MAPL?

[tclune]

I don't know these ESMF procedures any better. And I've definitely been inconsistent where "my" naming style conflicts with ESMF argument names. But when the variable really is just for the purpose of interacting with ESMF as these are it seems like the compromise should be towards ESMF. (E.g., I left the yaml key that you defined alone as it was not identical to the ESMF argument no matter what.)

I'm not worried about 100% consistency - but if you are going back in to fix other things, then yes - as much as possible follow the changes that I made.

[tclune]

As a general policy, are we using the ESMF conventions where they overlap with MAPL?

Just to be more specify. Yes - general policy is to use ESMF conventions when a variable is substantially only used as an argument to ESMF procedures. This is the case for things like importState (where I would otherwise prefer import_state). I just don't want to be overly strict here. For now we won't go sweeping the code for consistency, but I had the energy when making related changes this weekend and propagated it as best I could.

Was hoping that this PR would go in before mine as then I would have the responsibility for completing the exercise. Instead this PR is paying the price.

[darianboggs]

As a general policy, are we using the ESMF conventions where they overlap with MAPL?

Just to be more specify. Yes - general policy is to use ESMF conventions when a variable is substantially only used as an argument to ESMF procedures. This is the case for things like importState (where I would otherwise prefer import_state). I just don't want to be overly strict here. For now we won't go sweeping the code for consistency, but I had the energy when making related changes this weekend and propagated it as best I could.

Was hoping that this PR would go in before mine as then I would have the responsibility for completing the exercise. Instead this PR is paying the price.

Got it. I might as well change them while I have them.