Opened 7 years ago

Closed 5 years ago

#976 closed defect (fixed)

CanSas HDF reader will not read all valid CanSas HDF (NXcanSAS) files

Reported by: pkienzle Owned by: krzywon
Priority: blocker Milestone: SasView 4.2.1
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing

Description (last modified by butler)

The current canSAS reader is interpreting fields by name even when the name of the field is not specified in the canSAS spec:

http://download.nexusformat.org/doc/html/classes/applications/NXcanSAS.html

For example, the mask information is being read from the "Mask" field, but the spec says that the mask field name given by the required @mask attribute of the SasData group. It may happen to work since "Mask" is a likely field name for the mask data, but "mask" is equally likely and HDF is case sensitive.

It may be that the reduction software is not writing the required attribute names, but the reader should at least check prior to looking for the default names such as "mask" or "Mask".

Change History (16)

comment:1 Changed 7 years ago by butler

  • Description modified (diff)

comment:2 Changed 7 years ago by smk78

Whose reduction software are we talking about here?

comment:3 Changed 7 years ago by butler

We are not talking about anybody's specific writer. The point is that because it is hard to get agreement on nomenclature sometimes, many fields are defined by an attribute tag that gives the name of the field as in the mask example given. Basically if your writer uses "Mask" as the field name then our reader will read it but that is INCORRECT implementation — we SHOULD be looking not for "Mask" but for the @mask to get the name of the field we are to look for (which COULD be "steve" instead or "mask" instead of "Mask")

Our reader should follow the spec if we are going to claim it is a standard and we read anybody's file who adheres to said spec :-)

comment:4 Changed 7 years ago by smk78

Ahh, ok. I read 'It may be that the reduction software is not writing the required attribute names' and wondered what reduction software that meant.

comment:5 Changed 6 years ago by butler

  • Milestone changed from SasView Next Release +1 to SasView 4.3.0

comment:6 Changed 6 years ago by smk78

Transferred from #1127:

Jan Ilvasky/Pete Jemian have noted several issues with how SasView handles NXcanSAS:

i) SasView expects NXcanSAS to have the .h5 extension, however such enforcement actually breaks the NeXus standard which doesn't specify an extension (Tim Snow notes that .h5, .nxs, .nexus, .hdf, even .nx.hdf are in use!);

ii) the .h5 example files in the SasView /test folder are actually incompatible with the NXcanSAS standard, they use the attributes “uncertainty” and “I_uncertainty" instead of the plural “uncertainties”.

Separately, Brian Pauw would now really like SasView to start loading NXcanSAS containing @Mask_indicies (which rather spookily goes to the original reason this ticket was opened).

Last edited 6 years ago by smk78 (previous) (diff)

comment:7 Changed 6 years ago by smk78

  • Summary changed from CanSas HDF reader will not read all valid CanSas HDF files to CanSas HDF reader will not read all valid CanSas HDF (NXcanSAS) files

comment:8 Changed 6 years ago by smk78

Added NXcanSAS to ticket title so it can be found easier in ticket searches.

comment:9 Changed 6 years ago by smk78

Transferred from #1127:

@butler writes:

The bottom line is we know that we are in fact not fully compliant with the NXcanSAS standard and need to fix that…. but we cannot necessarily use all the things that a specific NXcanSAS file gives us. What the reader should do is accept any NXcanSAS standard compliant file that contains the information needed by SasView.

This means:

  • Check for an NXcanSAS format beyond its extension (as required by the spec)
  • Read all the SasView relevant information as long as it is provided in a way that conforms to the standard — meaning we must look at the attribute tags first
  • In the absence of an attribute tag we should look for common names we expect (but this is an extra so don't need to guess everybody's naming)
  • accept any file we can extract the appropriate information from even if it contains a lot of extra guff we don't understand (said guf being discarded by SasView)

comment:10 Changed 6 years ago by smk78

  • Priority changed from minor to blocker

As this has become a more pressing matter I'm making it a blocker for 4.3.

comment:11 Changed 6 years ago by krzywon

  • Owner set to krzywon
  • Status changed from new to assigned

comment:12 Changed 6 years ago by krzywon

In 8f882fecc993c2aea9372b888a43497808abe2d7/sasview:

Changes to NXcanSAS reader to comply with specification. refs #976

comment:13 Changed 6 years ago by krzywon

In cf820f570b22acbdf7786ad33fd7ce08e817e90a/sasview:

Give proper label to NXcanSAS data files in file browser window. refs #976

comment:14 Changed 6 years ago by krzywon

In 02c1608e6546bb8b1a0df37db94d096ef657c016/sasview:

Allow for multiple Q resolutions/uncertainties for USANS data. refs #976

comment:15 Changed 5 years ago by butler

  • Milestone changed from SasView 4.3.0 to SasView 4.2.1

As agreed at the Tuesday meeting we are now planning a 4.2.1 version for which this will be the main feature. Moving ticket to that milestone.

comment:16 Changed 5 years ago by GitHub <noreply@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In dcd6efda873ff0f7f10cbe8d301cc4cc3f65cd3b/sasview:

Merge pull request #180 from SasView?/ticket-1111

Multiple data loader and writer updates - NXcanSAS compliance, data conversion, saving as NXcanSAS, plus more

Fixes #976
Fixes #1129
Fixes #1111
Fixes #1221

Note: See TracTickets for help on using tickets.