ESD Support for UNIX Applications

Yet another common direction

Trigger for this discussion

• LER not well served by online DIMAD

• “Opticians” using complex Unix-based codes

• People finding ways to “make do” for data acquisition, transfer, and implementation of results

• ESD has been moving to Unix too

Turner’s Data Path

Raises many questions

• Which disk areas are to be shared?• How should they be managed?• How do offline and online model-based applications

interfere with each other?• How can we best provide the necessary BPM data?• The idea of producing a “config” file is great, how can we

better support that?• Where (physically and logically) do we put an Octo-CPU

Barnburner-6 Linux box for analysis code?• How can OPS, ESD, and PEP-II best cooperate to get the

required job done?

Two separate kinds of support

• “Sandbox” support – allow users to test ideas and codes without worrying about infrastructure issues

• Production support – how to promote worthy code to production and provide for ongoing maintenance

Unix MATLAB Progress

• Note: VMS MATLAB is frozen by the vendor and is two major releases old

• Fast Channel Access now available (SSRL and SNS)

• MATLAB Compiler now being tested

• No license required to run compiled version!

Data Access for Unix MATLAB

• Channel Access extensions now provide access to “normal” SLC database items as well as, of course, EPICS variables.

• Currently NOT provided:Direct BPM accessHistory or Archiver data

Idea for Production MATLAB Programs

• Test under your user account on a machine which has read access to data of interest

• Convince your colleagues that your program is robust and useful

• Compile the file into an executable• Move executable to gateway production area• Provide command line or “SCP button” access

AIDA – the Data Conduit(Greg White, Bob Sass, Ron MacKenzie et al.)

• Will soon provide transparent, fast data access to SLC database, Channel Access, SLC history, Channel Archiver, and Oracle databases.

• Will extend to complex BPM acquisitions.• User need not know ultimate source of data.• Extensive design documents available.• MATLAB Java interface begs to be a client

Local large NFS server

• Will provide local common data storage

• Visible from gateways and other production machines

• Reduces reliance on SCS

• ESD would welcome PEP-II “buy-in”

ESD’s Reasons for supporting Unix

• Physicists now running new code on Unix• We do not have the resources to support systems,

robust data access, AND applications.• The long lead time for application extensions on

VMS leads to frustration and backdoor solutions• Ray has asked us to focus forward, not backwards.

VMS is NOT forward.• If you can’t fight ‘em, join ‘em!

Unix support from VMS/SCP

• Provide robust data access

• Provide appropriate control access

AND/OR

• Provide applications as servers

VMS-based application servers

• Buffered BPM acquisition(AIDA access may prove sufficient)

• Correlation plots(Also possible to move app entirely)

• Gobs of model-based code

• Wire scanners, feedback control, ……

• Plenty of opportunity for everyone

A surfeit of questions remain

• Deployment procedures(new/old versions, “blessed” production area)

• Screen management for interactive code• Data access priorities• Unix data management procedures• Reliability of SCS-dependent machines• Linux? Solaris? Both?• Steering the chaos

How to proceed

• Form a small working group with ESD, OPS, and PEP-II representation.

• Work together on plans for Unix (Solaris or Linux) program support.

• Work together to plan application moves and data access requirements.