[NeXus-committee] Proposal for NXcrystal and NXmonochromator
Benjamin Watts
benjamin.watts at psi.ch
Tue Mar 10 12:30:34 GMT 2015
Yes, the "features" approach has to prove itself fully feasible before
we can rely on it. Also, we just ratified an NXgrating definition:
https://github.com/nexusformat/definitions/blob/master/base_classes/NXgrating.nxdl.xml
I just haven't updated NXmonochromator to include it as an option yet.
Cheers,
Ben
On 10/03/15 13:13, Pete Jemian wrote:
>
> 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
> <mailto:mark.koennecke at psi.ch>> wrote:
>
>
> Hi,
>
>
>
> > Am 10.03.2015 um 12:13 schrieb Eugen Wintersberger
> <eugen.wintersberger at desy.de <mailto: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
> <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
> >
> > --
> > ------------------------------------
> > DI. Dr. Eugen Wintersberger
> >
> > FS-EC
> > DESY
> > Notkestrasse 85
> > D-22607 Hamburg
> > Germany
> >
> > E-Mail: eugen.wintersberger at desy.de
> <mailto:eugen.wintersberger at desy.de>
> > Telefon: +49-40-8998-1917 <tel:%2B49-40-8998-1917>
> > -----------------------------------
> > _______________________________________________
> > 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/20150310/d837a8ba/attachment.html>
More information about the NeXus-committee
mailing list