Re: NT Types

[White, G. <gr...@sl...>]

Hi Matej, right, exactly that's what I was getting at - we have to put error and
value into the other types, but we can't codify the semantics of the numbers
returned in value and error, it's too complex. I think even if one could codify
it, it then wouldn't be used in practice.

Other stuff.
NTMatrix shouldn't have error. One would use another NTMatrix for the covariance matrix.
NTTable I think should have error in some codified way. I've wanted that many times.

Cheers
Greg


On Apr 16, 2014, at 4:34 AM, Matej Sekoranja <mat...@co...<mailto:mat...@co...>> wrote:

Here is my take on errors.

Error should be carried with the value.
Once you introduce error you should always propagate it (e.g. if you multiply 2 values, you should recalculate an error too) - once you ignore it, you break the chain.

So I would add

structure NTScalar
    scalar_t value
    double error (opt)
    ...

to NTScalar.
(I'll ignore other types for the time being.)

However, I would not add any other fields, e.g. "long n".
A error value can be a source of different things: measurement/instrument error, statistical post-processing, etc., and for each different case you will need different meta-data (e.g. N, min, max, start-end timestamp, etc.). These are just too specific to be a part of NTScalar (and are more meta-data as data), however there can be a way to get this (optional "NTAggregate stats" field, RPC call, whatever...).

For other complex NT-type I would say: a value field is always accompanied with error field, e.g.

structure NTHistogram
  double []  ranges
  (short[] | int[] | long[])  value
  double[] error (opt)


structure NTcontinuum
  double[] base
  double[] value
  double[] error (opt)


NTTable is a tricky thing, since there is no "value" field. It a set of columns. If you need to put an error there you add a column field called "error" of type double[].
(Using a non-scalar type for a column values is an overkill!).

structure NTMatrix
    double[]  value
    double[] error (opt)

I think this is the most we can do regarding errors, any other solution is just too complex to be accepted (IMHO).

Matej

ps pvaSrv does return NTScalar/NTScalarArray.



On Wed, Apr 16, 2014 at 6:28 AM, White, Greg <gr...@sl...<mailto:gr...@sl...>> wrote:
[Adding EPICS V4 Developers for archive - so we can capture this thread]

Hi Bob, responding to your request for use cases. Sorry, it pretty
long; I added some vocabulary clarification I think we're missing,
a note about error from IOCs (important for pvaSrv), the requested
use cases, and all the names and phone numbers in my little black book,
'cos I'm married now.


Words
-----
Before I start let's be clear on terms "value" and "error". We're
talking about 2 cases which use slightly different language, and but I'm
summarizing the two important quantities in both of the two, by "value"
and "error".

The first case is a number of measurements made of an observable - in
which case "value" is the central tendency (often but not always given
by the mean, but may be median, and number of other measures - even
FWHM) and error is the dispersion (often computed by RMS, but may be
standard deviation, or again, any number of others).

The second case is fitting data, in which case "value" might well be the
so called "expected value" at the given point, and "error" would
probably be the residual at that point (rather than the error in the
true fitting sense of fit error, though in some cases it could be). Or
the datum could characterize a whole curve, in which case value may be
an array of fit parameter values and error might be the Chi-sq.

So my point is the possibilities for what exactly are meant in each
instance of a value and error, are many. We can't possibly cover them
all. But we do at least know that a common thread through all of these
is that two quantities represent a datum; the value of the datum, and
numerically how good the value is (the error). Our datum objects
(N-types) should handle these as well as regular data.

Normative Type usage comments
-----------------------------
With respect to a conclusion, I'm clear only that error (and number of
observations) must be added to Normative Types at the same level as a
value (presently represented by NTScalar and NTScalarArray). But 2 big
things remain:

        1. Just saying error (and N) must be added to the level of a
        value (NTScalar and NTScalarArray) doesn't help NTTable,
        NTContinuum, NTHistogram, NTMultiChannelArray. And it needs
        to. I'm completely absolutely sure. For EPICS V4 to be serious,
        those types must encapsulate error in a way that clients can
        look for it and find it, or know for sure it isn't in the
        returned variable.

        2. In JavaIOC days it was roughly clear what the association of
        a javaIOC process variable to a PVStructure was, and hence to a
        Normative Type was. But with pvaSrv over IOC records, it's not
        clear at all. pvaSrv doesn't return Normative Types (like
        NTScalar or NTScalarArray). Even if it did, since at present in
        an IOC, the value of a pva PV and its error come from different
        records, it's impossible presently to encode a pva PV for the
        value and error of an IOC datum [that's right isn't it?].  So,
        returning the error of a value with the value would be a major
        major feature of adding pvaSrv to an IOC, but it needs to return
        N-types, and those N-types must be modified to encode the
        error. Those n-types would be NTScalar and NTScalarArray for
        single quantities, and NTMultiChannelArray (stupidly named, it
        should be multiPVArray) for a system of PVs from the IOC. And it
        seems all of these must be done by dbGrp, since even one such
        datum, in 1 NTScalar, must from >1 record in the case of a PV
        with error.

