Revisions to time-varying MITgcm file

[gmacgilchrist]

@Maddie-Sh, I was taking a look at the time-varying forcing documentation and had a few suggestions that it would be good to address.

1. In general, it is a bit verbose and would be helpful to strip down so that someone new to it can quickly navigate and discern what they need to do.
2. Clearer links to existing documentation should be highlighted at the start of the article. I know that very little exists, but nevertheless, pointing to what is there is important. You can also point to any discussions that you've had on the MITgcm-support email list (which should exist in perpetuity).
3. Remove reference to specific files and runs (unless you intend to include the code somewhere on the wiki). Or, indeed, you could link to a zenodo or gihub repo that includes a simple "time varying forcing" example with all of the relevant scripts and files for running it. (Only do this if it would be straightforward).
4. If you've not done something, e.g. cyclical forcing, you should not try to document it fully, or at least relegate the documentation to later in the page. A short section highlighting that this should be possible, after describing what you know to be possible, would be appropriate.
5. In general, avoid speaking about things in ambiguous terms, for example "It is unclear whether this timePhase parameter should also be used for non-snapshot". Try to be clear about things that you know (and write the documentation with confidence about what will work) and flag any absolutely necessary caveats where appropriate.
6. Identifying the bug that you've found (with the requirement to set a time series that excedes the length of the run) is important, but you should do it only once (currently you reference it several times through the document), at the most relevant place, and as a subset of the main thread of the discussion (rather than a major component). Ultimately, you want to give just enough information for someone to be able to either hack past the issue, or pick up the effort to try to solve it (for example with a link to any place where the issue has been raised, eg on Github). One way to think of this is ensuring that, if/when the bug is fixed, it would be easy to cut out a section of this document so that noone has to think of it again.

General

• Include code scripting (text placed between two backward apostrophes ``)
• Keep your titles/headers short and clear
• Make sure headers follow logical ordering with the document title having one # and subheadings proceeding with ##, ###, etc.