Ship helpers for preparing common patterns of input

[axch]

I noticed when writing the repeatability test suite that the examples had repeated patterns in the input:

• f-plane Coriolis force field
• beta-plane Coriolis force field
• rectangular bordered pool geometry (i.e., the wetmask being all 1 except for a 1-cell border)

I think it's a good idea (in principle, no comment on priority) to ship helper functions that implement these patterns so that users doing basic things can get started more easily.

There is a choice about whether to implement those features in the Fortran core of MIM or in Python/Matlab/etc helper code that the project ships in conjunction with the Fortran.

• Pro Fortran: Implemented just once in one place (whereas, if there come to be both Python and Matlab frontends, these helpers will be duplicated across them and will need to be kept in sync).
• Pro Fortran: Feature is available to the hypothetical user that just compiles the Fortran and doesn't use any frontend.
• Pro frontend: Programming in Fortran is tedious and error-prone.
• Pro frontend: Helpers will be simple to unit-test (though, I don't know whether Matlab's unit testing framework(s) are any easier to use than Fortran's).
• Pro frontend: Additional such patterns will be easier to add, if there aren't very many frontends to which they need to be added.
• Pro frontend: Lower core maintenance burden and maintenance churn: If these helper functions change, the rest of the core does not need to be reverified, and does not even seem to need to be reverified.
• Pro frontend: Research results are more reproducible because the computed inputs are always present to be saved, and loaded from. We can presumably minimize this point by dumping the computed inputs even if they are computed in Fortran, but I think that having that computation in the frontend(s) emphasizes the distinction more.

If Issue #21 is implemented, sinusoidal and stochastic wind will become two more such input patterns.

[edoddridge]

Another pro frontend point: the parameters.in file won't become cluttered with so many unused options.

I think there may be some value to having a few options implemented as defaults in the Fortran code that the user must actively override - e.g. forcing the wetmask to have a boundary around the edge (at least until we've sorted out #15 ). This would be a way of making MIM kinder to inexperienced users. Though it should definitely throw a warning if the user doesn't specify something important.

[axch]

Sensible defaults are definitely important. For single numbers, I think it may be sufficient to implement them by providing a template parameters.in file with the defaults in it, and inviting users to copy it and modify to suit their needs. And put the things they are most likely to want to modify near the top :) Not sure offhand what to think about the automatic wet mask clobber you point out -- that looks like it will surprise someone who intentionally left water on the boundary.

[axch]

For reference, the erstwhile sinusoidal and stochastic wind forcing features can come back as input generation helpers.

[axch]

A fairly general class of helper is "Give me a function that computes this field at arbitrary points, and the resolution of your simulation, and I will construct the correct input field (by sampling your function)." This should be directly useful for simulating idealized conditions, where the inputs are representable by simple mathematical curves. This interface can also cover the use case "Here's a map, which is discretized differently than my simulation resolution; please interpolate."