On Mon, 26 Oct 2009, Tim Kroeger wrote: > 3. _n_v_comp should have identical entries for each DofObject in the > mesh
For isoparametric LAGRANGE elements, yes. For other elements, there is still a lot of redundancy, but there can be many different cases. Vertices, edges, faces, and volumes will have different numbers of components per variable, and likewise for different varieties of hanging nodes. > that would save nearly 40 MB per thread for my case.) It would still be possible to save roughly this amount, by sharing _n_v_comp structures (and _n_systems) between DoFObjects. But you see now that it's not quite a trivial change. If we wanted to avoid even temporarily allocating that memory, the first idea that comes to mind is to build some kind of DoFMap factory object that manages reference-counted n_v_comp structures, then switch DofObject pointers from object to object as we assign new variables to them... not something I'd want to futz with unless I was really bored or literally running out of RAM. > 4. When I configured libMesh for 64bit mode, I did *not* do > "--enable-ghosted". As far as I remember, this is the default now, or > should I be a fool and remember this wrong? Anyway, libmesh_config.h > contains "#define LIBMESH_ENABLE_GHOSTED 1", so this should be okay, > shouldn't it? Yes. --- Roy ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
