[NeXus-committee] Additions to NeXus
Benjamin Watts
benjamin.watts at psi.ch
Wed May 11 15:46:57 BST 2016
Hi Herbert & Tobias,
I was just in the middle of writing an email saying that Tobias'
method of giving a list of Stokes vectors is a better way than what
Herbert was proposing. I would also encourage providing @units="none"
when giving a relative value of the Stokes parameters where the total
intensity (1st parameter) would be 1.
Cheers,
Ben
On 11/05/16 16:41, Tobias Richter wrote:
> We have defined the stokes parameters for NXmx, but I missed porting
> that back into NXbeam.
>
> The manual says:
>
> *incident_polarisation_stokes[np, 4]*: /NX_CHAR
> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>/
>
> If there are not np values for each of the np images, it’s either an
> average or a one-off number. I’m not sure we need two fields.
>
> But getting that into NXbeam was the plan after the acceptance of
> NXmx. But tracking that is a manual thing and it got dropped.
>
> Tobias
>
> P.S. I “invented” the use of NXbeam in NXsample for NXmx, so my side
> in that discussion should be obvious.
>
>
> From: NeXus-committee <nexus-committee-bounces at nexusformat.org
> <mailto:nexus-committee-bounces at nexusformat.org>> on behalf of Herbert
> Bernstein <yayahjb at gmail.com <mailto:yayahjb at gmail.com>>
> Date: Wednesday, 11 May 2016 at 16:31
> To: Benjamin Watts <Benjamin.Watts at psi.ch <mailto:Benjamin.Watts at psi.ch>>
> Cc: "nexus-committee at nexusformat.org
> <mailto:nexus-committee at nexusformat.org>"
> <nexus-committee at nexusformat.org <mailto:nexus-committee at nexusformat.org>>
> Subject: Re: [NeXus-committee] Additions to NeXus
>
> Dear Ben,
>
> The two-component polarization has been customary in MX work for
> many years, but you are absolutely right that a full Stokes vector
> would make the most sense. I would suggest two versions:
>
> /incident_polarisation_stokes_average=[SVECI,SVECQ,SVECU,SVECV]
>
> @units="Watts/meter^2"
>
> /incident_polarisation_stokes=[STOKESI,STOKESQ,STOKESU,STOKESV]
>
> @units="Watts/meter^2"
>
> So that we can carry frame-by-frame polarization if we have it, or
> just the average if we don't.
>
>
> On Wed, May 11, 2016 at 9:09 AM, Benjamin Watts
> <benjamin.watts at psi.ch <mailto:benjamin.watts at psi.ch>> wrote:
>
> Hi Everyone,
> I'm going to agree with Eugen that it makes sense for
> NXbeam to be a child of NXsample as it implies that the beam
> is described at the position of the sample. If there are
> multiple sources as Pete described, then they can be
> differentiated by the name of the NXbeam group being "pump"
> and "probe".
>
> * It would also be useful to better specify the "polarisation
> vector" for 'incident_polarization' and 'final_polarization' -
> I don't understand what this 2-component vector is supposed to
> be. I would suggest we use a Stokes vector.
> * The 'i' and 'j' symbols seems inconsistent on
> http://download.nexusformat.org/sphinx/classes/base_classes/NXbeam.html
> Perhaps it is supposed to allow multiple incoming and outgoing
> beams, but it got messed up along the way.
>
> Cheers,
> Ben
>
>
>
> On 11/05/16 14:50, Eugen Wintersberger wrote:
>> Hi Pete
>>
>> On 05/11/16 13:33, Pete Jemian wrote:
>>> The source is definitely a part of the instrument, not something at the top
>>> level of the experiment (NXentry). Consider the case of a synchrotron X-ray
>>> experiment with a laser pump. There are two sources to be documented.
>>> They both belong under the description of the pump/probe instrument.
>>>
>>> Why should the beam be part of the sample? Makes no sense at all. The
>>> sample has no beam. The beam does not describe the sample in any useful
>>> way. NXbeam documents the state of the beam at some position along the
>>> path from source to detector. It could go in many places along the optical
>>> path.
>> Besides the fact that NXbeam is mentioned as a possible child
>> for NXsample
>> it makes perfect sense there too.
>> If you have many optical components in your beam path and one
>> is mainly interested in the
>> beam paramters in front of the sample NXbeam within NXsample
>> would be my
>> first approach to document these parameters.
>>
>> regards
>> Eugen
>>
>>
>>> Pete
>>> On May 11, 2016 6:17 AM, "Andreas Förster"<andreas.foerster at dectris.com>
>>> <mailto:andreas.foerster at dectris.com>
>>> wrote:
>>>
>>>> Dear NeXus folks,
>>>>
>>>> there was a little discussion last week about possible additions to the
>>>> NeXus standard (and NXmx) to record beam information relevant for the
>>>> estimation of dose. Herbert proposed a good solution, but the outcome of
>>>> this discussion is still pending.
>>>>
>>>> At DECTRIS, we're keen to tell our customers how to record additional
>>>> metadata in a NeXus-compliant way. That's why I'd like to have official
>>>> word on the fields below:
>>>>
>>>> Information on the synchrotron should be recorded in an NX_Source group.
>>>> Is /entry/source the right place for that?
>>>>
>>>> /entry/source *NX_SOURCE*
>>>> <http://download.nexusformat.org/sphinx/classes/base_classes/NXsource.html>
>>>> <http://download.nexusformat.org/sphinx/classes/base_classes/NXsource.html>
>>>>
>>>> o *name*: *NX_CHAR*
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>>
>>>> § Name of synchrotron
>>>>
>>>> o *@short_name*: *NX_CHAR*
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>>
>>>> § short name for source, perhaps the acronym
>>>> Data describing the beam as it hits the sample should probably go the
>>>> NX_Beam group in /entry/sample/beam. None of the fields below are
>>>> currently defined. Could these definitions be adopted?
>>>>
>>>> · /entry/sample/beam *NX_BEAM*
>>>> <http://download.nexusformat.org/sphinx/classes/base_classes/NXbeam.html>
>>>> <http://download.nexusformat.org/sphinx/classes/base_classes/NXbeam.html>
>>>>
>>>> o *name*: *NX_CHAR*
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>>
>>>> § Name of beamline
>>>>
>>>> o *total_flux/xray_flux*: *NX_FLOAT*
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-float>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-float> {units=
>>>> *NX_RATE*<http://download.nexusformat.org/sphinx/nxdl-types.html#nx-rate>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-rate>
>>>> }
>>>>
>>>> § Beam intensity (example: s-1)
>>>>
>>>> o *incident_beam_size: **NX_FLOAT*
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-float>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-float>*[2]*
>>>>
>>>> § Two-dimensional array of FWHM (if Gaussian) or diameters (if top hat)
>>>> of beam
>>>>
>>>> o *profile*: *NX_CHAR*
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>> <http://download.nexusformat.org/sphinx/nxdl-types.html#nx-char>
>>>>
>>>> § Gaussian or top hat
>>>>
>>>> Should the name of the beamline be recorded in beam or in source? For the
>>>> flux (as a rate - in contrast to the already existing flux density field
>>>> "flux"), either name is fine by me.
>>>>
>>>> I'm happy to discuss these points during the next NeXus meeting.
>>>>
>>>> Thank you and all best
>>>>
>>>>
>>>> Andreas
>>>>
>>>>
>>>>
>>>> --
>>>> <https://www.dectris.com> <https://www.dectris.com>
>>>> Andreas Förster, Ph.D.
>>>> MX Application Scientist, Scientific Sales
>>>> Phone:+41 56 500 2100 <tel:%2B41%2056%20500%202100> | Direct:+41 56 500 2176 <tel:%2B41%2056%20500%202176> | Email:
>>>> andreas.foerster at dectris.com
>>>> <mailto:andreas.foerster at dectris.com>
>>>> DECTRIS Ltd. | Taefernweg 1 | 5405 Baden-Daettwil | Switzerland |
>>>> www.dectris.com <http://www.dectris.com>
>>>>
>>>> [image: LinkedIn]<https://www.linkedin.com/company/5067919>
>>>> <https://www.linkedin.com/company/5067919>
>>>> [image: facebook]
>>>> <https://www.facebook.com/pages/Dectris-Ltd/623855944369304> <https://www.facebook.com/pages/Dectris-Ltd/623855944369304><https://twitter.com/DECTRIS_News>
>>>> <https://twitter.com/DECTRIS_News>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> NeXus-committee mailing list
>>>> NeXus-committee at nexusformat.org
>>>> <mailto:NeXus-committee at nexusformat.org>http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>>>
>>>
>>> _______________________________________________
>>> NeXus-committee mailing list
>>> NeXus-committee at nexusformat.org
>>> <mailto:NeXus-committee at nexusformat.org>http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>>
>>
>>
>> _______________________________________________
>> NeXus-committee mailing list
>> NeXus-committee at nexusformat.org
>> <mailto:NeXus-committee at nexusformat.org>http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>
>
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> <mailto:NeXus-committee at nexusformat.org>
> http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>
>
>
>
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus-committee/attachments/20160511/f02fc854/attachment.html>
More information about the NeXus-committee
mailing list