From: Norbert Stoop <norbert@st...>  20081215 14:07:10

Sorry for the delayed answer, I had a lot of work to do and was away for some days... Derek Gaston wrote: > On Dec 10, 2008, at 3:07 PM, Benjamin Kirk wrote: > >> Because if you try adding quads to a dim=3 mesh it will fail. > > You're right. > >> And because 2D mesh which is a surface in 3D needs to be written as >> a 3D >> exodusII mesh, right? > > This I don't know. The short answer is: Yes, absolutely. The long answer: The logical dimension of a mesh can be understood as the number of parameters required to describe each point in it. A curve, for instance, needs a single parameter t which measure where along the curve you are, ie. it has logical dimension 1. A sheet requires two parameters (s,t) to describe the position on the sheet (logical dimension is 2). Now, these objects can live in different spaces. For example, a curve could live in 2D, meaning that each t corresponds to a point (x(t),y(t)) in 2D. If it lives in 3D, the positions are given as (x(t),y(t),z(t)). The same goes for a sheet in 2D or 3D, only that x,y and z depend on t *and* s. This map, which brings you from the parameter space (t,s) \in R^2 to the physical space AFAIK is called the embedding. Ie. f: (s,t) > R^3 is the embedding of a sheet in 3D. The surface of a sphere with radius R, as an example, is given by x(phi,theta)=R*sin(theta)*cos(phi) y(phi,theta)=R*sin(theta)*sin(phi) z(phi,theta)=R*cos(theta) Here, you have two parameters, phi and theta, and a map which goes from (phi,theta) to the 3D space. The logical dimension of this surface is 2, but the number of coordinates to describe it in the physical space is 3. Since your mesh viewer does not now about the embedding map, you *have* to give it the cartesian coordinates, of which you need 3 here. I hope things are a bit more clear now... >> And what is the problem reading an exodusII file with a 2d mesh if >> dim in >> the exodus file is 3? We need to remove the assertion on read. > > I guess the question here is what does the dimension in the Exodus > file mean at all? We certainly don't use it at all (except for that > assert() in read) and as far as I can tell in my testing, none of > Ensight, Paraview or Cubit seems to care about reading a 2D solution/ > mesh from an Exodus file that states its dimension as 3. The dimensionality in the Exodus API specifies how many coordinates in the physical space to expect for each vertex, ie. it corresponds to LIBMESH_DIM, and not to the logical mesh dimension. > So why do I care... I dunno... it just makes me feel icky... and there > is the chance that some code someday will assume something from a file > that states its dimension as 3 and really only contains a 2D mesh. I guess one should be more careful with specifying the dimension of the physical space (LIBMESH_DIM) anyway. For example, consider a planar mesh in the xyplane. On this mesh, you can define vectors/gradients that live in the xyplane. Now, if you consider this mesh to be a planar "thing" in three dimensions, then the crossproduct of two such vectors gives you a vector perpendicular to the mesh, ie. zcomponent is not zero. On the other hand, if your mesh is really living in two dimensions (LIBMESH_DIM=2), then the cross product of two vectors in the xyplane still will be in the xyplane (since the definition of the cross product differs depending on the dimension of the *embedding* space). This difference has physical consequences... In other words, if you have true 2D system and you simulate with LIBMESH_DIM=3, it *might* be that you solve it in a wrong way. Maybe one should be able to tell the physical dimension at the level of the problem and not as a compile time option for the whole library? Best, Norbert 