The new updates using the mass ranges look OK.

Update revision following review discussion

Hi John,

1. Yes, increasing the safety factor to 10% is sensible.

Thanks for checking it through John.

This clever solution for finding ASqMax looks OK overall, so I am approving these changes.

Hi 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.

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

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

• Address comments from Tom

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!)

Thank you for these improvements, Tom. I think this is uncontroversial.

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.

That sounds great, thanks Tom. Let me know when you're ready for me to take a look (there is no urgency - the code above is working locally for me)

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!

OK, points noted, and will have a go at the resonances too

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.

Thanks for checking through this, @tlatham !

• Remove unnecessary error message

• Add catch-all return and finish B-W updates