Subject: Re: ccm single precision: Not recommended
From: Peter Paul Smolka (smolka@uni-muenster.de)
Date: Sat Oct 23 1999 - 12:29:32 MDT
On Fri, 22 Oct 1999, Ghan, Steven J wrote:
> Date: Fri, 22 Oct 1999 15:16:12 -0700
> From: "Ghan, Steven J" <Steve.Ghan@pnl.gov>
> To: CCM Mail Group <ccm-users@ncar.UCAR.EDU>
> Cc: "Ghan, Steven J" <Steve.Ghan@pnl.gov>
> Subject: ccm single precision
>
> I am in the process of coupling CCM3 with a global chemistry model, and would
> like to run with single-precision to reduce the memory load involved with
>
(....)
> simulation from a double-precision simulation), and if they could share how they
> did it. I'd prefer not to go through the same process of identifying the
> necessary mods if someone already has done it.
>
> -Steve Ghan
>
Dear Steve,
before I made an NT version I worked on porting ccm3.2 to OS/2
(just because I have a compiler that finds undefined variables
at EXECUTION(!) time).
In short: Don t move to single precision.
There are several reasons:
1) If you do so you will find that even some of the variables
that are written out during the initialization phase will
get significantly different results, even such that the model
stops (controlled error exit).
2) If you go slowly through the code, the documentation of
the physics of the ccm3.2 handbook AND the nature of the way
how many eqs are solved (iteratively etc.) changes of the
precision (see the impact of machine epsilon, just set it "by hand"
to some 1.E-07 and see what happens) will have a very negative effect.
I personally do think that it might be an idea (if somebody has the time)
to apply a symbolic equation solving system to SOME(italic) of
the eqs to optimize for example for time etc
(thus eliminating the iterations and thus eliminating also the
impact of precision).
3) Undefined variables etc.: A hint from Dr. Kluszek, NCAR showed
that the results of new versions are tested against results
that are not only intelligable but also comparable regarding
the numeric values. As from the complexity ccm3.6 is comparable
to a large 3D groundwater model even the elimination of undefined vars.
(changing the code) may have bad effects as other things need to be
changed subsequently.
Just see the short "upper deck" of the 747: Removal or extension
of the upper deck
reduces the upward force of the body of the plane significantly,
the upward force of the large tailwing becomes too big, needs also
reduction so overall even the "correction" to a normal behaviour
of a plane (uplift by the wings) has in this case a negative effect.
In short: ccm3.6 IS a proven way to describe and model climate
(including Pliocene and Miocene paleoclimate). The measure of
correctness is an evaluation of the results, not of compiler/linker
and other phenomena. Thus changing this delicate equilibrium is
something that should be done with care (or avoided).
In principle a direct handling of the arrays (allocating them
explicitly, passing them explicitely and thus avoiding the
large buffers may be a way to cut down storage by a factor of 0.7.
I embarked on that for the OS/2 version but then I got a nice
offer from Dell for a Pentium with 256 MB RAM... (with NT).
4) If you ARE(italic) able to run ccm3.6 on your platform and
your concern is the interference with your chemistry model maybe
you could pass the arguments you need (in REAL*8) to one of
your(italic) subroutines, assign them where needed to
REAL*4 "chemistry" arrays and pass, where appropriate only the result
back as REAL*8. As conversion takes place automatically this shall
work IF your "chemistry eqs." permit this.
(= NOT using the common blocks, but exactly the arrays you need,
which is normally much less than the whole common blocks).
Introducing such "mirror" arrays of lets say NLEV*PLON or so should
not be that much if per step only THOSE vars are transferred that are
actually needed.
>
Best regards, Peter
**********************************************************************
Dr. Peter P. Smolka **
University Muenster **
Geological Institute **
Corrensstr. 24 **
D-48149 Muenster **
**
Tel.: +49/251/833-3989 +49/2533/4401 **
Fax: +49/251/833-3968 +49/2533/4401 **
E-Mail: smolka@uni-muenster.de **
E-Mail: PSmolka@T-Online.de
**********************************************************************
This archive was generated by hypermail 2b27 : Thu Jun 01 2000 - 09:28:47 MDT