Bug in allowed_interaction_types argument to generate_transitions()

[redeboer]

As noted by/with @MartinTum, setting allowed_interaction_types in generate_transitions() does not work as expected when using a tuple (setting the interaction type per node).

Imports and particle database definition

import graphviz
import qrules
from qrules.particle import Particle, Spin
from qrules.settings import InteractionType
from qrules.transition import StateTransitionManager


Tcc1_4430 = Particle(
    name="Tcc̅1(4430)⁺",
    pid=99999999999,
    latex=R"\mathit{T}_{c\overline{\mathit c}1}(4430)^+",
    spin=1,
    mass=4.478,
    width=0.181,
    charge=+1,
    isospin=Spin(1, +1),
    parity=+1,
    c_parity=-1,
    g_parity=+1,
)
particle_database = qrules.load_pdg()
particle_database += Tcc1_4430

reaction = qrules.generate_transitions(
    initial_state="B0",
    final_state=["J/psi(1S)", "pi+", "K-"],
    allowed_intermediate_particles=["K(0)", "K*", "Tc", "f(0)"],
    allowed_interaction_types=("weak", "strong"),  # <-- problem here
    particle_db=particle_database,
)

Using the STM directly does result in the correct behaviour:

stm = StateTransitionManager(
    initial_state=["B0"],
    final_state=["J/psi(1S)", "pi+", "K-"],
    particle_db=particle_database,
)
stm.set_allowed_interaction_types([InteractionType.WEAK], node_id=0)
stm.set_allowed_interaction_types([InteractionType.STRONG], node_id=1)
problem_sets = stm.create_problem_sets()
reaction = stm.find_solutions(problem_sets)

[grayson-helmholz]

Isn't there a semantic difference when one version applies the allowed_interaction_types to all nodes and the other version applies them per node?

[redeboer]

Yes, the examples described above should produce exactly the same result.
You're right to point out that a dictionary for allowed_interaction_types would be clearer though, #290.

[grayson-helmholz]

As mentioned above, this behaviour is not due to a bug but a unflexible API and will be adressed in #290 .
Closing the issue.

[redeboer]

Indeed, my assumption in #285 (comment) is incorrect. The example is behaving as it is currently designed, i.e. the list of str descriptions of the interaction type descriptions is not per-node, but is the union of interaction types that are applied.