[MITgcm-support] ifort optimization puzzle

[Martin Losch]

Hi again,
I found the loops that cause the optimization problem in find_rho. They 
are the inner loops (i-loops) in:
FIND_RHOP0 and FIND_BULKMOD for JMD95P/Z
and in
FIND_RHODEN for MDJWF
These loops are vectorized I can suppress  the optimization of the 
respective loops with CDIR$ NOVECTOR and the problem goes away.
I don't see anything in  these loops that should really be problem, 
maybe someone with more experience in vektorization can

On Mar 9, 2005, at 8:40 AM, Martin Losch wrote:

> 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
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support