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.