Use Cases
---------
> Greg can you think of other compelling arguments / use cases for error?
> If only BPMs, why not serve those values with statistical samples as a
> secondary server?

There are many, these are just a few:

1. Fast Beam pulse synchronized data.  Not just Beam monitors, but any
gated ADC type device which is sampling at a rate which is faster than
the rate at which those samples are collected.  In this case the
sampling is free running synchronized to beam but collection happens
asynchronously. So when I say BPM, I mean any gated adc type device:

Consider also that this class of data usually is retuned in different
data shapes.

  a) one bpm.

        i)   one bpm sampled over M pulses - 1 data point returned,
             being the value and error (over the M observations)
        ii)  one bpm sampled over M pulses - return array of M data
             points (all values, no error)
        iii) one bpm sampled over M pulses N times - return array of
             M data points each with errors (over the N observations)

     At SLAC we call this "buffered data" - after its need for a fast
     buffer to do the aggregation accumulation.

     USE CASES: fast feedback. orbit diagnostics.

  b) A beam synchronous acquisition of many BPMs - where the data
     returned for all BPM are taken to be from the same pulse:

        i)  m bpms sampled over 1 pulse
        ii)  m bpms sampled over M pulses
        iii) m bpms sampled over M pulses N times

     At SLAC we call this Beam Synchronous Acquisition (BSA) data. Yes,
     it's the same as a) above for the case of m=1 bpm. But it's
     different in that you don't need as much IOC in a as you do if you
     know you're going to need b.

     USE CASES:

         1. orbit display and orbit fitting (fit on the errors too).

         2. steering (if a bpm has high error you don't include it in
       the steering problem (Ax-b).

         3. Model Independent Analysis (MIA). In this case the errors
       are really key.

2. Archiving data of 1a and 1b above. At SLAC we continuously archive
1.a.i) data for every GADC type device. That is, for every GADC in the
machine, we archive for instance, for a BPM [{X, Y, TMIT} x 15 event
codes x {Value, error, M} ] = 135 PVs! Yes, every BPM in LCLS has at
least 135 PVs, just for its synchronous data, and all 135 are archived.

3. The results of measurements made by applications. A number of "high
level" applications take samples from PVs, and do a calculation, and
store the results in PVs, which are then archived. Eg of errors
calculated by apps: pulse length RMS, laser camera saturation RMS, orbit
fits (as above) where error is ChiSq of the orbit fit.

5. Correlation Plots. This is an interesting use case. Correlation Plots
is an application that helps you make acquisitions and then do
analysis. Fitting is a major part of the analysis. Often the data taken
in have eg RMS error (bpms, toroid etc) and you do a fit on the data -
which leads to fit residuals and ChiSq of the fit. Many similar apps which
are built on top of correlation plots do a similar thing for specialist
analysis, like wire scans, emittance estimation, undulator setpoint
optimizations etc, and those archive their results.

