NIAC2012

Planning is currently underway for the NIAC / Code Camp meeting in 2012. This is being organised to take place at The Cosner’s House, Abingdon, UK and occur prior to the NOBUGS meeting.

Dates are:

Location and Accomodation

The Cosner’s House, Abingdon, UK

Science and Technology Facilities Council
The Cosener's House
Abbey Close
Abingdon
Oxfordshire
OX14 3JD
United Kingdom

The fee of £200 per event covers two nights accommodation and all meals during the days - see Logistics below

Registration is via the NOBUGS conference website

Travel

If arriving at Heathrow, take the Oxford “airline” bus, but get off at the penultimate stop St Aldates rather than Oxford bus station. Public transport to Abingdon leaves from St Aldates either Oxford bus company buses 35 or X3 or Thames travel bus X2 get off at the Vineyard or Stratton Way and walk to Coseners house

If you are arriving later and wish to take a taxi/minicab from Oxford to Coseners House, there is a taxi rank at the final Oxford “airline” stop (Gloucester Green coach station). More information about taxi/minicab servcies in Oxford are on this page.

Logistics

People arriving for the NIAC and staying on for NOBUGS conference the following week at [http://www.stfc.ac.uk/About+STFC/51.aspx| RAL] can keep their rooms in Cosner’s. Daily transport will be available to and from the NOBUGS venue at the RAL site.

The meeting fee for NIAC/Nexus code camp is the Coseners house 24 hour delegate rate, which covers Dinner, B+B, plus lunch. So:

If you will be staying Friday evening (and onwards) you need to reserve and pay for this separately yourself with Coseners house

List of Attendees

Please add your name to this table after registering for the meetings via the NOBUGS site

Name Company/Institute Code Camp (18/19) NIAC (20/21) NOBUGS (24-26) Arrival date (accommodation needed from) Departure date            
Freddie Akeroyd   ISIS Facility, Rutherford Appleton Laboratory, UK   YES   YES   YES   Day attendee   Day attendee
Tobias Richter   Diamond Light Source, UK   YES   YES   YES   Day attendee   Day attendee
Steve Cottrell   ISIS Facility, Rutherford Appleton Laboratory, UK   NO   YES   YES   Day attendee   Day attendee
Ben Watts   Swiss Light Source, Paul Scherrer Institut, Switzerland   YES   YES   NO   18/09/2012   22/09/2012
Jiro Suzuki   J-PARC, KEK, Japan   NO   YES   YES   19/09/2012    
Joachim Wuttke   JCNS at FRM II   NO   YES   YES   19/09/2012    
Mark Koennecke   Paul Scherrer Institute, Switzerland   YES   YES   YES   17/09/2012    
Jens-Uwe Hoffmann   Helmholtz-Zentrum Berlin   YES   YES   YES   18/09/2012    
Eugen Wintersberger   DESY   YES   YES   YES   17/09/2012    
Herbert J Bernstein   Dowling College, USA   NO   YES   YES (24th)   19/09/2012   21/09/2012
Fajin Yuan   Diamond Light Source   YES   YES   YES   Day attendee   Day attendee
Graeme Winter   Diamond Light Source   YES (19th)   YES (20th)   NO   Day attendee   Day attendee
David Mannicke   ANSTO   YES   YES   YES   17/09/2012   27/09/2012
Peter Peterson   SNS, ORNL, USA   NO   YES   YES   19/09/2012   27/09/2012
Armando Sole   ESRF   NO   YES   NO   19/09/2012   22/09/2012
Pete Jemian   APS   Skype   Skype   NO   2012-09-18 (Skype only, no lodgingrequired)   2012-09-21
                         

Pete Jemian's physical avatar at the meeting

Agenda

Both meetings are taking place in the Hamilton room at Coseners house, starting at 9am. Evening meal is scheduled for 7pm each day

NeXus Code Camp

The code camp allows existing NeXus developers to meet and work together on developing software or resolving particular NeXus design issues. A preliminary list of items is listed below, but the exact subset is decided on the first day of the meeting.

NIAC Meeting

This is a meeting for members of the NeXus International Advisory committee and other interested persons. It generally discusses matters of policy and strategy, but can discuss specific NeXus instrument definitions if the relevant experts are in attendance.

Meeting Minutes

Date: 20 Sept 2012

Attendees:

Motion to accept CIF-style angle descriptions with discussed additions.
Vote: for 9 against 0, abstain 4

Coffee break

AS: ESRF advocate dictionary/HDF5 and just use the few parts of NeXus they want and ignore the rest (very pragmatic view).

TR: Need to take larger view and not get tied up in technical details. need to engage with facilities using NeXus (eg ALBA).

BW: Need to emphasise community involvement - dictating standards is historical problem of creating an example to start with.

JW: What is NeXus, is it something interchangeable? Have we been truthful about what it can achieve? I have no problem in maintaining tools to convert data to whatever format the users ask for.

JH: Users want physical meaning for the data recorded, not just numbers whose meaning is obscured by instrument details. But to understand the instrument, also need more raw values.

MK: Different use cases; 1. understanding instrument (raw values), 2. exchange/data analysis (physical)

GW: Standard has value if I can read and understand a file without any further information. As soon as you move away from that, it becomes a huge problem to support the variants.

HB: Seen 2 issues; dictionary of names and format. People can use any format and you have no control anyway. The only thing you need is that every uses a common vocabulary. vocabularies tend to merge. separate vocab and application definitions.

FA: if we concentrate app defs and vocab, then we are working towards standards, tools are not required (there are plenty available). People are choosing HDF5, help them come together and talk.

GW: data rates are a problem - HDF5 are needed. Don’t want to have facility-specific dialects of NeXus. Need consistence and completeness (single file).

AS: performance issues get in the way of a single file, multiple files must be acceptable.

GW: don’t water it down - all or nothing!

EW: I tried to invent better than NeXus but failed. Users just want basic data, but beamline scientist want to record everything in order to know what the instrument is actually doing. Sometimes will need to correct for strange instrument behavior that requires info not normally needed by users. Making this general enough to use at more than one beamline quickly leads to something NeXus-like.

HB: Offer - if you can agree on your vocab, I’ll give you an IUCr working group for adopting/working on your dictionary. I.e. CIF and NeXus join forces!

JW: I support this. Clarity would help me. vocab is valuable to me, but formats are minor technical details.

EW: Important thing is to make entry to Nexus easy. Some instruments are unique and we don’t have to worry about them. OO can help us define terms.

HB: we use “prefixes” for namespaces, but are considering using general XML. want to make sure terms don’t conflict.

PJ: have image that NeXus legislates, but we should put out message that we want to collaborate to reduce conflicts.

MK: make an action that we concentrate on dictionaries and appl defs.

GW: ImageCIF has good library that does a lot of work for me. It would be easier to persuade people to use Nexus if we had the same kind of library - part of analysis work is done by the library.

HB: maintaining libraries will get done if there is adoption.

GW: If we can get Nexus routines included in CBFlib, then my work becomes much easier. analysis program writers will not resist.

Everyone agrees that moving CIF and NeXus closer would be great.

HB: CIF will make addition docs for IUCr people and will put a link to NeXus doc from the IUCr website.

MK and HB: lets arrange a meeting between NIAC and IUCr to discuss cooperation.

GW and SC: want to make sure that IUCr don’t steamroll vocabularies of other communities

MK: Can we put NAPI into maintenance mode?

PP: what is status of validation tool?

FA: GUI tool works and I have used it, waiting for colleague to finish CLI tool

FA + HB: cooperation on validation tools could be useful. NeXus backend for CBFlib validation tool is possible.

MK: break for lunch and after lunch we will try to bring the discussion to a close.

Lunch break

Motion to accept above statements.
vote: for 8, against 1, abstain 0

Motion to accept above statements.
vote: for 12, against 0, abstain 1

Motion to support above commitments.
vote for 14

Coffee break

Motion to elect HB into NIAC as the CIF representative.
vote for 14, against 0 

Motion to allow application definitions to be flat and simple (not implement the full instrument description)
vote: for 12, against 2, abstain 1.

21 Sept 2012

Motion to elect MK as Chairman
vote - for for 13, against 0, abstain 1

Motion to elect TR as Executive Secretary
vote - for for 13, against 0, abstain 1

Motion to elect FA as Technical Chair
vote - for 13, against 0, abstain 1

Motion to elect PJ as Documentation Chair (PJ notes that his travel will be very limited)
vote - for for 14, against 0, abstain 0

Motion to investigate possible technical implementations of NeXus with object oriented base classes.
vote: for 12, against 1, abstain 0

Motion to move signal and axes attributes into NXdata group attributes.
vote - for 12, against 0, abstain 2

Motion to accept as a possible solution and invite TR to present sample implementations.
vote - for 12, against 1, abstain 1

Coffee Break

FA: maybe use detector bank approach?

EW: split file drive approach would work better.

HB & MK: this is a bug in HDF5, but DECTRIS can’t wait for it to be fixed (years)

EW: are they using the most recent version; performance problems before 1.8.6

HB: they are and plan to ship with 1.8.10

Motion to work as closely as possible with this community to get this under NeXus.
vote - for all.

Motion: Changes to base classes must be ratified tech committe and put on the nexus mailing list to allow a 4 week period for objections.
vote - for 12

BW: It would be nice if we could have option items in application definitions

PP: Already can! you just set the “minimum required” attribute to zero.

Lunch Break

EW: NXlog is fine if you have single values with time stamps. how to handle detectors?

MK: You need to have a sufficiently precise timing system that all the computers have access to.

AS: Market is maturing, let’s wait and see what works in the community

PP: why not just let time be an independent variable?

MK: people will want to know which things need to be correlated.

Motion to ask tech committee to investigate possible solutions to recommend to users.
vote - for 12, against 0, abstain 1

EW: spoke to Heiner Billich: facilities should get together to make requests and pool funding - but should NeXus be part of this effort?

MK: NIAC might not be a good representative for that activity, this is beyond the scope of NIAC.

HB: Should make polite contact and say that we want HDF5 to work well - what can we do to help? What does the HDF group want the interaction with NIAC to be? NeXus should encourage the discussion.

Motion to support AS to open discussion with the HDF group on behalf of the NIAC.
vote - for 12, against 0, abstain 1

PP: we wrote application definitions to match our files, so I have some.

JW: is it working? why are there so few compliant examples?

MK: It has taken some time to solidify a base to begin testing compliance

HB: we have driving force from facilities

BW: A code camp activity could be to generate example files for a new instrument.

Promises to supply valid example files:
 - MK: 6-10
 - PP, FA: 3
 - SC: 1
 - TR: 2

Motion to confirm that the feature allowing optional fields in application definitions is endorsed by the NIAC.
vote - for all

FA: is there a way to have the presence of one tag be dependent on the presence of another? TR thinks so.

Coffee break

Motion to encourage use of these attributes, with the corrections discussed.
vote - for 12, against 0, abstain 1

Motion to set the term length to 2 years and the limit for executive officers as two terms.
vote for 11, against 0, abstain 0

Meeting End