[MITgcm-support] ifort optimization puzzle

[Martin Losch]

Hi Ed,

no it doesn't have anything to do with KPP, at least not directly. I 
can turn that off and use ivdc_kappa (implicit diffusion) for 
convection instead, no difference (the solutions change, of course, but 
the conservation properties for temp are good with g77 and *clearly* 
wrong with ifort), however, you are right, about the precision and the 
_d business:
although the mean temperature remains constant with ifort -O0, the 
solution is still much different from the solution with g77. That 
effect actually goes away, when I don't use KPP.

I noticed something even weirder: The behavior goes away, when I use a 
LINEAR equation of state (instead of MDJWF or JMD95Z, JMD95P), the 
problem goes away. I haven't tried POLY3 because I haven't produced a 
set of coefficients for that, but that will probably work to.

So, what do I do now? I have recompile find_rho with -O0 (the rest with 
-O1) and everything looks OK, but maybe I can find out what type of 
statement produces the problem and replace it by something more stable. 
Does anyone know offhand the compiler directives for ifort that make 
the compile vectorize or not vectorize specifice loops?

Martin


On Mar 8, 2005, at 8:24 PM, Ed Hill wrote:

> On Tue, 2005-03-08 at 08:47 +0100, Martin Losch wrote:
>>
>> together with Michael Schodlok I have set up a 1D experiment: 1 column
>> of water (nx=ny=1, overlap=2, nr=30, dz=30*10). We specify zero net
>> surface heat flux (qnet = 0), but -50W/m^2 shortwave heat flux 
>> (warming
>> due to the sun), in order to drive kpp. This works all very nicely and
>> we were happy, the mean temperature was constant, as it should (why
>> didn't we stop there?). Then I suggested to move to a faster machine
>> (from a $%^&* SUN to a nice linux-box with ifort). We used the 
>> standard
>> ifort build-options file with paths to netcdf appended. But suddenly
>> the system was losing heat at 1200W/m^2. Turning off optimization 
>> (-O0)
>> or using g77 gave the old results (with constant mean temperature). We
>> clearly have an optimization problem here. How serious do you think
>> this is (I admit that we are using a somewhat pathological
>> configuration)?
>
> Hi Martin,
>
> Jean-Michel has spent a lot of time recently going through the code and
> systematically changing constants such as:
>
>   "2.23" ===> "2.23 _d 0"
>
> and he has found that it really does make different compilers produce
> much more similar results.  And apparently the kpp package is just
> chock-full of examples like the one above--see for yourself.
>
> So, is there any chance that you're being bitten by type conversions in
> kpp -- and that your ifort optimization settings are amplifying the
> effect?
>
> Ed
>
> -- 
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>              Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support