One problem just popped up with the subset stuff: PetscLinearSolver keeps the _pc object constant across solves (... perhaps that was the reason for using SAME_NONZERO_PATTERN?) unless PetscLinearSolver::clear() is called in between. When the subset on which to solve is changed, however, this causes a PetscError. Of course, I can let PetscLinearSolver::restrict_solve_to() call PetscLinearSolver::clear(), but this does not always suffice. That is, a given SystemSubset object might change the list of dofs from time to time. That is, if the subset is selected via the subdomain id and the application changes some cell's subdomain id (which is done in my application), the subset changes without a call to PetscLinearSolver::restrict_solve_to(). The question is now: Whose responsibility is it to call LinearSolver::clear() in this situation?
Possibility #1: The user. Works of course, but the user is likely to forget, and this causes a difficult-to-find error. Possibility #2: The PetscLinearSolver class. But this class doesn't directly get to know. It would have to make a backup of the dof list of the previous solve and compare it. That does not seem to be performant. Possibility #3: The SystemSubset class. This seems natural since this class has to re-determine the list anyway (which, in the current implementation, is done in a method that has to be called by the user). However, the SystemSubset class has no access to the solver. It has access to the System object (needs that because of the DofMap), but in general can't assume that the System is a LinearImplicitSystem. Possibility #4: The SystemSubset class calls System::restrict_solve_to(this) in the described situation, and LinearImplicitSystem::restrict_solve_to() calls LinearSolver::clear(). The latter has to be done anyway, of course. The problem with this is that it cannot be assumed that the System is actually currently restricted to the given SystemSubset. That is, the user could create several SystemSubset objects for the same System and activate them one after each other, to solve the same system of different subsets. Possibility #5: As #4, but SystemSubset will check first whether System is currently restricted to *this. Possibility #6: Similarly as #5, but to make it less confusing, the API of System gets an additional method called System::update_subset(SystemSubset&), the task of which is to recognize that the given subset has changed. That is, LinearImplicitSystem::update_subset(my_subset) will call LinearSolver::init() if the System is currently restricted to my_subset, otherwise do nothing. Within all these possibilities, I find #6 least confusing and least error-prone. Still, it's not really nice, and I am open to other suggestions. Best Regards, Tim -- Dr. Tim Kroeger CeVis -- Center of Complex Systems and Visualization University of Bremen [email protected] Universitaetsallee 29 [email protected] D-28359 Bremen Phone +49-421-218-7710 Germany Fax +49-421-218-4236 ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
