[MITgcm-support] mnc output

chris hill cnh at mit.edu
Thu Jan 26 13:38:04 EST 2006


Hi Martin,

  I don't think there is a precision problem.
  Attached is a test program with Yossis numbers.
  It seems to work as expected (as long as everything stays in 64-bit 
values). Are we missing something?

Chris

P.S. We tested here with g77 and ifort.

Martin Losch wrote:
> Hi Yossi,
> 
> I may be wrong about this, but I think that the fact that by increasing 
> the time step by a factor of 10 the problem goes away is another piece 
> of evidence that my guess is not so bad. I have not fully understood, 
> how the routine different_multiple works, but is evaluates differences 
> between myTime (huge number) and deltaTclock (relatively small number). 
> Now you have increased deltaTclock by one order of magnitude. If you run 
> your experiment for 200kys with the longer time step, you'll have the 
> same problem as before, I am pretty sure. I can't see why the absolute 
> number of timesteps should matter, but the relative size between myTime 
> and deltaTclock.
> 
> Have you tried enforcing ieee arithmetics? with the pgf77 the option is 
> -Kieee
> 
> Martin
> On Jan 26, 2006, at 7:10 AM, Yosef Ashkenazy wrote:
> 
>> 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
>>>
>>
>> _______________________________________________
>> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diffm.F
Type: text/x-fortran
Size: 2719 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20060126/b4b533e9/attachment.bin>


More information about the MITgcm-support mailing list