[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030617: NLDN web display at USF (cont.)



>From: "Happel, Shelly" <address@hidden>
>Organization: USF
>Keywords: 200306121710.h5CHA3Ld017681 McIDAS NLDNDISP web pages

Hi Shelly,

>Thanks again! I made the change to the script and ran it again. From what I
>can see the log file says dsserve.k done. That's the only line it added.

OK, I am convinced that the problem is caused by the lack of definition
of RTPTSRC dataset elements.  The DATALOC command says that all RTPTSRC
data will be accessed as LOCAL-DATA:

dataloc.k* ADDE_ROUTE_RTPTSRC                      LOCAL-DATA

but there is no definition in place _for the routines being run_ by
the web server.

Yesterday afternoon I tried to plot a variety of RTPTSRC data using
metlab.cas.usf.edu as the ADDE server, and they all failed.  I have
to think that this is a result of your blocking displays that are
not in your local domain, which is OK.  I was a little suprised,
however, that the user 'mcidas' running on metlab.cas.usf.edu can
not go through the remote ADDE interface that _is_ setup on metlab.
I found this out by logging onto metlab and becoming 'mcidas' and
then:

cd workdata
dataloc.k ADD RTPTSRC metlab.cas.usf.edu
ptlist.k RTPTSRC/LIGHTNING
-- this hung --

I change the pointing back to LOCAL-DATA:

dataloc.k ADD RTPTSRC LOCAL-DATA

and then attacked the problem in the web server context.  I did
this by creating a RESOLV.SRV file in the

/usr/local/apps/php-apache/htdocs/sridhara/mcidas/data

directory.  RESOLV.SRV is the file that contains the definitions for
datasets (mapping from dataset group/descriptor (e.g., RTPTSRC/LIGHTNING)
to the files that compose the dataset (MDXX0071 - MDXX0080 in the
case of RTPTSRC/LIGHTNING).  Since all of the needed definitions were
already included in the version of RESOLV.SRV that had been created
in the McIDAS account (~mcidas/workdata/RESOLV.SRV), I simply copied
that file to the directory above.  I saw that the 'mcidas' version
of RESOLV.SRV had some extra dataset definitions in it, so I deleted
these in the copy.

I think that now that the web driven routines will have a dataset
definition file accessible, the NLDN plotting should work.  Please
try this out as soon as you can and let me know the results.  If
it does work, please remember to remove the logging additions that
you made to the gen_mcidas* script(s).

>I know there are some issues with our data feed...

Huh?  I just took a look at the latency plots for the various feeds
you are getting with the LDM, and don't see any problems with
metlab receiving data.

I did notice that the pointing for various datasets in the 'mcidas'
account (defined in ~mcidas/data/ADDESITE.TXT) has McIDAS routines
going out to remote servers for datasets that should be available
locally (e.g, RTIMAGES, RTWXTEXT):

ADDE_ROUTE_RTIMAGES=PAPAGAYO.UNL.EDU
ADDE_ROUTE_RTWXTEXT=ATM.GEO.NSF.GOV

or could be available locally if LDM were setup to request the data
(e.g., NEXRCOMP, RTNEXRAD):

ADDE_ROUTE_NEXRCOMP=PAPAGAYO.UNL.EDU
ADDE_ROUTE_RTNEXRAD=ATM.GEO.NSF.GOV

but I do not notice any data reception problems.

>Arlene tried to use it last
>night in the student lab and had some problems.

What exactly?

>Sigh..... She's talking
>about sending me back to you folks in Oct/Nov for training and I think I'll
>be able to get a lot more out of it this time since I've had more experience
>with LINUX and with the data sets. 

Well, traveling to Boulder should not be considered a hardship :-)

>Attached is the latest log file. I hope we can figure this out - I really
>really appreciate your help.

I think that my creation of a RESOLV.SRV file in the first MCPATH directory
defined in the gen_mcidas* scripts should solve your NLDN display problem.
You will have to try the plots and let me know if things are working.

Tom