[MITgcm-devel] Re: [MITgcm-support] diagnostics at last timestep
Martin Losch
Martin.Losch at awi.de
Fri Mar 2 08:17:32 EST 2007
Hi Andrea,
thanks for the clarification. I am not sure that I understand the
details of the n-1 business, but I am sure that you can explain this
to me in a few weeks.
Let me ask if the following will produce a snapshot at (or near) the
end of the integration. Basically I want time averages and snapshots
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), so I have
in data:
startTime =0.,
endtime = 172800.,
deltaT = 6.,
dumpfreq = 0.,
taveFreq =0.,
dumpInitAndLast = 0.,
to supress all output from the "standard io".
in data.diagnostics I have (among many other things):
dumpAtLast = .true. (although that doesn't make a different for
the time averages either)
frequency(2) = 43200.,
fields(1,2) = 'WVEL',
filename(2) = 'WVEL',
this will give me 12 averages of the vertical velocity every twelve
hours, including the last 12h (36h-48h), iter=7200,14400,21600, and
28800, so far so good. Then I have
frequency(15) = -43200.,
timePhase(15) = 43200.,
fields(1,15) = 'WVEL '
filename(15) = 'WSNP',
This gives me output a iter=43200/(deltaT=6)=7200,14400,21600. I was
expecting to get also output at iter=nIter0+nTimeSteps=28800. If I
set timephase=0. I get out at iter=0 in addition to the above but not
at 28800. 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.
Martin
On 2 Mar 2007, at 13:22, Andrea Molod wrote:
> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list