Agenda for 20-Feb-2013

----------------------

1. Status of Performance measurement benchmarking (*Matej*, 5 mins)

2. Objectives for Diamond meeting [3].

  What talks are we going to give at the Diamond EPICS Meeting?

  To get the ball rolling chairs propose something like the following:

  Overview of EV4 and years activities with demo of eget getting data

      from various sources *Greg*,*Matej*

  V4-IOC integration:

       pvaSrv (*Ralph*)

       pvaccess and Ntypes in pvManager (*Matej*)

       IOC modifications for large datasets (*Michael*)

  BNL Physics Apps (*Lingyun*)

  Services (flash talks, ~7 mins each)

       Directory Service, eLog, Masar,

       Unit Conversion service, integration with CSS (*Guobao*)

       Model (*Greg*), Archiver (*David*), Directory (*Ralph*)

  Developments and Activities for this year:

       Image processing pipeline prototyping (David)

       JavaIOC (Marty)

3. pvaSrv internal names (10 mins)

  Review of Ralph's proposal for naming components of pvaSrv [5].

Minutes

======

Present: BD, MD, DH, AJ, MK, RL, NM, MS, GS

Scribe:

Chair:

New Topic: Status of Performance measurement benchmarking

MS: Created pvCommonCPP [for boost]

Put measuring points in pvDataCPP.

Prototype was only on MacOS, now should work on other platforms.

Has verified vxWorks

AJ: Are you using Epics time API?

MS: Not yet, wanted to check with AJ. Is it high performance [or will it

pollute results?]

AJ: Shouldn’t be. Does it get high res time on mac?

MS: Let’s take this offline.

AJ: Right, if we can improve EPICS time for what’s needed, then let’s do that.

GW:

MS: Framework has 2 parts: You can get all the samples, and analyze with

own tool, or use 2nd simple tool to get table of results. The 2nd one can be

adapted easily.

GW: We don’t include analysis or other executions that take very long compared

to others.

MS: Next week I should be able to complete the framework, add other measuring points.

New Topic: Items for the Diamond Meeting

GW: BD and GW put a list together, that they want to see completed before the Diamond meeting. Goal: reorient V4 thinking towards integrating the V3 IOC, plus some services. “Services” sometimes is a dangerous term in V3 context.

GW: Any talks and topics missing?!

Revision:

Overview of EV4 and years activities with demo of eget getting data

      from various sources *Greg*,*Matej*

  V4 - V3IOC integration:

       “EPICS Base from v3 to v4” (Andrew)

             How AJ sees v3 merging with pvData/Access/Srv to become v4.

       pvaSrv (Ralph)

        Design and implementation overview

       pvaccess and Ntypes in pvManager (*Matej*)

       IOC modifications for large datasets (*Michael*)

  BNL Physics Apps (*Lingyun*)

  Services (flash talks, ~7 mins each)

       Directory Service, eLog, Masar, integration with CSS (*Guobao*)

       Model (*Greg*), Archiver (*David*), Directory (*Ralph*)

  Developments and Activities for this year:

       Image processing pipeline prototyping (David)

       JavaIOC (Marty)

GW: Real titles by next week

BD: Titles are not relevant

GW: David, is the main thrust of your work now in the image processing pipeline?

DH: Not now but it will be.

<discussion on whether DH will be in a position to talk about proposals for a processing pipeline>

GW: We said one of the main V4 activities this year will be this imaging pipeline. We need a better definition and a plan. BD and DH might have to agree on a plan of action.

DH: Will fix the bugs and add an AreaDetector plugin (serving AD frames as pvData images). this will show valuable aspects of what we need for a V4 IOC.

GW: Others might want to cooperate, so a plan/schedule would be extremely useful.

MD: Part 1: General improvements to data handling (primarily in pvDataCPP)

Part 2: pvaSrv improvements to integration with the V3 IOC (most of which would be on the V3 side)

AJ: DH’s stuff would be serving NTImage data over pvAccess from AreaDetector, without the V3 IOC, correct?

GW: Would like to have a one-page description (including diagram of who is doing which parts)

DH: The other aspect is automagically creating the complete V3 IOC and configurations, screens, panels, etc. from one source. (These are the requirements from Tom.)

GW: Can MD talk about his planned changes next week?

MD: Sure.

BD: And benchmarks.

GW: Can we get a statement about what BNL’s objectives are?

BD: It’s about optimizing the V3 data flow (driver -> db -> network protocol)

MD: I could write an email about this.

GW: Please include how BNL sees the developments for V3/V4/pipelines.

MD: OK. I’ve been warned.

New Topic: pvaSrv internal names

RL: The parts that interface to one v3 pv, we should call “v3Pv”.

RL: The part that interfaces to a pile of v3 pvs, we should call “v3Group”.

GW: “classicPv” and “classicGroup”?

MK: Ralph’s names make complete sense for existing V3 users.

BD: Use the term “IOC”

GW: Rename the Java IOC

RL: Don’t call any V4 processing “thing” with the term “IOC”

AJ: DB

MD: PDB = Process Database

RL: dbPv and dbGroup would work.

GW: +1

RL: Then going forward with the API that combines db pvs with pvs from elsewhere, might be called “Pv” and “Group.” i.e. dbGroup is a specialization of Group.

RL: Do we also need a n-type for output of pvaSrv? [RL] thinks not yet.

RL - can see that certain n-types would imply certain monitor options and process

 options. At the moment, n-types are not defined w.r.t. processing at all.

- e.g. if we have an NTGroup type, clients would want to specify for process=true the set and the order of the group members that are to be processed.

RL: So we shall return to this when the process and monitor options are defined.

GW: We need Matej to give a proposal for monitor options at least.

MK: There are some now, but they refer to a single record.

Rl: What’s the right term for “monitor options”?

MK: Don’t know.

*******************

AI on MK by 26-Feb: Find out what present support there is for

monitor and get/put options, for presentation in next meeting.

*******************