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.

Sign up for GitHub

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

Jump to bottom

Make POLDI algorithms more robust against input errors #12454

Closed
MichaelWedel opened this issue Apr 22, 2015 · 3 comments
Closed

Make POLDI algorithms more robust against input errors #12454

MichaelWedel opened this issue Apr 22, 2015 · 3 comments
Assignees
@MichaelWedel
Labels
Framework Issues and pull requests related to components in the Framework Stale This label is automatically applied to issues that are automatically closed by the stale bot

Comments

@MichaelWedel
Copy link
Contributor

This issue was originally TRAC 11616

This ticket is blocks : TRAC10702

There are some small problems in Problems in PoldiFitPeaks1D and PoldiFitPeaks2D that I would like to address before finishing the workflow algorithm for POLDI.

  1. PoldiFitPeaks2D and PoldiAnalyseResiduals (and thus also PoldiAutoCorrelation) can only work with 2D workspaces that have a POLDI instrument set, otherwise unpredictable things happen. This can be validated before the algorithm is run at all and should avoid random crashes.

  2. PoldiFitPeaks1D should use EstimatePeakErrors just like PoldiFitPeaks2D. Furthermore it should check that parameters are reasonable (q-Values above zero for example).

    Keywords: POLDI, bugfix
@MichaelWedel
Copy link
Contributor Author

@MichaelWedel (2015-04-22T15:28:23):
Refs http://trac.mantidproject.org/mantid/ticket/11616. More strict criteria for acceptable peaks

5604de2

@MichaelWedel MichaelWedel added the Framework Issues and pull requests related to components in the Framework label Jun 3, 2015
@MichaelWedel MichaelWedel self-assigned this Jun 3, 2015
@MichaelWedel MichaelWedel added this to the Release 3.5 milestone Jun 3, 2015
@NickDraper NickDraper modified the milestones: Release 3.5, Release 3.6 Sep 14, 2015
@NickDraper NickDraper modified the milestones: Release 3.6, Release 3.7 Jan 22, 2016
@MichaelWedel MichaelWedel modified the milestones: Release 3.7, Release 3.8 May 18, 2016
@NickDraper NickDraper modified the milestones: Release 3.8, Release 3.9 Oct 3, 2016
@NickDraper NickDraper modified the milestones: Release 3.9, Temporary Holding Oct 14, 2016
@NickDraper NickDraper removed this from the Temporary Holding milestone Oct 3, 2017
@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
Assignees

@MichaelWedel MichaelWedel

Labels
Framework Issues and pull requests related to components in the Framework Stale This label is automatically applied to issues that are automatically closed by the stale bot
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@NickDraper @MichaelWedel