Opened 3 years ago

Closed 3 years ago

#269 closed defect (fixed)

Failure to assign model when using attached data file

Reported by: ajj Owned by: krzywon
Priority: major Milestone: SasView 3.1.0
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing

Description

When sending the attached file to fitting, a blank fit panel occurs and assigning the model fails with:

Traceback (most recent call last):

File "/usr/lib64/python2.6/site-packages/sasview-3.0.0_r7073-py2.6-linux-x86_64.egg/sans/perspectives/fitting/fitpage.py", line 1181, in _on_select_model

self.onSmear(None)

File "/usr/lib64/python2.6/site-packages/sasview-3.0.0_r7073-py2.6-linux-x86_64.egg/sans/perspectives/fitting/fitpage.py", line 2587, in onSmear

temp_smearer = self.on_smear_helper()

File "/usr/lib64/python2.6/site-packages/sasview-3.0.0_r7073-py2.6-linux-x86_64.egg/sans/perspectives/fitting/fitpage.py", line 2613, in on_smear_helper

self._get_smear_info()

File "/usr/lib64/python2.6/site-packages/sasview-3.0.0_r7073-py2.6-linux-x86_64.egg/sans/perspectives/fitting/fitpage.py", line 1586, in _get_smear_info

self.dq_l = data.dx[0]

IndexError?: index out of bounds

It seems it is trying to assign dq_l when this dataset has no smearing information (pinhole SAXS from I22 at Diamond).

The cansas1D file was created by me using a python script which I believe produces standard compliant files. The data file and script are attached.

Attachments (2)

convert-to-ascii.py (4.7 KB) - added by ajj 3 years ago.
Script to convert 2013 DAWN output to cansas XML
113217.xml (124.9 KB) - added by ajj 3 years ago.
Datafile that causes problems

Download all attachments as: .zip

Change History (9)

Changed 3 years ago by ajj

Script to convert 2013 DAWN output to cansas XML

Changed 3 years ago by ajj

Datafile that causes problems

comment:1 Changed 3 years ago by ajj

  • Milestone changed from SasView Next Release +1 to SasView 3.0.1
  • Owner set to krzywon
  • Status changed from new to assigned

Assigning to Jeff as he knows the innards of the readers.

comment:2 Changed 3 years ago by krzywon

No dI and dQ values are given, so nothing is stored, so the dQ and dI arrays from the data1D dataset are empty. When sent to the fitting engine, resolution information is expected, so when the empty arrays are read the result is the index out of bounds error. There are two options to fix this:

(1) If dI and dQ are not given in cansas data, the values will be set to 0.
(2) If data is sent to the fitting engine with no resolution information, the values will default to zero.

I'd suggest at least do option 2 to cover other data formats without resolution information, but making sure the cansas reader always has values in the resolution would be helpful.

comment:3 follow-up: Changed 3 years ago by ajj

So loading cansas assumes that there must be resolution data?

The cansas spec does not require any error or resolution information - minimum requirement is I and Q.

We load other data with no resolution and no dI (2 column ascii) and that works fine - the same should be true for cansas xml. If setting the data1D arrays to zeros is how we handle that for 2 column data, then the same answer should be done for cansas.

comment:4 in reply to: ↑ 3 Changed 3 years ago by krzywon

Replying to ajj:

So loading cansas assumes that there must be resolution data?

The cansas spec does not require any error or resolution information - minimum requirement is I and Q.

Correct, the cansas spec does <edit>not</edit> require error/resolution information. There is no assumption for the error values, whether or not they are provided. When data is loaded, what is there is loaded.

We load other data with no resolution and no dI (2 column ascii) and that works fine - the same should be true for cansas xml. If setting the data1D arrays to zeros is how we handle that for 2 column data, then the same answer should be done for cansas.

This is fine by me. I think I have a solution already. I just need to test it more before committing it to the repository. And remind me - where should this go in the repository? Trunk, a new branch or a new release branch?

Last edited 3 years ago by krzywon (previous) (diff)

comment:5 Changed 3 years ago by krzywon

I pushed the changes to trunk to fix this issue. If no resolution information is provided by the data set, the data in memory is given resolution of 0.

comment:6 Changed 3 years ago by ajj

  • Work Package set to SasView Bug Fixing

comment:7 Changed 3 years ago by krzywon

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

I've made the fix and told Andrew about the fix. I think he has tested it, but I'm closing for now.

Note: See TracTickets for help on using tickets.