This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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