Menu
▾
▴
Re: EPICS meeting agenda for V4 - two questions
|
From: White, G. <gr...@sl...> - 2010-08-09 03:06:57
|
Hi everyone,
First, thanks very much for starting this effort and getting us on track Bob. I have some comments inline [I'm using a threaded email client; can everyone clearly see the comment nesting level? - I've noticed many people at SLAC are using mail clients that can't display comment nesting!]
On Aug 6, 2010, at 7:01 AM, Dalesio, Leo wrote:
> Do I have a complete list of talks we should give? The speakers correct?
>
> EPICS Vv4
> Development plan Bob
> PVData changes Marty
> PVAccess Changes Matej
> C++ server Nikolay
> Data Types Gabriele?
> Multichannel server Gabriele
> Image Server Nikolay
> Array Server ??
> Accel Machine types Greg or Guobao
* Regarding the separate talk titles "Multichannel server", and "Array Server"; my understanding is that there would be no specific "multichannel server" nor "array server". Rather, Multichannel and Array are simply standardized subtypes of a PVData. They are special only in that we shall attempt to use those standardized general types, to define the standardized specific types of high level services. For instance, a BPM Orbit service (one that would return the x and y offset, tmit, status etc, of every bpm in a beamline) may use the Array type repeatedly in its returned data type. It would probably return a PVData that looked something like this (p-code):
PVData BPMOrbit
{
int beamIdentifier
SometypeofTimestamp timestamp
Array Xs
Array Ys
Array XRMSs
Array YRMSs
Array TMITs
Array Statuses
}
* Regarding the talk titled "Accel Machine types", I read that meaning "application level data types for accelerator modelling." If so, it would include such things as R-matrix, RmatA-to-RmatB, Twiss, phase space orbit etc - as we talked about in the breakout meeting. I could do such a talk. But if you meant instead "Accelerator modelling codes for different accelerator machines (space charge dominated, linac, photon etc)," then maybe you mean a talk like Guobao's service architecture for different modelling codes.
About the remaining application level data types for accelerator modelling [and high level apps generally] I know I'm still on the hook to provide the remaining absolute basic ones. I'll do Klystron control, magnet, Relational Db and multiknobs/bumps really soon - maybe tomorrow.
>
> Should we do a session specifically on applying EPICS V4 to machine control?
> where does matlab, python, css go?
> Put the Accel Machine types into this session?
> orbit server
> magnet server
> twiss server
* Firstly, please let's not call it "twiss" server, but rather "model" server. This is because a model server must include first order transfer matrices (R mats, and in circular machines - C mats), as well as Twiss params.
Secondly, can I propose that we distinguish between usages of the words server and service. Let's say a service is a functional interface to data, which is running on one or more server demons (on one or more hosts). Why so pedantic? Because especially in "model services", >1 server type may be involved in providing the service. For instance, the model data may be provided directly from a modelling code such as Elegant running in an EPICS-V IOC server demon, or from an Oracle relational Database service running in an EPICS-V IOC server demon - *or both*. This setup is similar to the one we've evolved into at SLAC - some model data served by the AIDA modelling service comes from the AIDA XAL model server (model of single devices), and others come from the AIDA Oracle server (gold and latest models of the whole machine).
> changes to MMLT to use these
> using Python for machine control?
>
>
*Bob*, to answer your question, I can certainly outline the orbit, magnet and model types. Maybe *Roland* can comment on whether he'd be ready to comment on MML in October?
>
> where do the servers go?
Yes, I had a similar thought. Can we write an a nominal scientific services architecture document outlining the use of these tools, in time for October? What would be in it? I have some thoughts, but right now it's more questions than answers. I can volunteer to edit it.
+ What is the fixed set of basic APIs we propose to define
+ Do we propose to provide minimal reference implementations of services which use those APIs? Eg maybe BPMOrbit, magnet, RF, linear model, history, RDB. This set would cover a lot!
+ How does one do service management. eg, if a service becomes unresponsive, how do track down the IOC on which it runs. How do you restart it.
+ Where does it log stderr and stio.
+ What message logging system will be used. What is the error message API. Remember that high level function is now being moved to the server, so client side error messages have to be merged seamlessly with server side ones to give the user a complete picture of what wet wrong and why. At SLAC we did this with a CORBA based error messaging framework.
So, putting all the above comments together I guess something like this for talks. What do you think:
EPICS Vv4
Development plan Bob
PVData changes Marty
PVAccess Changes Matej
C++ server Nikolay
Data Types Gabriele?
Multichannel
Array
EPICS Vv4 Scientific Services
Services architecture and High level interfaces - Greg
BPM Orbit
Model
Twiss
Rmats
Magnet
RF
History/Archive
Image Service - Nikolay
Machine Modelling Service Architecture** - Guobao
Archiving - James
MML - James
** I'm thinking a talk like the one Guobao gave at SLAC recently.
"EPICS Vv4" ! Nice!
Cheers
Greg
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
|