[Support #FLO-999289]: IDD Access and Participation

Hi John,

re:
> Thanks for your prompt, courteous, and informative response.

No worries.

> I will do my best to address each of your questions regarding my inquiry.

re: it is likely that a Unidata member institution would feed you data via the 
IDD

> We would happily work directly with one of the member institutions to receive 
> this
> IDD feed. As with you, I think Texas A&M is a fantastic choice.

Very good.  I will send a note to the LDM/IDD administrator at Texas A&M right
after this reply.

re: near real-time ground-based truth information

> As with Unidata's other agreements for proprietary data (restricted use) we 
> would initiate
> user agreements for any non-commercial and or public use.
> Further, much like the proprietary lightning data that is carried on the IDD 
> stream we would
> work with Unidata to make a format and delivery system that could easily 
> integrate into the
> LDM/IDD specifications for relay to the entire community. While this is a 
> commercial venture
> on our end, the educational uses for education, research, and emergency 
> planning are significant.
> That is why we want to provide the service free-of-charge to universities and 
> research facilities. IDD
> seemed the most logical infrastructure for that endeavor.

Fantastic!  This exactly the sort of quid pro quo arrangement that makes the 
Unidata
community vibrant!!

re: do you want us to pursue contact of the LDM/IDD site administrator at a 
Unidata community
member site

> Yes, If it's not too much trouble I'd like to start moving down this path. 
> This would allow
> us to get this project behind us and focus primarily on our near real-time 
> surface event
> truthing system (SETS) for severe weather events.

I will be sending the email I mentioned above this morning.

re: do you have a *nix machine on which you can install and run the LDM.

> No, however once the system (flavor) and requirements are given to us we will 
> field one
> in very short order.

The LDM runs on every variety of Linux tested so far.  It also runs on "major"
Unix systems (e.g., Solaris, IRIX, FreeBSD, etc.).  There is, however, a problem
that was uncovered on the latest release of MacOS-X.  This problem is not caused
by the LDM, but, rather, by the OS itself.  Apple has not addressed/fixed this
problem in the approx. 1 year since they were notified about it.

As far as the sort of hardware that would be needed: this really depends on
what you plan on doing with the data once it is received (e.g., decoding
and other processing).  The LDM itself does not use much in the way of
system resources.  Decoders, on the other hand, can use quite a bit of
system resources (e.g., CPU cycles, memory, disk).  We are now recommending
that our "power users" move to 64-bit machines that have a minimum of 4 GB
of RAM.  The good news is that this class of system now costs on the order
of $500 for commodity, off-the-shelf hardware.  Just so you know, I have
run tests in which I ran an LDM in an OpenSUSE 10.3 virtual machine that was
running inside of VMware Player which was running on an IBM Thinkpad T60
which was running Windows XP.  A user in Florida noted in the ldm-users email
list about a year ago that he was running several virtual machines on a
machine with more horsepower, and that one of the virtual machines was
running the LDM and ingesting and relaying data.  The VMware virtual machine
approach is interesting, but even though it works, we would recommend a
straight *nix machine for sites wanting to do a lot of processing.

re: forward and reverse DNS

> See answer above - Does it need forward and reverse DNS?

Yes, one of the security mechanisms in the LDM is the use of both forward
and reverse DNS.  Requests from downstream machines (machines receiving
data feeds) include the IP address of the downstream machine.  The upstream
LDM uses DNS to translate this into a fully-qualified hostname which
is then compared against the list of ~ldm/etc/ldmd.conf ALLOW lines to see
if the upstream machine has been configured to allow the feed request.
Without the ability to do the reverse name lookup (IP to name), the
ALLOW mechanism will fail.  The upstream site, however, has the option of
allowing the request by IP address, but this would not prevent spoofing.

> > - which IDD datafeeds are you interested in
> 
> Real-Time Model Data.
> Real-Time Remote Sensing Image Data (Satellite & Radar)
> Real-Time Text Data
> **Real-Time Point Data is NOT needed

OK.  There are several different feeds of model data:  HDS, NGRID (both
from NOAAPort), CONDUIT (high resolution model output from NCEP), GEM
(from the Canadian Meteorological Center) and FNMOC (from Fleet Numerical).
The CONDUIT feed is the highest volume feed of all IDD feeds.  If one
wants all of the CONDUIT data, one should have more of a muscle machine
and an Internet connection with a large pipe.

> Of Course Bandwidth and Data Transfer Amounts would need to be considered
> so that we may properly budget for this (or any) setup.

Yup.

> Again, Thanks for the help and we look forward to participating in the UNIDATA
> community very soon.

No worries.  I will contact the LDM/IDD administrator at Texas A&M.  If he
is willing to feed you, he will contact you for details.  If he is not
willing to feed you, I will look for an alternate site.

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: FLO-999289
Department: Support IDD
Priority: Normal
Status: Closed