[MITgcm-support] Floating point overflows in gad_os7mp_adv_r

[Christopher L. Wolfe]

Martin, Constantinos,

Thank you both for the advice.

Martin,

> Incidentally, I use this scheme for very high resolution grid and  
> also for coarse resolution grid, and so far there haven't been any  
> problems at all. Why, in your opinion, do you get the overflows and  
> I (and others) don't?

The only reason I can think of is that these overflows need very  
specific conditions to occur and these conditions have a very low  
probability of occurring when the model is initialized using  
"reasonable" conditions. To give you an idea of how rare these events  
are: I have four nearly identical simulations that have been running  
for millions of steps with no problem. Then I got an overflow in *one*  
simulation near time step 7020000. Modifying the code by replacing the  
instances of abs(X + Eps) with abs(X) + Eps got this simulation past  
the overflow and the output fields look very reasonable. The other  
three simulations are still running with the original code and are  
having no problem.

While rare, the conditions which would cause an overflow are quite  
physically reasonable. All it takes is two neighboring tracer cells  
whose values differ by Eps and the velocity pointed the correct  
direction and, bam, overflow.

Christopher


On May 21, 2008, at 1:32 AM, Martin Losch wrote:

> Christopher,
> since no-one competent is answering ...
>
> as far as I can see the "+Eps" is only supposed to avoid a division  
> by zero. I assume that this "technique" is carried over to some  
> extent from, say gad_dst3fl_adv_, where there  is no "abs".
> So my assumption is that you can even replace all instances of abs(Y 
> +eps)/abs(X+eps) by (abs(Y)+eps)/(abs(X)+eps) and the algorithm  
> should work, but it's up to you to prove it (to yourself). And if it  
> works we should consider changing it in the code for everyone, so I  
> am curious about your experience. The fact that this scheme is not  
> really really documented (e.g. you need a overlap of 4 for it to  
> work), tells you that this scheme is not fully established.
>
> Incidentally, I use this scheme for very high resolution grid and  
> also for coarse resolution grid, and so far there haven't been any  
> problems at all. Why, in your opinion, do you get the overflows and  
> I (and others) don't?
>
> Martin
>
> On 21 May 2008, at 00:02, Christopher L. Wolfe wrote:
>
>>
>> Well, replacing all the instances of division by abs(X + Eps) with  
>> division by abs(X) + Eps in gad_os7mp_adv_? caused the overflows to  
>> stop. However, since I don't know that much about the algorithm, I  
>> don't know if this change will have a detrimental effect on the  
>> algorithm. Anyone knowledgeable care to comment?
>>
>> Thanks,
>> Christopher
>>
>> -----------------------------------------------------------
>> Dr. Christopher L. Wolfe                   858-534-4560
>> Physical Oceanography Research Division    OAR 357
>> Scripps Institution of Oceanography, UCSD  clwolfe at ucsd.edu
>> -----------------------------------------------------------
>>
>>
>>
>> On May 19, 2008, at 6:45 PM, Christopher L. Wolfe wrote:
>>
>>>
>>> Hi all,
>>>
>>> I'm getting floating point overflows in gad_os7mp_adv_r. I haven't  
>>> pinned it down to the exact line that's causing it yet, but I've  
>>> found several places where there's division by arbitrarily small  
>>> quantities and I was wondering if someone familiar with the OS7MP  
>>> algorithm could comment on it (or point me to a detailed  
>>> exposition of the algorithm). Anyway, on lines 154, 157, and 182  
>>> there's division by abs(DelIp + Eps), where DelIp = ( Qip - Qi ) *  
>>> MskI. DelIp does not appear to be guaranteed non-negative, so  
>>> abs(DelIp + Eps) can be made arbitrarily small. There's similar  
>>> division by abs(X + Eps) (where X is some possibly negative  
>>> quantity on lines 181 and 183.
>>>
>>> My question is this: Would it be a good idea to replace the  
>>> instances of abs(X + Eps) with abs(X) + Eps, or would that totally  
>>> screw up the algorithm?
>>>
>>> Thanks,
>>> Christopher
>>>
>>> -----------------------------------------------------------
>>> Dr. Christopher L. Wolfe                   858-534-4560
>>> Physical Oceanography Research Division    OAR 357
>>> Scripps Institution of Oceanography, UCSD  clwolfe at ucsd.edu
>>> -----------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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