This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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