Merge branch 'master' of ssh://phab.hepforge.org/source/laura into johndan-KMatrixFloatingParameters
Name coupling parameters in KMatrix propagator
tlatham | |
jback |
Merge branch 'master' of ssh://phab.hepforge.org/source/laura into johndan-KMatrixFloatingParameters
Name coupling parameters in KMatrix propagator
Trial fits to a B+ 3-body decay
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
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. |
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. |
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. |