---
# System prepended metadata

title: 'Minutes of ORSO meeting on 24 April 2023 12:30 BST (13:30 Europe, 07:30 US, 21:30 Aus)'

---

# Minutes of ORSO meeting on 24 April 2023 12:30 BST (13:30 Europe, 07:30 US, 21:30 Aus)

Present: Jochen Stahn (JS), Andrew McCluskey (AM), Tom Arnold (TA), Brian Maranville (BBM), Max Skoda (MS), Bridget Murphy (BMM)
Apologies: Andrew Nelson (AN), Christy Kinane (CS)

# Agenda


## 1. Review previous minutes and assign a note taker

Minutes approved

Open Actions from previous meetings:
 
- [ ] ACTION2: CK to discuss with MS and contact a X-ray manufacturer
- [ ] ACTION_FEB1 BMM & BBM to arrange a k.o. meeting for a sub-group for Data Analysis to work on AI integration.
- [X] ACTION_FEB2 TA & BMM to write a mailshot based on ECNS poster

ARM will look into mailing list options.

- [X] ACTION_FEB3 TA, JS, MS create a poster for ECNS.
- [ ] ACTION_FEB4: BMM organize meeting between AM, BMM, JS, BBM & Daphne to start discussion w.r.t. IUCr & CIF format 
- [X] ACTION_FEB5: JS Invite Arie van der Lee to meet us 

Invited but no answer
<details>
<summary>
Discussion of CIF in email: </summary>
Glavic Artur Gregor <artur.glavic@psi.ch>
Maranville, Brian B. (Fed);NELSON, Andrew <anz@ansto.gov.au>;Stahn Jochen <jochen.stahn@psi.ch>;maximilian.skoda@stfc.ac.uk;tom.arnold@ess.eu;christy.kinane@stfc.ac.uk;murphy@physik.uni-kiel.de;andrew.mccluskey@ess.eu
Hi All,

 

I don’t really get the point why one should represent reflectivity data in CIF format. CIF is being used to represent the OUTCOME of a crystal structure determination (lattice and atom positions), not the measured data itself (at least in all files I saw). For reflectivity that would be an SLD profile or slab model.

The only positive thing about adapting an existing format is being compatible with software that exists. But to my knowledge neither data writers nor any software using CIF files have relevance for reflectivity.

 

For the format itself. I’ve written some file readers for GenX and SLDdb to get the crystal structure from CIF. The format itself is a pain to read but the main issue is the schema. Even in crystallography there seems to be no common standard to what to put in the header. Depending on the source you would fine important data like cell volume under completely different key.

 

So maybe you should ask Arie what was the reason to advocate for CIF in reflectivity and what kind of benefits they see. Maybe I’m missing something but right now it seems an effort without reword.

 

Cheers,

Artur

 

__________________________________________
Paul Scherrer Institut
Artur Gregor Glavic
WHGA/350
Forschungsstrasse 111
5232 Villigen PSI
Schweiz

Telefon: +41 56 310 46 82
E-Mail: Artur.Glavic@psi.ch

From: Maranville, Brian B. (Fed) <brian.maranville@nist.gov>
Sent: Monday, February 20, 2023 4:31 AM
To: NELSON, Andrew <anz@ansto.gov.au>; Stahn Jochen <jochen.stahn@psi.ch>; maximilian.skoda@stfc.ac.uk; Glavic Artur Gregor <artur.glavic@psi.ch>; tom.arnold@ess.eu; christy.kinane@stfc.ac.uk; murphy@physik.uni-kiel.de; andrew.mccluskey@ess.eu
Subject: Re: orso and CIF [SEC=OFFICIAL]

 

I couldn't find an example rfCIF file anywhere on the internet, or even a specification (draft or otherwise) of the format.  The announcement of the working group found in the link sent earlier in this thread is the only reference I can find to the project.

 

Having looked at CIF1 files, they have a text header with predefined names (like our ORT format) but the namespace is flattened to just key-value pairs.  I have the impression from other discussions I've had on the CIF format that it has a very rigid schema and does not allow ad-hoc extensions like the ORSO format (I'd actually prefer that we not support those in the base class definitions in ORSO, but that's a different matter)

 

Overall I don't see what we'd gain from adopting a CIF structure, unless it makes it easier for us to get manufacturers to support us.  Our header hierarchy could probably be flattened just by adding underscores for each level, though the names would get long.  Reading these files looks a bit painful, as they are not using a common serialization format so it's all pretty manual: https://github.com/quantumjockey/pycif/blob/master/pycif.py

 

From: NELSON, Andrew <anz@ansto.gov.au>
Sent: Sunday, February 19, 2023 6:03 PM
To: Stahn Jochen <jochen.stahn@psi.ch>; maximilian.skoda@stfc.ac.uk <maximilian.skoda@stfc.ac.uk>; Glavic Artur Gregor <artur.glavic@psi.ch>; tom.arnold@ess.eu <tom.arnold@ess.eu>; christy.kinane@stfc.ac.uk <christy.kinane@stfc.ac.uk>; murphy@physik.uni-kiel.de <murphy@physik.uni-kiel.de>; Maranville, Brian B. (Fed) <brian.maranville@nist.gov>; andrew.mccluskey@ess.eu <andrew.mccluskey@ess.eu>
Subject: RE: orso and CIF [SEC=OFFICIAL]

 

