Hi gang, I started out writing a response to Karen's document she sent last week or the week before, then decided I needed a better starting point from which to evaluate the proposed iMeshP interface. I came up with the attached 3 use cases. I would encourage all to think about their iMeshP implementations in the context of these use cases, to see if their design will enable these use cases as described. I've taken pains to avoid prescribing any iMeshP design decisions in these use cases; if I've fallen short on any of them in this regard, please point them out. Note that some of them say things about how the calculation is distributed over processes; this is fair game, I think, since it's how the apps developers will approach our interface (i.e. they'll decide beforehand how they want to partition the problem over processes). If anybody has use case(s) which are substantially different from the space covered by those in this document, please suggest them. The idea is to keep the number of use cases somewhat low, but to fairly represent the bulk of the space we expect to cover with iMeshP. At some point, I imagine this document going into the repo or (heaven forbid) some sort of paper published in the distant future. I've written how my design will work for the first two use cases, and so far so good (though the 2nd one isn't trivial to understand). I'm pretty sure the 3rd use case will be easier (for me), but we'll see. I'm sending this out partly to help others get started thinking about their designs in the context of realistic use cases, and partly to reassure Karen that I'm doing something about her message, despite the radio silence :). - tim -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 iMesh, iMeshP Use Cases The use cases below describe the PDE to be solved, and any application-imposed constraints on the parallel solution approach. These are meant to illustrate the use of the iMesh and iMeshP interfaces to solve these problems. For a given use case, describe how the constructs proposed for iMesh and iMeshP (e.g. Process, iMesh/iMeshP Instances, iMesh/iMeshP API functions, Partition, Part) will be used to solve the problem. While not absolutely required, this will generally require desription of: - the basic approach to distributing the domain and computations for the domain across Processes - what kind of communications are done in general, and how those interact with iMeshP constructs - the basic steps of the computational or time step kernel, and how they interact with iMeshP/iMesh. ===================== Use case 1: Solve a discretized PDE with FEM using spatial domain decomposition --------------------- Problem statement Solve a function dF/dx = f(x) on a spatial domain with prescribed boundary conditions. =============================== Use case 2: Radiation transport ------------------------------- Problem Statement In this use case, the radiation flux phi(x,E,t) is computed over a finite element grid, with flux values stored at vertices. In a very simplified form, the implicit formulation of this equation can be written as: d/d(x,E,t) phi(x,E,t1) = f(S(x,E), phis(x,t0)) where phis(x,t) = sum_E{w_E phi(x,E,t)} is the scalar flux, a weighted sum of energy-dependent fluxes phi(x,E,t). The discretized problem is partitioned into S spatial domains {si} and E energy domains {ej}. A given time step solution consists of two parts. First, across an energy subdomain ej, the problem is solved over the spatial subdomains si using a domain decomposition PDE solution method; the result is an phi(v(si),ej,t0), the radiation flux for a given energy ej at each vertex si. Second, the energy-based flux is converted to a scalar phi(v(si),t0), by computing a weighted sum over energy subdomains ej of the flux at each vertex, phi(v(si),ej,t0). The scalar flux is used in computing the energy-dependent flux phi(v(si),t1) on the next time step. =============================== Use case 3: Structural dynamics with parallel contact detection ------------------------------- Problem Statement Solve a structural dynamics problem: d/dt^2 x(x,t) = f(x,t) over a volumetric domain V with multiple connected sets V_k, handling cases where connected sets come into contact and exert force on each other when their boundaries collide. Solve each time step in two phases. In the first phase, solve for new positions x(x,t) using a standard (spatial) domain decomposition FEM, with each process responsible for computing behavior of a spatial subdomain. In the second phase, for all faces bounding single volume elements (i.e. not contiguously connected to two volume elements), given the length of the next timestep t, compute location and time of collision of any two faces in that set. Solve this second phase by distributing faces over processes according to spatial proximity, based on some space-filling decomposition of the bounding box of all volume elements (which will by definition enclose all bounding faces). No restrictions should be placed on which process is assigned a volume element and any of its connected boundary faces; that is, a volume and its connected boundary faces are not required to be solved by the same process.