Add convergence tasks for space and time only

[cbegeman]

This PR extends the convergence test framework to accommodate convergence in space, time or both. This PR also adds additional tests for space-only and time-only convergence for the cosine_bell, geostrophic, manufactured_solution, and inertial_gravity_wave groups. The convergence_time cases have not been optimized (in terms of resolution and time steps) nor have separate convergence thresholds been specified.

Checklist

• User's Guide has been updated
• Developer's Guide has been updated
• API documentation in the Developer's Guide (api.md) has any new or modified class, method and/or functions listed
• Documentation has been built locally and changes look as expected
• Testing comment in the PR documents testing used to verify the changes
• New tests have been added to a test suite

[cbegeman]

Testing

I have tested all of the convergence tests on chrys with intel, impi.

[cbegeman]

@sbrus89 If you want to review, feel free!

[xylar]

@cbegeman, sorry for dropping the ball on this one. I don't seem to get notified when I get marked as a reviewer so I just hadn't noticed.

[xylar]

I really like this approach! I also really appreciate the amount of effort that went into it.

I'm seeing a crash in icos/geostrophic/convergence_time/forward/60km_960s. I think this is too big a time steps to be safe for RK4 at this resolution.

This leads to a more general comment. I think different options like refinement_factor are appropriate for space and time. First, there is not a clear reason that the number of forward steps in time necessarily needs to match the number in space (though it's fine if it does). But more importantly, one should presumably always be reducing dt from the base value, whereas it is common to increase the resolution from the base value. So for geostrphic, I could imagine:

icos_base_resolution = 60.0
icos_space_refinement_factors = 8., 4., 2., 1.
icos_time_refinement_factors = 1., 0.5, 0.25, 0.125
rk4_dt_per_km = 2.0

We might decide that we want to have a cheaper base resolution, we might feel that we could get away with a larger rk4_dt_per_km, or we might feel we could get away with larger values for icos_time_refinement_factors but it seems clear that 8 is too large.

A small side note for the future. In a future PR, we might want to add different convergence_thresh values for space, time and both. We expect 4th order convergence in time only (eventually) with RK4, right? We can cross that bridge when we come to it, though.

[xylar]

@cbegeman, what do you think of switching the order of the for loops here? It would make more sense to me to have tests without and with viz next to each other in the list.

[xylar]

Hmm, I'm not happy with my suggested icos_time_refinement_factors because it only applies in convergence_time, not in convergence_both. I'll have to think about that more.

[xylar]

I suppose another approach would be to automatically renormalize *refinement_factor for convergence_space tests to be <= 1, so that 8, 4, 2, 1 and 4, 2, 1, 0.5 would both automatically becomes 1, 0.5, 0.25, 0.125 for space-only.

[cbegeman]

I did intend that eventually we would set time refinement factors differently from space refinement factors with different config options, but it would require a lot of testing for me to figure out what those should be for each case so I thought that could be a follow-on PR. Is that ok with you?

[cbegeman]

@xylar Ready for re-review when you have a chance