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
