What data should be loaded / is loaded if a Cansas xml file has multiple <SASdata>?

[smk78]

(Ticket raised on behalf of Lewis) SasView will apparently read Cansas xml files with multiple <SASdata> blocks (provided there aren't too many…) but it only actually seems to load one data block [I think the last one read - Steve]. This behaviour needs investigating and explaining to the user asap. But in the longer term this behaviour needs to be reviewed and the loader amended accordingly (perhaps by recognising multiple <SASdata> and then asking for first/last/increment).

[krzywon]

Is there an example data file available to test out so I can try to fix this?

[smk78]

xml file written by SasView? with 1 <SASdata> block

[smk78]

xml file written by SasView? with 2 <SASdata> blocks

[ajj]

"Official" cansas example here:

Multiple sasentry each with two sasdata

​http://www.cansas.org/svn/1dwg/trunk/examples/cs_af1410.xml

[krzywon]

After some testing, it appears all of the data in a single <SASentry> is loaded into a single Data1D() object, regardless of the number of <SASdata> sets that are present. If multiple <SASenty> elements are present, separate Data1D() objects are created for each.

For the "cansas-multi - Copy - 1frame.xml" file, a single Data object is created, with 512 data points.

For the "cansas-multi - Copy - 2frame.xml" file, a single Data object is created, with 1024 data points.

For the "Official" cansas example, 10 Data objects are created, with varying number of data points, but all are loaded.

The question I have - what is the desired action here? Should each <SASdata> set be it's own Data1D object within SasView, should the current behavior remain, or should we ask the user what is desired?

[smk78]

I would say that the original intent was that <SASdata> would represent multiple datasets under the same run number (so multiple 'periods' or 'frames'), whereas <SASentry> represented a new run number. In terms of what !SasView might do with such data I would argue to treat both the same and create separate Data1D() objects. However, there could be a lot of <SASdata> blocks if the file has come from the X-ray community, so might be best to warn how many there are and ask the user to select min, max, increment?

[Jeff KRzywon <krzywon@…>]

In [250fec92ea66b0770da33360a90f022e1d674072]:

Closes #596: Major rewrite to canSAS XML reader to create separate Data1D objects for each SASdata. Also fixed a few bugs that were present in the reader, that were not caught until now.