ABS reader (NIST 1D) does not handle negative dx properly (USANS slit smearing)

[pkienzle]

The NIST (*.ABS) USANS files contain the slit length as a negative entry in the dx column which is not recognized by the reader. Need to add the case of dx < 0 then dx =NONE and dl = abs(dx).

[butler]

This is important to the NIST community so we would like to fix it in this release. Should only impact NIST 1D data (.ABS) so should not be any need for general infrastructure questions discussion making it fairly clean and easy?

[krzywon]

I took a quick look and noticed the USANS data, because it has no data file extension, is getting loaded by the generic ASCII reader. This will take a small infrastructure change and updates to the ABS reader to get working.

[butler]

I don't think we should be encouraging changes to general readers to support individual idiosyncrasies. Ultimately we can dilute our efforts significantly if we try to support all data formats and their idiosyncrasies anyway (that is why I thought we supported standard formats), but those that we do have should be confined to their own reader?

NIST folk should be using NIST or standard formats I would think?

[butler]

As agreed on fortnightly call of June 21, am moving all minor priority tickets to next release (+1) given the resources and time available to get this release out.

[butler]

The regular ASCII reader should not be changed to deal with a NIST idiosyncrasy. However the .ABS reader, as a NIST reader, and as the ticket title implies should in fact respect the NIST format. A test with 4.1.2 shows the reader sees the negative fourth column as a pinhole resolution with a negative dq. Given the cleanup of the readers the ABS reader should be fixed for the next release.

[GitHub <noreply@…>]

In 2b442811f6c17cdc297505d0d4fe58dcfa5111fc/sasview:

Merge pull request #134 from SasView?/ticket-489

Ticket 489: Properly handle negative dx values in the ABS reader.

closes #489