14from abc
import abstractmethod
29 Abstract solver for patch-based finite diffences
31 All solvers in ExaHyPE are cell-centered discretisations.
34 ## Adaptive mesh refinement
36 We have, at the moment, no hard-coded AMR operator set available unless
37 you work with an overlap of one. In this case, you find operators in the
38 toolbox. Very few pre-manufactured operators there are ready to go for
39 higher overlaps (the injection operator is an example). In general, you
40 will have to inject your own transfer operators.
42 It depends on the flavour that you want to use for your interpolation and
43 restriction. A simple interpolation for an overlap of three and a patch_size
46 self._interpolation = "tensor_product< " + self._name + ">"
47 self.add_solver_constants( "static constexpr double NormalInterpolationMatrix1d[] = {0.0, 1.0, 0.0};" )
48 self.add_solver_constants( " ""static constexpr double TangentialInterpolationMatrix1d[] = {
80 baseline_action_set_descend_invocation_order=0,
84 A unique name for the solver. This one will be used for all generated
85 classes. Also the C++ object instance later on will incorporate this
89 Size of the patch in one dimension. All stuff here's dimension-generic.
92 That's the size of the halo layer which is half of the overlap with a
93 neighbour. A value of 1 means that a patch_size x patch_size patch in
94 2d is surrounded by one additional cell layer. The overlap has to be
95 bigger or equal to one. It has to be smaller or equal to patch_size.
98 Number of unknowns per Finite Volume voxel.
100 auxiliary_variables: int
101 Number of auxiliary variables per Finite Volume voxel. Eventually, both
102 unknowns and auxiliary_variables are merged into one big vector if we
103 work with AoS. But the solver has to be able to distinguish them, as
104 only the unknowns are subject to a hyperbolic formulation.
106 min_meshcell_h: double
107 This size refers to the individual Finite Volume.
109 max_meshcell_h: double
110 This size refers to the individual Finite Volume.
112 plot_grid_properties: Boolean
113 Clarifies whether a dump of the data should be enriched with grid info
114 (such as enclave status flags), too.
127 self._unknowns and self._auxiliary_variables respectively hold the number of unknowns and
128 auxiliary variables in the equation to be computed. Unknowns are variables that change over
129 time whereas auxiliary variables can be space-dependent but don't vary over time.
130 These can be specified either as simple ints or by a dictionary
131 (e.g.) unknowns = {'a': 1, 'b': 1, 'c': 3}
132 in which the user specifies the multiplicity of the variable (the velocity has one component
133 per dimension for example.)
134 If they are specified by a dictionary then the code generates a "VariableShortcuts" file which
135 allows the user to specifiy a variable by name and automatically maps this to the right position
136 in an array for better legibility. Otherwise they must manually remember the position of each
139 use_var_shortcut is used to know whether or not the user passed their variables via a dict
140 variable_names and variable_pos are used internally to remember the names and respective
141 positions of variables if set by a dictionary.
147 if type(unknowns)
is dict:
150 for var
in list(unknowns.values()):
153 elif type(unknowns)
is int:
157 "not a valid type for parameter unknowns, needs to be int or dictionary"
160 if type(auxiliary_variables)
is dict:
163 for var
in list(auxiliary_variables.values()):
166 elif type(auxiliary_variables)
is int:
170 "not a valid type for parameter auxiliary_variables, needs to be int or dictionary"
179 if min_meshcell_h > max_meshcell_h:
181 "Error: min_meshcell_h ("
182 + str(min_meshcell_h)
183 +
") is bigger than max_meshcell_h ("
184 + str(max_meshcell_h)
189 peano4.toolbox.blockstructured.ReconstructedArrayMemoryLocation.CallStack
252 + self.__class__.__name__
257Runge-Kutta order: """
266Auxiliary variables: """
282 coarsest_tree_level = 0
284 domain_size * 3 ** (-coarsest_tree_level) / self.
_patch_size
287 coarsest_tree_level += 1
288 return coarsest_tree_level
291 finest_tree_level = 0
293 domain_size * 3 ** (-finest_tree_level) / self.
_patch_size
296 finest_tree_level += 1
297 return finest_tree_level
330Real type of this solver: """
334We assume that you use a domain size of (0,"""
336 +
""")^d. Peano 4 will cut this domain equidistantly
337and recursively into three parts along each coordinate axis. This yields a spacetree.
339The spacetree will at least have """
342The spacetree will at most have """
346The spacetree will thus span at least """
348 +
""" octants/cells (see clarification below) per coordinate axis. This means a """
350 +
"""^d grid of octants.
351The spacetree will thus span at most """
353 +
""" octants/cells (see clarification below) per coordinate axis. This means a """
355 +
"""^d grid of octants.
359 +
"""^d patches of compute cells into the finest tree level.
360In the text above, we refer to the elements of this level of the tree as octants.
361The octants are squares/cubes and many papers refer to them as cells, but they are not
362the actual compute data structure. The compute data structure is the cells that
363are embedded into these finest level spacetree cells. We therefore prefer the
364term octant for the latter, whereas we use the term (compute) cell for the
365entities that are actually used for the computations, i.e. hold degrees of
366freedom, and are actually visible within Paraview, e.g.
368The coarsest possible mesh will consist of """
370 +
""" compute cells per coordinate axis.
371The finest possible mesh will consist of """
373 +
""" compute cells per coordinate axis.
375The coarsest mesh width of """
377 +
""" is thus just smaller than the maximum mesh size """
380The finest mesh width of """
382 +
""" is thus just smaller than the minimum mesh size """
393 Add further includes to this property, if your action sets require some additional
394 routines from other header files.
403 Add further includes to this property, if your solver requires some additional
404 routines from other header files.
412 Return number of steps required to realise the Runge-Kutta scheme
414 Delegate to ButcherTableau.RungeKutta_steps, which tells us for a given
415 polynomial order _rk_order how many Runge Kutta steps we have to
424 Add further includes to this property, if your action sets require some additional
425 routines from other header files.
433 Add further includes to this property, if your solver requires some additional
434 routines from other header files.
443 Recall in subclasses if you wanna change the number of unknowns
444 or auxiliary variables. See class description's subsection on
447 :: Call order and ownership
449 This operation can be called multiple times. However, only the very
450 last call matters. All previous calls are wiped out.
452 If you have a hierarchy of solvers, every create_data_structure()
453 should first(!) call its parent version. This way, you always ensure
454 that all data are in place before you continue to alter the more
455 specialised versions. So it is (logically) a top-down (general to
456 specialised) run through all create_data_structure() variants
457 within the inheritance tree.
462 _patch: Patch (NxNxN)
463 Actual patch data. We use Finite Volumes, so this is
464 always the current snapshot, i.e. the valid data at one point.
466 _patch_overlap_old, _patch_overlap_new: Patch (2xNxN)
467 This is a copy/excerpt from the two adjacent finite volume
468 snapshots plus the old data as backup. If I want to implement
469 local timestepping, I don't have to backup the whole patch
470 (see _patch), but I need a backup of the face data to be able
471 to interpolate in time.
473 _patch_overlap_update: Patch (2xNxN)
474 This is hte new update. After the time step, I roll this
475 information over into _patch_overlap_new, while I backup the
476 previous _patch_overlap_new into _patch_overlap_old. If I
477 worked with regular meshes only, I would not need this update
478 field and could work directly with _patch_overlap_new. However,
479 AMR requires me to accumulate data within new while I need
480 the new and old data temporarily. Therefore, I employ this
481 accumulation/roll-over data which usually is not stored
582 assert False,
"storage variant {} not supported".format(
587 peano4.toolbox.blockstructured.get_face_merge_implementation(
592 peano4.toolbox.blockstructured.get_face_merge_implementation(
596 self.
_patch.generator.merge_method_definition = (
597 peano4.toolbox.blockstructured.get_cell_merge_implementation(self.
_patch)
601#include "peano4/utils/Loop.h"
602#include "repositories/SolverRepository.h"
605#include "peano4/utils/Loop.h"
606#include "repositories/SolverRepository.h"
609 self.
_patch.generator.load_store_compute_flag =
"::peano4::grid::constructLoadStoreComputeFlag({},{},{})".format(
615 self.
_patch_estimates.generator.load_store_compute_flag =
"::peano4::grid::constructLoadStoreComputeFlag({},{},{})".format(
630 self.
_patch_overlap_old.generator.load_store_compute_flag =
"::peano4::grid::constructLoadStoreComputeFlag({},{},{})".format(
636 self.
_patch_overlap_new.generator.load_store_compute_flag =
"::peano4::grid::constructLoadStoreComputeFlag({},{},{})".format(
642 self.
_patch_overlap_update.generator.load_store_compute_flag =
"::peano4::grid::constructLoadStoreComputeFlag({},{},{})".format(
648 self.
_patch.generator.includes +=
"""
649#include "../repositories/SolverRepository.h"
652#include "../repositories/SolverRepository.h"
655#include "../repositories/SolverRepository.h"
658#include "../repositories/SolverRepository.h"
661#include "../repositories/SolverRepository.h"
671 Create required action sets
673 Overwrite in subclasses if you wanna create different
676 ## Call order and ownership
678 This operation can be called multiple times. However, only the very
679 last call matters. All previous calls are wiped out.
681 If you have a hierarchy of solvers, every create_data_structure()
682 should first(!) call its parent version. This way, you always ensure
683 that all data are in place before you continue to alter the more
684 specialised versions. So it is (logically) a top-down (general to
685 specialised) run through all create_data_structure() variants
686 within the inheritance tree.
688 :: Recreation vs backup (state discussion)
690 We faced some issues with action sets that should not be
691 overwritten. For example, the postprocessing should not be overwritten
692 as users might want to set it and then later on reset the number of
693 unknowns, e.g. In this case, you would loose your postprocessing if
694 create_action_sets() recreated them. So I decided to make an exception
695 here: the postprocessing step is never overwritten by the standard
698 There are further action sets which have a state, which users might
699 want to alter. The most prominent one is the AMR routines, where users
700 often alter the interpolation and restriction scheme. Here, things are
701 tricky: If we keep the default one, the action set would not pick up
702 if you changed the number of unknowns, e.g. However, if we recreated
703 the action set, we'd miss out on any changed interpolation/restriction
704 scheme. Therefore, I have to hold the interpolation and restriction
707 ## Injecting your own guards
709 If you inject your own guards, you should combine them with a storage
710 predicate, i.e. _store_cell_data_default_guard() and
711 _load_cell_data_default_guard(). The action sets themselves will not
712 combine the guard with further boolean expressions. Also, you have to
713 study carefully if a predicate accepts a unique guard or a set of
719 All action sets are given the right (default) priorities in this step.
720 You can alter them in subclasses, but it might be more appropriate to
721 set the priorities of your own action sets relative to the existing
722 ones using self._baseline_action_set_descend_invocation_order.
738 build_up_new_refinement_instructions=
True,
739 implement_previous_refinement_instructions=
True,
740 called_by_grid_construction=
False,
746 build_up_new_refinement_instructions=
False,
747 implement_previous_refinement_instructions=
True,
748 called_by_grid_construction=
False,
755 build_up_new_refinement_instructions=
True,
756 implement_previous_refinement_instructions=
True,
757 called_by_grid_construction=
True,
851 "not marker.willBeRefined() "
852 +
"and repositories::"
854 +
".getSolverState()!="
856 +
"::SolverState::GridConstruction"
861 "not marker.willBeRefined() "
862 +
"and repositories::"
864 +
".getSolverState()!="
866 +
"::SolverState::GridConstruction"
872 Extend the guard via ands only. Never use an or, as subclasses might
873 extend it as well, and they will append further ends.
877 "not marker.willBeRefined() "
878 +
"and repositories::"
880 +
".getSolverState()!="
882 +
"::SolverState::GridConstruction"
888 Extend the guard via ands only. Never use an or, as subclasses might
889 extend it as well, and they will append further ends.
893 "not marker.hasBeenRefined() "
894 +
"and repositories::"
896 +
".getSolverState()!="
898 +
"::SolverState::GridConstruction "
899 +
"and repositories::"
901 +
".getSolverState()!="
903 +
"::SolverState::GridInitialisation"
909 Extend the guard via ands only. Never use an or, as subclasses might
910 extend it as well, and they will append further ends.
914 "not marker.willBeRefined() "
915 +
"and repositories::"
917 +
".getSolverState()!="
919 +
"::SolverState::GridConstruction"
925 Extend the guard via ands only. Never use an or, as subclasses might
926 extend it as well, and they will append further ends.
930 "not marker.hasBeenRefined() "
931 +
"and repositories::"
933 +
".getSolverState()!="
935 +
"::SolverState::GridConstruction "
936 +
"and repositories::"
938 +
".getSolverState()!="
940 +
"::SolverState::GridInitialisation"
944 return self.
_name +
"Q"
947 return "instanceOf" + self.
_name
952 Add all required data to the Peano4 project's datamodel
953 so it is properly built up
960 print(
"Patch overlap data")
963 print(
"Patch overlap data")
967 datamodel.add_cell(self.
_patch)
976 Tell Peano what data to move around
978 Inform Peano4 step which data are to be moved around via the
979 use_cell and use_face commands. This operation is generic from
980 ExaHyPE's point of view, i.e. I use it for all grid sweep types.
983 step.use_cell(self.
_patch)
993#include "tarch/la/Vector.h"
995#include "peano4/utils/Globals.h"
996#include "peano4/utils/Loop.h"
998#include "repositories/SolverRepository.h"
1004 Add your actions to init grid
1006 The AMR stuff has to be the very first thing. Actually, the AMR routines'
1007 interpolation doesn't play any role here. But the restriction indeed is
1008 very important, as we have to get the face data for BCs et al. The action
1009 set order is inverted while we ascend within the tree again. Therefore, we
1010 add the AMR action set first which means it will be called last when we go
1011 from fine to coarse levels within the tree.
1013 The projection onto the faces is a postprocessing step. This is different
1014 to DG, where we need face data for the current time step's solution. Here,
1015 we ensure that all halos are valid for the subsequent time step again.
1019 The order of the action sets is preserved throughout the steps down within
1020 the tree hierarchy. It is inverted throughout the backrolling.
1022 This is what we want to achieve:
1024 - Project solution onto faces. This happens in touchCellLastTime(). See
1025 exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces for comments.
1026 The project will end up in QUpdate.
1027 - Roll updates over on the faces from QUpdate into Q_new. This is done
1028 by RollOverUpdateFace, which requires in turn that the getUpdated()
1029 flag is set. As the roll-over plugs into touchFaceLastTime(), it will
1030 always be called after the projection, since the latter is a cell
1032 - Copy new face data Q_new into old face data Q_old, as this is the
1033 initial sweep, i.e. the old face data otherwise might hold rubbish.
1034 This is a backup operation realised through the action set
1035 BackupPatchOverlap. This one plugs into touchFaceLastTime() too.
1036 Therefore, it is important that its priority is smaller than the one
1037 of the roll-over, since we invert the call order for the touch-last
1039 - Restrict the data to the coarser level if we are on a hanging face.
1048 if restart_from_checkpoint:
1056 step.add_action_set(
1071 The boundary information is set only once. It is therefore important that
1072 we ues the face label and initialise it properly.
1078 if evaluate_refinement_criterion:
1089 @plot_description.setter
1093 Use this one to set a description within the output patch file that tells
1094 the vis solver what the semantics of the entries are. Typicallly, I use
1095 a comma-separated list here.
1103 Add action sets to plotting grid sweep
1105 Consult the discussion in add_actions_to_init_grid() around the order
1106 of the individual action sets.
1109 ## Adaptive mesh refinement
1111 It is important that we have the coupling/dynamic AMR part in here, as
1112 there might be pending AMR refinement requests that now are realised.
1113 For the same reason, we need the update of the face label and the update
1114 of the cell label in here: The AMR might just propagate over into the
1115 plotting, i.e. we might create new grid entities throughout the plot.
1116 These entities (faces and cells) have to be initialised properly.
1117 Otherwise, their un-initialised data will propagate through to the next
1120 To make the restriction work, we have to project the solutions onto the
1124 ## Roll over face data
1126 Das ist ein Kaese, weil das nur einspringt, wenn project wahr ist
1134 step.add_action_set(
1143 filename=output_path +
"solution-" + self.
_name,
1147 guard=
"repositories::plotFilter.plotPatch(marker) and "
1149 additional_includes=
"""
1150#include "exahype2/PlotFilter.h"
1151#include "../repositories/SolverRepository.h"
1153 precision=
"PlotterPrecision",
1154 time_stamp_evaluation=
"0.5*(repositories::getMinTimeStamp()+repositories::getMaxTimeStamp())",
1156 restart_preprocess=restart_from_checkpoint
1159 step.add_action_set(plot_patches_action_set)
1163 filename=output_path +
"grid-" + self.
_name,
1165 guard=
"repositories::plotFilter.plotPatch(marker) and "
1167 additional_includes=
"""
1168#include "exahype2/PlotFilter.h"
1169#include "../repositories/SolverRepository.h"
1173 step.add_action_set(plot_grid_action_set)
1180 Add action sets to checkpoint grid sweep
1182 Consult the discussion in add_actions_to_init_grid() around the order
1183 of the individual action sets.
1186 ## Adaptive mesh refinement
1188 It is important that we have the coupling/dynamic AMR part in here, as
1189 there might be pending AMR refinement requests that now are realised.
1190 For the same reason, we need the update of the face label and the update
1191 of the cell label in here: The AMR might just propagate over into the
1192 plotting, i.e. we might create new grid entities throughout the plot.
1193 These entities (faces and cells) have to be initialised properly.
1194 Otherwise, their un-initialised data will propagate through to the next
1197 To make the restriction work, we have to project the solutions onto the
1201 ## Roll over face data
1203 Das ist ein Kaese, weil das nur einspringt, wenn project wahr ist
1211 step.add_action_set(
1220 filename=output_path +
"checkpoint-" + self.
_name,
1225 additional_includes=
"""
1226#include "../repositories/SolverRepository.h"
1228 precision=
"PlotterPrecision",
1229 time_stamp_evaluation=
"0.5*(repositories::getMinTimeStamp()+repositories::getMaxTimeStamp())",
1231 restart_preprocess=restart_from_checkpoint
1234 step.add_action_set(checkpoint_patches_action_set)
1238 filename=output_path +
"grid-" + self.
_name,
1241 additional_includes=
"""
1242#include "../repositories/SolverRepository.h"
1246 step.add_action_set(checkpoint_grid_action_set)
1255 It is important that we do the inter-grid transfer operators before we
1256 apply the boundary conditions.
1264 step.add_action_set(
1284 The ExaHyPE2 project will call this operation when it sets
1285 up the overall environment.
1287 This routine is typically not invoked by a user.
1289 output: peano4.output.Output
1292 templatefile_prefix = os.path.dirname(os.path.realpath(__file__)) +
"/"
1294 if self._solver_template_file_class_name
is None:
1295 templatefile_prefix += self.__class__.__name__
1297 templatefile_prefix += self._solver_template_file_class_name
1302 abstractHeaderDictionary = {}
1303 implementationDictionary = {}
1304 self._init_dictionary_with_default_parameters(abstractHeaderDictionary)
1305 self._init_dictionary_with_default_parameters(implementationDictionary)
1306 self.add_entries_to_text_replacement_dictionary(abstractHeaderDictionary)
1307 self.add_entries_to_text_replacement_dictionary(implementationDictionary)
1309 generated_abstract_header_file = (
1311 templatefile_prefix +
"Abstract.template.h",
1312 templatefile_prefix +
"Abstract.template.cpp",
1313 "Abstract" + self._name,
1316 abstractHeaderDictionary,
1321 generated_solver_files = (
1323 templatefile_prefix +
".template.h",
1324 templatefile_prefix +
".template.cpp",
1328 implementationDictionary,
1334 output.add(generated_abstract_header_file)
1335 output.add(generated_solver_files)
1336 output.makefile.add_h_file(subdirectory +
"Abstract" + self._name +
".h", generated=
True)
1337 output.makefile.add_h_file(subdirectory + self._name +
".h", generated=
True)
1338 output.makefile.add_cpp_file(subdirectory +
"Abstract" + self._name +
".cpp", generated=
True)
1339 output.makefile.add_cpp_file(subdirectory + self._name +
".cpp", generated=
True)
1341 if self._use_var_shortcut:
1343 os.path.dirname(os.path.realpath(__file__))
1345 +
"../VariableShortcuts.template.h",
1346 "VariableShortcuts",
1349 implementationDictionary,
1353 output.add(generated_shortcut_file)
1354 output.makefile.add_h_file(subdirectory +
"VariableShortcuts.h", generated=
True)
1364 This one is called by all algorithmic steps before I invoke
1365 add_entries_to_text_replacement_dictionary().
1367 See the remarks on set_postprocess_updated_patch_kernel to understand why
1368 we have to apply the (partially befilled) dictionary to create a new entry
1369 for this very dictionary.
1371 d[
"NUMBER_OF_GRID_CELLS_PER_PATCH_PER_AXIS"] = self.
_patch.dim[0]
1377 d[
"SOLVER_NAME"] = self.
_name
1379 d[
"NUMBER_OF_UNKNOWNS"] = self.
_unknowns
1381 d[
"SOLVER_NUMBER"] = 22
1383 d[
"ASSERTION_WITH_1_ARGUMENTS"] =
"nonCriticalAssertion1"
1384 d[
"ASSERTION_WITH_2_ARGUMENTS"] =
"nonCriticalAssertion2"
1385 d[
"ASSERTION_WITH_3_ARGUMENTS"] =
"nonCriticalAssertion3"
1386 d[
"ASSERTION_WITH_4_ARGUMENTS"] =
"nonCriticalAssertion4"
1387 d[
"ASSERTION_WITH_5_ARGUMENTS"] =
"nonCriticalAssertion5"
1388 d[
"ASSERTION_WITH_6_ARGUMENTS"] =
"nonCriticalAssertion6"
1391 raise Exception(
"min/max h are inconsistent")
1400 "BOUNDARY_CONDITIONS_IMPLEMENTATION"
1403 "REFINEMENT_CRITERION_IMPLEMENTATION"
1407 d[
"COMPUTE_KERNEL_CALL"] = jinja2.Template(
1415 d[
"ABSTRACT_SOLVER_USER_DECLARATIONS"] = jinja2.Template(
1418 d[
"ABSTRACT_SOLVER_USER_DEFINITIONS"] = jinja2.Template(
1421 d[
"SOLVER_USER_DECLARATIONS"] = jinja2.Template(
1424 d[
"SOLVER_USER_DEFINITIONS"] = jinja2.Template(
1427 d[
"START_TIME_STEP_IMPLEMENTATION"] = jinja2.Template(
1430 d[
"FINISH_TIME_STEP_IMPLEMENTATION"] = jinja2.Template(
1433 d[
"CONSTRUCTOR_IMPLEMENTATION"] = jinja2.Template(
1437 d[
"PREPROCESS_RECONSTRUCTED_PATCH"] = jinja2.Template(
1440 d[
"POSTPROCESS_UPDATED_PATCH"] = jinja2.Template(
1444 d[
"COMPUTE_TIME_STEP_SIZE"] = jinja2.Template(
1447 d[
"COMPUTE_NEW_TIME_STEP_SIZE"] = jinja2.Template(
1482 @auxiliary_variables.setter
1492 @preprocess_reconstructed_patch.setter
1496 Please consult exahype2.solvers.fv.FV.preprocess_reconstructed_patch() for
1497 a documentation on this routine.
1512 @postprocess_updated_patch.setter
1516 Define a postprocessing routine over the data
1518 The postprocessing kernel often looks similar to the following code:
1522 dfor( volume, {{NUMBER_OF_GRID_CELLS_PER_PATCH_PER_AXIS}} ) {
1523 enforceCCZ4constraints( newQ+index );
1524 index += {{NUMBER_OF_UNKNOWNS}} + {{NUMBER_OF_AUXILIARY_VARIABLES}};
1529 Within this kernel, you have at least the following variables available:
1531 - newQ This is a pointer to the whole data structure (one large
1533 The patch is not supplemented by a halo layer.
1534 - oldQWithHalo This is a pointer to the data snapshot before the
1535 actual update. This data is combined with the halo layer, i.e. if you
1536 work with 7x7 patches and a halo of 2, the pointer points to a 11x11
1540 Furthermore, you can use all the symbols (via Jinja2 syntax) from
1541 _init_dictionary_with_default_parameters().
1544 C++ code that holds the postprocessing kernel
1559 "Halo (overlap) size has to be bigger than zero but was {}".format(
1571 @interpolation.setter
1575 Set the interpolation scheme. If you rely on a built-in operation, then this
1576 call is all you have to do. Some ExaHyPE solvers however require each solver
1577 to provide special matrices/operators for some interpolation/restriction
1578 variants. If this is the case, you still have to add these matrices manually
1591 Set the restriction scheme. If you rely on a built-in operation, then this
1592 call is all you have to do. Some ExaHyPE solvers however require each solver
1593 to provide special matrices/operators for some interpolation/restriction
1594 variants. If this is the case, you still have to add these matrices manually
1609 cell_data_storage: Storage,
1610 face_data_storage: Storage,
1614 By default, we hold all data on the call stacks. You can explicitly switch
1615 to storage on the heap via smart pointers.
1617 @see create_data_structures()
1620 assert isinstance(cell_data_storage, Storage)
1621 assert isinstance(face_data_storage, Storage)
Update the cell label within a sweep.
Abstract solver for patch-based finite diffences.
_abstract_solver_user_definitions
add_actions_to_create_grid(self, step, evaluate_refinement_criterion)
The boundary information is set only once.
_load_face_data_default_guard(self)
Extend the guard via ands only.
_provide_cell_data_to_compute_kernels_default_guard(self)
get_min_number_of_spacetree_levels(self, domain_size)
postprocess_updated_patch(self)
_action_set_project_patch_onto_faces
_preprocess_reconstructed_patch
_action_set_initial_conditions_for_grid_construction
_user_action_set_includes
set_solver_constants(self, datastring)
add_actions_to_perform_time_step(self, step)
AMR.
_store_cell_data_default_guard(self)
Extend the guard via ands only.
add_user_solver_includes(self, value)
Add further includes to this property, if your solver requires some additional routines from other he...
create_readme_descriptor(self, domain_offset, domain_size)
_reconstruction_kernel_call
_action_set_update_face_label
_action_set_postprocess_solution
_action_set_roll_over_update_of_faces
user_action_set_includes(self)
Add further includes to this property, if your action sets require some additional routines from othe...
_postprocess_updated_patch
_provide_face_data_to_compute_kernels_default_guard(self)
_load_cell_data_default_guard(self)
Extend the guard via ands only.
auxiliary_variables(self)
get_max_number_of_spacetree_levels(self, domain_size)
_action_set_couple_resolution_transitions_and_handle_dynamic_mesh_refinement
add_implementation_files_to_project(self, namespace, output, dimensions, subdirectory="")
The ExaHyPE2 project will call this operation when it sets up the overall environment.
_finish_time_step_implementation
get_name_of_global_instance(self)
add_to_Peano4_datamodel(self, datamodel, verbose)
Add all required data to the Peano4 project's datamodel so it is properly built up.
add_actions_to_checkpoint_solution(self, step, output_path, restart_from_checkpoint=False)
Add action sets to checkpoint grid sweep.
switch_storage_scheme(self, Storage cell_data_storage, Storage face_data_storage)
By default, we hold all data on the call stacks.
_start_time_step_implementation
__init__(self, name, patch_size, overlap, rk_order, unknowns, auxiliary_variables, min_meshcell_h, max_meshcell_h, plot_grid_properties, kernel_namespace, baseline_action_set_descend_invocation_order=0)
name: string A unique name for the solver.
_compute_new_time_step_size
number_of_Runge_Kutta_steps(self)
Return number of steps required to realise the Runge-Kutta scheme.
_solver_user_declarations
_solver_template_file_class_name
add_actions_to_init_grid(self, step, restart_from_checkpoint=False)
Add your actions to init grid.
_baseline_action_set_descend_invocation_order
user_solver_includes(self)
Add further includes to this property, if your solver requires some additional routines from other he...
_action_set_update_cell_label
_init_dictionary_with_default_parameters(self, d)
This one is called by all algorithmic steps before I invoke add_entries_to_text_replacement_dictionar...
add_solver_constants(self, datastring)
_primary_variables_indices
_abstract_solver_user_declarations
_boundary_conditions_implementation
create_data_structures(self)
Recall in subclasses if you wanna change the number of unknowns or auxiliary variables.
get_coarsest_compute_grid_cell_size(self, domain_size)
get_finest_number_of_patches(self, domain_size)
_action_set_initial_conditions
_get_default_includes(self)
get_coarsest_number_of_patches(self, domain_size)
_reconstructed_array_memory_location
_action_set_AMR_commit_without_further_analysis
_unknown_identifier(self)
_action_set_preprocess_solution
create_action_sets(self)
Create required action sets.
add_user_action_set_includes(self, value)
Add further includes to this property, if your action sets require some additional routines from othe...
_store_face_data_default_guard(self)
Extend the guard via ands only.
get_finest_number_of_compute_grid_cells(self, domain_size)
get_coarsest_number_of_compute_grid_cells(self, domain_size)
add_use_data_statements_to_Peano4_solver_step(self, step)
Tell Peano what data to move around.
_action_set_handle_boundary
add_entries_to_text_replacement_dictionary(self, d)
restriction(self)
Set the restriction scheme.
_action_set_compute_final_linear_combination
add_actions_to_plot_solution(self, step, output_path, restart_from_checkpoint=False)
Add action sets to plotting grid sweep.
_auxiliary_variables_indices
_action_set_copy_new_faces_onto_old_faces
preprocess_reconstructed_patch(self)
get_finest_compute_grid_cell_size(self, domain_size)
_initial_conditions_implementation
_action_set_AMR_throughout_grid_construction
_constructor_implementation
_refinement_criterion_implementation
The action set to realise AMR.
The handling of (dynamically) adaptive meshes for finite differences.
The global periodic boundary conditions are set in the Constants.h.
PostprocessSolution differs from other action sets, as I only create it once.
PreprocessSolution differs from other action sets, as I only create it once.
Project patch data onto faces, so the faces hold valid data which can feed into the subsequent Runge-...
Roll over QUpdate data on face into QNew.
Realise patch via smart pointers.
Realise patch via smart pointers.
Very simple converter which maps the patch 1:1 onto a double array.