[MITgcm-support] dumpFreq & MNC package
Laure Grignon
lg804 at noc.soton.ac.uk
Mon Jan 22 06:26:48 EST 2007
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
More information about the MITgcm-support
mailing list