 |
Peano
|
|
Peano
|
The Python-side model of "what happens during one mesh sweep". More...
Namespaces | |
| namespace | ActionSet |
| namespace | Step |
| namespace | Steps |
| namespace | StepsToStepRepository |
| namespace | StepToActionSets |
| namespace | StepToObserver |
| namespace | SynchroniseActionSets |
| namespace | UserActionSet |
The Python-side model of "what happens during one mesh sweep".
A peano4.api.solversteps.Step.Step corresponds to one generated C++ Observer, i.e. one grid traversal. It holds the vertex/face/cell data it touches and an ordered list of peano4.api.solversteps.ActionSet.ActionSet instances - the actual "reactions to events" (touch vertex first time, create cell, ...) that get woven into that Observer. peano4.api.solversteps.UserActionSet.UserActionSet is the one action set every Step gets by default: an empty, user-editable stub placed under actions/ rather than being regenerated every run.
peano4.api.solversteps.Steps.Steps is the top-level collection: it holds every Step a peano4.api.Project knows about and, via StepsToStepRepository, additionally generates the C++ StepRepository that lets the runtime look steps up by name/index at runtime.
Steps and Step do not write C++ themselves. Each delegates to a private generator held by aggregation: Step to StepToActionSets/StepToObserver, Steps to StepsToStepRepository. Those generators are the bridge into peano4.api.output - the actual C++ code writers - turning one Python-side ActionSet/Step/Steps object into a peano4.api.output.ActionSet/Observer/TemplatedHeaderImplementationFilePair that is what ends up on disk.
Solid hollow-triangle arrows are inheritance (UserActionSet extends ActionSet); diamond-ended lines are aggregation/composition (a Step owns its list of action sets and its two generators; a Steps owns its list of Steps and its one generator); open-arrow solid lines are the plain back-references the generators keep to the object they serve; dashed open arrows are "creates" dependencies into peano4.api.output.
1.9.8