[MITgcm-devel] fixing REAL4_IS_SLOW

[Martin Losch]

Hi Jean-Michel,

testing: I was only thinking of testing whether the model compiles  
and runs at all (which was not the case before my fixes last week),  
matching of results can only be expected to be on the order of 6-7  
digits (single precision) in cg2d. In the current tests we only check  
the dynamical core of the code. Such a (global) test would only catch  
case, which completely break the code (such as the fixes that were  
put into CPP_EEMACROS.h, that broke the flag in the past). But maybe  
such a test is really no necessary.

monitor: should I change that? won't have time in the next week. it  
involves a few more things, because of grid statistics, etc. Maybe it  
is best to remove the FFIELDS monitor altogether if REAL4_IS_SLOW is  
undefined for you, please do it if you think so. I will not look into  
this for at least a week or so, but then, if you feel it's necessary,  
I can takle this.

Martin
On 31 Oct 2008, at 17:04, Jean-Michel Campin wrote:

> Hi Martin,
>
> Just to end this story:
> I think it's better to test only few selected exp.
> (like what we have now) with #undef REAL4_IS_SLOW flag :
> With ifort on faulks (and also on few other platforms),
> we only get few digits of matching for cg2d, for solid-body.cs
> which means that if something (important to check) was sligtly
> broken, we would not be able to tell.
> Funny enough, on my laptop (x86_64), ifort (v.10) gives
> a good matching. Hard to know why it's different from faulks.
>
> Do you plan to change the mon_printstats_rs.F/mon_stats_rs.F
> thing ? The way it is now could be misleading, since
> the surf.forcing monitor is really different when REAL4_IS_SLOW
> is turn off (no area, no masking are accounted for).
> In this case and for those fields, I would even prefer no monitor
> rather than a different (and somehow wrong) one.
>
> Cheers,
> Jean-Michel
>
> On Mon, Oct 27, 2008 at 07:28:34AM +0200, Martin Losch wrote:
>> Hi Jean-Michel,
>>
>> checked in, yes CPP_EEOPTIONS.h was no different, just for the test
>> summary that I sent in the last email I undefined REAL4_IS_SLOW and
>> changed it back afterwards.
>>
>> verification: solid-body and inverted_barometer are good choices; the
>> inverted_barometer is such a superfluous experiment, just testing the
>> ATMOSPHERIC_LOADING flag, that is long used in other experiments as
>> well. With this REAL4_IS_SLOW flag it will have some meaning. On the
>> other hand it just tests the basic gfd, maybe add some diagnostics  
>> (and
>> mnc of course)?
>>
>> I was also thinking of having a dedicated test where everything is
>> tested like this:
>>>> cvs co MITgcm
>>>> run ./script_that_modifies eesupp/inc/CPP_EEMACROS.h (to set #undef
>> REAL4_IS_SLOW, or maybe that can be overriden with a - 
>> UREAL4_IS_SLOW in a
>> build_options file, I haven't tried that yet?)
>>>> run ./testreport
>> just to see if compilation and execution of code work, because  
>> that was
>> definitely broken; this test will not, of course, test the  
>> accuracy. What
>> do you think?
>>
>> Martin
>>
>> On 27 Oct 2008, at 02:13, Jean-Michel Campin wrote:
>>
>>>
>>> Martin,
>>>
>>> looked at those 2 files:
>>>  CPP_EEMACROS.h and CPP_EEOPTIONS.h
>>> from your faulks/scratch */eesupp/inc dir
>>> and you should check-in CPP_EEMACROS.h
>>> (CPP_EEOPTIONS.h has not changed, right ?)
>>>
>>> And I started to test this on:
>>>   solid-body.cs-32x32x1
>>> + inverted_barometer (Not yet added mnc)
>>> with g77, gfortran & ifort (on my laptop) and seems to work.
>>> get all 16 identical digits between the 3 compilers, for both exp.
>>> I also tried natl_box (with mnc), it runs with g77 but I am getting
>>> floating exception / floating invalid with gfortran / ifort
>>> (wscale_ in kpp_routines.f).
>>>
>>> I can try pgf once we've decided which one to switch to _rs=real*4
>>>
>>> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel