[NeXus-committee] Proposal for NXcrystal and NXmonochromator
Koennecke Mark (PSI)
mark.koennecke at psi.ch
Tue Mar 10 12:09:13 GMT 2015
Hi,
> Am 10.03.2015 um 12:13 schrieb Eugen Wintersberger <eugen.wintersberger at desy.de>:
>
> Hi Ben
> extending NXmonochromator for soft x-rays is definitely a good idea.
> However, instead of using all this funny fields I would rather use
> Tobias's "features"-feature and define new class NXgrating.
> Then we could have three NXmonochromator related features
> 1.) NXmonochromator for Neutrons
> whatever is required here - I have no idea about Neutrons
> 2.) NXmonochromator for hard x-rays
> NXmonochromator must comprise NXcrystal, type, etc.
> 3.) NXmonochromator for soft x-rays
> NXmonochromator must comprise NXgrating, NXslit, etc.
>
> One could think about this as an application definition restricted
> to NXmonochromator ;)
>
>
Again there is a little bit of history here. NXmonochromator came about when we were discussing OO NeXus.
And it became our first NeXus OO base class: with NXmonochromator being the base class to NXcrystal and NXvelocity_selector.
To stay in line then new classes NXgrating of NXdouble_crystal would be in order to define these different types of
monochromators. I do not care if they are implemented as Tobias features or as interfaces or as new classes.
Otherwise NXmonochromator or NXcrystal would become as big as Nxdetector in order to cover all
different monochromator types.
Regards,
Mark
> regards
> Eugen
>
>
> On Tue, 2015-03-10 at 11:54 +0100, Benjamin Watts wrote:
>> Hi Eugen & Pete,
>> If you want to move the "usage" field into NXmonochromator, then
>> maybe we should rethink NXmonochromator and consider a larger
>> overhaul. We currently have the "crystal" and "velocity_selector" as
>> optional fields for hard X-rays and neutron, respectively, and I want
>> to add "grating" to that set of optional fields for the soft X-ray
>> case. For soft X-rays, the situation is actually even more complicated
>> as the geometry set by entrance and exit slits are also a fundamental
>> part of the monochromator (and the entrance slit is also optional,
>> since some beamlines simply consider the source size and position
>> stable and small enough).
>> Can you think of a better way to achieve all this? One option would be
>> to set it up so that one looks at the "usage" field first and then
>> uses its value to decide which optional fields to looks for next. This
>> would mean including values such as "grating" and "velocity_selector"
>> in the list of possibilities for the "usage" field, which would then
>> make the name "type" more appropriate.
>>
>> Cheers,
>> Ben
>>
>>
>> On 09/03/15 21:41, Eugen Wintersberger wrote:
>>
>>>> The choice of Bragg or Laue orientation is important when calculating
>>>> the rocking curve profile, whether or not the crystal is used as part of
>>>> a monochromator.
>>> I entirely agree with you here. However, this is a particular use case
>>> for a crystal in connection with a monochromator. Thus, at least in my
>>> opinion, the "usage" field belongs to NXmonochromator.
>>>
>>>> On 03/09/2015 03:14 PM, Eugen Wintersberger wrote:
>>>>> Hi Pete
>>>>>
>>>>> On Sun, 2015-03-08 at 11:48 -0500, Pete Jemian wrote:
>>>>>> Eugen:
>>>>>>
>>>>>> You propose to:
>>>>>> * rename "usage" field to "type"
>>>>> I propose to remove the "usage" field entirely from NXcrystal.
>>>>>
>>>>>> * add "channel_cut" as another possible value
>>>>> And I propose to add a "type" field to NXmonochromator. The possible
>>>>> values for "type" could be "Laue", "Bragg", "Pseudo Channel Cut", and
>>>>> "Channel Cut". Or something in this way.
>>>>>
>>>>>> As I said before, "channel_cut" is not an alternative to "Bragg" or
>>>>>> "Laue" in its description of crystal orientation. Most channel cut
>>>>>> crystals use Bragg orientation. I suggest a new field could be added to
>>>>>> describe "channel_cut". Another similar term could be
>>>>>> "pseudo_channel_cut" which describes the crystal arrangement of most
>>>>>> synchrotron X-ray monochromators.
>>>>> This would be the "type" field for NXmonochromator. It should identify
>>>>> what type of mono we talk about.
>>>>>
>>>>>> Like many things in NeXus, the field name "usage" does not seem to fit
>>>>>> so well, as you point out.
>>>>>>
>>>>>> Rather than disrupt the historical use of the "usage" field in NeXus
>>>>>> data files and however many data files have been written with this
>>>>>> field, would it be acceptable to improve the documentation for the
>>>>>> "usage" field?
>>>>> In the best case I would declare it as deprecated. At least from my
>>>>> point of view NXcrystal describes a crystal and not its particular
>>>>> application. But we can leave it there for compatibility reasons and
>>>>> declare it as deprecated.
>>>>>
>>>>> I am not sure if, what I propose, is really the best approach. But for
>>>>> the time being I have no better idea how to deal with the situation.
>>>>>
>>>>> regards
>>>>> Eugen
>>>>>
>>>>>
>>>>>> Pete
>>>>>>
>>>>>> On 3/8/2015 10:56 AM, Eugen Wintersberger wrote:
>>>>>>> Hi folks
>>>>>>> as a result of the recent discussion I would like to propose the
>>>>>>> following changes to NXcrystal:
>>>>>>>
>>>>>>> remove the "usage" field from NXcrystal
>>>>>>>
>>>>>>> It makes no sense there as the way the crystal is used in a particular
>>>>>>> application is entirely unimportant for the particular crystal itself.
>>>>>>>
>>>>>>>
>>>>>>> Furthermore I would like to suggest the following change to
>>>>>>> NXmonochromator
>>>>>>>
>>>>>>> add a "type" field to NXmonochromator
>>>>>>>
>>>>>>> This field should basically hold the values of "usage" from the current
>>>>>>> NXcrystal class. I would also suggest to have an additional possible
>>>>>>> value "channel_cut" available for this field.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Eugen
>>>>>>>
>>>> _______________________________________________
>>>> NeXus-committee mailing list
>>>> 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
>>
>> _______________________________________________
>> NeXus-committee mailing list
>> NeXus-committee at nexusformat.org
>> http://lists.nexusformat.org/mailman/listinfo/nexus-committee
>
> --
> ------------------------------------
> DI. Dr. Eugen Wintersberger
>
> FS-EC
> DESY
> Notkestrasse 85
> D-22607 Hamburg
> Germany
>
> E-Mail: eugen.wintersberger at desy.de
> Telefon: +49-40-8998-1917
> -----------------------------------
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-committee
More information about the NeXus-committee
mailing list