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

Reply via email to