GoalAdaptiveNonlinearVariationalSolver - #4893
Conversation
daf58a1 to
b28fbf5
Compare
|
For example we might want to have |
|
How does this compare to all the mesh adaptivity work that has already been done with Firedrake (https://github.com/mesh-adaptation)? In particular https://github.com/mesh-adaptation/goalie |
|
I can add my perspective. I'm sure @stephankramer and @joewallwork will have other interesting things to say! Compared to goalie, this PR
This PR also composes nicely with the rest of Firedrake. When the mesh is refined, the integration with netgen ensures the geometry is better approximated (this is not true with goalie). The adaptive mesh hierarchy constructed by the More about adaptive mesh refinement vs adaptive remeshing, as there is a major mathematical difference. In the adaptive mesh refinement used in this PR, the adapted mesh is a refinement of the input mesh (ignoring better geometry approximation). This means that for normal elements the refined function space is a superspace of the original one, which is very advantageous for stable approximation: loosely speaking, your approximation can only get better as you refine. In contrast, with adaptive remeshing, the input and output meshes are in principle unrelated (although they are in practice, because the algorithm transforms the one into the other step by step), and so you don't have nice hierarchical approximations. I suspect this is why 95%+ of the community around adaptive discretisations use adaptive mesh refinement. |
|
Hi all, great to see this contribution! Nice work. I'll try to find some time to play around with this. To respond to @pefarrell's points:
Yes, Goalie is designed to handle time-dependent problems that consider multiple meshes during the simulation. You can apply it to stationary problems, too.
I had proposed an MSc project for a student to hook up AMR in Goalie using Netgen but unfortunately it didn't go ahead. It was designed to be general enough to allow different adaptor approaches but we have mainly used Animate so far.
Yeah this is one of the main limitations of Goalie.
Currently we make a choice of error estimate based on the dual-weighted residual. There were plans to support more/custom error estimates but we haven't had time.
I don't recall Goalie having limitations in terms of solvers, although I haven't tried loads of them. However, it is currently limited to simple theta-method timestepping schemes. |
|
Thanks for this useful exposition. By raising this I wanted to point out that there is a more general appetite for adaptivity using Firedrake and therefore it would be very nice to set this up in a more general way so that potential future contributions would be able to reuse some of the code. I think this should be brought to a Firedrake team meeting for further discussion. |
998ef03 to
582c8f4
Compare
| * ``False`` (default) – never write. | ||
| * ``True`` – write at every iteration. | ||
| * A positive integer ``k`` – write every ``k`` iterations. | ||
| verbose |
There was a problem hiding this comment.
I think this whole thing should be PETSc options. This would be cognate with what we do for NVS
| self.eta_cell_sum_vec = [] | ||
| self.eff1_vec = [] | ||
| self.eff2_vec = [] | ||
| self.eff3_vec = [] |
|
|
||
| def print(self, *args, **kwargs): | ||
| if self.options.verbose: | ||
| PETSc.Sys.Print(*args, **kwargs) |
| coef_map = {} | ||
| self.problem = refine(self.problem, refine, coefficient_mapping=coef_map) | ||
|
|
||
| def compute_efficiency_indices(self, eta_cell, eta_h, eta): |
There was a problem hiding this comment.
feels like it should somehow be programmable rather than being part of the abstract interface.
| A dictionary of solver parameters for the primal problem | ||
| dual_solver_parameters | ||
| A dictionary of solver parameters for the dual problem. | ||
| Defaults to `primal_solver_parameters`. |
There was a problem hiding this comment.
namespace this into the options tree.
| """ | ||
| u_out = self.u_high if self.u_high is not None else self.problem.u | ||
| error_estimate = self.etah_vec[-1] | ||
| return u_out, error_estimate |
There was a problem hiding this comment.
return the soltion, query for the error. Just like converged reason.
…roject/firedrake into pbrubeck/goal-adaptive-solver
Add a global DWR estimate of the error in the goal functional, split into
the error committed by discretising and the error committed by not solving
the algebraic system exactly, and stop adapting once it meets a tolerance.
* -dwr_atol/-dwr_rtol stop the loop once |eta| < max(atol, rtol*|J(u_h)|).
A marking callback that returns None now means "stop adapting": the
refine hook hands the same DM back, and a SNES convergence test reports
immediate convergence, so the rest of -snes_adapt_sequence costs nothing.
PETSc's DMAdaptor has no tolerance of its own to do this with.
* -dwr_monitor reports the estimate once per cycle. An exact_solution kwarg
adds the true error and an effectivity index to that output.
* Warn when the solver error estimate exceeds the discretisation error
estimate, since refining then cannot help.
* A marking callback is no longer required: without one, adaptive
refinement degenerates to uniform refinement, as grid sequencing asks.
Three fixes this uncovered:
* dwr_ options were read from the reconstructed context, whose prefix is
renamed after the multigrid level it becomes, so every one of them
silently reverted to its default after the first refinement.
* Function's second positional argument is val, not name, so the
enriched-order primal solve raised on every mark.
* Interpolation between a space and itself is the identity. PETSc asks for
it when the adaptor hands back the DM it was given.
Port the p-Laplacian goal-based adaptivity demo from #4893, with netgen
replaced by a plain mesh, and give it and the elasticity demo names that say
which is linear and which is not. The elasticity demo needs MUMPS null-pivot
detection for its indefinite system.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Closed in favour of #5273 |
5 participants
Description
Implements a new
GoalAdaptiveNonlinearVariationalSolverclass to do adaptive refinement on aNonlinearVariationalProblemdefined on a coarse (netgen) mesh. The adaptive procedure relies on a user-specified functional of interest, refered to as goal functional. The solver will iteratively solve -> estimate -> mark -> refine until an automatic error estimate to the goal functional falls below a user specified tolerance.