Ideas for areaDetector in EPICS V4 – from the Science and Technical perspective

1. Ideas for areaDetector in EPICS V4 – from the Science and Technical perspective Nick Rees & Ulrik Pedersen

2. Top Down view

3. areaDetector in EPICS v4 • areaDetector in EPICS v3 passes data between plugins by passing a pointer to the data to another asyn port. • One data type (NDArray) • One process. • areaDetector in EPICS v4 potentially can: • pass data between processes or systems using pvAccess. • Support more complex processing than can be done by one process. • Support the needs of parallel detectors • Potentially a hugely flexible image processing and detector system.

5. Workflow views: DAWN/Passarelle

6. UFO (Ultra-Fast O?)

7. Master Node FEM FEM FEM FEM FEM FEM Readout Node Readout Node Readout Node Readout Node Readout Node Readout Node Sensor/Medipix3 Hybrids Network 10GigE Optical Links Detector head Detectors • More larger, parallel systems. • Need classes to help writing detector drivers. • Major amount of work we do. • Control fanout is not easy in V3. • V4 structures clearly help here.

8. Carrier Board AGIPD Board Key Detector Control Software Percival Control and Data Protocol Control Driver Data Receiver Detector Data Stream (n copies) • Data Processing: • 2 bit gain handling • DCS subtraction • Pixel re-arrangement • Rate correction(?) • Flat field • Dark subtraction • Efficiency correction Configuration Cmd Status Documented Controlled Interfaces Control Server HDF5 file Beamline Control Software Detector API Data Compression Detector Engineer Software EPICS/ Area Detector Tango/ Lima Matlab HDF5 File Writer Actual/potential network or CPU socket boundaries HDF5 file

9. Lessons from Lima • Independent library with minimal dependencies • Easier unit testing. • Simpler dependencies. • Processing model is per frame, rather than per plugin • ProcessLib assembles a list of operations to be done one a frame and passes it to a thread pool. • Different frames can have different processing. • Python is tightly integrated. • Flexible and fast to develop.

10. Message types: Request response Publish/subscribe Push/pull Lessons from ZeroMQ

11. Bottom up view

12. areaDetector in EPICS V4 • Existing plugins and drivers should continue to work as now, with minimal API changes. • If a new API is designed, an adaptor class to maintain compatibility with existing drivers. • Support for EPICS v4 so that plugins can receive NDArrays from local application or other hosts seamlessly • Or maybe just using ZeroMQ instead of pvAccess?

13. Possible changes to NDArray • More accurate programmatic description of memory layout (color mode like ymc, rgb dimensions by plane or pixel etc) • Operators: • copy (shallow and deep) • const void pointer for read-only access • Copy-on-write • Public function to return a void pointer for read/write access. • How to spawn a copy of the NDArray object *and* data? • ROI and slicing available in class • Or maybe not - perhaps an external utility class (maybe friend) is better? Check literature... • Python numpy slicing style? • Support for stitching together multiple NDArrays into a single NDArray with N+n dimensions. • Producing a new copy of the NDArray. • Deep copy necessary here.

14. Possible changes to NDArray • NDAttributes to be extended to support more dimensions and datatypes.  • Perhaps an NDAttribute is really also an NDArray - or has an NDArray? • NDArray with smart-pointer built in for automatic reference counting. • Can it be done in a clever scope fashion, removing the need to use reserve/release? • Possibly use an external implementation; for instance boost. • A single, shared array pool per process rather than one per driver and plugin. • Easier to configure a single memory pool on one machine rather than multiple smaller pools. • When a chain of plugins are not used, they don't put a claim on a memory pool. • We have had problems when a detector is used in two different use-cases with different chains of plugins - when switching to use the second chain, the machine has run out of memory.

15. Flexible processing • Python(ic) bindings to allow writing plugins and drivers in python! One of the things that we envy from Lima! • Tom has developed "adPython" which is native python bindings (embedding python in C) to processing plugins. This is easy to use and fairly good performance due to the use of numpy (one additional copy on returning a new or filtered image result as an output). • Could be extended to support drivers in python? • Migrate into areaDetector base?  • Maybe only if areaDetector move to a more public repository - and then with some separation to avoid a hard dependency on python... • Some issues about python GIL when running multiple plugins - although numpy appears to release the GIL on intensive computation. • Could extend to support python 'multiprocess' i.e. multiple instances of python processes - at the cost of more memcopy or shared memory implementation. • OpenCV support • Probably still in a separate module as we dont want a hard dependency on these libs. An NDArray should translate into a Cv:Mat (matrix) object, preferably without copying. However, some CV functions do modify the source data - using a copy on write implementation which the NDArray must then support.

16. Other ideas • Using a more generic library than EPICS OSI for common stuff like threading, mutexes, containers, queues and shared pointers. • Proposing boost. All the tools and more. Downside: support on all platforms? (VxWorks, RTEMS?) • It would make it easier to use the areaDetector drivers and plugins in non-epics applications (for instance unit tests and Lima adaptors). • An easier API for using the drivers and plugins without running an IOC • For external unit-testing of a driver or plugin • Python bindings would be easier to make to allow creating an areaDetector application directly in a python script. Useful for bespoke BL applications where image acquisition need to be accompanied with other controls or live calculations. • Could possibly be designed as some form of adaptor pattern, catching the calls to setParam, setParam, NDArraycallbacks etc. • Would allow writing support in Lima for using areaDetector drivers without requiring an IOC.