Friday, July 13th

9.15 Morning: Plans for EPICS V4 WG:
* Decide whether we proceed after the present EPICS V4 charter. 
If so, what would the next working group do (using items from day 1 about our present status, and from day 2 about 
short term things)?
[Discussion lead *Bob Dalesio*] 

* What should be the long term plan for the EPICS IOC?  
Objective is not to decide this definitively, but to articulate enough of the points that a serious 
proposal can be written to the EPICS community, and the managers and labs that would have to support it.
[Need very good minutes for this!!!!!]

*** Diamond Tour ***

Afternoon: Plans for other WG, and any overflow
* Proposal for an Accelerator Applications Group next year (*Greg*, 30 mins).
What might the charter deliverables of a Working Group for accelerator services and applications be?

* Catch up items that we never got to in the previous schedule.

* Prototype Normative Type self-identification and introspection interfaces.
*Greg*, *Matej*, *Marty* and anyone else who wants to join.


Present: DH, Mark Heron (MH) subject to availability), BD, GS, MK, Michael Abbot (MA), JR, TK, Daniel Meyer (DM), Markus Janousch (MJ), MS, Daron Chabot (DC),Paul Gibbons, Tom Cobb

Scribe: GW
BD: Before we proceed, what is feedback from last year.
MK: I'm more opptmistic about future than a year ago.
BD: +1

BD: Going forward: Is there anything that the physics team needs, requirements, that have not been handled. Eg NTs?
GW: NTs need some more work, but I think we're going to get 1PWD in 2 or 3 weeks.

BD: What is status of helpers for NTs?
GW:  the people who have immediate requirements (=BNL people) should write the helper classes
GS: worries about people writing helpers in diverse ways (no standardization)
MK: set up a mercurial repo for helper classes (e.g. normativeTypesCPP)
BD: GS has responsibility for the BNL implementation of the NTs wrappers.
BD: GW will do the self-id specification.

BD: Can't do dirk req without ragged table, so it has to go into NT specification.
[GW add Ragged table, self-id, decision on introspection. Also need better NTContinuum.]

BD: Need alos to update pvAccess documentation.
MK: Also pvIOC and pvData. MS is resp for specification. 
MS: There will be other additions.
MS: Also we need a short document that defines the difference between the reference implementation and the specification, eg -ve offsets.

NEW TOPIC: Charter review of outstanding items:

List of items outstanding.

Charter Deliverables status review w.r.t. charter exit in Sept.:

* A normative document of the pvAccess protocol
-> 95%. Needs update for "beta2"

* A normative document of the pvData protocol. The document must include 
the user API - how a programmer creates data objects for the wire, and extracts them on the other side
-> 90%. Needs update for "beta2". 
MK. needs a few weeks.

* A normative document of the EPICS V4 IOC processing pipeline
-> Punted. Next year, as part of beamline oriented work.

A reference implementation of pvAccess in each of C++ and Java language bindings
-> Done. ST beta2 work.

A reference implementation of pvData in each of C++ and Java language bindings
-> Done. ST beta2 work.

A reference implementation of the EPICS V4 IOC in each of C++ and Java language bindings. The Java version has high priority.
-> Java one Done. ST beta2 work. CPP punted to next charter. CPP IOC side will only consist of v3Channel (connecting to V3 Pvs) and channelRPC will be moved to pvAccess.

A normative document of the EPICS V4 interoperable data types. These data types must be universally understood by every client and service which claims EPICS V4 compatibility. The requirement for this deliverable is distinct from the pvData document deliverable, since pvData can encode any type, this deliverable recommends the confined set of data objects that will be used by EPICS V4 interoperable services
-> 85% done. See above for additions outstanding.

A directory service accessible through the EPICS V4 API itself, from which can be found at least PV and entity names, and associated service names
-> BD: RL is 85%. Should finish without waiting for asynch RPC.

A normative document of the EPICS V4 services API. This defines the form for encoding parameters and status descriptions between clients and services and back
-> GW, JR, MS. 20% done. But short.

A report of interoperability of the EPICS V4 IOC with EPICS v3 record processing
-> MK: There may be material in the overview docs. 
MK: Where do I put thsi on the web? [addressed offline]

A performance report, comparing EPICS v3 to EPICS V4 for some common EPICS v3 control and read tasks, plus report of the expected performance of EPICS V4 service support. For instance, round trip time for network encoding/deserialization of results of 4 or 5 common service queries such as archive data, orbit data, whole beamline model etc. Comparisons to at least 2 other common high performance data interconnects should be made, eg ICE, ASN.1, EXI Web Service.
-> BD: as far as I'm concerned we have a performance report. But we should re-run the performance measures after beta 2 completed. So, it's 100% done.

