[NeXus-tech] axes for multidimensional data

[Pete Jemian]

The data is actually a 3-D collection.
FYI: The scan was interrupted before completion.

Previous image was the "D=5" slice.  Too complicated for view.
The "D=1" slice shows the situation better.
The full dataset seems ideal (in my view) for us to use as one example.

The attached tarball contains both our internal data format (MDA) at 1.7 
MB, and a text file dump, at 1.9 MB, of its content.  It will take some 
work to get it into HDF5.  Won't happen today.

Pete

On 3/2/2011 1:01 PM, Pete Jemian wrote:
> Here's an example plot of a data set.
> It was collected with the EPICS sscan record using a two-layer next of
> 1-D scans. The outer scan was the delay generator, the inner scan was a
> positioner. Note the drift in the top rows of the positioner scan.
> I'll see if I can translate this into an HDF5 file as an example data
> set for us.
>
> Plot is now attached...
>
> Pete
>
>
> On 2/22/2011 4:58 AM, Tobias Richter wrote:
>> Hi Mark,
>>
>> On Tue, 2011-02-22 at 08:46 +0100, Mark Koennecke wrote:
>>> I am a little confused: up to now we had discussed this problem in the
>>> context of a scan in 2D or more. Not as
>>> a general thing.
>>
>> As I wrote the @drive idea is an aside that might be useful, but I'd
>> want it to be left out for now. Otherwise the problem is general only in
>> that it applies to scans in nD with n>1.
>>
>>> Then in the context of scans in 2D the problem has come up at PSI too. I
>>> will add another two ideas towards a solution
>>> to the mess. The first is to use an additional data attribute which
>>> describes what has been meant:
>>>
>>> data:NXdata
>>> data[nx*ny]
>>> @signal=1
>>> @scan_intent=nx:ny
>>> x[nx*ny]
>>> @axis=1
>>> @primary=1
>>> y[nx*ny]
>>> @axis=1
>>
>> This (and Ben's suggestion) suffers from not passing the slicing test.
>> For our users the main selling point of hdf5 is efficient storage of
>> multi dimensional data. Here the view is almost the more dimensions the
>> better - leave all the off-by-one errors in dealing with the arrays to
>> the well tested file backend. This is important for user written
>> analysis scripts.
>>
>> But even if we will not find an agreement here, as long as it is legal
>> to write data the way we prefer here, there should be a solution that
>> solves our axis problem as well.
>>
>> Regards,
>> Tobias
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7idc_0040_example.tar.gz
Type: application/gzip
Size: 718388 bytes
Desc: not available
URL: <http://lists.nexusformat.org/mailman/private/nexus-tech/attachments/20110302/d1fc2486/attachment-0001.bin>