[NeXus-tech] Telco Summary

[Wintersberger, Eugen]

Hi folks 
first I have to apologize for not attending the Telco. We had visitors
from the ALS. Had to do some advertising for Nexus (though I am not sure
how successful I was ;)). 

On Thu, 2014-01-23 at 16:25 +0100, Mark Koennecke wrote: 
> ============================
> NeXus Telco Summary Week 04/2014
> ============================
> 
> 
> Publications
> ===============
> 
> In the run up to the teleconference Herbert and I briefly
> discussed a new publication to be written for NeXus. The last
> referrable one is from 2005. Options include:
> - If we have a PX application definition, there definitly should be
>    an article in Acta Cryst.
> - Otherwise Herbert suggested to use Review of Scientific Instruments
> To be continued. Any further options anyone? Journal of Instruments
> and Methods comes to my mind.

What ever you want to do - go ahead ;) 

> 
> 
> 
> AXIS Type for Fields
> =======================
> 
> This is about assigning a type to an SDS such that the presence of
> certain attributes can be validated. The use case is the axis type
> which needs to have the transformation_type, vector, offset and
> depends_on attributes.
> 
> Freddie suggested to denote axis in NXDL rather with the tag
> <axis> </axis> rather then <field type="axis"</field>. To be
> verified with Pete Jemian.

I definitely prefer the <field type="axis"> version. Technically an axis
is nothing else than a field with additional mandatory attributes. And
it is easy to manage this in any XML parser. <field type="axis"> tells
me exactly what I am dealing with - a field which requires particular
attributes. If there is only a tag <axis></axis> I have to implicitly
know that this is a field. 

> 
> PX Application Definition
> ===========================
> 
> The rest of the time was spent on discussing the PX application definition.
> The first topic were the pose:NXcollection groups. They deviate from
> the normal NeXus usage. The meaning of them is to contain a list of axes
> to position the component. For PX two are needed: to position the detector
> and to position the sample. There is aggreement that this information 
> needs to
> be stored.
> 
> We settled for storing the axes for the sample in a NXgoniometer group,
> the ones for the detector in the detector group.

This is definitely a better place than an instance of NXcollection. 

> 
> 
> Next we went through Tobias list of issues about the PX definition:
> 
> Check that arrays are not flipped or rotated
>     This is about storage order of arrays. Turned out to be
>     very difficult to test without equipment requiring this feature.
>     Postponed.
> 
> Graeme will go through a test cycle which involves converting CBGF files
> to NeXus and back again to CIF. Those will then be processed. If this works
> we have proven that our NeXus application definition for PX is coomplete 
> enough.

Sounds good to me.

> 
> 
> Offset conflict
> ===================
> 
> Something I noted on the Telco but did not mention because I did not 
> want to
> open a new topic: we have a conflict about the offset attribute for fields
> in NeXus. There are two meanings:
> - offset is Rank values of offsets to use for each dimension if the data is
>    not in C storage order. Of type NX_INT. This at design#attributes
> - In the discussion on NeXus coordinate systems offset means: 3 float
>    components to describe a translation to be applied before applying 
> the operation
>    of the real axis.
> Obviously this must be resolved. We agreed to rename the offset for data 
> not in C
> storage order to data_offset.

I can life with this :D

> 
> 
> 
> 
> Topics Still Pending
> =======================
> 
> Variants and ESD
> -------------------
> 
> Many people at the Telco liked Pete Jemians idea about specifying the
> names of error fields in an attribute. Concerning variants a mix of the
> different proposals was preferred. Tobias will provide an example
> file with an implementation for us to look at and discuss again.
> 
> Still pending.

Sounds good to me. In general, I think, we should use attributes much
more extensively for adding semantics or additional information to
fields rather than encoding this in the name of the field. To my opinion
this gives us more freedoms for further extensions of the standard.

> 
> 
> NXpinhole and NXslit
> -----------------------
> 
> Tobias clarifies a point on this with Eugen and will prepare for voting 
> when
> there is time available.

Great to hear that. If anyone has any objectives with NXslit and
NXpinhole please let me know. 

> 
> 
> Eugens Proposal on Non Standard Fields
> -----------------------------------------
> 
> What to we do with it?

I guess the major issue with this proposal was, as Tobias pointed out,
that it can cause problems with axis and their geometric dependencies.

@Tobias: I hope I go this right ...

I worked on this proposal with Ben and Jonathan and I guess the best
would be if we three put our heads together and think about this again. 
Hopefully we can provide a solution to this problem.

However, I want to mention that we should not take the problem of
non-standard fields lightly. I stumble upon them every day here at DESY.
For us 2014 is THE NEXUS YEAR. If everything goes well most of our
beamlines will produce Nexus files when we are back in user operation in
spring 2015.

> 
> 
> NeXus Interfaces
> --------------------
> 
> Do we want this? To be discussed later in 2014 when PX is done with.

Good idea. 

> 
> 
> Next Telcos
> ============
> 
> The next Telco is aimed for february, 5. We aim for a joint Telco together
> with COMCIF in week 9; february 24-28 .

I most probably cannot attend the conference at 5th since I am at the
ESRF for an experiment.

Regards
Eugen

> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20140123/ddce9d0f/attachment.sig>