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, 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).
I just thought of one situation where this won't be true: Right now the natural way for FEMSystem-derived code to access the current t is with the System::time variable. Because that exists at a lower level, it shouldn't be removed from the parent class. However, an FEMContext::time variable will also have to exist to allow independent threads to all do higher order accurate integration of problems with functions of t in their weak forms. On the bright side, this won't be a new bug, because none of our current time solvers update System::time properly in mid-timestep anyway. If someone's evaluating FEMSystem::time from within one of the residual member functions and wondering why their theta=0.5 code is only seeing O(deltat) convergence, yell at me and I'll fix it now; otherwise I'll wait until I redo the whole API. --- 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
