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

[ldmMcidas #GZG-682445]: Local Grid file

Hi Paul,

re: where is GRID file GRID0021
> OK...I am working through some info. I will let you know if I cannot figure
> it out.

OK.

re:
> BTW Do you remember when we wrote about the 0but files about net-cdf files?
> We have them and have identified that it is the McIDAS decoders that are
> creating those issues.
> 
> These are the ldm pqact lines
> 
> FSL2    ^FSL\.NetCDF\.NOAAnet\.windprofiler\.01hr
> PIPE    -close
> proftomd -vl logs/ldm-mcidas.log
> -d /home/data/mcidas U2 WPRO 81
> 
> # 6-minute
> FSL2    ^FSL\.NetCDF\.NOAAnet\.windprofiler\.06min
> PIPE    -close
> proftomd -vl logs/ldm-mcidas.log
> -d /home/data/mcidas U6 WPR6 91
> 
> These are the files
> 
> -rw-------  1 ldm  ldm      0 Apr 17 20:54 .tmp_netcdf.7hqtI5
> -rw-------  1 ldm  ldm      0 Apr 17 20:48 .tmp_netcdf.aOtukP
> -rw-------  1 ldm  ldm      0 Apr 17 21:00 .tmp_netcdf.cVVsgX
> -rw-------  1 ldm  ldm      0 Apr 17 20:46 .tmp_netcdf.VOYP4G
> -rw-------  1 ldm  ldm      0 Apr 17 21:06 .tmp_netcdf.VXqqrY
> 
> 
> We know for sure it is the mcidas decoders doing this.

I disagree, at least, on the new climate machine.

Here is what I did to come to this conclusion:

- login to the new climate as 'ldm'

- comment out the FSL2 entries in the McIDAS pattern-action file
  that decoders wind profiler data

- verify the integrity of all pattern-action files (to make sure
  I did not make a typo):

  ldmadmin pqactcheck

- send a HUP signal to tell all pqact instances to reread their
  pattern-action files:

  ldmadmin pqactHUP

- deleted all .tmp_netcdf.* files

  cd ~ldm
  rm .tmp_netcdf.*

- in one window, I watched for the receipt of FSL2 wind profiler data:

  ldmadmin watch -f FSL2

  in a second window I could do a long listing for files named .tmp_netcdf.*:

  cd ~ldm
  ls -alt .tmp_netcdf.*

- I waited until the first 6-minute profiler product was received (from
  the 'ldmadmin watch -f FSL2' instance running in one window) and
  immediately checked for the existence of a .tmp_netcdf.* file; there
  was one.

  I waited for indication of receipt of a second 6-minute netCDF file
  and ran the listing again, and there were then two .tmp_netcdf.*
  files.

  This indicated that the process creating those .tmp_netcdf.* files
  was the GEMPAK decoder, dcncprof (the actions to run this decoder
  are in ~ldm/etc/pqact.split.gempak)

Since this did not prove that the GEMPAK decoder was the sole cause of
.tmp_netcdf.* files, I then:

- uncomment the FSL2 actions in the McIDAS pattern-action file,
  ~ldm/etc/pact.conf_mcidasB

- comment the FSL2 actions in the GEMPAK pattern-action file,
  ~ldm/etc/pqact.split.gempak

- verify the integrity of all pattern-action files:

  ldmadmin pqactcheck

- send a HUP to tell all 'pqact's to reread their pattern-action files

  ldmadmin pqactHUP

- delete the .tmp_netcdf.* files:

  cd ~ldm
  rm .tmp_netcdf.*

- in one window watch for the arrival of FSL2 wind profiler products

  ldmadmin watch -f FSL2

  in a second window got ready to run a long listing of the temporary
  files:

  cd ~ldm
  ls -alt .tmp_netcdf.*

- I then waited for the arrival of a wind profiler product.  As soon
  as I saw one come in, I created the listing, and it was empty:

climate:~> ls -alt .tmp_netcdf.*
ls: No match.

  I waited for a second product and got the same (null) listing
  result.  I waited for a third, and the result was the same.

I then re-enabled GEMPAK decoding of FSL2 wind profiler data
by re-editing ~ldm/etc/pqact.split.gempak and uncommenting
out the two FSL2 acdtions; checked for integrity of all
pattern-action files, and then sent a HUP to tell all 'pqact's
to re-read their pattern action files.  I then waited for the
receipt of an FSL2 wind profiler product and ran the long
listing as soon as I saw one.  Voila, there was now one .tmp_netcdf.*
file:

climate:~> ls -alt .tmp_netcdf.*
-rw------- 1 ldm ldm 0 Apr 17 23:12 .tmp_netcdf.VI8XRC

So, on the new climate machine at least, the problem of not
deleting the temporary, zero-length netCDF files resides in
the GEMPAK decoder, not the ldm-mcidas decoder.

Question:

- were the GEMPAK decoders now being used on the new climate machine
  built from source on that machine, or were they copied from a different
  machine?

  If they were copied, I strongly suggest building them on the new climate
  to see if that makes a difference.

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: GZG-682445
Department: Support ldm-mcidas
Priority: Normal
Status: Closed