Cheers
Greg

[1] http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes=
.html#ntaggregate<http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes=.html#ntaggregate>


On Apr 15, 2014, at 9:53 AM, Dalesio, Leo <da...@bn...<mailto:da...@bn...>> wrote:

I am sorry =E2=80=93 I disconnected by accident and each reconnect I could =
neither hear =E2=80=93 and I assume =E2=80=93 be heard. I was trying to mut=
e so I could catch Michael D. up. I think that we are the sum of those argu=
ing for and against and would like to resolve this.
To recap =E2=80=93 I hear we reached no conclusion =E2=80=93 so=E2=80=A6..
I would like to declare =E2=80=93 that a field that denotes the error bars =
on a value be added as a double to the scalar types. The discussion has gon=
e on for years. No one has ever argued that time stamp and alarm severity w=
ere not essential to understanding a value. The one issue that was left on =
the table, was the intrinsic precision of the value. PREC was just a hint a=
bout how to display the value. DBND was just a hint about when to send the =
value and it was strongly suggested that this value be at least as big as t=
he systematic error of the instrument and the cabling. Adding this to the v=
alue does not improve any of the services that are not about instrumentatio=
n. However, this is for control systems and at NSLS II, 1 million of my PVs=
are connected to instrumentation =E2=80=93 and at least 100K of those are =
analog. Additionally, our new intelligent instruments are sampling data at =
ever higher rates and can calculate things like error in real time. BPMs ar=
e the best example as the error is extremely important when performing feed=
back. However, a conscientious process engineer will include this.
The alternative of using the statistical type could be successfully made. I=
f the only case that cared about this error field was the feedback clients,=
it would be OK to insist that NT_what did we call stastics?, be used to se=
nd these to the feedback algorithm. In either case, we need to modify the B=
PM electronics. If we do this, we would lose this information from the gene=
ral instrumentation interfaces. For instance, thermocouples are accurate to=
3 dgc. All instrumentation has some level of validity. The pick up, the ca=
bling, the adc, the oversampling/averaging all feed into this value. If som=
eone is going through all of that trouble of oversampling, why not send up =
all of the information =E2=80=93 or at least the statistical information? I=
do not hear anyone lamenting that they do not know the accuracy of their t=
hermocouples. The only place I hear the lament is on BPMs and only in the c=
ontext of performing feedback.
If there are no more compelling cases, I suggest that we do not add the err=
or to the NT_SCALARs. Greg can you think of any others? Matej? Is there any=
trouble in making the V4 statistical type the service from the BPMs? It wo=
uld give much better understanding of the reading than just an error value.
For Gabriele  =E2=80=93 we do not have to pass this through to PVManager =
=E2=80=93 as the use of it should only be on the specific instruments where=
it is important. I do not recall Nikolay=E2=80=99s argument against.
The argument I do recall from Nikolay is that the archive servers should ha=
ve more than one return method. I would like to build on that later. Archiv=
ers should be able to respond to requests with different types =E2=80=93 ta=
ble, time series of NT_SCALARs, and a time series of NT_STATISTICAL values =
that return statistics on the compression. A single statistical value shoul=
d also be available from over sampling instruments =E2=80=93 like the BPMs.=
This does not have an impact on the normative types =E2=80=93 just the way=
we view the way we implement services =E2=80=93 right?
Sorry for my technical problems today =E2=80=93 can we try to resolve this =
in the following way=E2=80=A6..
Greg can you think of other compelling arguments / use cases for error? If =
only BPMs, why not serve those values with statistical samples as a seconda=
ry server? Anyone else with arguments FOR making the error a part of NT_SCA=
LAR voice them now.
Thanks,
Bob