Update process interface interface

[szabo137]

With this, we update the process and cross-section interface to adopt the new phase space points. This solved #57.

TODOs

• update tests for process interface
• update test implementation for processes
• update process interface description
• update tests for cross-section and probability
• update building of cross sections and probabilities
• update perturbative compton
• old interface (incl. versions for vectors of inputs)
• cleanup

[szabo137]

@AntonReinhard I think this is ready for review. You are right, deleting lots of code is a lot of fun 😆

BTW: In contrast to #57 the functions _incoming_flux and _total_probability can not be defined on PhaseSpacePoint, because the latter always contain outgoing momenta, which these functions do not depend on. In general, there are cases, where one wants a PhaseSpacePoint but only with the incoming particles: an IncomingPhaseSpacePoint, maybe.

[AntonReinhard]

In contrast to #57 the functions _incoming_flux and _total_probability can not be defined on PhaseSpacePoint, because the latter always contain outgoing momenta, which these functions do not depend on. In general, there are cases, where one wants a PhaseSpacePoint but only with the incoming particles: an IncomingPhaseSpacePoint, maybe.

That makes sense. I think it would be nice to have an IncomingPhaseSpacePoint, but if that one exists, then an OutgoingPhaseSpacePoint probably should too, and having three times the essentially same struct seems bad for code duplication.

I think there are a few options to consider:

• Have the current PhaseSpacePoint be made up of an incoming and an outgoing PhaseSpacePoint. Those two should be symmetric, so only one definition is really needed. Problem: There'll likely be more memory footprint and checking required, since a PhaseSpacePoint would need to make sure that the process, model, and ps_def of the incoming and outgoing parts are the same. I think this would also nicely allow to have a product definition of vectors of incoming and outgoing halves.
• Allow our PhaseSpacePoint to have 0 length in or out particle vectors. We could then add some functions like has_incoming and has_outgoing to make sure the required parts are given where needed. Since the length of the vectors are part of the type info it should be possible to dispatch on this too, though I'm not sure if partial template specializations are a thing in Julia. Otherwise, the function definitions might get long again... Something like these:

const IncomingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, IN_P, 0} where {PROC, MODEL, PSDEF, PSELT, IN_P}
const OutgoingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, 0, OUT_P} where {PROC, MODEL, PSDEF, PSELT, OUT_P}

There might be more ideas, but these two came to mind.

[AntonReinhard]

I can definitely see your point with the IncomingPhaseSpacePoint being necessary, there are still way too many functions now that are defined on momenta instead of PSPs now, which propagates through a lot of code. I think the real goal is to have all the public-facing functions defined on (I/O)PSPs.

Together with #49, that should get rid of a lot of boilerplate code again. The solution to that issue is likely to just create constructors for the PSP on Reals/SFMs or any other representation. Then there should be no reason for anything to use flat momenta instead of PSPs. It should also make it simple enough for the user to broadcast functions that it's not really necessary to provide those overloads ourselves.

[szabo137]

In contrast to #57 the functions _incoming_flux and _total_probability can not be defined on PhaseSpacePoint, because the latter always contain outgoing momenta, which these functions do not depend on. In general, there are cases, where one wants a PhaseSpacePoint but only with the incoming particles: an IncomingPhaseSpacePoint, maybe.

That makes sense. I think it would be nice to have an IncomingPhaseSpacePoint, but if that one exists, then an OutgoingPhaseSpacePoint probably should too, and having three times the essentially same struct seems bad for code duplication.

I think there are a few options to consider:

• Have the current PhaseSpacePoint be made up of an incoming and an outgoing PhaseSpacePoint. Those two should be symmetric, so only one definition is really needed. Problem: There'll likely be more memory footprint and checking required, since a PhaseSpacePoint would need to make sure that the process, model, and ps_def of the incoming and outgoing parts are the same. I think this would also nicely allow to have a product definition of vectors of incoming and outgoing halves.
• Allow our PhaseSpacePoint to have 0 length in or out particle vectors. We could then add some functions like has_incoming and has_outgoing to make sure the required parts are given where needed. Since the length of the vectors are part of the type info it should be possible to dispatch on this too, though I'm not sure if partial template specializations are a thing in Julia. Otherwise, the function definitions might get long again... Something like these:

const IncomingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, IN_P, 0} where {PROC, MODEL, PSDEF, PSELT, IN_P}
const OutgoingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, 0, OUT_P} where {PROC, MODEL, PSDEF, PSELT, OUT_P}

There might be more ideas, but these two came to mind.

Understood! I agree that having two distinct types for incoming and outgoing phase spaces adds some duplications and boilerplate code.
Having the special cases in the current implementation, which switch off the in- or out-channel seems reasonable. But we should be careful that we do not end up checking for has_incoming over and over again because this adds lots of indirections. Intuitively, having some type of product type sounds like the best solution, but I currently can't see the solution of the cost-benefit calculation.

[AntonReinhard]

Having the special cases in the current implementation, which switch off the in- or out-channel seems reasonable. But we should be careful that we do not end up checking for has_incoming over and over again because this adds lots of indirections.

Since we have all the information in the type info now, it should be enough to dispatch on IncomingPSP and have any necessary checks done at compile time. I think I like the idea of the aliases.