>From: "Anderson, Alan C. " <address@hidden> >Organization: St. Cloud State >Keywords: 200402182057.i1IKvTrV011544 McIDAS-X setup Alan, Sorry I have not been able to respond to this inquiry before now, but I have been in Costa Rica since Feb. 22 and have not been able to respond to email as consistently as I would like. >In my message from yesterday, I commented that while our new ldm seems >to be running ok, I am not getting any content in my log file, >ldmd.log > >The file was created (upon start ?) but is empty. I checked my lines >in /etc/syslog.conf, and these seem ok. I sent back a message earlier that outlined some troubleshooting you can do: - check the /etc/syslog.conf entries to make sure that they are correct - stop and restart syslogd - use the 'logger' command to see if you can successfully write to the log file: logger -p local0.debug 'test of syslog writing to LDM log file' If 'logger' doesn't work, it means that either your /etc/syslog.conf file entries are bad, syslogd is not running or is wedged, or ~ldm/logs/ldmd.log is not writable by you. >Also, have another problem. I have downloaded and installed the >mcidas-ldm decoders as directed on your web page. OK, just so we are on the same page, the ldm-mcidas decoders are for the Unidata-Wisconsin (IDD feedtype UNIWISC) imagery, NLDN lightning data, and FSL wind profiler data. The have nothing to do with surface or upper air decoding in McIDAS. These are handled by the McIDAS-XCD decoders. >I can create images >and a skewT but cannot get a simple plot of surface data. We should first make sure of what machine you are pointing to to do the plots. Please let me know the output of: DATALOC LIST RTPTSRC If you are pointing at some other ADDE server, you are seeing a problem on their server, not yours. If you are pointing elsewhere, you should do the following to point back at your own machine: DATALOC ADD RTPTSRC LOCAL-DATA -- or -- DATALOC ADD RTPTSRC cyclone.stcloudstate.edu The latter invocation of DATALOC assumes that the remote ADDE sever has been correctly setup on cyclone. >Seems like >I must have Area and upper air files where they are supposed to be, >but am not getting suface data (or else mcidas is looking in the wrong >place ?). If you are trying to access the RTPTSRC data from cyclone or LOCAL-DATA, then the failure to plot surface data points to a problem decoding the surface data. >Checked my redirect list and also the string XCDDATA, >everything points to /var/data/mcidas which is where I keep the >files. > >Any hints ? Again, if you are pointing at your own machine, then you should try the following from a McIDAS session running as 'mcidas': 1) DMAP MDXX Do you have MDXX files 1-10 or any subset listed? If no, then no surface data is being decoded. If yes, are they current? If no, then the decoding is not running. Do you have 10 surface MDXX files listed? If yes, then you are not scouring the data files before they get to be 10 days old, and they are most likely full. In this case, the easiest thing to do is stop the LDM, delete the MD files, and then restart the LDM. 2) it could be the case that the rapid access files were never correctly created before turning on the LDM. If the items in 1) don't fit/are not the problem, do the following: stop the LDM <as 'mcidas'> do: cd workdata batch.k XCD.BAT batch.k XCDDEC.BAT decinfo.k LIST Was surface decoding (DMSFC) turned on (the decinfo.k listing should tell you this). If not, turn it on: decinfo.k SET DMSFC ACTIVE restart the LDM >Thanks Is cyclone accessible to me via ssh? I just logged on, so it is. I checked what I wrote above and all looks OK. I can list out individual records out of the current MD file using PTLIST, but I am unable to list using SFCLIST. Now, I am stumped! Right at the moment, I am thinking it may have something to do with the time. The reason I say this is that it is 7 am Boulder time, so the time in UTC is 14:03. McIDAS on cyclone thinks it is 8:03 UTC: cyclone% tl.k H := 8:03:57 XCDDATA := /var/data/mcidas Y := 2004061 --END OF LIST Yup, you have a system clock problem. To see this in another way, plesae take a look at the latencies for the IDS|DDPLUS data: http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?IDS|DDPLUS+cyclone.stcloudstate.edu Notice that your clock is off by 21600 seconds. This must be the problem with accessing data in McIDAS since the data looks like it is in the future. When you correct your clock, two things should happen: the LDM latency plots should return to normal values, and the McIDAS decoding and access to data should get corrected. Cheers, Tom -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publically 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.
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.