Merge branch 'master' of ssh://phab.hepforge.org/source/laura into johndan-KMatrixFloatingParameters
Name coupling parameters in KMatrix propagator
Details
Details
- Reviewers
tlatham jback - Maniphest Tasks
- T59: Allow the s0_prod parameter of the K-matrix to float
- Commits
- rLAURAc9953f876dc8: Allow floating of parameters in the K-matrix
Trial fits to a B+ 3-body decay
Diff Detail
Diff Detail
- Repository
- rLAURA laura
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
There are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
Thanks very much for this @johndan. It looks good.
I think it would just be good to take the opportunity while we're at it to allow any of the parameters to float.
We should also include the name of the propagator in the name of the parameters so that if we have more than one K-matrix in a given fit we don't get identically named parameters appearing - this will cause problems with the sim-fit for example.
See the inline comments for details.
| inc/LauKMatrixPropagator.hh | ||
|---|---|---|
| 196–199 | These Doxygen lines should be attached to what is now line 169. | |
| src/LauKMatrixProdPole.cc | ||
| 108–124 | Might we want to provide the option to also float the pole mass? | |
| 118–119 | I always prefer to have the braces, even for one-line if's or loops. | |
| src/LauKMatrixProdSVP.cc | ||
| 97–119 | Might we also want to provide the option to float s_0^scatt and the m_0, s_A, s_A0 parameters? | |
| 107–108 | As above, please add the braces. | |
| src/LauKMatrixPropagator.cc | ||
| 455 | This parameter has not been given a name, should probably follow line 463. | |
| 463 | It would be good to use the name_ of this propagator in forming the names of all the parameters, in case we have more than one K-matrix instance in a fit (e.g. for pipi and Kpi S-wave in B -> Kpipi). | |
| 502 | These parameters have not been given names - should probably be done as per line 463 | |
| src/LauKMatrixProdSVP.cc | ||
|---|---|---|
| 97–119 | We could float these parameters, although we must ensure that s_0^scatt is always negative. The slowly varying part must have an amplitude that is of the form 1/(s + x), where x is a positive number. Otherwise we would get 1/(s - |x|), which is resonance behaviour with a pole at s = x. | |
Comment Actions
Need to apply an upper bound = 0 for s_0^scatt if this is allowed to float. Some parameters still need "names" added, as per Tom's suggestion.
| src/LauKMatrixProdSVP.cc | ||
|---|---|---|
| 97–119 | We could apply an upper bound for s_0^scatt = 0. | |
Comment Actions
- Add K-matrix name to gCoupling parameters to avoid clashes in models with >1 K-matrix
Comment Actions
I think only 1 parameter needed a changed name - @jback let me know if I missed something here though.
| src/LauKMatrixProdSVP.cc | ||
|---|---|---|
| 97–119 | How do we do that when, by default, we will simply create this parameter as LauParameter(name,value) and not with some bounds. Isn't it safe simply to require that the person who floats this parameter knows to set the bounds meaningfully? | |
| src/LauKMatrixProdSVP.cc | ||
|---|---|---|
| 97–119 | Yes, I think this makes sense. The person should only accept solutions when s_0^scatt is negative to ensure no resonance behaviour is occurring for the slowly-varying parts (SVPs). Furthermore, a hard-coded upper limit of zero will also more than likely cause unstable fit convergence. | |
Comment Actions
- Cleanup LauAbsResonance constructor which involved a lot of duplication for K-matrix
Comment Actions
- Movement of one comment and correct access to one floating parameter
- trivial reset of changes caught up in earlier commit