[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20050809: 20050808: LDM write errors from decoders
- Subject: 20050809: 20050808: LDM write errors from decoders
- Date: Tue, 09 Aug 2005 15:45:10 -0600
>From: Nancy Selover <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200508092108.j79L8wjo024617
>Steve,
>
>Adding the "/" in Gemenviron helped NWX, as now I can see most of the
>messages and products. I still get the error message, which has the
>leading "/", but it only happens to certain products, perhaps those are
>products I commented out in the pqact.gempak_nwx file.
Nancy,
Not every product in NWX is available all the time. A few will only be
broadcast 1x per month (like the 30 day outlook). Some are only broadcast when
a particular event occurs, such as a hurricane local statement.
It sounds like things are normal, unless you have a common product like a
Zone forecast, MOS, etc which do not appear after at least one day.
>
>The bigger problem is I am still not getting the surface or upper air
>obs or models or satellite images to write to directories. The
>connection is they are all decoded files. I have checked the
>pqact.gempak_decoders file, and there is no leading "/" for any of
>entries in that file. They all say, for example:
>
>HDS ^[YZ].[A]... KWBH
> PIPE decoders/dcgrib2 -d data/gempak/logs/dcgrib2_MRF.log
> -e GEMTBL=/huser/gempak/GEMPAK5.8.2a/gempak/tables
>
>But, there is NO log directory under /var/data/gempak
>so I can't see the logs.
The LDM uses relative (to $LDMHOME which was set when LDM was built).
You should copy of link your $GEMEXE/dc* programs to an ~ldm/decoders
directory (which you have to create). You will also want to copy or link
the shell script $NAWIPS/bin/scripts/dcgunzip to ~ldm/decoders.
If you are receiving the CRAFT feed you will want to copy or link
$NAWIPS/bin/scripts/dccraft_move to an ~ldm/util directory.
The decoders will create their directories, but if they are failing earlier
than that point, you can create the ~ldm/data/gempak/logs directory
by hand. You can always try launching a decoder from the command line,
such as "dcmetr -h". It should print out some help information. If it
fails, then something more basic is wrong.
>
>Also, the other type of entry without the leading "/" is like this:
>
>WMO ^S[AP]
> PIPE decoders/dcmetr -a 500 -m 72 -s sfmetar_sa.tbl
> -d data/gempak/logs/dcmetr.log
> -e GEMTBL=/huser/gempak/GEMPAK5.8.2a/tables
> data/gempak/surface/YYYYMMDD_sao.gem
>
>I did not edit these, except to update the version to 5.8.2a
>
>I am also not getting the satellite imagery and I have set up the
>nsat_links script in the crontab and checked the path.
nsat_links shouldn't be needed, unless you aren't going to use gempak naming
for the pnga2area actions- but rather file to AREAxxxx McIDAS style names.
I haven't used nsat_links for about 4 years. Tom now supports the
GEMPAK style file name in the McIDAS distribution.
>
>The radar are coming in, but Garp can't see the directory structure.
Your Level III data should be found under
$RAD/NIDS/
where $RAD should be set in Gemenviron to $GEMDATA/nexrad.
Steve Chiswell
Unidata User Support
>
>Nancy
>
>
>-----Original Message-----
>From: Unidata Support [mailto:address@hidden]
>Sent: Tuesday, August 09, 2005 9:54 AM
>To: Nancy Selover
>Cc: Unidata Support
>Subject: 20050808: LDM write errors from decoders
>
>
>Nancy,
>
>I can help you with GEMPAK decoders and program access to the data.
>
>For the NWX access problems, check your GEMDATA environmantal variable
>as configured in your $NAWIPS/Gemenviron file. That should point to your
>/var/data/ldm/gempak directory. In looking at the error message you show
>below, you are missing the leading "/" in the directory name, and I need
>to know if that was a typo, or the root of the problem.
>
>The environmental variable $TEXT_DATA will be set to $GEMDATA/nwx in
>Gemenviron, so this also relieas on the GEMDATA variable being correct.
>
>Steve Chiswell
>Unidata User Support
>
>
>>From: Nancy Selover <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200508090157.j791vPjo029601
>
>>This is a multi-part message in MIME format.
>>
>>--Boundary_(ID_mRLemyhH004n7qDStD3mNQ)
>>Content-type: multipart/alternative;
>> boundary="Boundary_(ID_ithdHyIr2omZeORHgiZROw)"
>>
>>
>>--Boundary_(ID_ithdHyIr2omZeORHgiZROw)
>>Content-type: text/plain; charset="us-ascii"
>>Content-transfer-encoding: quoted-printable
>>
>>
>>Gempak can't find the LDM files. We finally got LDM running after
>>commenting out the network IP address, and it's busy writing the NWX
>>and Radar data. However, Gempak cannot read any of it. Garp can't
>>find the directory structure, although the NIDS files are exactly where
>
>>they should be. The NWX files are all there and show up in the NWX
>>program, but when I click on any of the files, I get:
>>NWX: Error scanning directory 'var/data/ldm/gempak/nwx/pub_prod/SFT'
>>or which ever product I selected. =20
>>
>>When I looked at the directory structure, data is linked to
>>/var/data/ldm and /var/data is owned by root, while /var/data/ldm is
>
>>owned by ldm and the ldm and gempak users all have permissions. =20 =20
>
>>I can't find this on the e-mail archives. I have tried checking all
>>the configuration files to make sure they are sending the data to the
>>right place, but I can't find anything wrong. Attached is a piece of
>>the log file from the ldmd.log, showing that there are write errors
>>from the decoders, as well as from the Mcidas satellite imagery script.
>
>>I haven't got NSAT_LINKS set yet, so I'm not particularly worried about
>
>>that yet. But I should be able to get the surface and upper air obs.
>>I am using the configuration files from mothra (LDM 6.10.0) on the new
>>version, but I changed the version number for GEMPAK from 5.7.4 to
>>5.8.2a throughout. It was easier than trying to find the changes in
>>products from the old file to the new file. =20
>>
>>Sorry to be such a pest, but this is our first time setting the
>>programs up from scratch on a new machine (FC3).
>>
>> <<writeerrors.txt>>=20
>>
>>Our older machine crashed that was running Gempak, so I really need to
>>get this running. If it's something really simple and stupid I did,
>>that's great, just let me know. If there's an e-mail archive that
>>covers this, send me the link or the exact subject line. If you need
>>to poke around in the machine, let me know that, and I'll call you with
>
>>the password.
>>
>>Thank you,
>>Nancy
>>
>>Nancy J. Selover=20
>>Asst. State Climatologist=20
>>Office of Climatology tel: 480-965-0580=20 Arizona State University
>>fax: 480-965-1473=20 Tempe, AZ 85287-1508 e-mail: address@hidden=20
>>
>>
>>
>>--Boundary_(ID_ithdHyIr2omZeORHgiZROw)
>>Content-type: text/html; charset="us-ascii"
>>Content-transfer-encoding: quoted-printable
>>
>><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META
>>HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>>charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange
>>Server version = 6.5.7226.0"> <TITLE>LDM write errors from
>>decoders</TITLE> </HEAD> <BODY>
>><!-- Converted from text/rtf format --> <BR>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial">Gempak can't find the LDM files.
>
>>= We finally got LDM running after commenting out the network IP
>>address, = and it's busy writing the NWX and Radar data. However,
>
>>Gempak = cannot read any of it. Garp can't find the directory
>>structure, = although the NIDS files are exactly where they should
>>be. The NWX = files are all there and show up in the NWX program,
>
>>but when I click on = any of the files, I get:</FONT></P>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial">NWX: Error scanning directory =
>>'var/data/ldm/gempak/nwx/pub_prod/SFT' or which ever product I =
>>selected. </FONT> </P>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial">When I looked at the directory =
>>structure, data is linked to /var/data/ldm and
>>= /var/data is owned by root, while /var/data/ldm is owned
>>by = ldm and the ldm and gempak users all have permissions.
>></FONT></P>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial"> </FONT>
>>
>><BR><FONT SIZE=3D2 FACE=3D"Arial">I can't find this on the e-mail =
>>archives. I have tried checking all the configuration files to =
>>make sure they are sending the data to the right place, but I can't
>>find = anything wrong. Attached is a piece of the log file from
>>the = ldmd.log, showing that there are write errors from the decoders,
>>as well = as from the Mcidas satellite imagery script. I
>>haven’t got = NSAT_LINKS set yet, so I'm not particularly worried
>
>>about that = yet. But I should be able to get the surface and
>>upper air = obs. I am using the configuration files from mothra
>>(LDM 6.10.0) = on the new version, but I changed the version number for
>
>>GEMPAK from =
>>5.7.4 to 5.8.2a throughout. It was easier than trying to find the
>
>>= changes in products from the old file to the new file.
>></FONT></P>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial">Sorry to be such a pest, but this is =
>
>>our first time setting the programs up from scratch on a new machine =
>>(FC3).</FONT> </P>
>>
>><P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
>><<writeerrors.txt>> </FONT> </P>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial">Our older machine crashed that was =
>>running Gempak, so I really need to get this running. If it's =
>>something really simple and stupid I did, that's great, just let me =
>>know. If there's an e-mail archive that covers this, send me the
>>= link or the exact subject line. If you need to poke around in
>>the = machine, let me know that, and I'll call you with the =
>>password.</FONT></P>
>>
>><P><FONT SIZE=3D2 FACE=3D"Arial">Thank you,</FONT>
>>
>><BR><FONT SIZE=3D2 FACE=3D"Arial">Nancy</FONT> </P>
>>
>><P><B><I><FONT SIZE=3D2 FACE=3D"Arial">Nancy J. =
>>Selover</FONT></I></B><I></I><FONT FACE=3D"Times New Roman"><BR>
>></FONT><I></I><I><FONT SIZE=3D2 FACE=3D"Arial">Asst. State =
>>Climatologist</FONT></I><FONT FACE=3D"Times New Roman"><BR>
>></FONT><FONT SIZE=3D2 FACE=3D"Arial">Office of Climatology tel: =
>>480-965-0580</FONT><FONT FACE=3D"Times New Roman"><BR> </FONT><FONT
>>SIZE=3D2 FACE=3D"Arial">Arizona State University fax: =
>>480-965-1473</FONT><FONT FACE=3D"Times New Roman"><BR> </FONT><FONT
>>SIZE=3D2 FACE=3D"Arial">Tempe, AZ 85287-1508 e-mail: =
>>address@hidden</FONT><FONT FACE=3D"Times New Roman"> </FONT> </P> <BR>
>>
>></BODY>
>></HTML>=
>>
>>--Boundary_(ID_ithdHyIr2omZeORHgiZROw)--
>>
>>--Boundary_(ID_mRLemyhH004n7qDStD3mNQ)
>>Content-type: text/plain; name="writeerrors.txt"
>>Content-transfer-encoding: base64
>>Content-disposition: attachment; filename="writeerrors.txt"
>>Content-description: writeerrors.txt
>>
>>QXVnIDA5IDAwOjEyOjU2IGdvZHppbGxhIGNpcnBbNDY1MV06IERlc2lyZWQgcHJvZHVjdCB
>>jbGFz
>>czogMjAwNTA4MDgyMzEyNTYuNDY2IFRTX0VORFQge3tFWFAsICAiLioifX0gDQpBdWcgMDk
>>gMDA6
>>MTI6NTYgZ29kemlsbGEgY2lycFs0NjUxXTogQ29ubmVjdGVkIHRvIHVwc3RyZWFtIExETS0
>>2IA0K
>>QXVnIDA5IDAwOjEyOjU2IGdvZHppbGxhIGNpcnBbNDY1MV06IEVSUk9SOiByZXF1ZXN0ZXI
>>2LmM6
>>Mjc4OiBVcHN0cmVhbSBMRE0gZGlkbid0IHJlcGx5IHRvIEZFRURNRSByZXF1ZXN0OyByZXF
>>1ZXN0
>>ZXI2LmM6Mjc4OiBSUEM6IEF1dGhlbnRpY2F0aW9uIGVycm9yOyB3aHkgPSAoYXV0aGVudGl
>>jYXRp
>>b24gZXJyb3IgNSkgDQpBdWcgMDkgMDA6MTI6NTkgZ29kemlsbGEgcHFhY3RbNDY0NF06IGN
>>oaWxk
>>IDUxNTcgZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF1ZyAwOSAwMDoxMzowMiBnb2R6aWx
>>sYSBw
>>cWFjdFs0NjQ0XTogY2hpbGQgNTE2MiBleGl0ZWQgd2l0aCBzdGF0dXMgMTI2IA0KQXVnIDA
>>5IDAw
>>OjEzOjA1IGdvZHppbGxhIHBxYWN0WzQ2NDRdOiBjaGlsZCA1MTY3IGV4aXRlZCB3aXRoIHN
>>0YXR1
>>cyAxMjYgDQpBdWcgMDkgMDA6MTM6MDggZ29kemlsbGEgcHFhY3RbNDY0NF06IGNoaWxkIDU
>>xNzIg
>>ZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF1ZyAwOSAwMDoxMzoxNCBnb2R6aWxsYSBwcWF
>>jdFs0
>>NjQ0XTogY2hpbGQgNTE3NyBleGl0ZWQgd2l0aCBzdGF0dXMgMTI2IA0KQXVnIDA5IDAwOjE
>>zOjE1
>>IGdvZHppbGxhIHBxYWN0WzQ2NDddOiBwYnVmX2ZsdXNoICgzKSB3cml0ZTogQnJva2VuIHB
>>pcGUg
>>DQpBdWcgMDkgMDA6MTM6MTUgZ29kemlsbGEgcHFhY3RbNDY0N106IHBpcGVfcHV0OiAtY2x
>>vc2Vk
>>ZWNvZGVycy9wbmdhMmFyZWEtdmwvdXNyL2xvY2FsL2xkbS9sb2dzL2xkbS1tY2lkYXMubG9
>>nLWFl
>>dGMvU0FUQU5OT1QtYmV0Yy9TQVRCQU5EL3Zhci9kYXRhL2xkbS9nZW1wYWsvaW1hZ2VzL3N
>>hdC9H
>>T0VTLTEwLzhrbS9XVi9XVl8yMDA1MDgwOV8wMDAwIHdyaXRlIGVycm9yIA0KQXVnIDA5IDA
>>wOjEz
>>OjE1IGdvZHppbGxhIHBxYWN0WzQ2NDddOiBwaXBlX3Byb2RwdXQ6IHRyeWluZyBhZ2FpbiA
>>NCkF1
>>ZyAwOSAwMDoxMzoxNiBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogcGJ1Zl9mbHVzaCAoMykgd3J
>>pdGU6
>>IEJyb2tlbiBwaXBlIA0KQXVnIDA5IDAwOjEzOjE2IGdvZHppbGxhIHBxYWN0WzQ2NDddOiB
>>waXBl
>>X3B1dDogLWNsb3NlZGVjb2RlcnMvcG5nYTJhcmVhLXZsL3Vzci9sb2NhbC9sZG0vbG9ncy9
>>sZG0t
>>bWNpZGFzLmxvZy1hZXRjL1NBVEFOTk9ULWJldGMvU0FUQkFORC92YXIvZGF0YS9sZG0vZ2V
>>tcGFr
>>L2ltYWdlcy9zYXQvR09FUy0xMC84a20vV1YvV1ZfMjAwNTA4MDlfMDAwMCB3cml0ZSBlcnJ
>>vciAN
>>CkF1ZyAwOSAwMDoxMzoxNiBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogY2hpbGQgNTE4MiBleGl
>>0ZWQg
>>d2l0aCBzdGF0dXMgMTI2IA0KQXVnIDA5IDAwOjEzOjE2IGdvZHppbGxhIHBxYWN0WzQ2NDd
>>dOiBj
>>aGlsZCA1MTg3IGV4aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MTcgZ29
>>kemls
>>bGEgcHFhY3RbNDY0NF06IGNoaWxkIDUxOTUgZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF
>>1ZyAw
>>OSAwMDoxMzoxNyBnb2R6aWxsYSBwcWFjdFs0NjQ0XTogY2hpbGQgNTE5MiBleGl0ZWQgd2l
>>0aCBz
>>dGF0dXMgMTI2IA0KQXVnIDA5IDAwOjEzOjE3IGdvZHppbGxhIHBxYWN0WzQ2NDRdOiBjaGl
>>sZCA1
>>MTk4IGV4aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MTcgZ29kemlsbGE
>>gcHFh
>>Y3RbNDY0NF06IGNoaWxkIDUyMDcgZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF1ZyAwOSA
>>wMDox
>>MzoxNyBnb2R6aWxsYSBwcWFjdFs0NjQ0XTogY2hpbGQgNTIxMCBleGl0ZWQgd2l0aCBzdGF
>>0dXMg
>>MTI2IA0KQXVnIDA5IDAwOjEzOjE4IGdvZHppbGxhIHBxYWN0WzQ2NDRdOiBjaGlsZCA1MjE
>>zIGV4
>>aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MjEgZ29kemlsbGEgcHFhY3R
>>bNDY0
>>N106IHBidWZfZmx1c2ggKDMpIHdyaXRlOiBCcm9rZW4gcGlwZSANCkF1ZyAwOSAwMDoxMzo
>>yMSBn
>>b2R6aWxsYSBwcWFjdFs0NjQ3XTogcGlwZV9wdXQ6IC1jbG9zZWRlY29kZXJzL3BuZ2EyYXJ
>>lYS12
>>bC91c3IvbG9jYWwvbGRtL2xvZ3MvbGRtLW1jaWRhcy5sb2ctYWV0Yy9TQVRBTk5PVC1iZXR
>>jL1NB
>>VEJBTkQvdmFyL2RhdGEvbGRtL2dlbXBhay9pbWFnZXMvc2F0L0dPRVMtMTAvNGttL1ZJUy9
>>WSVNf
>>MjAwNTA4MDlfMDAwMCB3cml0ZSBlcnJvciANCkF1ZyAwOSAwMDoxMzoyMSBnb2R6aWxsYSB
>>wcWFj
>>dFs0NjQ3XTogcGlwZV9wcm9kcHV0OiB0cnlpbmcgYWdhaW4gDQpBdWcgMDkgMDA6MTM6MjE
>>gZ29k
>>emlsbGEgcHFhY3RbNDY0N106IHBidWZfZmx1c2ggKDMpIHdyaXRlOiBCcm9rZW4gcGlwZSA
>>NCkF1
>>ZyAwOSAwMDoxMzoyMSBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogcGlwZV9wdXQ6IC1jbG9zZWR
>>lY29k
>>ZXJzL3BuZ2EyYXJlYS12bC91c3IvbG9jYWwvbGRtL2xvZ3MvbGRtLW1jaWRhcy5sb2ctYWV
>>0Yy9T
>>QVRBTk5PVC1iZXRjL1NBVEJBTkQvdmFyL2RhdGEvbGRtL2dlbXBhay9pbWFnZXMvc2F0L0d
>>PRVMt
>>MTAvNGttL1ZJUy9WSVNfMjAwNTA4MDlfMDAwMCB3cml0ZSBlcnJvciANCkF1ZyAwOSAwMDo
>>xMzoy
>>MSBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogY2hpbGQgNTIyMiBleGl0ZWQgd2l0aCBzdGF0dXM
>>gMTI2
>>IA0KQXVnIDA5IDAwOjEzOjIxIGdvZHppbGxhIHBxYWN0WzQ2NDddOiBjaGlsZCA1MjI3IGV
>>4aXRl
>>ZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MjIgZ29kemlsbGEgcHFhY3RbNDY
>>0N106
>>IHBidWZfZmx1c2ggKDMpIHdyaXRlOiBCcm9rZW4gcGlwZSANCkF1ZyAwOSAwMDoxMzoyMiB
>>nb2R6
>>aWxsYSBwcWFjdFs0NjQ3XTogcGlwZV9wdXQ6IC1jbG9zZWRlY29kZXJzL3BuZ2EyYXJlYS1
>>2bC91
>>c3IvbG9jYWwvbGRtL2xvZ3MvbGRtLW1jaWRhcy5sb2ctYWV0Yy9TQVRBTk5PVC1iZXRjL1N
>>BVEJB
>>TkQvdmFyL2RhdGEvbGRtL2dlbXBhay9pbWFnZXMvc2F0L0dPRVMtMTAvNGttL0lSL0lSXzI
>>wMDUw
>>ODA5XzAwMDAgd3JpdGUgZXJyb3IgDQpBdWcgMDkgMDA6MTM6MjIgZ29kemlsbGEgcHFhY3R
>>bNDY0
>>N106IHBpcGVfcHJvZHB1dDogdHJ5aW5nIGFnYWluIA0KQXVnIDA5IDAwOjEzOjIyIGdvZHp
>>pbGxh
>>IHBxYWN0WzQ2NDddOiBwYnVmX2ZsdXNoICgzKSB3cml0ZTogQnJva2VuIHBpcGUgDQpBdWc
>>gMDkg
>>MDA6MTM6MjIgZ29kemlsbGEgcHFhY3RbNDY0N106IHBpcGVfcHV0OiAtY2xvc2VkZWNvZGV
>>ycy9w
>>bmdhMmFyZWEtdmwvdXNyL2xvY2FsL2xkbS9sb2dzL2xkbS1tY2lkYXMubG9nLWFldGMvU0F
>>UQU5O
>>T1QtYmV0Yy9TQVRCQU5EL3Zhci9kYXRhL2xkbS9nZW1wYWsvaW1hZ2VzL3NhdC9HT0VTLTE
>>wLzRr
>>bS9JUi9JUl8yMDA1MDgwOV8wMDAwIHdyaXRlIGVycm9yIA0KQXVnIDA5IDAwOjEzOjIyIGd
>>vZHpp
>>bGxhIHBxYWN0WzQ2NDddOiBjaGlsZCA1MjMyIGV4aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQo
>>=
>>
>>--Boundary_(ID_mRLemyhH004n7qDStD3mNQ)--
>>
>--
>************************************************************************
>Unidata User Support UCAR Unidata
>(303)497-8643 P.O. Box
>address@hidden Boulder, CO
>------------------------------------------------------------------------
>Unidata WWW Service
>------------------------------------------------------------------------
>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.
>
--
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.