#include <source/transfer/datamovers/standard/CoarsenAlgorithm.h>
Public Member Functions | |
CoarsenAlgorithm (bool fill_coarse_data=false) | |
virtual | ~CoarsenAlgorithm () |
void | registerCoarsen (const int dst, const int src, const tbox::Pointer< xfer::CoarsenOperator< DIM > > opcoarsen, const hier::IntVector< DIM > &gcw_to_coarsen=hier::IntVector< DIM >(0)) |
tbox::Pointer< xfer::CoarsenSchedule< DIM > > | createSchedule (tbox::Pointer< hier::PatchLevel< DIM > > crse_level, tbox::Pointer< hier::PatchLevel< DIM > > fine_level, xfer::CoarsenPatchStrategy< DIM > *patch_strategy=((xfer::CoarsenPatchStrategy< DIM > *)(0)), tbox::Pointer< xfer::CoarsenTransactionFactory< DIM > > transaction_factory=(xfer::CoarsenTransactionFactory< DIM > *)(0)) |
bool | checkConsistency (tbox::Pointer< xfer::CoarsenSchedule< DIM > > schedule) const |
Given a previously-generated coarsen schedule, check for consistency with this coarsen algorithm object to see whether a call to resetSchedule is a valid operation. | |
void | resetSchedule (tbox::Pointer< xfer::CoarsenSchedule< DIM > > schedule) const |
Given a previously-generated coarsen schedule, reconfigure it to peform the communication operations registered with this coarsen algorithm object. That is, the schedule will be transformed so that it will function as though this coarsen algorithm created it. Note that the set of operations registered with this coarsen algorithm must be essentially the same as those registered with the coarsen algorithm that created the schedule originally. That is, the number of operations registered must be the same and the source and destination patch data items and operators must have identical characteristics (i.e., data centering, ghost cell widths, stencil requirements, etc.). However, the specific source, destination patch data ids and operators can be different. Detailed and fairly complete error checking is performed when this routine is called to prevent potential errors or unexpected behavior. | |
void | printClassData (ostream &stream) const |
Communication algorithms generally consist of three parts: an algorithm, a schedule, and a patch strategy. The algorithm describes the communication between patch data items but is independent of the configuration of the AMR hierarchy. hier::Patch data items and their associated coarsening operators are registered with the algorithm. To generate the communication dependencies for a particular hierarchy configuration, the algorithm generates a schedule based on the current hierarchy configuration. This schedule then performs the communication based on the registered data types and their associated operators. User-defined pre-processing and post-processing are provided through the abstract patch strategy class.
The source patch data space is used during processing to store temporary data. Thus, the user-defined coarsening operators should operate on the source space by using the patch data with those indices.
Note that each coarsen schedule created by a coarsen algorithm remains valid as long as the patches involved in the communication process do not change; thus, they can be used for multiple data communication cycles.
Typical usage of a coarsen algorithm to perform data coarsening on an AMR hierarchy involves four steps:
User-defined coarsening operations can be written using the interfaces in CoarsenPatchStrategy for preprocessCoarsen() and postProcessCoarsen(). Users who use create these operations must note that all data that is to be used in such operations should be registered with the CoarsenAlgorithm using registerCoarsen(), whether or not the data is to be coarsened.
|
Construct a coarsening algorithm and initialize its basic state. Coarsening operations must be registered with this algorithm before it can do anything useful. See the registerCoarsen() routine for details
|
|
The virtual destructor for the algorithm releases all internal storage. |
|
Register a coarsening operation with the coarsening algorithm. Data from the interiors of the source component on a source (fine) patch level will be coarsened into the source component of a temporary (coarse) patch level and then copied into the destination component on the destination (coarse) patch level. If the coarsening operator requires data in ghost cells outside of the patch interiors (i.e., a non-zero stencil width), then those ghost cells must exist in the source patch data component and the ghost cells must be filled with valid data on the source level before a call to invoke the communication schedule. Note that the source and destination components may be the same in any case. Some special circumstances require that data be coarsened from the ghost cell regions of a finer level and the resulting coarsened data should be copied to the destination patch level. When this is the case, the optional integer vector argument should be set to the cell width, in the destination (coarser) level index space, of the region around the fine level where this coarsening should occur. For example, if the coarser level needs data in a region two (coarse) cells wide around the boundary of the finer level, then the gcw_to_coarsen should be set to a vector with all entries set to two. Moreover, if the refinement ratio between coarse and fine levels is four in this case, then the source patch data is required to have at least eight ghost cells.
|
|
Create a communication schedule to coarsen data from the patch levels. This communication schedule may then be executed to perform the data transfers. This schedule creation procedure assumes that the coarse level represents a ragion of coarser index space than the fine level. To avoid potentially erroneous behavior, the coarse level domain should cover the domain of the fine level. Neither patch level can be null and when assertion checking is active, passing a null level pointer will produce an unrecoverable exception. Note that the schedule remains valid as long as the patches on the levels do not change; thus, it can be used for multiple data communication cycles.
|
|
Given a previously-generated coarsen schedule, check for consistency with this coarsen algorithm object to see whether a call to resetSchedule is a valid operation.
|
|
Given a previously-generated coarsen schedule, reconfigure it to peform the communication operations registered with this coarsen algorithm object. That is, the schedule will be transformed so that it will function as though this coarsen algorithm created it. Note that the set of operations registered with this coarsen algorithm must be essentially the same as those registered with the coarsen algorithm that created the schedule originally. That is, the number of operations registered must be the same and the source and destination patch data items and operators must have identical characteristics (i.e., data centering, ghost cell widths, stencil requirements, etc.). However, the specific source, destination patch data ids and operators can be different. Detailed and fairly complete error checking is performed when this routine is called to prevent potential errors or unexpected behavior.
|
|
Print the coarsen algorithm state to the specified data stream.
|