On Dec 6, 2012, at 12:58 PM, Roy Stogner <[email protected]> wrote:
>
> On Thu, 6 Dec 2012, Derek Gaston wrote:
>
>> Would you actually do something like:
>> system.addVariableGroup()? Or would VariableGroups be automatically created
>> based on the types
>> of variables that have been added? It would be great if it were the second
>> one... that way, all
>> of this is not a user-facing API... but really just an optimization under
>> the hood.
>
> I'd vastly prefer automatic creation, with one caveat. Based on Ben's
> anticipated numbering requirements, users should need to
> add_variable() matching types in the right order in order to get them
> into the same variable group. e.g. with different orders for u,v vs p:
>
> add_variable(u1), followed by v1, p1, u2, v2, p2, would give us four
> variable groups: one for u1,v1, one for p1, one for u2,v2, one for p2.
>
> add_variable(u1), followed by v1, u2, v2, p1, p2, would give us two
> variable groups: one for u1,v1,u2,v2, one for p1,p2
>
> If the only way to make the first case as efficient as the second
> would be to force a different-than-requested index ordering on the
> user, then I'm against it. I dislike user code which depends on
> indexing internals, but people still write apps like that (*cough*,
> Ben, *cough*), and I don't want to risk breaking any of them, even
> hypothetical non-FINS apps that don't force node-first rather than
> variable-first dof ordering anyway.
Right now we have
/**
* Adds the variable \p var to the list of variables
* for this system. Returns the index number for the new variable.
*/
unsigned int add_variable (const std::string& var,
const FEType& type,
const std::set<subdomain_id_type> * const
active_subdomains = NULL);
I'll add another method
add_variables (std::vector<std::string> &vars,
…);
But I should also be able to create a "cleanup" method that collapses
contiguous blocks of the same type that have been added, allowing this to be a
pure under-the-hood optimization too.
Internally, I think the way to go is to treat everything across the board as
VariabeGroups, the current capability is just a degenerate case of a
VariableGroup with only one Variable inside.
Automatically identifying VariableGroups is subject to Roy's concern. Consider
for example Talylor-Hood Q2Q1 in 2D:
add_variable(u);
add_variable(v);
add_variable(P);
results *currently* in a global solution vector ordered like so:
(u0 u1 … uN v0 v1 … vN p0 p1 … pM)
whereas automatically identifying u & v and collapsing them into a
VariableGroup will yield instead
( u0 v0 u1 v1 … uN vN p0 p1… pM)
At the element level all should be good - the dof_indices will simply be
permuted to handle the global scatter/gather differences, but if anyone is
accessing the global solution directly things will be different.
-Ben
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
