Page MenuHomeHEPForge

Allow floating of parameters in the k-matrix
ClosedPublic

Authored by johndan on Nov 18 2020, 10:14 AM.

Details

Summary

Merge branch 'master' of ssh://phab.hepforge.org/source/laura into johndan-KMatrixFloatingParameters

Name coupling parameters in KMatrix propagator

Test Plan

Trial fits to a B+ 3-body decay

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
johndan updated this revision to Diff 141.Nov 18 2020, 10:23 AM
  • Remove changes not intended for this review
johndan updated this revision to Diff 142.Nov 18 2020, 10:24 AM
  • Remove more changes destined for later review
tlatham changed the edit policy from "All Users" to "Laura (Project)".
tlatham added a project: Laura.
tlatham changed the visibility from "All Users" to "Public (No Login Required)".
johndan updated this revision to Diff 148.Nov 27 2020, 4:08 PM
  • Correct name of s0prod LauParameter, thus distinguishing it from s0Scatt
tlatham requested changes to this revision.Dec 10 2020, 5:30 PM

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?
Not sure if some of those also ought to be in the LauKMatrixProdPole::getFloatingParameters as well (or instead)? Maybe @jback can comment on that?

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).
This comment applies also to lines 455, 502, 530, 536, 542, 548, 554

502

These parameters have not been given names - should probably be done as per line 463

This revision now requires changes to proceed.Dec 10 2020, 5:30 PM
johndan updated this revision to Diff 162.Dec 16 2020, 2:42 PM
  • Add doxygen lines for one function
johndan updated this revision to Diff 163.Dec 16 2020, 2:42 PM
  • Add doxygen lines for one function
johndan updated this revision to Diff 164.Dec 16 2020, 3:35 PM
  • Add braces for Tom
  • Allow pole mass-squared to vary
johndan updated this revision to Diff 165.Dec 16 2020, 3:37 PM
  • Add braces for Tom
  • Allow pole mass-squared to vary
johndan marked 8 inline comments as done.Dec 16 2020, 4:23 PM
johndan added inline comments.
src/LauKMatrixProdPole.cc
108–124

Yes

src/LauKMatrixProdSVP.cc
97–119

I don't think I have a use-case for this, but could imagine that others might. I will wait for @jback 's reply before adding the functions to expose the parameters, and adding them to getFloatingParameters()...

johndan updated this revision to Diff 166.Dec 16 2020, 4:23 PM
johndan marked an inline comment as done.
  • Add K-matrix name to parameter names, to allow multiple K-M's per model
jback requested changes to this revision.Dec 17 2020, 8:36 PM
jback added inline comments.
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.

This revision now requires changes to proceed.Dec 17 2020, 8:36 PM
johndan marked an inline comment as done.Jan 7 2021, 9:38 AM
johndan added inline comments.
src/LauKMatrixProdSVP.cc
97–119

@jback, by "require always negative", are you suggesting something more strict than a default upper-bound for the parameter?

johndan requested review of this revision.Jan 7 2021, 10:20 AM
johndan marked an inline comment as done.
johndan updated this revision to Diff 173.Jan 7 2021, 10:23 AM
  • Correct Doxygen comments
jback requested changes to this revision.Jan 11 2021, 2:59 PM

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.

This revision now requires changes to proceed.Jan 11 2021, 2:59 PM
johndan updated this revision to Diff 186.Jan 15 2021, 10:52 AM
johndan marked 2 inline comments as done.
  • Add K-matrix name to gCoupling parameters to avoid clashes in models with >1 K-matrix
johndan updated this revision to Diff 187.EditedJan 15 2021, 11:02 AM
johndan marked 2 inline comments as done.
  • Allow other parameters of the SVP to be floated

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?

johndan updated this revision to Diff 188.Jan 15 2021, 11:19 AM
  • Remove whitespace at end of file
  • Fix compilation errors
jback added inline comments.Jan 15 2021, 6:10 PM
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.

johndan marked an inline comment as done.Jan 21 2021, 12:39 PM
johndan updated this revision to Diff 196.Jan 21 2021, 12:51 PM
  • Cleanup LauAbsResonance constructor which involved a lot of duplication for K-matrix

Can we 'land' this so that we can start merging D41? Thanks!

johndan updated this revision to Diff 199.Fri, Jan 29, 2:06 PM
  • Minor, aesthetic, improvements
johndan updated this revision to Diff 200.Fri, Jan 29, 6:37 PM
  • Movement of one comment and correct access to one floating parameter
  • trivial reset of changes caught up in earlier commit
johndan updated this revision to Diff 201.Fri, Jan 29, 6:58 PM
  • Allow floating of s0scatt and mSq0
tlatham accepted this revision.Mon, Feb 1, 10:34 PM

Many thanks @johndan, this looks great. I understand from @jback that he's also happy with this, so I'll go ahead and land this one onto master.

This revision was not accepted when it landed; it landed in state Needs Review.Mon, Feb 1, 10:53 PM
This revision was automatically updated to reflect the committed changes.