Hi Christian, re: > I thank you very much again for your very very nice support you give > out to McIDAS users. It is very much appreciated!! No worries. I'm glad to help when I can... > You identified very well the problems we have! Excellent. I _always_ like to hear of positive results :-) > I had the problem that > redirections for lightning data were not there at all. I did have > problem with dmap: > dmap.k MDXX007 > PERM SIZE LAST CHANGED FILENAME DIRECTORY > ---- --------- ------------ -------- --------- > 0 bytes in 0 files I thought so... > So I did the two commands of redirection, both in the mcidas user > accound as well as in the other user account which plot the data (is > it needed? "Teaching" McIDAS where to find data files is only needed in the account in which ADDE will be acting on behalf of the user. My recommended, standard configuration has all of the ADDE server setup done in the 'mcidas' account, so if you followed the recommended setup (and you did since you are pointing to the external interface on kepler), you would only have to run the REDIRECT commands in one account, 'mcidas'. > I thought so since there was also a LWPATH.NAM there): > > % redirect.k ADD MDXX007\* \"/home/ldm/data/xcd > % redirect.k ADD MDXX0080 \"/home/ldm/data/xcd Each account will have an LWPATH.NAM file in the user's McIDAS working directory. The question would have been what REDIRECTions were there, and what REDIRECTions were actually needed there. The simpliest installation is one where all of the work needed to configure McIDAS is done in the 'mcidas' account. This allows other users to simply "point" (DATALOC ADD ...) to the site's external ADDE interface to get data. > Then scouring manually using McIDAS script mcscour.sh did the trick! > I have still however big MDXX LTG files. I thought that the scouring > would have reduce the MDXX file sizes. McIDAS scouring (through the actions in mcscour.sh) deletes entire files that are older than the number of days requested to delete. It will not delete old data in an MD file since it does not work at that level. If you find that you continue to have problems because you have old NLDN lightning MD files, you could simply delete them. > I am quite happy that it works again now, thanks to your thorough help! I am glad that things are now working :-) > For the restriction for the ADDE server, I will wait for your > instructions on how to implement it. OK. I will try to research this sometime this week. My time is tight, however, since I will be involved in an Antarctic workshop that starts tomorrow (Antarctic researchers are using the LDM in an 'Antarctic IDD'). > One question: I have some lightning data stored into ascii files for > europe (lat+lon+intensity). Is it easy to ingest into McIDAS? I > already ingest it into GEMPAK files with sfedit. 'Easy' is a relative concept ;-). McIDAS does have an ASCII to MD file converter, TXT2MD, that could be used to convert your data into MD file format. Please look over the online help for TXT2MD (HELP TXT2MD) and then send in questions that occur to you. > Many thanks again and again!! You are most welcome! 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: LPP-595939 Department: Support 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.