NSTX MDSplus Server Update <22-Dec-2008>
Summary
The transition to serving NSTX MDSplus data from a new Linux computer, skylark, occurred 19Nov2008.
MDSplus Data is no longer being served directly by the VMS cluster. The VMS cluster will continue to provide (client) access to the data served from one of NSTX's two Linux-based MDSplus servers, skylark and lark.
One will be able to connect to any tree via skylark, lark, VMS, or the Linux cluster. All computers environment/logicals have 'tree-pointers' to the correct host.
The lark computer (Linux) will remain in operation, as-is, for the time being. We plan to integrate lark's operations into a skylark cluster during the LLD-pause planned for summer 2009.
Trees formerly served by VMS (europa, birch) and now served by skylark: nstx, activespec, activesp_raw, cameras, derived, ed, edge, eng_trend, engineering, eng_dev, efitrt, efitrt_dev, fueling, gaspuffimgng, mptscalib, nstx_trend, operations, particles, passivespec, pspec_raw, rf, wf.
Trees currently served by lark : larknstx, befit, befit**, cameras2, dcon, efit, efit??, efitanalysis, efitanalys**, lrdfit, lrdfit**, microwav_raw, microwave, mmwr, mse, nbi, ops_pc, probes, profdb, pspec_pc, sflip, ucla_interf, usxr .
Known Issues & work-around
Please avoid logging on to the BIRCH VMS node. The porting team sometimes temporarily use BIRCH as a way to look at the old VMS-hosted trees, and therefore the system logical names on BIRCH may not point you to the online/skylark tree.
Users have discovered that some programs that run on portal no longer work. This is usually not due to the skylark project, but because 'portal' was converted in August to a 64-bit Linux operating system; it used to be a 32-bit OS. 'portalR3' and 'nstxpool' are still 32-bit Linux so use those. Some 64-bit MDSplus code works, and we plan to work on the 32-to-64-bit conversion over the coming months . Let 'us' know if you have an application that you normally use that do not run properly on portal/64-bit and we'll put it on the list.
The 'shotclock' on VMS is no longer being supported. On Linux machines: 'module load nstx/epics' then type 'nstxclock'.
There is a floating point number issue. VMS used a proprietary VAX format, most other OS's use the IEEE format.
This is benign when using IDL, LabVIEW, traverser, scope.
Embedded TDI has worked, but other TDI (CAMAC device drivers) don't like the VAX format.
You will no longer be able to modify CAMAC module (e.g. timing triggers) settings from VMS using traverser. You will be able to do that from a Linux machine.
mdstcl (TCL on VMS) can't read the foreign format. Nodes read by TCL need to be converted to IEEE. We've been using IDL on Linux to read, then write these nodes. This puts it in the format of the host OS.
We're looking into recasting all floating point values to IEEE format.
On VMS, you cannot use some TCL commands. VMS' version is old and doesn't forward the mdstcl commands to a remote server. However, you can use the 'mdstcl' function in IDL. Linux computers do forward mdstcl requests to the remote server.
The VMS mdir 'alias' does not work on VMS. Bill Davis made a work-around.
To EDIT a tree, you must be logged on to the computer that hosts the server for that tree. This is no different than before, just pointing out this behavior. Most tree-owners have accounts on the tree's native MDSplus server.
The version of the Traverser on the Linux machines that was in-use last run does not display the contents of some nodes. A newer version (that works) is under trial use and is the default version that is loaded with /module load nstx'. Report any problems.
The primary NSTX MDSplus Event Server is now skylark. Birch is also running an event server. Events should be sent to skylark, you should wait on events from skylark. If your VMS program uses events a special 'event forwarding agent' may be need. Contact Bill Davis if your program doesn't seem to be getting the events it expects.
There are two environmental variables in linux (logical names on VMS) that specify the event server (mds_event_server [for wfevent]), and event target (mds_event_target [for setevent]). On Linux, if you do an mdsconnect in your program, these env's are overridden and the machine you connected to becomes the event server and target. This override behavior hasn't been tested on VMS yet.
If you have a program on the Linux cluster (e.g. nstxpool) that does an explicit mdsConnect to europa (or other VMS) for a tree served by lark or skylark, your program can read data normally but will not have write permission. Removing the mdsConnect command will allow write access for you, since your mds-connection is implicit (via the Linux environment) and direct to the correct server.
Cluster and Desktop Environment Changes
If you access MDSplus data from the VMS or a Linux cluster, the modules and other standard environment settings will be changed by the Computer Division.
If you access MDSplus data from a 'desktop' computer, you may want to reconfigure your registry/environment to point to skylark instead of a VMS machine (e.g. europa) in order to realize better performance:
If you access MDSPlus from a 'test cell' diagnostic PC, using LabVIEW: You should edit your LabVIEW program to MDSconnect to skylark instead of europa or other VMS system. It is recommended that mdsplus events be sent to skylark, but they can also be sent to birch (VMS) if there are VMS programs waiting on the event.
Additional Material (a bit outdated)
Contact list:
Bill Davis 609-243-2546 bdavis@pppl.gov
Paul Sichta 609-243-3477 psichta@pppl.gov
Greg Tchilinguirian 609-243-2669 gtchilin@pppl.gov
Gretchen Zimmer 609-243-3133 gzimmer@pppl.gov