[MITgcm-devel] REAL4_IS_SLOW is broken
Martin Losch
Martin.Losch at awi.de
Sun Oct 26 16:07:10 EDT 2008
No, not really, what do you consider a large problems (in terms of "size mitgcmuv")?
Martin
----- Original Message -----
From: chris hill <cnh at mit.edu>
Date: Sunday, October 26, 2008 21:56
Subject: Re: [MITgcm-devel] REAL4_IS_SLOW is broken
To: MITgcm-devel at mitgcm.org
> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20081026/9081847b/attachment.htm>
More information about the MITgcm-devel
mailing list