[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
19990503: profiler data & mcidas (cont.)
- Subject: 19990503: profiler data & mcidas (cont.)
- Date: Mon, 03 May 1999 15:47:06 -0600
>From: address@hidden
>Organization: St. Cloud State
>Keywords: 199904091934.NAA23884 McIDAS-XCD
Alan,
>A question about profiler data; in the past, this was provided as part
>of the UW data stream and the decoders created a file called
>profiler.cdf (at least that is what is on my disk).
Right. The PROFILER.CDF data file is still in the Unidata-Wisconsin
datastream, BUT it is scheduled to be deleted on July 1.
>I have not used this lately, and have not heard from students until one
>asked today "why can't we get profiler data"? I looked on disk for
>hobbes and profiler.cdf is there, with a current date time stamp, but
>no result on our terminals.
If the file is coming in, then the problem has to be in the decoding of
the file into a McIDAS format.
>I suspect that I omitted something in our
>last upgrade to os2-mcidas 7.4, namely that profiler data now is
>'handled' as an MD file and that I never set it up properly.
Isn't hobbes an AIX machine? What machine(s) are doing the data
decoding for your OS/2 machines? If you are decoding files on your AIX
machine and then sharing the data files through NFS, then the problem
lies on your AIX box. If you are sending the data along to the OS/2
machines and running the decoders there, then the problem is on your
OS/2 machine(s). I'd ask Don about this, but he is not in the office
at the moment.
>I don't
>have FSL2 on our list of requested feeds, and I don't recall turning on
>a new decoder in the ldm on hobbes.
The FSL2 feed contains both the hourly summary and 6-minute FSL wind
profiler data in it. These products are the replacement for the
PROFILER.CDF product (which is hourly summary data only) in the
Unidata-Wisonsin data feed.
>However, our pqact.conf on waldo
>suggests that profiler data is provided by the UW data (and also from
>FSL2. I understand from your emails that profiler data will disappear
>from the UW data as of 1 July.
Right, it _will_ be going away.
>Can you briefly comment on changes in profiler data over the last
>year?
The FLS2 feed was made available a number of months ago and announced
to the members of the ldm-users, gembud, mcidas-x, and mcidas-os2
email lists. At the time of the announcement we noted that sites
should transition to use of the FSL2 datastream since the profiler
data in the UW stream would be going away.
>Why is profiler.cdf still being created?
As an aid during users' transitions.
>Is it used by os2-mcidas?
McIDAS-OS2 does have the capability of decoding the PROFILER.CDF file
into a McIDAS MD file. Don also added the capability of converting
the FSL2 data to MD files in the OS/2 XCD component.
>As to the new ldm and mcidasx on waldo, first, I have added FSL2 to the
>requested feeds coming into hobbes, from chinook at UNL, then stopped
>and restarted the ldm. Have not yet added HRS. This should allow
>profiler data to start coming in to hobbes.
Good.
>I note that you have
>already added FSL2 to the feeds waldo requests from hobbes.
Right.
>I made my
>change earlier today, but still have not seen any files in the MDXX80
>group in /var/data/mcidas on waldo, so nothing is there yet. From your
>comments of 4-29, I assume that the decoders that create profiler MD
>files are the MCIDAS-XCD point source decoders and they are already
>running successfully.
Actually, the profiler decoder for data in the FSL2 feed is the ldm-mcidas
decoder, proftomd.
>Also, the pqact.conf on waldo has the hourly
>summary profiler data from FSL2 uncommented.
Right.
>So, I am puzzled by the lack of profiler data on waldo; comments?
Me too. I will get onto waldo and see if the products are, in fact,
getting to the machine. If they are, then next step is to see why
proftomd is not converting them into McIDAS MD files.
>I note your changes and suggestion to eliminate /var/data/mcidasd.
Right.
>I don't have any explanation about the STRTABLE file being in
>/var/data/mcidasd.
The only thing I can think of is an errant REDIRECTion in a McIDAS-X
session.
>It may well have happened in our setting up the
>MCDATA environment. I will check on that.
OK. If it hasn't reappeared then the problem was transitory. If it
reappears we need to find out how/why it is being created.
Tom