[MITgcm-support] MNC oddities on Cray T3E

Ed Hill ed at eh3.com
Thu Mar 29 23:07:13 EDT 2007


On Fri, 30 Mar 2007 Mark Hadfield <m.hadfield at niwa.co.nz> wrote:
> 
> Thanks to Ed Hill and Constantinos Evangelinos for their responses 
> (though I am a little hurt by Ed's dissing of our T3E).
>
> I take Constantinos' point about the desirability of doing type 
> conversions explicitly. Also, I have realised since posting the
> original message that MNC_CW_RL_W_OFFSET includes some code to handle
> missing values and that presumably should be type sensitive.
> 
> However on further reflection I think that there is one (and only
> one) correct & robust way to declare the variables to be passed to
> the NF_PUT_* functions and that is to match the declarations of those 
> functions in the netCDF library, eg:
> 
>       DOUBLEPRECISION  resh_d( MNC_MAX_BUFF )
>       REAL  resh_r( MNC_MAX_BUFF )
>       INTEGER resh_i( MNC_MAX_BUFF )
> 
> This avoids the need to worry about whether REAL is REAL*4 or REAL*8, 
> etc and avoids the need for #ifdefs. It still means that we might be 
> passing 8-byte reals into a netCDF function that will write them to a 
> netCDF FLOAT variable, but that is unavoidable.
> 
> Constantinos suggested I could use the preprocessor to #define REAL*4
> to REAL*8. I think this would break the ability to read 32-bit data
> via MDSIO. There's also the mismatch between Fortran
> case-insensitivity and cpp case-sensitivity.
> 
> RE the possibility of rebuilding the netCDF library on the Cray T3E
> to make 32-bit the default  precision, I did manage to do this, but
> it involves changing 8 or so files and there are still some rough
> edges. (The problem is not with the real numbers but with the
> integers, as a Fortran INTEGER now matches a C short, a possibility
> that the netCDF build system has not considered.) So I think this is
> a second-best solution.


Hi Mark,

Its been a while since I wrote those lines and my memory is less than
perfect.  I can't think of any really good arguments against what you
propose.

Perhaps the safest thing to do is to add a define such as:

#ifdef MNC_USE_OLD_TYPE_CONV
      REAL*8  dval, dvm(2)
      REAL*4  rval, rvm(2)
      INTEGER ival, ivm(2), irv
      REAL*8  resh_d( MNC_MAX_BUFF )
      REAL*4  resh_r( MNC_MAX_BUFF )
      INTEGER resh_i( MNC_MAX_BUFF )
#else
      DOUBLEPRECISION dval, dvm(2)
      REAL            rval, rvm(2)
      INTEGER         ival, ivm(2), irv
      DOUBLEPRECISION resh_d( MNC_MAX_BUFF )
      REAL            resh_r( MNC_MAX_BUFF )
      INTEGER         resh_i( MNC_MAX_BUFF )
#endif

so that its very easy to switch between the current situation and your
suggested change.

Ed


-- 
Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/



More information about the MITgcm-support mailing list