AGENDA
=======

Colleagues,

In tomorrow's telecon I'd like to go through the list of illustrations of the
basic functionalities of EPICS V4, and assign people responsible for delivering
demos of that functionality.

There are 18 such illustrations listed below. Each have a name attached.

Now, basically all the line items have pre-requisities, that's the point of the exercise. It
forces us to be clear about the non-functional requirements necessary to achieve the
functional requirements. For instance, #10 requires NTMatrix be defined, which means an
NT self-id solution must be implemented, and a way for eget to talk to a service must be implemented.
Therefore, for each of these, we must be clear on the prerequisites and who is responsible for them (yes,
I know I'm attached to many of them). However, part of the intention of assigning responsibility
for the line item deliverable, is to ensure that the named individual demos the functionality
whether they received the prerequisite or not. I think there is only one prerequisite which, if absent,
truly renders solution impossible; that's the way eget should interface to services
that take arguments.

So, tomorrow, let's first go through the list below to assign responsible party. Then spend
some time on the basic service interface.
  * *Ralph*, *David*, how do you define your services to take arguments. Did you use the same method
  as hellowService and rdbService?
  * Should a javaIOC be necessary? if not, how would be arguments be formally documented (since there
    would be no database xml file?
  * I would like an interface in which one can ask the service what are its arguments. How would that be
    achieved?

Timeline. All of these shall be demoed at the October meeting, 17-19 Oct.
** But, I would like to be able to conduct ALL the demoes myself. That ensures that they
are all mature enough, and encapsulated enough, that examples can be distributed and documented
sufficiently for a new user. So, I'd like to take delivery of these by *1-Oct*.

MINUTES
=======

Present: BD, DH, TK, MR, JR, MS, GS, GW
Scribe: JR

*********
TOPIC: Put names on each deliverable demo per list below
*********
GW: Focus on first item, demos to be delivered for the October meeting.

GW: Any person should be able to download and run the examples after reading the documentation. Better than developers demonstrating their applications.

MS: can do items 1 and 2

GW: This is ambiguous, would like to demonstrate both cav3 as a provider, and cav3 via V3Channel.

MS: Use channel access native libraries from client?

GW: Ways are channel access on the wire, and V3Channel on the V3IOC with pvAccess on the wire. Don't have good names for these methods.

MK: V3Channel is in pvIOCCpp, returns V3 record values over pvAccess.

MK: cav3 is in pvAccessJava and allows you to talk channel access using the pvAccess API. Not available in CPP. Client must specifiy which transport.

GW: V3Channel is pvAccess on the wire (c++ server only), cav3 is channel access on the wire (Java client only). Both use the pvAccess client API.

GW: Hard part of 2 is a is a way of specifying the provider on the command limand line.

MS: Problem is no implementation of cav3 in cpp, eget is in cpp.

GW: MS can demonstrate V3Channel by October, not the use of cav3 in eget?

MS: Yes

GW: OK

MK: Week's work to do that.

GW: Important AI. Do V3Channel mechanism. Demo cav3 when it's ready.

AI MS: November, start cav3 implementation in C++.

GW: Item 3 (unsigned)

MK: Java client can talk to pvIOCCPP over pvAccess and get an unsigned field or record. It will work. But the Java client can't use the data.

GW: Can use C++ both ends. Point is to demonstrate pvAccess transporting unsigned.

MK: What are you going to do with it?

MS: C++ client and V3Channel server. 

MK: This will work with C++ both ends. Item 3 will work.

GW: MK able to implement?

MK: Need records to demonstrate this. Records that make sense.

GW: Just need large number.

MK: Need a record with a large 32 bit unsigned value. Can do that with MS.

MS: Yes we can do that

GW: Item 4  trivial

GW: Item 5  trivial

MS: Want one value per line?

GW: Yes, like RDB service. Default one value per line. Optional for row-wise is good. Can pipe into UNIX tools.

GW: Item 6, will eput exist? 

MS: pvput exists, can do scalars and arrays.

GW: Need a server that has a scalar and and array to put to.

MK: For 7 and 8, when I setup a V3 IOC with V3Channel have another waveform record for item 8. Use the same test IOC IOC.

GW: Yes would like a V3 and V4 IOC for tests/demos. Shall we use a test one for demo purposes?

MS: Yes.

MK: Yes, one Java IOC and one V3 IOC with V3Channel. I will do this with MS.

AI on MK and MS: Produce test/demo IOCs in C++ and Java to go with client items.

GW: Item 9

MS: eget with switch performs monitors.

GW: Item 10 get as a NTMatrix. Does eget know NTMatrix? 

MS: It knows NTTable, not NTMatrix yet. I will add NTMatrix to eget.

GW: Pass arguments, make new item 10.1

MS: Arguments are passed as a string. What is the service API?

GW: WIll define API. Have Java library for arg parsing.

MS: eget in C++

GW: Argument passing for RDB service use support offered by bash for argument passing. Java library does the same thing.

GW: Item 11 get NTTable and print as a table and print as a table. 

DH: Archiver result is NTTable. Request is a structure containing start and end time, channel name. Request is not an NTTable

GW: Ok, requests won't be NTTables anyway.

DH: Current repo built against release 1.1. Currently refactoring. Fieldname change is ok, some libraries have moved around, more work required. No problem for October.

GW: Demonstration?

JR: You can distribute archive data with the example, no need to connect to a remote server.

DH: Works out of the box once it's been refactored, already includes sample data.

GW: Gather. Timo? Example by 1st October.

TK: Time is tight.

GW: Get synchronous orbit data?

TK: Same time pressure.

GW: Item 17. Using V3Channel mechanism. 

MK: Clarification required? Is this an local gather on a V3 IOC.

GW: Yes.

MK: Work needs to be done. V3Channel connects to a single record at one one time.

MK: Start with homogenous gather for October. Get an array of scalars where each element comes from a different V3 record.

GW: How to configure it so that the V4 PV knows which records to gather. Requirement is to get multiple fields.

MK: Fields and record terminology is mixed. Can get EGU, timestamp, alarm p, alarm etc. from single V3 value already over channel access.

GW: So user can get all channel access standard fields back alreadyy. But only what version 3 supports.

MK: Value of V4 gather record will be an array of scalars.

GW: Why is homogeneous support harder? Can introspect and create structures on the fly.

MK: Could do something like the example.

GW: If I want to get a quadrupole, what would I see? I want a single V4 PV giving me back the B field, polynomial and energy. Create support with V3Channel to get a list of version 3 PVs as a PVData structure.

MK: What are the records that represent a quadrupole? There are a collection of V3 records that give you the various parameters.

JR: Something like this?

record(ai, "CURRESETPOINT")
record(waveform, "POLYNOMIAL")
record(ai, "FIELDSETPOINTNT")

MK: Committed to come up with a V3 IOC and a V4 IOC for the demo. Will attempt to to come up with some records for an example.


MK: Is all  this stuff going in example application.

GW: Not single application, no. I'd like to be able tole to talk to example IOC with eget on comommand line.

MK: Where are we going to put them.

GW: New place  on sourceforge.
MK: exampleCPP/Java?

GW: All ok with that?

Resolution: Put demos in examexampleJava and exampleCPP.

GW: Put good readmes in these.

GW: last Item. EasyPVA. I will take responsibility for that. Haven't tried for RPC yet. Once have ththat can test everything.

GW: Is there a way for a user to ask a service what it's arguments are.

MS: User can get information using introspection with get field. Needs text too.

GW: Formal definition can be in description field. I'll try and work on that.

Thanks to James and David.
Meeting ends. 


FUNCTIONAL REQUIREMENTS OF EPICS V4 ILLUSTRATIONS
=================================================
Basic Get and Put
=================

*MS*
1. Get the value of an V3 PV [user has no knowledge that it's V3 as opposed to V4]
eget QUAD:34:IDES
23.424

*MS*
2. Get the values of all the V3 CA standard fields (-r is pvAccess request string)
eget QUAD:34:IDES -r 'field()'
structure QUAD:34:IDES
{
   value = 23.424
   alarm = structure
   {
       severity = structure
       {
           index = 0
           choices = [none,minor,major,invalid]
       }
       message = null
       ackTransient = false
       ackSeverity = structure
       {
           index = 0
           choices = [none,minor,major,invalid]
       }
   }
   timeStamp = structure
   {
       secondsPastEpoch = 1253549456
       nanoSeconds = 478000000
   }
}

*MK*
3. Get the value of an UNSIGNED V3 PV
[Can't think of a sensible large number, but can think of many that would only be +ve]
eget BEAM:RATE
60

*MS*
4. Get the value of a V4 scalar pv
eget XCOR:LI:34:IACT
23.3

*MS*
5. Get the value of a V4 array pv to the command line
eget QAUD:LI:18:POLYOMIALS
34.6
19.5
29.3

*MS*
6. Put the value of a V4 scalar pv
eput -v 34.4 XCOR:LI:34:IDES

*MS*
7. Put the value of a V4 array PV
eput -v 34.4 19.6 29.3 XCOR:LI:34:IDES

*MS*
8. Put the value of a V3 waveform [(!!!) is this possible?]
eput -v 34.4 19.6 29.3 QUAD:34:POLY

*MS*
9. Monitor the value of a simple type V4 PV
emon BPMS:LI34:X
[MS: says we have pvget with a special switch for monitor]

*GW*&MS
10.  Get a NTMarix and print as a matrix
$ eget -a TYPE=DESIGN -a POS=MID -a RUN=LATEST QUAD:LI21:271/R
0.23 0.1234 0.0 0.0 0.067562 0.001167
-0.34520 0.0923 0.0 0.0 0.046981 0.001514
0.0 0.0 1.881007 4.857304 0.0 0.0
0.0 0.0 -1.50064 -3.862346 0.0 0.0
-0.00132 -0.001129 0.0 0.0 0.224701 0.003894
0.162595 0.10285 0.0 0.0 -19.603 -0.233109

10.1 Get values according to arguments in a consistent way from any RPC service
See examples eget -a above.

*DH*
11. Get a NTTable and print as a table. Illustrate with archive service.
$ eget -a start="3 minutes ago" -a end="now" -a p=12 QUAD34_Bfield

TimePastEpoch(s) Value Date Alarm
496169397.856321000 7.355487346649e-02 Wed Jun 21 17:49:57 2012 NO ALARM
496169401.996447000 1.682446300983e-01 Wed Jun 21 17:50:01 2012 NO ALARM
496169410.052636000 2.558367252350e-01 Wed Jun 21 17:50:10 2012 NO ALARM
496169420.109690000 3.173123300076e-01 Wed Jun 21 17:50:20 2012 NO ALARM
...


Use Cases of Directory Service
==============================
*RL*
12. Get the names of a number of PVs (v3 or v4 potentially heterogeneous mix) where their names match a string, using the Directory Service. Ideally, sort by a tag or option. E.g.:
eget -s DirectoryService -a pattern 'XCOR:*:BDES' -a options "sortbyz"
XCOR:1:BDES
XCOR:20:BDES
XCOR:44:BDES
XCOR:68:BDES
XCOR:89:BDES
...
Extra credit: ideally not just * but regular expression.

*RL*
13. As above but additionally get the values. In the case illustrated below done with a pipe, but better if integrated into eget.
Eg. Print the value of BDES from all correctors whose PV name matches the pattern XCOR:LI:*:BDES
eget -s DirectoryService -a pattern=XCOR:*:BDES -a options="sortbyz" -a beampath=0 | xargs eget -t {}
XCOR:1:BDES
23.5
XCOR:20:BDES
34.5
XCOR:44:BDES
15.5
XCOR:68:BDES
13.7
XCOR:89:BDES
34.5
...

*RL*
14. Get the value of a number of PVs, where the names match the conjunction (AND) of Directory Service tags
E.g.: Print the value of the desired B field (BDES) from all correctors in the (SwissFEL) section SINBC01
eget -s DirectoryService -a property='section=SINBC01' -a property='type=COR' tag='BDES' -options="sortbyz" | eget -t
sinbc01.cor01:B 23.34345
sinbc01.cor02:B 43.47543


Use Cases of Gather Service
===========================
*TK*
15. Use of an ad hoc Gather to get the field value (V3 PVs) of many magnets or BPMs.
Show use of gather service to simply give LATEST gathered values from a Gather record defined by the client:
So this is something probably done in Matlab
[TODO insert example]

*TK*
16. Get synchronous BPM orbit data from a BPM service, that is using the gather service in combination with a SLAC/PSI
like BPM synchronous data system. Data form is NTTable.

eget -a Npulses=3 SwissFELTI:sync:bpmorbit
pulse_Id bpm_name            X         Y             TMIT         Status
31330    sinlh01.diag01.bpm  0.331939 -0.20821595 9.2273582E9 OK
31690 sinlh01.diag01.bpm  0.343939 -0.21321534 9.3973582E9 OK
32056 sinlh01.diag01.bpm  0.343939 -0.21321534 9.3973582E9 OK
31330 sinlh02.diag01.bpm  0.430091 -0.19211863 9.4554767E9 OK
31690 sinlh02.diag01.bpm  0.429820  -0.18054654    9.3577114E9 OK
32056 sinlh02.diag01.bpm  0.476549  -0.23452345    9.3245235E9 OK
... snipped many more
Total number of rows printed would be M bpms in the gather record named SwissFELTI:sync:bpmorbit, times
N pulses

*MK*
17. Get the values of a number of V3 PV (fields) from one V3 IOC, through a V4 record on V3 IOC PVA
[ie, "The Dirk Requirement" ].
Ideally a heterogenous structure of V3 scalar and waveforms.
E.g. Get a summary of the PVs relating to a QUAD from an IOC. In this example the V4 PV
is QUAD35:SUMMARY, to illustrate that one might use the "physics" name (QUAD35) for such summary
PVs, and their values might be composed of a structure of V3 PVs named with engineering names and their values:

eget QUAD35:SUMMARY
QUAD:SECT02:13:B 42.3
QUAD:SECT02:13:POLY 23234.2342 5435.34 753.3 4.34234 5.32E-23
QUAD:SECT02:13:E 4.454


EasyPVA, Model Service and Directory Service from Matlab.
=========================================================

Overall *GW*, from input from RL and TK.

18.  Example of orbit correction from Matlab, done using easyPVA
Illustrates requirements for:
1. EasyPVA understanding request for PVStructure
2. EasyPVA understanding arguments as part of request for data
3. EasyPVA understanding that an argument TO a service may be an array
   (in the example a table of magnet names and B field values)
Also assumes the Directory Service requirement articulated above to get Corrector and BPM names
-------------------------------
% SwissFEL orbit correction in 1/2 page of matlab
% The following is syntactically valid Matlab, but need to see from Ralph how it is actually done.
%
import org.epics.ca.easyPVA.*;
easyPVA = EasyPVAFactory.get();

% *RALPH*
% Get the names of all the Correctors and BPMs from the Directory Service
corrNamesChan = easyPVA.createChannel('DS:SwissFEL:GUN_to_ARAMIS');
corrNamesChan.addArgument('DEVICETYPETAG','XCOR');
corrNames = corrNamesChan.createGet().getStringArray();
bpmNamesChan = easyPVA.createChannel('DS:SwissFEL:GUN_to_ARAMIS');
bpmNamesChan.addArgument('DEVICETYPETAG','BPMS');
bpmNames = bpmNamesChan.createGet().getStringArray();
Ncor = length(corrNames);
Mbpm = length(bpmNames);

% *Timo*
% Get BPM x orbit from the BPM service.
b = easyPVA.createChannel(...
   'BPMORBIT:SwissFEL:GUN_to_ARAMIS').createGet().getDoubleArray();

% *Greg*
% Form the Ax-b problem getting Rmats from the Model Service
modelmatrixChan = easyPVA.createChannel('model:aramis:gold:extant:R');
for bpmi = 1:Mbpm;
  modelmatrixChan.addArgument('to',bpmNames(bpmi));
  for corj = 1:Ncor;
     modelmatrixChan.addArgument('from',corrNames(corj));
     rmatAtoB_pvStruct = modelmatrixChan.createGet().getPVStructure();
     RmatCorToBpm = toMatrix(rmatAtoB_pvStruct);
     A(bpmi, corj) = RmatCorToBpm(1,2);
  end
end

% 2 lines of actual physics
x = inv(A)*b; % Solve Ax-b
newBDESes = -KtoB(x); % new B field values from K to B

% *RALPH*
% Deploy the new magnet settings.
magSetChan = easyPVA.createChannel('MAGNETSET');
magSetChan.addArgument('magnetlist',corrNames);
magSetChan.createPut().putDoubleArray(newBDESes,length(newBDESes));
-----------------------------

* EasyPVA to "put" a PVStructure to a service or PV
add example.