Quickstart¶
Your analysis starts by defining an amplitude model that describes the reaction process you want to study. Such a model is generally very complex and requires a fair amount of effort by the analyst (you). This also gives a lot of room for mistakes.
The ‘expert system’ is responsible to give you advice on the form of an amplitude model based on the problem set you define (initial state, final state, allowed interactions, intermediate states, etc.). Internally, the system propagates the quantum numbers through the reaction graph while satisfying the specified conservation rules. How to control this procedure is explained in more detail below.
Afterwards, the amplitude model of the expert system can be exported into ComPWA or Tensorwaves. The model can for instance be used to generate a data set (toy Monte Carlo) for this reaction and to optimize its parameters to resemble an actual data set as good as possible.
1.1. Define the problem set¶
We first define the boundary conditions of our physics problem, such as initial state, final state, formalism type, etc. and pass all of that information to the StateTransitionManager
. This is the main user interface class of the expertsystem
.
By default, the StateTransitionManager
loads all particles from the PDG. The expertsystem
would take a long time to check the quantum numbers of all these particles, so in this quickstart, we use a smaller subset of relatively common particles.
[1]:
from expertsystem.ui import InteractionTypes, StateTransitionManager
[2]:
stm = StateTransitionManager(
initial_state=["J/psi(1S)"],
final_state=["gamma", "pi0", "pi0"],
allowed_intermediate_particles=[
"f(0)(980)",
"f(0)(1500)",
"f(2)(1270)",
"f(2)(1950)",
"omega(782)",
"D*(2007)0",
"rho(770)0",
"phi(1020)",
"a(0)(980)0",
],
formalism_type="helicity",
)
The StateTransitionManager
(STM) is the main user interface
class of the expertsystem
. The boundary conditions of your
physics problem, such as the initial state, final state, formalism type,
etc., are defined through this interface.
prepare_graphs()
of the STM creates all topology graphs ― here, using the isobar model (a tree of two-body decays). The function also initializes the graphs with the initial and final state and a set of conservation laws at each interaction node.By default, all three interaction types (strong, EM, weak) are used in the preparation stage. However, it is also possible to choose the allowed interaction types globally via
set_allowed_interaction_types()
.
After the preparation step, you can modify the settings returned by
prepare_graphs()
to your liking. Since the output of this function
contains quite a lot of information, the
expertsystem UI
aids in the
configuration (especially the STM).
A subset of particles that are allowed as intermediate states can also be specified: either through the
STM's constructor
or by setting the instance attributeallowed_intermediate_particles
.
Hint
How does the StateTransitionManager
know what a "J/psi(1S)"
is? Upon construction, the StateTransitionManager
loads default definitions from the PDG. See Particle database for how to add custom particle definitions.
1.2. Prepare topologies¶
Create all topology graphs using the isobar model (tree of two-body decays) and initialize the graphs with the initial and final state. Remember that each interaction node defines its own set of conservation laws.
The StateTransitionManager
(STM) defines three interaction types:
Interaction |
Strength |
---|---|
strong |
\(60\) |
electromagnetic (EM) |
\(1\) |
weak |
\(10^{-4}\) |
By default, all three are used in the preparation stage. The function
prepare_graphs()
of the STM generates graphs with all possible
combinations of interaction nodes. An overall interaction strength is
assigned to each graph and they are grouped according to this strength.
[3]:
graph_interaction_settings_groups = stm.prepare_graphs()
1.3. Find solutions¶
If you are happy with the default settings generated by the StateTransitionManager
, just start with solving directly!
This step takes about 30 sec on an Intel(R) Core(TM) i7-6820HQ CPU of 2.70GHz running, multi-threaded.
[4]:
result = stm.find_solutions(graph_interaction_settings_groups)
The find_solutions
method returns a Result
object from which you can extract the solutions
and any violated_rules
in case solutions were found. Now, you can use the helper function get_intermediate_state_names
to print the names of the intermediate states that the StateTransitionManager
found:
[5]:
from expertsystem.ui import get_intermediate_state_names
print("found", len(result.solutions), "solutions!")
get_intermediate_state_names(result.solutions)
found 162 solutions!
[5]:
{'D*(2007)0',
'a(0)(980)0',
'f(0)(1500)',
'f(0)(980)',
'f(2)(1270)',
'f(2)(1950)',
'omega(782)',
'phi(1020)',
'rho(770)0'}
About the number of solutions
The “number of solutions
” is the total number of allowed StateTransitionGraph
instances that the StateTransitionManager
has found. This also includes all allowed spin projection combinations. In this channel, we for example consider a \(J/\psi\) with spin projection \(\pm1\) that decays into a \(\gamma\) with spin projection \(\pm1\), which already gives us four possibilities.
On the other hand, the intermediate state names that was extracted with get_intermediate_state_names
, is just a set
of the state names on the intermediate edges of the list of solutions
, regardless of spin projection.
Now we have a lot of solutions that are actually heavily suppressed (they involve two weak decays).
In general, you can modify the dictionary returned by
prepare_graphs()
directly, but the STM also comes with functionality
to globally choose the allowed interaction types.
So, go ahead and disable the EM and weak interaction:
[6]:
stm.set_allowed_interaction_types([InteractionTypes.Strong])
graph_interaction_settings_groups = stm.prepare_graphs()
result = stm.find_solutions(graph_interaction_settings_groups)
print("found", len(result.solutions), "solutions!")
get_intermediate_state_names(result.solutions)
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
WARNING:root:The specified list of interaction types [<InteractionTypes.Strong: 1>] does not intersect with the valid list of interaction types [<InteractionTypes.Weak: 3>, <InteractionTypes.EM: 2>].
Using valid list instead.
found 60 solutions!
[6]:
{'f(0)(1500)', 'f(0)(980)', 'f(2)(1270)', 'f(2)(1950)', 'rho(770)0'}
Huh, what happened here? Actually, since a \(\gamma\) particle appears in one of the interaction nodes, the expert system knows that this node must involve EM interactions! Because the node can be an effective interaction, the weak interaction cannot be excluded, as it contains only a subset of conservation laws.
Since only the strong interaction was supposed to be used, this results in a warning and the STM automatically corrects the mistake.
Once the EM interaction is included, this warning disappears. Be aware, however, that the EM interaction is now available globally. Hence, there now might be solutions in which both nodes are electromagnetic.
[7]:
stm.set_allowed_interaction_types([InteractionTypes.Strong, InteractionTypes.EM])
graph_interaction_settings_groups = stm.prepare_graphs()
result = stm.find_solutions(graph_interaction_settings_groups)
print("found", len(result.solutions), "solutions!")
get_intermediate_state_names(result.solutions)
found 90 solutions!
[7]:
{'a(0)(980)0',
'f(0)(1500)',
'f(0)(980)',
'f(2)(1270)',
'f(2)(1950)',
'omega(782)',
'phi(1020)',
'rho(770)0'}
Great! Now we selected only the strongest contributions. Be aware, though, that there are more effects that can suppress certain decays, like small branching ratios. In this example, the initial state \(J/\Psi\) can decay into \(\pi^0 + \rho^0\) or \(\pi^0 + \omega\).
decay |
branching ratio |
---|---|
\[\omega \rightarrow \gamma+\pi^0\]
|
0.0828 |
\[\rho^0 \rightarrow \gamma+\pi^0\]
|
0.0006 |
Unfortunately, the \(\rho^0\) mainly decays into \(\pi+\pi\), not \(\gamma+\pi^0\) and is therefore suppressed. This information is currently not known to the expert system, but it is possible to hand the expert system a list of allowed intermediate states.
[8]:
# particles are found by name comparison,
# i.e. f2 will find all f2's and f all f's independent of their spin
stm.allowed_intermediate_particles = ["f(0)", "f(2)"]
result = stm.find_solutions(graph_interaction_settings_groups)
print("found", len(result.solutions), "solutions!")
get_intermediate_state_names(result.solutions)
found 90 solutions!
[8]:
{'a(0)(980)0',
'f(0)(1500)',
'f(0)(980)',
'f(2)(1270)',
'f(2)(1950)',
'omega(782)',
'phi(1020)',
'rho(770)0'}
Now we have selected all amplitudes that involve f states. The warnings appear only to notify the user that the list of solutions is not exhaustive: for certain edges in the graph, no suitable particle was found (since only f states were allowed).
1.4. Generate an amplitude model¶
Now that we are satisfied with the intermediate resonances, we are all set convert the solutions that the STM found to an amplitude model! This can be done with the StateTransitionManager.generate_amplitude_model
method. Depending on the formalism type that you chose when constructing the STM, generate_amplitude_model
will use for instance HelicityAmplitudeGenerator
if you chose to work with formalism type "helicity"
.
The result is an AmplitudeModel
from which you can extract all information about Particle
instances, FitParameters
, Kinematics
etc.
[9]:
amplitude_model = stm.generate_amplitude_model(result)
amplitude_model.particles.names
[9]:
{'J/psi(1S)',
'a(0)(980)0',
'f(0)(1500)',
'f(0)(980)',
'f(2)(1270)',
'f(2)(1950)',
'gamma',
'omega(782)',
'phi(1020)',
'pi0',
'rho(770)0'}
Note
In this example, we used the helicity formalism. If you want to work with the canonical formalism, you have to construct the StateTransitionManager
with argument formalism_type="canonical-helicity"
instead of formalism_type="helicity"
.
Finally, you can use the expertsystem.io
to write
the AmplitudeModel
to a file (either XML or YAML):
[10]:
from expertsystem import io
io.write(amplitude_model, filename="model.xml")
io.write(amplitude_model, filename="model.yml")
This allows you to cache file AmplitudeModel
to disk and then load it back using load_amplitude_model
:
[11]:
imported_model_xml = io.load_amplitude_model(filename="model.xml")
imported_model_yml = io.load_amplitude_model(filename="model.yml")
assert imported_model_xml == amplitude_model
assert imported_model_yml == amplitude_model
Have a look through the sections of the resulting XML or YAML recipe file to see what you recognize from the problem set defined above. There may also be some things you want to change in there manually, so make sure you store this recipe file carefully (e.g. track it with Git) as to avoid overwriting it your changes after rerunning the expert system.
Now you can use this recipe file as an amplitude model in a PWA framework!