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

SaveNexusProcessed and LoadNexusProcessed changes masked detectors #8881

Closed
wdzhou opened this issue Sep 27, 2013 · 4 comments
Closed

SaveNexusProcessed and LoadNexusProcessed changes masked detectors #8881

wdzhou opened this issue Sep 27, 2013 · 4 comments
Assignees
Labels
Framework Issues and pull requests related to components in the Framework High Priority An issue or pull request that if not addressed is severe enough to postponse a release. Stale This label is automatically applied to issues that are automatically closed by the stale bot

Comments

@wdzhou
Copy link
Collaborator

wdzhou commented Sep 27, 2013

This issue was originally TRAC 8036

The defect is found while running the attached script. As the final result of the script, the result of the division in last step (stored in workspace NOM_18251) has non-zero uncertainties. But do the division between 2 workspaces that are loaded from the saved Nexus file (NOM_18250_Foc.nxs and NOM_18251_Foc.nxs) in this script renders a result with zero uncertainties. Theoretically, it should be the same as 'NOM_18251'.

Some investigation was made. And it is found that the detectors in the workspace loaded from the processed Nexus files are flagged as 'masked'. Thus algorithm BinaryOperation just put ZERO (value and uncertainties) in the output workspace.

Thus the problem must occur in either LoadNexusProcessed or SaveNexusProcessed when they deal with some spectra with multiple detectors, among which some detectors are masked.

@wdzhou
Copy link
Collaborator Author

wdzhou commented Feb 14, 2014

@NickDraper (2014-02-14T11:04:54):
Bulk move to assigned at the introduction of the triage step

@wdzhou
Copy link
Collaborator Author

wdzhou commented Jun 3, 2015

http://trac.mantidproject.org/mantid/raw-attachment/ticket/8036/problem.py
(uploaded by @wdzhou on 2013-09-27T02:34:06)


@wdzhou wdzhou added High Priority An issue or pull request that if not addressed is severe enough to postponse a release. Framework Issues and pull requests related to components in the Framework labels Jun 3, 2015
@stale
Copy link

stale bot commented Feb 24, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you feel this is incorrect please comment to keep it alive, with a reason why.

To prevent closure, e.g. for long-term planning issues, add the "Never Stale" label.

@stale stale bot added the Stale This label is automatically applied to issues that are automatically closed by the stale bot label Feb 24, 2021
@stale
Copy link

stale bot commented Mar 3, 2021

This issue has been closed automatically. If this still affects you please re-open this issue with a comment so we can look into resolving it.

@stale stale bot closed this as completed Mar 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues and pull requests related to components in the Framework High Priority An issue or pull request that if not addressed is severe enough to postponse a release. Stale This label is automatically applied to issues that are automatically closed by the stale bot
Projects
None yet
Development

No branches or pull requests

1 participant