[ESSSPECTROSCOPY] Update BIFROST NeXus loader for angles - #671
Conversation
|
Should I add test data for this? It would be a fairly large file with bogus data. So it wouldn't be useful beyond testing this loader. |
| with open_component_group( | ||
| NeXusLocationSpec(filename=file_spec.value), | ||
| nx_class=snx.NXparameters, | ||
| parent_class=snx.NXentry, | ||
| ) as group: | ||
| return group[param_name][()]['value'] |
There was a problem hiding this comment.
So McStas stores this differently than PROD?
There was a problem hiding this comment.
The McStas files that Greg made have an NXparameters group which doesn't exist in prod because it holds simulation params. The handling of nested value groups in the prod loader can load those data from mcstas files. Unfortunately, the sample stack does not exist in mcstas files. But the instrument angle can be loaded. So I could remove its special handler for mcstas. Should I?
| if isinstance(log['value'], snx.Group): | ||
| # The NXlog is nested in this group, e.g., the group can be an NXpositioner | ||
| # with children 'value', 'target_value', etc. | ||
| transform: snx.nxtransformations.Transform = log['value'][()] # type: ignore[assignment] |
There was a problem hiding this comment.
Still trying to understand whether this kind of nesting is a bug/bad and should be reported. Have had issues with this elsewhere. But no action here, as I presume it is necessary to make it work now.
There was a problem hiding this comment.
Yes, it wouldn't work otherwise.
b690076 to
db2d8bf
Compare
The integration tests are failing because of this. It looks like the CODA files encode the angles we need.
I am unhappy with relying on group names this much but I don't see a better alternative given that there are no unique NeXus classes to look for.