[MITgcm-support] ifort optimization puzzle

[Martin Losch]

Ooops, too fast,

this is what I wanted to say:
> I don't see anything in  these loops that should really be a problem, 
> maybe someone with more experience in vektorization can
have a look.

Martin


On Mar 9, 2005, at 11:11 AM, Martin Losch wrote:

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