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

20001230: McIDAS 7.7 ADDE setup at UGa (cont.)

>From: Thomas Mote <address@hidden>
>Organization: U. Georgia
>Keywords: 200012282251.eBSMpko24860 McIDAS-X 7.70 ADDE


re: how to setup directories so that can have current and archived data

>I'll think about this. For now, I may cut it to three days of satellite
>imagery and just leave it all in the same directory. I want to make sure I
>have at least one full 24-hour period available.

I agree with this approach.  I am thinking of a moving 24-hour (or whatever
length makes sense) "window" into a larger set of data (2, 3, 4, 5... days).
How to do this efficiently is the trick.

>BTW, what is the easiest
>way to make this imagery available? I suppose I could add something on the
>function key menu. Any suggestions?

I will be immersing myself into a rewrite of the Unidata GUI for McIDAS
in the next couple of months.  After that, the GUI (MCGUI) will be able
to "point" at any server for any supported data type (IMAGE, POINT, GRID,
TEXT) and display/analyze/copy/etc.  The nice thing about this approach
is that when one's data is stale, but internet connections are viable,
one can simply point at another server and keep working.  

It might be wise for me to jam together the Fkey menus necessary for
access of GINI data and put it in an addendum.  I will chew on this
for the next couple of days.

>Thanks for all the fixes on the CFG file. I did change a couple of
>directories (as you noticed) when I made the other changes. I wasn't sure
>how to specify the filename filter. As long as it works, I'm happy!

You are welcome.  Some of the changes were caused by directory name
fluidity, but most were caused by my fat-fingering at the keyboard.

>Regarding a public announcement of the availability of the data. I'm
>willing to do that, but there are a couple of things I should ask/tell you


>First, I know the NIDS data is supposed to be available on NOAAport very

Yes, starting tomorrow!

>Our NOAAport vendor will provide us with the software necessary
>to ingest it (may not require any modifications, not sure). We only have
>a one-channel system, but we can automatically switch between channels. If
>the NIDS data is not available via the IDD,

It will be.  We are establishing a floater stream much like the one from
WSI.  Also, individual sites will be able to request particular stations'
products from the top level IDD nodes.  Finally (but not least), McIDAS
sites will be able to display any/all stations by pointing at ADDE
servers that have all of the data all of the time.

>I may "channel surf" hourly to
>get some satellite imagery and some NIDS data. I would leave everything
>configured as it is now, there just wouldn't be as many images. If a
>sufficient amount of NIDS data will be available on the IDD, then I
>will just leave my NOAAport system pointed to GOES East. What is the plan
>for putting NIDS on the IDD? (Feel free to point me to a web page if this
>information is already posted.) 

There have been numerous emails to ldm-users about the plan for IDD
distribution of NIDS (NEXRAD Level III product) data.  The following is
the body of one of the more recent announcements:

  Date: Fri, 29 Dec 2000 09:58:29 -0700
  From: Anne Wilson <address@hidden>
  Organization: UCAR
  Hello LDM Users,
  After January 1, unencrypted NOAAPORT NEXRAD Level 3 data will be
  available via the Internet Data Distribution system.  In a previous
  message we told you about our plan to distribute the NEXRAD data:
  In particular, we have drafted a new routing scheme for the NEXRAD
  data that uses only two tiers.  It can be seen at
  Please look there to see which first tier site you should use as your
  NEXRAD feed.
  Also, we have prepared a page to help you get the NEXRAD data.  See
  for detailed information about getting and using the data.  
  Please proceed slowly in requesting NEXRAD data, because if you
  request all of the data as soon as it is available, there is a real
  possibility of overloading your own site as well as delaying data to
  other IDD sites, since the NEXRAD data is a significant increase in
  the number of products and volume of data already carried on the IDD.
  We recommend that sites start by requesting the NEXRAD floater feed
  and at most three other sites until we have a chance to evaluate and
  adjust the routing to balance the load among participating IDD sites.
  The encrypted, uncompressed data is currently available on the NEXRAD
  feed and is already flowing to several first tier sites.  You can add
  your request line now to start receiving the data when it becomes
  available at your upstream feed.
  If you have any questions, please first read the information
  available.  Many questions are answered there.  If you can't find the
  answer to your question in the material we have provided, send email
  to address@hidden
  We also want to express our appreciation to top-level source sites and
  first-tier sites for agreeing to participate in the NEXRAD data
  distribution, giving up some of their network bandwidth, computing
  resources, and time during the holiday season to reconfigure their
  LDMs to make NEXRAD data available to other IDD sites.  In particular,
  we want to thank:
   Harry Edmon
   Eric Horst
   Eirh-Yu Hsie
   Mark Laufersweiler
   Bob Leche
   Jeff Masters
   Bill Noon
   Art Persons
   Pete Pokrandt
   Larry Riddle
   Jerry Robaidek 
   Clint Rowe
   Gilbert Sebenste
   Paul Sirvatka
   Bryan White
   David Wojtowicz
  for their help.
  Wishing you all a wonderful new year with lots of good quality data!

>Secondly, there is a 50/50 chance we will be purchasing a 2- or 3-channel
>NOAAport system in the next six months. I should know in the next few
>weeks whether we will get the go ahead. We would be willing to make this
>data publicly available as well, and I may also have some funds for
>support staff. The purchase would be from the same vendor, so presumably
>we wouldn't need to change the way things are configured.

