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

[Andrea Molod]

hi martin,

its late (early?) so please tell me if this is rambling.......

this whole offset stuff for the snap shots is there because of when the
diag is filled, when the state variables are updated and when the model
clock is 'ticked' forward.

when the diagnostic array is filled the clock has been ticked forward but 
all the state variables have not been updated. so some of them have their 
'one timestep ago' values. (i think u and v have been advanced and t and s 
and eta have not....) -

to think about changing this around will make a big mess that will have
to be cleaned and all sorts of experiments and configurations checked out
to make sure they still work. the way it works now seemed best at the
time for many many (many?) reasons. not that it makes anything fixed
in stone.....

so the output you are getting at multiples of 3600 are actually filled
at 3600 + 1 time step, and are 'called' values at the multiple of 3600
because that is what is in the state variable.

now for the end time - when the model says its end time and the diagnostic 
array filling routine is called, we do not know the state variables at 
the end time.

so maybe i can ask you what you want to do? do you want the 
values at 'end time - 1' timestep stuck in there and artificially called 
'end time' values?

if yes, then you can use the phase variable in the
namelist and tell it to do that always, ie, set phase equal to
the negative of your model timestep (NOT -3600). see the code in 
eesupp/src called diff_phase_multiple for this and you can see that
this would work.

if no, then to get the ones 'really' at your end time, your model
clock needs to be at end time + 1 -- extend the run 1 more time step
and leave the phase alone.

hope this is useful and not rambling and not 'too much information'.

andrea


On Fri, 2 Mar 2007, Martin Losch wrote:

> I could also threaten to change these lines in the repository to speed up the 
> responses of the author of diagnostics (o:
>
> But as a matter of a fact this "hack" does not work. Now I get out at the 
> nIter0+nTimesteps-1st time step but not at the last one. I checked 
> diagnostics_write.F again, and there a myItM1=myIter-1,
>> C--     write snap-shot with suffix = myIter-1 to be consistent with
>> C       state-variable time-step:
> If I replace change that (wrITer=myIter and wrTime=myTime  also for freq<0) 
> then I get output for all of my diagnostics at the last timestep (timePhase = 
> 0,3600 and default). I guess that's what I want, but not for the case 
> timePhase = -0.5*frequency (which is the default for snapshots).
> Personally, I could live with this solution, but what does the diagnostics 
> czar say?
>
> Martin
>
> On 1 Mar 2007, at 19:34, Patrick Heimbach wrote:
>
>> 
>> Hi Martin,
>> 
>> I looked at the code diagnostics_write.F
>> and it seems clear that dumpAtLast (which is supposed to do the trick)
>> is only implemented in conjunction with positive frequency,
>> i.e. time-averages.
>> Don't know why that is, and don't see a good reason for it.
>> 
>> If you want to be courageous and test, then change line
>>
>>          IF ( dumpAtLast .AND. myTime.EQ.endTime
>>     &                    .AND. freqSec.GE.0. ) dump2fileNow = .TRUE.
>> 
>> (remove ".AND. freqSec.GE.0."),
>> or wait for the author of diagnostics to reply.
>> 
>> -p.
>> 
>> 
>> 
>> On Mar 1, 2007, at 12:20 PM, Martin Losch wrote:
>> 
>>> Hi there,
>>> 
>>> I can't make the diagnostics package dump a snapshot of a diagnostics 
>>> variable, say UVEL, at the last time step. I have tried all sorts of 
>>> things:
>>> frequency(1) = -3600.,
>>> timePhase(1)= 0.,3600., nothing
>>> dumpAtLast = .true.,
>>> but nothing works and I don't get output for the last timestep (which is 
>>> at a multiple of 3600.sec of course). For time averaged quantities 
>>> (frequency>0) it seems to work.
>>> What have I overlooked?
>>> 
>>> Martin
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>> 
>> ---
>> Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>> MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
>> FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel