[NeXus-tech] Summary of last telco

[Wintersberger, Eugen]

Hi all
  I finished NXslit and NXpinhole last week and sent a mail on Wednesday
with a request for looking at it to this mailing list (just if I got the
new geometry concept right). 
I attached also a new DESY Nexus file to the mail (with powder data) to
show the current state of Nexus at DESY beamlines. Unfortunately, it
turned out that the file was to big so I got a bounce message from this
list including an 'awaits for approval' message. However, the mail never
got approved ;)

So, for NXslit and NXpinhole please have a look to the Nexus Wiki. 

regards
Eugen

On Tue, 2013-10-22 at 13:56 +0200, Mark Koennecke wrote: 
> Hi,
> 
> I made a little summary of what we were up to on the last telco.
> To keep us on track. I hope I did not miss something important.
> 
> Hear you tomorrow,
> 
>               Mark
> 
> NeXus Telco Summary, Week 41
> ==============================
> 
> Main topic: requirements of MX
> 
> 1) Coordinate frame (done)
> 2) SI Units, can be specified in application definition
> 3) Missing feature: standard way to detail standard error:
>     Suggestion: append _esd to data name.
> 4) variants, still open
> 5) Structure of beam etc. May  be missing fields, easy
> 6) Rotation axes. This kicked off a discussion on NXgoniometer.
>     Which is essentially a collection of axes. What was felt missing
>     was a way to give a field a type. NeXus knows types up to now
>     only for classes. A type for a field would mean that certain
>     attributes must be present. For examples for an axes: 
> transformation_type,
>     vector, offset, depends_on and some.
> 
>     There was some understanding that this field type should be a
>     separate attribute, like NX_class.
> 
>     The idea of an axes class came up and was rejected (temporarily)
>     for two reasons:
>     - The transformation_type, vector,... attribute scheme has been
>       decided upon
>     - A common criticism of NeXus is that there is to much hierarchy. An
>      NXaxis group would increase this.
> 
>     It was felt that this is a bigger thing. To let sink in  a bit and
>     discuss at the next Telco
> 7) Detector orientation and such: covered, additional fields may be needed
> 8) Image masks: covered with the DECTRIS work
> 9) some more additional fields
> 
> Other pending issues:
> 
> 
> NXgoniometer
> -------------
> 
> Is ready for suggestiona and voting pending the resolution of the
> field type axis issue mentioned above. As NXgoniomter is just a
> collection of axes and a depends_on field and may be some stuff like
> name etc.
> 
> 
> Variants
> ------------
> 
> Different versions of fields, may be updated after a refinement.
> We more or less ditched the approaches:
> - Having an NXsubentry because it requires populating a whole
>    hierarchy with links
> - NXvariant group, holding only variants of some fields. Deemed to
>    complicated
> 
> The most popular approach appeared to be some form of appending
> _variant to field names. Or, if there is more then one variant:
> _variant_somename, _variant_someothername. It is still unclear
> how this is to be used. IMHO, the latest stance on this was to
> update the actual value with the best one and store the old one
> in a variant. There was agreement that time_stamps ought to be added
> to affected fields and variants.
> 
> Polarisation
> -----------------
> 
> Current polarisation fields in NeXus reflect neutron use cases.
> Needs enhancement for X-rays. Waiting for an expert to make
> suggestions.
> 
> NXaperture
> -------------
> 
> Eugen trying to reformulate this.
> 
> 
> NXslit and NXpinhole
> -----------------------
> 
> Check again.
> 
> FEL
> --------
> 
> Herbert argued for two more detector parameters in order to cober the
> FEL case. This was not principally opposed but Herbert was tasked to
> provide a little description what this is for. For us to understand
> what we agree too.
> 
> 
> Missing
> ------------
> 
> I am feeling like I missed something important in this summary.
> But seem not to remember it. Someone to help out?
> 
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech

-------------- 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/mailman/private/nexus-tech/attachments/20131022/4d2b8d0b/attachment.sig>