[MITgcm-devel] alpha et omega

[Martin.Losch at awi.de]

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
>