[NeXus-committee] Proposal for NXcrystal and NXmonochromator

Koennecke Mark (PSI) mark.koennecke at psi.ch
Tue Mar 10 13:28:08 GMT 2015 

Eugen,

Am 10.03.2015 um 13:59 schrieb Eugen Wintersberger <eugen.wintersberger at desy.de<mailto:eugen.wintersberger at desy.de>>:



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


This is what I meant...


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.



This is too what I think is correct. But NeXus never went down the OO route. So, in principle, we are
free to do what needs to be done: additional classes for the new special monochromators.

Regards,

     Mark



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<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
-----------------------------------
_______________________________________________
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
-----------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus-committee/attachments/20150310/ad50ea72/attachment.html>

More information about the NeXus-committee mailing list