[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[GEMPAK #ABG-423464]: garp issues
- Subject: [GEMPAK #ABG-423464]: garp issues
- Date: Wed, 20 Sep 2006 13:33:06 -0600
Brian,
I was out on vacation when you sent your previous responses, and it seemed like
you had a
workaround for the moment.
I have gone back through the COMET code for Garp, and thus far have found two
areas where the code is not compatible with 64 bit operating systems. The most
widely tripped
bug is the time display on the lower status bar, which could also come into
play with
the time matching you mention due to the layer of Garp which allows training by
setting a clock time where data is made available though the case run time.
Here the storage of the time was 32 bit, but the system clock time is now 64 bit
on various platforms and OS.
If you want an updated linux binary, I can make a test copy for you to see if
that
helps your lab situation. Your original message also mentioned Solaris 10,
which you
would probably have to build an updated source tree. Let me know if you want to
pursue either of these options, as I realize your classes are now in session.
I am currently working on the 5.9.4 release, if you prefer to wait until that
is posted.
Thanks for your info on what you had found,
Steve Chiswell
Unidata User Support
>
> Dear Steve,
>
> Finally, some progress over here, and some good news. I reinstalled
> fedora5 (since I did not do the initial install), and then the gempak
> 5.9.3 binaries. I was excited at first, since the clear button worked,
> but then I tried again, garp crashed. However, this time I noticed a
> trend. The crash occurs when I overlay a field with >1 more or less times
> than the other field. This is easy to do when testing by selecting random
> times. However, if one is careful and selects the same number of
> highlighted times for each field using the pull down time widget, the
> clear button works, and it actually works for my other fedora5 machines
> in the lab. Another way to make sure the same number of fields exist is
> to use the time matching option, which is actually what we do a lot of in
> class. Sure enough, after time matching the clear works as well. So, this
> crashing on my fedora5 systems appears to occur when not all garp frames
> have the same number of fields on them.
>
> Since we use time matching a lot, this problem is not major. However, if
> you do not have this problem on your fedora5 system, then I am at a loss,
> since I have seen it in the 5.9.3 binaries, my compiled version, a
> reinstalled fedora5 with no updates, and a fedora5 version with all
> packages selected and all fedora updates. So, I am out of things to try.
>
> Brian
>
> On Sat, 2 Sep 2006 address@hidden wrote:
>
> >
> > Dear Steve,
> >
> > Since I did not hear back in the last week, I decided this was not good
> > news with my current approach with the 5.9.3 binaries. So, I decided to
> > just try and compile gempak myself on the fedora core5. I got it to
> > compile using the g77 and motif. However, I did have to to use an
> > older libXm.a (by two years) from another linux machine, since the default
> > fedora core5 install version on Xm from Feb06 produced the following
> > errors for the major programs: /usr/lib/libXm.a(TextIn.o): In function
> > `SelfInsert':
> > (.text+0x8002): undefined reference to `XftTextExtentsUtf8'
> > /usr/lib/libXm.a(TextOut.o): In function `FindWidth':
> > (.text+0x77e): undefined reference to `XftTextExtentsUtf8'
> > ....
> > (.text+0x313): undefined reference to `jpeg_destroy_decompress'
> > collect2: ld returned 1 exit status
> > make[2]: *** [linux/garp] Error 1
> >
> >
> > Anyways, it is compiled now, so I got to try out my garp "clear"
> > problem again, and sure enough I get the same problem as before. Garp
> > crashes when I hit clear after overlaying fields from *two* separate data
> > sources (surface over radar, model over satellite, etc...). Here is the
> > crazy error again:
> > metlab>> Invoke ... /home/metlab/GEMPAK5.9.3/os/linux/bin/garp
> > G A R P - v2.1 starting...
> > *** glibc detected *** /home/metlab/GEMPAK5.9.3/os/linux/bin/garp: double
> > free or corruption (!prev): 0x1123cf28 ***
> > ======= Backtrace: =========
> > /lib/libc.so.6[0x827f18]
> > /lib/libc.so.6(__libc_free+0x78)[0x82b3ef]
> > /home/metlab/GEMPAK5.9.3/os/linux/bin/garp[0x80aa1cb]
> > /home/metlab/GEMPAK5.9.3/os/linux/bin/garp[0x80a8c3d]
> > /home/metlab/GEMPAK5.9.3/os/linux/bin/garp[0x80a8ce5]
> > /home/metlab/GEMPAK5.9.3/os/linux/bin/garp[0x80a98c7]
> > ...
> >
> > Now I am starting to get concerned, since I am running out of options
> > here, but at least I have some compilation control to test things. Please
> > respond with any ideas.
> >
> > Thank you.
> >
> > Brian
> >
> >
> > On Fri, 25 Aug 2006 address@hidden wrote:
> >
> > >
> > > Steve,
> > >
> > > Just to follow up on what I tried today. I am running Xorg, so I
> > > installed every package/option there was with the Fedora installer
> > > associated with Xorg (there were a few items not installed). Still no
> > > luck. I wish there was any easy way to compare to your system on your
> > > Fedora5. I guess there must be something missing here with the fedora
> > > install, or some craziness with the video card perhaps; however, it is
> > > strange that this only happens with the garp clear or reset button.
> > >
> > > Brian
> > >
> > > On Thu, 24 Aug 2006 address@hidden wrote:
> > >
> > > >
> > > > Steve,
> > > >
> > > > yes, I believe we are using the xorg for X11, at least there is a
> > > > xorg.conf in the /etc/X11 dir. Below are the settings. Not sure if there
> > > > is something to be set here, or some other X11 piece we are missing
> > > > during
> > > > the Fedora5 install.
> > > >
> > > > I had some hope this afternoon when I remembered that kde sometimes
> > > > works
> > > > better, but I get the problem under any mode (kde, gnome, or failsafe).
> > > >
> > > > Brian
> > > >
> > > > # XFree86 4 configuration created by pyxf86config
> > > >
> > > > Section "ServerLayout"
> > > > Identifier "Default Layout"
> > > > Screen 0 "Screen0" 0 0
> > > > InputDevice "Mouse0" "CorePointer"
> > > > InputDevice "Keyboard0" "CoreKeyboard"
> > > > EndSection
> > > >
> > > > Section "Files"
> > > >
> > > > # Multiple FontPath entries are allowed (they are concatenated together)
> > > > # By default, a font server independent of the X server is
> > > > # used to render fonts.
> > > > FontPath "unix/:7100"
> > > > EndSection
> > > >
> > > > Section "Module"
> > > > Load "dbe"
> > > > Load "extmod"
> > > > Load "fbdevhw"
> > > > Load "glx"
> > > > Load "record"
> > > > Load "freetype"
> > > > Load "type1"
> > > > Load "dri"
> > > > EndSection
> > > >
> > > > Section "InputDevice"
> > > >
> > > > # Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
> > > > # Option "Xleds" "1 2 3"
> > > > # To disable the XKEYBOARD extension, uncomment XkbDisable.
> > > > # Option "XkbDisable"
> > > > # To customise the XKB settings to suit your keyboard, modify the
> > > > # lines below (which are the defaults). For example, for a non-U.S.
> > > > # keyboard, you will probably want to use:
> > > > # Option "XkbModel" "pc102"
> > > > # If you have a US Microsoft Natural keyboard, you can use:
> > > > # Option "XkbModel" "microsoft"
> > > > #
> > > > # Then to change the language, change the Layout setting.
> > > > # For example, a german layout can be obtained with:
> > > > # Option "XkbLayout" "de"
> > > > # or:
> > > > # Option "XkbLayout" "de"
> > > > # Option "XkbVariant" "nodeadkeys"
> > > > #
> > > > # If you'd like to switch the positions of your capslock and
> > > > # control keys, use:
> > > > # Option "XkbOptions" "ctrl:swapcaps"
> > > > # Or if you just want both to be control, use:
> > > > # Option "XkbOptions" "ctrl:nocaps"
> > > > #
> > > > Identifier "Keyboard0"
> > > > Driver "kbd"
> > > > Option "XkbModel" "pc105"
> > > > Option "XkbLayout" "us"
> > > > EndSection
> > > >
> > > > Section "InputDevice"
> > > > Identifier "Mouse0"
> > > > Driver "mouse"
> > > > Option "Protocol" "IMPS/2"
> > > > Option "Device" "/dev/input/mice"
> > > > Option "ZAxisMapping" "4 5"
> > > > Option "Emulate3Buttons" "yes"
> > > > EndSection
> > > >
> > > > Section "Monitor"
> > > >
> > > > ### Comment all HorizSync and VertSync values to use DDC:
> > > > Identifier "Monitor0"
> > > > VendorName "Monitor Vendor"
> > > > ModelName "Dell 1907FP (Digital)"
> > > > DisplaySize 380 300
> > > > ### Comment all HorizSync and VertSync values to use DDC:
> > > > HorizSync 30.0 - 81.0
> > > > VertRefresh 56.0 - 76.0
> > > > Option "dpms"
> > > > EndSection
> > > >
> > > > Section "Device"
> > > > Identifier "Videocard0"
> > > > Driver "radeon"
> > > > VendorName "Videocard vendor"
> > > > BoardName "ATI Technologies Inc RV370 5B62 [Radeon X600
> > > > (PCIE)]"
> > > > EndSection
> > > >
> > > > Section "Screen"
> > > > Identifier "Screen0"
> > > > Device "Videocard0"
> > > > Monitor "Monitor0"
> > > > DefaultDepth 24
> > > > SubSection "Display"
> > > > Viewport 0 0
> > > > Depth 16
> > > > Modes "800x600" "640x480"
> > > > EndSubSection
> > > > SubSection "Display"
> > > > Viewport 0 0
> > > > Depth 24
> > > > Modes "1280x1024"
> > > > EndSubSection
> > > > EndSection
> > > >
> > > > Section "DRI"
> > > > Group 0
> > > > Mode 0666
> > > > EndSection
> > > >
> > > >
> > > >
> > > > On Thu, 24 Aug 2006, Unidata GEMPAK Support wrote:
> > > >
> > > > > >
> > > > > > Dear Steve,
> > > > > >
> > > > > > Just to clarify below, garp does work (does not crash when hitting
> > > > > > clear, reset) on the new Solaris10 with the binary 5.9.3 install.
> > > > > > It is
> > > > > > just my new Linux Fedora5 boxes having problems, which is not good
> > > > > > for the
> > > > > > new weather lab and classes starting next week. I am using the same
> > > > > > datatype.tbl and garp defaults for both Solaris and Linux. The
> > > > > > Linux has
> > > > > > 2Gb of RAM and I increased the limits to unlimited, in case that
> > > > > > was an
> > > > > > issue.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > >
> > > > >
> > > > > Brian,
> > > > >
> > > > > The error you sent previously indicates that the problem lies within
> > > > > a call to
> > > > > the X library. Do you know if you are using the Xorg
> > > > > server/libraries on your FC5 boxes?
> > > > >
> > > > > Steve Chiswell
> > > > > Unidata User Support
> > > > > > On Wed, 23 Aug 2006 address@hidden wrote:
> > > > > >
> > > > > > >
> > > > > > > Dear Steve,
> > > > > > >
> > > > > > > I fixed the datatype and nexrad ingest below. Thanks....
> > > > > > >
> > > > > > > Now I have one remaining garp problem on my linux (fedora core 5)
> > > > > > > binary
> > > > > > > install version of 5.9.3. Garp loads fine and I can overlay
> > > > > > > things;
> > > > > > > however, if I overlay two different types of data (surface on
> > > > > > > sat, model
> > > > > > > on sat, sfc on radar, etc...) and then press clear or reset, garp
> > > > > > > crashes
> > > > > > > with the error below. If I overlay within the same group (model
> > > > > > > on model)
> > > > > > > and hit clear, it does not crash. Any ideas what could cause this?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > metlab>>ntl &
> > > > > > > [1] 1069
> > > > > > > metlab>>Resource File: /home/gempak/GEMPAK5.9.3/resource/Ntop
> > > > > > > graphic, satellite, radar, fax -- 33 95 20 2
> > > > > > > Invoke ... /home/gempak/GEMPAK5.9.3/os/linux/bin/garp
> > > > > > > G A R P - v2.1 starting...
> > > > > > > !!!!!Whoa!!!!!! Free() got a 0xx
> > > > > > > *** glibc detected ***
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp: double
> > > > > > > free or corruption (!prev): 0x112304f0 ***
> > > > > > > ======= Backtrace: =========
> > > > > > > /lib/libc.so.6[0xb05f18]
> > > > > > > /lib/libc.so.6(__libc_free+0x78)[0xb093ef]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a14c2]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x809fad8]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x809fb4e]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a0874]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a0901]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a80ff]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x8058695]
> > > > > > > /usr/lib/libXt.so.6(XtCallCallbackList+0x123)[0x73aa63]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x82404ef]
> > > > > > > /usr/lib/libXt.so.6[0x770b11]
> > > > > > > /usr/lib/libXt.so.6(_XtTranslateEvent+0x2e3)[0x7711e3]
> > > > > > > /usr/lib/libXt.so.6(XtDispatchEventToWidget+0x4f4)[0x748cf4]
> > > > > > > /usr/lib/libXt.so.6[0x74947a]
> > > > > > > /usr/lib/libXt.so.6(XtDispatchEvent+0xc7)[0x748347]
> > > > > > > /usr/lib/libXt.so.6(XtAppMainLoop+0x4c)[0x7484fc]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x8051fd6]
> > > > > > > /lib/libc.so.6(__libc_start_main+0xdc)[0xab7724]
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x8051c51]
> > > > > > > ======= Memory map: ========
> > > > > > > 00101000-00109000 r-xp 00000000 fd:00 3854915
> > > > > > > /usr/lib/libXrender.so.1.3.0
> > > > > > > 00109000-0010a000 rwxp 00007000 fd:00 3854915
> > > > > > > /usr/lib/libXrender.so.1.3.0
> > > > > > > 00112000-0011b000 r-xp 00000000 fd:00 3855288
> > > > > > > /usr/lib/libXcursor.so.1.0.2
> > > > > > > 0011b000-0011c000 rwxp 00008000 fd:00 3855288
> > > > > > > /usr/lib/libXcursor.so.1.0.2
> > > > > > > 0011e000-00122000 r-xp 00000000 fd:00 3855241
> > > > > > > /usr/lib/libXfixes.so.3.0.0
> > > > > > > 00122000-00123000 rwxp 00003000 fd:00 3855241
> > > > > > > /usr/lib/libXfixes.so.3.0.0
> > > > > > > 0021f000-00235000 r-xp 00000000 fd:00 3857605
> > > > > > > /usr/lib/libXmu.so.6.2.0
> > > > > > > 00235000-00236000 rwxp 00016000 fd:00 3857605
> > > > > > > /usr/lib/libXmu.so.6.2.0
> > > > > > > 006e0000-006f0000 r-xp 00000000 fd:00 3857123
> > > > > > > /usr/lib/libXpm.so.4.11.0
> > > > > > > 006f0000-006f1000 rwxp 00010000 fd:00 3857123
> > > > > > > /usr/lib/libXpm.so.4.11.0
> > > > > > > 0072d000-00782000 r-xp 00000000 fd:00 3857482
> > > > > > > /usr/lib/libXt.so.6.0.0
> > > > > > > 00782000-00786000 rwxp 00054000 fd:00 3857482
> > > > > > > /usr/lib/libXt.so.6.0.0
> > > > > > > 007bc000-007d4000 r-xp 00000000 fd:00 3855094
> > > > > > > /usr/lib/libg2c.so.0.0.0
> > > > > > > 007d4000-007d5000 rwxp 00017000 fd:00 3855094
> > > > > > > /usr/lib/libg2c.so.0.0.0
> > > > > > > 007d5000-007d8000 rwxp 007d5000 00:00 0
> > > > > > > 009e1000-009ec000 r-xp 00000000 fd:00 2219555
> > > > > > > /lib/libgcc_s-4.1.1-20060525.so.1
> > > > > > > 009ec000-009ed000 rwxp 0000a000 fd:00 2219555
> > > > > > > /lib/libgcc_s-4.1.1-20060525.so.1
> > > > > > > 00a84000-00a85000 r-xp 00a84000 00:00 0 [vdso]
> > > > > > > 00a85000-00a9e000 r-xp 00000000 fd:00 2219522 /lib/ld-2.4.so
> > > > > > > 00a9e000-00a9f000 r-xp 00018000 fd:00 2219522 /lib/ld-2.4.so
> > > > > > > 00a9f000-00aa0000 rwxp 00019000 fd:00 2219522 /lib/ld-2.4.so
> > > > > > > 00aa2000-00bcf000 r-xp 00000000 fd:00 2219538 /lib/libc-2.4.so
> > > > > > > 00bcf000-00bd1000 r-xp 0012d000 fd:00 2219538 /lib/libc-2.4.so
> > > > > > > 00bd1000-00bd2000 rwxp 0012f000 fd:00 2219538 /lib/libc-2.4.so
> > > > > > > 00bd2000-00bd5000 rwxp 00bd2000 00:00 0
> > > > > > > 00bd7000-00bfa000 r-xp 00000000 fd:00 2219545 /lib/libm-2.4.so
> > > > > > > 00bfa000-00bfb000 r-xp 00022000 fd:00 2219545 /lib/libm-2.4.so
> > > > > > > 00bfb000-00bfc000 rwxp 00023000 fd:00 2219545 /lib/libm-2.4.so
> > > > > > > 00bfe000-00c00000 r-xp 00000000 fd:00 2219549 /lib/libdl-2.4.so
> > > > > > > 00c00000-00c01000 r-xp 00001000 fd:00 2219549 /lib/libdl-2.4.so
> > > > > > > 00c01000-00c02000 rwxp 00002000 fd:00 2219549 /lib/libdl-2.4.so
> > > > > > > 00c04000-00cfd000 r-xp 00000000 fd:00 3854913
> > > > > > > /usr/lib/libX11.so.6.2.0
> > > > > > > 00cfd000-00d01000 rwxp 000f9000 fd:00 3854913
> > > > > > > /usr/lib/libX11.so.6.2.0
> > > > > > > 00d03000-00d08000 r-xp 00000000 fd:00 3854911
> > > > > > > /usr/lib/libXdmcp.so.6.0.0
> > > > > > > 00d08000-00d09000 rwxp 00004000 fd:00 3854911
> > > > > > > /usr/lib/libXdmcp.so.6.0.0
> > > > > > > 00d0b000-00d0d000 r-xp 00000000 fd:00 3854909
> > > > > > > /usr/lib/libXau.so.6.0.0
> > > > > > > 00d0d000-00d0e000 rwxp 00001000 fd:00 3854909
> > > > > > > /usr/lib/libXau.so.6.0.0
> > > > > > > 00d10000-00d1f000 r-xp 00000000 fd:00 3854984
> > > > > > > /usr/lib/libXext.so.6.4.0
> > > > > > > 00d1f000-00d20000 rwxp 0000e000 fd:00 3854984
> > > > > > > /usr/lib/libXext.so.6.4.0
> > > > > > > 00d3d000-00d44000 r-xp 00000000 fd:00 3860439
> > > > > > > /usr/lib/libXp.so.6.2.0
> > > > > > > 00d44000-00d45000 rwxp 00007000 fd:00 3860439
> > > > > > > /usr/lib/libXp.so.6.2.0
> > > > > > > 00d4d000-00d64000 r-xp 00000000 fd:00 3856013
> > > > > > > /usr/lib/libICE.so.6.3.0
> > > > > > > 00d64000-00d65000 rwxp 00016000 fd:00 3856013
> > > > > > > /usr/lib/libICE.so.6.3.0
> > > > > > > 00d65000-00d67000 rwxp 00d65000 00:00 0
> > > > > > > 00d69000-00d71000 r-xp 00000000 fd:00 3856019
> > > > > > > /usr/lib/libSM.so.6.0.0
> > > > > > > 00d71000-00d72000 rwxp 00008000 fd:00 3856019
> > > > > > > /usr/lib/libSM.so.6.0.0
> > > > > > > 08048000-0837d000 r-xp 00000000 fd:01 44793968
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp
> > > > > > > 0837d000-083a6000 rw-p 00334000 fd:01 44793968
> > > > > > > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp
> > > > > > > 083a6000-108bf000 rw-p 083a6000 00:00 0
> > > > > > > 10fb7000-11276000 rw-p 10fb7000 00:00 0 [heap]
> > > > > > > b6fc6000-b7327000 rw-p b6fc6000 00:00 0
> > > > > > > b7600000-b7621000 rw-p b7600000 00:00 0
> > > > > > > b7621000-b7700000 ---p b7621000 00:00 0
> > > > > > > b7773000-b7bee000 rw-p b7773000 00:00 0
> > > > > > > b7cee000-b7eee000 r--p 00000000 fd:00 3854901
> > > > > > > /usr/lib/locale/locale-archive
> > > > > > > b7eee000-b7ef1000 rw-p b7eee000 00:00 0
> > > > > > > b7eff000-b7f06000 r--s 00000000 fd:00 3917058
> > > > > > > /usr/lib/gconv/gconv-modules.cache
> > > > > > > b7f06000-b7f09000 rw-p b7f06000 00:00 0
> > > > > > > bf5a4000-bf888000 rwxp bf5a4000 00:00 0 [stack]
> > > > > > > bf888000-bf88b000 rw-p bf888000 00:00 0
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, 18 Aug 2006, Unidata GEMPAK Support wrote:
> > > > > > >
> > > > > > > > >
> > > > > > > > > Dear Support,
> > > > > > > > >
> > > > > > > > > I have two questions related to garp that was recently
> > > > > > > > > installed on a new
> > > > > > > > > Sun with Solaris10.
> > > > > > > > >
> > > > > > > > > 1. I have done a binary install of gempak 5.9.3. It seems to
> > > > > > > > > be working
> > > > > > > > > for the most part. It is decoding the ldm ingest (creating
> > > > > > > > > gem files) and
> > > > > > > > > I can run all applications. The only problem is garp. When I
> > > > > > > > > hit the model
> > > > > > > > > horiz and cross section button garp freezes and crashes with
> > > > > > > > > a 700 mb core
> > > > > > > > > file. I thought it might be a garp-defaults issue (since I
> > > > > > > > > copied in one
> > > > > > > > > I have used previously), but it also crashes with the
> > > > > > > > > garp-defaults that
> > > > > > > > > came with gempak5.9.3. I also copied over my older 5.6.F
> > > > > > > > > binaries from
> > > > > > > > > another Sun, and garp works fine with this, so it is
> > > > > > > > > something with 5.9.3?
> > > > > > > >
> > > > > > > > Brian,
> > > > > > > >
> > > > > > > > It may be an effect of changes since the 5.6.F distribution
> > > > > > > > related to using the
> > > > > > > > datatype.tbl aliases file for model data sets rather than the
> > > > > > > > Garp_defaults
> > > > > > > > pattern matching. The Garp defaults file method required all
> > > > > > > > data sets be in a single grid
> > > > > > > > directory, but that isn't really feasible now, especially for
> > > > > > > > larger data sets where
> > > > > > > > individual forecast times may be in seperate files. Are you
> > > > > > > > using the
> > > > > > > > fle naming as distributed with 5.9.3 for your LDM actions, or
> > > > > > > > are you using older
> > > > > > > > configurations? Garp may get upset withe the default data set
> > > > > > > > "eta" if
> > > > > > > > there are no data sets that match that name (the datatype.tbl
> > > > > > > > file has an alias
> > > > > > > > for eta, but it might need to be modified depending on wthere
> > > > > > > > you are using older decoder actions.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 2. I am looking for a way to get the CONUS nexrad data into
> > > > > > > > > garp, so
> > > > > > > > > students can overlay. I am creating the fnexrad radar mosaic
> > > > > > > > > using:
> > > > > > > > > FNEXRAD ^radar_mosaic_national
> > > > > > > > > PIPE -close decoders/dcgrib2 -d
> > > > > > > > > data/gempak/logs/dcgrib_radar.log
> > > > > > > > > -e GEMTBL=/home/gempak/NAWIPS/gempak/tables
> > > > > > > > > data/gempak/radar/YYYYMMDD_radr.gem
> > > > > > > > > #
> > > > > > > > > however, since this is a gridded file, I am looking for some
> > > > > > > > > setup files
> > > > > > > > > to display in garp (so students can overlay). Not sure if
> > > > > > > > > this is the best
> > > > > > > > > approach. Actually, I was hoping that there was a CONUS NIDS
> > > > > > > > > ingest
> > > > > > > > > directly, just like for an individual site?
> > > > > > > >
> > > > > > > > I create both the grib version of the radar composite as well
> > > > > > > > as a gini image in the
> > > > > > > > FNEXRAD feed. The GINI image is 1km, and works well for
> > > > > > > > overlaying the image with
> > > > > > > > observations, contours, watched, warnings, etc.
> > > > > > > >
> > > > > > > > The Grid data set can be used to plot the radar echoes on top
> > > > > > > > of a satellite image, or
> > > > > > > > to use in gridded calculations (such as with the RUC
> > > > > > > > temperature grids to do a precipitation type).
> > > > > > > >
> > > > > > > > If you just want to look at the radar image, then the action
> > > > > > > > provided in $NAWIPS/ldm/etc/templates/pqact.gempak_nexrad is:
> > > > > > > > # png compressed 1km radar GINI format
> > > > > > > > FNEXRAD ^rad/NEXRCOMP/(...)/(...)_(........)_(....)
> > > > > > > > FILE -close
> > > > > > > > data/gempak/images/sat/NEXRCOMP/\1/\2/\2_\3_\4
> > > > > > > >
> > > > > > > > You may prefer to put that in
> > > > > > > > data/gempak/nexrad/NEXRCOMP/\1/\2/\2_\3_\4
> > > > > > > > (I actually have a link on our systems)
> > > > > > > > The original rational was that GINI was a satellite format, but
> > > > > > > > its not a critical issue now
> > > > > > > > since the color management can handle the number of colors
> > > > > > > > needed for the echo levels.
> > > > > > > >
> > > > > > > > If you are using the default actions I provide, you may already
> > > > > > > > be filing these.
> > > > > > > >
> > > > > > > > Steve Chiswell
> > > > > > > > Unidata User SUpport
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks in advance for any advice.
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Ticket Details
> > > > > > > > ===================
> > > > > > > > Ticket ID: ABG-423464
> > > > > > > > Department: Support GEMPAK
> > > > > > > > Priority: Normal
> > > > > > > > Status: Closed
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > Ticket Details
> > > > > ===================
> > > > > Ticket ID: ABG-423464
> > > > > Department: Support GEMPAK
> > > > > Priority: Normal
> > > > > Status: Closed
> > > > >
> > > > >
> > > >
> > >
> >
>
>
Ticket Details
===================
Ticket ID: ABG-423464
Department: Support GEMPAK
Priority: Critical
Status: Closed
