In D58#1640, @kreps wrote:

I think I have it now all, but I ran to another issue with arcanist, which refused to upload diff on a large file without marking it binary. The file is src/EvtGenModels/EvtVubAC.cpp and we might need to change it back from binary when we finish this.

@kreps , @jback feel free to add yourselves as reviewers too
We should also decide whether to extend this to the rest of the package now or leave to later. I'd probably favour doing it all in one go.

Rebase on master

rEVTGEN6d93ea5c4f5e takes care of the CMake configuration to automate the generation of the documentation.
Now just need to add the Doxygen comments to all the classes!

Thanks @kreps , yes the README needs some text in the introduction but agree we can maybe add that in a separate step.
I've just finished going through the History file and making it looks reasonable in Markdown format, see:
https://evtgen.hepforge.org/doc/doxygen/test/md_History.html
So I think this can indeed be landed now.

• Start to convert various files to Markdown format

Thanks for this @johndan. I'm not (yet) very familiar with RDataFrame, so bear with me while I look at that part.
I'm thinking that we could use YAML for the config file for this, which should make it more obvious what the various fields are, make it easier to deal with missing fields, etc.
I've been looking into YAML a little bit already in the context of T48 and this is actually a nicer case in which to try it out for the first time, so I'll have a bit of a play with it.

Thanks for this @johndan. I'm not (yet) very familiar with RDataFrame, so bear with me while I look at that part.
I'm thinking that we could use YAML for the config file for this, which should make it more obvious what the various fields are, make it easier to deal with missing fields, etc.
I've been looking into YAML a little bit already in the context of T48 and this is actually a nicer case in which to try it out for the first time, so I'll have a bit of a play with it.

Looking into using YAML for the data format and the yaml-cpp package for parsing it.

Great, many thanks indeed!

Thanks @mwhitehe, the numbers look good. Just one small inline comment.

Many thanks for taking care of all these extensions to the K-matrix @johndan !
Will land this now.

• Start to convert various files to Markdown format

Hi @johndan, thanks for this. Few comments inline.

• Fix stripping of paths

I've copied what is currently generated from this to the following page so that you can look at it more easily:
https://evtgen.hepforge.org/doc/doxygen/test/

Sounds good to me, many thanks @johndan.

All looks good to me thanks @johndan. If @jback can do a final check over as well, since there have been a few changes, then hopefully we can get this landed soon.

Thanks for all this @johndan it looks really nice. I've not really gone through the physics since I think you and @jback have gone through that thoroughly already. So these comments are all more technical.
There are various inline comments (mostly minor). Plus, here are a few general comments:

• Do you have an example of using this generalisation of the K-matrix that could go into the examples dir?
• Please remove the noexcept specifications on functions
  • I would prefer to do a systematic sweep through the package as part of T34 and I still need to fully firm up my understanding of when it is necessary/helpful to do this and what are the prerequisites for it to be valid to do so
  • Having said that, I'm pretty certain that some of those that you've specified noexcept are actually potentially throwing because they call functions that are themselves potentially throwing, e.g. TMatrixD::operator[]
• Please update the release notes

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.

Looks great, thanks Michal!

I'm afraid I don't have time right now to really fully review the physics. But hopefully your tests should have covered that. If we think it's necessary, perhaps we can ask the analysts who were requesting this to do some further validations?
I've added a follow-up on the issue of the various double* arguments - in short I'm also not a fan but let's leave them as they are for now.
I've also added one other small question on initialisation of member variables.
I don't see any other problems.

In D41#1074, @johndan wrote:

General question, @tlatham : should I cherry-pick commits to bring this differential in line with the master (e.g. c38fa2a34f4a772754d1e8f610def10747d95104 - LauFormulaPar fix)?

Thanks for these improvements. They look fine to me.

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.

Many thanks @kreps, looks good to me.

• Update release notes

OK, good to go now, I'll take care of landing it later on.

• Reference Maniphest task in release notes