Lima2 issueshttps://gitlab.esrf.fr/limagroup/lima2/-/issues2020-03-25T16:18:54+01:00https://gitlab.esrf.fr/limagroup/lima2/-/issues/2Shall we support a non distributed configuration (a la Lima1) ?2020-03-25T16:18:54+01:00Samuel DebionneShall we support a non distributed configuration (a la Lima1) ?This would be a different assembly of the Lima 2 building blocks.
- Lima2 centralized: one lib that does it all (a la Lima1)
- Lima2 distributed: one control lib, multiple acquisition executables, eventually additional processing executa...This would be a different assembly of the Lima 2 building blocks.
- Lima2 centralized: one lib that does it all (a la Lima1)
- Lima2 distributed: one control lib, multiple acquisition executables, eventually additional processing executables
@claustre @alejandro.homshttps://gitlab.esrf.fr/limagroup/lima2/-/issues/3Decoupling processing and acquisition: how shall we expose the state of forme...2023-02-17T11:01:22+01:00Samuel DebionneDecoupling processing and acquisition: how shall we expose the state of former pipeline tasks?Decoupling processing and acquisition means having multiple pipelines running (the one associated with the current acquisition and the ones associated with previous acquisitions that are still not fully processed).
For instance (pseudo ...Decoupling processing and acquisition means having multiple pipelines running (the one associated with the current acquisition and the ones associated with previous acquisitions that are still not fully processed).
For instance (pseudo code):
```
ct.get_pipeline().get_nb_saved_frames(); // By default get the current pipeline
ct.get_pipeline(acq_id).get_nb_saved_frames(); // Get a specific pipeline status
```
We could associated an ID to the acquisition and then retrieve the pipeline that process that acquisition to get status or retrieve results.
From the Tango DS perspective how should that look like? And from the Bliss perspective?
@claustre, @alejandro.homshttps://gitlab.esrf.fr/limagroup/lima2/-/issues/4Processing pipeline configuration: how shall we expose this feature to the user?2020-03-25T16:19:05+01:00Samuel DebionneProcessing pipeline configuration: how shall we expose this feature to the user?With a flexible pipeline, i.e. the graph of tasks can be specified at runtime, how shall we expose this feature to the user? From Tango? In a configuration file (static)? How often would that change? On acquisition basis, experience basi...With a flexible pipeline, i.e. the graph of tasks can be specified at runtime, how shall we expose this feature to the user? From Tango? In a configuration file (static)? How often would that change? On acquisition basis, experience basis or beamline basis?
Depending on the graph, we will have (dynamic) Tango devices to configure the individual tasks, does that sound feasible with Tango?
Remember that saving / streaming is "just another task" in LImA2.
@claustre @alejandro.homshttps://gitlab.esrf.fr/limagroup/lima2/-/issues/5Shall we merge Image and Video acquisition?2020-03-25T16:19:12+01:00Samuel DebionneShall we merge Image and Video acquisition?Since Boost.GIL supports much more image formats than the typical grayscale of Processlib and provides tools to write generic algorithm (code that works on different image type), should we merge image and video acquisition in LIMA2, e.g....Since Boost.GIL supports much more image formats than the typical grayscale of Processlib and provides tools to write generic algorithm (code that works on different image type), should we merge image and video acquisition in LIMA2, e.g. have the same API and pipeline (with color conversion when needed)?
@claustre @alejandro.homshttps://gitlab.esrf.fr/limagroup/lima2/-/issues/22I/Os2020-04-28T15:06:44+02:00Samuel DebionneI/OsI/Os are standard processes that can be inserted in the processing pipeline:
* [x] Saving to file (HDF5)
* [ ] Saving to buffer
* [ ] Streaming (MPI Streams, ZMQ)
* [ ] Object storage (Memcached)I/Os are standard processes that can be inserted in the processing pipeline:
* [x] Saving to file (HDF5)
* [ ] Saving to buffer
* [ ] Streaming (MPI Streams, ZMQ)
* [ ] Object storage (Memcached)v0.1.0Samuel DebionneSamuel Debionne2020-04-24https://gitlab.esrf.fr/limagroup/lima2/-/issues/29License and Copyright2020-05-06T08:41:24+02:00Laurent ClaustreLicense and CopyrightI propose to use a LGPLv3 license. The copyright is not intended to be held by staff members but ESRF (or BCU/ESRF), you can add a AUTHORS file if you want to be mentioned as developer. We could have a CONTRIBUTORS files as well.I propose to use a LGPLv3 license. The copyright is not intended to be held by staff members but ESRF (or BCU/ESRF), you can add a AUTHORS file if you want to be mentioned as developer. We could have a CONTRIBUTORS files as well.v0.1.02020-05-15https://gitlab.esrf.fr/limagroup/lima2/-/issues/50Legacy (lima1) Processing Pipeline2020-09-29T16:23:54+02:00Samuel DebionneLegacy (lima1) Processing PipelineA Lima1-like pipeline with the following processing:
```
-> ImageAcquired
| Intensity reconstruction->Free Hw Buffer
| Binning->Free Hw Buffer
| ROI
| Flip
| Rotation
| PartialAssemble->Free Hw Buffer
| Buffer(queue_node)
| Imag...A Lima1-like pipeline with the following processing:
```
-> ImageAcquired
| Intensity reconstruction->Free Hw Buffer
| Binning->Free Hw Buffer
| ROI
| Flip
| Rotation
| PartialAssemble->Free Hw Buffer
| Buffer(queue_node)
| Image Assemble(multifuncion_node)
->ImageAssembled
| Accumulation
: SaturationMask: Given an intensity threshold
->Image with Nb of saturations per pixel per Accumulated image
: SaturationCallback: Given a threshold on the nb of pixels
->Event when the number of saturated pixels is above the threshold
->BaseImageReady
| Background - Substraction
| Flatfield - Correction
| Mask
| User - Transformation
->ImageReady
+ Saving
->ImageSaved
+ VideoImage
+ RoiCounters
+ Roi2Spectrum
+ BeamCalculations
+ User - Calculation
->CountersReady
```
### TBB nodes
- [ ] Intensity correction node (low priority)
- [ ] Image assembly nodes: geometry (flip, rotation, roi), see #18
- [ ] Saving node, see #22
- [ ] Event node (e.g. ImageAcquired, ImageReady)v0.1.0Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/18Image Assembly2022-04-04T13:42:55+02:00Samuel DebionneImage AssemblyThe most generic approach to image assembly (reconstruction) is the definition by the HW plugin of a (set of) function(s) performing the task(s), to be called in dedicated processing node(s).
The system can then provide helpers that imp...The most generic approach to image assembly (reconstruction) is the definition by the HW plugin of a (set of) function(s) performing the task(s), to be called in dedicated processing node(s).
The system can then provide helpers that implement the function(s) based on:
* [ ] Detector Layout description in camera plugin
Low priority tasks:
* [ ] HW geometric transformation (i.e. flip, roi, bin)Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/15Python Binding2020-04-17T17:48:30+02:00Samuel DebionnePython BindingSIP has three major drawbacks:
- Requires a preprocessor (sip -> cpp) that complicates the build system
- Uses a python module at runtime that poses all gkind of compatibility issues
- Verbose SIP files with duplicated C++ code
* ...SIP has three major drawbacks:
- Requires a preprocessor (sip -> cpp) that complicates the build system
- Uses a python module at runtime that poses all gkind of compatibility issues
- Verbose SIP files with duplicated C++ code
* [x] Evaluate pybind11
* [ ] Provide a generic binding for every camerasv0.1.0Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/14Hardware Interface2020-04-17T17:21:25+02:00Samuel DebionneHardware InterfaceThe hardware interface should be split into control and acquisition interfaces.
* [ ] Survey on the SDKs for cameras that should be supported in distributed mode
* [ ] API for the control part of the Hardware Interface
* [ ] API for the...The hardware interface should be split into control and acquisition interfaces.
* [ ] Survey on the SDKs for cameras that should be supported in distributed mode
* [ ] API for the control part of the Hardware Interface
* [ ] API for the acquisition part of the Hardware InterfaceSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/8Shall we allow to modify the processing pipeline when the acquisition is paused?2020-03-25T16:19:47+01:00Samuel DebionneShall we allow to modify the processing pipeline when the acquisition is paused?Some sequences require to take 'black' images for reference or immediate Background Correction at a given interval. This is currently implemented in the control software by stoping the acquisition, preparing a new one (just changing the ...Some sequences require to take 'black' images for reference or immediate Background Correction at a given interval. This is currently implemented in the control software by stoping the acquisition, preparing a new one (just changing the file prefix), starting a one shot acquisition and restart the regular acquisition afterwards.
Since we have multiple pipelines in LIMA2, it should be possible to just pause the acquisition and change the processing pipeline. This breaks the concept of acquisition preparation in two set of parameters:
- immutable for hardware settings
- mutable for software processing (that includes saving)
To better picture what would be the consequences:
```c++
prepare_acquisition() // Only allowed when the camera is idle
pipeline_id_t prepare_processing() // Allowed when the acquisition is paused
```
@claustre @alejandro.homs @papillonhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/10Shall we support sparse storage for (very) sparse images?2019-03-27T10:30:56+01:00Samuel DebionneShall we support sparse storage for (very) sparse images?Some images might be better represented as (pixel, value) pairs rather than a dense matrix.
(Discussion with Armando).
@claustre @alejandro.homsSome images might be better represented as (pixel, value) pairs rather than a dense matrix.
(Discussion with Armando).
@claustre @alejandro.homshttps://gitlab.esrf.fr/limagroup/lima2/-/issues/25Documentation2020-04-17T17:56:47+02:00Samuel DebionneDocumentationThis is a transversale issue. Ideally, the documentation would be written before the development.
* [x] Setup Gitlab pages to generate Sphinx documentationThis is a transversale issue. Ideally, the documentation would be written before the development.
* [x] Setup Gitlab pages to generate Sphinx documentationSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/12With distributed acquisition, when does the reconstruction step should happen?2021-06-25T12:33:02+02:00Samuel DebionneWith distributed acquisition, when does the reconstruction step should happen?At saving time (more distributed dataflow) or at preprocessing time? What kind of flexibility do we need here?
Implementing distributed processing for some of the tasks should not be to difficult but still...At saving time (more distributed dataflow) or at preprocessing time? What kind of flexibility do we need here?
Implementing distributed processing for some of the tasks should not be to difficult but still...https://gitlab.esrf.fr/limagroup/lima2/-/issues/13Shall we support acquisition of multiple frames at a time?2019-03-27T11:10:18+01:00Samuel DebionneShall we support acquisition of multiple frames at a time?After discussing librashpa with @ponsard, it sounds like it would be a good idea to have an acquisition interface that support getting multiple frames at a time. This would be more in phase with the underlying hardware. Like `recvmmsg` f...After discussing librashpa with @ponsard, it sounds like it would be a good idea to have an acquisition interface that support getting multiple frames at a time. This would be more in phase with the underlying hardware. Like `recvmmsg` for sockets, [RoCE](https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet) offers better performance if multiple send are bundled (something like 4-5 images).
We can talk about frame block processing.https://gitlab.esrf.fr/limagroup/lima2/-/issues/16Testing2020-04-17T17:56:48+02:00Laurent ClaustreTestingThis should be implemented from the beginning.
* [x] Unit tests
* [x] Performance regression tests
* [x] Benchmarks framework
Using micro benchmarking tools like [Google Benchmark](https://github.com/google/benchmark).
For performa...This should be implemented from the beginning.
* [x] Unit tests
* [x] Performance regression tests
* [x] Benchmarks framework
Using micro benchmarking tools like [Google Benchmark](https://github.com/google/benchmark).
For performance tests, dedicated hardware is required.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/20Command Line Interfaces2020-04-17T17:56:51+02:00Samuel DebionneCommand Line InterfacesWhile Lima is mostly a library, it should come with minimal utilities (that would also serve as examples) to do simples experiments and tests:
* [x] Control CLI
* [x] Processing CLIWhile Lima is mostly a library, it should come with minimal utilities (that would also serve as examples) to do simples experiments and tests:
* [x] Control CLI
* [x] Processing CLISamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/31Automatic source code formatting2020-05-14T19:42:42+02:00Samuel DebionneAutomatic source code formatting* [x] Agree on formatting options (write `.clang-format` file) (#53)
* [x] Apply re-formatting to the code base (#52)
* [x] Add CI Pipeline stage to check formatting (#63)
* [x] Agree on formatting options (write `.clang-format` file) (#53)
* [x] Apply re-formatting to the code base (#52)
* [x] Add CI Pipeline stage to check formatting (#63)
v0.1.0Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/54PSI/Eiger Plugin2020-04-17T17:27:07+02:00Alejandro Homs PuronPSI/Eiger Pluginhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/19Camera Plugins2024-02-15T14:10:27+01:00Samuel DebionneCamera Plugins* [x] Simulator
* [ ] PSI Eiger
* [x] PSI JungFrau
* [x] Smartpix
* [x] Dectris Eiger* [x] Simulator
* [ ] PSI Eiger
* [x] PSI JungFrau
* [x] Smartpix
* [x] Dectris Eigerhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/167Add XPCS processing2023-07-24T10:58:46+02:00Samuel DebionneAdd XPCS processingXPCS processing would sparsify (remove 0 photon data) and save the data in the same sparse format than the one used for saving the peaks in the SMX processing. The format we use is basically 3 vectors:
```cpp
pixel_t pixel_value; // int...XPCS processing would sparsify (remove 0 photon data) and save the data in the same sparse format than the one used for saving the peaks in the SMX processing. The format we use is basically 3 vectors:
```cpp
pixel_t pixel_value; // intensity
int pixel_idx; // 1D index in the image
int frame_idx; // index of the beginning of the image in pixel_idx
```
An empty frame is just one entry in the `frame_idx` vector:
```
frame_idx = [0, 25, 36, 36, 54, 98... ]
^
frame #3 is an empty frame (same pixel index as the previous one)
```
**TODO**
- [ ] The `writer_sparse` needs to be refactored for this use case -the current implementation is too specific to SMX. The SMX specific part would be moved to the SMX processing.
- [ ] A sparsifier algorithm / node needs to be implemented. Implementations already exist in the benchmarks.
- [ ] A `sparse_frame`, similar to the one designed for SMX but without background, needs to be implemented. Refactoring needed.https://gitlab.esrf.fr/limagroup/lima2/-/issues/26Have configurable chunking of HDF5 file2021-06-18T15:06:56+02:00Samuel DebionneHave configurable chunking of HDF5 fileDepending on the use case and downstream data analysis, chunking must be configured in different ways to get good reading performance.Depending on the use case and downstream data analysis, chunking must be configured in different ways to get good reading performance.https://gitlab.esrf.fr/limagroup/lima2/-/issues/27Should binning promote the data type to higher bit depth?2019-04-09T15:32:26+02:00Samuel DebionneShould binning promote the data type to higher bit depth?https://gitlab.esrf.fr/limagroup/lima2/-/issues/32Static Code Analysis2020-01-08T16:32:27+01:00Samuel DebionneStatic Code AnalysisMany options available these days:
* [clang-tidy](http://clang.llvm.org/extra/clang-tidy/): is a clang-based C++ “linter” tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, lik...Many options available these days:
* [clang-tidy](http://clang.llvm.org/extra/clang-tidy/): is a clang-based C++ “linter” tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. clang-tidy is modular and provides a convenient interface for writing new checks.
* [iwyu](https://include-what-you-use.org/) (include what you use) : This parses C++ source files and determines the exact include files required to compile that file, no more no less.
* lwyu (link what you use): This is a built in CMake feature that uses options of ld and ldd to print out if executables link more libraries than they actually require.
* [cpplint](https://github.com/cpplint/cpplint): a C++ style checker following Google’s C++ style guide.
* [cppcheck](http://cppcheck.sourceforge.net/): a static analysis tool for C/C++ code. Cppcheck primarily detects the types of bugs that the compilers normally do not detect. The goal is to detect only real errors in the code (i.e. have zero false positives).
They are all pretty well integrated with CMake:
* `<LANG>_CLANG_TIDY` can be set with cache variable `CMAKE_<LANG>_CLANG_TIDY`
* `<LANG>_CPPCHECK` can be set with cache variable `CMAKE_<LANG>_CPPCHECK`
* `<LANG>_CPPLINT` can be set with cache variable `CMAKE_<LANG>_CPPLINT`
* `<LANG>_INCLUDE_WHAT_YOU_USE` can be set with cache variable `CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE`
* `LINK_WHAT_YOU_USE` can be set with cache variable `CMAKE_LINK_WHAT_YOU_USE`
## Clang Tidy
* [x] Agree on a `.clang-tidy` configuration
* [x] Add a CMake option to enable `clang-tidy` on demand
* [ ] Apply clang-tidy suggestions to the codebase when sensible
## Include-what-you-use
* [ ] Add a CMake option to enable `iwyu` on demand
* [ ] Apply iwyu suggestions to the codebase when sensibleSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/37Processing in Python2020-06-08T19:00:32+02:00Samuel DebionneProcessing in PythonEnable processing tasks to be written in python.
There are multiple options to consider:
- embed the python interpreter in the processing C++ executable
- write the processing in python (using `mpi4py` and/or Boost.MPI python binding)...Enable processing tasks to be written in python.
There are multiple options to consider:
- embed the python interpreter in the processing C++ executable
- write the processing in python (using `mpi4py` and/or Boost.MPI python binding)
* [ ] Check if Python interpreter can be called from multiple (TBB) threadsSamuel DebionneSamuel Debionne2020-06-15https://gitlab.esrf.fr/limagroup/lima2/-/issues/30SmartPix Camera Plugin2020-04-17T17:29:40+02:00Samuel DebionneSmartPix Camera Plugin* [x] Conda package for libsmpx
* [x] Implement `smpx` class, a the low level API to hide dance commands details (mapping command one-to-one)
* [x] Implement camera plugin with slow "controller image transfer"
* [ ] Implement camera ...* [x] Conda package for libsmpx
* [x] Implement `smpx` class, a the low level API to hide dance commands details (mapping command one-to-one)
* [x] Implement camera plugin with slow "controller image transfer"
* [ ] Implement camera plugin with fast RASHPA image transferSamuel DebionneSamuel Debionne2020-07-01https://gitlab.esrf.fr/limagroup/lima2/-/issues/35Distributed Logging2020-03-20T08:11:55+01:00Samuel DebionneDistributed Logging* [ ] Evaluate [EZTrace](http://eztrace.gforge.inria.fr/index.html) for generating traces
* [ ] Evaluate [ViTE](http://vite.gforge.inria.fr/) or [Vampir](http://vampir.eu/) (commercial) for vizualization* [ ] Evaluate [EZTrace](http://eztrace.gforge.inria.fr/index.html) for generating traces
* [ ] Evaluate [ViTE](http://vite.gforge.inria.fr/) or [Vampir](http://vampir.eu/) (commercial) for vizualizationhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/67REMU Camera Plugin for Rashpa integration2020-09-10T11:03:44+02:00Samuel DebionneREMU Camera Plugin for Rashpa integration- [ ] Build REMU on rnice, install it on MPX7
- [ ] Duplicate and adapt Smartpix plugin- [ ] Build REMU on rnice, install it on MPX7
- [ ] Duplicate and adapt Smartpix pluginSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/17Resource Management2020-04-17T15:41:06+02:00Samuel DebionneResource Management* [ ] Memory Management
* [ ] Centralized Memory Management* [ ] Memory Management
* [ ] Centralized Memory Managementhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/49Multi Channel Acquisition2020-04-17T16:14:40+02:00Samuel DebionneMulti Channel AcquisitionRASHPA allows to define multiple data channels, using concurrent Data Transfer Processes (DTP) in RASHPA jargon, so that one detector is a multiple independent image sources for Lima.
> **Data channels** are the functional blocks in the...RASHPA allows to define multiple data channels, using concurrent Data Transfer Processes (DTP) in RASHPA jargon, so that one detector is a multiple independent image sources for Lima.
> **Data channels** are the functional blocks in the RASHPA controller that are in charge of data transfer from a particular detector module to the destination buffers. While DTPs are the way in which data transfer operations are defined at the system level and presented to the detector application and the users, data channels are the functional blocks that actually implement the DTPs from the detector modules.
Exemple of data channels are:
- a crop of the full image
- a band of an image (assuming a multiband detector)
- a transformed image (e.g. geometry, binning, down-sampling)
One approach would be to consider each channel as a camera but the configuration of RASHPA (the buffers and the data channels) would need to be shared between the cameras.2021-01-30https://gitlab.esrf.fr/limagroup/lima2/-/issues/28HW Buffer management2020-04-23T08:58:06+02:00Samuel DebionneHW Buffer managementDifferent buffer management needs for hardware and processing.
Hardware management:
- availability (pre-allocation)
- pinned, numa, alignement
Possible implementations:
* [ ] Benchmark [Boost.Pool](https://www.boost.org/doc/libs/r...Different buffer management needs for hardware and processing.
Hardware management:
- availability (pre-allocation)
- pinned, numa, alignement
Possible implementations:
* [ ] Benchmark [Boost.Pool](https://www.boost.org/doc/libs/release/libs/pool/) and [Boost.LockFree](https://www.boost.org/doc/libs/release/libs/lockfree/) queue.
* [ ] Evaluate [Boost.Align](https://www.boost.org/doc/libs/release/libs/align/)Alejandro Homs PuronAlejandro Homs Puron2020-05-11https://gitlab.esrf.fr/limagroup/lima2/-/issues/38Processing Plugins2020-01-30T09:55:26+01:00Samuel DebionneProcessing PluginsIn Lima1, processing tasks and savings are tightly coupled with Lima.Core. For instance, modifying the HDF5 format requires to recompile Lima.Core and possibly all the plugins that depends on it.
We could define a processing interface a...In Lima1, processing tasks and savings are tightly coupled with Lima.Core. For instance, modifying the HDF5 format requires to recompile Lima.Core and possibly all the plugins that depends on it.
We could define a processing interface and use the [Boost.DLL](https://www.boost.org/doc/libs/1_72_0/doc/html/boost_dll.html) machinery that was designed "to simplify plugin development using C++ in a portable cross-platform manner" to extend the list of available processing tasks at runtime.https://gitlab.esrf.fr/limagroup/lima2/-/issues/39Processing in OpenCL2020-03-20T08:09:19+01:00Samuel DebionneProcessing in OpenCLFor the records, these are interesting introduction to mixing CPU and GPU processing with TBB:
https://software.intel.com/en-us/videos/use-c-and-intel-threading-building-blocks-intel-tbb-for-hardware-programming
https://software.intel....For the records, these are interesting introduction to mixing CPU and GPU processing with TBB:
https://software.intel.com/en-us/videos/use-c-and-intel-threading-building-blocks-intel-tbb-for-hardware-programming
https://software.intel.com/en-us/blogs/2015/12/09/opencl-node-overview
Might be a better option than the Python route.https://gitlab.esrf.fr/limagroup/lima2/-/issues/40Fault Tolerance2020-02-27T16:35:35+01:00Samuel DebionneFault ToleranceThe phrase "fault tolerance" means many things to many people. Here we define "fault tolerance" to mean the ability to recover from one or more component software failures (e.g. crashes).
In an MPI application, the predefined default er...The phrase "fault tolerance" means many things to many people. Here we define "fault tolerance" to mean the ability to recover from one or more component software failures (e.g. crashes).
In an MPI application, the predefined default error handler, which is called `MPI_ERRORS_ARE_FATAL`, for a newly created communicator or for `MPI_COMM_WORLD` is to abort the whole parallel program as soon as any MPI error is detected.
There is another predefined error handler, which is called `MPI_ERRORS_RETURN` that allows manual handling of errors.
In MPICH, there is a flag called -disable-auto-cleanup which will prevent the process manager from automatically cleaning up all processes when a single process fails.
More info can be found at the [Fault Tolerance Research Hub](https://fault-tolerance.org/).https://gitlab.esrf.fr/limagroup/lima2/-/issues/41Python Binding Tests2020-03-17T17:37:34+01:00Samuel DebionnePython Binding TestsAdd binding tests to the unit test suit.
* [ ] Move functions that are "just for testing" in a `Test` class
* [ ] Use pytest for a proper unit testing
* [ ] Run pytest suits from CMakeAdd binding tests to the unit test suit.
* [ ] Move functions that are "just for testing" in a `Test` class
* [ ] Use pytest for a proper unit testing
* [ ] Run pytest suits from CMakehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/43Add logging command line options2020-04-20T16:41:54+02:00Samuel DebionneAdd logging command line optionsAdd command line options such as
* `--log-level`
* `--log-channel`
to the control CLI.
Broadcast the log options to the client processes (acquisition, processing).Add command line options such as
* `--log-level`
* `--log-channel`
to the control CLI.
Broadcast the log options to the client processes (acquisition, processing).v0.1.0https://gitlab.esrf.fr/limagroup/lima2/-/issues/44Add logging to the FSM2020-03-20T08:25:15+01:00Samuel DebionneAdd logging to the FSMUse the Lima logging facility in the Finite State Machine.Use the Lima logging facility in the Finite State Machine.https://gitlab.esrf.fr/limagroup/lima2/-/issues/46Add TBB mpi_send_node / mpi_recv_node2020-03-20T15:31:09+01:00Samuel DebionneAdd TBB mpi_send_node / mpi_recv_nodeA flexible way to design a distributed processing would be to a have a pair `mpi_send_node` / `mpi_recv_node` TBB nodes. The [Pro TBB book as chapter](https://link.springer.com/chapter/10.1007/978-1-4842-4398-5_18) that covers a similar ...A flexible way to design a distributed processing would be to a have a pair `mpi_send_node` / `mpi_recv_node` TBB nodes. The [Pro TBB book as chapter](https://link.springer.com/chapter/10.1007/978-1-4842-4398-5_18) that covers a similar concept.
This would be much better than sending the data straight from the acquisition process to the processing process.https://gitlab.esrf.fr/limagroup/lima2/-/issues/48Multiband Images2020-03-25T15:30:27+01:00Samuel DebionneMultiband ImagesSmartPix (and probably other detectors) has multiple counters for different energy thresholdand can thus generate multiband images.SmartPix (and probably other detectors) has multiple counters for different energy thresholdand can thus generate multiband images.https://gitlab.esrf.fr/limagroup/lima2/-/issues/47Add Processing Management Operations2020-03-25T18:20:38+01:00Samuel DebionneAdd Processing Management OperationsWith multiple concurrent pipeline, running for different acquisitions, we need a way to manage (status, abort) the pipeline.With multiple concurrent pipeline, running for different acquisitions, we need a way to manage (status, abort) the pipeline.https://gitlab.esrf.fr/limagroup/lima2/-/issues/51Test Coverage Tool2020-04-17T12:41:42+02:00Samuel DebionneTest Coverage ToolConfigure a test coverage tool sucha as [codecov.io](https://codecov.io/).Configure a test coverage tool sucha as [codecov.io](https://codecov.io/).https://gitlab.esrf.fr/limagroup/lima2/-/issues/55Refactor RPC Client to mutualise Event Loop2020-09-15T11:00:52+02:00Samuel DebionneRefactor RPC Client to mutualise Event LoopToday we have one event loop per client. Since many clients can be instantiated in one process (thus spawning many threads), it would be better to mutualise the event loop -at least for the same client types.
```
rpc::event_loop<...> ev...Today we have one event loop per client. Since many clients can be instantiated in one process (thus spawning many threads), it would be better to mutualise the event loop -at least for the same client types.
```
rpc::event_loop<...> event_loop;
rpc::client<...> client(event_loop);
```v0.1.0https://gitlab.esrf.fr/limagroup/lima2/-/issues/56Refactor Control with additional Pipeline and Topology concepts2020-04-20T09:00:59+02:00Samuel DebionneRefactor Control with additional Pipeline and Topology conceptsThe Control API is specialized with the Camera. We need more template parameters for the Processing part and the Topology of the applications (unless we manage to do something generic for the topology).The Control API is specialized with the Camera. We need more template parameters for the Processing part and the Topology of the applications (unless we manage to do something generic for the topology).v0.1.0https://gitlab.esrf.fr/limagroup/lima2/-/issues/57Application Topology Concept2020-04-20T09:17:42+02:00Samuel DebionneApplication Topology ConceptDescribe the application Topology in terms of processes and implement the inter-process Coordination.Describe the application Topology in terms of processes and implement the inter-process Coordination.v0.1.0https://gitlab.esrf.fr/limagroup/lima2/-/issues/58Design and Implement the Processing part of the Control API2020-04-20T10:07:46+02:00Samuel DebionneDesign and Implement the Processing part of the Control APIA large part of the processing is missing in the Control API, things like:
```c++
/// Returns a receiver for frame notifications
receiver<any_state_t> register_frame_xxx_change();
```
```c++
/// Returns a copy of the pipeline state (e....A large part of the processing is missing in the Control API, things like:
```c++
/// Returns a receiver for frame notifications
receiver<any_state_t> register_frame_xxx_change();
```
```c++
/// Returns a copy of the pipeline state (e.g. node states, such as ROI counters)
/* unspecified */ pipeline_state();
```v0.1.0https://gitlab.esrf.fr/limagroup/lima2/-/issues/61Define Metadata2022-04-05T18:48:42+02:00Samuel DebionneDefine MetadataMetadata are attached to a frame. They describe the frame or the context of the acquisition in general and can be used by processing nodes.
In Lima1 we have:
- static (camera model, S/N...)
- common (acquisition params, processing par...Metadata are attached to a frame. They describe the frame or the context of the acquisition in general and can be used by processing nodes.
In Lima1 we have:
- static (camera model, S/N...)
- common (acquisition params, processing params)
- image (image attributes)
There are two different ways to store metadata :
`attributes`: a string key-value store
`metadata`: a typed structure
The typed structure can have nested structures:
```c++
struct metadata
{
camera cam; // Camera info
acquisition acq; // Acquisition info
...
};
```
Metadata should implement (compile time) reflection so that saving could be implemented in a generic way.
Frames are specialized with Metadata than can be specific to a camera / processing pipeline.v0.1.0https://gitlab.esrf.fr/limagroup/lima2/-/issues/66Add Detector Configuration Utility2020-09-10T18:31:42+02:00Samuel DebionneAdd Detector Configuration UtilitySome detectors requires to run configuration script (e.g. send a sequence of commands) to the detector during the initialization phase of Lima (e.g. when starting the Device Server).
- [x] Add minizip conda package
- [ ] Adapt CMake bui...Some detectors requires to run configuration script (e.g. send a sequence of commands) to the detector during the initialization phase of Lima (e.g. when starting the Device Server).
- [x] Add minizip conda package
- [ ] Adapt CMake build system
- [ ] Write a (mini) zip utility lib to ease the iteration over the archive and decompression of files to memory / file to be sent to the detectorSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/64Is there a way to prepare and lock pages without actually allocating memory?2020-05-12T10:15:32+02:00Samuel DebionneIs there a way to prepare and lock pages without actually allocating memory?When accessing a buffer allocated using `malloc/mmap` for the first time, there is a great chance to get a page fault which is critical in real-time application. So far the only solution considered was to allocate and page lock the buffe...When accessing a buffer allocated using `malloc/mmap` for the first time, there is a great chance to get a page fault which is critical in real-time application. So far the only solution considered was to allocate and page lock the buffers in advance (e.g. during preparation). This also means that the application has to manage a buffer pool.
Is there any chance that another mechanism exists to tell the kernel to prepare some pages for our process, in a way that subsequent calls to `malloc/mmap` will be fast?
The answer might be just NO...Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/65I/Os memcached_node2020-06-10T18:50:33+02:00Samuel DebionneI/Os memcached_nodeAdd a `memcached_node` to publish the data on a memcached server. The data will be later consumed by DAU online processing.
Possible client libraries in C / C++ are:
* https://libmemcached.org/libMemcached.html (Unmaintained)
* https:/...Add a `memcached_node` to publish the data on a memcached server. The data will be later consumed by DAU online processing.
Possible client libraries in C / C++ are:
* https://libmemcached.org/libMemcached.html (Unmaintained)
* https://github.com/cybozu/libyrmcds (Minimalistic)https://gitlab.esrf.fr/limagroup/lima2/-/issues/70Update the Processing documentation2020-09-21T09:08:26+02:00Samuel DebionneUpdate the Processing documentationThe documentation is slightly outdated (still mention STLab.Concurrency,etc.) and incomplete.The documentation is slightly outdated (still mention STLab.Concurrency,etc.) and incomplete.https://gitlab.esrf.fr/limagroup/lima2/-/issues/72Geometry Transformation node2020-09-29T16:23:54+02:00Samuel DebionneGeometry Transformation nodeRelated to #50
Add a `roi_flip_rot_node`Related to #50
Add a `roi_flip_rot_node`Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/75Integrate docs generation to CMake2021-05-27T09:10:09+02:00Samuel DebionneIntegrate docs generation to CMakeFollowing this excellent tutorial [Clear, Functional C++ Documentation with Sphinx + Breathe + Doxygen + CMake](https://devblogs.microsoft.com/cppblog/clear-functional-c-documentation-with-sphinx-breathe-doxygen-cmake) we could integrate...Following this excellent tutorial [Clear, Functional C++ Documentation with Sphinx + Breathe + Doxygen + CMake](https://devblogs.microsoft.com/cppblog/clear-functional-c-documentation-with-sphinx-breathe-doxygen-cmake) we could integrate the documentation generation to the build system instead of have a serapate Make based build system.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/76Revert sphinxcontrib.mermaid workaround2021-05-27T12:18:17+02:00Samuel DebionneRevert sphinxcontrib.mermaid workaroundOnce [#71](https://github.com/mgaitan/sphinxcontrib-mermaid/pull/71) is merged.Once [#71](https://github.com/mgaitan/sphinxcontrib-mermaid/pull/71) is merged.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/77Improve parameter validation2021-12-21T10:45:21+01:00Samuel DebionneImprove parameter validationThe "parameter validation protocol" is based on parameters providing a `[[nodiscard]] bool validate() const` function, where all the parameters of the tree are visited in turn.
Unfortunately, for a deep parameter tree (vs flat parameter...The "parameter validation protocol" is based on parameters providing a `[[nodiscard]] bool validate() const` function, where all the parameters of the tree are visited in turn.
Unfortunately, for a deep parameter tree (vs flat parameter structure), it's not possible to report which parameter is actually incorrect. The current workaround is to throw from the `validate()` function. With this workaround, we are reporting an invalid parameter one at a time while we could report all the parameters that are invalids in one pass.
I suggest to switch to something like:
```cpp
struct invalid_param {
std::string name; //<! Name of the parameters including the tree (aka "processing.saving.base_path")
std::string message; //<! Explain what is wrong with the parameter
std::string suggested_value; //<! Eventually a suggested value that is in the validity range?
};
// Validate function (annoted to the data member)
template <typename T, typename OutputIterator>
void validate(T const& val, OutputIterator invalid) const
{
if (val < 0)
*invalid++ = invalid_param {"negative value not supported", "1"};
}
```Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/78Add Acquisition Group concept2021-07-15T18:50:27+02:00Samuel DebionneAdd Acquisition Group conceptFrom the Bliss point of view, one big improvement that Lima2 could offer would be to introduce the concept of "acquisition group" -the term is mine.
The idea is that consecutive acquisition in a group would be seen as one single acquisi...From the Bliss point of view, one big improvement that Lima2 could offer would be to introduce the concept of "acquisition group" -the term is mine.
The idea is that consecutive acquisition in a group would be seen as one single acquisition in terms of frame numbering and file saving (concatenation) for instance.
Assuming we add a `acq_group_id` to the acquisition parameters, for consecutive acquisitions that share the same `acq_group_id`, Lima would consider that it is a continuing acquisition and that it shares the same processing instance with the first one in the group. There might be better ways to introduce the same concept.
@matias.guijarro Did I put it right? @alejandro.homs What do you think?https://gitlab.esrf.fr/limagroup/lima2/-/issues/79Data access and Vizualisation2022-03-08T13:45:15+01:00Samuel DebionneData access and Vizualisation# Data access
Here is the overall high level interface of Lima2. Client such as Flint control the acquisition and access the data using the Client API that manages the distributed nature of data receivers. The Client API knows where to ...# Data access
Here is the overall high level interface of Lima2. Client such as Flint control the acquisition and access the data using the Client API that manages the distributed nature of data receivers. The Client API knows where to get the data for a given frame.
```mermaid
flowchart BT
flint(FLINT)
api(Client API) --- flint
cds(Control DS) --- api
rds1(Receiver DS #1) --- api
rdsn(Receiver DS #n) --- api
```
Data in the processing graph are made available using a *circular buffer node* that can be inserted anywhere in the processing graph:
```mermaid
flowchart LR
src(Source) --> proc1(OpenCL - Energy Reconstruction + pyFAI) --> buf1{{Circular buffer for sparse data}}
src --> proc2(CPU - Image reconstruction) --> buf2{{Circular buffer for dense data}} --> proc3(ROI counters) --> buf3{{Circular buffer for ROI counters}}
```
The receiver API gives read access to the cyclic buffer -which size is configurable. A Tango DS is used to serve this data.
## Tango
Reusing the same `DevEncoded` for images called `DATA_ARRAY`:
```python
# The DATA_ARRAY definition
#struct {
#unsigned int Magic= 0x44544159;
#unsigned short Version;
#unsigned short HeaderLength;
#DataArrayCategory Category;
#DataArrayType DataType;
#unsigned short DataEndianness;
#unsigned short NbDim;
#unsigned short Dim[8]
#unsigned int DimStep[8]
#} DataArrayHeaderStruct;
# With
DataArrayVersion = 3
DataArrayPackStr = '<IHHIIHHHHHHHHIIIIIIII'
DataArrayMagic = struct.unpack('>I', b'DTAY')[0] # 0x44544159
DataArrayHeaderLen = 64
DataArrayMaxNbDim = 6
```
### DATA_ARRAY v3.0
New catergories for sparse images are introduced:
| Category | NbDim |
|----------|-------|
| ScalarStack | 1 |
| Spectrum| 1 |
| Image| 2 |
| SparseImage | 3 |
| SpectrumStack| 2 |
| ImageStack | 3 |
| SparseImageStack | 4 |
For `SparseImageStack `, the dimensions are:
```
dims[0] = nb pixels
dims[1] = width
dims[2] = height
dims[3] = nb images (for stacks)
```
The data block (or bytes) is the concatenation of
| Category | Type | Size |
|----------|------|------|
| Pixel value | ImageType2DataArrayType | nb pixels |
| Padding to 32 bits |
| Pixel index | Int32| nb pixels |
| Frame index | Int32 | nb frames |
# Vizualisation
## GUI - Flint
### Live display of BLISS scans
Flint listens to scan data source to know if there’s something to display.
Poll the image counter of Lima. Call `read_image` according to the refresh rate.
### Users data plotting
New user plotting are introduced:
* Image plot of the reduced data (without background). The Lima Client API would do the densification.
* Time curve plot with the number of peaks over time.
### Specific options
Display images with a number of peaks higher than a given threshold.
## GUI - Web beam viewer
Lima web server used to display camera image with beam position (bpm) statistics built on top of the Tango DS.https://gitlab.esrf.fr/limagroup/lima2/-/issues/89Add Distributed pipeline example2021-12-22T13:16:52+01:00Samuel DebionneAdd Distributed pipeline exampleLike we have a Lima1 pipeline based on TBB, we should provide a Distributed pipeline based on MPI.
- [ ] On the receiver side, the processing thread `MPI_Send` the data to the processing nodes, in a round robin
- [ ] On the processing...Like we have a Lima1 pipeline based on TBB, we should provide a Distributed pipeline based on MPI.
- [ ] On the receiver side, the processing thread `MPI_Send` the data to the processing nodes, in a round robin
- [ ] On the processing sides, a thread `MPI_Receive` the data queue them in a buffer for further processing
- [ ] A new Tango DS is needed for the configuration of the processing nodeshttps://gitlab.esrf.fr/limagroup/lima2/-/issues/93Add Round-Robin support in the Client library2022-09-14T09:56:36+02:00Samuel DebionneAdd Round-Robin support in the Client libraryMultiple receivers are supported but do not collaborate well yet in Round-Robin topologies.
- [ ] make the `Processing` topology aware
- [ ] implement `getFrame()`, get the frame from the proper receiver
- [ ] implement `popRoiCounters(...Multiple receivers are supported but do not collaborate well yet in Round-Robin topologies.
- [ ] make the `Processing` topology aware
- [ ] implement `getFrame()`, get the frame from the proper receiver
- [ ] implement `popRoiCounters()`, join ROI counters from all receiversAlejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/97Lima2 API Serialization2022-01-21T15:43:57+01:00Samuel DebionneLima2 API SerializationWith a Tango DS serialization model set to `NO_SYNC` we need to make sure that the API calls are properly serialized at our level. Probably that a mutex in the `control`, `receiver` generic implementations would be enough.
```cpp
class ...With a Tango DS serialization model set to `NO_SYNC` we need to make sure that the API calls are properly serialized at our level. Probably that a mutex in the `control`, `receiver` generic implementations would be enough.
```cpp
class receiver
{
public:
/// Prepare acquisition (e.g. allocate buffers)
auto prepare_acq(acq_params_t const& acq_params)
{
const std::lock_guard<std::mutex> lck(m_api_mutex);
...
}
private:
std::mutex m_api_mutex; //<! Serialize API calls
```Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/98Chaining Processing2022-01-31T09:44:59+01:00Samuel DebionneChaining ProcessingProcessing are reusable TBB graph / Cuda / OpenCL, you name it, pipelines. Processings provide the `void on_frame_ready(data_t const&)` callback.
It would be interesting to be able to chain several processings, e.g. chain a reconstructi...Processing are reusable TBB graph / Cuda / OpenCL, you name it, pipelines. Processings provide the `void on_frame_ready(data_t const&)` callback.
It would be interesting to be able to chain several processings, e.g. chain a reconstruction processing with a Lima1 processing.https://gitlab.esrf.fr/limagroup/lima2/-/issues/100Split public and private headers2022-01-24T14:59:13+01:00Samuel DebionneSplit public and private headersIt's difficult to identify which headers (of Lima.Core) are required to use a detector or pipeline library. The `pImpl` idiom is used to minimize dependencies but some headers are leaking...
For instance, the legacy pipeline exposes `ro...It's difficult to identify which headers (of Lima.Core) are required to use a detector or pipeline library. The `pImpl` idiom is used to minimize dependencies but some headers are leaking...
For instance, the legacy pipeline exposes `roi_counters_result` in it's API. Including `nodes/roi_counters.hpp` would work but would expose way too much implementation details.
This distinction is necessary to have a clean install.https://gitlab.esrf.fr/limagroup/lima2/-/issues/104Support Multiple Clients2022-03-14T18:30:23+01:00Samuel DebionneSupport Multiple ClientsMultiple clients should be able to communicate with the detector, for instance:
- A viewer client could attach to the current processing to get frames to display;
- A (Nexus) writer could get on_end_acq notifications to generate aggre...Multiple clients should be able to communicate with the detector, for instance:
- A viewer client could attach to the current processing to get frames to display;
- A (Nexus) writer could get on_end_acq notifications to generate aggregated HDF5 files using VDS.
A mechanism (e.g. distributed mutex) could be used to appoint one of the client as master (while the others are read-only).https://gitlab.esrf.fr/limagroup/lima2/-/issues/108Plugin SDK dependency should be private2022-04-04T15:28:02+02:00Samuel DebionnePlugin SDK dependency should be privateOtherwise it defeats the purpose of the pimpl idiom.
```diff
diff --git a/detectors/psi/src/CMakeLists.txt b/detectors/psi/src/CMakeLists.txt
index a89ca0da..b2a0be92 100644
--- a/detectors/psi/src/CMakeLists.txt
+++ b/detectors/psi/src...Otherwise it defeats the purpose of the pimpl idiom.
```diff
diff --git a/detectors/psi/src/CMakeLists.txt b/detectors/psi/src/CMakeLists.txt
index a89ca0da..b2a0be92 100644
--- a/detectors/psi/src/CMakeLists.txt
+++ b/detectors/psi/src/CMakeLists.txt
@@ -37,7 +37,7 @@ target_include_directories(psi_hw
target_link_libraries(psi_hw
PUBLIC lima_core
- PUBLIC slsDetectorShared slsReceiverShared
+ PRIVATE slsDetectorShared slsReceiverShared
)
```
The SDK is used in the `utils.hpp` file included in processing to perform the reconstruction.Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/115Pass hw::info to Processing2022-02-18T10:07:49+01:00Samuel DebionnePass hw::info to ProcessingMost detector information are missing to populate the metadata of the Nexus files. The necessary information are available on the control side and should be broadcasted to the receivers.Most detector information are missing to populate the metadata of the Nexus files. The necessary information are available on the control side and should be broadcasted to the receivers.https://gitlab.esrf.fr/limagroup/lima2/-/issues/116Update documentation2022-03-01T14:22:39+01:00Samuel DebionneUpdate documentationThe documentation is slightly outdated:
- [ ] Client Library documentation
- [ ] Servers documentation
- [ ] Design documentationThe documentation is slightly outdated:
- [ ] Client Library documentation
- [ ] Servers documentation
- [ ] Design documentationSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/120DevEncoded container for multiple Data and Metadata2022-03-15T10:58:21+01:00Samuel DebionneDevEncoded container for multiple Data and MetadataThe idea is to have a single DevEncoded with multiple blocks of data (data array, sparse frame...) that need to be transferred "atomically". Metadata should be optional.
This DevEncoded definition would be shared with Lima.
One option ...The idea is to have a single DevEncoded with multiple blocks of data (data array, sparse frame...) that need to be transferred "atomically". Metadata should be optional.
This DevEncoded definition would be shared with Lima.
One option would be to use [CBOR](https://cbor.io/) or a similar serialization layer.
- [ ] DevEncoded design
- [ ] C/C++ encoding library
- [ ] Python decoding libraryhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/121Expose all the Rashpa GDT parameters2022-03-15T11:08:02+01:00Samuel DebionneExpose all the Rashpa GDT parametersThe following discussion from !119 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima2/-/merge_requests/119#note_172786): (+1 comment)
> I guess we need to expose all the parameters (...The following discussion from !119 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima2/-/merge_requests/119#note_172786): (+1 comment)
> I guess we need to expose all the parameters (not just footer)https://gitlab.esrf.fr/limagroup/lima2/-/issues/123Formalize acq_info to processing with image assembly information2022-04-04T13:52:21+02:00Alejandro Homs PuronFormalize acq_info to processing with image assembly informationFirst step in formalization towards a flexible and uniform image assembly (reconstruction) implementation, as mentioned in #18First step in formalization towards a flexible and uniform image assembly (reconstruction) implementation, as mentioned in #18https://gitlab.esrf.fr/limagroup/lima2/-/issues/124Processing source node spin-lock on the FIFO output consumes CPU cycles on lo...2022-04-06T15:00:25+02:00Alejandro Homs PuronProcessing source node spin-lock on the FIFO output consumes CPU cycles on low frame-rate regimesIn low frame-rate regimes, one CPU thread is completely consumed by reading the processing FIFO. Such approach is not (very) OS-friendly.
The `boost::lockfree::spsc_queue` requires `memory_fence`s on both the producer and the consumer. ...In low frame-rate regimes, one CPU thread is completely consumed by reading the processing FIFO. Such approach is not (very) OS-friendly.
The `boost::lockfree::spsc_queue` requires `memory_fence`s on both the producer and the consumer. A more OS-friendly implementation could introduce a `std::mutex + std::condition_variable` pair on top of the `lockfree::spsc_queue`, which are systematically used by the producer while the consumer only uses it when `pop` fails. Such solution ensures a deterministic latency in both operations while not over-consuming CPU cycles in low-speed regimes.
Another possibility is to use [Intell OneTBB `concurrent_bounded_queue`](https://oneapi-src.github.io/oneTBB/main/tbb_userguide/Concurrent_Queue_Classes.html). It seems to have a multi-producer/multi-receiver approach, with the corresponding additional complexity.https://gitlab.esrf.fr/limagroup/lima2/-/issues/125Implement Trigger Modes2022-07-18T17:10:35+02:00Samuel DebionneImplement Trigger Modes- [ ] Software
- [ ] External
- [ ] Gate (exposition given by the pulse)
With an additional parameter `nb_frames_per_trigger`.
- `Software && nb_frames_per_trigger == nb_frames` is equivalent to "Internal trigger"
- `Software && nb_fra...- [ ] Software
- [ ] External
- [ ] Gate (exposition given by the pulse)
With an additional parameter `nb_frames_per_trigger`.
- `Software && nb_frames_per_trigger == nb_frames` is equivalent to "Internal trigger"
- `Software && nb_frames_per_trigger == 1` is equivalent to "Internal trigger multi"
- `External && nb_frames_per_trigger == nb_frames` is equivalent to "External trigger"
- `External && nb_frames_per_trigger == 1` is equivalent to "External trigger multi"
More combinations are possible with this configuration.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/128Add support for Receiver instances with different Processing Pipelines2022-06-15T09:53:41+02:00Samuel DebionneAdd support for Receiver instances with different Processing PipelinesReceivers in the LIma application might have different responsibilities and different processing pipeline, e.g.
- One receiver running the regular pipeline for data saving
- One receiver running a fast feedback pipeline to control the a...Receivers in the LIma application might have different responsibilities and different processing pipeline, e.g.
- One receiver running the regular pipeline for data saving
- One receiver running a fast feedback pipeline to control the acquisition
We need several set of processing parameters for each receivers. The client is responsible of sending the parameters (knows about the topology).https://gitlab.esrf.fr/limagroup/lima2/-/issues/130Add gain control2022-06-07T09:00:58+02:00Alejandro Homs PuronAdd gain controlFixed-gain control is needed in order to measure the Jungfrau pedestal mapsFixed-gain control is needed in order to measure the Jungfrau pedestal mapsAlejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/131Follow-up from "Resolve: Compute Accumulation for Vizualisation in SMX pipeline"2022-06-07T11:51:27+02:00Alejandro Homs PuronFollow-up from "Resolve: Compute Accumulation for Vizualisation in SMX pipeline"The following discussion from !132 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima2/-/merge_requests/132#note_189052): (+1 comment below )
> AFAIU there are two different concepts:...The following discussion from !132 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima2/-/merge_requests/132#note_189052): (+1 comment below )
> AFAIU there are two different concepts:
>
> - `nb_acc_frames_reset` : the number of frames when the accumulators are reset to 0
> - `nb_acc_frames_xfer` : the number of frames when the accumulators are transferred to host (something like once per second, aka 1000 at 1KHz)
>
> In theory `nb_acc_frames_reset >>> nb_acc_frames_xfer`...
Comment by @alejandro.homs:
> I like the idea!
>
> Other variants:
>
> * `acc_nb_frames_before_reset` & `acc_nb_frames_before_xfer`
> * `nb_acc_frames_before_reset` & `nb_acc_frames_before_update`https://gitlab.esrf.fr/limagroup/lima2/-/issues/132Use HDF5 internal reference counting2022-06-08T16:12:09+02:00Samuel DebionneUse HDF5 internal reference countingIt turns out that the `H5I` part of the library provides access to the internal counters of the H5 handles. This should simplify our HDF5 wrapper and probably solve [the issue reported on the HDFGroup forum](https://forum.hdfgroup.org/t/...It turns out that the `H5I` part of the library provides access to the internal counters of the H5 handles. This should simplify our HDF5 wrapper and probably solve [the issue reported on the HDFGroup forum](https://forum.hdfgroup.org/t/hdf5-infinite-loop-closing-library-v1-10-6/8468).Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/134Update pyFAI kernels2022-06-09T21:42:04+02:00Samuel DebionneUpdate pyFAI kernelsIn the SMX pipeline, the pyFAI kernels need to be updated from the latest version (recently merged):
- azimuthal model for sigma-clipping
- poissonian model for peak finding
@jerome.kieffer warns that it might take 10% more GPU resour...In the SMX pipeline, the pyFAI kernels need to be updated from the latest version (recently merged):
- azimuthal model for sigma-clipping
- poissonian model for peak finding
@jerome.kieffer warns that it might take 10% more GPU resources.https://gitlab.esrf.fr/limagroup/lima2/-/issues/135OpenCL out-of-resources error in SMX pipeline2022-06-13T10:53:45+02:00Alejandro Homs PuronOpenCL out-of-resources error in SMX pipelineAfter running several acquisitions with the SMX pipeline, an *Out of resources* `OpenCL` error is thrown during `prepare`, as shown in the following log:
[lima2_jungfrau_smx_out_of_resources_bliss.log](/uploads/fd0b3ba53209ee6d1050f1936...After running several acquisitions with the SMX pipeline, an *Out of resources* `OpenCL` error is thrown during `prepare`, as shown in the following log:
[lima2_jungfrau_smx_out_of_resources_bliss.log](/uploads/fd0b3ba53209ee6d1050f193645832e9/lima2_jungfrau_smx_out_of_resources_bliss.log)https://gitlab.esrf.fr/limagroup/lima2/-/issues/136Add pedestal accumulation with OpenCL2022-06-13T18:32:15+02:00Alejandro Homs PuronAdd pedestal accumulation with OpenCLReading the dense output files during pedestal acquisition can be a lengthy operation if the number of frames to average is large. A more efficient approach would calculate the accumulation in the GPU.Reading the dense output files during pedestal acquisition can be a lengthy operation if the number of frames to average is large. A more efficient approach would calculate the accumulation in the GPU.https://gitlab.esrf.fr/limagroup/lima2/-/issues/137Add support for Receiver with multiple Processing Pipelines2022-07-05T14:26:13+02:00Samuel DebionneAdd support for Receiver with multiple Processing PipelinesA receiver would have a variant of pipelines that can be selected at runtime.
```c++
std::variant<noop, smx, avg> pipeline; // Receiver can switch to any of these pipelines
```
A single acquisition can then be configured to switch proc...A receiver would have a variant of pipelines that can be selected at runtime.
```c++
std::variant<noop, smx, avg> pipeline; // Receiver can switch to any of these pipelines
```
A single acquisition can then be configured to switch processing after a given nb of frames. A _processing sequence_ would be define as:
```c++
struct proc_step {
int nb_frames;
proc_enum proc;
/* ... */ proc_params ;
};
// processing sequence
std::vector<proc_sequence> proc_params{
{ 100, proc_enum::noop, { ... }}, // warmup
{ 1000, proc_enum::avg, { ... }}, // pedestal measurement
{ -1, proc_enum::smx , { ... }}, // experiment
};
```https://gitlab.esrf.fr/limagroup/lima2/-/issues/138Implement compute and I/O overlap in SMX2022-08-03T15:46:26+02:00Samuel DebionneImplement compute and I/O overlap in SMX- [ ] Use a double buffering scheme to implement compute and I/O overlap of the pyFAI kernels.
- [ ] Make sure the transfer are DMA from host pinned memory.- [ ] Use a double buffering scheme to implement compute and I/O overlap of the pyFAI kernels.
- [ ] Make sure the transfer are DMA from host pinned memory.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/141Release computing resources when processing finished2022-12-07T11:00:52+01:00Samuel DebionneRelease computing resources when processing finishedIn the context of a processing pipeline, the lifetime of computing resources (aka GPU buffers, queues...) should be release as soon as the processing is finished. In the other hand, the lifetime of results buffers (aka circular buffer) i...In the context of a processing pipeline, the lifetime of computing resources (aka GPU buffers, queues...) should be release as soon as the processing is finished. In the other hand, the lifetime of results buffers (aka circular buffer) is tight to the acquisitions by clients.
- Release computing resources ASA the pipeline is finished
- Release results buffers when the pipeline is erasedhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/142Add failure_node to simulate failure in processing2022-09-13T11:43:49+02:00Samuel DebionneAdd failure_node to simulate failure in processingThe collapsing / cleanup of the processing when a node throws an exception (e.g. `hdf5_node` fail to access file) is difficult to master. This new node would make failure reproductible and testable.The collapsing / cleanup of the processing when a node throws an exception (e.g. `hdf5_node` fail to access file) is difficult to master. This new node would make failure reproductible and testable.https://gitlab.esrf.fr/limagroup/lima2/-/issues/144Merge latest Core into PSI branch2022-10-11T15:47:39+02:00Alejandro Homs PuronMerge latest Core into PSI branchAlejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/147Support continuous / infinite acquisition2023-07-21T14:34:13+02:00Samuel DebionneSupport continuous / infinite acquisitionBliss `timescan`s fails because `io_hdf5_node` does not support a number of frames unknown at creation time.Bliss `timescan`s fails because `io_hdf5_node` does not support a number of frames unknown at creation time.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/148Add pipeline metadata, e.g. creation timestamp, params2022-11-14T09:33:46+01:00Samuel DebionneAdd pipeline metadata, e.g. creation timestamp, paramsWhen retrieving the pipelines (aka with the Tango `pipelines` attribute), it would be interesting to get metadata associated with the pipelines to order and/or visualize them according, for instance, to their creation timestamp.When retrieving the pipelines (aka with the Tango `pipelines` attribute), it would be interesting to get metadata associated with the pipelines to order and/or visualize them according, for instance, to their creation timestamp.https://gitlab.esrf.fr/limagroup/lima2/-/issues/149Add support for init_params per device2023-07-21T14:33:49+02:00Samuel DebionneAdd support for init_params per device`plugins_params` is currently a device property of the control device that is broadcasted to each/every devices that belong to the app.
Multiple options:
- One config file with all the init params as `plugins_params` (a la PSI)
- a vec...`plugins_params` is currently a device property of the control device that is broadcasted to each/every devices that belong to the app.
Multiple options:
- One config file with all the init params as `plugins_params` (a la PSI)
- a vector plugin params with configuration for each devices (a la Smartpix)
- each device has it's own `plugin_params`, aka not broadcasted anymore (a la Sam :-))
@ponsard has a PR ready to implement option 2. @alejandro.homs what do you think?https://gitlab.esrf.fr/limagroup/lima2/-/issues/153Split processing construction from acquisition preparation2023-05-17T18:06:01+02:00Samuel DebionneSplit processing construction from acquisition preparationThis would allow to reuse the same processing across multiple acquisitions, aka chaining acquisitions with a single processing instance.
```
uuid = /* gen uuid */;
prepare_proc(uuid, nb_frames, proc_params);
prepare_acq(uuid, ctrl_para...This would allow to reuse the same processing across multiple acquisitions, aka chaining acquisitions with a single processing instance.
```
uuid = /* gen uuid */;
prepare_proc(uuid, nb_frames, proc_params);
prepare_acq(uuid, ctrl_params, acq_params);
prepare_acq(uuid, ctrl_params, acq_params); // Reuse the same processing (frame index not reset)
prepare_acq(uuid, ctrl_params, acq_params);
```https://gitlab.esrf.fr/limagroup/lima2/-/issues/156Compression on writer_sparse datasets not supported2022-12-05T15:20:54+01:00Samuel DebionneCompression on writer_sparse datasets not supportedThe compression setting is exposed to the user but not properly supported, aka only compression=`none` works.
In the `writer_sparse`, the `dcpl` is defined and used for the radius-1d and `radius_mask` datasets but those are written with...The compression setting is exposed to the user but not properly supported, aka only compression=`none` works.
In the `writer_sparse`, the `dcpl` is defined and used for the radius-1d and `radius_mask` datasets but those are written without chunking, resulting in:
```
H5Dint.c line 1319 in H5D__create(): filters can only be used with chunked layout
```https://gitlab.esrf.fr/limagroup/lima2/-/issues/158Modularized GPU pipelines (split across multiple TBB nodes)2022-12-14T08:57:50+01:00Samuel DebionneModularized GPU pipelines (split across multiple TBB nodes)Currently the GPU code in rather monolithic, including computation that are not related, e.g. pedestal correction and FAI. And now reconstruction.
We should be allow composition of GPU pipelines in a more modular way:
```mermaid
graph ...Currently the GPU code in rather monolithic, including computation that are not related, e.g. pedestal correction and FAI. And now reconstruction.
We should be allow composition of GPU pipelines in a more modular way:
```mermaid
graph LR;
transfer_to_device_node --> reconstruction_node ;
subgraph GPU
reconstruction_node -- Event -->gain_pedestal_correction;
gain_pedestal_correction -- Event --> fai_node;
end
gain_pedestal_correction --> transfer_to_host_node;
transfer_to_host_node --> io_hdf5_node;
```
The nodes would be constructed with the appropriate resource (context, queues and buffers). Computing resources need to be handled separately as discussed in #141.
The data transmitted will be a `boost::compute::event`, to be discussed.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/159Make the Receiver Allocator Aware2023-01-12T14:53:58+01:00Samuel DebionneMake the Receiver Allocator AwareStarting with the `simulator`:
```
class receiver
{
receiver(std::pmr::polymorphic_allocator allocator = std::allocator());
...
```
then the allocator should be used to allocate the `data_t` provided to `on_frame_ready()` callback.Starting with the `simulator`:
```
class receiver
{
receiver(std::pmr::polymorphic_allocator allocator = std::allocator());
...
```
then the allocator should be used to allocate the `data_t` provided to `on_frame_ready()` callback.ID29 restarthttps://gitlab.esrf.fr/limagroup/lima2/-/issues/160Checkpoint nodes should be connected after the Buffers nodes in the graph Top...2023-01-16T12:00:10+01:00Samuel DebionneCheckpoint nodes should be connected after the Buffers nodes in the graph TopologyThis is not the case at least for the `sparse` node. The counter might be incremented before the data are in the buffer causing "Data not available" race condition in the client.This is not the case at least for the `sparse` node. The counter might be incremented before the data are in the buffer causing "Data not available" race condition in the client.ID29 restartSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/161Processing slows down once acquisition is finished2023-01-12T14:04:33+01:00Samuel DebionneProcessing slows down once acquisition is finishedWith the SMX Pipeline, the processing gets 10x slower once the acquisition is finished. The reason is yet unknown.With the SMX Pipeline, the processing gets 10x slower once the acquisition is finished. The reason is yet unknown.ID29 restartSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/162SegFault when interrupting processing (Ctrl+C)2023-01-12T13:59:09+01:00Samuel DebionneSegFault when interrupting processing (Ctrl+C)```
Thread 191 "lima2_psi_smx_rcv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x725c4e38eee0 (LWP 263801)]
``````
Thread 191 "lima2_psi_smx_rcv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x725c4e38eee0 (LWP 263801)]
```ID29 restartSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/163Recover from FAULT state2023-01-12T13:58:45+01:00Samuel DebionneRecover from FAULT stateSomething went wrong and then Client Detector reports a FAULT state (which is fine). It looks like resetAcq() is a no-op. At the SDK level, the receivers are still `Status:Running`.
Subsequent call to `prepareAcq()` returns:
```
Can not...Something went wrong and then Client Detector reports a FAULT state (which is fine). It looks like resetAcq() is a no-op. At the SDK level, the receivers are still `Status:Running`.
Subsequent call to `prepareAcq()` returns:
```
Can not execute F_SET_RECEIVER_TIMING_MODE when receiver is not idle[lid29p9jfrau1, 1960]
```
The only solution so far is to restart the Device Servers.ID29 restarthttps://gitlab.esrf.fr/limagroup/lima2/-/issues/164Implement HDF5 metadata from Detector Info2023-01-12T14:53:31+01:00Samuel DebionneImplement HDF5 metadata from Detector InfoHDF5 metadata are currently filled with dummy values.HDF5 metadata are currently filled with dummy values.ID29 restarthttps://gitlab.esrf.fr/limagroup/lima2/-/issues/165Modify Stream2 implementation to give access to Compressed Data2023-01-30T11:33:10+01:00Samuel DebionneModify Stream2 implementation to give access to Compressed DataThe current Stream2 C implementation provided by Dectris returns the decompressed data only. This is an issue for the multiple reasons:
- Decompression is single threaded and happens in the context of the acquisition thread;
- Compresse...The current Stream2 C implementation provided by Dectris returns the decompressed data only. This is an issue for the multiple reasons:
- Decompression is single threaded and happens in the context of the acquisition thread;
- Compressed data should be accessible e.g. to avoid recompressing for no reason if no transformation are applied.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/166Clang format check not running properly2023-02-10T16:21:29+01:00Samuel DebionneClang format check not running properlyThe job succeeds but the check does not actually run:
```
$ .gitlab-ci/run-style-check-diff.sh
Target branch: develop
fatal: detected dubious ownership in repository at '/builds/limagroup/lima2'
To add an exception for this directory, c...The job succeeds but the check does not actually run:
```
$ .gitlab-ci/run-style-check-diff.sh
Target branch: develop
fatal: detected dubious ownership in repository at '/builds/limagroup/lima2'
To add an exception for this directory, call:
git config --global --add safe.directory /builds/limagroup/lima2
.gitlab-ci/run-style-check-diff.sh: line 14: git-clang-format: command not found
```https://gitlab.esrf.fr/limagroup/lima2/-/issues/168Add introspection to processing data accessor2023-07-21T14:43:47+02:00Samuel DebionneAdd introspection to processing data accessorSplit the pipeline concept into:
- Computation, with resources that are local to the processing such as GPU memory are bound to the computation lifetime
- Data accessor/publisher, with circuclar buffer and progress counter that are avai...Split the pipeline concept into:
- Computation, with resources that are local to the processing such as GPU memory are bound to the computation lifetime
- Data accessor/publisher, with circuclar buffer and progress counter that are available until the pipeline get erased.
Data accessors should be introspectable and give information about the data available (shape, dtype...).They are basically the sender part of the channel where the receiver is in the reading loop of Bliss.https://gitlab.esrf.fr/limagroup/lima2/-/issues/169Add accumulation algorithm2023-09-14T09:00:02+02:00Samuel DebionneAdd accumulation algorithmAdd accumulation algorithm following the latest dev on Lima1:
- filtering (offset, threshold)
- reduction operation (sum, mean)Add accumulation algorithm following the latest dev on Lima1:
- filtering (offset, threshold)
- reduction operation (sum, mean)Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima2/-/issues/170Version 0.1b on master branch with support of simulator dectris eiger and sma...2024-02-15T16:14:55+01:00Laurent ClaustreVersion 0.1b on master branch with support of simulator dectris eiger and smartpixToday it is no possible for anybody to know on which branch to start to either compile the latest stable version or to start developing a new camera support.
We must do a effort to provide a first beta release 0.1b when a minimum of code...Today it is no possible for anybody to know on which branch to start to either compile the latest stable version or to start developing a new camera support.
We must do a effort to provide a first beta release 0.1b when a minimum of code is available to allow anyone to start with Lima2.Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima2/-/issues/171SMX PSI/Jungfrau-4M: SEGV at acq. end2024-03-05T10:20:24+01:00Alejandro Homs PuronSMX PSI/Jungfrau-4M: SEGV at acq. endAt the end of an acquisition one data receiver crashes:
```
...
- 18:30:23.536 INFO: Ready ...
- 18:30:23.536 INFO: Ready ...
- 18:30:23.536 INFO: Receiver Started
- 18:30:23.536 INFO: Receiver Started
- 18:30:23.536 INFO: Status: runni...At the end of an acquisition one data receiver crashes:
```
...
- 18:30:23.536 INFO: Ready ...
- 18:30:23.536 INFO: Ready ...
- 18:30:23.536 INFO: Receiver Started
- 18:30:23.536 INFO: Receiver Started
- 18:30:23.536 INFO: Status: running
- 18:30:23.536 INFO: Status: running
[lid29p9jfrau2:3433106] *** Process received signal ***
[lid29p9jfrau2:3433106] Signal: Segmentation fault (11)
[lid29p9jfrau2:3433106] Signal code: Address not mapped (1)
[lid29p9jfrau2:3433106] Failing at address: 0x5c
[lid29p9jfrau2:3433106] [ 0] linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0)[0x77a376cc04c8]
[lid29p9jfrau2:3433106] [ 1] /lib/powerpc64le-linux-gnu/libc.so.6(cfree+0x30)[0x77a37507f1e0]
[lid29p9jfrau2:3433106] [ 2] [0x77a2e134de80]
[lid29p9jfrau2:3433106] [ 3] /users/blissadm/conda/miniconda/envs/jungfrau_lima2/lib/libstdc++.so.6(_ZdaPv+0x18)[0x77a3753234c0]
[lid29p9jfrau2:3433106] [ 4] /users/blissadm/conda/miniconda/envs/jungfrau_lima2/lib/libtango.so.94(_ZN5Tango9Attribute10delete_seqEv+0x100)[0x77a375e83cc0]
[lid29p9jfrau2:3433106] [ 5] /users/blissadm/conda/miniconda/envs/jungfrau_lima2/lib/libtango.so.94(_ZN5Tango9Attribute17fire_change_eventEPNS_9DevFailedE+0x1574)[0x77a375e9b1c4]
[lid29p9jfrau2:3433106] [ 6] lima2_psi_smx_recv(+0x8e224)[0x7455fe0e224]
[lid29p9jfrau2:3433106] [ 7] lima2_psi_smx_recv(+0x8e6ec)[0x7455fe0e6ec]
[lid29p9jfrau2:3433106] [ 8] /users/blissadm/conda/miniconda/envs/jungfrau_lima2/lib/liblima_psi_recv.so.0.0(+0x383b0)[0x77a376bf83b0]
[lid29p9jfrau2:3433106] [ 9] /users/blissadm/conda/miniconda/envs/jungfrau_lima2/lib/liblima_psi_recv.so.0.0(+0x3977c)[0x77a376bf977c]
[lid29p9jfrau2:3433106] [10] /users/blissadm/conda/miniconda/envs/jungfrau_lima2/lib/libstdc++.so.6(+0xff304)[0x77a37534f304]
[lid29p9jfrau2:3433106] [11] /lib/powerpc64le-linux-gnu/libpthread.so.0(+0x8838)[0x77a376a08838]
[lid29p9jfrau2:3433106] [12] /lib/powerpc64le-linux-gnu/libc.so.6(clone+0x74)[0x77a37511ba44]
[lid29p9jfrau2:3433106] *** End of error message ***
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
- 18:52:51.180 INFO: Stopping Receiver
```
[lima2_jungfrau4m_rr4_smx.log.2](/uploads/55cfb7eb15ab8d0fa24009ef91a3dbec/lima2_jungfrau4m_rr4_smx.log.2)
The call stack seems to be:
```
* operator delete[](void*)
* Tango::Attribute::delete_seq()
* Tango::Attribute::fire_change_event(Tango::DevFailed*)
* push_change_event("nb_frames_xferred", xferred_frames, 1, 0, true)
* lima::tango::receiver<lima::detectors::psi::receiver, lima::processing::pipelines::smx::pipeline>::prepare(char*)::{lambda(int)#3}::operator()(int) const
* lima::acquisition_thread<lima::detectors::psi::hw::acquisition>::start()::{lambda()#1}::operator()() const
```Alejandro Homs PuronAlejandro Homs Puron