[MITgcm-devel] Re: [MITgcm-support] diagnostics at last timestep

[Jean-Michel Campin]

Hi Martin,

 ...
> every 12h of a 48h integration (where I don't care too much if the
> snapshots are really at 12h or 12h+/-deltaT, but I'd like to have
> them the appropriated iteration number),
 ...
> From your explanation I gather, that setting
>   frequency(15) = -43200.,
>   timePhase(15) = -6., (=-deltaT)
>   fields(1,15) = 'WVEL   '
>   filename(15) = 'WSNP',
> will give me WSNP fields at 7200,14400,21600, and 28800. Is that true?
> From my little tests I should think that it would rather be  
> 7199,14399,21599,28799, which is something, I do not want.

You are right. By setting this frequency & phase, you
will get WSNP fields at 7199,14399,21599,28799
but if you don't care about 1 time step shift,
it should be OK, no ?

Now, this iteration issue is not new (and it's not so simple), 
but for state variable, at least it's easier: Seriously,
is it better to have an output file with the "true" iteration
number (7199), or one which is artificially shifted by 1
just to make (at least me) completely confused ?
I did not follow carefully Patrick's suggestion and following
answer, but my impression is that changing from wrITer=myItM1 
to wrITer=myIter in diagnostics_write.F
is equivalent to renaming iteration number 7199 to 7200.

Practically:
They are several way to get the last iteration output
for state variable (setting dumpFreq=0. with the default
dumpInitAndLast=.TRUE. will do it ; reading the pickup file
is an other way. And we could also decide to reduce the number 
of output file at each dumpFreq by moving some of them 
from dumpFreq to diagFreq ?) but it's not available with 
the diagnostics pkg.
However, with pkg diagnostics, 
if this run is to be restart (e.g., from it=28800), setting
frequency=-43200. & phase=0 will write the snap-shot at it=28800.
And if this run is not going to be restart, then the simplest 
thing would be to make the run 1 iteration longer, with
endtime = 172806. & dumpAtLast=F.

And long term plan (but not at the top of my to-do list):
In order to have a true dumpAtLast implementation for 
snap-shot diagnostics, we would need:
1) to add, for each diagnostics, a flag (in gdiag array)
that tells if it's a state variable or not (= flux, tendency,
intermediate state).
2) add a final calls to DIAGNOSTICS_FILL_STATE followed by
a call to DIAGNOSTICS_WRITE in the_model_main.F, to fill
state variable diags (if snap-shot & dumpAtLast).
3) add the right logic for other than state variable
snap-shot & dumpAtLast output.
This might be not only usefull for dumpAtLast of snap-shot,
but also for this delicate issue of iteration number of
snap-shot diagnostics of non-state variable.
Now the tricky part: it could become quiet difficult to 
put, in the same file, state and non state variables 
since they will be associated to a different time & iteration.
Well, does not look like a good plan ...

Cheers,
Jean-Michel

On Fri, Mar 02, 2007 at 02:17:32PM +0100, Martin Losch wrote:
> 
> Martin
>