[MITgcm-support] mnc output

[mlosch at awi-bremerhaven.de]

Hi Yossi and Ed,

withouth having looked at your example, I would guess that at 
20kys you run into precision problems. The model time "myTime" 
is counted in seconds. 20kys are approximately 6e11 seconds.

if the following expression is true:
DIFFERENT_MULTIPLE(dumpFreq,myTime,deltaTClock)
the model writes output.

This is the comment in eesupp/src/different_multiple.F
C     !DESCRIPTION:
C     
*====================================================
======*
C     | LOGICAL FUNCTION DIFFERENT\_MULTIPLE                       
C     | o Checks if a multiple of freq exist
C     |   around val1 +/- step/2
C     
*====================================================
======*
C     | This routine is used for diagnostic and other periodic    
C     | operations. It is very sensitive to arithmetic precision. 
C     | For IEEE conforming arithmetic it works well but for      
C     | cases where short cut arithmetic  is used it may not work 
C     | as expected. To overcome this issue compile this routine  
C     | separately with no optimisation.                          
C     
*====================================================
======*

So maybe, if you try compiling this routine without optimisation, it 
will work for another 20000kys. (when you'll will approach 
machine precision)

However, if this is really the problem and if long integrations like 
that become the rule (and not the exception), we might have to 
consider an option for setting the time units explicitly, e.g, in hours 
wouldl give another 3 orders of magnitude, etc. 

Martin

Martin Losch
Alfred Wegener Institute 
Postfach 120161, 27515 Bremerhaven, Germany; 
Tel./Fax: ++49(0471)4831-1872/1797



----- Original Message -----
From: Yosef Ashkenazy <ashkena at bgu.ac.il>
Date: Wednesday, January 25, 2006 9:04 am
Subject: Re: [MITgcm-support] mnc output

> Hi Ed,
> 
> Thank you very much for your suggestions. Indeed, it is 
possible to 
> break the long run into pieces and to start each time from a 
pickup 
> file. However, since my simulations are really long (~80kyr), it is 
> not 
> so convenient.
> The problem is not related to large memory size since my 
output 
> files 
> are much smaller than 2GB.
> I built a very simple configuration to test this problem; a simple 
> 4x4 
> box with two vertical layers. It turns out that the problem is 
> related 
> to the time step rather than to the actual time of the simulation. 
> Please have a look at this test case :
> http://www.bgu.ac.il/~ashkena/temp/
> You will find there a very short matlab code that demonstrates 
the 
> problem and the entire configuration with the results. I hope we 
> can 
> solve this strange problem.
> 
> Many thanks,
> 
> Yossi
> 
> Ed Hill wrote:
> 
> >On Tue, 2006-01-24 at 09:20 +0200, Yosef Ashkenazy wrote:
> >  
> >
> >>Hi,
> >>
> >>Currently I'm performing long runs of the MITgcm. I'm using 
the 
> mnc 
> >>package. After relatively long time of simulation (~19200 
years) 
> the 
> >>model starts to produce three or four times the same output 
at 
> each 
> >>output point (instead of single output). Do anyone faced this 
> problem 
> >>before ? Any suggestions ?
> >>    
> >>
> >
> >Hi Yossi,
> >
> >I've never seen what you describe.  Thats odd.
> >
> >Could you try the following:
> >
> > - Run the model from a pickup so that the simulation 
> >   time per run is shorter
> >
> > - Are your output files growing close to or perhaps beyond 
> >   2GB in size?  Large files can cause problems with netCDF 
> >   and other libraries if they aren't compiled with the 
> >   proper large-file-support.  There are various settings that 
> >   you can use to decrease the number of time steps saved in 
> >   each file such as:  mnc_max_fsize
> >
> >http://mitgcm.org/r2_web_testing/latest/online_documents/
node254.html
> >
> >If none of the above helps, the best way to track down this 
> problem is
> >to create a scenario that repeatedly triggers the problem.  So if 
all
> >else fails, please create a setup that triggers this problem and 
> then we
> >can (hopefully) have you send it to us and we'll pick it apart.
> >
> >Ed
> >
> >  
> >
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>