Opened 8 years ago

Last modified 7 years ago

#594 accepted task

Check default value of cansas_version property in CansasReader class

Reported by: smk78 Owned by: tim
Priority: major Milestone: SasView 4.3.0
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing

Description (last modified by butler)

(Ticket raised on behalf of Lewis) CansasReader has a property cansas_version which determines the xml header written in the files. This currently seems to default to 1.0 and not 1.1 as you get the old header if you call this class directly. However if you save xml files from the GUI they are saved with the new header! This suggests the default is over-ridden somewhere. Needs investigating.

Attachments (4)

isis_1_0_write_test.xml (25.6 KB) - added by krzywon 8 years ago.
Cansas v1.0 file written after loading Cansas 1.0 data set
isis_1_1_write_test.xml (46.8 KB) - added by krzywon 8 years ago.
Cansas v1.1 file written after loading Cansas 1.1 data set
ISIS_1_0.xml (18.3 KB) - added by krzywon 8 years ago.
Cansas v1.0 file loaded
ISIS_1_1.xml (33.9 KB) - added by krzywon 8 years ago.
Cansas v1.1 file loaded

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by krzywon

Cansas v1.0 file written after loading Cansas 1.0 data set

Changed 8 years ago by krzywon

Cansas v1.1 file written after loading Cansas 1.1 data set

Changed 8 years ago by krzywon

Cansas v1.0 file loaded

Changed 8 years ago by krzywon

Cansas v1.1 file loaded

comment:1 Changed 8 years ago by krzywon

I have attached cansas 1.0 and 1.1 data files that can be loaded into sasview as well as saved data sets for each that show they are written with the proper header. Could you provide an example data file that is not saving properly?

comment:2 Changed 8 years ago by smk78

No this was an issue calling the class from Python. It seems the default behaviour is to write 1.0?

comment:3 Changed 8 years ago by smk78

If you don't load xml data - and thus give the program a hint as what version of xml it should write - where does it decide to write 1.1?

comment:4 Changed 8 years ago by krzywon

OK, I get the issue now. That isn't right. Let me look into this.

comment:5 Changed 8 years ago by krzywon

I've had no luck recreating this issue. All data I've saved through the GUI in cansas xml format gets saved as cansas v1.0, not v1.1. I tested in the 4.0 alpha release and running from the code base. I have saved projects, fits, p(r) inversions, and data plotted on graphs. All come out saved as v1.0.

comment:6 Changed 8 years ago by smk78

Unless you have got your 1.0's and 1.1's transposed in that comment, you have indeed recreated the issue: why is the default to write 1.0 headers and not 1.1 headers?

comment:7 Changed 8 years ago by krzywon

The default of writing as cansas 1.0 is because of the underlying code used to write the save states, fits, etc. Each perspective has its own cansas reader to call in the saved parameters from save states and analyses. These all expect cansas v1.0 right now. I have a local fix to start writing the data in v1.1, but none of these saved states are loadable yet. I will make the perspective readers look at the cansas version in the header, or see if I can get them all integrated into a single reader/writer.

comment:8 Changed 8 years ago by krzywon

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

comment:9 Changed 8 years ago by krzywon

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

This will get fixed at the same time the save state is refactored. Moving to +1.

comment:10 Changed 7 years ago by krzywon

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

comment:11 Changed 7 years ago by tim

  • Owner changed from krzywon to tim
  • Status changed from accepted to assigned

comment:12 Changed 7 years ago by tim

  • Status changed from assigned to accepted

comment:13 Changed 7 years ago by butler

  • Description modified (diff)
  • Milestone changed from SasView 4.2.0 to SasView 4.3.0

comment:14 Changed 7 years ago by butler

  • Priority changed from critical to major
Note: See TracTickets for help on using tickets.