A "Getting Started" document for EPICS V4 Service developers
-> 100%. Will be updated after "Dirk Req" is completed.

A User Guide for EPICS V4 IOC control application developers
-> Punted to next charter, since control is getting attention in that charter, not this.

A command line tool similar to caget (call it say pvget), which understands all the interoperable data typesabove, and conforms to the EPICS V4 services API above.
-> 60%. Needs NT decoding. Understanding RPC w.r.t. the services API. So, dependent on services API.
At least scalar and array types, NTTable, NTHisogram, NTcontinuum. If plottable then plot with gnuplot.

A normative document of the EPICS V4 Directory Service function, API, and unix command line tool.
-> On RL. 85% done. The DS doc needs to be put into the EPICS V4 document collection. 

A reference implementation of the EPICS V4 Directory Service.
-> See above.

Outside scope but expected.
pvManager, a framework and client side application software library for managing sets of EPICS V4 PV acquisitions.
-> 0% BD: We need to connect pvAccess & NTs to pvManger. 

-> An archive data retrieval service. Only the EPICS service endpoint is in scope, not the archiver architecture itself. This may be modified in a future charter amendment.
-> Completed.

NEW TOPIC: What is the remit of the next Working Group
BD: Yesterday we seemed to decide that there will be a next working group, and it will 
concentrate on beamlines, not physics services. Is that right?
GW: I'd suggest that there be 2 groups going forward: the EPICS V4 WG to concentrate on beamline,
and also a WG to concentrate on physics applications.
<apparent concensus>
<discussion of people who may be involved in these groups>

BD: Next step in that is then to try to get the group together.
BD: Also be more specific about the charter of the next WG.
BD: The 8 topics for the next WG discussed yesterday, should be fleshed out...

From yesterday: Possible subjects of the Beam line directed V4 working group.

1) Heterogeneous data aggregator on epics V3  - part of this charter. No normative type. MK: Not hard (when implemented as channel RPC request).
2) Connect ntimage and ndarray into v4 server 
3) Actions on images (ala areaDetector, such as background substraction...)
4) Review normative types in light of beam line control.

5) Fully implemented pvIOCCPP for supporting beam line control
6) Prototype V4 record using V3 image-processing record.
    Including large buffer management
7) scan service
8) Demonstrate the suitability of a control architecture in which all client-server interaction
is mediated by pvAccess. 
Make sure HDF5 is properly integrated into the services and processing pipeline. May be handled as a service.
Longer term plan
8) as above
9) Demonstrated architecture of the combined V3 record processing with V4 services in the embedded IOC.
10) Implement pvData and portMapper on v3 IOC (essentially port driver) run as a v4 service.
11) Chunked transmission. 
12) Multicast.

