[NeXus-tech] Dealing with start and end positions per scan point
Herbert J. Bernstein
yayahjb at gmail.com
Wed May 27 14:44:04 BST 2015
Dear Andreas,
I think we started there and some people objected to it. I will be
happy to add a summary tag, but, depending on how discussions go, it
may not end up as part of the official NeXus standard.
That being said, I think, in these days of ultrafine slicing we need
information on the oscillation angle range both image by image and for
the whole set of images. I was just talking to Bob Sweet about this,
and what I would suggest is two new tags:
GONIOMETER_PHI_range_average which would be the average of the
magnitudes of the differences between GONIOMETER_PHI and
GONIOMETER_PHI_end values
and
GONIOMETER_PHI_range_total which would be a two element array, with
the min and max of the GONIOMETER_PHI and GONIOMETER_PHI_end values.
The code for this is actually a little tricky to avoid getting fooled
if you cross 0 or 360, but I should have something reasonable for you
to look at by tomorrow.
Regards,
Herbert
On Wed, May 27, 2015 at 12:54 AM, Andreas Förster
<andreas.foerster at dectris.com> wrote:
> Dear all,
>
> this sounds good and rather clear. In addition, what about giving the user
> the option of noting an average value of GONIOMETER_PHI, e.g.
> GONIOMETER_PHI_RANGE, just as a tool to accelerate processing. This average
> value would obviously be a simplification and not contain all the
> information of the individual start/end points, but it's what's needed for
> data integration. Users would like it.
>
> Best.
>
>
> Andreas
>
>
>
> On Tue, May 26, 2015 at 10:12 PM, <Mark.Basham at diamond.ac.uk> wrote:
>>
>> Sounds good to me.
>>
>> Cheers
>>
>> Mark
>> ________________________________________
>> From: Herbert J. Bernstein [yayahjb at gmail.com]
>> Sent: 26 May 2015 21:09
>> To: Basham, Mark (DLSLtd,RAL,LSCI)
>> Cc: NeXus Technical sub-committee list; Andreas Förster; Robert Sweet;
>> Richter, Tobias (ESS,RAL,LSCI); Mark Koennecke; Graeme Winter
>> Subject: Re: Dealing with start and end positions per scan point
>>
>> Dear Mark,
>>
>> I am not sure whether it matters to most end users if they have the
>> end or the delta, but it is important that we use a term which clearly
>> indicates what it is that we are using, so that people don't get
>> confused. It is rare to find an end user who reads the documentation.
>>
>> Does anybody object to the use of "_end"?
>>
>> Regards,
>> Herbert
>>
>> On Tue, May 26, 2015 at 3:20 PM, <Mark.Basham at diamond.ac.uk> wrote:
>> > Hi Herbert,
>> >
>> > Sorry I misunderstood NXtransforms, I thought they pointed to a
>> > NXpositioner, hence my suggestion.
>> >
>> > Seeing your example I understand how this should work, and I'm happy
>> > with that format (Although possibly the NXtransformations description needs
>> > some more work)
>> >
>> > entry:NXentry
>> > sample:NXsample
>> > goniometer:NXtransforms
>> > GONIOMETER_PHI=[0,0.5,1.,1,5]
>> > @end_point="/entry/sample/goniometer/GONIOMETER_PHI_end"
>> > ... other attributes
>> > GONIOMETER_PHI_end=[0.5,1.,1.5,2.]
>> > @start_point=/entry/sample/goniometer/GONIOMETER_PHI
>> >
>> > I don't know if this lends itself better to a
>> > GONIOMETER_PHI_span/increment as its more obviously a axillary dataset? and
>> > was this what Dectris wanted/prefered?
>> >
>> > Cheers
>> >
>> > Mark
>> >
>> > ________________________________________
>> > From: Herbert J. Bernstein [yayahjb at gmail.com]
>> > Sent: 26 May 2015 16:41
>> > To: Basham, Mark (DLSLtd,RAL,LSCI)
>> > Cc: NeXus Technical sub-committee list; Andreas Förster; Robert Sweet;
>> > Richter, Tobias (ESS,RAL,LSCI); Mark Koennecke; Graeme Winter
>> > Subject: Re: Dealing with start and end positions per scan point
>> >
>> > Dear Colleagues,
>> >
>> > Moving to back NXpositioner from NXtransformations would be a major
>> > change for NXmx at this point, but more importantly I don't see how to
>> > connect this to the goniometer axes in an MX experiment. A detailed
>> > example might be helpful.
>> >
>> > However, that being said, Mark has a point about the _end version of
>> > an axis not being properly associated with the original version of the
>> > axis, so that I would suggest is that we add an attribute to the
>> > original to point to the data with the end points, and a backpointer
>> > with the end points to make it
>> > clear where the start points are located
>> >
>> > entry:NXentry
>> > sample:NXsample
>> > goniometer:NXtransforms
>> > GONIOMETER_PHI=[0,0.5,1.,1,5]
>> > @end_point="/entry/sample/goniometer/GONIOMETER_PHI_end"
>> > ... other attributes
>> > GONIOMETER_PHI_end=[0.5,1.,1.5,2.]
>> > @start_point=/entry/sample/goniometer/GONIOMETER_PHI
>> >
>> > I would suggest _not_ giving GONIOMETER_PHI_end any of the axis
>> > positioner attributes, such as @vector, @offset, etc., so it is clear
>> > that it is just an auxiliary array of data, not a second axis.
>> >
>> > Would this address the concern?
>> >
>> > Regards,
>> > Herbert
>> >
>> >
>> >
>> > On Tue, May 26, 2015 at 11:03 AM, <Mark.Basham at diamond.ac.uk> wrote:
>> >> Dear All,
>> >>
>> >>
>> >>
>> >> So with the requirement for the range of travel of a given axis to be
>> >> included in the format, after a conversation with Graeme, I think the
>> >> suggestion from Herbert is exactly what we came up with, in that the only
>> >> way to fully capture the data is with 2 points per scan point. As Herbert
>> >> said:
>> >>
>> >>
>> >> “””
>> >>
>> >> For any given axis setting let as assume that the value given for that
>> >> axis, e.g. "GONIOMETER_PHI" will always be the settings at which
>> >>
>> >> the collection of data for each frame starts. Shall we then use the
>> >>
>> >> suffix "_end" for the settings at which the collection of data for each
>> >> frame ends, e.g. "GONIOMETER_PHI_end" ?
>> >>
>> >> “””
>> >>
>> >>
>> >>
>> >> This however would suggest a separate positioner for the end points,
>> >> which I don't think is the best way to do this, I would suggest making use
>> >> of the fields inside NXpositioner to manage the end points.
>> >>
>> >>
>> >>
>> >> So in the description, all the motors should be defined by
>> >> NXpositioners, and in here the position will be recorded in ‘value’, now we
>> >> could introduce a "value_end" parameter, but this seems at odds to
>> >> "raw_value" and "target_value".
>> >>
>> >>
>> >> So my suggestions are as follows
>> >>
>> >> 1) add a "end_value" or "range_value" to NXpositioner (or whatever to
>> >> show the region covered)
>> >>
>> >> 2) make a version 1.1 of NXpositioner with:
>> >>
>> >> "raw_value" -> "value_raw"
>> >>
>> >> "target_value" -> "value_target"
>> >>
>> >> "target_end" or "target_range"
>> >>
>> >>
>> >>
>> >> 2 is clearly more work, but could be more consistent, especially with
>> >> "soft_limit_max" and "soft_limit_min" being in the same class (and I seem to
>> >> remember from the meeting in December we wanted to make things postfixes as
>> >> Herbert suggested for clarity)
>> >>
>> >>
>> >> What do people think?
>> >>
>> >>
>> >> Cheers
>> >>
>> >>
>> >> Mark
>> >>
>> >>
>> >>
>> >>
>> >> Dr Mark Basham,
>> >> mark.basham at diamond.ac.uk<mailto:mark.basham at diamond.ac.uk> Tel: +44 1235
>> >> 778853
>> >> Senior Software Scientist,
>> >> www.diamond.ac.uk<http://www.diamond.ac.uk/>
>> >> Diamond Light Source, Chilton, Didcot, Oxon, OX11 0DE, U.K.
>> >>
>> >>
>> >> --
>> >> This e-mail and any attachments may contain confidential, copyright and
>> >> or privileged material, and are for the use of the intended addressee only.
>> >> If you are not the intended addressee or an authorised recipient of the
>> >> addressee please notify us of receipt by returning the e-mail and do not
>> >> use, copy, retain, distribute or disclose the information in or attached to
>> >> the e-mail.
>> >> Any opinions expressed within this e-mail are those of the individual
>> >> and not necessarily of Diamond Light Source Ltd.
>> >> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>> >> attachments are free from viruses and we cannot accept liability for any
>> >> damage which you may sustain as a result of software viruses which may be
>> >> transmitted in or with the message.
>> >> Diamond Light Source Limited (company no. 4375679). Registered in
>> >> England and Wales with its registered office at Diamond House, Harwell
>> >> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>> >>
>
>
>
>
> --
> **************************************************
> Andreas Förster, PhD
> Application Scientist MX
>
> DECTRIS Ltd.
> Neuenhoferstr. 107
> 5400 Baden
> Switzerland
>
> +41 56 500 2100 general
> +41 56 500 2101 fax
> +41 56 500 2176 direct
> andreas.foerster at dectris.com
> www.dectris.com
>
> Don´t miss the latest developments,
> subscribe to the DECTRIS eNewsletter
> **************************************************
>
>
> Confidentiality Note
> This message is intended only for the use of the named recipient(s)
> and may contain confidential and/or privileged information. If you are
> not the intended recipient, please contact the sender and delete the
> message. Any unauthorized use of the information contained in this
> message is prohibited.
More information about the NeXus-tech
mailing list