Ticket #380 (closed: fixed)

Opened 12 years ago

Last modified 5 years ago

Concept: How do we handle indirect flight path instruments

Reported by: Nick Draper Owned by: Nick Draper
Priority: trivial Milestone: Pilot
Component: Keywords:
Cc: Blocked By:
Blocking: Tester:

Description

Currently some of our algorithms assume a hard coded flight path.

  • ConvertUnits
  • CorrectForAttenuation
  • any others?

Indirect instruments follow a more variable flight path with more components. The use of the geometry need to take this into account.

How?

Possibly encode Flight path into instrument file

<Monitor flight path>

<Source/>
<detector/>

</Monitor flight path>
<Detector flight path>

<Source/>
<Samplepos/>
<Monochromator/>
<detector/>

</Detector flight path>

This would help with L1 and L2, but what about angles?

Change History

comment:1 Changed 12 years ago by Nick Draper

  • Milestone changed from Iteration 15 to Iteration 16

comment:2 Changed 12 years ago by Nick Draper

  • Priority changed from major to trivial

Moved to trivial priority by Scientific Steering Committee 20/02/2009

comment:3 Changed 11 years ago by Nick Draper

  • Milestone changed from Iteration 16 to Unassigned

comment:4 Changed 11 years ago by Nick Draper

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

comment:5 Changed 11 years ago by Nick Draper

  • Milestone changed from Unassigned to Pilot

comment:6 Changed 5 years ago by Stuart Campbell

This ticket has been transferred to github issue ​1228

Note: See TracTickets for help on using tickets.