Splitting ModelSystem and Cell

[ndaelman-hu]

This issue was prompted by the Area C meeting on 13.12.2024

System Hierarchies and Particle Definitions

The current structure of ModelSystem leaves some unclarities open wrt structuring. Any ModelSystem instance contains subsections model_system and cell.

• The intended use of model_system is to cover subsystems in the system hierarchy. What may constitute a subsystem is completely context-dependent. Atoms, monomers, material phases, device components, coarse-grained systems, ONIOM shells are equally valid, and may even be used intermittently, e.g. first by material phase, then by monomer: system -> slab + [polymer -> monomer] (where -> stands for "subsystem of").
• cell specifies the positions, velocities, etc. of whatever kind of particle it refers to. It may also employ other sections, like AtomState, for more contextual definitions.

Structuring Options

This schema is now ambiguous regarding where to place the particle definitions (i.e. populate cell):

• top level: all particles are defined at the top-level system. Subsystems only refer back to the particles via their indices.
• bottom level: each leaf node in the system hierarchy defines its own particles. Supersystem nodes (i.e. nodes that aren't leafs) simply stay blank.
• maximally referential: similar to "bottom level", but each supersystem node repeats the particle definitions of its own subsystems.
• minimalistic referential: similar to "bottom level", but each supersystem node refers to the origins of its own subsystems.
• free-style: no clear structure, fully up to the whims of the parser dev.

Under the current schema, all options are equally valid. I think we can all agree that we'd like to set a clearer guideline of which approach to use. We seem to prefer the "top level" approach overall.
This assumes, of course, that we won't run into any cases where we need the more generic "bottom level" and its alternatives. I think that we can safely split such cases over multiple entries, as they typically involve very different kinds of calculations. Feel free to provide counterexamples.

Suggested Solution

If we end up going with "top-level", we either:

1. decouple cell from ModelSystem.
2. have model_system be of a simpler type than ModelSystem.

Regardless of the implementation, we should still retain some common (intrinsic) properties for any subsystem, e.g. total charge, total mass. We should also support references to ModelMethod, to cover cases like ONIOM.

Sketch of the problem statement and suggested solutions.

[ndaelman-hu]

@EBB2675 do you anticipated any case where a subsystem may refer to an electronic section?

[JosePizarro3]

One solution might be to follow CMSO, and define cell under a specific sub class of ModelSystem.

I don't know if you discussed this internally, but it seems to me this would be the option 3 of your list in the first message.

But for @Bernadette-Mohr @JFRudzinski , does this CMSO makes sense?

[JFRudzinski]

One solution might be to follow CMSO, and define cell under a specific sub class of ModelSystem.

I don't know if you discussed this internally, but it seems to me this would be the option 3 of your list in the first message.

But for @Bernadette-Mohr @JFRudzinski , does this CMSO makes sense?

Is this relevant to the issue here, or is it a parallel suggestion? Adopting CMSO in itself does not address the ambiguity of the cell class definition does it? Or am I missing something?

In any case, there are of course some specific aspects of CMSO that do not apply to soft matter in general, but I see no issue in the overarching structure. Not sure if you had some specific aspect in mind?

[JosePizarro3]

One solution might be to follow CMSO, and define cell under a specific sub class of ModelSystem.
I don't know if you discussed this internally, but it seems to me this would be the option 3 of your list in the first message.
But for @Bernadette-Mohr @JFRudzinski , does this CMSO makes sense?

Is this relevant to the issue here, or is it a parallel suggestion? Adopting CMSO in itself does not address the ambiguity of the cell class definition does it? Or am I missing something?

In any case, there are of course some specific aspects of CMSO that do not apply to soft matter in general, but I see no issue in the overarching structure. Not sure if you had some specific aspect in mind?

I saw that the problem is that cell appears at the same time of the hierarchical model system structure. And I read the two solutions: decouple cell out of model system (not sure what this means) or model system being simpler type than ModelSystem. I think the second solution, now that I think more carefully, goes into a similar direction of CMSO.

So if what bothers is that cell appears, I think abstraction might be the solution, similar to CMSO: having a metaclass ModelSystem which contains the hierarchy and from which AtomicModelSystem (the one containing cell), MicroModelSystem, MacroModelSystem, etc. (I don't know which categories would be here) inherit from and can be used in the hierarchical structure.