[MITgcm-devel] REAL4_IS_SLOW is broken

[Martin Losch]

Hi again,

the model runs with my modifications and seems to pass the testreport  
(not quite done yet, but I don't see why it should fail for the last  
few experiments) on eddy.csail.mit.edu, however,

both mnc (for grid variables in write_grid.F) and diagnostics,  
regardless of mnc, for the _RS variables (e.g. surface forcing) is  
broken if READ4_IS_SLOW is undefined. As far as I can see, the  
diagnostics package is not set up for the RL/RS and always assumes  
real*8 variables. I can fix write_grid.F and also the monitor of the  
surface fields (requires mon_printstats_rl to be replaced by rs- 
version, not a big deal), but the diagnostics is hopeless I guess.

Should I go ahead and do these changes? If so, what can be done about  
the diagnostics? Issue a warning, if the critical variables are  
active (in data.diagnostics)? I don't know how to do that.

Even if the diagnostics stuff cannot be sorted out, I still think  
that fixing the REAL4_IS_REAL flag  for the rest of the code is a  
good thing, so I would opt to do the changes. What do you think?

Martin

On 25 Oct 2008, at 16:59, Martin Losch wrote:

> Hi Chris,
>
> I think I found the problem: in CPP_EEMACROS.h the expansion of the  
> _EXCH_*RS/4 macros is independent of REAL4_IS_SLOW, that is they  
> always expand into RL like this:
> #define _EXCH_XY_RS(a,b) CALL EXCH_XY_RL ( a, b )
> #define _EXCH_XYZ_RS(a,b) CALL EXCH_XYZ_RL ( a, b )
> #define _EXCH_XY_R4(a,b) CALL EXCH_XY_RL ( a, b )
> #define _EXCH_XYZ_R4(a,b) CALL EXCH_XYZ_RL ( a, b )
>
> I fixed this by putting the into ifdefs and expanding them to _RS  
> in the cae of REAL4_IS_SLOW. That did the trick. I will certainly  
> check, if this breaks the testreports, but in case it doesn't break  
> the tests, can I just check this in (I am asking, because I don't  
> feel too comfortable futzing around in this area; maybe you or  
> anybody else want to have a look at my modifications frist?)
>
> Martin
>
> PS. Should we have a test that checks this functionality, or is it  
> not so important?
>
>
> On 25 Oct 2008, at 07:36, Martin Losch wrote:
>
>> Hi Chris,
>>
>> after our telephone conversation yesterday, I quickly tried #undef  
>> REAL4_IS_SLOW, to see whether this has any effect on the quadcore  
>> performance. It compiles without any problems, but the code stops  
>> at the temperature == 0 test in ini_theta.F, some THETA values are  
>> zero. Actually many values are zero, not only temperature, because  
>> after exchange there are stripes of zeros along the tile edges in  
>> all grid fields (most of them are now real*4, but theta is still  
>> real*8).
>>
>> Now, I did expect this to work right away, but since you and  
>> Dimitris have already gone through using the _RS -> real*4  
>> business, maybe you remember what you did exacty, or maybe this is  
>> documented somewhere?
>>
>> Our domain here at Weizmann is a cartesian grid, so I am NOT using  
>> exch2, as you might have with Dimitris. Do you have any idea,  
>> what's going on? If it's not so complicated to do I am willing to  
>> fix this in the code (never good to have feature that does not  
>> work, right?), otherwise we should include a comment in  
>> CPP_EEOPTIONS.h that this flag REAL4_IS_SLOW always needs to be  
>> defined
>>
>> Martin
>> _______________________________________________
>> 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