On Tue, 27 Oct 2009, Tim Kroeger wrote: >> 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. > > I see. Anyway, at least it should be possible to replace some of the > pointers with ints or short ints (or perhaps chars). I mean, one could make > the arrays one-dimensional and then manage an array of offsets for the > systems instead. Since _n_v_comp and _dof_ids are private in DofObject, the > necessary changes should be manageable. Do you agree? Would such a change > be welcome if I implemented it?
Yes; it's not too intrusive. We'd want to make the data type a typedef, though; short int ought to be good for the default, but most users could get away with char and it's not inconceivable that someone might want a full int. > It would save some memory, but possible at the cost of time. I don't know > how often this information is accessed. If it is read in each assembly, it > could slow down things noticably. It's read in every call to dof_indices, even. We'd certainly want a before/after comparison on speed. > By the way, what is the current state of ParallelGrid? Perhaps, this should > be the right time for me to switch? Probably not. ParallelMesh itself still has a bug with some adaptive coarsening situations, which means that none of the developers use it by default, which means there are probably other bugs left over in other libMesh classes that assume a serial Mesh. --- 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
