| Description: | ARM PROBLEM IDENTIFICATION FORM (PIF)
PIF No. P940217.2
Subject: Bad netCDF file submitted to the Archive
Submitted By: PJ Caraher
Organization: Argonne National Lab
Date Submitted: 17 Feb 94
How may we contact you?
e-mail: caraher@eid.anl.gov
phone: (708)252-4262
Submitter's Priority: 3
[Critical-1 Very Important-2 Important-3 Inconvenient-4 Interesting-5]
Where was this Problem Identified: SDS
Does this PIF result in a Software Change Request? No
Does problem impact data values or cause data loss? Yes
which platform(s): DsgpsondeB5.a0 and DsgpsondeB5.a1
Specify (or estimate) begin and end dates for data loss
Begin Date / / Time : Local/GMT (circle one)
End Date / / Time : Local/GMT (circle one)
Apparent cause of data loss, if known:
SUGGESTED CAUSES: either human error or software failure
[human error, component failure, temperature, lightning ]
[foreign matter, power loss, software failure, ]
[communications failure, modification difficulites, specify other]
Problem Description/Change Description.
The Reader`s Digest condensed version of the story is we created netCDF
files (DsgpsondeB5.a1.940208.143000.cdf & DsgpsondeB5.a1.940208.143000.cdf)
that have improperly timestamped data. These files were shipped to the
Archive. These files will be regenerated to have the proper data and sent
to the Archive. However, the improper files at the Archive should be
marked as bad.
Now for the long version:
At the Morris boundary facility (B5) a single sonde raw data file containing
two launches was created. These were the 14:30 and 17:30 launches of
8 Feb. Normally, the sonde creates a unique file for each launch. When
this two-launch raw data file was ingested, the data from the 17:30 launch
was read in as data from the 14:30 launch.
The data times within the sonde raw data files are all listed relative to
the launch time. So, an entry for 17:31 would be listed as 1 minute after
launch time and, since the launch time for this file was 14:30, the data was
packaged as being for time 14:31. Also, since data for 14:31 already
existed, it was written over by the 17:31 data.
Thus, a 14:30 netCDF file with 17:30 data was created. Also, no 17:30
netCDF file was created. The 17:30 file is being made by splitting the
problem raw data file into a 14:30 file and a 17:30 and ingesting the
17:30 file. The 14:30 file will also be ingested but, since a file
was already created with this name and Archived, this new file will be
version .v1.
So, how did this happen? I think that it was due to either software
failure or human error. A software failure of some sort could have
caused the 14:30 raw data file to never close and when the 17:40
launch was started, it went to the same file.
A more likely explanation is that the problem was due to human error.
The 14:30 launch contained only 3 minutes and 12 seconds worth of data.
It could be that the site operator was preoccupied with trying to regain
the signal and did not properly execute their tasks.
This is speculation on my part. Someone more familiar with the operation
of the sonde, such as Barry Lesht, should be able to shed some light on
this subject.
Recommended Distribution:
Tichler, Yates, Lesht, Singley, Splitt, Schneider
(Revision 1.1, 2/26/93 dkg) |