peano4.api.taskgraph.Runner Namespace Reference

Functions
	create_runner (peano_project, identifier, steps)
	Create the header/implementation file pair that represents one of a project's algorithmic phases represented by a sequence of steps.

Variables
str	TEMPLATE_RUNNER_HEADER_FILE
str	TEMPLATE_RUNNER_CPP_FILE

Function Documentation

create_runner()

peano4.api.taskgraph.Runner.create_runner	(		peano_project,
			identifier,
			steps
	)

Create the header/implementation file pair that represents one of a project's algorithmic phases represented by a sequence of steps.

It yields one class of the classname identifier which is held in the project's runners subdirectory/namespace. This class holds exactly one method run() which toggles through the steps one by one.

Even though the runner seems to accept only a sequence of steps (which are members of peano4.api.solversteps), the runner belongs into the task graph repository, as it assumes that each step has a field has_to_repeat. This field is not defined within peano4.api.solversteps.Step. It is something graph compilers add to the data model. Consult the compiler description in peano4.api.taskgraph.compiler.

peano_project: peano4.api.Project The Peano 4 project to add the generated files to.

identifier: str Same identifier used for the phase's Observers, e.g. "SetupSimulation", "TimeStep", "Plot".

steps: [peano4.api.solversteps.Step] The sequence of Observers realising this algorithmic phase, in the order compiled from the phase's task graph (

See also

peano4.api.taskgraph.compiler.Sequential.translate). Its first element's name is the repositories::StepRepository::Steps enumerator the generated runner hands to peano4::RunMultipleSteps's constructor to kick the phase off. run() instantiates each step's Observer in turn and traverses the spacetree set with it, switching the log filter's program phase beforehand, bracketing the traversal itself with that Observer's own static prepareTraversal()/ unprepareTraversal() (

peano4.api.output.Observer - the spacetree set never calls these itself, so the runner is exactly the "up to the user" call site its own doc comment asks for), and timing the traversal via the inherited _watch/_runtimeMeasurement. "Undef" (and no traversals at all) if the phase has no steps, e.g. no solver contributed to it, so the generated code still compiles.

Before every step but the first, run() also calls peano4::parallel::Node::getInstance().setNextProgramStep(...) with that step's own program step - whoever calls run() in the first place already had to set Node's program step to this phase's first step beforehand (

See also

getFirstSubstep(), used exactly that way in exahype2.api.generators.DefaultSimulationMain), so run() only asserts on it there rather than setting it again; every subsequent step within the same phase has nothing else to set it, so run() must do so itself. This is what makes peano4::parallel::Node::getInstance().getCurrentProgramStep() reliable for every step, not just a phase's first - in particular, it is what the guard expressions peano4.api.taskgraph.compiler.DeriveLoadStoreComputeFlag builds actually depend on at runtime.

Definition at line 94 of file Runner.py.

Variable Documentation

TEMPLATE_RUNNER_CPP_FILE

str peano4.api.taskgraph.Runner.TEMPLATE_RUNNER_CPP_FILE

Definition at line 32 of file Runner.py.

TEMPLATE_RUNNER_HEADER_FILE

str peano4.api.taskgraph.Runner.TEMPLATE_RUNNER_HEADER_FILE

Initial value:

=  """
// This file is part of the ExaHyPE2 project. For conditions of distribution and
// use, please see the copyright notice at www.peano-framework.org
#pragma once
 
#include "peano4/RunMultipleSteps.h"
 
{% for item in NAMESPACE -%}
namespace {{ item }} {
{%- endfor %}
  class {{CLASSNAME}};
{% for item in NAMESPACE -%}
}
{%- endfor %}
 
 
class {{NAMESPACE | join("::")}}::{{CLASSNAME}}: public peano4::RunMultipleSteps {
  public:
    {{CLASSNAME}}();
 
    virtual void run() override;
  private:
    static tarch::logging::Log _log;
};
"""

Definition at line 6 of file Runner.py.