[McIDAS #STG-808468]: Conversion of mcidas area to shapefile format

Hi Martha,

re:
> You asked about our version of McIDAS on the NOAAPORT decoder; it is
> 2008c.

Very good, thanks.

> I finally managed to get the MySQL database set up; I had a great deal
> of difficulty as resetting the password using the method you gave me
> would seem to work, then when I tried to use the password, it refused access.
]
This is very odd indeed!

> Just FYI, what I did was delete the three Packages mysql-server,
> mysql-client, and mysql-devel which I had already installed, and after
> fishing on the Internet found that I should delete
> /var/lib/mysql as well as it was apparently corrupted.

OK.  I had not run into this before.

> I re-installed the mysql packages.  The first time one runs
> "/etc/init.d/mysqld start" that re-creates /var/lib/mysql if
> it isn't there. Then I used the command
>
> mysqladmin -u root password "xxxxx"
>
> to set the root password, as a MySQL book I have recommended.

OK.

> I then did the rest of the steps, "gribadmin makedb" and restarted DMBIN

Questions:

- 'gribadmin makedb' run as 'mcidas' worked without error?

- what messages do you see in the Unidata McIDAS XCD log file?

  The log file location and name is set in the copy of 'xcd_run' that
  you would have copied over to a directory in 'ldm's PATH.

  I have all Unidata McIDAS-XCD installations set to use
  ~ldm/logs/XCD_START.LOG, but your setup may be different.

> But when I issue the command "gribadmin latest" I see nothing even
> though the data are coming over.  ("gribadmin fields" shows the fields, and 
> the
> Database file /var/lib/mysql/mcrtgrib exists as well), but the database
> doesn't seem to be populating.

OK.  This indicates that the MySQL access works from the 'mcidas' account.
Since the XCD decoding is run from the 'ldm' account, my next questions are:

- are 'mcidas' and 'ldm' in the same group?
- can 'ldm' read/write files from the MCDATA directory of 'mcidas'

> Also, the xcdscour method won't work for us, as we get errors "argument
> list too long" when it's run (we have seen this error before, when there
> are too many files for an ls or rm command to process;

Hmm...  you _will_ want to be using the scouring technique embodied in
'xcdscour' as it does more than remove disk files; it scours entries
from the MySQL database also.

> when this happens I typically use a find command to pipe the files
> to be deleted to a file, then use xargs rm -fv < file to delete.)
> However, we already had scour.conf set up to clean up bufr
> And grib directories, so I modified that so that ldmadmin scour will
> keep only one day's worth of bufr and grib data.

Something is very strange here.  I routinely keep > 3 days of grib/bufr
data on disk, and I do not experience a problem with too many files
existing in a directory for a simple 'ls' or 'rm' invocation.

Questions:

- how many files are in the directory in which the grib files are being
  written?

Right now, my development machine has about 1.5 days of model data in
the ~ldm/data/mcidas/grib directory, and that represents 11713 grib/grib2
files.  'ls' has _NO_ problem with this small of a number of files; neither
does 'rm'.

Another couple of questions:

- are new grib/grib2 files being written into your mcidas/grib directory?

- if yes, do you have another process (kicked off by the LDM) writing those
  files (i.e., they are not being written by DMBIN)?

- if no, then DMBIN is partially working -- it is filing the data.  The
  question would be why the files are not being processed into the MySQL
  database.  Log messages in the XCD_START.LOG file should give us some
  clues as to why.

> So we are making progress but aren't there yet.

OK.

> And Randy wanted me to ask you, do you know if we can get the IDD conduit
> stream, which you mentioned the other day, as we would like to get GFS
> ensemble data.

This can be arranged.  Let's talk about this after we get the GRIB/GRIB
processing working.

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: STG-808468
Department: Support McIDAS
Priority: Normal
Status: Closed