-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathezget_bugs.html
executable file
·306 lines (259 loc) · 12.4 KB
/
ezget_bugs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
<HTML>
<HEAD><title> EzGet entry page</title></head>
<BODY>
<body background="bg9.gif">
<H1>EzGet Bugs, Updates, and Limitations
</H1>
<HR>
<p>
Bugs in Version 1.0: A rarely encountered bug was discovered that
sometimes caused an EzGet internal table (where dimension information
is stored) to fill up prematurely. This bug would be obvious to any
user who encountered it and was corrected in version 1.1.2. Another
bug was found which affects masking of geographical regions. If a
geography mask were stored with more than the longitude and latitude
dimensions explicitly defined (e.g., if the mask were a function of
time), but if in fact this third dimension contained only one element
(i.e., "time" might actually only be a dummy dimension and therefore
the data stored would only be 2-dimensional), and if the field that
EzGet was instructed to mask was in fact a function of time, then EzGet
will obtain masking information for most of the field from some
unpredictable location in the computer's memory and garbage will be
produced, which may or may not be evident to the user. This bug was
corrected in Version 1.1.3. A bug that affects mapping data to a
target grid when the domain for the longitude dimension requires use of
the "cycle" length information (usually 360 degrees) prevents proper
regridding in some cases. This bug was fixed in Version 1.1.4.
<p>
Bugs in Version 1.1: Several bugs were found having primarily to do
with masking geographical regions under the newly implemented option to
use land fraction data (expressed as a percentage). The worst problem
found was that land data would be masked when ocean data should have
been masked and vice versa. Most of these bugs were corrected in
Version 1.1.2. Also the second bug found in Version 1.0 remained in
Version 1.1, but was corrected in Version 1.1.3, and the third bug
found in Version 1.0 remained in Version 1.1, but was corrected in
Version 1.1.4.
<p>
Bugs in Version 1.1.2: Two bugs related to the newly implemented
option to use land fraction data (expressed as a percentage) were
discovered. Also the second bug found in Version 1.0 remained in
Version 1.1.2. These bug were corrected in Version 1.1.3. The third
bug found in Version 1.0 remained in Version 1.1.2, but was corrected
in Version 1.1.4.
<p>
Bugs in Version 1.1.3: The third bug found in Version 1.0 remained in
Version 1.1.3, but was corrected in Version 1.1.4. A bug
(introduced into Version 1.1.3) that affects geography masking in the
case that the land fraction data are stored as INTEGERS (0 to 100)
leads to incorrect masking results. All known PCMDI land fraction data
masks are stored as real (0.0 to 100.0), not integer, so this bug
should not have had any affect on data processed at PCMDI. This error
was also corrected in Version 1.1.4.
<p>
Bugs in Version 1.1.4: Minor bugs in the selection of geographical
regions were found; these bugs should be obvious if encountered because
the code crashes. A bug in the regridding option that allows mapping to
a user-specified gaussian grid was found. An error in overriding
cycle=0. when regridding was found. A few other errors were found, but
documentation is unavailable.
<p>
Bugs in Version 1.2: No bugs have been reported in the most recent
release of EzGet (Version 1.2; 11 February 2000). Users should
report suspected bugs to [email protected]. Also all users should
register by email at [email protected], indicating name, location, and
platform, so that they can be immediately informed if significant bugs
are found. New releases of EzGet will be announced by email to all
those registered.
<p>
Updates: A short description of the differences in various versions of
EzGet is given here.
Version 1.0 was the original version of EzGet to be publicly released
in March 1996. It had been thoroughly tested at PCMDI over a two year
period.
Version 1.1 was released in September 1996. Programs using version 1.0
should run successfully under version 1.1, but the newer version
differs in the following respects:
<P>
<ul>
<li> The capability for selecting (or masking) data from specific
geographical regions was extended so that output from the Atmospheric
Model Intercomparison Project 2 (AMIP 2) and Paleoclimate Modeling
Intercomparison Project (PMIP) could be used in unmodified form. In
addition to the types of geographical data that were previously
permitted, version 1.1 makes it possible for EzGet to read land
fraction data (expressed as a percent) or sea ice fraction data
(expressed as a percent), making it easy to mask out data from land,
ocean or sea ice regions in analyses of the intercomparison project
output. In addition, when data is extracted, for example, from land
areas only, the weights created by EzGet, which can be used to
calculate area averages, are properly generated even for models in
which individual grid cells are partly land and partly ocean. See
documentation of subroutines defgeog, getgeog, and defmisc for further
details. </li>
<P>
<li> The capability of extracting integer data was expanded by allowing
for proper identification of missing integer data. See documentation
of subroutine defmisc for further details. </li>
<P>
<li> A bug in the assignment of aliases for the longitude and latitude
coordinates (accomplished through calls to subroutine defmisc) was
corrected. See documentation of subroutine defmisc for further
information. </li>
<P>
<li> The assignment of weights for the LMCE and LMD models was corrected
and generalized to allow for different model resolutions. </li>
<P>
<li> In calls to subroutine defdim, EzGet now recognizes that the model
acronym 'ech*' (where * can represent any group of characters)
indicates a gaussian grid. See appendix A of the documentation. </li>
<P>
<li> A bug was found and corrected, so that EzGet now correctly recognizes
the equivalence of the strings, 'sea ice', 'sea-ice', and 'seaice',
which are used to select data from regions with sea ice. If this bug
was encountered in the previous version, an explicit error message
would be written so the user would have known about it. </li>
<P>
<li> Documentation was updated to account for all these changes.
Significant changes were made in the sections on subroutines defgeog,
demisc, and getgeog. </li>
</ul>
<P>
Version 1.1.2 was released in 11 November 1996. It differs from
Version 1.1 in the following respects:
<P>
<ul>
<li> A few bugs were corrected, primarily having to do with masking
geographical regions under the newest option to use land fraction data
(expressed as a percentage). The worst bug was that in version 1.1
land data would be masked when ocean data should have been masked and
vice versa. Also an option is now available to specify explicitly that
the geography data set contains land fraction data (expressed as a
percentage). See documentation of subroutine defmisc for further
details. </li>
<P>
<li> A bug involving an internal dimension table created by EzGet was
corrected, which makes it less likely that this table will become
filled. </li>
</ul>
<P>
Version 1.1.3 was released on 19 December 1996. It differs from
Version 1.1.2 in the following respects:
<P>
<ul>
<li> The two bugs described at the beginning of this page were eliminated. </li>
</ul>
Version 1.1.4 was released on 16 May 1997. It differs from Version
1.1.3 in the following respects:
<P>
<ul>
<li>A bug in all previous versions that prevented proper mapping of
data to a target grid when the longitude domain required information on
the "cycle" length (usually 360 degrees) was corrected. Another bug
was fixed which now allows the user to reset the geography masking
"off" by specifying "0 " as the mask-index in a call to defgeog (as
described in the documentation). This error was present in all
previous versions. In addition the specification of the parameter,
'data size', by a call to subroutine defmisc, which was inadvertantly
required by previous versions in order to correctly retrieve data
through subroutine getvdata, is no longer required, but continues to be
recommended. A bug in Version 1.1.3, which affected land/sea masking
when land fraction data was stored as integers (0 to 100), was
corrected.</li>
<P>
<li>A new subroutine was added to EzGet: subroutine getnogap, which allows
the user to extract data and place it in contiguous memory. This
subroutine is nearly the same as subroutine getvdata, but the user can
instruct EzGet (through one of the subroutine arguments) to check that
the data extracted will not exceed the size of the arrays the user has
defined to receive the data. Thus instead of defining 'data size' by
calling defmisc followed by a call to getvdata, the user can more
concisely simply call getnogap. This subroutine is described in the
latest documentation.</li>
<P>
<li>The maximum length allowed for variable names was increased from
16 to 64 characters.</li>
<P>
<li>A change was made in the behavior of EzGet in the case of a dimension
that is length 1. For example, consider a file containing a variable
that is a function of longitude, latitude and time, but all data in the
file are from a single time "slice". In this case (in which a
dimension is defined in a file, but has a length of one) EzGet no
longer requires the user to call subroutine defdim for this dimension.
If the dimension is not defined by the user, EzGet will assume the user
wants to retrieve the single time "slice" of data from the file and
will apply unit "weighting" for this dimension.</li>
<P>
<li>In the EzGet documentation, all references to subroutine getvdata
were removed because this subroutine is nearly identical to subroutine
getnogap, which is now fully documented. The documentation was also
revised to be consistent with all software changes made since Version
1.1.2. </li>
<P>
</ul>
Version 1.2 was released on 11 February 2000. It differs from Version
1.1.4 in the following respects:
<P>
<ul>
<li>Bugs were fixed as described above.</li>
<P>
<li>A capability was added to calls to subroutines defvar and defvarex,
which allows the user to check that a file exists before attempting
to retrieve data. When this option is invoked, an error flag is
returned to the user indicating whether or not the variable was found.
In previous ezget versions, the code would error exit if a variable or
file did not exist. The latest EzGet documentation explains this feature.</li>
<P>
<li>A subroutine was added (diminfo) which returns descriptive
information about a dimension (e.g., units, title, source, etc.). The
latest EzGet documentation explains this feature.</li>
<P>
</ul>
<P>
Current limitations of EzGet include:
<P>
<ul>
<li> EzGet has not been ported to the DEC Alpha computers. </li>
<P>
<li>The full capabilities of EzGet apply only to 4-byte floating point
(real*4) data. Double precision and integer data, for example, can be
extracted, but cannot be interpolated to new grids within EzGet.
Missing data values can be recognized for integer data, but not double
precision data. </li>
<P>
<li>The names of fields that will be extracted by EzGet should be no longer
than 64 characters long. All standard names for AMIP and PMIP are well
within this limit.</li>
<P>
<li>Coordinates are converted to single precision when extracted by
EzGet, and currently it is only possible to specify the domain of data
to be extracted in single precision. This may lead to problems if, for
example, the time domain of some hourly data you want to extract is
for years 1000 through 1001 (i.e. hours 8,760,000 through 8,768,760).
Single precision floating point numbers are unable to resolve 1 part in
8.7x10**6, so it would not be possible to properly extract this data by
specifying a domain with subroutine defdim. Note, however, subroutine
defdimi could be used to specify a domain and retrieve the data
successfully (but if it were necessary to retrieve the coordinate
values by calling getcoord, they would be truncated.) </li>
<p>
<li> Geography maps used to specify regions such as "North America",
"Australia", "South Pacific", etc. are currently available for AMIP 1
models, but they are not yet available for all PMIP, CMIP, or AMIP 2
models.
</ul>
<p>
<HR>
<a href="ezget.html">Return to EzGet Overview</A> <br>
<a href="../index.html">Return to Software Tools</A> <br>
<a href="../../PCMDI.html">Return to PCMDI home page</A>
<HR>
<p>
Last update August 11, 1997. For questions or comments on EzGet, contact<BR>
Karl Taylor (<a href="mailto:[email protected]">[email protected]</a>)
<p>
<a href="http://www.llnl.gov/disclaimer.html">LLNL Disclaimers</a>
<p>
UCRL-ID-123716
</BODY>
</HTML>