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

Make the peak radius an attribute of the function. #6391

Closed
mantid-roman opened this issue Jun 26, 2012 · 2 comments
Closed

Make the peak radius an attribute of the function. #6391

mantid-roman opened this issue Jun 26, 2012 · 2 comments
Assignees
Labels
Framework Issues and pull requests related to components in the Framework
Milestone

Comments

@mantid-roman
Copy link
Contributor

This issue was originally TRAC 5545

The PeakFunction has a default and quite small 'peak radius' - a cut-off distance for the peak wings. It is a good thing for algorithms such as FindPeaks but can be a problem for a user who is unfamiliar with it.

There should not be a global radius. It should be an attribute with different defaults for each peak type.

@mantid-roman
Copy link
Contributor Author

@NickDraper (2012-08-10T12:43:53):
Moved at the end of release 2.2


@NickDraper (2012-10-28T11:39:02):
Moved to milestone 2.4


@NickDraper (2013-01-28T09:23:11):
Moved at the code freeze for release 2.4


@NickDraper (2013-04-29T09:49:45):
Moved to r2.6 at the end of r2.5


@NickDraper (2013-07-26T13:54:59):
Moved to backlog at the code freeze for R2.6


@NickDraper (2014-02-28T16:53:47):
Please assess if ticket is still valid and add a description to the ticket


@NickDraper (2014-03-03T13:47:12):
What effect would this have on the creating and adjusting a peak using the GUI.

The Very Large comment is slightly concerning.

Rather than a set default could we not try to assess the HWHM using a simple walk out from the centre of the peak?


@mantid-roman (2014-03-03T15:28:54):

  • This won't have any negative effect on the GUI.
  • Very large means that practically there is no cut-off and no loss of accuracy.
  • The dynamic cut-off is possible but it will be slower than the fixed value or each peak will have to implement the walk.
  • Maybe this 'radius' should become an attribute? This would make it more visible and flexible.

@NickDraper (2014-12-08T10:25:31):
Moved to the backlog at the code freeze of R3.3

@mantid-roman
Copy link
Contributor Author

@mantid-roman mantid-roman added the Framework Issues and pull requests related to components in the Framework label Jun 3, 2015
@mantid-roman mantid-roman self-assigned this Jun 3, 2015
@mantid-roman mantid-roman changed the title Make the default peak radius infinite and reduce it only when needed Make the peak radius an attribute of the function. Feb 25, 2016
@mantid-roman mantid-roman added this to the Release 3.7 milestone Feb 25, 2016
@mantid-roman mantid-roman modified the milestones: Release 3.8, Release 3.7 May 16, 2016
@mantid-roman mantid-roman modified the milestones: Release 3.8, Release 3.9 Sep 30, 2016
@NickDraper NickDraper modified the milestones: Release 3.9, Temporary Holding Oct 14, 2016
@mantid-roman mantid-roman modified the milestones: Release 3.9, Temporary Holding Oct 14, 2016
mantid-roman added a commit that referenced this issue Nov 30, 2016
mantid-roman added a commit that referenced this issue Nov 30, 2016
mantid-roman added a commit that referenced this issue Dec 1, 2016
…param_estimation' into 6391_peak_radius_problem

There are some changes that I want to use here. Re #6391.
mantid-roman added a commit that referenced this issue Dec 1, 2016
mantid-roman added a commit that referenced this issue Dec 2, 2016
mantid-roman added a commit that referenced this issue Dec 2, 2016
mantid-roman added a commit that referenced this issue Dec 2, 2016
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
Projects
None yet
Development

No branches or pull requests

2 participants