[MITgcm-devel] refining debugLevel choices

[Menemenlis, Dimitris (3248)]

Jean Michel What you suggest sounds reasonable.

Dimitris Menemenlis
818-625-6498

On May 21, 2011, at 9:22 AM, "Jean-Michel Campin" <jmc at ocean.mit.edu> wrote:

> Hi,
> 
> I talked about adding a new parameter to refine the choice of
> messages to print to STDOUT, but when I looked to different printed
> messages, seems little bit arbitrary which one to switch to condition on 
> the new parameter and which one to keep with debugLevel. So I changed 
> my mind and propose instead to extend the choices related to debuLevel:
> 
> Would add 2 more levels: debLevC,debLevD= 3,4
> (presently we have 0,1,2 =debLevZero,debLevA,debLevB)
> and change the code so that:
> printed msg with present debuLevel=1  <-> new debuLevel=2
> printed msg with present debuLevel=2  <-> new debuLevel=4
> And new debuLevel=1 will be less printed msg than new debuLevel=2 (present debuLevel=1)
>  (in particular, no MDSIO file opening msg at debuLevel=1)
> And new debuLevel=3 will be less printed msg than new debuLevel=4 (present debuLevel=2)
>  (in particular, no debug-stats of all state vars at debuLevel=3)
> 
> debugMode=T would switch new debuLevel to 3 (instead of new 4)
> and the default value for debuLevel would be debLevB ;
> can also change the default to debLevA for adjoint run (with #ifdef 
> ALLOW_AUTODIFF_TAMC) to avoid printing messages each time MDSIO open 
> a file in read mode.
> 
> The changes in the code don't look too bad (and if I miss one, 
> it's not going to break the code) and if one user forgot to
> make the corresponding changes in his parameter file "data", 
> it will just result in less printed messages (not too bad).
> 
> Do you agree with those changes ? other suggestions ?
> 
> Thanks,
> Jean-Michel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel