Why do different results come from the same CCM3 code with d

[sunxg007@yahoo_com_cn]

Why do different results come from the same CCM3 code with different platform?


I've found a strange thing recently, i.e., the model
results are quite different with the same both CCM3
code and data set running in different SGI platform,
one is on origin300, and the other is one sgi3800.
I wonder where these conflications come
from. Can anybody help me? Thanks in advance.

 

[pjr]

Why do different results come from the same CCM3 code with different platform?


I've found a strange thing recently, i.e., the model
results are quite different with the same both CCM3
code and data set running in different SGI platform,
one is on origin300, and the other is one sgi3800.
I wonder where these conflications come
from. Can anybody help me? Thanks in advance.

You need to tell us a little more. Do you mean that the climate is different, or that two solutions are diverging after a few days when run on the two platforms?

At some point or another we will need to make an FAQ entry on criteria useful in determining whether two long climate simulations are different. For the moment, I will just say that it is almost impossible to state definitively that two simulations are different if you are comparing averages of runs of less than 5 years duration.

If your question is about simulations which differ after a few days then the answer is that it is quite likely that:

1) you are running with two different versions of the compiler

2) the compiler flags (which are frequently hidden from the user) are different for the two platforms.

The result of these items are that the model simulations will differ at roundoff after the first time step. From then on you will see the simulation differences grow in time according to the classic solution differences seen in weather prediction and chaos theory.

Phil

 

[eaton]

When we port CAM to a new platform (could be a different machine, or the
same machine with new OS or compiler versions) one of the first validation
tests we run checks that the simulation on the new platform is "within
roundoff" of the simulation on a previously validated platform. This
procedure is described at
http://www.ccsm.ucar.edu/models/atm-cam/port/pergro-test.html and is based
on the methods described in the paper of Rosinski and Williamson (the
reference for that paper is contained in the web page). The details are
given for the CAM3 build/run procedure. This procedure can be carried out
in CCM3.6.6 (the original work was done in CCM2), but some modifications
are necessary. Here are the modifications I can remember:

1. A special configuration of the model is used for perturbation growth
testing. In CAM this is a build time option which is specified by using
the -pergro option with configure. In CCM-3.6.6 the option is runtime and
is specified using the pergro namelist variable in the CLM namelist.

2. The output history files are set up to only contain the variable T and
PS. CCM didn't have the 'empty_htapes' namelist variable, so there was no
easy way to start from an empty history file and just add the fields you
need using 'fincl'. In CCM the way to do this (other than by hacking
source code) is to use the 'exclude' namelist variable to remove the
unneeded fields from the primary history file.

If you like hacking code, the easy way to eliminate all the default
fields on the primary history file is by changing the variable 'active'
from 1 to 0 at line 181 of bldfld.F.

3. Postprocessing the CCM history files is probably best done by converting
them to netCDF using the ccm2nc utility,
http://www.cgd.ucar.edu/cms/ccm3/tools/hUtils-1.5.5.tar.gz
and then obtaining the cprnc utility from a CAM distribution.

4. CCM3.6.6 did not have an aqua_planet option, and this is not required
for perturburbation growth testing in that model version.

I haven't tried this so there is probably some detail missing. But this
should be close.

Brian

 

[oyvind_seland@geo_uio_no]

One possible reason for the differences you may see when only changing
compiler versions is that different versions treat a number of non-standard fortran 77 statements differently. I had to replace a number of amax and amin within the standard ccm3 code with max and min since
the new compiler version only used amax and amin as real*4 instead of real*8 as it should be.


Øyvind Seland