Cc:ing this to Derek to make sure he doesn't miss this one; I think he's done the most libMesh work with custom preconditioners most recently and he might have thoughts or see concerns we're missing.
My own thoughts: On Tue, 21 Sep 2010, Tim Kroeger wrote: > 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? That's an interesting case. > 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. Definitely don't like these options. > 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. Hmm... The SystemSubset is indeed what's responsible for determining whether the dof list has changed, so it should be responsible for communicating that somehow. Call this Possibility #7: int SystemSubset::set_revision gets incremented every time the dof list changes. LinearImplicitSystem::last_set_revision stores the set_revision that was used to create the current preconditioner. Before solving, we check to see whether the set_revisions no longer match; if they don't then we clear the preconditioner. If the user is creating custom preconditioners, then he has to remember to tell SystemSubset to redetermine the dof list manually and then create a preconditioner accordingly, but if his code doesn't do so then at least he's just stuck with a default preconditioner, not a broken one. > 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. But unless the System is using the current SystemSubset, that SystemSubset never gets called upon to create a new dof list, right? > Possibility #5: As #4, but SystemSubset will check first whether System is > currently restricted to *this. Even if I'm right about this being unnecessary, it would be a very good idea at least as an assertion. > 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. I think it's a matter of opinion whether this is less or more confusing than #5. --- Roy ------------------------------------------------------------------------------ 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
