On Fri, 24 Apr 2009, Tim Kroeger wrote: >> Sadly no, I meant all nodes, then all elements - Elem is a DofObject >> too, and that's where we store degrees of freedom for finite elements >> (e.g. discontinuous monomials) that need some connectivity-less DoFs >> but can otherwise get away working on with low order geometric >> elements. > > I'm not sure whether I understood this.
It's lower-level details, if you wanted to make sure you operate on each index once but only once. The code you've got now should be correct for setting indices of all element types, but as you said it won't work for scaling indices. > When looping over the nodes first, how do I get the dofs the live on > a node and correspond to a given variable? Find the total number with DofObject::n_comp(sys_num,var_num), then from 1 to n_comp get DofObject::dof_number(sys_num,var_num,comp_num). >> This would return some derived type ("SliceVector"?) that didn't store >> its own data, but rather just an index map, so it could act as a proxy >> to the appropriate components of full_vec (or to System::solution by >> default). > > Yes, very good idea. But I'm unsure how the index map would work: from where > to where does it map? >From a dense local indexing (this is the ith degree of freedom belonging to variable v) to the system's global indexing (it's the jth degree of freedom belonging to any variable). So when you access slice[i] it really accesses whole[j] = whole[map[i]]. > Also, I wonder what such a SliceVector does when grid refinement > takes place during its lifetime. Cry? I'd just presumed that it would be invalidated by a reinit(). But I suppose since it's got to have a pointer-to-System, it could easily register/unregister itself with that system upon creation and destruction; the System would then be able to keep a list of slices and call reinit() on each during an EquationSystems::reinit(). > It seems to me that, although introducing a nice API, this approach > will require a lot of work. True. > Anyway: If I should some day write a patch that does *not* use your > "SliceVector" approach: Would you accept that patch or not? Yeah, I think so. Even if we went all out with SliceVectors in the long run, a few redundant APIs later would be better than missing APIs now. --- Roy ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users