Check timestep and reference_time for compatibility in FrequencyAspect

[darianboggs]

We need to check timestep and reference_time in FrequencyAspect to verify compatibility with other derived types and variables.

[tclune]

(Mentioning @atanas so that he watches this issue.)

There are 2 sub-issues here (both are small so don't necessarily need to split into separate issues.)

1. Is the specified timestep and reference time for a user component compatible with those of the parent in terms of running.
2. Are the specified timestep/ref time compatible as FrequencyAspect's.

For each of these we must distinguish between the "ordinary" and the exceptional cases. Ordinary cases are those where the timestep does not involve months/years. In these cases we expect ESMF MOD() to be our friend.

My initial thoughts:

Case 1:

• ordinary: I think we want to require that each user clock tick coincides with some clock tick of the parent:
  MOD(UserRefTime - ParentRefTime, ParentTimeStep) == 0
MOD(UserTimestep,ParentTimestep) == 0
  Case 2:
• ordinary: I think we want to require that each import clock tick coincides with some clock tick of the export:
  MOD(ImportRefTime - ExportRefTime, ExportTimeStep) == 0
MOD(ImportTimestep,ExportTimestep) == 0

More thought is needed for the extraordinary cases.

[darianboggs]

Draft PR #3368 is pushed. It checks cases where the timesteps do not contain yy and mm units. Before merging this PR, that condition will be relaxed so that the user component timestep can contain any units, and the OuterMetaComponent timestep can contain yy and mm units if and only the user component timestep contains only yy and mm units, which avoids the nonuniform lengths of years and months.

[mathomp4]

Huh. I didn't know ESMF provided a mod() for time but, yeah, there it is:

ESMF_TimeIntervalFunction(MOD) - Divide two TimeIntervals, return TimeInterval remainder