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
Branch
johndan-KMatrixFloatingParameters
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 129
Build 129: arc lint + arc unit

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
  • Remove changes not intended for this review
  • 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)".
  • 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
172–175

These Doxygen lines should be attached to what is now line 169.

src/LauKMatrixProdPole.cc
110–126

Might we want to provide the option to also float the pole mass?

120–121

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
  • Add doxygen lines for one function
  • Add doxygen lines for one function
  • Add braces for Tom
  • Allow pole mass-squared to vary
  • Add braces for Tom
  • Allow pole mass-squared to vary
johndan added inline comments.
src/LauKMatrixProdPole.cc
110–126

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 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 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 marked an inline comment as done.
  • 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 marked 2 inline comments as done.
  • Add K-matrix name to gCoupling parameters to avoid clashes in models with >1 K-matrix
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?

  • Remove whitespace at end of file
  • Fix compilation errors
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.

  • Cleanup LauAbsResonance constructor which involved a lot of duplication for K-matrix

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

  • Minor, aesthetic, improvements
  • Movement of one comment and correct access to one floating parameter
  • trivial reset of changes caught up in earlier commit
  • Allow floating of s0scatt and mSq0

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.Feb 1 2021, 10:53 PM
This revision was automatically updated to reflect the committed changes.