============= Meeting 21-Jan-2012 =============

Agenda (as followed)

9.00 am convene and get ready. Power strip, network mucking about etc.
Actually start at 9:30.

Morning - Administration and Demos

  * 9:30 Demo of model services (*Greg*)

  * 10:30 Demo all normative types to pvget and eget (*Matej*)

Afternoon - EPICS V4 control database & IOC requirements and design references

  * Draft Charter deliverables  (*Bob* and *Greg*)

  [ moved to tomorrow] * Beamline instrumentation controls requirements on EPICS V4 (*Bob*)
    Broad matters of high throughput large datasets etc.

  * **3.00 pm** [9:00am Michigan local time, via Skype screenshare/video] 
    Marty's review of the existing pvDatabase (*Marty* given by *Matej*),  

  * **3.30 pm** [9:30am Michigan local time, via Skype screenshare/video]
    Marty's ideas on Memory, Multithreading and Locking (*Marty*). 
    From Marty's email of Dec 12

  * APS' requirements and desires for the IOC (*Andrew*
    For Andrew and Tim Mooney.

  [* Michael's review of V4 IOC requirements, if present] 

------------------------ Minutes ----------------------------

Present: GW DH RL BD MS AJ TK + observers (PSI3)

Scribe: DH


Online Modelling of SwissFel with EPICS

GW gives talk. Outlines twiss parameters and R-matrix. Use of MAD. Affect of change at one point of ring at other points of beam.

GW: 2x2, 4x4 and 6x6 R-matrices exist (2x2 1 plane of motion, 4x4 2 planes 6x6 +energy).

BD: Parameters at each energy?
GW: That's important - you get parameters from a given energy.

GW: Not running continuously - constantly updating parameters to machine in real time - because not enough trust. Get values and then operators looks at values and uploads to machine. May be well-understood enough to auto upload steering system if passes certain criterion. Intermidiate step is to continously calculate parameters. Operators can try adding bumps and see if high beta elsewhere.

GW: Gold model for each energy etc. Can have multiple models in database and switch. E.g. physicist can  calculate parameters for a future experiment and put in DB in advance.

GW: Only recompute model if something changes - e.g. energy.

GW: Start to end simulation 1 idea for modelling beam. JR may have done something on this at DLS - not deployed.

DH: Can this be used to examine cross-coupling. (R(1,4), R(3,2))?
GW: Looking at cross terms can be used for this. MAD can calculate this - some models don't.

NEW TOPIC: Demo all normative types to pvget and eget (*Matej*)
pvget normative type agnostic. eget knows NTs.
Important on public network had to change ca address list


MK Demos eget  scalar

eget gets value

Good idea to add human readible option  - e.g. -i) - translate enums, timestamps, and warning limits etc.

MK Demos eget  scalarArray, NTTable, NTMatrix, NTMatrix

For eget table test supply columns argument else error.

GW: Service writers should implement error messages that show what's missing. 

Can't set precision - stardard C++ default. Should add this option. -t = terse or transpose? Confusing for user. 

AJ: Perhaps use -v for verbose and default is terse.

For Matrix test supply row and columns.

GW: eget has -x option ("Use column-major order to decode matrix.") but document states much use row major order.

eget -s pva:///auth/testNTURI?name0=value0

GW: Why using -s flag.
DH: Is -s necessary to decide whether to use RPC or get.

Use Authority? eget pvarpc? -- Neither

eget pva:///testA#field(value,timeStamp)

GW: Can field be encoded as service parameters. Reserve some names like field?

GW: Is field sent to server.
MS: No. # hint to client , not sent to server.

MS: ? means RPCS. Otherwise get.

RESOLUTION: We shall use a difference of client side syntax of the pva URI, to specify whether pvaccess "get" or pvaccess "rpc"
should be used to make an acquisistion. Ie 
so eget pva:///test shall use pvaccess get
eget pva:///test?  (with no arguments) shall use pvaccess rpc

MS looks at remaining NTs.

Discussion of NTAny - should this be a normative type.

DH: A type that's either scalar or scalar array useful for NTImage.

