Extract quantum state related classes from Particle

[redeboer]

Currently, a Particle is just a source of truth, while in the eventual graph, we need to work with quantum numbers only (that is, we are not interested in PID and name).

The aim (#127 (comment)):

• Particle - statically defines particle info from in the PDG [immutable]
• QuantumState - dynamically defines a set of quantum numbers (used in graph, solvers, and conservation_rules) [immutable or mutable]
• ComplexEnergyState - statically defines a fully defined particle state [immutable]
  Used for 'mass and width' (that is, pole position) and therefore eventually ends up in the amplitude model.

[redeboer]

So, design problem:
Does a Particle have a State or is it a State?

• If it is a State, we have the problem that a class derived from a NamedTuple tuple cannot be derived further, unless we give up the NamedTuple class sytax (NamedTuple subclassing NamedTuple python/typing#427).
• If it has a State (makes sense), we use composition.
  • That makes construction of a Particle bothersome:
    particle = Particle(name="J/psi", pid=443, state=State(mass=3.0969, ...)
    (with the necessary import statements)
  • Can a Particle have different states? If so, it has to be mutable again...

[spflueger]

To summarize, we need to figure out first:

• State and Particle mutable or immutable?
• Particle to inherit from State or compose a State?

Note: Using dataclasses might be an option (requires python 3.7). Otherwise normal classes work (more code)

[spflueger]

Internally the solvers would gradually be building up a State, which would later be upgraded to a Particle.
So we would also need a comparison operation State == Particle. I would say that favors composition. I think be default keeping things immutable is good and only add mutability if its needed.

[redeboer]

State and Particle mutable or immutable?

So far, we assumed immutable. Take for example the spin property: we chose float, because we didn't want to consider projection, only magnitude. However, spin will be part of State and we wanted to introduce that class for use in the edge properties (#128 ), which does require spin projection...

Particle to inherit from State or compose a State?

We have to compose if we want to use the NamedTuple syntax (#127 (comment)). But then, as you say (#127 (comment)), we want comparison in of the eventual state as an edge property, which needs spin projection.

[redeboer]

Alternative: keep Particle as it is and have a separate State class that serves as an edge property. You fill then fill that State class with Particle info and/or randomised input from ui._default_settings when propagating states.

You can then still define a State == Particle operator that simply ignores spin projection of the particle.

[spflueger]

It feels like we are missing a piece here. So that a fully defined particle state (with spin projections and everything) is different from lets say particle properties (which just define some static attributes of a particle). The dynamic content of a fully defined particle state comes from the "State" then. Note that this is just some brainstorm idea, but the basic idea would be to introduce some third component.

[spflueger]

Alternative: keep Particle as it is and have a separate State class that serves as an edge property. You fill then fill that State class with Particle info and/or randomised input from ui._default_settings when propagating states.

You can then still define a State == Particle operator that simply ignores spin projection of the particle.

Sounds not bad, but we are still missing a piece. We need some data structure which holds a fully defined state (with spin projections a complex energy position)

[redeboer]

It's hard to combine the fact that:

• particle info is static, unique, and immutable
• edge properties should represent state info, but in a dynamic way, both in usage and for physics issues, like spin projection (This ties in to the design of conservation rules Use decorator pattern for conservation_rules #130.)

In that sense, the internal dicts weren't too bad after all, only that one can make string typos and cause hard to debug errors (we should at least avoid nested dicts).

[redeboer]

We need some data structure which holds a fully defined state (with spin projections a complex energy position)
#127 (comment)

As for the dynamically hiding info in conservation rule function calls (the stackoverflow question), is it okay to pass around state attributes that aren't really used? (memory footprint)

[spflueger]

Ok, so let me propose this possible solution (naming could be improved):

• Particle - statically defines a particle as in the PDG (immutable)
• State - dynamically defines a set of quantum numbers (used in the expert system). Could be (immutable or mutable)
• ParticleState - statically defines a fully defined particle state (with spin projections) (immutable)

[spflueger]

As for the dynamically hiding info in conservation rule function calls (the stackoverflow question), is it okay to pass around state attributes that aren't really used? (memory footprint)

I'm not sure what you mean. So in order to have static typing support and only give access to the necessary information within each rule, I would use the following design. Define a custom immutable data structure as input for each rule which only contains the necessary info. A function in the decorator would reduce the full State info to the one required by the rule. The solvers would work with States and hand them to the decorated rules.

[redeboer]

Particle - statically defines a particle as in the PDG (immutable)

That puts it perfectly: a Particle can at most contain info that is defined in the PDG (that is, not a spin projection). Also, does that mean the current design of Particle is sufficient to move on to #128?

State - dynamically defines a set of quantum numbers (used in the expert system). Could be (immutable or mutable)

Is this specific only to the graph module (that is, edge properties)?

ParticleState - statically defines a fully defined particle state (with spin projections) (immutable)

...while this is specific to conservation rules?

[spflueger]

Particle - statically defines a particle as in the PDG (immutable)

That puts it perfectly: a Particle can at most contain info that is defined in the PDG (that is, not a spin projection)

State - dynamically defines a set of quantum numbers (used in the expert system). Could be (immutable or mutable)

Is this specific only to the graph module (that is, edge properties)?

Both State and ParticleState would be used as graph edges props and in the solvers to pass info to the rules. Note that ParticleState > State in terms of attributes. So a ParticleState would "contain" a State.

ParticleState - statically defines a fully defined particle state (with spin projections) (immutable)

...while this is specific to conservation rules?

See comment above. I also forgot to mention here, that this would be data structure we would use in the Recipe module

[redeboer]

I still don't really understand the difference between State and ParticleState. Is a ParticleState necessary for open edges (initial and final state)?

[spflueger]

I still don't really understand the difference between State and ParticleState. Is a ParticleState necessary for open edges (initial and final state)?

I modified my comment above to clarify. But as a concrete example:

class State:
    charge = 0
    parity = +1
    spin = Spin(1, 1)
    ...

class ParticleState(State):
    mass = 1.2
    width = 0.1

In that sense a ComplexEnergyState would be maybe more descriptive.

[redeboer]

In that sense a ComplexEnergyState would be maybe more descriptive.

So it's like

class ComplexEnergyState
    mass: float = 1.2,
    width: float = 0.1,
    quantum_numbers=State(
        charge=0,
        parity=+1,
        spin=Spin(1, 1),
    )
    ...

?

[redeboer]

I also forgot to mention here, that this would be data structure we would use in the Recipe module
#127 (comment)

I also still don't really understand this. If it is Recipe module only (why?) maybe it's better to discuss in that issue #22

[spflueger]

In that sense a ComplexEnergyState would be maybe more descriptive.

So it's like

class ComplexEnergyState
    mass: float = 1.2,
    width: float = 0.1,
    quantum_numbers=State(
        charge=0,
        parity=+1,
        spin=Spin(1, 1),
    )
    ...

?

correct (composition or inheritance aside)

[redeboer]

But why split up that class? (Mass conservation rule?)

[spflueger]

I also forgot to mention here, that this would be data structure we would use in the Recipe module
#127 (comment)

I also still don't really understand this. If it is Recipe module only (why?) maybe it's better to discuss in that issue #22

It would not solely be used in the Recipe. So the solvers would gradually build up a graph of ComplexEnergyStates (starting from regular States for intermediate edges). The final solution would be converted into an Amplitude Recipe which also need a ComplexEnergyState

[spflueger]

But why split up that class? (Mass conservation rule?)

Ok, let me clarify. The mass (or more precisely complex energy) is strictly speaking not relevant to figure out if a physical solution exists to a specific problem (e.g.: J/Psi -> gamma pi0 pi0). You can imagine if you would be the first person studying this decay, you do not know what intermediate states to expect. The expert system will inform you though, that based on quantum mechanics only certain combinations of quantum numbers are possible (in the pi0 pi0 Subsystem f0, f2, f4, ... in case of strong interactions). Based on that information you would construct some "new" particles with J^{PC} = 0^{++} and 2^{++} etc and put that into your amplitude model to see if they actually exist in nature.

[redeboer]

#127 (comment)
This is a super important remark, I think, and well put. Because it ties in to the eventual recipe and the eventual transition towards PWA. For instance, this is where fit parameters come into play: the expert system ideally 'suggest' a fit parameter based on some 'optimal' pole energy (now we just call that mass and width taken directly from the PDG). Important to keep in mind for #22 (and perhaps even #124).