1 / 15

ESD Support for UNIX Applications

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

jamuna
Download Presentation

ESD Support for UNIX Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ESD Support for UNIX Applications Yet another common direction

  2. 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

  3. Turner’s Data Path

  4. 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?

  5. 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

  6. 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!

  7. 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

  8. 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

  9. 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

  10. 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”

  11. 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!

  12. Unix support from VMS/SCP • Provide robust data access • Provide appropriate control access AND/OR • Provide applications as servers

  13. 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

  14. 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

  15. 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.

More Related