On Sun, 28 Sep 2008, Nasser Mohieddin Abukhdeir wrote:
> This "const FEMContext &context" idea would involve a little work, but not a > huge inconvenience. I don't understand the big picture, Primarily: multithreading. I'd like to make FEMSystem automatically use Ben's TBB threading code, but that operates at an element level, and we can't have two threads working on two different elements if only one FEMSystem::elem exists. So either FEMSystem could create more than one copy of itself (which would break any really creative user code in very hard to fix ways) or FEMSystem could use more than one elem (which would break everybody's user code in relatively easy to fix ways). > but something like > this will be quite confusing if the corresponding class data still exists, > that is, if FEMSystem.elem still exists many mistakes will be made (probably > by me). Oh, no - I'm in the same boat, and I don't want to make the same mistakes. API changes that make formerly valid code fail to compile are bad enough; API changes that make formerly valid code give invalid results are just *wrong*. Part of the motivation for creating DiffSystem was to avoid such situations. A few users would have a perfectly fine serial non-adaptive application, but it would break if they switched on adaptivity or parallelism, just because they forgot to use the right iterators or to call the function for applying hanging node constraints. --- Roy ------------------------------------------------------------------------- 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
