3d detectors

[Kristian Nielsen]

> Kristian,
>      I modified your PSD_monitor routine to handle time-of-flight data
> (called PSDTOF_monitor.comp).  The new detector generates data in x, y, and
> t and I find I now have a major file-size problem.  For example, a 140×140
> PSD_monitor generates about a 150 kB file.  If we divide 16.7 msec (1/60 for
> the SNS source) into 10 mu-sec bins, we need 1670×150 kB or several hundred
> MB.  These files are quite sparse, so there should be great gains to be made

OK, that would be a problem.

The current method needs to store one double precision floating point
number for each bin (8 bytes) in memory during the simulation. This
would be 260 Mb of RAM needed in your case which is a lot, but not
totally unreasonable. To compute error estimates the current method
needs three times that amount which is quite a lot. However, going to
single precision is quite dangerous for large number of neutron
histories (~10e9). Once the computation finishes, converting to single
precision is fine, of course.

I already had plans to implement an optional binary output format. This
would output your detector data as a single precision binary file (130Mb
in your case). This would then subsequently be converted to NeXuS. This
is something I could implement for you quickly (a few weeks) if needed.

> via data compression.  In addition, the ideal way to view this data would be
> by looking at x-y plots over a specified range of time channels.  This
> viewing would best be done interactively.  In other words, import the entire
> data set into a viewer to which one can specify a range of time channels.
> My impression is that Nexus can help with both the compression and the
> viewing.  Do you have any plans for generating Nexus files?  I will look
> into this, but I suspect you are the most-qualified person for the job.

Your example clearly shows the use of writing NeXuS directly from the
simulation, using its build-in data compression algorithms. This would
appear to be quite useful here. I will think some more about it, but
that will take somewhat longer to implement.

Are you saying that a suitable general viewer is already available for
the NeXuS/HDF format? That would be great, obviously it will never be
possible to create all the visualization tools we need specifically for
McStas. If good NeXuS/HDF tools are available, I will want to accelerate
the implementation of NeXuS in McStas.

> P.S. Is the source code for the DETECTOR_OUT_2D macro available?

Yes, it is found in the files mcstas-r.h and mcstas-r.c (located in the
lib/ subdirectory of the distribution). Obviously we need to include a
DETECTOR_OUT_3D macro as well. Send me your code when you finish it or
get stuck, and I will look at it.

Good luck, it sounds like you are doing great work!

 - Kristian.

--
Kristian Nielsen        kristian.nielsen at risoe.dk
Risø National Laboratory
Condensed Matter Physics and Chemistry Department
Tel. +45 4677 5515   Fax +45 4677 4790