Experimental Physics and
| |||||||||||||||||
|
Hi Matt,
On Fri, Jul 17, 2015 at 4:42 PM, Matthew D. Moore <[email protected]> wrote:
I have a fork of Nick Rees' github repo that I use for our Xspress3. I changed many of the (weirdly, for a machine from a vendor) DLS-specific configuration, so that it would build well on the system provided by Quantum. I also added trivial loading of "simple_mca.db" from the Mca record so that "normal" (IMHO) MCA-style ROI variable names could be used, to act more like any other multi-element MCA. There isn't support code to have these ROIs actually work to update counts and so on. I use client code to copy these ROI placeholders to the live Xspress3 ROIs. Using a "normal" Mca record would certainly be something to consider. I trimmed many of the useless attributes from being saved to HDF5 files (for example, ROI definitions were being saved at each pixel -- not a lot of extra data, but certainly unnecessary). I worked on saving data as Float32 instead of Float64. Float64 is simply not necessary for this data. In fact, like the saving of the ROI limits at each pixel, it sort of demonstrates a fundamental lack of understanding of what the detector does. I made a Pull Request against Nick's repository in January. It has not been merged, and Nick's repo has not been updated since. I had taken this to mean that no one else was working on this code. Meanwhile, Nick wrote:
> We are doing some work at Diamond - starting by simplifying the driver so that it has far > fewer parameters in the NDArray, and making it simpler to scale the system by number of > channels. This should make it more performant and able to scale to higher speeds and/or > more channels. I don't see these changes. Is this code available? > I would be interested if anyone actually uses the ROI's that are stored in the data file. You mean the HDF5 data files? Then, no. The ROIs are not necessary here. If one has the full array and knows the ROI definitions, these are as easy to extract as they are to read from a separate dataset. One thing we've found to be very important for performance is to use compression on the HDF5 files. We typically acquire data for 10 to 100 ms per spectra. Since the max count rate is ~3MHz and there are 4096 bins, the typical count is around 10 to 100 in each bin. Even with the data stored as Int32 or Float32 (and especially as Float64), the data are highly compressible, and disk i/o dwarfs compression / decompression time. We typically use Zlib compression level 1. > These add a lot of attributes and have a lot of overhead - both manipulating the > NDArray every frame, and also when writing the file at the end - because it writes > all the parameters after the scan finishes. I think saving the SCA and DTC data is a good idea, but the ROI data is not necessary. I trimmed my copy of XSP3.xml from ~250 to ~75 lines (for a 4 element array). The main complaint with the Xspress3 is the lack of dead time information. This seems to not be an Epics issue, but an issue from the vendor.
| ||||||||||||||||
ANJ, 16 Dec 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |