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