He contacted me several years ago about this (>10 years ago?), but it was one step too far at that point.

Here’s a relevant link: https://www.iucr.org/news/newsletter/volume-14/number-1/specular-reflexivity-data

 

What’s interesting about the list of names is that there’s representation of X-rayOFFICIAL manufacturers.

 

I don’t think spreading out into CIF, as well as ORT, as well as Nexus is a good idea. As a community we should choose one and develop that, while still being able to switch in the future. If we consider the canSAS community:

 

- sasCIF didn’t take off.

- the canSAS XML format was their initial development BUT

- I think they are now concentrating on NXcanSAS.

 

We could do a lot worse than follow in their footsteps. I think ORT is a good product for us at the moment, but it may be that NXorsoREF becomes more attractive in the future.

 

However, if a refCIF meant that X_ray manufacturers provided support, or at least joined in, then that would be nice.

 

 

 

 

 

 

From: Stahn Jochen <jochen.stahn@psi.ch>
Sent: Monday, 20 February 2023 1:00 AM
To: maximilian.skoda@stfc.ac.uk; Glavic Artur Gregor <artur.glavic@psi.ch>; tom.arnold@ess.eu; christy.kinane@stfc.ac.uk; murphy@physik.uni-kiel.de; brian.maranville@nist.gov; NELSON, Andrew <anz@ansto.gov.au>; andrew.mccluskey@ess.eu
Subject: orso and CIF

 

CAUTION, EXTERNAL EMAIL: This message has come from outside of ANSTO. Do not take action, click links or open attachments unless you trust the source of this message and know the content is safe. Report spam and phishing using the Report Message button or if unsure, forward this message to servicedesk@ansto.gov.au as an attachment.

 

 

Dear ORSO chairs and orsopy authors,

 

recently Arie van der Lee contacted Max end me and told us, he was initiating a CIF reflectivity file standard some 15 years ago. The project failed due to missing support. Now he asks us wether we plan to expand our activities towards CIF. 

Im am not sure if YAML and CIF logic are compatible - and if it is a good idea to add another representation besides our own and nexus. Could you please think about this and replay to me? 

 

Best regards, 

Jochen


Anfang der weitergeleiteten Nachricht:

Von: "A. van der Lee" <arie.van-der-lee@umontpellier.fr>
Datum: 7. Februar 2023 um 17:18:29 MEZ
An: Stahn Jochen <jochen.stahn@psi.ch>
Kopie: Maximilian.Skoda@stfc.ac.uk
Betreff: ORSO file format

﻿

Dear Jochen, dear Max,

I came across your recent 2023 paper in J. Appl. Cryst and learned about ORSO and your file format project.

I have initiated about 15 years ago a project with the same goals; see here: <https://journals.iucr.org/j/issues/2006/03/00/me0319/index.html>

The approach was, however, different, since I had in mind to use cif-syntax for the file format and the part I have done was largely based on the pdCIF dictionary. This choice was based on the fact that the techniques are rather similar in approach, and also because manufacturers of commercial diffractometers are used to work with cif-formats - I had someone from Rigaku in the group.  I have never finished the project because of a lack of motivated collaborators.

Do you have in mind to make an interface to a cif representation or would it be illogical  to have two types of dictionaries?

Best wishes, Arie van der Lee

 

--
**********************************************************************
A. van der Lee
Institut Européen des Membranes
CNRS - UMR 5635
Université de Montpellier - Case Courrier 047
Place E. Bataillon
34095 MONTPELLIER Cedex 5 - FRANCE
Tel : 33 (0) 4 67 14 91 35
**********************************************************************

vice-president of the European Crystallographic Association
member of RECIPROCS
</details>


**********************************************************************

- [X] ACTION_FEB6: BMM/TA Submit Abstract to IUCr meeting (IUCr2023 CommDat workshop)

Not submitted, no ORSO members going to the meeting.
 
## 2. Reports from each working group
 
### Education & Outreach

* Report on ECNS
* Web page update: Would like to modify the front page of the web page to highlight activities. ACTION set up meeting to update webpage.
* Constitution update
Link to github.

* AGM 
date for AGM
will include presentation from Frank Schreiber's group.
Need to make better link with Linus/Frank ACTION MS


###  Data Formats
- Issue for implementing orsopy in Mantid. Mantid want to use **only** conda and therefore no PyPI. But currently, orsopy is only on PyPI, therefore we need a condaforge release of orsopy.
ACTION AN will make a conda-forge recipe for orsopy
- Simple example usage docs: TA will initiate feedback from JPARC
- request for formalization of lookup paths for e.g. wavelength, incident angle (whether it is in column or header): ACTION JS and BBM to decide. 
- ACTION BBM to create examples for Nexus usage and distribute for discussion at next meeting.


###  Reproducibility
- LENS working group 4 interested in data sets for benchmarking (with an interest towards machine learning, something something). 
ACTION ARM to discuss standard sample box with Andrew Caruana when at ISIS in two weeks time. 
- need to resurect round-robin sample
ACTION AN to chase SNS-ORNL?


### Data Analysis

Nothing to report!

## 3. AOB

Date of next meeting 5th June
at 12:30 UK time. (13:30 Europe, 07:30 US, 21:30 Aus)
