[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20001103: SFCPLOT, SFCPLT, and UKMET model GRID numbers

>From: Bill Fingerhut <address@hidden>
>Organization: Lyndon State
>Keywords: 200011031415.eA3EFH422672 McIDAS-X 7.6 SFCPLOT SFCPLT XCD


>Mark passed along last nights response. He isn't around
>just now, but I tried what you suggested. Cirrus is the
>adde server, we are pointing at it, the schema is the same
>for all sfchourly dates available. And, the SFCPLOT command
>worked for me. 

OK, perhaps the failure was some sort of a transient occurrance?

>We thought the answer might be a corrupt MD file and tried
>an experiment to test the idea. All MD files between 1 and
>9 were renamed, except for yesterdays (7). This did not fix
>the problem yesterday. We must have made a mistake. 

Your renaming experiment was an excellent idea!  This would eliminate
the possibility of a bad file IF the 'mcadde' account was only able
to see MD files in the SFCHOURLY range (1-10) in the directory where
MD files are being decoded.  Since 'mcadde' shares 'mcidas's' home
directory, this would mean that the user McIDAS on the ADDE remote
server machine would have to have either a REDIRECTion pointing to
a file with a different schema, or such a file could have existed
in the MCPATH of the user 'mcidas' (as defined in ~mcidas/.mcenv).

This is the only thing I could imagine that could cause the weirdness
that you saw.

>Unfortunately, I have another question 'related' to this
>command. If we change the command to SFCPLT and keep the
>parameters and keywords the same, it fails. The response is
>Any thoughts?

Since SFCPLT is an MDX macro command, I would try a couple of things
right after seeing an error like this:

o rerun the SFCPLT invocation adding the DEV=GCC keyword sequence so
  we get more debug output

o run MDL file_number, where file_number is the MD file from which you
  are attempting to read data (e.g., MDL 7)

The debug output from SFCPLT could help us target what is amiss.  Since
SFCPLT uses SYSKEY.TAB values for the LATEST data, it could be that the
copy of SYSKEY.TAB that your REDIRECTion pointed to had a value for the
current ISFC MD file number that was incorrect.  The debug output will
help us trace this.

>On another subject:
>* When you pointed at cirrus, you changed case to lower case. 
>Can this make a difference?

No.  The case used to specify the machine name in a DATALOC command
has no effect.

>* Did you decide what to do about the 'assignment of cylinders
>to UKMET model data' problem I reported Sept. 15?

Not yet.  I finished my McIDAS-X workshop duties last night at 8 pm.
I can now focus my attention on problems like this one.  BTW, thanks
for reminding me of this; it has been a long three weeks!


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.