Add entry point where the user can specify decay dynamics

[redeboer]

Since #189, the Dynamics section in the output amplitude model recipe file shrinks, because the PDG particle definitions do not contain dynamics info (e.g. Flatté or relativistic Breit-Wigner). This dynamics info should be added only later on for the eventual fitting package, so when the amplitude recipe is created.

We need to think of a smart design here, perhaps even leave it up to the fitting package.

[redeboer]

@Leongrim How should this work from a user perspective?

Since #110 (removes dynamics from the input particle database), you manually have to add your dynamics to the output recipe file and it should like this. The question is, how to make add this info through Python, and at which stage? (In terms of the workflow notebooks: at which step, for instance, when you write the amplitude model?)

Eventually, the output recipe should look something like this: https://github.com/ComPWA/tensorwaves/blob/d97bfdde2e1da1c6bb17f0d2d78c51a42d15f9ac/examples/intensity-recipe.yaml#L1195-L1224

Dynamics:
  J/psi:
    Type: NonDynamic
    FormFactor:
      Type: BlattWeisskopf
      MesonRadius: 1.0

  f0(980):
    Type: RelativisticBreitWigner
    FormFactor:
      Type: BlattWeisskopf
      MesonRadius: 1.0

  f2(1270):
    Type: RelativisticBreitWigner
    FormFactor:
      Type: BlattWeisskopf
      MesonRadius: 1.0

  f0(1500):
    Type: RelativisticBreitWigner
    FormFactor:
      Type: BlattWeisskopf
      MesonRadius: 1.0

  f2(1950):
    Type: RelativisticBreitWigner
    FormFactor:
      Type: BlattWeisskopf
      MesonRadius: 1.0

[Leongrim]

So first of all. Anything you have to add yourself should be avoided. But I think you know that 😁

[redeboer]

That's true, but the expertsystem cannot provide dynamics, because it completely depends on your analysis.

To put it in other words: the expertsystem only knows initial state, final state, decay topology model (isobar), and conservation rules. Only at the moment of amplitude model construction does PWA start to come into the picture. And it's there that the dynamics start to play a part. (Dynamics basically just represent the fit function you use eventually in the fitter package, so that's technically separate from the allowed decay topologies that the expertsystem suggests.)

So for the dynamics, the question is, how to make it as convenient as possible to insert these dynamics to the amplitude construction?

[Leongrim]

I think so smothest way would be to still let the expertsystem handle this an give the option to add the dynamics because otherwise youhad again the same functions in ComPWA and Tensorwaves.

So for the user I think it would be best to have a functionthats adds basic dynamics (e.g. breitwiegner) to all resonances and after that an easy way to change this dynamics inside of the fitting/simulation scripts.

So I dount know much about K-Matrix but does that not combine different final states that could bossible have the same resonances? If so it would also be good to add the dynamics to a transition and not to a resonance

[redeboer]

This issue has become more pressing since https://github.com/ComPWA/tensorwaves/pull/120

[spflueger]

Here are my two cents: The main concept is that tensorwaves does not include any intelligence about what is being computed. So a "Recipe" (does not matter if its a yaml file or a Recipe class later on) should contain all infos that are required to build the amplitude. That means a dynamics for all occurring states have to be stated in the recipe for it to be valid. Note that would mean the default dynamics in tensorwaves should also be removed again. So I'm thinking that the user has to be able to provide a dynamics himself, but if no dynamics is provided "default" way of creating dynamics can be used. This can be kept simple for now (like use rel BW, and include form factors if its canonical or J==L), and be made smarter while the code grows. More concretely

# calling amplitude generator
gen = HelicityAmplitudeGenerator()
gen.generate(solutions, dynamics=None) # user can specify dynamics for each state here which has priority
# note: I'm assuming the user defined dynamics is in self.__dynamics from now on

# inside the amplitude generator, once a state is passed (not final states as they are stable)
if state in self.__dynamics: # if user provided some dynamics use that
    recipe_dyamics[state] = self.__dynamics[state]
else:
    recipe_dynamics[state] = generate_default_dynamics(state, more_info_about_the_decay)

def  generate_default_dynamics(state, ...):
    # try to do best to pick the dynamics here and return it

[redeboer]

Update: the ParticleDynamics class provides some methods that can set dynamics for specific particles. So for instance:

import expertsystem as es

result = es.generate_transitions(
    initial_state="J/psi(1S)",
    final_state=["K0", "Sigma+", "p~"],
    allowed_interaction_types="strong",
    allowed_intermediate_particles=["N"],
)
model = es.amplitude.generate(result)
for particle_name in model.particles.names:
    if particle_name.startswith("N"):
        model.dynamics.set_breit_wigner(particle_name)

Note, however, that it's not yet possible to write such a module. The following would crash:

es.io.write(model, "model.yml")

Just a bug, because wasn't tested.

[redeboer]

There is one more requirement to make the ParticleDynamics class more stable: it should be possible to remove a FitParameter from FitParameters (see #382).