Support preopening NeXus files

scipp / essreduce

Common functionality for ESS data reduction

https://scipp.github.io/essreduce/

BSD 3-Clause "New" or "Revised" License

1 stars 1 forks source link

Support preopening NeXus files #86

Closed SimonHeybrock closed 2 months ago

SimonHeybrock commented 2 months ago

This is not strictly required by anything right now, but I needed it for some testing, so a cleaned it up for the future.

Changes:

Be more relaxed about passing definitions for open groups.
Add flag to optionally open NeXus files. This may become more relevant in the future when loading even more different parts and/or chunks from files.

nvaytet commented 2 months ago

@jl-wynen is this related to https://github.com/scipp/scippnexus/pull/238 ?

jl-wynen commented 2 months ago

@jl-wynen is this related to scipp/scippnexus#238 ?

Yes. But ESSreduce has its own mechanism for this. See https://github.com/scipp/essreduce/blob/dd87cd7264f0187dd888ce6afcd7096df2ca5391/src/ess/reduce/nexus/_nexus_loader.py#L65

SimonHeybrock commented 2 months ago

As mentioned in the discussion related to (not) locking (#99) earlier, I think doing this via an injected provider seems like a decent option to me. The question is whether having what we have in this PR as a default is reasonable, or if should be something else.

As this sees little use for now, we can also consider to go with it, then iterate.

Please review again under those considerations!

jl-wynen commented 2 months ago

As mentioned in the discussion related to (not) locking (https://github.com/scipp/essreduce/issues/99) earlier, I think doing this via an injected provider seems like a decent option to me.

What do you mean by 'injected provider'? I don't see one in this PR. So are you saying that we should do it differently?

SimonHeybrock commented 2 months ago

As mentioned in the discussion related to (not) locking (#99) earlier, I think doing this via an injected provider seems like a decent option to me.

What do you mean by 'injected provider'? I don't see one in this PR. So are you saying that we should do it differently?

This PR (re)defines file_path_to_file_spec. What I am saying is that if a user requires special features such as non-locking or SWMR mode they can insert their own into the workflow, kicking out the pre-defined one.