[MITgcm-devel] REAL4_IS_SLOW is broken
chris hill
cnh at mit.edu
Sun Oct 26 15:56:04 EDT 2008
Hi Martin,
Have you tried on large probs?
The most impact should come from things that have a large memory
footprint.
Chris
Martin Losch wrote:
> - Unfortunately, I could not see any speed improvement on the machine I
> have available, so maybe the whole stuff is unnecessary, but at least
> the flag should work, otherwise is not worth having it at all.
>
>
> -
>
> ----- Original Message -----
> From: Jean-Michel Campin <jmc at ocean.mit.edu>
> Date: Sunday, October 26, 2008 21:28
> Subject: Re: [MITgcm-devel] REAL4_IS_SLOW is broken
> To: MITgcm-devel at mitgcm.org
>
> > 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
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> Martin Losch
> Alfred Wegener Institute
> Postfach 120161, 27515 Bremerhaven, Germany;
> Tel./Fax: ++49(0471)4831-1872/1797
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list