[NeXus-committee] Proposal for NXcrystal and NXmonochromator

Tue Mar 10 12:13:09 GMT 2015

Until we ratify the proposed "features" or "interfaces", any new classes
should be implemented using NXDL.
On Mar 10, 2015 7:09 AM, "Koennecke Mark (PSI)" <mark.koennecke at psi.ch>
wrote:

>
> 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
>
>
> _______________________________________________
> 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/20150310/88572a5f/attachment.html>