Postpone discussion of this until tomorrow.

AI: on GW. The syntactical desctiption of NTURI in the NOrmative Types doc, does not match the code example nor
intuitive use in a pvData datum. The query part should be defined in teh same way as the <field-name><field-value>
below it. 

AI on GW: The definition of NTMultiChannelArray should be fixed so that the timeStamp member is optional (as is normal
for other N-types).

GW: Suggests NTHistogram is changed back to fixed ranges. NTContinuum will remain as defined with a
comment in the doc alerting the reader that NTContinuum may be changed.

AI on GW: Change NTAggregate to to carrying an array of data. Add the M field, the number of elements, even
though M could be derived from the length of the value array. This is because a use may only request the 
statistics fields, and not the value field, using eg 'field(M)' to find out how many measurements were made.

NEW TOPIC: EPICS V4 control database & IOC requirements and design references
Slides: 21-LRD-v4-charter.pptx
Bob Dalesio and Greg White

* Matej will create c++ binding of EAZYPA.

* Matej will create the conversion classes between PVAccess and Gabriele's PVManager

BD: What does "v3channel" presently do?
(ans) RL: pvasrv, the new name of v3Channel - a pva server on top of v3, has 2 parts. i. V3Channel, maps to one 
field of a record, and provides metadata of the v3 db access,
like the DBR types but not exactly, and delivers the value and metadata as a v4 pvData structure.
 ii. multiValue, this supports atomic operations on groups of v3 records as long as they are in the same lockset.

GW: How is the set of v3 records in teh multivalue specified?
MS: That is answered in Marty's talk, basically it's part of the "field" request.

BD: Charter requires that a client can request aggregation or other functionality on the server side per subscription. (Implemented in 3.15 as server-side filter plug-ins.)
GW: Take that idea and convert it to a comprehensive design for subscription parameters. Keep things like buffers for averaging private, while making the results public.
BD: Similarily: Client can ask server to aggregate related structures (e.g. belonging to the same device) into a single structure.
Client can request time correlated scalars as a vector.

RL: suggest we wait until filtering options are implemented for v4 monitors. So, the deliverables list of slide 2 of talk should be extended to include monitor options. 

* Ralph will implement v4 subscription options in pvaSrv/v3Channel (implemented as special server-side filters).

slide: Version 4 IOC
BD: We intend to orient development to support high prformance data acquisition as required in physics and science applications.
We would pursue this as an extension of V3 IOC.
  - large buffer passing 
- large buffer driver support
- large buffer to PVAccess
TK: So this would be implemented in V3 IOC?
BD: Yes
BD: marty you're ok with thsi approach?
MK: Yes
BD: That would be in the EPICS Base repo?
AJ: yes

slide: Physics Services
BD: Model service will be a middle layer V4 service in top of the model code(s).
For unit conversion (current/field/energy and such) the IOC downloads the numbers from the conversion service and does the conversion on the (V3) server side.
Device views will use directory service (ChannelFinder) functionality to create these.
Orbit Service: definition seems unclear.
GW: Getting the "position of the last 1000 pulses around the machine" is the basic orbit service.
BD: Needs to flag defective BPMs (e.g. to take them out of machine protection).

GW/BD: In Gather there would be a number of fixed channels for each gathered set of channels, each setting up a PVmanager chain that provides the data.
RL: That is very similar to adding more records to a V3 IOC, doing the different averages.

slide: Version 4 Beamline Applications
* Image Archiving and Server. Offline analysis of acquired image data.
* Scan server (Daron)
* unit conversion of HKL/Energy (Arman)
* Image Compression. 
* Electronic Log[book] Service. That is, be able to put pvData structures as entries (better: attachments to entries) into the electronic logbook (olog) with "eput" (or any other V4 pvaccess put client).

NEW TOPIC: Review of the existing pvIOC, pvData, pvAccess and pvDatabase
Matej for Matej and Marty

Java binding status.
pvData and pvAccess are complete [with repect to what the original developers envisaged]. 
pvIOC is largely "complete" [under that same definition of complete]. It is proposed that
pvIOC be split into pvDatabase, and the existing higher level additions remaining in pvIOC.

