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

[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


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.