[NeXus-committee] Proposal for NXcrystal and NXmonochromator

Eugen Wintersberger eugen.wintersberger at desy.de
Tue Mar 10 14:23:26 GMT 2015


Hi Mark


> > 
> >      NXmonochromator
> >                            ^
> >                            |
> >       --------------------------------------------
> >       |                                          |
> >    NXcrystal                                 NXvelocity_selector
> > 
> > 
> 
> 
> This is what I meant...
> 

Uff - finally  I go it ;)


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

I will make some suggestions on the Wiki. 

regards 
Eugen

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

-- 
------------------------------------
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/4e063982/attachment.sig>


More information about the NeXus-committee mailing list