[McIDAS #LPP-595939]: Problems with NLDNDISP

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