Excellent!  It would be very generous of you to help other Unidata sites
by providing access to more of the NOAAPORT conveyed data, especially
the satellite imagery and NIDS products.

>Finally, we have had some network connectivity problems in our building.
>Cacimbo is attached to a 100Mbit hub, which is directly connected to the
>building fiber network and then the campus fiber optic network, bypassing
>the old thick ethernet in most of our building. However, they are having
>problems with the new system and we have found a number of occasions where
>the connectivity for machines on the fiber optic network is slower than
>the old broadband. It was probably quite fast today as nobody was on
>campus. I hope it stays that way and they have the bugs worked out, but I
>just thought I should mention it.

The connection was very fast yesterday.  Loading images from cacimbo to
my home machine was very fast (ADSL is nice when you are close enough
to the phone switch).

>Thanks again.

You are certainly welcome.

Two last comments:

o Since you only have the GOES-East NOAAPORT channel, I added/created
  a new ADDE dataset called GINIEAST.  The components of this dataset
  are the same on your machine as RTGINI, but the name is more
  representative of what you actually have.  Following this example,
  I created two datasets from the original on the ADDE server that we
  maintain in the main machine room of NCAR, adde.ucar.edu.  Since that
  machine has both GOES-East and GOES-West data, it made sense to have
  one dataset called RTGINI.  It now has three:  RTGINI (all of the
  GINI data), GINIEAST (for the NOAAPORT channel 1 data), and GINIWEST
  (for the NOAAPORT channel 2 data).  I have to say that there is
  a lot of redundancy in the elements of the datasets since there are
  some products that are broadcast on both NOAAPORT channels 1 and 2:
  CONUS, CONUSCOMP, and the imagery products (LI, PW, SFCT, CTP).
  By segmenting the datasets, a site can point at one ADDE server for
  GOES-East data and another server for GOES-West data.  This will
  help balance the ADDE load when more and more sites start taking
  advantage of its services.

o Second, I noticed that your XCD surface decoding was not working
  correctly (lots of 80 F temperatures in regions that should be in the
  20s).  I took the liberty of attempting to fix the problem by doing
  some XCD reconfiguration.  A quick SFCLIST of KDEN for the past 24
  hours pointing at cacimbo looks reasonable.  Also, a 24 hour listing
  for Gilette, WY (KGCC) looks like the problem was fixed:

%sfclist.k KGCC 24
 Day Time StCo  Stn   T  Td  Dir Spd Gus AltSet  Vis  Weather  Ceil
     hhmm        id  [F] [F]     [ kts ]  [mb]   [mi]
---- ---- ---- ----- --- --- --- --- --- ------ ----- -------- -----
  30 2000 WYUS KGCC   86                                       5/000
  30 2100 WYUS KGCC   86                                       5/000
  30 2155 WYUS KGCC   26  19 000   0     1018.3 10.00          5/080
  30 2255 WYUS KGCC   25  19 090   5     1018.6 10.00          8/085
S 30 2320 WYUS KGCC          310  24             6.00          5/080
  30 2355 WYUS KGCC   21  18 090   3     1019.0 10.00          5/080
  31 0055 WYUS KGCC   17  14 190   3     1019.3 10.00          5/080
  31 0155 WYUS KGCC   19  16 040   4     1019.6 10.00          8/080
  31 0255 WYUS KGCC   18  15 210   3     1020.0 10.00          8/085
  31 0355 WYUS KGCC   19  16 000   0     1020.7 10.00          8/080
  31 0455 WYUS KGCC   19  15 000   0     1020.7 10.00          8/080
  31 0555 WYUS KGCC   17  15 230   4     1021.0 10.00          5/085
  31 0655 WYUS KGCC   10   8 190   3     1021.3 10.00
  31 0755 WYUS KGCC    7   3 170   3     1021.0 10.00
  31 0855 WYUS KGCC    4   0 000   0     1021.0 10.00
  31 0955 WYUS KGCC    7   4 000   0     1021.3 10.00
  31 1055 WYUS KGCC    3  -1 000   0     1021.0 10.00
  31 1155 WYUS KGCC    2  -1 000   0     1020.7 10.00
  31 1255 WYUS KGCC    3  -1 000   0     1020.7 10.00
  31 1355 WYUS KGCC    3   0 000   0     1020.3 10.00
S 31 1409 WYUS KGCC    3   1 110   3     1020.3 10.00          5/006
  31 1455 WYUS KGCC    5   1 000   0     1019.6 10.00          5/006
S 31 1504 WYUS KGCC    7   3 330   4     1020.0 10.00
  31 1555 WYUS KGCC   12   9 000   0     1019.6 10.00
  31 1655 WYUS KGCC   17  14 000   0     1020.0 10.00          5/050
  31 1755 WYUS KGCC   26  22 020   3     1019.6 10.00
  31 1855 WYUS KGCC   28  22 000   0     1019.0 10.00
Number of reports = 27
sfclist.k: done

  You can see that the Ts before my mods were bogus (86 F and no Tds at 20
  and 21 Z) and the Ts after my mods look reasonable.  I will do some
  plots/contours on Tuesday when I am at a place where I can crank up McIDAS.

Here's to a healthy, happy, and bright New Year!


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.