From: ccm@sage.cgd.ucar.EDU (CCM Group Directories)
Message-Id: <199405092342.RAA16626@grub.cgd.ucar.edu>
Subject: Recent mail traffic
To: ccm-users@ncar.UCAR.EDU
Date: Mon, 9 May 94 17:42:28 MDT
To the subscribers to the ccm-users mail group:
With the general release of the CCM2, NCAR streamlined CCM
distribution procedures, making the model (and in the not too distant
future, it's technical documentation) available via anonymous ftp.
Since the CCM2 implementation is highly portable, and easily enabled
on a variety of high-performance workstation platforms, we anticipated
that a large number of external users might take advantage of its
availability. The ccm-users mail group was established to allow a
growing CCM user community to collectively rely on itself for
solutions to problems that might arise in the course of their work.
When a subscriber to this mail group posts a query, other subscribers
are free to respond if they feel they may be of help. We know of
subscribers who have demonstrated exemplary participation in this mail
group (e.g., an individual at UCSD who has independently responded to
user queries for help, made certain tools available to the community,
etc.). Over the last few weeks, however, we've seen examples of
participation that give us concern about the promulgation of incorrect
and misleading information.
The ccm-users mail group is an unmoderated mail group ... i.e., there
is no one formally monitoring and deciding what should or shouldn't be
posted. We are, therefore, relying on the care and dilligence of the
individual subscribers to avoid posting misleading or simply incorrect
information as fact. Unfortunately, some of the subscribers have not
displayed good judgement when it comes to posting messages prompting
us to warn ALL subscribers: ANY INFORMATION POSTED ON THIS MAIL GROUP
SHOULD BE USED WITH GREAT CAUTION. This includes using modified
distributions of the CCM2 code, modified versions of the associated
datasets, or software tools purported to manipulate CCM output
datasets, any and all of which may be advertised on this mail group.
The developers have neither the time nor the resources to fully verify
the functional integrity of independently distributed materials, so
buyer beware. We do not mean to discourage the exchange of modeling
tools or information, only that the end-user should exercise caution
(e.g., advertisement of a product, or a modeling or analysis tip, on
this mail group does not necessarily carry a formal endorsement that
it actually works). We will periodically repeat this warning in a
generic form as necessary, and will elaborate further in this mail
message using the more recent examples of misleading information. The
first example is as follows:
>There appears to be a problem with the surface geopotential output data
>for CCM2 experiment 422.
> ... we have been looking at the
>output from over the period from Dec. 1978 through 1989 on the
>MSS directory /CSM/ccm2/422/hist. No clear representation of Antarctica
>is present in the surface geopotential data. Furthermore, the surface
>geopotential should be fixed in time, yet the values change from
>one output time to the next.
The tone of this message strongly suggested a fundamental problem with
a CCM2 control integration. This message was taken very seriously by
the CCM Core Group, which spent several hours, as well as computer
resources, trying to identify the specific nature of the problem.
Since we couldn't reproduce the problem, we assumed that this user had
stumbled onto a corrupted history file and proceeded to pursue matters
directly with the user. As it turns out, this was a user problem, not
a problem with the dataset (as was later posted at our request). A
more thorough review of the documentation, coupled with a lower
profile approach to resolving the problem (e.g., "Help, I'm having a
problem"), would have avoided a situation that needlessly worried the
community of users analyzing Case 422, and consumed NCAR staff time
chasing a problem that didn't exist.
The second, more recent, set of examples are copied below:
>Hi ccm-users,
>
>Here are some tips.
>
>1. History tape data.
> For the first date of 'initial run', you may find the wrong values of
>output data. CCM2 does not averaging by 49 (for the case of dt=30min).
>
> And for the first date of 'restart run', you also find the wrong values
>of the first date data. CCM2 does averaging by 48. It should be done by 49.
>
>2. Perpetual Runs
> Even though the manual ('Users guide') does not mention the option of
>perpetual run, CCM2 codes can do this option by defining 'ANNCYC = .FALSE."
>in the namelist input files.
>However with this option only, you will find the wrong answer.
>You need to change the diurnal averaging option to 'DODIAVG = .TRUE.' as well.
>And also for the case of 'ANNCYC = .FALSE.', CCM2 does not read SST data
>properly. You'd better be cautious.
and
>Hi ccm-users,
>
>There needs more specific remark on the 'tips' which I sent to you earlier.
>
>. History tape data.
>
> For the first date of 'initial run', CCM2 does not average 18-level data.
> (One-level data are alright).
>
> And for the first date of 'restart run', CCM2 does not average properly
> 18-level data. (48 versus 49 for the case of dt=30min).
> (Here also one-level data are alright).
We feel it necessary to respond to these "tips", which basically
amount to a misunderstanding of the CCM2. Several of us attempted to
decipher the first item, and believe we understand what the user
is trying to say. The user is wrong. Using a 30 minute time step,
the correct diurnal averaging period is 48, not 49, time steps.
For item 2, the user has also provided misleading information. An
integral component of the CCM2 is the User's Guide documentation which
clearly and completely identifies the available namelist options.
ANNCYC is NOT one of the documented namelist options, and by
definition should be presumed not to work. There are several other
undocumented "optional" configurations appearing in the model code.
One can think of these as "hooks" intentionally left in the model for
the convenience of the developers, and other knowledgable users who
might want to modify the documented configuration to address their
particular needs. The mere existence of these hooks, however, does
not imply that they work in any way. In this case, be aware that the
tips for enabling a perpetual mode are incomplete, and hence
incorrect.
On the third item, aside from the continued confusion over time
averaging, we can't even begin to speculate about what the user is
trying to say.
Once again, we reiterate that the ccm-users mail group will only be
effective if our subscribers are careful about the information they
post, and the way in which they post it. Let's all try to maintain
a high quality of information exchange.
CCM Core Group
(0)