From: Derek Gaston <friedmud@gm...>  20081215 15:52:50

Right... I agree with all of this.... which is exactly _why_ I want a Mesh that was created with dim=2 to be written out to an Exodus file correctly as having dim=2. I guess my feeling is that most often when people are asking for a 2 dimensional mesh... they are doing so in order to perform a calculation in 2 dimensional space... not perform a 3D calculation on a 2D manifold. I don't want to exclude the latter option... but it should be just that... an _option_. Like John says you should have the ability to change any of the 3 of mesh_dimension(), spatial_dimension() or LIBMESH_DIM independently... but I would lobby for mesh_dimension() and spatial_dimension() to be the same by default... with a user needing to elevate spatial_dimension() in order to solve a lower dim problem in a higher dim space. It's just counterintuitive that I read a 2D mesh into a 2D Mesh object and when I write it out I get a 3D mesh... Again, I'm not trying to be argumentative... I've already updated all of my regression test gold files to use 3D meshes... it still just feels wrong. Derek On Dec 15, 2008, at 7:07 AM, Norbert Stoop wrote: > 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 > >  > SF.Net email is Sponsored by MIX09, March 1820, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to > help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 