[NeXus-committee] Proposal for NXcrystal and NXmonochromator
Eugen Wintersberger
eugen.wintersberger at desy.de
Tue Mar 10 12:59:18 GMT 2015
> >
>
> 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.
Ok - I obviously misunderstood the concept. However, there is a little
flaw. If NXmonochromator is the base class for NXcrystal and
NXvelocity_selector both of them cannot be members of NXmonochromator
(as it is currently the case). This does not work from an OO
perspective. A derived class cannot be a member of its base class.
If we want to use inheritance (instead of composition) we have to remove
NXcrystal and NXvelocity_selector from NXmonochromator to obtain the
following inheritance tree
NXmonochromator
^
|
--------------------------------------------
| |
NXcrystal NXvelocity_selector
In this case NXcrystal and NXvelocity_selector inherit all the
attributes from NXmonochromator plus their own attributes.
If we want to stick with such a scenario one could also add NXgrating
and NXchannel_cut to the tree to obtain something like
NXmonochromator
^
|
--------------------------------------------
| | | |
NXcrystal NXgrating NXchannel_cut NXvelocity_selector
But do not ask me how to make this more obvious in the manual.
> 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.
I aggree entirely with Mark that my original approach would most
probably bloat the NXmonochromator class. What about the inheritance
tree mentioned above?
regards
Eugen
>
> 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
>
--
------------------------------------
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
-----------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nexusformat.org/pipermail/nexus-committee/attachments/20150310/e100939e/attachment.sig>
More information about the NeXus-committee
mailing list