CCM1 estabv discussions

CCM Group Directories (ccm@sage.cgd.ucar.edu)
Wed, 6 Jul 94 8:07:01 MDT


From: ccm@sage.cgd.ucar.edu (CCM Group Directories)
Message-Id: <199407061407.IAA03095@grub.cgd.ucar.edu>
Subject: CCM1 estabv discussions
To: ccm-users@ncar.ucar.edu
Date: Wed, 6 Jul 94 8:07:01 MDT

In response to Paul Nutter's 1 July 1994 email message ...

>Question:
> Why does the t42 version not respond to the estabv.mods like
>the r15 version?

we attach the following output from two T42 CCM1 cases. Case (a) was run
with /ccm/ccm1/t42/lrw.mods alone. Case (b) was run with lrw.mods and
estabv.mods together. **In both cases, the entire model was recompiled.**

At timestep zero, the global integrals were as follows:

(a) NSTEP RMSZ RMSD RMST STPS
0 0.883917E-04 0.799398E-05 0.250912E+03 0.984487E+05

STQ STPE STKE STTE
0.229551E+02 0.253616E+10 0.145443E+07 0.253762E+10

(b) NSTEP RMSZ RMSD RMST STPS
NSTEP = 0 0.883917E-04 0.799398E-05 0.250887E+03 0.984487E+05

STQ STPE STKE STTE
0.230490E+02 0.253593E+10 0.145443E+07 0.253738E+10

See RMST, STQ, STPE and STTE for differences introduced by changes to
the estabv routine.

Given these results, we began to look for other explanations to the
ongoing dialogue on incorporating the estabv changes. CCM Core Group
staff examined the CCM1 relocatables (/ccm/ccm1/r15/ccm1reloc1 and
/ccm/ccm1/t42/ccm1reloc2) and determined that they were not created on
the date now associated with the files, 9/24/92. It appears they were
generated in the spring of 1991 (4/22/91 for the T42 relocatable and
3/6/91 for the R15 relocatable), and acquired their current time stamp
when the /ccm file system on shavano was created. Both relocatables
were compiled with CFT77 4.0.05.1, prior to version 5.0.2.15 in which
the code generation problem first surfaced. Therefore, if a user
compiled only the changed code, as shown in the sample generic decks,
and estabv was not modified, it would be loaded from the relocatable and
would give correct results. We hope this explains the confusion on the
part of several users who have been unable to see differences in their
results when using estabv.mods. It also means that investigators who
have been able to use the relocatable libraries /ccm/ccm1/r15/ccm1reloc1
and /ccm/ccm1/t42/ccm1reloc2 in their work were not affected by the
problems with estabv. Users who have made extensive modifications to
CCM1, and found it desirable or necessary to recompile the model
source, are the most likely to have been affected by the code
generation problem noted in earlier messages. Note that even minor
changes to model common blocks can require recompilation of the model
source code, making this a common way of working with the CCM.

We hope that this will finally conclude the network dialogue on the
matter of problems with the estabv code in CCM1.

CCM Core Group
(0)