GW: What is the direction for this?
DH: Is this the design for the V4 IOC, so that we just add the C++ implementation?
MS: No. this is Marty's idea of a new database. We don't even have a use case.

[discussion of clarification of what would constitute pvDatabase, pvIOC and what parts
of the existing pvIOCJava would become independent projects]

C++ implementation status
pvData and pvAccess are complete [with repect to what the original developers envisaged]. Some C++ specifics (shared pointers, memory management)

MK: (on pvIOC vs. pvDatabase) there's just too much stuff in pvIOC.

Proposal:  For Java, pvIocJava do what Marty suggests. For C++, extract v3Channel and multiValue into pvaSrv, stop further C++ IOC database development for now. 

GW: What is the group's feeling on whether we should continue active
development of pvIOCCPP [or focus on pvaSrv (for C++) and finalize the IOC design and implementation in Java first?


DH: would rather we not "rush off" and create a new design for c++ ioc. Want
to know what we would intended to do for area detector and other systems with respect to
the new c++ ioc. By default pvaccess will look for a provider called "local", that
connects to a local database. The point is the database code can't be reused. DH
doesn't like that the IOC presupposes the existence of a database - DH isn't sure
that's necessary. DH [feels that there are a number of questions which are not 
being adequately addressed prior to design]. Polymorphism is only supported in the device support, maybe in the record, but not on the database level.
DH would like the C++ bindin of the V4 ioc should not be implemented before 
much more design is done. 
So in summary, to answer the question - yes.

RL: Yes. Looking at our existing users, their biggest use cases are connecting to existing IOCs and existing areaDetector [hence we want good support for connecting v4 to v3].

MS: Yes, with the caveat that the requirements for a new IOC design are use case requirements not design proposals.

AJ: Idea for areaDetector remote operation: create a camera driver that has a pvAccess client and connects to a remote areaDetector instance, that serves up images as pvAccess NTImage structures.

BD: There is a need to do configuration of acquisitions, and so there must be a place to do that config. {If that config can be done in the context of pvaSrv ok, but it may well not be the case}. For instance, how would a non-programmer set the region of interest for an image acquisition, would be a question.
We must have a way to configure areaDetector acquisitions.
In summary, to answer the question, yes.

RL: areaDetector could run in the existing V3 framework, or in a new (to be created) framework, that instantiates and plugs together AD plug-ins.
A client could create AD plug-ins on-line. As soon as they start, their configuration is available through a top-level pvData structure.
AJ: Persistence could be achieved by a snapshot service like masar.

AJ: +1. The existing pvIOCCPP work should be split up; move the pvaSrv out. 
    The interesting  question for DH's work is how an acquisition would be reconfigured. Initially the acq could be reconfigured by config files, later it could be by a new callable interface.

TK: +1 (subject to understanding of the AD). Would like to know in general where we are going with the V4 IOC.
in particular, are we going to move away from the idea of a pv database? What would be the structure to replace that?

(1) Suspend active development of pvIOCCPP. Move pdrv and swtshell pvIOCJava modules to separate projects (repos).
(2) Create new project pvaSrv (a cpp project), extracting v3Channel and multiValue and add filtering and aggregation features.
(3) Create an areaDetector image acquisition (including reconfiguring acquisitions) project possibly called pvAreaDetector [pvAccess on top of areaDetector].
(4) Continue the large bufffer work in both 3.15 and pvData that Michael D is working on.

NEW TOPIC: Marty's ideas on Memory, Multithreading and Locking

For the purpose of support of high performance processing, we require some changes to the EPICS Base API the code is based on, per resolution:

RESOLUTION: pvaSrv shall be based on 3.15, but with an initial release based on 3.14 coming out soon.

The 3.14 release will only provide basic, existing functionality, depend on 2.0-BETA of the CPP modules, and be supported only in terms of bug fixes.

Once that 3.14 release is out, we can switch the CPP modules over to 3.15.

AI on Ralph by asap: Get the 3.14 pvaSrv release out and prepare the switch to 3.15