Extend usefulness of <locations> tag

[Anders Markvardsen]

The locations tag cannot be used for the case of describing e.g. MERLIN or IN5 where you may want to step over theta but at the same time what to simitanious rotate the axis by an equivalent.

e.g you want to be able to do

<locations t="1.0" t-end="4.0" n-elements="4" name="det" rot=1.0 rot-end=4.0 x-axis=0 y-axis=1 z-axis=0 />

which will be equivalent to

<location t="1.0" name="det1" rot=1.0 x-axis=0 y-axis=1 z-axis=0 />
<location t="2.0" name="det1" rot=2.0 x-axis=0 y-axis=1 z-axis=0 />
<location t="3.0" name="det1" rot=3.0 x-axis=0 y-axis=1 z-axis=0 />
<location t="4.0" name="det1" rot=4.0 x-axis=0 y-axis=1 z-axis=0 />

The above example illustrate a cylindrical distribution of pixels. Note the above cannot be achieved with using the <facing> tag.

In this ticket extend <locations> to allow for the above

[Owen Arnold]

Not sure that I understand what we currently can and can't do. Could you add a sketch for the geometries your are trying to describe to this ticket with the new syntax.

[Arturs Bekasovs]

Another real-world example where this might be useful is MUSR definition:

  <type name="ring-front">
    <component type="pixel">
    <location r="0.14" t="90" p="309.375000" rot="309.375000" name="det33"/>    
    <location r="0.14" t="90" p="298.125000" rot="298.125000" name="det34"/>
    <location r="0.14" t="90" p="286.875000" rot="286.875000" name="det35"/>
    ... more lines ...
    <location r="0.14" t="90" p="28.125000" rot="28.125000" name="det58"/>
    <location r="0.14" t="90" p="16.875000" rot="16.875000" name="det59"/>
    <location r="0.14" t="90" p="5.625000" rot="5.625000" name="det60"/>
    <location r="0.14" t="90" p="354.375000" rot="354.375000" name="det61"/>
    <location r="0.14" t="90" p="343.125000" rot="343.125000" name="det62"/>
    <location r="0.14" t="90" p="331.875000" rot="331.875000" name="det63"/>
    <location r="0.14" t="90" p="320.625000" rot="320.625000" name="det64"/>
    </component>    
  </type>  

This might be replaced with much shorter (and consequently less error-prone):

  <type name="ring-front">
    <component type="pixel">
      <locations r="0.14" t="90" p="309.375000" p-end="5.625000" rot="309.375000" rot-end="5.625000" name="det" n-elements="28" name-count-start="33"/>
      <locations r="0.14" t="90" p="354.375000" p-end="320.625000" rot="354.375000" rot-end="320.625000" name="det" n-elements="4" name-count-start="61"/>
    </component>
  </type>  

EMU has similar structure as well.

[Arturs Bekasovs]

I think it might be a good idea to make this think general, i.e. we can have corresponding -end attribute for all of [r,t,p,x,y,z,rot]. If attribute has corresponding -end, it will be increasing/decreasing, othewrise it will be static. This will allow for potential short-cuts for other types of linear/spherical detector alignment.

[Arturs Bekasovs]

Refs #9136. IDF for testing new locations functionality

Changeset: f9e5ab757168f2222a5e832d11ca976e6a1bb43b

[Arturs Bekasovs]

Refs #9136. Initial test for the new locations functionality

Changeset: b913acf87058ee57525f6085a4788e82f252a383

[Arturs Bekasovs]

Refs #9136. Leave only basic functionality of the locations parsing

All the range code should be written from scratch, it is assuming that we should have only one -end tag all over the place.

Temporarily skipping real test for now.

Changeset: 6c4dfb3348e5903f15506da91aa40083b82d7be9

[Arturs Bekasovs]

Refs #9136. Implement proper naming and test for it

Plus made it easier to test various locations combinations by creating IDF template and inserting <locations> tags on-the-fly

Changeset: c352861116b08e46cd115c26a21913fe6331a448

[Arturs Bekasovs]

Refs #9136. Code for copying static attributes and test for it

Changeset: c18b9f2502dbe7ed6a27cd46a6275f905d277ee9

[Arturs Bekasovs]

Refs #9136. Range functionality and tests for it

Changeset: 2503548293303ed8afcec4ddceb31e0c7d7cae05

[Arturs Bekasovs]

Refs #9136. Removed obsolete method

Changeset: 382617ebb7f830f56a383cd89640ce65572d245d

[Arturs Bekasovs]

Refs #9136. Better error handling and tests for it

Changeset: 268448ce7e559c43dc78440d3e4031560397a91f

[Arturs Bekasovs]

Refs #9136. Removed TODO - tried it, doesn't make them much faster

Changeset: 7b625564310c1b3732cbffcd1dd80871bd8c338c

[Arturs Bekasovs]

Refs #9136. Tests for rotation and fix attribute naming

Changeset: 6cad502c3ab35707d18ed5e8482b6e90e2d0199a

[Arturs Bekasovs]

Refs #9136. Test for *-end attribute without starting * attribute

Changeset: b426ee3488f20092cd4f3260b7220072a37ebd51

[Arturs Bekasovs]

Refs #9136. Handle the case with n-elements < 0 correctly

Changeset: ed2e2b02f634e00a403f88ed6e8376271b87ced3

[Arturs Bekasovs]

Tester:

Verify that new functionality is covered by unit tests well enough and that system tests are passing.

Running "grep -l '<locations' *" in instrument folder returned the following list of IDFs which use locations tag:

LARMOR_Definition.xml
LET_Definition_dr2to9.xml
LET_Definition.xml
MERLIN_Definition.xml
POLDI_Definition_2013.xml
SANS2D_Definition_tubes.xml

Using LoadEmptyInstrument algorithm load these and verify that instruments look the way they should. I wasn't able to get anything out of POLDI_Definition_2013.xml myself, but neither I was able to do so before the changes.

Then do the same for attached IDF. Try to experiment with it, changing attributes of the <locations> tag (or adding more of these tags) and check that you get what you expect.

Verify that <locations> description at http://www.mantidproject.org/IDF was updated accordingly.

[Arturs Bekasovs]

Updated the wiki documentation.

changeset

[Anders Markvardsen]

Merge remote-tracking branch 'origin/feature/9136_extend_locations_tag'

Full changeset: ​f42ab3adae92633c3503246c49f9724fe871f8f7

[Anders Markvardsen]

Tested on various examples. Note updated the wiki - mainly with some typos

[Stuart Campbell]

This ticket has been transferred to github issue ​9979