diff --git a/docs/Makefile b/docs/Makefile deleted file mode 100644 index 8020c04c..00000000 --- a/docs/Makefile +++ /dev/null @@ -1,66 +0,0 @@ -# Minimal makefile for Sphinx documentation - -# You can set these variables from the command line. -SPHINXOPTS = -SPHINXBUILD = sphinx-build -SPHINXAPIDOC = sphinx-apidoc -SPHINXPROJ = Goalie -SOURCEDIR = source -BUILDDIR = build -PYTHON = ${VIRTUAL_ENV}/bin/python3 - -# Put it first so that "make" without argument is like "make help". -help: - @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) - -.PHONY: help Makefile clean - -GENERATED_FILES = source/demos - -.PHONY: copy_demos - -source/demos: copy_demos - -copy_demos: - install -d source/demos - cp ../demos/*.py source/demos - cp ../demos/*.jpg source/demos - cp ../demos/demo_references.bib source/demos - for file in source/demos/*.py; do pylit -c $$file; mv $$file.txt $$file.rst; done - install -d $(BUILDDIR)/html/demos - cp source/demos/*.py $(BUILDDIR)/html/demos - cp source/demos/*.jpg $(BUILDDIR)/html/demos - cp source/demos/*.bib $(BUILDDIR)/html/demos - install -d $(BUILDDIR)/html/maths - mkdir -p $(BUILDDIR)/html/_images - cp source/maths/images/*.jpg $(BUILDDIR)/html/_images - -SPHINX_TARGETS = html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub \ - latex latexpdf latexpdfja text man texinfo info gettext changes \ - xml pseudoxml linkcheck doctest coverage - -# Catch-all target: route all unknown targets to Sphinx using the new -# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). -$(SPHINX_TARGETS): Makefile - @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) - -html: apidoc $(GENERATED_FILES) - -.PHONY: apidoc -apidoc: - $(SPHINXAPIDOC) $$($(PYTHON) -c 'import goalie; import os; print(os.path.dirname(goalie.__file__))') -o source -f -T - # TODO: Do this in a less hacky way - echo "" >> source/goalie.rst - echo "References" >> source/goalie.rst - echo "----------" >> source/goalie.rst - echo "" >> source/goalie.rst - echo ".. rubric:: References" >> source/goalie.rst - echo "" >> source/goalie.rst - echo ".. bibliography:: references.bib" >> source/goalie.rst - echo " :all:" >> source/goalie.rst - - -clean: - -git clean -fdx $(BUILDDIR)/html/ - -rm -rf $(BUILDDIR)/doctrees - -rm -rf $(GENERATED_FILES) diff --git a/docs/source/conf.py b/docs/source/conf.py deleted file mode 100644 index 3fc63d41..00000000 --- a/docs/source/conf.py +++ /dev/null @@ -1,193 +0,0 @@ -# -*- coding: utf-8 -*- -# -# Thetis documentation build configuration file, created by -# sphinx-quickstart on Tue Dec 20 16:15:38 2016. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# Note that not all possible configuration values are present in this -# autogenerated file. -# -# All configuration values have a default; values that are commented out -# serve to show the default. - -# If extensions (or modules to document with autodoc) are in another directory, -# add these directories to sys.path here. If the directory is relative to the -# documentation root, use os.path.abspath to make it absolute, like shown here. -# -# import os -# import sys -# sys.path.insert(0, os.path.abspath('.')) -import datetime - - -# -- General configuration ------------------------------------------------ - -# If your documentation needs a minimal Sphinx version, state it here. -# -# needs_sphinx = '1.0' - -# Add any Sphinx extension module names here, as strings. They can be -# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom -# ones. -extensions = [ - "sphinx.ext.autodoc", - "sphinx.ext.intersphinx", - "sphinx.ext.mathjax", - "sphinx.ext.viewcode", - "sphinx.ext.githubpages", - "sphinxcontrib.bibtex", -] - -# Add any paths that contain templates here, relative to this directory. -templates_path = ["_templates"] - -# The suffix(es) of source filenames. -# You can specify multiple suffix as a list of string: -# -# source_suffix = ['.rst', '.md'] -source_suffix = ".rst" - -# The master toctree document. -master_doc = "index" - -# General information about the project. -project = "Goalie" -copyright = f"2021-{datetime.datetime.now().year}, Joseph G. Wallwork et al." -author = "Joseph G. Wallwork et al." - -# The version info for the project you're documenting, acts as replacement for -# |version| and |release|, also used in various other places throughout the -# built documents. -# -# The short X.Y version. -import goalie - -version = goalie.__version__ -# The full version, including alpha/beta/rc tags. -release = goalie.__version__ - -# The language for content autogenerated by Sphinx. Refer to documentation -# for a list of supported languages. -# -# This is also used if you do content translation via gettext catalogs. -# Usually you set "language" from the command line for these cases. -language = "en" - -# List of patterns, relative to source directory, that match files and -# directories to ignore when looking for source files. -# This patterns also effect to html_static_path and html_extra_path -exclude_patterns = [] - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = "sphinx" - -# If true, `todo` and `todoList` produce output, else they produce nothing. -todo_include_todos = False - - -# -- Options for HTML output ---------------------------------------------- - -# The theme to use for HTML and HTML Help pages. See the documentation for -# a list of builtin themes. -# -html_theme = "nature" -# Add any paths that contain custom themes here, relative to this directory. -html_theme_path = ["_themes"] - -# Theme options are theme-specific and customize the look and feel of a theme -# further. For a list of options available for each theme, see the -# documentation. -# -# html_theme_options = {} - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = [] - - -# -- Options for HTMLHelp output ------------------------------------------ - -# Output file base name for HTML help builder. -htmlhelp_basename = "Goaliedoc" - - -# -- Options for LaTeX output --------------------------------------------- - -latex_elements = { - # The paper size ('letterpaper' or 'a4paper'). - # - # 'papersize': 'letterpaper', - # The font size ('10pt', '11pt' or '12pt'). - # - # 'pointsize': '10pt', - # Additional stuff for the LaTeX preamble. - # - # 'preamble': '', - # Latex figure (float) alignment - # - # 'figure_align': 'htbp', -} - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, -# author, documentclass [howto, manual, or own class]). -latex_documents = [ - ( - master_doc, - "Goalie.tex", - "Goalie Documentation", - "Joseph G. Wallwork et al.", - "manual", - ), -] - - -# -- Options for manual page output --------------------------------------- - -# One entry per manual page. List of tuples -# (source start file, name, description, authors, manual section). -man_pages = [(master_doc, "goalie", "Goalie Documentation", [author], 1)] - - -# -- Options for Texinfo output ------------------------------------------- - -# Grouping the document tree into Texinfo files. List of tuples -# (source start file, target name, title, author, -# dir menu entry, description, category) -texinfo_documents = [ - ( - master_doc, - "Goalie", - "Goalie Documentation", - author, - "Goalie", - "Goalie Goal-Oriented Mesh Adaptation Toolkit", - "Miscellaneous", - ), -] - -# FIXME: Avoid full paths, e.g. firedrake.function.Function -add_module_names = False - -# Example configuration for intersphinx: refer to the Python standard library. -intersphinx_mapping = { - "firedrake": ("https://firedrakeproject.org/", None), - "python": ("https://docs.python.org/3/", None), - "thetis": ("https://thetisproject.org/", None), - 'ufl': ('https://fenics.readthedocs.io/projects/ufl/en/latest/', None), -} - -autoclass_content = "both" - -# -- Options for sphinxcontrib.bibtex ------------------------------------ -bibtex_bibfiles = [ - "references.bib", - "demos/demo_references.bib", - "maths/1-references.bib", - "maths/2-references.bib", - "maths/3-references.bib", - "maths/4-references.bib", -] diff --git a/docs/source/index.rst b/docs/source/index.rst deleted file mode 100644 index 3e6c29c7..00000000 --- a/docs/source/index.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. title:: Goalie Goal-Oriented Mesh Adaptation Toolkit - -.. only:: html - -Goalie Goal-Oriented Mesh Adaptation Toolkit -============================================ - -Goalie provides metric-based goal-oriented mesh adaptation -functionality to the Python-based finite element library -`Firedrake `__. The 'y' is -silent, so its pronunciation is identical to 'Proteus' - the -ancient Greek god of the constantly changing surface of the -sea. - - -.. rubric:: Mathematical background - -Goal-oriented mesh adaptation presents one of the clearest -examples of the intersection between adjoint methods and mesh -adaptation. It is an advanced topic, so it is highly -recommended that users are familiar with adjoint methods, -mesh adaptation and the goal-oriented framework before -starting with Goalie. - -We refer to the `Firedrake documentation -`__ -for an introduction to the finite element method - the -discretisation approach assumed throughout. The -`dolfin-adjoint` package (which Goalie uses to solve adjoint -problems) contains some `excellent documentation -`__ -on the mathematical background of adjoint problems. The -goal-oriented error estimation and metric-based mesh adaptation -functionalities provided by Goalie are described in the manual. - -.. toctree:: - :maxdepth: 2 - - Goalie manual - - -.. rubric:: API documentation - -The classes and functions which comprise Goalie may be found -in the API documentation. - -.. toctree:: - :maxdepth: 1 - - Goalie API documentation - -They are also listed alphabetically on the :ref:`index ` -page. The index may be searched using the inbuilt -:ref:`search engine `. Goalie source code is hosted on -`GitHub `__. - - -.. rubric:: Demos - -Goalie contains a number of demos to illustrate the correct -usage of its different functionalities. It is highly recommended -that these are read in order, as many of the demos build upon -earlier ones. - -*Time partitions and mesh sequences* - -.. toctree:: - :maxdepth: 1 - - Partitioning a time interval - Creating a mesh sequence - Burgers equation on a sequence of meshes - Adjoint Burgers equation - Adjoint Burgers equation on two meshes - Adjoint Burgers equation with a time-integrated QoI - Adjoint Burgers equation (object-oriented approach) - Solid body rotation - Solid body rotation with multiple prognostic variables - Advection-diffusion-reaction - Advection-diffusion-reaction with multiple prognostic variables - -*Error estimation* - -.. toctree:: - :maxdepth: 1 - - Error estimation for Burgers equation - Point discharge with diffusion - -*Mesh adaptation* - -.. toctree:: - :maxdepth: 1 - - Hessian-based mesh adaptation for a 2D steady-state problem - Goal-oriented mesh adaptation for a 2D steady-state problem - Hessian-based mesh adaptation for a 2D time-dependent problem diff --git a/docs/source/maths/1-motivation.rst b/docs/source/maths/1-motivation.rst deleted file mode 100644 index 9e81d16d..00000000 --- a/docs/source/maths/1-motivation.rst +++ /dev/null @@ -1,156 +0,0 @@ -========== -Motivation -========== - -Computational physics contains a wide variety of applications -for which the accurate evaluation of a diagnostic -`quantity of interest (QoI)` is more important than the solution -of the prognostic equation that it is associated with. It is such -problems that Goalie is designed to solve. - -Given a partial differential equation (PDE) and a QoI, we are able -to formulate and solve the associated `adjoint problem`, which -describes how sensitivities of the QoI with respect to the PDE -solution propagate in space and time. Adjoint methods have many -uses, such as sensitivity analysis, gradient-based optimisation -and uncertainity quantification. Another less commonly used use -is for goal-oriented error estimation. - -The idea of goal-oriented error estimation is to approximate the -error accrued when evaluating the QoI using a particular -discretisation method in terms of residuals of the PDE and solutions -of the PDE and its adjoint. That is, we approximate an unknown -error quantity -- that we would like to minimise -- in terms of -computable (or at least approximable) quantities. Building upon -this, goal-oriented mesh adaptation takes such error estimators, -deduces local contributions from different regions of time and space -and modifies the discretisation appropriately so that high resolution -is used where the contribution to the QoI error is deemed to be high. -Moreover, low resolution is used where the corresponding contribution -is deemed to be low, meaning that resolution is not wasted -unnecessarily. - -Before progressing to the details of goal-oriented error estimation -and mesh adaptation, we provide an example application to demonstrate -a use-case where this technology is useful. - - -Tracer transport ----------------- - -Consider a relatively simple, steady-state PDE. Suppose we are -interested in the advection and diffusion of a tracer concentration, -which is being released from a point source. The tracer could represent -a chemical species or pollutant suspended in water, for example. - -Let :math:`c(\mathbf x)` denote the tracer concentration at point -:math:`\mathbf x\in\Omega`. The advection and diffusion processes are -governed by the PDE - -.. math:: - :label: tracer_eq - - \mathbf u\cdot\nabla c - -\nabla\cdot(D\nabla c) - =S, - -where :math:`\mathbf u` is the advective velocity, :math:`D` is the -diffusion coefficient and :math:`S` represents the source term. -Consider the "point discharge with diffusion" test case from :cite:`RCJ:14`. -That is, we have a rectangular domain, within which the fluid velocity -goes uniformly from left to right, i.e. :math:`\mathbf u=(1,0)`. -In such a case, we have an inflow across the left-hand boundary and -outflow across the right-hand boundary. Specifying the tracer -concentration to be zero on the inflow inflow, to satisfy natural -boundary conditions on the outflow and to satisfy Neumann conditions on the -channel sides, we are able to formulate and solve the problem numerically. - -.. figure:: images/point_discharge2d_forward.jpg - :figwidth: 60% - :align: center - - Finite element solution of the tracer transport problem. - Image taken from :cite:`WBHP:22` with authors' permission. - -In the above plot, the source term is centred at :math:`(2,5)`. -Tracer concentration is released, advected to the right and diffused -uniformly in all directions. Suppose now that there is also a receiver -region, centred at :math:`(20,7.5)` and with a radius of :math:`0.5`. -This setup can be understood as an idealised version of a -desalination plant outfall scenario, where the tracer is salinity -and we would like to understand the salt content at the inlet pipe -for the plant. In such a setup, the point source is the plant's -outlet pipe and the receiver region is the plant's inlet. As such, -we would like to accurately measure the functional - -.. math:: - :label: tracer_qoi - - J(c)=\int_R c\;\mathrm dx, - -where :math:`R` denotes the receiver region. Taking this as QoI, -the solution of the corresponding adjoint problem takes the form -below. - -.. figure:: images/point_discharge2d_adjoint.jpg - :figwidth: 60% - :align: center - - Finite element solution of the adjoint tracer transport problem. - Image taken from :cite:`WBHP:22` with authors' permission. - -Here the receiver region becomes a `source` for the adjoint problem. -Further, where the flow goes from left to right in the forward -problem, it goes from right to left in the adjoint. The adjoint -solution indicates that the QoI is most sensitive to what is happening -near to the receiver - which makes sense - and fairly sensitive to the -upstream conditions - which also makes sense. The adjoint solution is -near-zero downstream since the QoI is effectively independent of what -happens there in this advection-dominated problem. - -The goal-oriented error estimation technology allows us to construct -error indicator fields using the forward and adjoint solution fields -shown above. These combine the sensitivity information contributed by -the adjoint solution with information related to error distribution. -The error indicator then tells us which regions of the domain are -important in terms of accurately evaluating the QoI. - -Error indicator fields can be used to drive mesh adaptation, as discussed -above. This can be done in a variety of ways. Some examples for the -point discharge problem are shown below, including one approach that -gives rise to isotropic meshes and three which give rise to anisotropic -meshes. - -.. figure:: images/point_discharge2d_isotropic_dwr.jpg - :figwidth: 60% - :align: center - -.. figure:: images/point_discharge2d_anisotropic_dwr.jpg - :figwidth: 60% - :align: center - -.. figure:: images/point_discharge2d_weighted_hessian.jpg - :figwidth: 60% - :align: center - -.. figure:: images/point_discharge2d_weighted_gradient.jpg - :figwidth: 60% - :align: center - - Goal-oriented adapted meshes generated using various metric strategies. - Images taken from :cite:`WBHP:22` with authors' permission. - -The adapted meshes take rather different forms, but there are a number of -features that they have in common. For example, each of them deploy most -mesh resolution in bands between the source and receiver. In addition, -they tend to use less mesh resolution downstream (where the adjoint -solution is near zero) than upstream of the receiver region. - -The `next section <2-goal-oriented-error-estimation.html>`__ gives a -general overview of goal-oriented error estimation, including the main -ideas and fundamental mathematical results. - -References ----------- - -.. bibliography:: 1-references.bib diff --git a/docs/source/maths/1-references.bib b/docs/source/maths/1-references.bib deleted file mode 100644 index 75654f91..00000000 --- a/docs/source/maths/1-references.bib +++ /dev/null @@ -1,18 +0,0 @@ -@article{RCJ:14, - title={{TELEMAC} modeling system: {2D} hydrodynamics {TELEMAC-2D} software release 7.0 user manual}, - author={Riadh, A and Cedric, G and Jean, MH}, - journal={Paris: R\&D, Electricite de France}, - pages={134}, - year={2014} -} - -@article{WBHP:22, - title={Goal-oriented error estimation and mesh adaptation for tracer transport modelling}, - author={Wallwork, JG and Barral, N and Ham, DA and Piggott, MD}, - journal={Computer-Aided Design}, - volume={145}, - pages={103187}, - year={2022}, - publisher={Elsevier}, - doi={10.1016/j.cad.2021.103187} -} diff --git a/docs/source/maths/2-goal-oriented-error-estimation.rst b/docs/source/maths/2-goal-oriented-error-estimation.rst deleted file mode 100644 index eb727295..00000000 --- a/docs/source/maths/2-goal-oriented-error-estimation.rst +++ /dev/null @@ -1,104 +0,0 @@ -============================== -Goal-oriented error estimation -============================== - -In this manual page, it is assumed that you have read and understood -the `dolfin-adjoint -`__ -training material on adjoint methods. - -Goalie has been designed with time-dependent problems in mind. However, -the exposition of goal-oriented error estimation is most clearly presented -in the steady-state case. Therefore, suppose we have a "forward" PDE that -contains only derivatives in space and is written in the residual form, - -.. math:: - :label: forward - - F(u) = 0,\quad u\in V, - -where :math:`u` is the solution, which lives in a function space :math:`V`. -In addition, suppose that there exists a diagnostic quantity of interest -(QoI), - -.. math:: - :label: qoi - - J:V\rightarrow\mathbb R, - -for which we would like to accurately evaluate :math:`J(u)`. The adjoint -problem associated with :math:`J` is then given by - -.. math:: - :label: adjoint - - \frac{\partial F}{\partial u}^Tu^*=\frac{\partial J}{\partial u}^T, - \quad u^*\in V, - -where :math:`u^*` is the *adjoint solution*, which also lives in :math:`V`. - -Consider now a finite-dimensional subspace :math:`V_h\subset V` and suppose -that we have a weak formulation of the forward problem given by - -.. math:: - :label: weak_forward - - \rho(u_h,v)=0,\quad\forall v\in V_h, - -where :math:`u_h` is the approximate (weak) forward solution. Here -:math:`\rho(u_h,\cdot)` is often called the "weak residual" of the forward -problem. This is the equation that we solve when we call -:meth:`~.MeshSeq.solve_forward`. Similarly, suppose we have a weak formulation -of the adjoint problem with approximate (weak) adjoint solution :math:`u_h^*\in V_h`: - -.. math:: - :label: weak_adjoint - - \rho^*(u_h^*,v)=0,\quad\forall v\in V_h, - -where :math:`\rho^*(u_h^*,\cdot)` is the weak residual of the adjoint problem. -This is the equation that we solve when we call -:meth:`~.AdjointMeshSeq.solve_adjoint`. - -Recall that we seek to accurately evaluate :math:`J` using a finite element -method. This is the same as saying that we seek to minimise the "QoI error" -:math:`J(u)-J(u_h)`. The fundamental result in goal-oriented error estimation -is the first order *dual weighted residual* result :cite:`BR:01`, - -.. math:: - :label: dwr1 - - J(u)-J(u_h)=\rho(u_h,u^*)+R^{(2)}, - -which relates the QoI error to the forward weak residual with the test function -replaced by the adjoint solution. This result is "first order" in the sense -that the remainder term :math:`R^{(2)}` is quadratic in the forward and adjoint -discretisation errors :math:`u-u_h` and :math:`u^*-u_h^*`. There also exists -a second order result, - -.. math:: - :label: dwr2 - - J(u)-J(u_h)=\frac12\rho(u_h,u^*)+\frac12\rho^*(u_h^*,u)+R^{(3)}, - -with remainder term :math:`R^{(3)}` that is cubic in the forward and adjoint -discretisation errors. We refer to the part of the RHS of each equation without -the remainder term a *dual weighted residual error estimate*, since it approximates -the QoI error. - -Note that the first order DWR result :eq:`dwr1` replaces the test function with -the *true* adjoint solution, :math:`u^*`. Further, the second order result -:eq:`dwr2` also includes the *true* forward solution. Neither of these quantities -are known in practice. Therefore, we can usually only evaluate dual weighted -residual error estimates in an approximate sense. Typically, this means approximating -the true adjoint and/or forward solution using a higher order method. A simple -- but -computationally intensive -- approach is to solve the appropriate equation again in a -globally "enriched" finite element space. For example, on a uniformly refined mesh or -in a function space with higher polynomial order. This can be achieved in Goalie -using :meth:`~.GoalOrientedMeshSeq.indicate_errors`. See `the Burgers error estimation demo -<../demos/burgers_ee.py.html>`__ for example usage. - -References ----------- - -.. bibliography:: 2-references.bib diff --git a/docs/source/maths/2-references.bib b/docs/source/maths/2-references.bib deleted file mode 100644 index 366039ed..00000000 --- a/docs/source/maths/2-references.bib +++ /dev/null @@ -1,10 +0,0 @@ -@article{BR:01, - title={An optimal control approach to a posteriori error estimation in finite element methods}, - author={Becker, Roland and Rannacher, Rolf}, - journal={Acta numerica}, - volume={10}, - pages={1--102}, - year={2001}, - publisher={Cambridge University Press}, - doi={10.1017/S0962492901000010} -} diff --git a/docs/source/maths/3-metric-based.rst b/docs/source/maths/3-metric-based.rst deleted file mode 100644 index 9382808f..00000000 --- a/docs/source/maths/3-metric-based.rst +++ /dev/null @@ -1,397 +0,0 @@ -========================== -The metric-based framework -========================== - -The goal-oriented mesh adaptation functionality in Goalie -is designed such that it is agnostic of the specific method -used to modify the mesh. However, to give a concrete example, -this section describes the *metric-based* mesh adaptation -framework. Integration of this adaptation approach into the -Firedrake finite element library is currently underway. - -Metric spaces -------------- - -The metric-based framework has its roots in Riemannian -geometry - in particular, Riemannian metric spaces. - -A `metric space` -:math:`(\mathcal V,\underline{\mathbf M})` consists -of a vector space :math:`\mathcal V` and a `metric` -:math:`\underline{\mathbf M}` defined upon it. Under -the assumption that :math:`\mathcal V=\mathbb R^n` -for some :math:`n\in\mathbb N`, :math:`\mathcal M` can -be represented as a real :math:`n\times n` symmetric -positive-definite (SPD) matrix. From the metric, we -may deduce a distance function and various geometric -quantities related to the metric space. -The most well-known example of an :math:`n`-dimensional -metric space is Euclidean space, :math:`\mathbb E^n`. -Euclidean space is :math:`\mathbb R^n`, with the -:math:`n`-dimensional identity matrix -:math:`\underline{\mathbf I}` as its metric. -This gives rise to the well-known :math:`\ell_2` -distance function, - -.. math:: - :label: l2_distance - - d_2(\mathbf u,\mathbf v) - :=\sqrt{\sum_{i=1}^n(v_i-u_i)^2} - =\sqrt{(\mathbf{v}-\mathbf{u})^T\:\underline{\mathbf I}\:(\mathbf{v}-\mathbf{u})} - =\sqrt{\vec{\mathbf{uv}}^T\:\underline{\mathbf M}\:\vec{\mathbf{uv}}}, - -where :math:`\vec{\mathbf{uv}}` -denotes the vector from -:math:`\mathbf u=(u_1,\dots,u_n)\in\mathbb R^n` to -:math:`\mathbf v=(v_1,\dots,v_n)\in\mathbb R^n`. - -The definition above assumes that the metric takes a fixed -value. A `Riemannian metric space`, on the other hand, is -defined point-wise on a domain :math:`\Omega`, such that -its value is an :math:`n\times n` SPD matrix `at each point` -:math:`\mathbf x\in\Omega`. We use the notation -:math:`\mathcal M=\{\underline{\mathbf M}(\mathbf x)\}_{\mathbf x\in\Omega}` -for the Riemannian metric. Throughout this documentation, -the term `metric` should be understood as referring -specifically to a Riemannian metric. The fact that a -Riemannian metric can vary in space means that Riemannian -metric spaces are warped, when viewed in Euclidean space. -For example, think of the space-time continuum in -General Relativity. This is probably the most famous -example of a Riemannian metric space. - -.. figure:: https://upload.wikimedia.org/wikipedia/commons/6/63/Spacetime_lattice_analogy.svg - :figwidth: 80% - :align: center - - An example of a Riemannian metric space: the - gravitational field of the Earth (source: - `Wikipedia `__). - - -Given a Riemannian metric -:math:`\mathcal M=\{\underline{\mathbf M}(\mathbf x)\}_{\mathbf x\in\Omega}`, -we can define distance in the associated space as above. -However, since space is warped, we need -to integrate along a `curve`, rather than a straight line. -Given that :math:`\boldsymbol\gamma:[0,1]\rightarrow\mathbb R^n` -parametrises the curve from :math:`\mathbf u\in\Omega` to -:math:`\mathbf v\in\Omega`, the distance may be computed -using the parametric integral - -.. math:: - :label: metric_distance - - d_{\mathcal M}(\mathbf u,\mathbf v) - :=\int_0^1\sqrt{\vec{\mathbf{uv}}\:\underline{\mathbf M}(\boldsymbol\gamma(\xi))\:\vec{\mathbf{uv}}}\;\mathrm d\xi. - -We define length in the metric space by - -.. math:: - :label: metric_length - - \ell_{\mathcal M}(\vec{\mathbf{uv}}) - :=d_{\mathcal M}(\mathbf u,\mathbf v). - -As well as distances and lengths, it is also possible to define -volume in Riemannian space. Given a subset -:math:`K\subseteq\Omega`, its volume is given by - -.. math:: - :label: metric_volume - - \left|K\right|_{\mathcal M} - :=\int_K\sqrt{\underline{\mathbf M}(\mathbf x)}\;\mathrm dx. - -The concept of angle also carries over, amongst other things. - -Metric fields should be defined in Firedrake using -:class:`firedrake.meshadapt.RiemannianMetric`\s from instances of -a Lagrange :func:`firedrake.functionspace.TensorFunctionSpace` of -degree 1, i.e. a tensor space that is piecewise linear and continuous. -The following example code snippet defines a uniform metric, for example: - -.. code-block:: python - - from firedrake import * - from firedrake.meshadapt import RiemannianMetric - from goalie import * - - mesh = UnitSquareMesh(10, 10) - P1_ten = TensorFunctionSpace(mesh, "CG", 1) - metric = RiemannianMetric(P1_ten) - metric.interpolate(as_matrix([[1, 0], [0, 1])) - - -Geometric interpretation ------------------------- - -A convenient way of visualising a Riemannian metric field -is using an ellipse (in 2D) or an ellipsoid (in 3D). As -mentioned above, the metric takes the form of an SPD matrix -:math:`\underline{\mathbf M}(\mathbf x)` at each point in -space, :math:`\mathbf x\in\Omega`. Since it is symmetric, -this matrix has an orthogonal eigendecomposition, - -.. math:: - :label: orthogonal_eigendecomposition - - \underline{\mathbf M}(\mathbf x) - =\underline{\mathbf V}(\mathbf x)\: - \underline{\boldsymbol\Lambda}(\mathbf x)\: - \underline{\mathbf V}(\mathbf x)^T, - -where -:math:`\underline{\mathbf V}(\mathbf x)=\begin{bmatrix}\mathbf v_1,\dots,\mathbf v_n\end{bmatrix}` -is its matrix of (orthonormal) eigenvectors and -:math:`\underline{\boldsymbol\Lambda}(\mathbf x)=\mathrm{diag}(\lambda_1,\dots,\lambda_n)` -is its matrix of eigenvalues. - -Viewed in Euclidean space (i.e. the `physical space`), -a 2D metric can be represented by an ellipse with -:math:`i^{th}` semi-axis taking the direction -:math:`\mathbf e_i:=\mathbf v_i` and having magnitude -:math:`h_i:=1/\sqrt{\lambda_i}`. Viewed in the metric -space (i.e. the `control space`), however, it is -represented by a unit circle. - -.. figure:: images/ellipse.jpg - :figwidth: 80% - :align: center - - Representation of a 2D Riemannian metric as an ellipse. - Image taken from :cite:`Wallwork:21` with author's permission. - -Given a metric field, the eigendecomposition may be -computed in Goalie using the function -:func:`~.compute_eigendecomposition`. Similarly, given -:class:`firedrake.function.Function`\s representing the eigenvectors and -eigenvalues of a metric, it may be assembled using the -function :func:`~.assemble_eigendecomposition`. - -The orthogonal eigendecomposition gives rise to another -matrix decomposition, which is useful for understanding -metric-based mesh adaptation. If we define `metric density` -as the square root of the sum of the eigenvalues, - -.. math:: - :label: metric_density - - \rho:=\sqrt{\prod_{i=1}^n\lambda_i}, - -and the :math:`i^{th}` anisotropy quotient in terms of -the metric magnitudes by - -.. math:: - :label: anisotropy_quotient - - r_i:=h_i^n\prod_{j=1}^n\frac1{h_j},\quad i=1,\dots,n, - -then we arrive at the decomposition - -.. math:: - :label: alternative_decomposition - - \underline{\mathbf M} - =\rho^{\frac2n}\: - \underline{\mathbf V}\: - \mathrm{diag}\left(r_1^{-\frac2n},\dots,r_n^{-\frac2n}\right)\: - \underline{\mathbf V}^T. - -The reason that this formulation is useful is because -it separates out information contained within the metric -in terms of: - -- sizes (the metric density); -- orientation (the eigenvectors); -- shape (the anisotropy quotients). - -These are the three aspects of a mesh that metric-based -mesh adaptation is able to control, whereas other mesh -adaptation methods can only usually control element sizes. - -The metric decomposition above can be computed in Goalie -using the function :func:`~.density_and_quotients`. - - -Continuous mesh analogy ------------------------ - -The work of :cite:`LA:11` established duality between -the (inherently discrete) mesh and a (continuous) -Riemannian metric field. Having a continuous -representation for the mesh means that we are able to -apply optimisation techniques that are designed for -continuous problems. - -An example of one of the correspondences is between -`metric complexity` and mesh vertex count. Metric -complexity is expressed using the formula - -.. math:: - :label: metric_complexity - - \mathcal C(\mathcal M)=\int_\Omega\sqrt{\mathrm{det}(\mathcal M(\mathbf x)})\;\mathrm dx. - -and can be interpreted as the volume of the spatial -domain in metric space (recall the formula for -volume in Riemannian space). Metric complexity may -be computed in Firedrake using the method -:meth:`~.complexity`. -The time-dependent extension of metric complexity, - -.. math:: - :label: space_time_complexity - - \mathcal C(\mathcal M)=\int_{\mathcal T}\int_\Omega\sqrt{\mathrm{det}(\mathcal M(\mathbf x,t)})\;\mathrm dx\;\mathrm dt - -over a time interval :math:`\mathcal T` is analogous -to the total number of mesh vertices over all timesteps. - - -Metric-based mesh adaptation ----------------------------- - -The idea of metric-based mesh adaptation is to use -a Riemannian metric space `within` the mesher. In -doing so, we seek to modify the mesh so that in -the metric space it is a so-called `unit mesh`. -That is, all of its elements have unit edge length. -For a 2D triangular mesh this means having a mesh -comprised of equilateral elements with all sides -being of length one. -Making the elements consistent in metric space can -be thought of in terms of equidistributing errors, -which is one of the key ideas behind mesh adaptation -in general. - -In practice, it is not possible to tessellate space -with regular elements. Therefore, we instead seek a -`quasi-unit mesh`, whose elements are all "close to" -unit, in some sense. - -During the mesh adaptation process, the entities, -nodal positions and/or connectivity are modified -in order to move towards a quasi-unit mesh. The way -that this is quantified in practice is using a -`quality function`. For example, consider the 2D -quality function - -.. math:: - :label: metric_quality - - Q_{\mathcal M} - =\frac{\sqrt3}{12}\frac{\sum_{\boldsymbol\gamma\in\partial K}\ell_{\mathcal M}(\boldsymbol\gamma)^2}{| - K|_{\mathcal M}}, - -where :math:`\boldsymbol\gamma\in\partial K` indicates -an edge from the edge set of element :math:`K`. It -can be shown that :math:`Q_{\mathcal M}` is minimised -for an equilateral triangular element. - - -Operations on metrics ---------------------- - -In order to use metrics to drive mesh adaptation -algorithms for solving real problems, they must -first be made relevant to the application. Metrics -should be normalised in order to account for domain -geometry, dimensional scales and other properties -of the problem, such as the extent to which it is -multi-scale. - -In Firedrake, normalisation is performed by the -method :meth:`~.normalise` in the -:math:`L^p` sense: - -.. math:: - :label: lp_metric - - \mathcal M_{L^p}:= - \mathcal C_T^{\frac2n} - \:\left(\int_{\Omega}\mathrm{det}(\underline{\mathbf M})^{\frac p{2p+n}}\;\mathrm dx\right)^{-\frac2n} - \:\mathrm{det}(\mathcal M)^{-\frac1{2p+n}} - \:\mathcal M, - -where :math:`\mathcal C_T` is the target metric -complexity (i.e. tolerated vertex count), -:math:`n` is the spatial dimension and -:math:`p\in[1,\infty)` is the order of the -normalisation. Taking :math:`p=1` implies a truly -multi-scale metric and this becomes less so for -higher orders. In the limit :math:`p\rightarrow\infty` -we obtain - -.. math:: - :label: linf_metric - - \mathcal M_{L^\infty}:= - \left(\frac{\mathcal C_T}{\mathcal C(\mathcal M)}\right)^{\frac2n} - \:\mathcal M. - -For time-dependent problems, the normalisation -formulation also includes integrals in time. Suppose -:math:`\mathcal T` is the time period of interest, -:math:`\Delta t>0` is the timestep and -:math:`\mathcal C_T` is now the target `space-time` -complexity. Then the function :func:`~.space_time_normalise` -computes - -.. math:: - :label: space_time_lp_metric - - \mathcal M_{L^p}:= - \mathcal C_T^{\frac2n} - \:\left(\int_{\mathcal T}\frac1{\Delta t}\int_\Omega\mathrm{det}(\underline{\mathbf M})^{\frac p{2p+n}}\;\mathrm dx\;\mathrm dt\right)^{-\frac2n} - \:\mathrm{det}(\mathcal M)^{-\frac1{2p+n}} - \:\mathcal M. - -In many cases, it is convenient to be able to combine -different metrics. For example, if we seek to adapt -the mesh such that the value of two different error -estimators are reduced. The simplest metric combination -method from an algebraic perspective is the metric -average: - -.. math:: - :label: metric_average - - \tfrac12(\mathcal M_1 + \mathcal M_2), - -for two metrics :math:`\mathcal M_1` and -:math:`\mathcal M_2`. Whilst mathematically simple, -the geometric interpretation of taking the metric -average is not immediately obvious. Metric intersection, -on the other hand, is geometrically straight-forward, -but non-trivial to write mathematically. The elliptic -interpretation of two metrics is the largest ellipse -which fits within the ellipses associtated with the -two input metrics. As such, metric intersection yields -a new metric whose complexity is greater than (or equal -to) its parents'. This is not true for the metric -average in general. See :cite:`PUDG:01` for details. - -.. figure:: images/intersection.jpg - :figwidth: 80% - :align: center - - Intersection of two 2D Riemannian metrics, interpreted - in terms of their elliptical representations. - Image taken from :cite:`Wallwork:21` with author's permission. - -Metric combination may be achieved in Goalie using the -function :func:`~.combine_metrics`, which defaults to the -metric average. - - -Now that a concrete example of a mesh adaptation approach has -been described, we move on to discuss goal-oriented mesh -adaptation using Goalie in the `following section -<4-goal-oriented-mesh-adaptation.html>`__. - -References ----------- - -.. bibliography:: 3-references.bib diff --git a/docs/source/maths/3-references.bib b/docs/source/maths/3-references.bib deleted file mode 100644 index ae532092..00000000 --- a/docs/source/maths/3-references.bib +++ /dev/null @@ -1,31 +0,0 @@ -@article{PUDG:01, - title={Tetrahedral mesh optimisation and adaptivity for steady-state and transient finite element calculations}, - author={Pain, CC and Umpleby, AP and De Oliveira, CRE and Goddard, AJH}, - journal={Computer Methods in Applied Mechanics and Engineering}, - volume={190}, - number={29-30}, - pages={3771--3796}, - year={2001}, - publisher={Elsevier}, - doi={10.1016/S0045-7825(00)00294-2} -} - -@article{LA:11, - title={Continuous mesh framework part {I}: well-posed continuous interpolation error}, - author={Loseille, A and Alauzet, F}, - journal={SIAM Journal on Numerical Analysis}, - volume={49}, - number={1}, - pages={38--60}, - year={2011}, - publisher={SIAM}, - doi={10.1137/090754078} -} - -@article{Wallwork:21, - title={Mesh adaptation and adjoint methods for finite element coastal ocean modelling}, - author={Wallwork, JG}, - year={2021}, - journal={PhD thesis, Imperial College London}, - doi={10.25560/92820} -} diff --git a/docs/source/maths/4-goal-oriented-mesh-adaptation.rst b/docs/source/maths/4-goal-oriented-mesh-adaptation.rst deleted file mode 100644 index 18429c1c..00000000 --- a/docs/source/maths/4-goal-oriented-mesh-adaptation.rst +++ /dev/null @@ -1,157 +0,0 @@ -============================= -Goal-oriented mesh adaptation -============================= - -Error indicators ----------------- - -Goal-oriented mesh adaptation is the term used to refer to -mesh adaptation methods that are driven by goal-oriented -error estimates. Recall from `the error estimation section -<2-goal-oriented-error-estimation.html>`__ of the manual -that the fundamental result is the dual weighted residual -(DWR) :eq:`dwr1`, which can be written in approximate form - -.. math:: - :label: dwr - - J(u)-J(u_h)\approx\rho(u_h,(u_h^*)^+), - -where :math:`(u_h^*)^+` denotes an approximation of the -adjoint solution from a (finite-dimensional) superspace of -the base finite element space, i.e. :math:`V_h^+\supset V_h`. - -Mesh adaptation is all about wisely using varying resolution -to equidistribute errors. This means increasing resolution -where errors are deemed to be high and reducing it where -errors are deemed to be low. We cannot immediately deduce -spatially varying information from :eq:`dwr` as it is currently -written. A simple, but effective way of extracting such -information is to compute the element-wise contributions, - -.. math:: - :label: dwr_sum - - \rho(u_h,(u_h^*)^+)=\sum_{K\in\mathcal{H}}i_K, - -where - -.. math:: - :label: dwr_indicator - - i_K:=\rho(u_h,(u_h^*)^+)|_K. - -is the so-called *error indicator* for element :math:`K`. -The second output of :meth:`~.GoalOrientedMeshSeq.indicate_errors` -contains error indicator fields -- element-wise constant fields, -whose value on :math:`K` is the indicator :math:`i_K`. - -Note that so far we have only discussed how to estimate and -indicate errors for steady-state problems. The extension to -the time-dependent case is similar, in the sense that we -take a timestep-by-timestep approach in time like how we take an -element-by-element approach in space. Avoiding some minor details, -we can apply all of the subsequently discussed methodology to the -weak residual associated with a single timestep. For simple -time integration schemes like Implicit Euler, the main difference -will be that the weak residual also includes a term that -discretises the time derivative. - -Adapting based on error indicators ----------------------------------- - -Once error indicator fields have been computed, there are many -different ways to perform mesh adaptation. One common approach is -to use a hierarchical type approach, where the mesh resolution is -locally increased in elements where the indicator value falls -below a pre-specified tolerance and is locally decreased if the -indicator values are already lower than required. This is sometimes -called "adaptive mesh refinement (AMR)", although the literature is -not entirely consistent on this. The terms "quad-tree" and "oct-tree" -are used when it is applied to quadrilateral and hexahedral meshes, -respectively. Sadly, this form of mesh adaptation is not supported -in Firedrake. - -As described in the `previous section <3-metric-based.html>`__, -metric-based mesh adaptation is another approach which is currently -being integrated into Firedrake and is supported on developer branches. -In that case, we need to construct a Riemannian metric from an -error indicator field. Goalie provides a number of different -driver functions for doing this. The simplest is -:func:`~.isotropic_metric`, which takes an error indicator field -and constructs a metric that specifies how a mesh should be adapted -purely in terms of element size (not orientation or shape). -Alternative anisotropic formulations, which combine error indicator -information with curvature information from the Hessians of solution -fields are provided by :func:`~.anisotropic_metric`. See the API -documentation (and references therein) for details. - -The metric-based framework has been the main backend used for -goal-oriented mesh adaptation during the development of Goalie. -However, this does not mean other approaches would not work. -Mesh movement (or :math:`r`-adaptation) has been implemented in -Firedrake on a number of occasions (such as :cite:`MCB:18,CWK+:22`) -and could plausibly be driven by goal-oriented error estimates. - -Fixed point iteration loops ---------------------------- - -In some mesh adaptation approaches, it is common practice to adapt -the mesh multiple times until convergence is attained, in some -sense. This is often the case under metric based mesh adaptation, -for example. Goalie includes two methods to facilitate such -iterative adaptation approaches, as described in the following. - -In the non-goal-oriented case, there is the -:meth:`~.MeshSeq.fixed_point_iteration` method, which accepts a -Python function that describes how to adapt the mesh as an argument. -This provides the flexibility to use different adaptation routines. -The function should take as input the :class:`~.MeshSeq` instance -and the dictionary of solution fields from each timestep. For -example, it could compute the Hessian of the solution field at each -timestep using :meth:`~.RiemannianMetric.compute_hessian`, ensure that -it is a metric using :meth:`~.RiemannianMetric.enforce_spd` and then -combine this information using averaging or intersection. -In each iteration, the PDE will be -solved over the sequence of meshes (with data transferred inbetween) -using :meth:`~.MeshSeq.solve_forward` and a Hessian-metric will be -constructed on each mesh. All of the meshes are then adapted. - -The iteration is terminated according to :class:`~.AdaptParameters` -when either the pre-specified maximum iteration count -:attr:`~.AdaptParameters.maxiter` is reached, or the meshes no -longer change substantially. This is the case when none of the -corresponding element counts changes more than the relative -tolerance :attr:`~.AdaptParameters.element_rtol`. - -.. note:: - The convergence criteria are not actually checked until the - minimum iteration count :attr:`~.AdaptParameters.miniter` - has been met. - -In the goal-oriented case, the -:meth:`~.GoalOrientedMeshSeq.fixed_point_iteration` method takes a -similar form, except that -:meth:`~.GoalOrientedMeshSeq.indicate_errors` is called, rather than -:meth:`~.MeshSeq.solve_forward`. That is, the forward problem is -solved over all meshes in the sequence, then the adjoint problem is -solved over all meshes in reverse and finally goal-oriented error -indicators are computed. As such, the adaptor function depends on -these error indicators, as well as the :class:`~.MeshSeq` and -solution field dictionary (which contains solutions of both the -forward and adjoint problems). - -Like with the simpler case, the goal-oriented fixed point iteration -loop is terminated if the maximum iteration count or relative -element count convergence conditions are met. However, there are two -additional convergence criteria defined in :class:`~.GoalOrientedParameters`. -Convergence is deduced if the QoI value changes between iterations -by less than :attr:`~.GoalOrientedParameters.qoi_rtol`. It is -similarly deduced if the error estimate value changes by less than -:attr:`~.GoalOrientedParameters.estimator_rtol`. - - -References ----------- - -.. bibliography:: 4-references.bib diff --git a/docs/source/maths/4-references.bib b/docs/source/maths/4-references.bib deleted file mode 100644 index 811de2ba..00000000 --- a/docs/source/maths/4-references.bib +++ /dev/null @@ -1,23 +0,0 @@ -@article{MCB:18, - title={Optimal-transport--based mesh adaptivity on the plane and sphere using finite elements}, - author={McRae, Andrew TT and Cotter, Colin J and Budd, Chris J}, - journal={SIAM Journal on Scientific Computing}, - volume={40}, - number={2}, - pages={A1121--A1148}, - year={2018}, - publisher={SIAM}, - doi={10.1137/16M1109515} -} - -@article{CWK+:22, - title={Multi-scale hydro-morphodynamic modelling using mesh movement methods}, - author={Clare, Mariana CA and Wallwork, Joseph G and Kramer, Stephan C and Weller, Hilary and Cotter, Colin J and Piggott, Matthew D}, - journal={GEM-International Journal on Geomathematics}, - volume={13}, - number={1}, - pages={1--39}, - year={2022}, - publisher={Springer}, - doi={10.1007/s13137-021-00191-1} -} diff --git a/docs/source/maths/images/ellipse.jpg b/docs/source/maths/images/ellipse.jpg deleted file mode 100644 index 8c147471..00000000 Binary files a/docs/source/maths/images/ellipse.jpg and /dev/null differ diff --git a/docs/source/maths/images/intersection.jpg b/docs/source/maths/images/intersection.jpg deleted file mode 100644 index 9fbfe30e..00000000 Binary files a/docs/source/maths/images/intersection.jpg and /dev/null differ diff --git a/docs/source/maths/images/point_discharge2d_adjoint.jpg b/docs/source/maths/images/point_discharge2d_adjoint.jpg deleted file mode 100644 index 82af386f..00000000 Binary files a/docs/source/maths/images/point_discharge2d_adjoint.jpg and /dev/null differ diff --git a/docs/source/maths/images/point_discharge2d_anisotropic_dwr.jpg b/docs/source/maths/images/point_discharge2d_anisotropic_dwr.jpg deleted file mode 100644 index b97aab2e..00000000 Binary files a/docs/source/maths/images/point_discharge2d_anisotropic_dwr.jpg and /dev/null differ diff --git a/docs/source/maths/images/point_discharge2d_forward.jpg b/docs/source/maths/images/point_discharge2d_forward.jpg deleted file mode 100644 index 5bb60d8d..00000000 Binary files a/docs/source/maths/images/point_discharge2d_forward.jpg and /dev/null differ diff --git a/docs/source/maths/images/point_discharge2d_isotropic_dwr.jpg b/docs/source/maths/images/point_discharge2d_isotropic_dwr.jpg deleted file mode 100644 index f10efcbf..00000000 Binary files a/docs/source/maths/images/point_discharge2d_isotropic_dwr.jpg and /dev/null differ diff --git a/docs/source/maths/images/point_discharge2d_weighted_gradient.jpg b/docs/source/maths/images/point_discharge2d_weighted_gradient.jpg deleted file mode 100644 index e276c210..00000000 Binary files a/docs/source/maths/images/point_discharge2d_weighted_gradient.jpg and /dev/null differ diff --git a/docs/source/maths/images/point_discharge2d_weighted_hessian.jpg b/docs/source/maths/images/point_discharge2d_weighted_hessian.jpg deleted file mode 100644 index 9fe3ebf2..00000000 Binary files a/docs/source/maths/images/point_discharge2d_weighted_hessian.jpg and /dev/null differ diff --git a/docs/source/maths/index.rst b/docs/source/maths/index.rst deleted file mode 100644 index 3465d536..00000000 --- a/docs/source/maths/index.rst +++ /dev/null @@ -1,11 +0,0 @@ -************* -Goalie manual -************* - -.. toctree:: - :numbered: - - 1-motivation - 2-goal-oriented-error-estimation - 3-metric-based - 4-goal-oriented-mesh-adaptation diff --git a/docs/source/references.bib b/docs/source/references.bib deleted file mode 100644 index 2e967480..00000000 --- a/docs/source/references.bib +++ /dev/null @@ -1,61 +0,0 @@ -@article{Cle:75, - title={Approximation by finite element functions using local regularization}, - author={Cl{\'e}ment, Ph}, - journal={Revue fran{\c{c}}aise d'automatique, informatique, recherche op{\'e}rationnelle. Analyse num{\'e}rique}, - volume={9}, - number={R2}, - pages={77--84}, - year={1975}, - publisher={EDP Sciences} -} - -@book{VVP+:92, - title={Numerical recipes: example book C}, - author={Vetterling, William T and Vetterling, William T and Press, William H and Press, William H and Teukolsky, Saul A and Flannery, Brian P and Flannery, Brian P}, - year={1992}, - publisher={Cambridge University Press} -} - -@article{PPP+:06, - title={Adjoint a posteriori error measures for anisotropic mesh optimisation}, - author={Power, PW and Pain, Christopher C and Piggott, MD and Fang, Fangxin and Gorman, Gerard J and Umpleby, AP and Goddard, Anthony JH and Navon, IM}, - journal={Computers \& Mathematics with Applications}, - volume={52}, - number={8-9}, - pages={1213--1242}, - year={2006}, - publisher={Elsevier}, - doi={10.1016/j.camwa.2006.11.003} -} - -@article{LDA:10, - title={Fully anisotropic goal-oriented mesh adaptation for {3D} steady {E}uler equations}, - author={Loseille, Adrien and Dervieux, Alain and Alauzet, Fr{\'e}d{\'e}ric}, - journal={Journal of computational physics}, - volume={229}, - number={8}, - pages={2866--2897}, - year={2010}, - publisher={Elsevier}, - doi={10.1016/j.jcp.2009.12.021} -} - -@article{CPB:13, - title={Anisotropic ``goal-oriented'' mesh adaptivity for elliptic problems}, - author={Carpio, Jaime and Prieto, Juan Luis and Bermejo, Rodolfo}, - journal={SIAM Journal on Scientific Computing}, - volume={35}, - number={2}, - pages={A861--A885}, - year={2013}, - publisher={SIAM}, - doi={10.1137/120874606} -} - -@inproceedings{Barral:2016, - title={Anisotropic mesh adaptation in {F}iredrake -with {PETSc} {DMPlex}}, - author={N. Barral and M. G. Knepley and M. Lange and M. D. Piggott and G. J. Gorman}, - booktitle={25th Intl Meshing Roundtable}, - year={2016} -}