[MITgcm-support] dumpFreq & MNC package

Martin Losch Martin.Losch at awi.de
Mon Jan 22 09:54:35 EST 2007


Hi Laure,

as I said before dumpFreq sets the time interval between "state- 
dumps", You can determine the number of "dumps" like this: INT 
((endtime-starttime)/dumpFreq)+ 1 at the beginning (and 1 at the end  
if endtime-starttime is not a multiple of dumpFreq).

And no, dumpFreq never gets overwritten (unless you are using adjoint  
code, where it is set to 0 at the end of the forward integration).

Things to try:
1. Make sure that you are using exactly the code that you checked out  
(cd MITgcm && cvs diff will show you what you have modified in the  
main code. You'll also need to check in your local code directory).  
If in doubt, check out new code (just MITgcm_code) and retry.
2. turn off the mnc-package. Although it is unlikely that there is a  
problem in that package (useMNC=.false. in data.pkg), turning off  
eliminates a possible source of problems. Also, when you don't use  
the mnc-package, you'll get a file for each variable and snapshot  
with the timestep number, which lets you check at which timesteps you  
get output. (In the mnc-package this is also true, there are  
variables called "iter" and "T" in state.*.nc, which tell you exactly  
when your output was written (in model time))

Martin

On 22 Jan 2007, at 12:26, Laure Grignon wrote:

> Martin,
> I actually get about 41 different snapshots with such a run,  
> instead of the
> 3 I'm meant to have... I've tried again with another data file  
> which I know
> worked fine before, and I got the same problem.
> And the number of snapshots does actually seem to depend on  
> endTime, deltaT
> and dumpFreq. I've also tried setting nTimeSteps instead of  
> endTime, it
> doesn't get any better.
> It seems that the first snapshot corresponds at more or less (!)
> time=dumpFreq, and that it dumps then at each timestep...
> Is that possible that somewhere in the calculations, the dumpFreq  
> parameter
> is reset to another value that would be the timestep...?
> Laure
>
>
> On 19/1/07 18:40, "Martin Losch" <Martin.Losch at awi.de> wrote:
>
>> Laure,
>>
>> I am not quite sure what the problem is, but the name dumpFreq is a
>> bit misleading, it's really the time (in seconds) between "state"-
>> dumps. In your data file, you start at t=0 and end at t=7200. seconds
>> and you produce output at t=0,3600,7200 seconds, independent of you
>> time step.
>>
>> Does that help?
>>
>> Martin
>>
>> On 18 Jan 2007, at 17:19, Laure Grignon wrote:
>>
>>> Hello,
>>>
>>> I'm using the MIT with the MNC package to get a netcdf output. I
>>> appear to have the state generated more frequently than set in my
>>> data file. It is not the case when the same snapshot is written
>>> several times in the state file, because the snapshot is different
>>> at each timestep.
>>> I tried setting dumpFreq to different values, and always get the
>>> same problem, even for very short runs. I've checked on the screen
>>> output that dumpFreq is actually read as set in the data file, and
>>> it is (not only when the data file is first read, but also later
>>> when all the parameters of the model are displayed with their
>>> values, even the ones not in the data file).
>>>
>>> I also tried changing the timestep: no difference. The frequency at
>>> which the snapshots are written is not even proportional to the
>>> number of timesteps. (which rules out any confusion with the pickup
>>> files frequency)
>>> Although, when I set dumpFreq to 0, only the initial and final
>>> states are written, as it should be.
>>> The most surprising is that I managed to make it run properly
>>> before, with some slight changes in the data file.
>>>
>>> Does anybody have any idea on where that might come from? Is there
>>> a parameter I have neglected/ haven't set properly? Here is part of
>>> my data file:
>>>
>>> # Time stepping parameters
>>>  &PARM03
>>>  nIter0=0,
>>>  startTime=0.0,
>>> # nTimeSteps=5040,
>>>  endTime=7200,
>>>  deltaT=120,
>>>  abEps=0.1,
>>> # create a pickup file each day
>>> # pChkpt: *permanent pickup file
>>>  pChkptFreq=86400.0,
>>> #alternating pickup file: each 1/6th day:
>>>  chkptFreq=14400.0,
>>>  dumpFreq=3600,
>>>  monitorFreq=0,
>>>  cAdjFreq=-1,
>>>  periodicExternalForcing=.TRUE.,
>>>  externForcingPeriod=86400,
>>>  externForcingCycle=10454400,
>>>  &
>>>
>>>
>>> Thanks for your help!
>>> Laure
>>>
>>>
>>>
>>> ***************************************************
>>> Laure Grignon
>>> PhD: Observing the ocean using sub-sea gliders
>>> Ocean Observation and Climate (566/13)
>>> School of Ocean and Earth Sciences
>>> National Oceanography Centre, Southampton
>>> University of Southampton, Waterfront Campus
>>> European Way
>>> Southampton
>>> SO14 3ZH
>>> United Kingdom
>>>
>>> Tel: +44 (0) 23 8059 9219
>>> lg804 at noc.soton.ac.uk
>>>
>>> ***************************************************
>>> National Oceanography Centre, Southampton: http:// 
>>> www.noc.soton.ac.uk
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list