[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.


> 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.*

  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,

- comment the FSL2 actions in the GEMPAK pattern-action file,

- 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

  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.*

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.


- 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

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


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

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.