YAXT: Issueshttps://swprojects.dkrz.de/redmine/https://swprojects.dkrz.de/redmine/redmine/favicon.ico?17095821032015-04-27T12:34:37ZDKRZ projects
Redmine Feature #337 (New): check possibility of usage of mpi_type_create_hvector in xt_redist_collection...https://swprojects.dkrz.de/redmine/issues/3372015-04-27T12:34:37ZJoerg Behrensbehrens@dkrz.de
<p>If the sequence of redists given in the constructor always uses the same redist then we should reduce the created datatype to a simple form (using mpi_type_create_hvector instead of MPI_Type_create_struct).</p> Feature #334 (Closed): better bug message if xmap constructor failshttps://swprojects.dkrz.de/redmine/issues/3342014-11-12T17:40:05ZJoerg Behrensbehrens@dkrz.de
<p>The follwing error message is not helpful:</p>
<pre>
Fatal error in ../../yaxt-0.3.0/src/xt_xmap_intersection_ext.c, line 308: ERROR: destination intersections do not match with destination index list
</pre>
<p>What is the problem? Can we give out the first offending dest-index that can't be linked to any src-index?</p> Task #332 (Closed): allow empty messages in exchange routineshttps://swprojects.dkrz.de/redmine/issues/3322014-07-31T12:42:24ZJoerg Behrensbehrens@dkrz.de
<p>redists should be able to pass emtpy messages (struct Xt_redist_msg; with datatype = MPI_DATATYPE_NULL and rank = -1) to exchange routines.</p>
<p>These messages are just "place-holders" and should not trigger an actual exchange.</p>
<p>This should result in simple but general exchange routines that supports various message orders.</p> Feature #321 (New): runtime switch for the generation of MPI datatypeshttps://swprojects.dkrz.de/redmine/issues/3212013-06-27T13:32:47ZJoerg Behrensbehrens@dkrz.de
<p>There are now two ways to generate dataypes (src/xt_mpi.c)</p>
<p>(a) fast, but without exploiting potential for a compact description<br />(b) less fast, but with ...</p>
<p>So far the switch is a cpp symbol: COMPACT_DT in src/xt_mpi.c</p>
<p>We need a runtime switch in order to test both versions without recompilation</p> Task #316 (Closed): check if base redist class makes sensehttps://swprojects.dkrz.de/redmine/issues/3162013-03-08T16:47:22ZJoerg Behrensbehrens@dkrz.de
<p>if there is enough common functionality within the current redist variations then we should derive them from a base class</p> Feature #315 (Closed): new constructor xt_redist_repeathttps://swprojects.dkrz.de/redmine/issues/3152013-03-08T16:14:59ZJoerg Behrensbehrens@dkrz.de
<p>new constructor for simple static repetition of the same redist<br />(much simpler version of xt_redist_collection_static_new)</p>
<p>Xt_redist<br />xt_redist_repetition_new(Xt_redist redist, unsigned num_repetitions,<br /> MPI_Aint displacements[num_repetitions]);<br />//hint: use xt_mpi_generate_datatype from xt_mpi.c<br />//hint: write easy to read doc</p> Bug #313 (Closed): bug: xmap construction allows multiple writes to the same destination memory l...https://swprojects.dkrz.de/redmine/issues/3132013-01-17T10:12:09ZJoerg Behrensbehrens@dkrz.de
<p>If multiple source processes have the same index that is required by a target then all of these source processes may be registered as data sources which may lead to collisions when the actual data exchange happens. Also, this may lead to a bloated xmap.</p> Feature #311 (Closed): stripify xt_xmap_dist_dir_newhttps://swprojects.dkrz.de/redmine/issues/3112012-11-26T15:24:20ZJoerg Behrensbehrens@dkrz.de
<p>Following the idea of using bounding boxes for xmap constructions we could consider to implement a stripe-set form of all involved ingredients.<br />This avoids vectorization to death of big compact index lists (better scalability). This is suitable for a one-dim distributed directory which might not scale perfectly but probably is more cost effective for medium sized problems.</p> Feature #310 (New): new xmap constructor: xt_xmap_dist_dir_dim_newhttps://swprojects.dkrz.de/redmine/issues/3102012-11-26T15:15:33ZJoerg Behrensbehrens@dkrz.de
<p>The implementation should use the routine xt_idxlist_get_bounding_box (see issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: new idxlist method: xt_idxlist_get_bounding_box (Closed)" href="https://swprojects.dkrz.de/redmine/issues/309">#309</a>) in order to efficiently preselect intersection candidates coming from the distributed directory bucket lattice for later intersection computation.</p>
<pre>
Xt_xmap xt_xmap_dist_dir_dim_new(Xt_idxlist src_idxlist, Xt_idxlist dst_idxlist,
int ndim, Xt_int global_size[ndim],
Xt_idx global_start_index, MPI_Comm comm);
</pre> Feature #309 (Closed): new idxlist method: xt_idxlist_get_bounding_boxhttps://swprojects.dkrz.de/redmine/issues/3092012-11-26T14:57:24ZJoerg Behrensbehrens@dkrz.de
<p>Idea: We want to efficiently estimate the overlap between compact index sets. Currently this requires the participating objects to belong to the same compact idxlist class. In other cases objects are used internally in idxvec form which is the least efficient way to work with compact index sets. For these cases we want to construct bounding boxes which describe compact supersets of simple overlap-friendly geometry. These bounding boxes should be defined as Xt_bounds, a new primitive yaxt datatype completely visibility for all classes.</p>
<pre>
//basic type to express narrowness via bounds in one dimension:
typedef struct {int lb; int ub} Xt_bounds;
//idxlist method to get the bounding box:
void xt_idxlist_get_bounding_box(Xt_idxlist idxlist, int ndim,
Xt_int global_size[ndim],
Xt_idx global_start_index,
Xt_bounds bounds[ndim]);
</pre> Feature #307 (New): idxsection_get_index_stripes_consthttps://swprojects.dkrz.de/redmine/issues/3072012-10-25T15:13:33ZJoerg Behrensbehrens@dkrz.de
<p>Implement const version of idxsection_get_index_stripes (like get_indices_const).</p> Feature #306 (New): garbage collectorhttps://swprojects.dkrz.de/redmine/issues/3062012-10-25T15:11:10ZJoerg Behrensbehrens@dkrz.de
<p>Since we have an idxlist-internal cache that we might not need at some point, we might consider implementing a garbage collector to minimize the memory footprint of idxlists.</p> Feature #305 (New): fundamental vector typehttps://swprojects.dkrz.de/redmine/issues/3052012-10-15T12:11:57ZJoerg Behrensbehrens@dkrz.de
<p>It might be useful to have a fundamental vector type</p>
<p>struct vec_DATA_TYPE { int n; int cap; DATA_TYPE *p;};</p>
<p>in order to simplify the code, e.g. to reduce the number of arguments when vector-like information is passed (DATA_TYPE *p, n)</p> Feature #304 (New): basic warning/error managementhttps://swprojects.dkrz.de/redmine/issues/3042012-10-15T12:07:59ZJoerg Behrensbehrens@dkrz.de
<p>basic warning/error management => summary at finalize?</p> Feature #303 (Closed): improve make check under AIXhttps://swprojects.dkrz.de/redmine/issues/3032012-05-18T16:02:07ZJoerg Behrensbehrens@dkrz.de
<p><strong>make check</strong> should run the tests in a appropriate environment. This includes the variables MP_PROCS and MP_HOSTFILE and the creation of a suitable hostfile in the current directory.</p>
<p>Right now, the user has to set up such an environment by hand.</p>