Parallel 2D adaptive mesh refinement (AMR) with data using PABLO.
Parallel 2D adaptive mesh refinement (AMR) with data using PABLO The example is the parallel version of PABLO_example_00004.
Here the main focus is on the load-balance of both grid and data. The grid is refined several times together with the data and their inheritance follows the same rules like in example 00004. Until the last refinement no parallel paradigm is in action: every process owns the entire grid.
After this refinement, the load-balance with data is introduced, giving as result a parallel distribution of grid and data.
Even a constant vector of weight is used, in order to show that the loadBalance can be performed by using a weight function for each cell.
The user data communication interfaces are based on the Couriously Recurrent Template Pattern. The user has to implement a specification of the interface by writing a derived class. In the files PABLO_userDataLB.hpp and PABLO_userDataLB.tpp an example of this specification is given in the case of user data stored in a POD container similar to the STL vector.
The class in PABLO_userDataLB.hpp is an example of user specification of the load blance data communication interface based on the Curiously Recurrent Template Pattern. The user has to implement his interface class(es) in order to define how his data have to be written and read in the communication buffer. These classes have to be derived from the template base class bitpit::DataLBInterface using as template argument value the derived class. Like this,
The choice of the members of the class is completely up to the user and they have to be useful to access both internal and ghost data container. In the example user data datatype is given as template parameter in order to pass any container similar to the STL vector.
In any case, the user must at least implement all the methods reported in this example:
size_t fixedsize() method: this method is automatically called by the manager and it is intended to define the constant size of the data to be communicated per grid element. If all the element of the grid communicate the same size of data, this method must return a value different from zero and equal to the number of byte to be communicated for every element. Otherwise, it must return zero and the different data size for each element must be specified by the size method. Example: size_t size(const uint32_t e) method: this method is automatically called by the manager and it is intended to define the variable size of the data to be communicated of every grid element. In order to make the manager use this method, the fixedsize method has to return zero. Implementing this method, the user can pass to the manager the specific data size to be communicated for the element e. | [in] | index | of the internal element to be communicated. |
void move(const uint32_t from, const uint32_t to) method: this method is automatically called by the manager and it is intended to move data inside the internal data container. | [in] | from | index of the element whose data have to be moved to to. |
| [in] | to | index of the element where the from data have to be placed in. |
void gather(Buffer& buff, const uint32_t e) method: this method is automatically called by the manager and it is intended to write user data to the char communication buffer. The user has to specify in its implementation the way data can be read from the char buffer. The manager provide the user with a buffer and its read method in order to simply read POD data from the buffer. The user has to define the way his data can be read from the buffer by decomposing them in POD data and by using the buffer read method to take them from the buffer and to store them in the ghost data container. In this example we suppose that data is a container of POD data having the random access operator. | [in] | e | index of the ghost element to be communicated. |
| [in] | buff | is the char buffer used to communicate user data. The user has not to take care of the buffer, but its method write and read. These methods are intended to write/read POD data to/fromthe buffer. |
void scatter(Buffer& buff, const uint32_t e) method: this method is automatically called by the manager and it is intended to read user data from the char communication buffer and store them in the data container. The user has to specify in its implementation the way data can be read from the char buffer. The manager provide the user with a buffer and its read method in order to simply read POD data from the buffer. The user has to define the way his data can be read from the buffer by decomposing them in POD data and by using the buffer read method to take them from the buffer and to store them in the ghost data container. In this example we suppose that data is a container of POD data having the random access operator. | [in] | e | index of the element to be communicated. |
| [in] | buff | is the char buffer used to communicate user data. The user has not to take care of the buffer, but its method write and read. These methods are intended to write/read POD data to/fromthe buffer. |
void assign(uint32_t stride, uint32_t length) method: this method is automatically called by the manager and it intended to be used during the static load balance. At the beginning of any application of the this manager, the entire grid is on every MPI process. At the first load balance the grid is partitioned and distributed to the processes. Data are distributed using this method, by assigning the right length to the the process starting from the right stride. The user has to tell the manager how to start reading the length of data from the stride position and how to put only these data in the same container, deleting the rest. It is a restriction operation of the container to a contiguous part of it. In this examples data is supposed to be a container with the assign operator, as std::vector. | [in] | stride | the initial position of the data to be |
void resize(uint32_t newSize) method: this method is automatically called by the manager and it intended to be used during the static and the dynamic load balance. During the load balance process the user data container has to change its size to adapt itself to the new partition of the domain. The user has to tell the manager how to change the size of his data containers. In this examples data is supposed to be a container with the resize operator, as std::vector. | [in] | newSize | is the new size of the container |
void resizeGhost(uint32_t newSize) method: this method is automatically called by the manager and it intended to be used during the static and the dynamic load balance. During the load balance process the ghost user data container has to change its size to adapt itself to the new partition of the domain. The user has to tell the manager how to change the size of his ghost data containers. In this examples data is supposed to be a container with the resize operator, as std::vector. | [in] | newSize | is the new size of the container |
void shrink() method: this method is automatically called by the manager and it intended to be used during the static and the dynamic load balance. During the load balance process the user data container changes its size to adapt itself to the new partition of the domain. If the container can change its size and its capacity separately, this method is intended to get the container capacity equal to its size The user has to tell the manager how to change the capacity of his data containers to its size. In this examples data is supposed to be a container with the shrink_to_fit operator, as std::vector. UserDataLB(Data& data_, Data& ghostdata_) the constructor method: this method has to be called by the user in his application code. The user is free to implement his constructors as he wants, but he must guarantee the access to the internal and ghost data.
In the code of this example application, pay attention to the use of the interface
To run: ./PABLO_example_00007
To see the result visit: PABLO website
1.10.0