Yes, the default lambda1 parameter quoted in the documentation should be -0.3, as given by Eq 39 (not Eq 24) on page 24 of https://arxiv.org/pdf/hep-ph/9805303.pdf . The BTOXSGAMMA model description in the guide has various other grammar problems that also need correcting. We could update the latex for the guide in the repository, or put the correct info in the paper draft (or do both).

Example pi0 Dalitz distributions before & after the change:

Instead of proceeding with D76, we have instead created a branch for the Swift-HEP tests in the CERN GitLab (mirror) repository: https://gitlab.cern.ch/evtgen/evtgen/-/tree/SwiftHEP_Tests

Example probability distribution for Dstar0 -> D0 e+ e- decay:

Changes look good, Michal. The code is now more general and has excellent agreement with the previous version. Thanks.

Code can be merged, although it would be good if the "DK P-wave" comment for calcGamma in LauKMatrixPropagator.hh is removed before this revision is landed.

Thanks @johndan for implementing my suggestion.

For reference, old LHCb JIRA task for tau decays using TAUOLA (which could not add spin info): https://its.cern.ch/jira/browse/LHCBGAUSS-841.

Code changes look OK. Thanks for porting these over from the LHCb merge request, Michal.

Ok, don't see any showstoppers. Thanks for writing this model, Michal.

From further discussion elsewhere, it looks like the code needs further edits to allow channel-dependent L values (for a given total angular momentum J).

Algorithm looks OK overall, although it would be good if we could try to avoid using double pointers in various functions.

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.

Thanks @johndan, the changes you have made so far look good and makes the code more general. I have replied to your questions, and have also suggested that we calculate the barrier radii-squared terms at initialisation. Not sure what we can do for avoiding hard-coding the D* mass at initialisation (regarding access to LauResonanceMaker info).

Example environment setup script, using cvmfs packages:

I've had a first look at the code and have provided some suggestions for changes that I think are needed.

Code can be merged.

I'll try to compare the physics against the referenced paper next week, although I guess this was checked during the LHCb review?

• Update EvtEtaLLPiPi model according to D34 suggestions.

Code review: https://phab.hepforge.org/D34

! In T108#1685, @tlatham wrote:
Presumably then we would have json files that define the tests for each model and also have some other json file that maps the model to the source and header files that it depends on (or probably the other way around), then in the CI pipeline we would check what code has changed in the commit and decide which models need to be rerun based on the changes. Is that the idea?

The idea is to run a test doing:

• Need to decide if including the json header & source file is compatible with our license; I think it'll be OK since we include its own license fully.
• Also need to think about where we can store reference histograms for CI pipline. Can we use CERN EOS?
• Can ROOT be used in a CI pipeline? If not, we could create our own simple "histogram" class to store distributions so that they can be compared with references.

I think I've fixed all of the compilation errors and warnings, and have also added the cmake branch changes as well. To build this modernize branch using cmake, do: