[MITgcm-devel] alpha et omega

[Patrick Heimbach]

Martin,

ifort option could be '-check uninit'

When I introduced the init's for AD,
I was told they are benign in forward, so should bracket
within ALLOW_AUTODIFF_TAMC to keep code efficient.
If that's correct, it might explain why specific compiler
options didn't catch the problem(?)

-p.



On Nov 23, 2006, at 4:47 AM, <Martin.Losch at awi.de> wrote:

> Hi Jean-Michel,
>
> I will also change/introduce the inititalisation of all variables  
> viscAh_*/viscA4_* in mom_calc_visc.F
> There the same problem applies. These variables are either local to  
> mom_calc_visc or are passed from mom_fluxform/
> vecinv  (viscAh_D(i,j), viscAh_Z(i,j), viscA4_D(i,j), viscA4_Z 
> (i,j) ) where they are not properly initialized, either.
>
> would something like this do the job for regular testing:
> g77 -fzeros (does not seem to work for me, unfortunately)
> SunOS: f77/f90 -xcheck=init_local (did not catch the particular  
> problem with viscAh/4 for the MLAdjust experiment)
> I couldn't find a flag for the ifort or pgi compilers that sets  
> uninitialized variables to something that would cause floating
> point exceptions.
>
> Martin
>
> Martin Losch
> Alfred Wegener Institute
> Postfach 120161, 27515 Bremerhaven, Germany;
> Tel./Fax: ++49(0471)4831-1872/1797
>
>
>
> ----- Original Message -----
> From: Jean-Michel Campin <jmc at ocean.mit.edu>
> Date: Wednesday, November 22, 2006 10:08 pm
> Subject: Re: [MITgcm-devel] alpha et omega
>
>> Hi Martin,
>>
>> On Wed, Nov 22, 2006 at 07:39:41PM +0200, Martin.Losch at awi.de wrote:
>>> Thanks Chris,
>>>
>>> that was the problem: strain,vort3,shear, and all viscA-type
>> fields are not initialised properly. Only for TAF they are. I
>>> should have thought about that myself. When I make sure that all
>> fields are initially zero, then it works. Why is this not
>>> done in the first place? Should we change the code to do that
>> (basically remove the corresponding
>>> ALLOW_AUTODIFF_TAMC)? (but not today, this problem has sucked
>> everything out of me, and I will only produce
>>> errors, if I try to do that)
>>>
>>> M.
>>
>> 2 things:
>> a) threre is no truly "first place" (e.g., mom_calc_relvort3.F was
>> used only for coriolis/advection, and later, also used for viscosity)
>> and it's hard to find all non-initialized values just by looking to
>> the code (and to be clear, those values have no impact at all
>> on the solution).
>> Some rules would help (e.g., ``S/R with output field in argument
>> list
>> should set the field every-where'', like in mom_calc_hfacz), but
>> rules tend not to be followed/not survive very long.
>> Could get an idea with what is needed for AUTODIFF_TAMC,
>> but ends up initializing variable several times (and I don't like
>> to
>> do things 2 times, not the most efficient, and messy to understand).
>> b) the best strategy is to test the code on 1 platform that does not
>> initialize automatically (or with undef). I remember that I did some
>> test on such a platform a while ago (with Constantinos' help), but
>> it needs to be done regularly to check all the newly added pieces.
>>
>> Jean-Michel
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20061123/566c7620/attachment.htm>