20 Most generic version of a solver step. A solverstep describes what Peano 4
21 should do when it runs over the grid. As users have to specify which pieces
22 of data from the data model are used by the solver step, it can handle all
23 the user data stack flow.
25 This class also is responsible to generate all function signatures of all
26 the steps, observers and action sets. In the Peano terminology, a step
27 corresponds to an observer. For any given step, we run through the mesh
28 and pass the traversal automaton an observer which accepts events (aka
29 state transition observations).
31 It is the observer's job to then distribute these observations, broken
32 down into grid actions such as "touch vertex first time", among the action
33 sets that are tied to this observer. In Python you can have one action set
34 and associate it with several observers. In the C++ code, we will flatten
35 such a relation, i.e. create the corresponding action set multiple times.
37 @see peano4.solversteps.ActionSet
40 This name is used to create the underlying action set later on
45 add_user_defined_actions=True,
48 By default, the step generates at least one action set for the user.
49 However, you can disable this behaviour by passing False to
50 add_user_defined_actions. Alternatively, use remove_all_action_sets()
57 if add_user_defined_actions:
66 Each step holds a set of actions. They describe what the step actually
67 should do whenever it loads a vertex, runs into a cell, and so forth. By
68 default, the step holds one user-defined actions which means
69 that a stub is generated where users can insert their functionality. You
70 can remove this one (or any other one added so far) with this routine.
77 Simple bubble sort the action sets, such that their descend_invocation_order
80 @see peano4.solversteps.ActionSet.descend_invocation_order
96 Add a new action set to this mesh traversal step
98 Each step holds a set of action_sets. They describe what the step actually
99 should do whenever it loads a vertex, runs into a cell, and so forth. By
100 default, the step holds one user-defined action_set (UserActionSet) which means
101 that a stub is generated where users can insert their functionality. It is
102 important in which order you add your action_sets: The whole tree traversal
103 is a top-down/depth-first tree traversal. So all the enter, create, ...
104 operations of a action_set are invoked exactly in the order you add them to
105 the step. All the delete, leave, ... operations are invokved in reversed
108 I used to have a flag append_at_end with the default True, but this one is
109 now replaced, as each action set knows its priority.
119 You don't have to call this. It is automatically called once you add a step
120 to the project's steps.
138 Return max descend_invocation_order over all action sets associated with this step.
140 @see peano4.solversteps.ActionSet.descend_invocation_order
146 return self.
action_sets[-1].descend_invocation_order
151 Return minimum descend_invocation_order over all action sets associated with this step.
153 @see peano4.solversteps.ActionSet.descend_invocation_order
159 return self.
action_sets[0].descend_invocation_order
162 result = [
"marker",
"const peano4::datamanagement::VertexMarker&"]
164 result += [
"fineGridVertex" + i.name, i.get_full_qualified_type() +
"&"]
166 result += [
"coarseGridVertices" + i.name, i.get_enumeration_type() +
""]
168 result += [
"coarseGridFaces" + i.name, i.get_enumeration_type() +
""]
170 result += [
"coarseGridCell" + i.name, i.get_full_qualified_type() +
"&"]
174 result = [
"marker",
"const peano4::datamanagement::FaceMarker&"]
176 result += [
"fineGridVertices" + i.name, i.get_enumeration_type() +
""]
178 result += [
"fineGridFace" + i.name, i.get_full_qualified_type() +
"&"]
180 result += [
"coarseGridVertices" + i.name, i.get_enumeration_type() +
""]
182 result += [
"coarseGridFaces" + i.name, i.get_enumeration_type() +
""]
184 result += [
"coarseGridCell" + i.name, i.get_full_qualified_type() +
"&"]
188 result = [
"marker",
"const peano4::datamanagement::CellMarker&"]
190 result += [
"fineGridVertices" + i.name, i.get_enumeration_type() +
""]
192 result += [
"fineGridFaces" + i.name, i.get_enumeration_type() +
""]
194 result += [
"fineGridCell" + i.name, i.get_full_qualified_type() +
"&"]
196 result += [
"coarseGridVertices" + i.name, i.get_enumeration_type() +
""]
198 result += [
"coarseGridFaces" + i.name, i.get_enumeration_type() +
""]
200 result += [
"coarseGridCell" + i.name, i.get_full_qualified_type() +
"&"]
204 result = [
"marker",
"const peano4::datamanagement::CellMarker&"]
206 result += [
"fineGridVertices" + i.name, i.get_enumeration_type() +
""]
208 result += [
"fineGridFaces" + i.name, i.get_enumeration_type() +
""]
210 result += [
"fineGridCell" + i.name, i.get_full_qualified_type() +
"&"]
213 result += [
"coarseGridVertices" + i.name, i.get_enumeration_type() +
""]
215 result += [
"coarseGridFaces" + i.name, i.get_enumeration_type() +
""]
217 result += [
"coarseGridCell" + i.name, i.get_full_qualified_type() +
"&"]
223 Each solver step basically gives us two big files/classes: A class which
224 handles the actual data movements, i.e. is an implementation of the tree
225 visitor pattern over the Peano4 tree. The other type is an interface which
226 provides plugin points into the created data transitions from a user's
230 included_action_sets = []
235 included_action_sets.append(full_qualified_action_set_name)
highest_descend_invocation_order(self)
Return max descend_invocation_order over all action sets associated with this step.
get_vertex_operations_signature(self)
get_face_operations_signature(self)
set_project(self, project)
Tie step to project.
use_vertex(self, submodel)
lowest_descend_invocation_order(self)
Return minimum descend_invocation_order over all action sets associated with this step.
construct_output(self, output)
Each solver step basically gives us two big files/classes: A class which handles the actual data move...
get_touch_cell_signature(self)
__init__(self, name, add_user_defined_actions=True)
By default, the step generates at least one action set for the user.
get_cell_operations_signature(self)
remove_all_actions(self)
Each step holds a set of actions.
copy_action_sets_from_other_step(self, other_step)
__sort(self)
Simple bubble sort the action sets, such that their descend_invocation_order is preserved.
add_action_set(self, action_set)
Add a new action set to this mesh traversal step.