Ticket #3098 (closed: fixed)
SANS reductions need to find the log entry that corrosponds to the run time
| Reported by: | Steve Williams | Owned by: | Anders Markvardsen |
|---|---|---|---|
| Priority: | major | Milestone: | Iteration 30 |
| Component: | Mantid | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Tester: | Karl Palmen |
Description
Richard reported this problem
...Run 7064 reduces in Mantid with the detector at 4m from the sample Z=23.3392, not 8m, Z=27.3382 as it should have ...
The Z possitions are shown in the Geometry tab
Change History
comment:2 Changed 9 years ago by Anders Markvardsen
Richard write 23 May 2011 16:17
Run 7064 was a normal SANS run, not any periods there. There is an ISIS problem here, rather than Mantid, in that from the end of one run, all logging info goes into the file for the NEXT run,and then a SANS2d problem due to our moving detectors.
If we spend a lot of time reconfiguring the beam line, all the info appears in a possibly long log in the next run. Thus run 7063 was detector at 4m, the detector moved to 8m before we did BEGIN for 7064, but all the logging info a the start of 7064 will say the detector is at 4m, whilst that at the end the correct 8m. Alas the BEGIN is not actually logged, other that as the start time elsewhere in the file, so ideally Mantid ought to trawl through the log until the run start time is passed, and only then look for the detector positions!
Most of our values like detector positions are set to “log on changeâ€, so the series of rear_det_z will be the detector moving from 4m to 6m in this case.
Steve suggest the following fix - which is to read the log to when the experiment started rather than the first entry in the log
comment:3 Changed 9 years ago by Steve Williams
- Owner changed from Steve Williams to Anders Markvardsen
- Status changed from new to assigned
comment:5 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 30 to Iteration 31
Bulk move of tickets to iteration 31 at the iteration 30 code freeze
comment:6 Changed 9 years ago by Anders Markvardsen
- Status changed from assigned to accepted
- Milestone changed from Iteration 31 to Iteration 30
comment:7 Changed 9 years ago by Anders Markvardsen
- Status changed from accepted to verify
- Resolution set to fixed
comment:8 Changed 9 years ago by Karl Palmen
- Status changed from verify to verifying
- Tester set to Karl Palmen
comment:9 Changed 9 years ago by Karl Palmen
- Status changed from verifying to closed
An examination of the code shows that the reading of the log starts at the last entry before the start time, unless all entries are after the start time when the reading starts at the first entry. This is what is required.
comment:10 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 3945
"New" tickets moved at the code freeze of iteration 29