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

[Staging #YHC-348380]: Perus LDM

Hi Marcial,

re:
> Too much snow yet?

There is never too much snow in the Colorado mountains :-)  We only got
just under a foot (25 cm) of snow, and then the winds came.  I was hoping
for lots more snow (and with a higher water content).

re:
> Thanks for your time, I really appreciate it.

No worries.

re:
> I tried to follow the instructions in the web page of unidata but I
> think they are not as clear as they were before. What do you think?

I think that the instructions for building current versions of the LDM
are reasonably clear:

First, vet your build environment against the table of successful build
environments and unsuccessful build environments. Choose a 64-bit environment
if possible. Then, do the following:

    $ su - ldm
    $ wget ftp://ftp.unidata.ucar.edu/pub/ldm/ldm-6.11.2.tar.gz
    $ gunzip -c ldm-6.11.2.tar.gz | pax -r '-s:/:/src/:'
    $ rm ldm-6.11.2.tar.gz # optional
    $ cd ldm-6.11.2/src
    $ export PATH=... # if necessary
    $ ./configure [--enable-logging=localn] [--localstatedir=volatile_dir] 
[--disable-max-size] [--with-noaaport] [--with-gribinsert] [CC=...] 
[CFLAGS=...] >configure.log 2>&1
    Password: ...
    $ make install >make.log 2>&1
    $ make clean # optional

NOTE: If you don't have the pax(1) utility, then use this command, instead:

    $ gunzip -c ldm-6.11.2.tar.gz | (mkdir -p ldm-6.11.2 &&
    cd ldm-6.11.2 && tar -xf - && mv ldm-6.11.2 src)

The root of the installation tree will be $HOME/ldm-6.11.2 for the
version-dependent files.

The tricky part for long-time users is the introduction of the ~ldm/var
directory structure.  I had to experiment with this a bit before I really
understood what needed to be done in new installations (upgrades of existing
installations were less of a problem).

re:
> I think they use to be more like a guided instruction type, I think
> this was more clear for the final users.

It struck me that the 6.11.2 installation on the Peru machine somehow did not
follow the sequence for new LDM installations (the set that I cut and pasted
above); if we can understand where things went astray, we could improve the
documentation to help new users.  The biggest thing that I saw was that several
of the directories in the ~ldm directory were actual directories instead of
soft links -- the LDM has always had the notion that most of its installation
directories are accessible through a 'runtime' link.  For instance:

runtime -> ldm-6.11.2
bin     -> runtime/bin
include -> runtime/include
lib     -> runtime/lib
share   -> runtime/share
src     -> runtime/src

This structure makes it easy to build a new LDM distribution while an existing
one is installed and in use, and then cut over to the newly built distribution
by stopping the LDM; changing the runtime link to point at the new distribution;
and then restarting the LDM.

Since the installation for current versions of the LDM will create this
structure, I think that something went wrong in the installation on the
Peru machine.  Again, if we could better understand what went wrong, we
could improve the documentation.

Important: I notice that you are configuring the Peru machine to get
some CONDUIT data:

Real-time stats for data.senamhi.gob.pe:
http://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex?data.senamhi.gob.pe

I figured that you would be doing this at some point (the model output
in the HDS datastream is almost exclusively for the U.S.).  I have
some recommendations:

- if there is no use for the HDS data, turn off the REQUEST for it
  in ~ldm/etc/ldmd.conf

  This will save bandwidth. (The latency plots have indicated that there
  are times when the bandwidth to to the Peru machine is limited.)

- it may be necessary to "split" the CONDUIT REQUEST into several 
non-overlapping
  REQUESTs

  Most U.S. users getting all of CONDUIT split their REQUEST five ways.  Here 
is an
  example:

  Instead of REQUESTing everything in a single line:

REQUEST CONDUIT ".*" idd.unidata.ucar.edu

  the REQUEST is split into fifths:

REQUEST CONDUIT "([09]$)" idd.unidata.ucar.edu
REQUEST CONDUIT "([18]$)" idd.unidata.ucar.edu
REQUEST CONDUIT "([27]$)" idd.unidata.ucar.edu
REQUEST CONDUIT "([36]$)" idd.unidata.ucar.edu
REQUEST CONDUIT "([45]$)" idd.unidata.ucar.edu

  This same approach may well be needed for the CONDUIT feed to the
  Peru machine.  Since you probably only want to REQUEST the global
  fields, your REQUEST(s) will be different than the above.  You can
  still split the feed up into pieces by incorporating the sequence
  number (that is what is being referenced in this example) into the
  regular expression pattern that specifies the fields you want.  I
  can provide a more specific example for you as soon as I know the
  pattern you will use to get the set of fields that you want.

re:
> Again, thanks for everything.

No worries.  We're sorry for the difficulties you encountered!

re:
> PS: I still need to solve a problem with the gempak nmap2 map not
> resizing but I will try to fix that tonight, I found an email stating
> that need to recompile the openmotif but this did not helped.

Hmm... I am no GEMPAK expert, but I think that the display size
for NMAP2 is fixed (i.e., it is not like the IDV where you can
resize the window at will).  One has to compile with a specific
size in mind to get what is wanted.  I may be completely wrong
in this, of course, so please do not accept my comments as fact.
If you have GEMPAK specific questions please send them to
address@hidden.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: YHC-348380
Department: Support LDM
Priority: Normal
Status: Closed