[MITgcm-devel] REAL4_IS_SLOW is broken

[Jean-Michel Campin]

Hi Martin,

Congratulation for getting on board to fight with this _RL / _RS stuff.

I have 2 comments:
1) lot of recent pieces of code are all in _RL (but some parts might
work as well with _RS with undef READ4_IS_SLOW). It's tricky
to figure out which part always needs real*8 and which part does not.
And in addition, assuming 1 piece of code works well with real*4,
if this part is not so important for the full model speed, we could
decide to keep it in _RL . In summary, not easy to push forward.
2) regarding what is there now:
- pkg/diagnostics: will see if something easy can be done.
- would be good to test this #undef READ4_IS_SLOW ;
  I would try it on 1 or 2 experiments; which one ? I would avoid
  the tutorials and also the one which are the only test for something
  we care about (e.g., lab_sea, global_ocean.cs). What about
  natl_box ? dome ? adjustment.cs-32x32x1 (or an other one to test
  CS-grid) ?

Cheers,
Jean-Michel

On Sat, Oct 25, 2008 at 08:59:56PM +0200, Martin Losch wrote:
> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel