Skip to content

Conversation

@jl-wynen
Copy link
Member

No description provided.

@jl-wynen jl-wynen requested a review from SimonHeybrock July 11, 2023 12:02
"metadata": {},
"outputs": [],
"source": [
"sample = raw_sample['data']\n",
Copy link
Member

Choose a reason for hiding this comment

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

Have you considers naming this detectors instead of data?

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 haven't. Why detectors? Does this match the nexus structure more closely?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. On the other hand there may be workspaces that do not correspond to detector data.

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you still think it should be renamed?

Copy link
Member

Choose a reason for hiding this comment

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

Not sure. 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.

This will never produce the same nested structure as a typical NeXus file. So I don't see this as a strong argument. Plus 'data' is shorter than 'detector'. But it is also very generic (there are a lot of things one could call data).

So I'm leaning towards leaving it as is but I'm not opposed to changing it. Not very helpful, I know...

if 'position' in res["data"].coords:
res["data"].coords['position'] = res["data"].coords['position'][spec_dim, 0]
res["data"] = res["data"][spec_dim, 0].copy()
return res
Copy link
Member

Choose a reason for hiding this comment

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

Is there so much duplication in this file because you copied the code for being able to preserve the old version in parallel? It makes it very hard to review, as it appears as completely new code.

Copy link
Member Author

Choose a reason for hiding this comment

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

Essentially, yes. We touch this code so little that I didn't see the value in avoiding the duplication. It would require making each function handle both cases or reimplementing the old one on top of the new one.
Or do you see a better option.

The main differences between the new and old functions are how they build data arrays / data groups from coords_labs_data.

Copy link
Member

Choose a reason for hiding this comment

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

Any recommendation on how to review this?

Copy link
Member

@SimonHeybrock SimonHeybrock left a comment

Choose a reason for hiding this comment

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

Reviewed mantid.py based on diff without the deprecated content, LGTM.


def _wrap_dict_in_variable(d: Dict[str, Any]) -> Dict[str, sc.Variable]:
return {
key: val if isinstance(val, sc.Variable) else sc.scalar(val)
Copy link
Member

Choose a reason for hiding this comment

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

This is like https://github.com/scipp/scippnexus/blob/99850ab2dbf3ef156db623bd7200be7d9b3332bc/src/scippnexus/v2/base.py#L22-L23, maybe name similarly? The function name also implies that the entire dict is wrapped in a (single) variable.

@jl-wynen jl-wynen merged commit e646466 into main Jul 12, 2023
@jl-wynen jl-wynen deleted the load-mantid branch July 12, 2023 07:33
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.

3 participants