-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve and simplify loading of transformation chains #243
Conversation
This reverts commit 433e17e.
transformations
modulee3b4a18
to
048e3ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I must say I didn't follow all the code changes, but the tests look fine ;-)
""" | ||
Represents a depends_on reference in a NeXus file. | ||
|
||
The parent (the full path within the NeXus file) is stored, as the value may be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are parents always guaranteed to be absolute or could they also be relative?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class does not check this on init, but in our code it comes from dataset.parent.name
, and in h5py
name
gives the full absolute path.
value: sc.Variable | sc.DataArray, | ||
*, | ||
transformation_type: str, | ||
select: ScippIndex, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this select
actually never used in the old function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, never used, because it was unclear what to do with potential time selection. Also, since the selection was already applied when loading the underlying group or dataset it made little sense, unless the plan was to apply it to the entire chain, which maybe was the original idea? So maybe it should be considered to forward select
when resolving a chain? But I think such a mechanism will be useless 90% of the time, since each chain link can have different length, etc., ...
raise TransformationError('A transformation needs a vector attribute.') | ||
return sc.vector(value=self.attrs.get('vector')) | ||
|
||
def __getitem__(self, select: ScippIndex): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I managed to follow where the select
logic was moved. Is is simply that we are not performing any selection on a time-dependent transformation anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can, since it is applied when loading the NXlog, before maybe_transformation
builds a transformation from it. See also above though.
Co-authored-by: Neil Vaytet <[email protected]>
Co-authored-by: Neil Vaytet <[email protected]>
See docstring in
nxtransformations.py
for an explanation.I have added
class DependsOn
which seems a much saner way to handle the references, instead of juggling absolute and relative paths. The subclassTransformationChain
additionally hold the chain of transformations starting at the depends_on.Fixes #234 by introducing a new mechanism that can work around the shortcomings of the default data load. See there also for larger context.
Technically this represents a breaking change, since users would have to call
build()
after loading groups with transformations. In practice this is however typically not accessed directly — users typically usesnx.compute_positions
instead of working with the raw chains.