MADNESS 0.10.1
|
Declares the macrotaskq
and MacroTaskBase classes.
More...
#include <madness/world/cloud.h>
#include <madness/world/world.h>
#include <madness/mra/macrotaskpartitioner.h>
Go to the source code of this file.
Namespaces | |
namespace | madness |
Namespace for all elements and tools of MADNESS. | |
Functions | |
template<typename tupleT , std::size_t I> | |
constexpr bool | madness::check_tuple_is_valid_task_result () |
given a tuple check recursively if all elements are valid task results | |
template<typename T > | |
void | madness::gaxpy (const double a, ScalarResult< T > &left, const double b, const T &right, const bool fence=true) |
the result type of a macrotask must implement gaxpy | |
template<typename T > | |
std::vector< ScalarResult< T > > | madness::scalar_result_vector (World &world, std::size_t n) |
helper function to create a vector of ScalarResultImpl, circumventing problems with the constructors | |
Variables | |
template<typename T > | |
constexpr bool | madness::is_valid_task_result_v |
check if type is a valid task result: it must be a WorldObject and must implement gaxpy | |
Declares the macrotaskq
and MacroTaskBase classes.
A MacroTaskq executes tasks on World objects, e.g. differentiation of a function or other arithmetic. Complex algorithms can be implemented.
The universe world is split into subworlds, each of them executing macrotasks of the task queue. This improves locality and speedups for large number of compute nodes, by reducing communications within worlds.
The user defines a macrotask (an example is found in test_vectormacrotask.cc), the tasks are lightweight and carry only bookkeeping information, actual input and output are stored in a cloud (see cloud.h)
The user-defined macrotask is derived from MacroTaskIntermediate and must implement the run() method. A heterogeneous task queue is possible.
The result of a macrotask is an object that lives in the universe and that is accessible from all subworlds. The result is accumulated in the universe and must therefore be a WorldObject. Currently we have implemented
TODO: priority q TODO: task submission from inside task (serialize task instead of replicate) TODO: update documentation TODO: consider serializing task member variables