Skip to content
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

Add dream.load_nexus #10

Merged
merged 3 commits into from
Dec 13, 2023
Merged

Add dream.load_nexus #10

merged 3 commits into from
Dec 13, 2023

Conversation

SimonHeybrock
Copy link
Member

@SimonHeybrock SimonHeybrock commented Dec 7, 2023

@celinedurniak this replaces scipp/ess#199. I have adapted it for the latest file I have (which has sorted detector numbers).

@jl-wynen
Copy link
Member

jl-wynen commented Dec 7, 2023

(which has sorted detector numbers).

I didn't follow the discussion. Can we rely on them being sorted from now on?

@SimonHeybrock
Copy link
Member Author

SimonHeybrock commented Dec 7, 2023

(which has sorted detector numbers).

I didn't follow the discussion. Can we rely on them being sorted from now on?

We might, but we are not: Scipp will dynamically choose a faster or slower grouping algorithms, depending on whether they are sorted or not. There is no risk for correctness due to assumptions.

@pytest.mark.filterwarnings("ignore:Failed to load /entry/instrument/monitor_bunker")
@pytest.mark.filterwarnings("ignore:Failed to load /entry/instrument/monitor_cave")
@pytest.mark.filterwarnings("ignore:Failed to load /entry/instrument/polarizer/rate")
@pytest.mark.filterwarnings("ignore:Failed to load /entry/instrument/sans_detector")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you planning to remove those filters when we have a complete file?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose, what are you asking?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to know if these are permanent and a problem with the loader or just temporary until we get better files.

'high_resolution',
'sans',
):
assert f'{name}_detector' in instr
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the GEANT4 loader, those are called name, i.e., without "_detector". We should use the same names in both and I'm in favour of the shorter names in the GEANT4 loader. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@celinedurniak Should we remove the suffix? The name is also repeated on the event data, e.g.,

/entry/instrument/endcap_forward_detector/endcap_forward_event_data

What do you prefer? Something like /entry/instrument/endcap_forward/events? Or something longer? Should we keep the naming from the NeXus file?

tests/dream/io_test.py Show resolved Hide resolved
Comment on lines +21 to +22
See https://confluence.esss.lu.se/pages/viewpage.action?pageId=462000005
and the ICD DREAM interface specification for details.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't great. Are there publicly accessible resources about this? Can we make these public?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why public? This is an ESS repo, so I think everyone who needs access can get to the info?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how that will work for visitors. But fine.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will only matter for instrument scientist, mainly during hot commissioning.

- The high-resolution detector has a very odd numbering scheme. The SANS detector
is using the same, but is not populated in the current files. The scheme
attempts to follows some sort of physical ordering in space (x,y,z), but it
looks partially messed up.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be issues to help us follow up on them?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure. It depends on how we will handle versioning in the loader. Will we have to keep it working with the current files, if ECDC makes fixes/changes in the future?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not the current ones as they should be replaced by newer ones, I guess. But ultimately, we will have to keep supporting old ones.

src/ess/dream/io.py Show resolved Hide resolved
'mounting_unit': 5,
'cassette': 6,
'counter': 2,
'strip': 256,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These names correspond to the ICD, not GEANT4 names on the confluence page. Are these the ones we want to go with? Should we rename the dims in the GEANT4 loader?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can necessarily keep the GEANT4 naming, since the NeXus files order things in a different way so logic folding according to GEANT4 names is not possible (in at least 1 case, I think).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

dg = f[entry][()]
dg = snx.compute_positions(dg)
if not fold_detectors:
return dg
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For readability, can you turn the everything below this line into a separate function and call it here?

@SimonHeybrock SimonHeybrock changed the base branch from main to deps December 7, 2023 11:11
Base automatically changed from deps to main December 11, 2023 04:21
@SimonHeybrock SimonHeybrock merged commit e24d289 into main Dec 13, 2023
3 checks passed
@SimonHeybrock SimonHeybrock deleted the load-dream branch December 13, 2023 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants