Re: [Libmesh-devel] Bug in ExodusII_IO?

[Derek G. <fri...@gm...>]

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 x-y-plane. On this mesh, you can define vectors/gradients that
> live in the x-y-plane.
> 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. z-component 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 x-y-plane still will be  
> in
> the x-y-plane (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 18-20, 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/
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel