Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update citations for html #132

Merged
merged 2 commits into from
Nov 19, 2024
Merged

update citations for html #132

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e113769
update citations for html
acse-ej321 Nov 18, 2024
6c129f2
consolidate refs in docs repo
acse-ej321 Nov 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion demos/demo_references.bib
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, don't we want to remove this bibtex file and just use the one in the docs repo?

Copy link
Collaborator Author

@acse-ej321 acse-ej321 Nov 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left the demo_references.bib file in each of the ./demos folders and updated the Makefile to copy each into the one in the docs repo which is the collective reference. The logic for including maintaining a demo_references.bib I think would be the convenience of adding any future demos and references to the same repository.
It would simplify the file structure even more to just add them to the one in docs repo - so will do that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, sorry that I didn't suggest this earlier!

Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,8 @@ @Article{McRae:2018
pages={1121--1148},
doi={10.1137/16M1109515}
}
@inproceedings{park2019,

@inproceedings{Park:2019,
title={Verification of unstructured grid adaptation components},
author={Park, Michael A and Balan, Aravind and Anderson, William K and Galbraith, Marshall C and Caplan, Philip and Carson, Hugh A and Michal, Todd R and Krakos, Joshua A and Kamenetskiy, Dmitry S and Loseille, Adrien and others},
booktitle={AIAA Scitech 2019 Forum},
Expand Down
2 changes: 1 addition & 1 deletion demos/lineal_spring.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -230,5 +230,5 @@ def update_boundary_displacement(t):
#
# .. rubric:: References
#
# .. bibliography:: demo_references.bib
# .. bibliography::
# :filter: docname in docnames
2 changes: 1 addition & 1 deletion demos/monge_ampere1.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,5 +195,5 @@ def ring_monitor(mesh):
#
# .. rubric:: References
#
# .. bibliography:: demo_references.bib
# .. bibliography::
# :filter: docname in docnames
4 changes: 2 additions & 2 deletions demos/monge_ampere_3d.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@

# In this demo we demonstrate that the Monge-Ampère mesh movement
# can also be applied to 3D meshes. We employ the `sinatan3` function
# from :cite:`park2019` to introduce an interesting pattern.
# from :cite:`Park:2019` to introduce an interesting pattern.

from firedrake import *

Expand Down Expand Up @@ -98,5 +98,5 @@ def monitor(mesh):
#
# .. rubric:: References
#
# .. bibliography:: demo_references.bib
# .. bibliography::
# :filter: docname in docnames
10 changes: 5 additions & 5 deletions movement/monge_ampere.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ def MongeAmpereMover(mesh, monitor_function, method="relaxation", **kwargs):
:class:`~.MongeAmpereMover_Relaxation`. If the argument is set to `"quasi_newton"`
then it is solved in its elliptic form using a quasi-Newton method in
:class:`~.MongeAmpereMover_QuasiNewton`. Descriptions of both methods may be found in
:cite:`MCB:18`.
:cite:`McRae:2018`.

The physical mesh coordinates :math:`\mathbf{x}` are updated according to

Expand Down Expand Up @@ -109,7 +109,7 @@ class MongeAmpereMover_Base(PrimeMover, metaclass=abc.ABCMeta):

Currently implemented subclasses: :class:`~.MongeAmpereMover_Relaxation` and
:class:`~.MongeAmpereMover_QuasiNewton`. Descriptions of both methods may be found in
:cite:`MCB:18`.
:cite:`McRae:2018`.
"""

def __init__(self, mesh, monitor_function, **kwargs):
Expand Down Expand Up @@ -366,7 +366,7 @@ class MongeAmpereMover_Relaxation(MongeAmpereMover_Base):
= m(\mathbf{x})\det(\mathbf{I} + \mathbf{H}(\phi)) - \theta,

where :math:`\tau` is the pseudo-time variable. Forward Euler is used for the
pseudo-time integration (see :cite:`MCB:18` for details).
pseudo-time integration (see :cite:`McRae:2018` for details).

This approach typically takes tens or hundreds of iterations to converge, but each
iteration is relatively cheap.
Expand Down Expand Up @@ -424,7 +424,7 @@ def pseudotimestepper(self):
"""
Setup the pseudo-timestepper for the relaxation method.

Forward Euler is used for the pseudo-time integration (see :cite:`MCB:18` for
Forward Euler is used for the pseudo-time integration (see :cite:`McRae:2018` for
details). The pseudo-timestep may be set through the `pseudo_timestep` keyword
argument to the constructor.

Expand Down Expand Up @@ -555,7 +555,7 @@ class MongeAmpereMover_QuasiNewton(MongeAmpereMover_Base):
:math:`\phi` with respect to :math:`\boldsymbol{\xi}`.

In this mesh mover, the elliptic Monge-Ampère equation is solved using a quasi-Newton
method (see :cite:`MCB:18` for details).
method (see :cite:`McRae:2018` for details).

This approach typically takes fewer than ten iterations to converge, but each
iteration is relatively expensive.
Expand Down
6 changes: 3 additions & 3 deletions movement/spring.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ def SpringMover(*args, method="lineal", **kwargs):
"""
Movement of a ``mesh`` is determined by reinterpreting it as a structure of stiff
beams and solving an associated discrete linear elasticity problem. (See
:cite:`FDK+:98` for details.)
:cite:`Farhat:1998` for details.)

:arg mesh: the physical mesh to be moved
:type mesh: :class:`firedrake.mesh.MeshGeometry`
Expand Down Expand Up @@ -237,7 +237,7 @@ class SpringMover_Lineal(SpringMover_Base):
Movement of a ``mesh`` is determined by reinterpreting it as a structure of stiff
beams and solving an associated discrete linear elasticity problem.

We consider the 'lineal' case, as described in :cite:`FDK+:98`.
We consider the 'lineal' case, as described in :cite:`Farhat:1998`.
"""

@PETSc.Log.EventDecorator()
Expand Down Expand Up @@ -285,7 +285,7 @@ class SpringMover_Torsional(SpringMover_Lineal):
Movement of a ``mesh`` is determined by reinterpreting it as a structure of stiff
beams and solving an associated discrete linear elasticity problem.

We consider the 'torsional' case, as described in :cite:`FDK+:98`.
We consider the 'torsional' case, as described in :cite:`Farhat:1998`.
"""

def __init__(self, *args, **kwargs):
Expand Down
Loading