Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Sign in
Toggle navigation
Open sidebar
pyMOR
pymor
Commits
23188e84
Unverified
Commit
23188e84
authored
Sep 10, 2020
by
Stephan Rave
Committed by
GitHub
Sep 10, 2020
Browse files
Apply suggestions from code review
Co-authored-by:
Petar Mlinarić
<
mlinaric@mpi-magdeburg.mpg.de
>
parent
cc8d5633
Pipeline
#64834
failed with stages
in 31 seconds
Changes
1
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
6 additions
and
6 deletions
+6
-6
docs/source/tutorial_projection.rst
docs/source/tutorial_projection.rst
+6
-6
No files found.
docs/source/tutorial_projection.rst
View file @
23188e84
...
...
@@ -29,7 +29,7 @@ by an external PDE solver (see :doc:`tutorial_external_solver`).
Since this tutorial is also supposed to give you a better overview of pyMOR's
architecture, we will not import everything from the :mod:`pymor.basic` convenience
module but directly import all classes and methods from ther
e
original locations in
module but directly import all classes and methods from the
i
r original locations in
pyMOR's subpackages.
Let's build a 2-by-2 thermal block |Model| as our FOM:
...
...
@@ -75,7 +75,7 @@ The singular value decay looks promising:
Solving the Model
-----------------
Now that we have our FOM and a reduce space :math:`V_N` spanned by `basis`, we can project
Now that we have our FOM and a reduce
d
space :math:`V_N` spanned by `basis`, we can project
the |Model|. However, before doing so, we need to understand how actually
solving the FOM works. Let's take a look at what
:meth:`~pymor.models.interface.Model.solve` actually does:
...
...
@@ -130,7 +130,7 @@ an |Operator|:
fom.rhs
This is due to the fact
,
that |VectorArrays| in pyMOR cannot be parametric. So to allow
This is due to the fact that |VectorArrays| in pyMOR cannot be parametric. So to allow
for parametric right-hand sides, this right-hand side is encoded by a linear |Operator|
that maps numbers to scalar multiples of the right-hand side vector. Indeed, we see that
...
...
@@ -212,7 +212,7 @@ the defect by which :math:`u_N` fails to satisfy the equations:
.. math::
u_N(\mu) := \operatorname{argmin}_{u \in \mathbb{R}^N} \|F(\mu) - L(\mathbb{V}_N \cdot u)\|.
u_N(\mu) := \operatorname{arg
\,
min}_{u \in \mathbb{R}^N} \|F(\mu) - L(\mathbb{V}_N \cdot u
; \mu
)\|.
While this is a feasible (and sometimes necessary) approach that can be realized with
pyMOR as well, we choose here an even simpler method by requiring that the residual is
...
...
@@ -220,7 +220,7 @@ orthogonal to our reduced space, i.e.
.. math::
(\mathbb{V}_{N,i},\, F(\mu) - L(\mathbb{V}_N \cdot u_N)) = 0 \qquad i=1,
...
,N,
(\mathbb{V}_{N,i},\, F(\mu) - L(\mathbb{V}_N \cdot u_N
; \mu
)) = 0 \qquad i=1,
\ldots
,N,
where the :math:`\mathbb{V}_{N,i}` denote the columns of :math:`\mathbb{V}_N`
and :math:`(\cdot, \cdot)` denotes some inner product on our
...
...
@@ -388,7 +388,7 @@ system matrix and right-hand side. However, if we compare the timings,
print(f'ROM assemble: {tac-toc:.5f} (s)')
print(f'ROM solve: {tuc-tac:.5f} (s)')
we see that we lo
o
se a lot of our speedup when we assemble the ROM
we see that we lose a lot of our speedup when we assemble the ROM
(which involves a lot of full-order dimensional operations).
To solve this issue we need to find a way to pre-compute everything we need
...
...
René Fritze
@r_milk01
mentioned in commit
cd738009
·
Sep 10, 2020
mentioned in commit
cd738009
mentioned in commit cd738009f5b40f3e8bbc368d55ab662da17e2140
Toggle commit list
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment