Should also take the opportunity to sort out the naming conventions, particularly for the resonances.

Thanks Mark, looks good, I'll merge it.

Many thanks for putting this together Mark, it's great to have an example that uses the MIPW.
I haven't yet tried running it but will try and do so later on, so these are just from a read through and all quite minor stuff.
(For one I've tried out the new "Suggest edit" feature, so hopefully it will be clear what I mean!)

This is mainly a fix of Doxygen warnings but I have taken the opportunity to streamline very slightly the arguments to LauKMatrixPropagator::calcGamma, hence the request for review.

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.