Subject: Re: Plugging Away Resent-Date: Thu, 09 Dec 1999 10:34:23 -0500 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Thu, 9 Dec 1999 09:31:13 -0600 (CST) From: Joe Thompson To: gcf@npac.syr.edu CC: joe@erc.msstate.edu DIAGRAM Diagram looks good. Probably put in only one Surface Mesh Engine (could just as well be two Geometry Engines or Volume Mesh Engines). Better to just indicate somehow that all these engines might be multiple: Maybe with a (s) in each title? I think I would add an Adaptive Mesh Engine. This would also connect to Collab and Plan. Put Parallel Decomp on Volume Mesh Engine, and put Collab and Plan on Surface Mesh Engine - i.e. just interchange. Maybe Computer Scientist instead of Computer Consultant? Politically correct, and does make sense because expertise needed here might be in database and data structure issues. Indicate a visualization nterface somehow? I realize portal implies viz, and that might be enough: your call. One item here would be seeing the computational science solution, the volume grid, and the underlying geometry at the same time. In the design mode, the computational scientist would make changes in the underlying geometry and hope that the results would propagate automatically. QUESTIONS The Collab and Plan module relates most to setting up the geometry and the surface mesh, and comes in twice: first in the initial setup of the solution, and later in the design mode where changes are made to the geometry. And it relates to solution steering in the adaptive mode (your "shared mesh refiner"). Here I see the computational scientist and the mesh expert having to work together because their knowledge is complimentary: comp scientist knows what he wants to happen, but mesh man knows how to make it happen. Component objects are (reusable) geometic pieces. For example, a wing for an airplane. Or an engine. One engine might be built with considerable effort, but then placed four times on a four-engine plane, with the placement requiring little effort. And that engine might be saved and used again - perhaps with some modifications (editing) - next year on another plane. Or its position on a plane might be modified in the design mode. This is very important - and is ideally suited for object technology: build, edit, use again. Even that engine would be made up of multiple objects: fan blades, etc. And on a wing, a flap would be a component which could be repositioned. So there is a hiearchy in these objects, both on 2D and 3D. Down on the lowest level, those component objects of that engine are made up of curve and surface splines (NURBS). So a single curve or surface segment might be an elementary object that could be used in many places. So these objects are produced and refines by the engines, just as you say. When I first read about Java a few years back, the classes immediately made me wonder about the possibility of geometry classes inheriting properties and being extended, etc. The point is that geometry/mesh is inherently component-based, from the very small to the very large - and those components are reusable in many combinations. And this is the thing that requires CS - and none of the mesh guys (or codes) really have it in stength.