No subject


Tue May 11 10:12:20 EDT 2010


exactly the same way you use to do, and it will do the same things.

I just added a warning if using "testreport -noieee"
to suggest to use instead the new option: "testreport -fast".

And ignoring "-ieee" option (which is the default anyway) only
had an effect if someone was trying "testreport -noieee -ieee"
(in this case, -ieee in 2nd position use to cancel the -noieee effect)
but now it's completely ignored and in this particular case,
it will now keep the "-noieee" effect.

Cheers,
Jean-Michel

On Tue, Jun 28, 2011 at 09:27:24AM +0200, Martin Losch wrote:
> Hi Jean-Michel,
> 
> one particular non-expert user glances through this email and wonders if he needs to change his daily/weekly scripts/build-options files. What do you suggest?
> 
> Martin
> 
> On Jun 27, 2011, at 8:50 PM, Jean-Michel Campin wrote:
> 
> > Hi,
> > 
> > I made some minor changes in testreport, replacing '-noieee' option 
> > with '-fast' (it still accepts '-noieee' but give a warning).
> > Also added option '-devel' and ignore -ieee option (since it's the 
> > default anyway).
> > 
> > In optfiles which are tested daily, the -ieee flags involve also
> > a lower optimisation in order to keep the results as close as
> > possible to the reference output (and I checked recently that, indeed,
> > with gfortran and ifort, if I switch to -O2 instead of -O0 
> > but keeping the same IEEE setting, a small number of experiments 
> > drift away from the standard output). 
> > But for a non-expert user, the main difference between using
> > -ieee or not, is the difference in optimisation, making the
> > 2nd executable running much faster that the 1rst one.
> > 
> > I think that the new names "testreport -fast" and ".fast" suffix
> > on the testing web page are easier to guess what it means and also 
> > closer to what it is really.
> > 
> > Anyway, it would not be a big deal to switch back to -noieee if 
> > this is found to be a bad move (I would still keep the addition of
> > -devel anyway).
> > 
> > Cheers,
> > 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



More information about the MITgcm-devel mailing list