[MITgcm-devel] negative diagnostics freq

[Jean-Michel Campin]

Hi Dimitri and others,

I would like to clarify the issues relative to this "negative frequency"
in diagnostics pkg:

1) diagnostics outputs are different from what regular time-ave &
snap-shot (dumpFreq & diagFreq) give.
tendencies & fluxes <-> at iteration "n" for both
state variables     <-> at the beginning of iteration "n" (you can
                        call it iteration n-1) with diagnostics pkg
                    but at the end of iteration "n" with time-ave &
                        regular snap-shot.
I sent an e-mail to the development list at the beginning of this
year (Jan 02, subject: "names and diagnostics") that was pointing to
the advantages of this convention. Since that time, the instantaneous
(negative freq) diagnostics has been added. The same arguments are
even more relevant for instantaneous output (when I want to check
that the fluxes & tendencies are corrects: I need the model-state
variables at the beginning of the time-step to compute off-line
the fluxes,tendencies; and then I compare them with what the model
did).
Also I don't want to have the instantaneous diagnostics being coded
completely differently from the time-average diagnostics.
And finally, I don't see why we should export the disadvantages
of the time-ave & regular snap-shot to the new diagnostics pkg.

In short, I don't want this part to change.
What might need to change eventually is the file-name (based on
an iteration number, but which one ?) of the diagnostics-pkg
output file, that was not so clear to me.

2) the diagnostics instantaneous outputs are written at the middle
of the time period.
The idea is to make the instantaneous output centered in time to
match the time-average output.
For instance, with a strong seasonal forcing and a |frequency| of 1
month:
freq > 0 : give monthly averages (centered at the middle of the month):
 January, February ...  (by the way, this looks much more "natural"
 to me than the alternative where the time average is centered at
 the end of the month).
freq < 0 : give snap-shots that are centered at the same time, so that
 you don't have to worry about the phase in the seasonal cycle when
 you do comparison.

Since the diagnostics pkg is primarily intended for time-averaged
output (in fact, for snap-shot, the direct output is probably more
efficient, and you don't need space in the qdiag array), this
is the time-average "convention" (as described above) that is
now implemented.

I don't have any problem, if people agree, to change the diagnostics pkg
for instantaneous output, to write them at the end of the time period
instead of at the middle. But I would prefer not to change it back again
later if this "phase synchronization" argument was brought again.

3) The way to solve this half period / full period question is
well known, but not yet implemented.
We just have to add a kind of "phase" in addition to the frequency
(default could be what we have now ? or something else ?).
Personally, I would prefer to have frequency & phase expressed
in seconds rather than iterations (I often have to change
the time-step, do not need to change all the output frequencies
(in s) except those that are in data.diagnostics, and it's not very
convenient) and was waiting for a consensus on this issue before
adding a "phase" to the parameter list (in data.diagnostics).

Jean-Michel