OK, thanks, I'll try that out. I'll make a PR if it works for me. Thanks, David
On Mon, Jan 12, 2015 at 4:44 PM, Roy Stogner <[email protected]> wrote: > > On Mon, 12 Jan 2015, David Knezevic wrote: > > I'm solving a series of PDEs with different non-zero Dirichlet boundary >> conditions. I'm using the DirichletBoundary functionality, and for each >> solve in the series I currently do this via the following steps: >> >> - Remove all existing DirichletBoundaries via >> get_dof_map().remove_dirichlet_boundary >> - Add the new DirichletBoundary objects (for the same set of boundaries as >> before) >> - Call EquationSystems::reinit() to reinitialize the dof constraints >> - Perform the solve >> >> This works fine, but the call to EquationSystems::reinit() is somewhat >> inefficient for me because it clobbers the PETSc matrix data so that PETSc >> doesn't let me reuse the preconditioner from one solve to the next. >> >> I'm not changing the mesh and I'm constraining the same set of dofs on >> each >> solve, so I was wondering if there's a way to just recompute the >> constraints without calling EquationSystems::reinit() ? I wonder if it >> would be sufficient for me to pick out a couple of the relevant commands >> from EquationSystems::reinit, like: >> >> sys.get_dof_map().create_dof_constraints(_mesh, sys.time); >> sys.get_dof_map().process_constraints(_mesh); >> > > This has been (buried a ways down) on my TODO list for quite a while; > we definitely need to have some kind of "reinit_constraints()" method > to do just that more efficiently; it's ludicrous to redo every > DofObject and matrix just to change a few constraint right hand sides, > and I've got one case where the wasted reinit() calls are something > like 20% of runtime. > > I believe a complete implementation would look like: > > System::reinit_constraints() { > sys.get_dof_map().create_dof_constraints(_mesh, sys.time); > sys.user_constrain(); > sys.get_dof_map().process_constraints(_mesh); > sys.get_dof_map().prepare_send_list(); > } > > The user_constrain() should be a no-op in your case. The > prepare_send_list() might be a bit of overhead for our use cases, but > I didn't see it show up in profiling, and it would be nice to leave it > in for use in e.g. contact problems where communication details may > depend on what ended up constrained by what. > > Would you give that a try and give back to me? > > Copying Paul so he'll be aware of upcoming GRINS changes if this > works, plus Nick so he'll be relieved to find out someone's finally > fixing this junk. > > Thanks, > --- > Roy > ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. www.gigenet.com _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
