PixelData.num_pixels sometimes returns uint64

[ghost]

This is causing issues when using .num_pixels in calculations. This only happens when the data is file-backed, as the PixelData instance pulls the number from faccess which stores it as uint64.

Example:

signal_sum = sum(fe_sqw.data.pix.get_data('signal'));
while fe_sqw.data.pix.has_more()
    fe_sqw.data.pix.advance();
    signal_sum = signal_sum +  sum(fe_sqw.data.pix.get_data('signal'));
end
mean_signal = signal_sum/fe_sqw.data.pix.num_pixels

prints:

mean_signal = unit64 0

Outputs::

• PixelData.num_pixels should always return a double

[nickbattam-tessella]

The max integer value a double can store exactly is 2^53 (~9*10^15). Storing and returning the number of a pixels may introduce problems for the next generation of machines.

LET has 12 Doors 48 Tubes 1024 Detectors 1000 TimeBins 1000 measurements ~6*10^11 pixels Mushroom will have 3 order of magnitude more flux than LET so will approach this limit.

For PixelData objects with no backing file (i.e. those created with an explicit array argument in the constructor) the num_pixels is calculated as the (double) valued num_pix = size(obj.data, 2);

The data for num_pixels is stored in file as uint64 and that value should be retained. Providing a standard double-valued attribute will help prevent hard-to-find user errors.

[mducle]

Mushroom will have 3 order of magnitude more flux than LET so will approach this limit.

Not really. Whilst it's true that MUSHROOM and future instruments (like at ESS) will have maybe up to 10^3 times more events than current instruments, they will not have 10^3 times more pixels. An event is a single neutron detection. A pixel in Horace terms is the sum of neutron events within a time-of-flight range/bin.

LET currently runs with a time bin of 1us, which is about the limit of the current data acquisition electronics. This time bin size could decrease by a factor of 10 in the near future but not much more (the limitation is the amount / access time of fast RAM to store the events rather than the time resolution of the electronics itself which is of the order of 0.01us). MUSHROOM will actually have fewer detectors than LET (because the detector tubes use 3He which is much more expensive now than when LET was built), so I think it will have about the same number of pixels as LET - maybe an order of magnitude more as people do finer rotation steps (the number of measurements in your product), but I don't see it being 10^3 times more.

If Horace was to change to storing event data rather than the histogrammed pixel data then we would have an issue, but this is not on the cards...