Below is a list of what I think we discussed and decided at yesterday's
phone conference; if you do not agree, let me know.
Our next phone conference is 11/28 at 9am PST. Please reserve 90 minutes
for the meeting. At the meeting, we will discuss the questions in the
combined document, along with other questions that are emailed to me before
the meeting. If we have time, we'll discuss what is in the document that
shouldn't be there.
You'll see below that we deferred decisions on many topics; please think
about those topics so that we can reach decisions on them soon.
11/15 Phone conference notes:
We decided to simplify for now the assumptions of our discussion. We
decided to assume for now that there is only one mesh instance and one
partition. We agreed that people had major heartburn about:
- multiple meshes in a partition, and
- multiple partitions of a mesh.
We had a discussion of what was missing in the combined document.
We agreed to add functions from RPI's initial document that return
information about remote copies of entities. Karen will add this missing
functionality to the document.
We agreed to assume that functions returning global information (such as the
total number of parts in a partition or the number of parts in each parallel
process) would have the option of using communication to return their answer
and, thus, would have to be called synchronously by users. We agreed that
implementations did not necessarily have to use communication, but the
documentation would warn users that communication might occur.
We discussed but did not yet accept the possibility of adding a
partition-syncing function that would compute and store global information
about a partition after modifications of a partition were completed. We
discussed allowing this function to compute and store some scalar values
(e.g., total number of parts in a partition), but ruled out allowing it to
compute and store vector data of size O(number of processors) (e.g., the
number of parts on each processor).
We discussed and deferred a decision on adding functions that give hints to
an implementation about which data mappings the application will use,
allowing the implementation to pre-compute them if it chooses to. The
example discussed was mapping between entities and parts, but other examples
in iMesh may also exist.
We discussed and deferred a decision on adding an iterator over entities
with given type/topology in a set or part. We have non-iterator
functionality, but not an iterator.
We discussed and deferred a decision on storing in a partition information
about which "objects" were used in computing the partition. These objects
can be single entities or groups of entities.
We discussed and deferred a decision on whether part assignments apply only
to the entities involved in generating a partition, or whether they induce
part assignments on lower-dimensional entities.
We discussed and deferred a decision on designating a given partition as the
"active" partition; i.e., the partition that is actually used in the
distribution of mesh data in distributed memory. We were concerned that
when multiple partitions were used, multiple copies of mesh entities would
be needed to fully support multiple partitions at the same time.
Designating one partition as "active" would store data with respect to only
one partition.
