From: Derek Gaston <friedmud@gm...>  20081210 22:21:08

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. > 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. 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. If this is the will of the group though... I'll just roll with it and update all of my "gold" files in my regression tests so they all have dimension=3 results. Derek 
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 
From: John Peterson <peterson@cf...>  20081215 15:33:12

On Mon, Dec 15, 2008 at 8:07 AM, Norbert Stoop <norbert@...> wrote: > > 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? LIBMESH_DIM is a compiletime constant for both storage and efficiency's sake. It allows constructs like "Real array[LIBMESH_DIM]" and "#ifdef (LIBMESH_DIM==X)" code paths. This is a separate concept from the spatial dimension a mesh can/should have, although it must be true that mesh.spatial_dimsion <= LIBMESH_DIM. I propose that we should be able to set LIBMESH_DIM, mesh.mesh_dimension() and mesh.spatial_dimension() independently, so long as it holds that mesh.mesh_dimension() <= mesh.spatial_dimension() <= LIBMESH_DIM. Default values would match the current setup in which the spatial_dimension and LIBMESH_DIM are the same, but the user would then have the flexibility to specify say a 1D mesh living in 2D with a library compiled for 3D. I'm sure there will still be some technical issues, but the fact remains we should logically separate the three concepts.  John 
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 
From: Norbert Stoop <norbert@st...>  20081215 17:19:15

Derek Gaston wrote: > 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. Yes, I fully agree with this idea. It only requires to set spatial_dimension=mesh_dimension instead of spatial_dimension=LIBMESH_DIM in the mesh initialization routines and adding a function to override the default. Since spatial_dimension is not used at many other places, the possibility to break other things is relatively small. To me, this also sound the most consistent and the original Exodus fix will not break anything anymore. Norbert PS: Sorry, Derek, for sending you a separate copy of this message... 