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

[Martin Losch]

Thank Jean-Michel and everyone for the thorough explanation. I  
suppose I can live with all this, I just needed to understand some of  
the issues, which I do now.

Martin
On 2 Mar 2007, at 23:26, Jean-Michel Campin wrote:

> 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
>>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel