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.
>From: Richard Massa <address@hidden> >Organization: UC Davis >Keywords: 200210150109.g9F19F112387 McIDAS-XCD LDM Richard, re: login >I'd be happy to give you a login, but I'd rather fix the problems myself, for >no other reason than I'm responsible for the system and I'd like to go through >these steps with you so I can learn them and hopefully fix them myself here >eventually. I understand. The only reason I suggested a login is that I am _the_ McIDAS support person at Unidata, and I have lots more than one site :-(. re: run 'ldmadmin watch' to verify that the LDM is getting data >I'm always running that on my workstation to make sure that data is still >getting to us :) OK. re: verify that XCD decoders are running >They were running, but I restarted anyways to see if it would help. Sorry... >should have included that in my email. > >mcidas@atm20:/var/data/xcd$ ps -ef |grep inge >ldm 21857 21830 0 14:25 ? 00:00:00 ingetext.k DDS >ldm 21858 21830 0 14:25 ? 00:00:00 ingebin.k HRS >ldm 21989 21858 0 14:25 ? 00:00:00 ingebin.k HRS >ldm 21998 21857 0 14:25 ? 00:00:01 ingetext.k DDS > >mcidas@atm20:/var/data/xcd$ ps -ef |grep start >ldm 21831 21824 0 14:25 ? 00:00:00 startxcd.k >ldm 22002 21831 0 14:25 ? 00:00:00 startxcd.k These listings look OK. >I did try stopping and restarting... that has made some improvement (I think) >as I'm seeing MDXX0060, and MDXX0070, which weren't there before, as well as a >substantial increase in file size. Perhaps things are working, but I am still >unable to look at temperature (just my test case) in mcidas... Which says that the data isn't there. >(A good >question: which data set is that, and where can I find a list of >filename->realname mappings?) The POINT data is all decoded into an ADDE dataset with group name RTPTSRC. The different sets in the group were defined when you ran BATCH LSSERVE.BAT. You can review the settings by running DSSERVE LIST RTPTSRC, and this should give: Group/Descriptor Type Format & Range RT Comment ------------------------ ----- ------------------ -- -------------------- RTPTSRC/AIRCRAFT POINT MD 61-70 Y Real-Time Aircraft data RTPTSRC/FOUS14 POINT MD 41-50 Y Real-Time FOUS14 data RTPTSRC/LIGHTNING POINT MD 71-80 Y Real-Time Lightning data RTPTSRC/PROF6MIN POINT MD 91-100 Y Real-Time 6-Minute Profiler data RTPTSRC/PROFHOURLY POINT MD 81-90 Y Real-Time Hourly Profiler d ata RTPTSRC/PTSRCS POINT MD 1-100 Y All point data in MDXX file s RTPTSRC/SFCHOURLY POINT MD 1-10 Y Real-Time SFC Hourly RTPTSRC/SHIPBUOY POINT MD 31-40 Y Real-Time Ship and Buoy dat a RTPTSRC/SYNOPTIC POINT MD 51-60 Y Real-Time SYNOPTIC data RTPTSRC/UPPERMAND POINT MD 11-20 Y Real-Time Upper Air (Mandat ory) RTPTSRC/UPPERSIG POINT MD 21-30 Y Real-Time Upper Air (Signif icant) DSSERVE: done This gives the breakdown you are after: RTPTSRC/SFCHOURLY:= Real-Time SFC Hourly -> MD files 1-10 (MDXX0001 - MDXX0010) and so on. >I also still don't see anything from a PTLIST command. > >ldm@atm20:/a/data/xcd$watch -n1 "ls -la MD*" >Every 1s: ls -la MD* Thu Oct 17 14:36:45 20 > 02 >-rw-r--r-- 1 ldm ldm 5545608 Oct 16 03:38 MDXX0018 >-rw-r--r-- 1 ldm ldm 5781328 Oct 16 13:47 MDXX0019 >-rw-r--r-- 1 ldm ldm 5635920 Oct 17 14:33 MDXX0020 >-rw-r--r-- 1 ldm ldm 784960 Oct 16 03:24 MDXX0028 >-rw-r--r-- 1 ldm ldm 1275344 Oct 16 13:47 MDXX0029 >-rw-r--r-- 1 ldm ldm 1264688 Oct 17 14:33 MDXX0030 >-rw-r--r-- 1 ldm ldm 4987588 Oct 16 13:31 MDXX0038 >-rw-r--r-- 1 ldm ldm 4984780 Oct 16 13:48 MDXX0039 >-rw-r--r-- 1 ldm ldm 4578052 Oct 17 14:35 MDXX0040 >-rw-r--r-- 1 ldm ldm 2215544 Oct 16 08:26 MDXX0049 >-rw-r--r-- 1 ldm ldm 4909200 Oct 16 05:08 MDXX0057 >-rw-r--r-- 1 ldm ldm 8858712 Oct 16 11:22 MDXX0058 >-rw-r--r-- 1 ldm ldm 7778136 Oct 17 14:29 MDXX0059 >-rw-r--r-- 1 ldm ldm 8859048 Oct 17 14:35 MDXX0060 >-rw-r--r-- 1 ldm ldm 3112844 Oct 16 04:04 MDXX0068 >-rw-r--r-- 1 ldm ldm 5436048 Oct 16 13:47 MDXX0069 >-rw-r--r-- 1 ldm ldm 5449292 Oct 17 14:32 MDXX0070 This gives you the same sort of info that the PTLIST command gave. >Also, I've been seeing something that might be indicative of a (the) problem: >I've got a zombie dmsfc.k process, that seems to be rapidly changing its PID >(or dying and getting a new one started). Its parent is the slave startxcd.k >process... OK, this is telling us that dmsfc.k, the SAO/METAR decoder, is dying and is being automatically restarted by the XCD supervisory process, startxcd.k. The question is _why_ dmsfc.k is dying. >I've grepped -i dms (and startxcd) in the ldmd.log.* files and it >doesn't turn up anything at all. The McIDAS-XCD processes don't log to the LDM log file. Instead, they log to the file you defined as MCLOG in xcd_run. >I've currently restarted the ldm with the -v >flag so its being noisy, and I don't see anything besides products coming in. > >ldm@atm20:/a/data/xcd$ ps -ef |grep 7141 >ldm 7141 7005 0 14:45 ? 00:00:00 startxcd.k >ldm 7144 7141 0 14:45 ? 00:00:00 DMRAOB >ldm 7145 7141 0 14:45 ? 00:00:00 DMSYN >ldm 7146 7141 0 14:45 ? 00:00:00 DMMISC >ldm 7157 7141 9 14:45 ? 00:00:11 DMGRID >ldm 30730 7141 85 14:47 ? 00:00:04 [dmsfc.k <defunct>] dmsfc.k is dying. We must find out why. re: perhaps SCHEMA has been deleted. >The SCHEMA file is still there: >ldm@atm20:/a/data/xcd$ ls -la /a/data/xcd/SCHEMA >-rw-r--r-- 1 mcidas mcidas 481792 Oct 15 12:57 /a/data/xcd/SCHEMA I offered this suggestion since many folks make the mistake of trying to scour the McIDAS data files (MDXX*, etc.) using the LDM scour facility. If this is not done _very carefully_, then the SCHEMA file will eventually get deleted since its timestamp never changes. Once that happens, the decoders that need the database information in SCHEMA will stop working since they won't know how to create the output files (the MD files are Meteorological Database files; SCHEMA contans the database file schemas for the output data files). >Thanks for bearing with me through all of this. No worries. >If none of this sheds any >light, then you're welcome do the login thing, as its probably a lot more >efficient for you... I just logged to your system and see that the contents of your ~mcidas/workdata directory do not look complete. To me this means that the install was not done correctly/completely. A number of configuration files that should be found in the workdata directory are located in the ~mcidas/data directory. I don't understand how this could happen since the 'make install.xcd' will install the files in the workdata directory. Did you copy these files to the /home/mcidas/data directory? Also, I see a ~mcidas/update directory and a SKEDFILE in ~mcidas. It is very possible that you inherited this kind of structure from Erick. Instead of troubleshooting things in the current setup, I would much rather clean things up and get the installation looking like a standard McIDAS installation. That way, troubleshooting new problems will be much easier. So, I recommend: <as 'ldm'> o shutting down the LDM <as 'mcidas'> o uninstalling and then reinstalling McIDAS-X 2002 (this is pretty quick cd mcidas2002/src make uninstall.all At this point, there will be several files in the ~mcidas/data directory that shouldn't be there (e.g., STRTABLE, LWPATH.NAM, etc.). I would recommend removing all files from that directory EXCEPT the ones that you explicitly created during the configuration process or that were created as custom files for your site. Here are the files that I would definitely keep: ADDESITE.TXT LSSERVE.BAT LOCAL.NAM LOCDATA.BAT RESOLV.SRV <- this file should be in the workdata directory; move it there Once the directory is cleaned out, then a reinstall of the package can be done: cd ~mcidas/mcidas2002/src make install.all The other thing I would recommend doing -- unless specific setups at your site rely on the split of XCD-created data and the ldm-mcidas created data -- is combine the contents of /var/data/ldm/mcidas and /var/data/xcd. You will need to trust me when I say that the consolidation process will make life easier for you down the road. What it will do in the short term, however, is make you redo some of the setup work you did just a little while ago. I want to blast this off to you now before finishing my thoughts so that you can get started if you are there or give me the green light to do the modifications myself. Tom