[MITgcm-support] mnc output

[Yosef Ashkenazy]

Hi Martin,

I ran the simulation without optimization (i.e., without the -O3 
option...) for the eesupp/src/different_multiple.F routine and got the 
same results. Thus I'm not sure that the problem is related to the 
myTime variable.
In addition, when I used time step that is 10 times larger than the 
original one I didn't observe this problem. So, maybe the problem is 
related to the actual number of time steps rather than the time in seconds.

Yours,

Yossi

mlosch at awi-bremerhaven.de wrote:

>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
>>
>>    
>>
>
>_______________________________________________
>MITgcm-support mailing list
>MITgcm-support at mitgcm.org
>http://mitgcm.org/mailman/listinfo/mitgcm-support
>  
>