On Sun, 7 Aug 2016, Derek Gaston wrote:
> Well - one thing that makes this worse is that > System::add_variables() (Note the "s") returns the variable ID of > the last variable added when you're adding a whole group (which is > crazy not useful). You could backtrack to get the other variables' ids; it's useful... but really weird. > I know that we delay group creation a bit so that groups can > automatically be created so we may not know the group number at this > point (I can't quite tell)... but what if that function is changed > to return the VariableGroup object itself? Hold it as a reference we > should be able to get the ID out of it later... With the *current* behavior, even with the identify_variable_groups behavior, we ought to be able to get the current group number, because our only optimization is to create groups from contiguously added variables. I'd like to add an option to sort variables under the hood before grouping, for use in multiphysics codes which don't do that sorting themselves, but if we ever add that it won't be compatible with the current return-a-number-immediately-from-add_variable behavior that everyone relies on, so I won't worry about adding new incompatible APIs either. Regardless, I'd rather add a new API to get group data rather than changing the current APIs. --- Roy ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
