So really, unless there is a good reason... I think we should revert back to:
Ok - maybe I don't understand... but why was this a bug in the first place? To me... if you declare a Mesh object with dim=2 and you read an Exodus file with dim=2... then when you output it you should expect to get dim=2? Why would you want to always get LIBMESH_DIM? I shouldn't have to recompile my application in order to get a 2D Exodus file out... that should dynamically change based on the dimension I declared the Mesh to be (ie mesh_dimension() ).I seriously don't want to always have 3D Exodus files coming out... which if I read the code correctly is the only option now if I've compiled libmesh with LIBMESH_DIM=3 (as I always do of course). Checking to see if the thing is planar or not shouldn't be necessary.DerekOn Wed, Dec 10, 2008 at 10:04 AM, Benjamin Kirk <email@example.com> wrote:
Yeah - look for is_planar_xy in point_locator_tree.C
> Ok - something about the way this was "fixed" has broken stuff for me. If I
> now read a 2D Exodus mesh (using a Mesh created with dim=2) and then write the
> solution out.... it comes out having a dimension of _3_.
> To see this you can just run the attached exodus file (generated using Cubit)
> through example1... using:
> ./ex1 -d 2 square.e out.e
> Then inspect out.e with whatever method you want (I use ncdump... which shows
> that out.e clearly has num_dim = 3).
> Any ideas before I dig further?
I was running into a problem building an octree for planar meshes when a
quadtree is really what you want.
You might abstract that hack into
MeshTools::is_planar(Mesh &mesh, unsigned int xi, unsigned int eta)
Or something like that.
is_planar_xy = MeshTools::is_planar(mesh,0,1);
is_planar_yz = MeshTools::is_planar(mesh,1,2);
is_planar_xz = MeshTools::is_planar(mesh,0,2);
...you get the rest...