MH: Marty demoed portMapper as the external interface. Is there any sense in using that to
do device control on the network? That is, can I use pvIOCJava for conrtol?
MK: There is really only the basis for device control. 
BD: If we had a portDriver that handled ethernet and ... we could do 95% of device control.
MH: That assertion is not true on a pulsed machine.
BD: true. But still [it's a reasonable goal]

MS: What is large buffer management?
BD: Make it so driver can bring in a large buffer, and process it, and the protocol can transmit it.
That is, maximize 0-copy.
BD: In general we should better take advantage of multi-core machines.
BD: Things which are now done in the client, as a work around, should be architected to the appropriate place.

NEW TOPIC: Outstanding Technical Issues for this charter exit
MS 1. Asynch RPC.
GW 2. Services API. Add services to eget.
MS 3. Deciding provider (that is, pvAccess or CA) for a V3 PV.
    MS: Problem is in 2 parts: Specifying the list of alternative providers. 2nd, how to use a provider. 
    We may simply implement the solution that both providers are always tried! 
MK: 4. "Dirk Requirement." A module on embedded IOC that can collect V3 record data and return it as V4 data.
    Get and Put MUST be implemented. But not monitor.
    One MUST be able to specify an ad hoc list of V3 PVs to be acquired or put to. Additionally,
    alternatively, an IOC engineer must be able to pre-specify the list of V3 PV as a static list
    in a file on the IOC.
MK: Please no more requests until end of July, so I can get this working.
MS: 5. easyPVA RPC (in Java impl of easyPVA)
GW/JR 6.  SupereasyPVA.

Required for beta 2:

MS   7. Add the relevant NT PVstructures to pvManager - those types pvmanager already understands. 
GW 8. Mechanism for header and copyright.
MK 9. Bug that v3Channel and pvIOCJava fail for remote access.
MK 10. Add unsigned to v3channel 
MS 11. pvAccessJava test server not working due to beta 2 changes.
MK/MS 12. Upgrade documentation to beta 2. 
MS 13. Upgrade pvAccess specification document reflect implementation.
DH 14. Finish implementing java unsigned. 
MS 15. Java RPC depends on record processing, c++ Doesn't. Put Java RPC into pvAccess. This is
part of job 1 aboce, Async RPC. In Java, RPC will be multithreaded. In C++, not multithreaded.

<pasted into minutes>
Greg White, SLAC/PSI, 7-July-2012

This document lists proposed objectives for an activity in the EPICS V4 sphere,
towards a software platform and software services for online accelerator physics. 

Since name mapping and name acquisition depends on modelling. And applications and physics services depend on modelling, names, and unit conversion. Therefore, we have to create the reference system as a whole. The proposed major parts of the working group activity are described below.

1. Engineer, develop and provide reference implementations for "GUI" online operations accelerator physics applications, using the ecosystem of services defined below.

Example charter deliverables:  
    + Correlations plots
    + Wire scan
    + Emittance measurement
    + Archive data analysis

2. Unit Conversion. 

Engineer, document and provide a reference implementation for,
the problem of magnetic field and power unit conversion (energy independent field/ energy dependent bending gradient/ power supply current), that is general enough to be applicable and easily applied by a number of labs. 

Example charter deliverables:

This project is probably as much a documented design pattern as it is software. The solution is probably composed of:
   i) a reference document for the basic equations aimed at providing a 
      common "data dictionary" for software engineers and physicists
   ii) a reference (relational) database schema for associating K from model, 
      to magnet 
      measurement hysteresis records
   iii) and a reference implementation of a V3 magnet control with magnet 
       polynomials acquired from the database (through the combined 
       EPICS V3/V3 IOC described in [1].

2. Accelerator part Name Mapping. 

Engineer, document and provide a reference implementation for,
the problem of the mappings and associations between accelerator parts. That is,
between beampaths and modelling sections, lattice elements, composite devices, devices and process channels.

This would provide a documented taxonomy for those issues which are often poorly dealt with in control systems, such as the association of beampaths at different energies and timing profiles, to devices; from devices to lattice elements (such as klystrons to cavities and split quadrupoles to modelled lattice "slices"), and associating devices to their composite process control PVs.

Example charter deliverables: probably a document, database schema, V4 Directory Service config files, and work in unison with the model service below.

3. Directory Service

Engineer, document and provide a reference implementation for,
a directory service which can combine the solutions for name mapping and modelling.

4. Core Online Accelerator Physics Services.

Engineer, document and provide a reference implementation for,
the basic physics services that would make online software easier to develop, 
and the online control system faster and richer. 

Example Charter Deliverables.
A set of first services so defined is probably quite small:

    + Online model (giving design, and presently extant Twiss and R-mats, plus a 
      way to record so computed models in a database so that the same 
      model may be used by different control room software).

    + BPM Orbit acquisition system. A service that combines the V4 gather 
       system, and the SLAC/PSI pattern for pulse synchronous BPM-like 
       device value acquisition, to provide a very-very-easy to use API for 
       matlab apps to get synchronous orbits. Eg:

         orbit = easyPVA.createChannel(...

    + Magnet service. A service that implements synchronous magnet field changes.
    + LEM service. A service that can measure the difference between the 
       intended focusing field of quadrupoles, given the extant energy, and 
       the desired focusing field; and can be used to correct the difference.

    + Archive service. A service that makes any archiver implementation 
       data avilable as a V4 service.

5. Develop a web service for acquisition and return of any data.

Use fast web service technology for acquiring EPICS data and returning it. Probably IBM XML Screamer and EXI, or Agile Data + EXI. AJAX data binding. Possibly develop this in conjunction with the effort to put web data services in EPICS IOC as described in [1].

6. Prerequisite EPICS organisation.
  1. Bob becomes Director.
  2. Working Group Process becomes official mechanism for Working Groups.
  3. EPICS distribution wed site hosts V4.
[1] Epics Systemic Requirements proposal (draft 1.1, 9-July-2012)

 <end paste>