Benjamin Kirk wrote:
>> I was therefore thinking of the following: Create a custom
>> subdiv_dof_map, which collects the dof indices of all vertices in the
>> patch of e and then (in the correct order) combines them into one
>> dof_indices vector. This one can then be used as before. I guess it
>> would be minimally invasive and only need small changes in the
>> application code. I just hope there's no hidden catch...
>
> You're right. There may be bizarre AMR constraint implications I haven't
> thought through, but since you said you're presently not worried about AMR
> that is a non-issue.
>
> All that should be needed is a different method to compute the graph of the
> sparse matrix. (I think even the current dof distribution stuff will work
> just fine.)
Ah, I see, I almost forgot about that.
> The System base class holds an AutoPtr<DofMap> object, so I'm thinking it
> would be *really* easy to modify the DofMap class definition a little so
> that users can derive their own implementation and supply it to the System
> for use. Then we just add a System::replace_dof_map() member or something
> like that.
>
> Anyone have a different idea?
Sounds reasonable, I'll have a look at this soon. Talking about the
DofMap, I encountered another issue in the subdiv implementation, namely
the boundary conditions. Since you need patches around each element, you
have to insert ghost nodes at the boundary:
1
/|\
/ | \
/ | \
0 | V
\ | /
\ | /
\2/
Here, V is a ghost vertex. The position is just vertex 0 mirrored along
the 1-2 axis.
These vertices (and elements) do not carry any DOFs (it's really just
the mirror image of vertex 0). All we need them for is to get the subdiv
patch (ie. we need the position of V for setting up the shape
functions). The only reason to really have them in the mesh as an
element is for the patch creation: There we have to iterate around an
element using the neighbor() function, which will fail at the boundary.
Is there a way to specify that these ghost elements have no DOFs at all?
In my subdiv FE class, I can decide if a geometric element is a ghost
element or a real one, but from what I see the
FEBase::get_dofs_at_node() and similar functions which are used to build
the DofMap are all static...
Also, it was mentioned at some point that a "valence" field could be
added to the Node class. I worked around it, but it would certainly make
things a lot easier if we had it. I also imagine that the valence
property could be of use for other people, too. What do you think?
Thanks a lot for your help! I'll send a big patch for subdivs as soon as
it is working ;-)
-Norbert
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel