Possibly related to email thread "Potential weird EvtGen bug in semileptonic baryon decays(?)" from @florian et al.?

Thanks Michal, this indeed looks like a good set of clean-ups as well as the actual physics improvement.

Many thanks! Good to go as far as I'm concerned.

If you could also add to the History.md an entry for D80 that would be great, I completely forgot to do that before landing it just now!

Hi @jback, many thanks for checking this.
Certainly we should make sure that this is correct in the paper draft.
Once the paper is out we can take down the old guide and replace it with a copy of the paper or a link to the paper on arXiv.
But in the meantime, I think it is probably best also to correct the latex for the guide and perhaps put a new pdf on the webpage.

Thanks for these changes @kreps.
I have checked the consistency of the changes between B0 and B0bar and between the DEC and XML files and that all looks fine.
I also gave the two new scripts a quick try and they seem to work as advertised.
They are, however, missing the copyright section at the top. Ideally that section should also be updated to 2022 in the convertDecayFile.py script, then it can be copied into the two new files.
What does "Guide mark calculation" mean in ArgumentParser description in the two new scripts? Could these be made a bit more descriptive?

Rebased on master

Thanks Michal.
The config file is mostly just the default values with the only customisation coming in the first 5 lines:

• line 1 to run only the modernize-use-nullptr check
• line 3 to ensure that it warns about things in our header files
• line 5 so that it uses our .clang-format file for reformatting after any auto-applied changes

I have no doubt that the existing code will need cleaning up as we enable more checks. This is why I say "eventually" about having this run automatically, otherwise we'll just be swamped with warnings. A point for subsequent discussion will be what checks we want to use and in what order to start to gradually enable them and fix stuff as we go. I'll create a task where we can have such a discussion.

Thanks John!

Another option for the data format and parser would be JSON and nlohmann_json as the parser.
While I slightly prefer the look of YAML files, the nlohmann_json parser looks to be more fully featured that either json-cpp or yaml-cpp.
Will look at the various use-cases and see which would work better.

For some reason this didn't get automatically closed when you landed the changes. I tried adding the commit to the list of related commits but that didn't do anything either. Is it possible to close it manually?

As part of this review, should check whether there are adequate protections against invalid settings being passed to these models, e.g. not specifying model number 6 for Bs -> phi mu mu decay modelled with BTOSLLBALL, and implement them if missing.

Thanks @kreps - the solution for what to do with the excess BF sounds sensible and the actual changes to the numbers all appear to be correctly done.