From rene.gassmoeller at mailbox.org Mon Apr 3 13:31:41 2017
From: rene.gassmoeller at mailbox.org (Rene Gassmoeller)
Date: Mon, 3 Apr 2017 14:31:41 -0600
Subject: [aspect-devel] Development update: ASPECT-GUI, Docker container,
Solver defaults
In-Reply-To:
References:
Message-ID: <87870c02-d232-7f19-36c6-bc5ec626a957@mailbox.org>
Hi all,
this is an additional development update, somewhat out of the line of
the usual newsletters. In the last weeks there have been some
potentially useful, important additions and changes to ASPECT that in my
opinion justify this additional notice. Lets look at them one at a time:
1. ASPECT-GUI: Because ASPECT is growing at a steady pace the number of
input parameter file options today is probably larger than any single
person, including the maintainers, can remember. Looking up parameters
in the manual or in output files is the current solution, but that
requires a lot of searching through walls of text. Luckily since several
years there is a little program for deal.II called 'parameter_gui'
(https://github.com/dealii/parameter_gui) that can visualize the
structure of parameter files in a tree-like structure and allows to
change and save these parameters. Thanks to a concerted effort of the
maintainers we improved this program, and now provide a script inside
ASPECT that allows to browse all ASPECT input parameters (including
their type, documentation, and default value) in a graphical way, change
values, and write a parameter file that can afterwards be used to start
a regular ASPECT model. Installation and usage of this script is
described in a new section in the manual, and we want to encourage you
to try this new feature. We have found it can make creating new models
or modifying existing models much more intuitive, and have discovered
some options we had forgotten about! Of course, since the GUI only
produces a parameter file that is then started the traditional way there
is nothing wrong with writing your parameter files by hand, and we will
continue to support this way of starting models.
Discussions during the development of this feature can be found here:
https://github.com/geodynamics/aspect/pull/1419
https://github.com/geodynamics/aspect/pull/1414
https://github.com/dealii/parameter_gui/pulls?q=is%3Apr+is%3Aclosed
2. ASPECT docker container: Due to its list of dependencies the
installation of ASPECT was always somewhat tedious and prone to
problems. Following a discussion on the mailing list a few weeks back,
and with the growing use of container-based distribution systems we now
provide an ASPECT Docker image that allows to install ASPECT with a
single shell command if you have a Docker engine running on your machine
(try 'docker pull gassmoeller/aspect'). This is likely not the solution
for massively parallel computations, but it allows you to run smaller
models or tests on your local machine. Again more detailed information
is available in the current manual
(http://www.math.clemson.edu/~heister/manual.pdf). As a side note: This
allows the use of ASPECT on Microsoft Windows in a nearly native look
and feel.
Discussions about the development of this feature can be found here:
https://github.com/geodynamics/aspect/pull/1402
3. Stokes solver defaults: As you know ASPECT is used to model a vast
variety of different geodynamic scenarios. In particular the performance
of the Stokes solver can depend crucially on some input parameters and
the type of problem that is modelled. This makes choosing sensible
default values very hard. In general, ASPECT uses a two-stage Stokes
solver that first tries to solve the system using a less accurate, but
very cheap preconditioner. Upon a failure to reach a specified residual
tolerance after a specified number of iterations it switches to a much
more expensive but also much more accurate preconditioner. Parameters
that can be tuned in this process are in particular: 1. The tolerance up
to which the full Stokes system is solved. 2. The number of cheap solver
iterations, before the expensive preconditioner is used. 3. The accuracy
of the expensive preconditioner (it is itself the solution of a linear
system).
In the last week we have re-examined our default choice for the number
of cheap solver iterations. The old ASPECT default values were chosen
and tuned to allow simple models (e.g. with constant viscosity) to
converge within the cheap solver iterations, while the expensive
preconditioner was the default method for most other models. However our
tests with more realistic models have shown that nearly all models even
with realistic viscosity contrasts (>= 4 orders of magnitude, including
plasticity) benefit from more cheap solver iterations. While the number
of iterations usually increases significantly (up to a factor of 5) the
cheaper preconditioner offsets this easily (each iteration is around 40
times faster). The amount of achieved Stokes solver speedup depends on
the model, but can reach anything from 10% to a factor of 40. There are
a few consequences of these results:
- We think the new default for the number of cheap Stokes solver
iterations (200 instead of 30) benefits most models, while we can not
guarantee it helps all models.
- You can optimize individual models further. Playing with the above
mentioned parameters can significantly speed up model runtimes, in
particular if your model is limited by the time spend in the Stokes
solver. You can use the 'Stokes residual' postprocessor to investigate
convergence behavior of your particular model.
- Our old suggestion that setting the Number of cheap Stokes solver
iterations to 0 is helpful for plasticity models, does not seem to hold
any more in our tests.
Discussions during the development of this feature and results of our
convergence tests can be found here:
https://github.com/geodynamics/aspect/pull/1421
Since all of the above changes are recent, they might contain bugs, or
unknown side effects we have not discovered yet. Let us know about them
via the mailing list, open a Github issue, or (ideally :-)) go ahead and
submit a fix in form of a pull request on Github.
Thanks for reading,
Rene, on behalf of the ASPECT maintainers
--
Rene Gassmoeller
http://www.math.colostate.edu/~gassmoel/
From rene.gassmoeller at mailbox.org Tue Apr 11 11:00:25 2017
From: rene.gassmoeller at mailbox.org (Rene Gassmoeller)
Date: Tue, 11 Apr 2017 18:00:25 -0000
Subject: [aspect-devel] ASPECT Newsletter #27
Message-ID: <20170411175829.C4672AC2457@geodynamics.org>
Hello everyone!
This is ASPECT newsletter #27.
It automatically reports recently merged features and discussions about the ASPECT mantle convection code.
## Below you find a list of recently proposed or merged features:
#1432: Add legacy includes to make compile with deal.II 9.0.pre (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1432
#1431: Fix King benchmark parameter file (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1431
#1430: fix a bug in the latent heat material & add min and max viscosity (proposed by jdannberg; merged) https://github.com/geodynamics/aspect/pull/1430
#1429: Fix statistics output for nonlinear iterations (proposed by jdannberg) https://github.com/geodynamics/aspect/pull/1429
#1428: Update king benchmark (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1428
#1427: fix bib entry for the manual (proposed by tjhei; merged) https://github.com/geodynamics/aspect/pull/1427
#1426: Aspect maintenance (proposed by tjhei; merged) https://github.com/geodynamics/aspect/pull/1426
#1425: Update the grant numbers that supported ASPECT. (proposed by bangerth; merged) https://github.com/geodynamics/aspect/pull/1425
#1424: Update the current release in the manual. (proposed by bangerth; merged) https://github.com/geodynamics/aspect/pull/1424
#1423: Fix A+S iteration output (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1423
#1422: WIP: Add get manifold function (proposed by MFraters) https://github.com/geodynamics/aspect/pull/1422
#1421: Increase cheap solver step defaults to make Stokes solve faster (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1421
#1419: Add GUI documentation (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1419
#1418: Modify strain weakening feature of visco_plastic material model and add a related benchmark and particle property (proposed by naliboff) https://github.com/geodynamics/aspect/pull/1418
#1413: Implement make_pressure_rhs_compatible for compressible computations (proposed by tjhei; merged) https://github.com/geodynamics/aspect/pull/1413
#1402: Provide a Docker image (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1402
## And this is a list of recently opened or closed discussions:
#1420: compute code coverage (opened) https://github.com/geodynamics/aspect/issues/1420
A list of all major changes since the last release can be found at https://aspect.dealii.org/doc/doxygen/changes_current.html.
Thanks for being part of the community!
Let us know about questions, problems, bugs or just share your experience by writing to aspect-devel at geodynamics.org, or by opening issues or pull requests at https://www.github.com/geodynamics/aspect.
Additional information can be found at https://aspect.dealii.org/, and https://geodynamics.org/cig/software/aspect/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From heister at clemson.edu Wed Apr 12 06:46:59 2017
From: heister at clemson.edu (Timo Heister)
Date: Wed, 12 Apr 2017 09:46:59 -0400
Subject: [aspect-devel] Fwd: deal.II Version 8.5.0 released
In-Reply-To:
References:
Message-ID:
Hey all,
this is probably also of interest for the ASPECT community. The
release 1.5.0 and the current development version of ASPECT still work
with 8.4 of course.
---------- Forwarded message ----------
From: Timo Heister
Date: Wed, Apr 12, 2017 at 9:45 AM
Subject: deal.II Version 8.5.0 released
To: "dealii at googlegroups.com"
Version 8.5.0 of deal.II, the object-oriented finite element library awarded the
J. H. Wilkinson Prize for Numerical Software, has been released. It is
available for free under an Open Source license from the deal.II homepage at
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dealii.org_&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=c08Btfq4m9QEScXN3ZQwLZzzWQE7S8CYq1IYuzKV_Zk&m=u8TLeveT0HAvNrN0swagDJd9p3WXGdo_HzjUY0ME4dY&s=bdXAul5Ug7hWSVvO_7zbogZQTLct_vwHCXUF-yGaBwo&e=
The major changes of this release are:
- The CellDataStorage class provides a mechanism to store and communicate
user-defined data on each cell.
- The MappingManifold class provides mappings between the reference cell and a
mesh cell that is exact, rather than the usual polynomial approximations of
a manifold.
- Various improvements for high-order elements, including a switch of support
points in FE_Q and FE_DGQ to Gauss-Lobatto support points, stable
evaluation of high-order Legendre polynomials, and several bugfixes for
high-order polynomial mappings defined through the MappingQ class.
- The LinearOperator class has been extended by a generic ``payload''
mechanism that allows the attachment of arbitrary additional information to
a LinearOperator.
- A dedicated physics module to provide definitions and operations
used in continuum mechanics.
- The FE_Enriched class implements the operation of enriching the finite
element space of an underlying element.
- The FESeries namespace provides expansions of a finite element solution in
terms of different, hierarchical bases.
- New tutorial programs step-55, step-56, and step-57; as well as updates to
step-27, step-37, and step-44. In addition, the separate code gallery of
deal.II has gained a number of new entries.
- Static code analyzers are valuable tools to improve and maintain the quality
of the code in our library in addition to build and regression tests for a
variety of setups. This release was tested with Cppcheck, PVS-Studio, and
Coverity-Scan.
- More than 240 other features and bugfixes.
For more information see
- the preprint at https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dealii.org_deal85-2Dpreprint.pdf&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=c08Btfq4m9QEScXN3ZQwLZzzWQE7S8CYq1IYuzKV_Zk&m=u8TLeveT0HAvNrN0swagDJd9p3WXGdo_HzjUY0ME4dY&s=ZdH7tJBy-mYAiievI7_PY_pl5S1lbpfFXn1W3PDeziQ&e=
- the list of changes at
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dealii.org_developer_doxygen_deal.II_changes-5Fbetween-5F8-5F4-5F2-5Fand-5F8-5F5-5F0.html&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=c08Btfq4m9QEScXN3ZQwLZzzWQE7S8CYq1IYuzKV_Zk&m=u8TLeveT0HAvNrN0swagDJd9p3WXGdo_HzjUY0ME4dY&s=F9_EtRSpMaA2H-cgq2fmt7L3MiT-WiHi2M3sUOpkSOM&e=
The main features of deal.II are:
- Extensive documentation and 55 working example programs
- Support for dimension-independent programming
- Locally refined adaptive meshes
- Multigrid support
- A zoo of different finite elements
- Fast linear algebra
- Built-in support for shared memory and distributed parallel computing,
scaling from laptops to clusters with 100,000+ processor cores
- Interfaces to Trilinos, PETSc, METIS, UMFPACK and other external software
- Output for a wide variety of visualization platforms.
D. Arndt, W. Bangerth, D. Davydov, T. Heister, L. Heltai, M. Kronbichler,
M. Maier, J.-P. Pelteret, B. Turcksin, D. Wells, and many other contributors.
--
Timo Heister
http://www.math.clemson.edu/~heister/
--
Timo Heister
http://www.math.clemson.edu/~heister/
From bangerth at tamu.edu Wed Apr 12 08:09:42 2017
From: bangerth at tamu.edu (Wolfgang Bangerth)
Date: Wed, 12 Apr 2017 09:09:42 -0600
Subject: [aspect-devel] Fwd: deal.II Version 8.5.0 released
In-Reply-To:
References:
Message-ID: <76198558-5491-f2cb-8c45-2baa24bf09f0@tamu.edu>
On 04/12/2017 07:46 AM, Timo Heister wrote:
>
> this is probably also of interest for the ASPECT community. The
> release 1.5.0 and the current development version of ASPECT still work
> with 8.4 of course.
But we may switch to require deal.II 8.5 for the ASPECT dev version (and
consequently the next release) sometime soon.
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth at colostate.edu
www: http://www.math.colostate.edu/~bangerth/
From rene.gassmoeller at mailbox.org Tue Apr 18 17:04:34 2017
From: rene.gassmoeller at mailbox.org (Rene Gassmoeller)
Date: Tue, 18 Apr 2017 18:04:34 -0600
Subject: [aspect-devel] Updates relevant to contributors
Message-ID:
Hi all,
this is a development update that is mostly of concern to people
actively extending ASPECT and creating pull requests on Github.
As you know we collect all significant contributions to ASPECT within a
release cycle in a file called doc/modules/changes.h, in order to be
able to give proper credit to the authors of the extensions in the
release announcements and on the ASPECT website. These files are
archived for all releases within the project. Unfortunately, the
structure of the file often leads to conflicts when merging several
parallel development branches that all contained relevant additions.
We are happy to announce that this system was replaced by a more
scalable and (hopefully) simpler to use approach that should save all
developers some time. The new procedure is described in detail in the
file doc/modules/README.md. To summarize: Whenever you prepare a pull
request of significance, you should now create a new text file in the
folder doc/modules/changes/ with a filename that follows the structure
YYYYMMDD_your_name, which contains an entry similar to the entries in
our previous changes.h file. You can take a look in the folder for
examples. The full file changes.h is now only generated whenever
necessary (e.g. for a release) by a script that resides in doc/modules/.
This way parallel developments no longer modify the same file, and many
conflicts will be avoided.
While this change will require all existing pull requests to be rebased
and modified one (last) time, we think that this change will be
particularly handy during the upcoming hackathon, when we will have ~20
people working on projects in parallel.
Let us know if something about this approach does not work for you!
Best regards,
Rene
--
Rene Gassmoeller
http://www.math.colostate.edu/~gassmoel/
From sxliu at vt.edu Wed Apr 19 19:17:08 2017
From: sxliu at vt.edu (Shangxin Liu)
Date: Wed, 19 Apr 2017 22:17:08 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep sizes
of the same Ra
Message-ID:
Hi;
Recently I'm trying the new Boussinesq approximation formulation of ASPECT
to test the 3D spherical shell time-dependent convection. I tried running
the non-dimensional cases and set the start time to 0 and end time to
1. Through a series of tests, I found that the same Ra but different
gravity and alpha have far different results of velocity magnitude and the
tilmestep size. For example, I fixed the Ra to 7000 and run three cases:
Case1: gravity 7000, alpha 1
Case2: gravity 70000, alpha 0.1
Case3: gravity 700000, alpha 0.01
(All other parameters of these three cases in prm file are the same:
constant viscosity, CFL number=1, same solver tolerance, same spherical
shell geometry,etc..)
Case1 takes only 13 timesteps to reach the end time and the end RMS/Max
velocity is 0.00182/0.0055;
Case2 takes 20 timesteps to reach the end time and the end RMS/Max velocity
is 0.00558/0.0352;
Case3 takes 141 timesteps to reach the end time and the end RMS/Max
velocity is 0.0479/0.305.
They all ran on one node of our cluster but the running time is also
different:
case1: 999s
case2: 1.48e03 s
case3: 3.86e03 s
The end min/avg/max temperature and heat flux of upper/lower boundary of
the three cases are all the same.
>From ASPECT manual, I noticed that the time step size is inversely
proportional to the max velocity of the cell so such a huge difference of
tilmestep size must be caused by the difference of the velocity magnitude.
But in the non-dimemsioanl problem, the same Ra should have the same
magnitude of velocity. Why in ASPECT, the same Ra can have such different
velocity magnitude? I've realized that ASPECT uses the total pressure and
total density in its momentum equation, so larger value of gravity can
introduce a larger rho_0*g_0 term in the momentum equation. I'm not sure
whether this will cause the solver matrix of momentum equation going crazy.
Did anyone else run into this similar confusion? Wolfgang, Timo, Rene,
Juliane, any insight on this?
Best,
Shangxin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From timo.heister at gmail.com Thu Apr 20 10:09:43 2017
From: timo.heister at gmail.com (Timo Heister)
Date: Thu, 20 Apr 2017 13:09:43 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID:
Shangxin,
can you post your .prm? Are you using free slip boundary conditions
for the velocity?
On Wed, Apr 19, 2017 at 10:17 PM, Shangxin Liu wrote:
> Hi;
>
> Recently I'm trying the new Boussinesq approximation formulation of ASPECT
> to test the 3D spherical shell time-dependent convection. I tried running
> the non-dimensional cases and set the start time to 0 and end time to 1.
> Through a series of tests, I found that the same Ra but different gravity
> and alpha have far different results of velocity magnitude and the tilmestep
> size. For example, I fixed the Ra to 7000 and run three cases:
>
> Case1: gravity 7000, alpha 1
> Case2: gravity 70000, alpha 0.1
> Case3: gravity 700000, alpha 0.01
> (All other parameters of these three cases in prm file are the same:
> constant viscosity, CFL number=1, same solver tolerance, same spherical
> shell geometry,etc..)
>
> Case1 takes only 13 timesteps to reach the end time and the end RMS/Max
> velocity is 0.00182/0.0055;
> Case2 takes 20 timesteps to reach the end time and the end RMS/Max velocity
> is 0.00558/0.0352;
> Case3 takes 141 timesteps to reach the end time and the end RMS/Max velocity
> is 0.0479/0.305.
>
> They all ran on one node of our cluster but the running time is also
> different:
> case1: 999s
> case2: 1.48e03 s
> case3: 3.86e03 s
>
> The end min/avg/max temperature and heat flux of upper/lower boundary of the
> three cases are all the same.
>
> From ASPECT manual, I noticed that the time step size is inversely
> proportional to the max velocity of the cell so such a huge difference of
> tilmestep size must be caused by the difference of the velocity magnitude.
> But in the non-dimemsioanl problem, the same Ra should have the same
> magnitude of velocity. Why in ASPECT, the same Ra can have such different
> velocity magnitude? I've realized that ASPECT uses the total pressure and
> total density in its momentum equation, so larger value of gravity can
> introduce a larger rho_0*g_0 term in the momentum equation. I'm not sure
> whether this will cause the solver matrix of momentum equation going crazy.
> Did anyone else run into this similar confusion? Wolfgang, Timo, Rene,
> Juliane, any insight on this?
>
> Best,
> Shangxin
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw&m=UlGvhK8rWt4pq8DXeR9K1ZYfwj0hBZtV9zNTnj1zJS0&s=uxCinag781DkUL2eMpjkgQodtU35tW1_1Aww6Ngcpww&e=
From sxliu at vt.edu Thu Apr 20 12:01:10 2017
From: sxliu at vt.edu (Shangxin Liu)
Date: Thu, 20 Apr 2017 15:01:10 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID:
Hi Timo and John,
Before making further comments, there is a typo in my first email. I just
checked my prm files for these three cases. The CFL number of them is all
0.5 instead of 1. And I use 3 global refinement, 0 adaptive refinement,
with fixed mesh.
Yes. I can further try decreasing CFL number or increasing the grid
resolution. But the reason why we use 3 global refinement, i.e., 49152
cells globally is that Zhong et al., 2008 paper uses 12*32^3 (393216) cells
globally, which is equivalent to global refinement 4 in ASPECT. However,
since ASPECT uses quadratic element while CitcomS uses linear element, we
suppose the lower global refinement 3 of ASPECT is equivalent to higher
global refinement 4 in CitcomS.
John, the reason why we modify alpha and gravity to fix Ra is that
previously before the true Boussinesq approximation was merged into ASPECT,
we use a very small alpha to mimic constant reference density in energy
equation. Now we further try these series with the new ASPECT with Boussinesq
approximation formulation and found this confused issue.
Timo, I'm using free slip boundary condition for velocity on both top and
bottom boundary.
The attachment is the prm file for my first case that uses 7000 gravity and
1.0 alpha. You can simply change gravity to 70000/700000 and alpha to
0.1/0.01 to get case2/case3. Let's see whether we can get the
same tilmestep size and velocity magnitudes of the three cases.
Best,
Shangxin
On Thu, Apr 20, 2017 at 1:09 PM, Timo Heister
wrote:
> Shangxin,
>
> can you post your .prm? Are you using free slip boundary conditions
> for the velocity?
>
> On Wed, Apr 19, 2017 at 10:17 PM, Shangxin Liu wrote:
> > Hi;
> >
> > Recently I'm trying the new Boussinesq approximation formulation of
> ASPECT
> > to test the 3D spherical shell time-dependent convection. I tried running
> > the non-dimensional cases and set the start time to 0 and end time to 1.
> > Through a series of tests, I found that the same Ra but different gravity
> > and alpha have far different results of velocity magnitude and the
> tilmestep
> > size. For example, I fixed the Ra to 7000 and run three cases:
> >
> > Case1: gravity 7000, alpha 1
> > Case2: gravity 70000, alpha 0.1
> > Case3: gravity 700000, alpha 0.01
> > (All other parameters of these three cases in prm file are the same:
> > constant viscosity, CFL number=1, same solver tolerance, same spherical
> > shell geometry,etc..)
> >
> > Case1 takes only 13 timesteps to reach the end time and the end RMS/Max
> > velocity is 0.00182/0.0055;
> > Case2 takes 20 timesteps to reach the end time and the end RMS/Max
> velocity
> > is 0.00558/0.0352;
> > Case3 takes 141 timesteps to reach the end time and the end RMS/Max
> velocity
> > is 0.0479/0.305.
> >
> > They all ran on one node of our cluster but the running time is also
> > different:
> > case1: 999s
> > case2: 1.48e03 s
> > case3: 3.86e03 s
> >
> > The end min/avg/max temperature and heat flux of upper/lower boundary of
> the
> > three cases are all the same.
> >
> > From ASPECT manual, I noticed that the time step size is inversely
> > proportional to the max velocity of the cell so such a huge difference of
> > tilmestep size must be caused by the difference of the velocity
> magnitude.
> > But in the non-dimemsioanl problem, the same Ra should have the same
> > magnitude of velocity. Why in ASPECT, the same Ra can have such different
> > velocity magnitude? I've realized that ASPECT uses the total pressure and
> > total density in its momentum equation, so larger value of gravity can
> > introduce a larger rho_0*g_0 term in the momentum equation. I'm not sure
> > whether this will cause the solver matrix of momentum equation going
> crazy.
> > Did anyone else run into this similar confusion? Wolfgang, Timo, Rene,
> > Juliane, any insight on this?
> >
> > Best,
> > Shangxin
> >
> > _______________________________________________
> > Aspect-devel mailing list
> > Aspect-devel at geodynamics.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.
> geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-
> ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_
> QFS80R7PEA2q0EPwDy7VQw&m=UlGvhK8rWt4pq8DXeR9K1ZYfwj0hBZtV9zNTnj1zJS0&s=
> uxCinag781DkUL2eMpjkgQodtU35tW1_1Aww6Ngcpww&e=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a1_ref3.prm
Type: application/octet-stream
Size: 3442 bytes
Desc: not available
URL:
From heister at clemson.edu Thu Apr 20 13:47:29 2017
From: heister at clemson.edu (Timo Heister)
Date: Thu, 20 Apr 2017 16:47:29 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID:
Shangxin,
> set Linear solver tolerance = 1e-3
Is there a reason for choosing such a tolerance? I would have no
confidence that the solution is accurate. Can you re-run with
something like 1e-8.
That said, I think we likely still have a problem with equation
scaling if the gravity is not the same order of magnitude as the
velocity.
On Thu, Apr 20, 2017 at 3:01 PM, Shangxin Liu wrote:
> Hi Timo and John,
>
> Before making further comments, there is a typo in my first email. I just
> checked my prm files for these three cases. The CFL number of them is all
> 0.5 instead of 1. And I use 3 global refinement, 0 adaptive refinement, with
> fixed mesh.
>
> Yes. I can further try decreasing CFL number or increasing the grid
> resolution. But the reason why we use 3 global refinement, i.e., 49152 cells
> globally is that Zhong et al., 2008 paper uses 12*32^3 (393216) cells
> globally, which is equivalent to global refinement 4 in ASPECT. However,
> since ASPECT uses quadratic element while CitcomS uses linear element, we
> suppose the lower global refinement 3 of ASPECT is equivalent to higher
> global refinement 4 in CitcomS.
>
> John, the reason why we modify alpha and gravity to fix Ra is that
> previously before the true Boussinesq approximation was merged into ASPECT,
> we use a very small alpha to mimic constant reference density in energy
> equation. Now we further try these series with the new ASPECT with
> Boussinesq approximation formulation and found this confused issue.
>
> Timo, I'm using free slip boundary condition for velocity on both top and
> bottom boundary.
>
> The attachment is the prm file for my first case that uses 7000 gravity and
> 1.0 alpha. You can simply change gravity to 70000/700000 and alpha to
> 0.1/0.01 to get case2/case3. Let's see whether we can get the same tilmestep
> size and velocity magnitudes of the three cases.
>
> Best,
> Shangxin
>
>
>
> On Thu, Apr 20, 2017 at 1:09 PM, Timo Heister
> wrote:
>>
>> Shangxin,
>>
>> can you post your .prm? Are you using free slip boundary conditions
>> for the velocity?
>>
>> On Wed, Apr 19, 2017 at 10:17 PM, Shangxin Liu wrote:
>> > Hi;
>> >
>> > Recently I'm trying the new Boussinesq approximation formulation of
>> > ASPECT
>> > to test the 3D spherical shell time-dependent convection. I tried
>> > running
>> > the non-dimensional cases and set the start time to 0 and end time to 1.
>> > Through a series of tests, I found that the same Ra but different
>> > gravity
>> > and alpha have far different results of velocity magnitude and the
>> > tilmestep
>> > size. For example, I fixed the Ra to 7000 and run three cases:
>> >
>> > Case1: gravity 7000, alpha 1
>> > Case2: gravity 70000, alpha 0.1
>> > Case3: gravity 700000, alpha 0.01
>> > (All other parameters of these three cases in prm file are the same:
>> > constant viscosity, CFL number=1, same solver tolerance, same spherical
>> > shell geometry,etc..)
>> >
>> > Case1 takes only 13 timesteps to reach the end time and the end RMS/Max
>> > velocity is 0.00182/0.0055;
>> > Case2 takes 20 timesteps to reach the end time and the end RMS/Max
>> > velocity
>> > is 0.00558/0.0352;
>> > Case3 takes 141 timesteps to reach the end time and the end RMS/Max
>> > velocity
>> > is 0.0479/0.305.
>> >
>> > They all ran on one node of our cluster but the running time is also
>> > different:
>> > case1: 999s
>> > case2: 1.48e03 s
>> > case3: 3.86e03 s
>> >
>> > The end min/avg/max temperature and heat flux of upper/lower boundary of
>> > the
>> > three cases are all the same.
>> >
>> > From ASPECT manual, I noticed that the time step size is inversely
>> > proportional to the max velocity of the cell so such a huge difference
>> > of
>> > tilmestep size must be caused by the difference of the velocity
>> > magnitude.
>> > But in the non-dimemsioanl problem, the same Ra should have the same
>> > magnitude of velocity. Why in ASPECT, the same Ra can have such
>> > different
>> > velocity magnitude? I've realized that ASPECT uses the total pressure
>> > and
>> > total density in its momentum equation, so larger value of gravity can
>> > introduce a larger rho_0*g_0 term in the momentum equation. I'm not sure
>> > whether this will cause the solver matrix of momentum equation going
>> > crazy.
>> > Did anyone else run into this similar confusion? Wolfgang, Timo, Rene,
>> > Juliane, any insight on this?
>> >
>> > Best,
>> > Shangxin
>> >
>> > _______________________________________________
>> > Aspect-devel mailing list
>> > Aspect-devel at geodynamics.org
>> >
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw&m=UlGvhK8rWt4pq8DXeR9K1ZYfwj0hBZtV9zNTnj1zJS0&s=uxCinag781DkUL2eMpjkgQodtU35tW1_1Aww6Ngcpww&e=
>
>
--
Timo Heister
http://www.math.clemson.edu/~heister/
From maxwellr at gmail.com Thu Apr 20 13:51:04 2017
From: maxwellr at gmail.com (Max Rudolph)
Date: Thu, 20 Apr 2017 13:51:04 -0700
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID:
>
> That said, I think we likely still have a problem with equation
> scaling if the gravity is not the same order of magnitude as the
> velocity.
>
measured in what units?
i.e. does gravity in m/s/s have to be of the same order of magnitude as a
plate velocity in cm/year?
>
> On Thu, Apr 20, 2017 at 3:01 PM, Shangxin Liu wrote:
> > Hi Timo and John,
> >
> > Before making further comments, there is a typo in my first email. I just
> > checked my prm files for these three cases. The CFL number of them is all
> > 0.5 instead of 1. And I use 3 global refinement, 0 adaptive refinement,
> with
> > fixed mesh.
> >
> > Yes. I can further try decreasing CFL number or increasing the grid
> > resolution. But the reason why we use 3 global refinement, i.e., 49152
> cells
> > globally is that Zhong et al., 2008 paper uses 12*32^3 (393216) cells
> > globally, which is equivalent to global refinement 4 in ASPECT. However,
> > since ASPECT uses quadratic element while CitcomS uses linear element, we
> > suppose the lower global refinement 3 of ASPECT is equivalent to higher
> > global refinement 4 in CitcomS.
> >
> > John, the reason why we modify alpha and gravity to fix Ra is that
> > previously before the true Boussinesq approximation was merged into
> ASPECT,
> > we use a very small alpha to mimic constant reference density in energy
> > equation. Now we further try these series with the new ASPECT with
> > Boussinesq approximation formulation and found this confused issue.
> >
> > Timo, I'm using free slip boundary condition for velocity on both top and
> > bottom boundary.
> >
> > The attachment is the prm file for my first case that uses 7000 gravity
> and
> > 1.0 alpha. You can simply change gravity to 70000/700000 and alpha to
> > 0.1/0.01 to get case2/case3. Let's see whether we can get the same
> tilmestep
> > size and velocity magnitudes of the three cases.
> >
> > Best,
> > Shangxin
> >
> >
> >
> > On Thu, Apr 20, 2017 at 1:09 PM, Timo Heister
> > wrote:
> >>
> >> Shangxin,
> >>
> >> can you post your .prm? Are you using free slip boundary conditions
> >> for the velocity?
> >>
> >> On Wed, Apr 19, 2017 at 10:17 PM, Shangxin Liu wrote:
> >> > Hi;
> >> >
> >> > Recently I'm trying the new Boussinesq approximation formulation of
> >> > ASPECT
> >> > to test the 3D spherical shell time-dependent convection. I tried
> >> > running
> >> > the non-dimensional cases and set the start time to 0 and end time to
> 1.
> >> > Through a series of tests, I found that the same Ra but different
> >> > gravity
> >> > and alpha have far different results of velocity magnitude and the
> >> > tilmestep
> >> > size. For example, I fixed the Ra to 7000 and run three cases:
> >> >
> >> > Case1: gravity 7000, alpha 1
> >> > Case2: gravity 70000, alpha 0.1
> >> > Case3: gravity 700000, alpha 0.01
> >> > (All other parameters of these three cases in prm file are the same:
> >> > constant viscosity, CFL number=1, same solver tolerance, same
> spherical
> >> > shell geometry,etc..)
> >> >
> >> > Case1 takes only 13 timesteps to reach the end time and the end
> RMS/Max
> >> > velocity is 0.00182/0.0055;
> >> > Case2 takes 20 timesteps to reach the end time and the end RMS/Max
> >> > velocity
> >> > is 0.00558/0.0352;
> >> > Case3 takes 141 timesteps to reach the end time and the end RMS/Max
> >> > velocity
> >> > is 0.0479/0.305.
> >> >
> >> > They all ran on one node of our cluster but the running time is also
> >> > different:
> >> > case1: 999s
> >> > case2: 1.48e03 s
> >> > case3: 3.86e03 s
> >> >
> >> > The end min/avg/max temperature and heat flux of upper/lower boundary
> of
> >> > the
> >> > three cases are all the same.
> >> >
> >> > From ASPECT manual, I noticed that the time step size is inversely
> >> > proportional to the max velocity of the cell so such a huge difference
> >> > of
> >> > tilmestep size must be caused by the difference of the velocity
> >> > magnitude.
> >> > But in the non-dimemsioanl problem, the same Ra should have the same
> >> > magnitude of velocity. Why in ASPECT, the same Ra can have such
> >> > different
> >> > velocity magnitude? I've realized that ASPECT uses the total pressure
> >> > and
> >> > total density in its momentum equation, so larger value of gravity can
> >> > introduce a larger rho_0*g_0 term in the momentum equation. I'm not
> sure
> >> > whether this will cause the solver matrix of momentum equation going
> >> > crazy.
> >> > Did anyone else run into this similar confusion? Wolfgang, Timo, Rene,
> >> > Juliane, any insight on this?
> >> >
> >> > Best,
> >> > Shangxin
> >> >
> >> > _______________________________________________
> >> > Aspect-devel mailing list
> >> > Aspect-devel at geodynamics.org
> >> >
> >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.
> geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-
> ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_
> QFS80R7PEA2q0EPwDy7VQw&m=UlGvhK8rWt4pq8DXeR9K1ZYfwj0hBZtV9zNTnj1zJS0&s=
> uxCinag781DkUL2eMpjkgQodtU35tW1_1Aww6Ngcpww&e=
> >
> >
>
>
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sdk at vt.edu Thu Apr 20 14:16:07 2017
From: sdk at vt.edu (Scott King)
Date: Thu, 20 Apr 2017 17:16:07 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID: <1F3F8FAA-341A-4A85-86B8-1738F2609287@vt.edu>
We’ve run with everything from 10^{-2} to 10^{-7} and seen no difference. It was on Grant’s AGU poster.
You have no idea how many times this problem has been run on our cluster…. That said, Shangxin I suggest
you rerun it just to check. I’m not sure Grant did this after the Bousinessq formulation was released.
> On Apr 20, 2017, at 4:47 PM, Timo Heister wrote:
>
> Shangxin,
>
>> set Linear solver tolerance = 1e-3
>
> Is there a reason for choosing such a tolerance? I would have no
> confidence that the solution is accurate. Can you re-run with
> something like 1e-8.
>
> That said, I think we likely still have a problem with equation
> scaling if the gravity is not the same order of magnitude as the
> velocity.
>
>
> On Thu, Apr 20, 2017 at 3:01 PM, Shangxin Liu > wrote:
>> Hi Timo and John,
>>
>> Before making further comments, there is a typo in my first email. I just
>> checked my prm files for these three cases. The CFL number of them is all
>> 0.5 instead of 1. And I use 3 global refinement, 0 adaptive refinement, with
>> fixed mesh.
>>
>> Yes. I can further try decreasing CFL number or increasing the grid
>> resolution. But the reason why we use 3 global refinement, i.e., 49152 cells
>> globally is that Zhong et al., 2008 paper uses 12*32^3 (393216) cells
>> globally, which is equivalent to global refinement 4 in ASPECT. However,
>> since ASPECT uses quadratic element while CitcomS uses linear element, we
>> suppose the lower global refinement 3 of ASPECT is equivalent to higher
>> global refinement 4 in CitcomS.
>>
>> John, the reason why we modify alpha and gravity to fix Ra is that
>> previously before the true Boussinesq approximation was merged into ASPECT,
>> we use a very small alpha to mimic constant reference density in energy
>> equation. Now we further try these series with the new ASPECT with
>> Boussinesq approximation formulation and found this confused issue.
>>
>> Timo, I'm using free slip boundary condition for velocity on both top and
>> bottom boundary.
>>
>> The attachment is the prm file for my first case that uses 7000 gravity and
>> 1.0 alpha. You can simply change gravity to 70000/700000 and alpha to
>> 0.1/0.01 to get case2/case3. Let's see whether we can get the same tilmestep
>> size and velocity magnitudes of the three cases.
>>
>> Best,
>> Shangxin
>>
>>
>>
>> On Thu, Apr 20, 2017 at 1:09 PM, Timo Heister
>> wrote:
>>>
>>> Shangxin,
>>>
>>> can you post your .prm? Are you using free slip boundary conditions
>>> for the velocity?
>>>
>>> On Wed, Apr 19, 2017 at 10:17 PM, Shangxin Liu wrote:
>>>> Hi;
>>>>
>>>> Recently I'm trying the new Boussinesq approximation formulation of
>>>> ASPECT
>>>> to test the 3D spherical shell time-dependent convection. I tried
>>>> running
>>>> the non-dimensional cases and set the start time to 0 and end time to 1.
>>>> Through a series of tests, I found that the same Ra but different
>>>> gravity
>>>> and alpha have far different results of velocity magnitude and the
>>>> tilmestep
>>>> size. For example, I fixed the Ra to 7000 and run three cases:
>>>>
>>>> Case1: gravity 7000, alpha 1
>>>> Case2: gravity 70000, alpha 0.1
>>>> Case3: gravity 700000, alpha 0.01
>>>> (All other parameters of these three cases in prm file are the same:
>>>> constant viscosity, CFL number=1, same solver tolerance, same spherical
>>>> shell geometry,etc..)
>>>>
>>>> Case1 takes only 13 timesteps to reach the end time and the end RMS/Max
>>>> velocity is 0.00182/0.0055;
>>>> Case2 takes 20 timesteps to reach the end time and the end RMS/Max
>>>> velocity
>>>> is 0.00558/0.0352;
>>>> Case3 takes 141 timesteps to reach the end time and the end RMS/Max
>>>> velocity
>>>> is 0.0479/0.305.
>>>>
>>>> They all ran on one node of our cluster but the running time is also
>>>> different:
>>>> case1: 999s
>>>> case2: 1.48e03 s
>>>> case3: 3.86e03 s
>>>>
>>>> The end min/avg/max temperature and heat flux of upper/lower boundary of
>>>> the
>>>> three cases are all the same.
>>>>
>>>> From ASPECT manual, I noticed that the time step size is inversely
>>>> proportional to the max velocity of the cell so such a huge difference
>>>> of
>>>> tilmestep size must be caused by the difference of the velocity
>>>> magnitude.
>>>> But in the non-dimemsioanl problem, the same Ra should have the same
>>>> magnitude of velocity. Why in ASPECT, the same Ra can have such
>>>> different
>>>> velocity magnitude? I've realized that ASPECT uses the total pressure
>>>> and
>>>> total density in its momentum equation, so larger value of gravity can
>>>> introduce a larger rho_0*g_0 term in the momentum equation. I'm not sure
>>>> whether this will cause the solver matrix of momentum equation going
>>>> crazy.
>>>> Did anyone else run into this similar confusion? Wolfgang, Timo, Rene,
>>>> Juliane, any insight on this?
>>>>
>>>> Best,
>>>> Shangxin
>>>>
>>>> _______________________________________________
>>>> Aspect-devel mailing list
>>>> Aspect-devel at geodynamics.org
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw&m=UlGvhK8rWt4pq8DXeR9K1ZYfwj0hBZtV9zNTnj1zJS0&s=uxCinag781DkUL2eMpjkgQodtU35tW1_1Aww6Ngcpww&e=
>>
>>
>
>
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jbnaliboff at ucdavis.edu Thu Apr 20 09:16:48 2017
From: jbnaliboff at ucdavis.edu (John Naliboff)
Date: Thu, 20 Apr 2017 09:16:48 -0700
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID: <8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
Hi Shangxin,
Thanks for sending this question in.
Before thinking about your results in terms of the equations, I have two questions:
1. Do the values for RMS/Max velocity vary significantly if you systematically decrease the CFL number?
2. Likewise, do the values change significantly if you increase the grid resolution?
If the grid resolution is low and with the CFL number near the upper limit of what should be used, it’s possible you may get some divergence in the results. Worth a check before diving into other potential issues.
On a side note, I personally have trouble interpreting results that vary the Ra number by orders of magnitude through terms other than the viscosity. While this is certainly an interesting numerical case study, is there a different motivation for varying the Ra number through terms other than the viscosity?
Cheers,
John
*************************************************
John Naliboff
Assistant Project Scientist, CIG
Earth & Planetary Sciences Dept., UC Davis
> On Apr 19, 2017, at 7:17 PM, Shangxin Liu wrote:
>
> Hi;
>
> Recently I'm trying the new Boussinesq approximation formulation of ASPECT to test the 3D spherical shell time-dependent convection. I tried running the non-dimensional cases and set the start time to 0 and end time to 1. Through a series of tests, I found that the same Ra but different gravity and alpha have far different results of velocity magnitude and the tilmestep size. For example, I fixed the Ra to 7000 and run three cases:
>
> Case1: gravity 7000, alpha 1
> Case2: gravity 70000, alpha 0.1
> Case3: gravity 700000, alpha 0.01
> (All other parameters of these three cases in prm file are the same: constant viscosity, CFL number=1, same solver tolerance, same spherical shell geometry,etc..)
>
> Case1 takes only 13 timesteps to reach the end time and the end RMS/Max velocity is 0.00182/0.0055;
> Case2 takes 20 timesteps to reach the end time and the end RMS/Max velocity is 0.00558/0.0352;
> Case3 takes 141 timesteps to reach the end time and the end RMS/Max velocity is 0.0479/0.305.
>
> They all ran on one node of our cluster but the running time is also different:
> case1: 999s
> case2: 1.48e03 s
> case3: 3.86e03 s
>
> The end min/avg/max temperature and heat flux of upper/lower boundary of the three cases are all the same.
>
> From ASPECT manual, I noticed that the time step size is inversely proportional to the max velocity of the cell so such a huge difference of tilmestep size must be caused by the difference of the velocity magnitude. But in the non-dimemsioanl problem, the same Ra should have the same magnitude of velocity. Why in ASPECT, the same Ra can have such different velocity magnitude? I've realized that ASPECT uses the total pressure and total density in its momentum equation, so larger value of gravity can introduce a larger rho_0*g_0 term in the momentum equation. I'm not sure whether this will cause the solver matrix of momentum equation going crazy. Did anyone else run into this similar confusion? Wolfgang, Timo, Rene, Juliane, any insight on this?
>
> Best,
> Shangxin
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sdk at vt.edu Fri Apr 21 04:23:53 2017
From: sdk at vt.edu (Scott King)
Date: Fri, 21 Apr 2017 07:23:53 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To: <8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
Message-ID: <9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
John;
See the section of the Aspect manual for the 2D incompressible Cartesian benchmarks. This is a trick used to try to circumvent the density term in the time derivative of the temperature equation, which is not constant (as it would be for Bousinessq). The small alpha makes that term nearly constant while keeping the buoyancy term as Ra. In 2D the manual shows this works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is more illconditioned to begin with or something about the iterations and tolerance levels for the solver is different between 2D and 3D. Or it needs to be different between the two and isn’t.
Scott
> On Apr 20, 2017, at 12:16 PM, John Naliboff wrote:
>
> On a side note, I personally have trouble interpreting results that vary the Ra number by orders of magnitude through terms other than the viscosity. While this is certainly an interesting numerical case study, is there a different motivation for varying the Ra number through terms other than the viscosity?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jbnaliboff at ucdavis.edu Fri Apr 21 10:44:17 2017
From: jbnaliboff at ucdavis.edu (John Naliboff)
Date: Fri, 21 Apr 2017 10:44:17 -0700
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To: <9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
Message-ID: <14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
Hi Scott, Hi Shangxin,
Shangxin - Thank you for the clarification regarding the models. CFL=0.5
is certainly more reasonable, but it still might be worth it to try a
value like 0.1 just to make sure nothing odd is going on there.
Scott - Thanks for the explanation and definitely interested to see what
solution(s) arise.
Cheers,
John
*************************************************
John Naliboff
Assistant Project Scientist, CIG
Earth & Planetary Sciences Dept., UC Davis
On 04/21/2017 04:23 AM, Scott King wrote:
>
> John;
>
> See the section of the Aspect manual for the 2D incompressible
> Cartesian benchmarks. This is a trick used to try to circumvent the
> density term in the time derivative of the temperature equation, which
> is not constant (as it would be for Bousinessq). The small alpha
> makes that term nearly constant while keeping the buoyancy term as Ra.
> In 2D the manual shows this works up to Ra=7000*1e10, alpha-1e-10.
> Trying to use this for 3D spherical it breaks around 10^3/1e-3. It
> suggests either the 3D spherical matrix is more illconditioned to
> begin with or something about the iterations and tolerance levels for
> the solver is different between 2D and 3D. Or it needs to be
> different between the two and isn’t.
>
> Scott
>
>
>
>> On Apr 20, 2017, at 12:16 PM, John Naliboff > > wrote:
>>
>> On a side note, I personally have trouble interpreting results that
>> vary the Ra number by orders of magnitude through terms other than
>> the viscosity. While this is certainly an interesting numerical case
>> study, is there a different motivation for varying the Ra number
>> through terms other than the viscosity?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sxliu at vt.edu Fri Apr 21 15:00:33 2017
From: sxliu at vt.edu (Shangxin Liu)
Date: Fri, 21 Apr 2017 18:00:33 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To: <14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
Message-ID:
Hi Timo, John, and others,
I quickly made several new tests using the new Boussinesq approximation
formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
CFL number don't help a lot. There is still order-of-magnitude difference
of the velocity statistics and time step size between g 7000&alpha 1, g
70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
refinement 4 to see but global refinement 3 with quadratic element may be
already enough resolution. Something weird is still happening.
Best,
Shangxin
On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
wrote:
> Hi Scott, Hi Shangxin,
>
> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
> is certainly more reasonable, but it still might be worth it to try a value
> like 0.1 just to make sure nothing odd is going on there.
>
> Scott - Thanks for the explanation and definitely interested to see what
> solution(s) arise.
>
> Cheers,
> John
>
> *************************************************
> John Naliboff
> Assistant Project Scientist, CIG
> Earth & Planetary Sciences Dept., UC Davis
>
> On 04/21/2017 04:23 AM, Scott King wrote:
>
>
> John;
>
> See the section of the Aspect manual for the 2D incompressible Cartesian
> benchmarks. This is a trick used to try to circumvent the density term in
> the time derivative of the temperature equation, which is not constant (as
> it would be for Bousinessq). The small alpha makes that term nearly
> constant while keeping the buoyancy term as Ra. In 2D the manual shows
> this works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D
> spherical it breaks around 10^3/1e-3. It suggests either the 3D spherical
> matrix is more illconditioned to begin with or something about the
> iterations and tolerance levels for the solver is different between 2D and
> 3D. Or it needs to be different between the two and isn’t.
>
> Scott
>
>
>
> On Apr 20, 2017, at 12:16 PM, John Naliboff
> wrote:
>
> On a side note, I personally have trouble interpreting results that vary
> the Ra number by orders of magnitude through terms other than the
> viscosity. While this is certainly an interesting numerical case study, is
> there a different motivation for varying the Ra number through terms other
> than the viscosity?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3D_spherical_shell_test_results.pdf
Type: application/pdf
Size: 19128 bytes
Desc: not available
URL:
From heister at clemson.edu Mon Apr 24 08:09:04 2017
From: heister at clemson.edu (Timo Heister)
Date: Mon, 24 Apr 2017 11:09:04 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
Message-ID:
Shangxin,
I looked a little bit more into your example. Some observations:
1. You are using the "simple" model for a nondimensional computation.
It is probably a better idea to use "nondimensional" instead. I will
try to see if that makes a difference.
2. I haven't quite figured out how to quantify "don't make gravity too
large", but as I expected, the difference increases the larger the
gravity is. I think our pressure scaling or linear solver tolerance
needs to take the size of the gravity into account but it currently
doesn't.
3. A finer solver tolerance is likely important (see 2).
4. It looks like the buoyancy term can not be resolved adequately on
the current mesh (if you plot T or rho, you can see that it jumps from
0 to 0.5 within a single cell. See attached.
5. If you plot RMS over time, you can see that the timesteps are quite
large (especially for alpha>0.1). I am not sure if this is connected
to 4) or not.
Anyways, I will get back to you when I figure out more.
On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
> Hi Timo, John, and others,
>
> I quickly made several new tests using the new Boussinesq approximation
> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
> CFL number don't help a lot. There is still order-of-magnitude difference of
> the velocity statistics and time step size between g 7000&alpha 1, g
> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
> refinement 4 to see but global refinement 3 with quadratic element may be
> already enough resolution. Something weird is still happening.
>
> Best,
> Shangxin
>
>
> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
> wrote:
>>
>> Hi Scott, Hi Shangxin,
>>
>> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
>> is certainly more reasonable, but it still might be worth it to try a value
>> like 0.1 just to make sure nothing odd is going on there.
>>
>> Scott - Thanks for the explanation and definitely interested to see what
>> solution(s) arise.
>>
>> Cheers,
>> John
>>
>> *************************************************
>> John Naliboff
>> Assistant Project Scientist, CIG
>> Earth & Planetary Sciences Dept., UC Davis
>>
>> On 04/21/2017 04:23 AM, Scott King wrote:
>>
>>
>> John;
>>
>> See the section of the Aspect manual for the 2D incompressible Cartesian
>> benchmarks. This is a trick used to try to circumvent the density term in
>> the time derivative of the temperature equation, which is not constant (as
>> it would be for Bousinessq). The small alpha makes that term nearly
>> constant while keeping the buoyancy term as Ra. In 2D the manual shows this
>> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical
>> it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is
>> more illconditioned to begin with or something about the iterations and
>> tolerance levels for the solver is different between 2D and 3D. Or it
>> needs to be different between the two and isn’t.
>>
>> Scott
>>
>>
>>
>> On Apr 20, 2017, at 12:16 PM, John Naliboff
>> wrote:
>>
>> On a side note, I personally have trouble interpreting results that vary
>> the Ra number by orders of magnitude through terms other than the viscosity.
>> While this is certainly an interesting numerical case study, is there a
>> different motivation for varying the Ra number through terms other than the
>> viscosity?
>>
>>
>>
>
--
Timo Heister
http://www.math.clemson.edu/~heister/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: density.png
Type: image/png
Size: 130671 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rms-alpha.png
Type: image/png
Size: 37235 bytes
Desc: not available
URL:
From maxwellr at gmail.com Mon Apr 24 08:40:37 2017
From: maxwellr at gmail.com (Max Rudolph)
Date: Mon, 24 Apr 2017 08:40:37 -0700
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
Message-ID:
How large are the dynamic pressures in these calculations with very large
g, relative to the hydrostatic pressure? The dynamic pressure probably
scales with 1/eta while the hydrostatic contribution is rho*g*d. It would
be interesting to see if these issues persist if you use only the dynamic
pressure in the governing equations, e.g. what is suggested in the manual
on p. 17.
On Mon, Apr 24, 2017 at 8:09 AM, Timo Heister wrote:
> Shangxin,
>
> I looked a little bit more into your example. Some observations:
> 1. You are using the "simple" model for a nondimensional computation.
> It is probably a better idea to use "nondimensional" instead. I will
> try to see if that makes a difference.
> 2. I haven't quite figured out how to quantify "don't make gravity too
> large", but as I expected, the difference increases the larger the
> gravity is. I think our pressure scaling or linear solver tolerance
> needs to take the size of the gravity into account but it currently
> doesn't.
> 3. A finer solver tolerance is likely important (see 2).
> 4. It looks like the buoyancy term can not be resolved adequately on
> the current mesh (if you plot T or rho, you can see that it jumps from
> 0 to 0.5 within a single cell. See attached.
> 5. If you plot RMS over time, you can see that the timesteps are quite
> large (especially for alpha>0.1). I am not sure if this is connected
> to 4) or not.
>
> Anyways, I will get back to you when I figure out more.
>
> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
> > Hi Timo, John, and others,
> >
> > I quickly made several new tests using the new Boussinesq approximation
> > formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL
> number.
> > The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
> > CFL number don't help a lot. There is still order-of-magnitude
> difference of
> > the velocity statistics and time step size between g 7000&alpha 1, g
> > 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
> > refinement 4 to see but global refinement 3 with quadratic element may be
> > already enough resolution. Something weird is still happening.
> >
> > Best,
> > Shangxin
> >
> >
> > On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
> > wrote:
> >>
> >> Hi Scott, Hi Shangxin,
> >>
> >> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
> >> is certainly more reasonable, but it still might be worth it to try a
> value
> >> like 0.1 just to make sure nothing odd is going on there.
> >>
> >> Scott - Thanks for the explanation and definitely interested to see what
> >> solution(s) arise.
> >>
> >> Cheers,
> >> John
> >>
> >> *************************************************
> >> John Naliboff
> >> Assistant Project Scientist, CIG
> >> Earth & Planetary Sciences Dept., UC Davis
> >>
> >> On 04/21/2017 04:23 AM, Scott King wrote:
> >>
> >>
> >> John;
> >>
> >> See the section of the Aspect manual for the 2D incompressible Cartesian
> >> benchmarks. This is a trick used to try to circumvent the density
> term in
> >> the time derivative of the temperature equation, which is not constant
> (as
> >> it would be for Bousinessq). The small alpha makes that term nearly
> >> constant while keeping the buoyancy term as Ra. In 2D the manual shows
> this
> >> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D
> spherical
> >> it breaks around 10^3/1e-3. It suggests either the 3D spherical
> matrix is
> >> more illconditioned to begin with or something about the iterations and
> >> tolerance levels for the solver is different between 2D and 3D. Or it
> >> needs to be different between the two and isn’t.
> >>
> >> Scott
> >>
> >>
> >>
> >> On Apr 20, 2017, at 12:16 PM, John Naliboff
> >> wrote:
> >>
> >> On a side note, I personally have trouble interpreting results that vary
> >> the Ra number by orders of magnitude through terms other than the
> viscosity.
> >> While this is certainly an interesting numerical case study, is there a
> >> different motivation for varying the Ra number through terms other than
> the
> >> viscosity?
> >>
> >>
> >>
> >
>
>
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dannberg at gfz-potsdam.de Mon Apr 24 09:39:43 2017
From: dannberg at gfz-potsdam.de (Juliane Dannberg)
Date: Mon, 24 Apr 2017 10:39:43 -0600
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
Message-ID: <0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
Timo, Shangxin,
if you have the model running already, another thing to check might be
the ratio between the dynamic and static pressure (it is something that
came up in a discussion between Rene, Wolfgang and me, and Rene
mentioned that the problem we are talking about has quite a small
Rayleigh number, so small dynamic pressures). This ratio is changed when
scaling alpha vs. gravity, and if it is too small, it might not even be
the solver tolerance that is the problem.
Juliane
On 04/24/2017 09:09 AM, Timo Heister wrote:
> Shangxin,
>
> I looked a little bit more into your example. Some observations:
> 1. You are using the "simple" model for a nondimensional computation.
> It is probably a better idea to use "nondimensional" instead. I will
> try to see if that makes a difference.
> 2. I haven't quite figured out how to quantify "don't make gravity too
> large", but as I expected, the difference increases the larger the
> gravity is. I think our pressure scaling or linear solver tolerance
> needs to take the size of the gravity into account but it currently
> doesn't.
> 3. A finer solver tolerance is likely important (see 2).
> 4. It looks like the buoyancy term can not be resolved adequately on
> the current mesh (if you plot T or rho, you can see that it jumps from
> 0 to 0.5 within a single cell. See attached.
> 5. If you plot RMS over time, you can see that the timesteps are quite
> large (especially for alpha>0.1). I am not sure if this is connected
> to 4) or not.
>
> Anyways, I will get back to you when I figure out more.
>
> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
>> Hi Timo, John, and others,
>>
>> I quickly made several new tests using the new Boussinesq approximation
>> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
>> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
>> CFL number don't help a lot. There is still order-of-magnitude difference of
>> the velocity statistics and time step size between g 7000&alpha 1, g
>> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
>> refinement 4 to see but global refinement 3 with quadratic element may be
>> already enough resolution. Something weird is still happening.
>>
>> Best,
>> Shangxin
>>
>>
>> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
>> wrote:
>>> Hi Scott, Hi Shangxin,
>>>
>>> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
>>> is certainly more reasonable, but it still might be worth it to try a value
>>> like 0.1 just to make sure nothing odd is going on there.
>>>
>>> Scott - Thanks for the explanation and definitely interested to see what
>>> solution(s) arise.
>>>
>>> Cheers,
>>> John
>>>
>>> *************************************************
>>> John Naliboff
>>> Assistant Project Scientist, CIG
>>> Earth & Planetary Sciences Dept., UC Davis
>>>
>>> On 04/21/2017 04:23 AM, Scott King wrote:
>>>
>>>
>>> John;
>>>
>>> See the section of the Aspect manual for the 2D incompressible Cartesian
>>> benchmarks. This is a trick used to try to circumvent the density term in
>>> the time derivative of the temperature equation, which is not constant (as
>>> it would be for Bousinessq). The small alpha makes that term nearly
>>> constant while keeping the buoyancy term as Ra. In 2D the manual shows this
>>> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical
>>> it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is
>>> more illconditioned to begin with or something about the iterations and
>>> tolerance levels for the solver is different between 2D and 3D. Or it
>>> needs to be different between the two and isn’t.
>>>
>>> Scott
>>>
>>>
>>>
>>> On Apr 20, 2017, at 12:16 PM, John Naliboff
>>> wrote:
>>>
>>> On a side note, I personally have trouble interpreting results that vary
>>> the Ra number by orders of magnitude through terms other than the viscosity.
>>> While this is certainly an interesting numerical case study, is there a
>>> different motivation for varying the Ra number through terms other than the
>>> viscosity?
>>>
>>>
>>>
>
>
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sdk at vt.edu Mon Apr 24 10:32:36 2017
From: sdk at vt.edu (Scott King)
Date: Mon, 24 Apr 2017 13:32:36 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To: <0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
<0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
Message-ID:
Julia;
I had thought that the new business formulation was only using only the dynamic pressure. Is that not the case? I had a hard time figuring that out from the manual.
Best,
Scott
> On Apr 24, 2017, at 12:39 PM, Juliane Dannberg wrote:
>
> Timo, Shangxin,
> if you have the model running already, another thing to check might be the ratio between the dynamic and static pressure (it is something that came up in a discussion between Rene, Wolfgang and me, and Rene mentioned that the problem we are talking about has quite a small Rayleigh number, so small dynamic pressures). This ratio is changed when scaling alpha vs. gravity, and if it is too small, it might not even be the solver tolerance that is the problem.
> Juliane
>
> On 04/24/2017 09:09 AM, Timo Heister wrote:
>> Shangxin,
>>
>> I looked a little bit more into your example. Some observations:
>> 1. You are using the "simple" model for a nondimensional computation.
>> It is probably a better idea to use "nondimensional" instead. I will
>> try to see if that makes a difference.
>> 2. I haven't quite figured out how to quantify "don't make gravity too
>> large", but as I expected, the difference increases the larger the
>> gravity is. I think our pressure scaling or linear solver tolerance
>> needs to take the size of the gravity into account but it currently
>> doesn't.
>> 3. A finer solver tolerance is likely important (see 2).
>> 4. It looks like the buoyancy term can not be resolved adequately on
>> the current mesh (if you plot T or rho, you can see that it jumps from
>> 0 to 0.5 within a single cell. See attached.
>> 5. If you plot RMS over time, you can see that the timesteps are quite
>> large (especially for alpha>0.1). I am not sure if this is connected
>> to 4) or not.
>>
>> Anyways, I will get back to you when I figure out more.
>>
>> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
>>> Hi Timo, John, and others,
>>>
>>> I quickly made several new tests using the new Boussinesq approximation
>>> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
>>> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
>>> CFL number don't help a lot. There is still order-of-magnitude difference of
>>> the velocity statistics and time step size between g 7000&alpha 1, g
>>> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
>>> refinement 4 to see but global refinement 3 with quadratic element may be
>>> already enough resolution. Something weird is still happening.
>>>
>>> Best,
>>> Shangxin
>>>
>>>
>>> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
>>> wrote:
>>>> Hi Scott, Hi Shangxin,
>>>>
>>>> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
>>>> is certainly more reasonable, but it still might be worth it to try a value
>>>> like 0.1 just to make sure nothing odd is going on there.
>>>>
>>>> Scott - Thanks for the explanation and definitely interested to see what
>>>> solution(s) arise.
>>>>
>>>> Cheers,
>>>> John
>>>>
>>>> *************************************************
>>>> John Naliboff
>>>> Assistant Project Scientist, CIG
>>>> Earth & Planetary Sciences Dept., UC Davis
>>>>
>>>> On 04/21/2017 04:23 AM, Scott King wrote:
>>>>
>>>>
>>>> John;
>>>>
>>>> See the section of the Aspect manual for the 2D incompressible Cartesian
>>>> benchmarks. This is a trick used to try to circumvent the density term in
>>>> the time derivative of the temperature equation, which is not constant (as
>>>> it would be for Bousinessq). The small alpha makes that term nearly
>>>> constant while keeping the buoyancy term as Ra. In 2D the manual shows this
>>>> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical
>>>> it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is
>>>> more illconditioned to begin with or something about the iterations and
>>>> tolerance levels for the solver is different between 2D and 3D. Or it
>>>> needs to be different between the two and isn’t.
>>>>
>>>> Scott
>>>>
>>>>
>>>>
>>>> On Apr 20, 2017, at 12:16 PM, John Naliboff
>>>> wrote:
>>>>
>>>> On a side note, I personally have trouble interpreting results that vary
>>>> the Ra number by orders of magnitude through terms other than the viscosity.
>>>> While this is certainly an interesting numerical case study, is there a
>>>> different motivation for varying the Ra number through terms other than the
>>>> viscosity?
>>>>
>>>>
>>>>
>>
>>
>>
>>
>> _______________________________________________
>> Aspect-devel mailing list
>> Aspect-devel at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sxliu at vt.edu Mon Apr 24 16:05:19 2017
From: sxliu at vt.edu (Shangxin Liu)
Date: Mon, 24 Apr 2017 19:05:19 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
Message-ID:
Hi Timo,
Just to confirm. Are you plotting the total density at the first time step?
Best,
Shangxin
On Mon, Apr 24, 2017 at 11:09 AM, Timo Heister wrote:
> Shangxin,
>
> I looked a little bit more into your example. Some observations:
> 1. You are using the "simple" model for a nondimensional computation.
> It is probably a better idea to use "nondimensional" instead. I will
> try to see if that makes a difference.
> 2. I haven't quite figured out how to quantify "don't make gravity too
> large", but as I expected, the difference increases the larger the
> gravity is. I think our pressure scaling or linear solver tolerance
> needs to take the size of the gravity into account but it currently
> doesn't.
> 3. A finer solver tolerance is likely important (see 2).
> 4. It looks like the buoyancy term can not be resolved adequately on
> the current mesh (if you plot T or rho, you can see that it jumps from
> 0 to 0.5 within a single cell. See attached.
> 5. If you plot RMS over time, you can see that the timesteps are quite
> large (especially for alpha>0.1). I am not sure if this is connected
> to 4) or not.
>
> Anyways, I will get back to you when I figure out more.
>
> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
> > Hi Timo, John, and others,
> >
> > I quickly made several new tests using the new Boussinesq approximation
> > formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL
> number.
> > The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
> > CFL number don't help a lot. There is still order-of-magnitude
> difference of
> > the velocity statistics and time step size between g 7000&alpha 1, g
> > 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
> > refinement 4 to see but global refinement 3 with quadratic element may be
> > already enough resolution. Something weird is still happening.
> >
> > Best,
> > Shangxin
> >
> >
> > On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
> > wrote:
> >>
> >> Hi Scott, Hi Shangxin,
> >>
> >> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
> >> is certainly more reasonable, but it still might be worth it to try a
> value
> >> like 0.1 just to make sure nothing odd is going on there.
> >>
> >> Scott - Thanks for the explanation and definitely interested to see what
> >> solution(s) arise.
> >>
> >> Cheers,
> >> John
> >>
> >> *************************************************
> >> John Naliboff
> >> Assistant Project Scientist, CIG
> >> Earth & Planetary Sciences Dept., UC Davis
> >>
> >> On 04/21/2017 04:23 AM, Scott King wrote:
> >>
> >>
> >> John;
> >>
> >> See the section of the Aspect manual for the 2D incompressible Cartesian
> >> benchmarks. This is a trick used to try to circumvent the density
> term in
> >> the time derivative of the temperature equation, which is not constant
> (as
> >> it would be for Bousinessq). The small alpha makes that term nearly
> >> constant while keeping the buoyancy term as Ra. In 2D the manual shows
> this
> >> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D
> spherical
> >> it breaks around 10^3/1e-3. It suggests either the 3D spherical
> matrix is
> >> more illconditioned to begin with or something about the iterations and
> >> tolerance levels for the solver is different between 2D and 3D. Or it
> >> needs to be different between the two and isn’t.
> >>
> >> Scott
> >>
> >>
> >>
> >> On Apr 20, 2017, at 12:16 PM, John Naliboff
> >> wrote:
> >>
> >> On a side note, I personally have trouble interpreting results that vary
> >> the Ra number by orders of magnitude through terms other than the
> viscosity.
> >> While this is certainly an interesting numerical case study, is there a
> >> different motivation for varying the Ra number through terms other than
> the
> >> viscosity?
> >>
> >>
> >>
> >
>
>
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sxliu at vt.edu Mon Apr 24 16:30:09 2017
From: sxliu at vt.edu (Shangxin Liu)
Date: Mon, 24 Apr 2017 19:30:09 -0400
Subject: [aspect-devel] Linear solver A block tolerance & Linear solver S
block tolerance ?
Message-ID:
Hi Timo,
This may be unrelated to our alpha vs gravity discussion. But there are two
new Global parameters I have no idea about their function:
Linear solver A block tolerance and Linear solver S block tolerance.
What are their mathematic meanings and functions, compared to linear solver
tolerance?
Best,
Shangxin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dannberg at gfz-potsdam.de Mon Apr 24 11:10:21 2017
From: dannberg at gfz-potsdam.de (Juliane Dannberg)
Date: Mon, 24 Apr 2017 12:10:21 -0600
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
<0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
Message-ID: <97f45d7b-f773-8d87-4cdf-fd7e83f965fa@gfz-potsdam.de>
As far as I know we always use the full pressure (unless one chooses the
density in the material model to only be the density deviations from the
reference profile, in which case the computed pressure would be the
dynamic pressure), and looking at the manual, I agree that we could
document this better.
Rene, Timo, please correct me if I am wrong.
@Max: sorry, didn't see your email, we basically had the same idea you
posted.
On 04/24/2017 11:32 AM, Scott King wrote:
>
> Julia;
>
> I had thought that the new business formulation was only using only
> the dynamic pressure. Is that not the case? I had a hard time
> figuring that out from the manual.
>
> Best,
>
> Scott
>
>> On Apr 24, 2017, at 12:39 PM, Juliane Dannberg
>> > wrote:
>>
>> Timo, Shangxin,
>>
>> if you have the model running already, another thing to check might
>> be the ratio between the dynamic and static pressure (it is something
>> that came up in a discussion between Rene, Wolfgang and me, and Rene
>> mentioned that the problem we are talking about has quite a small
>> Rayleigh number, so small dynamic pressures). This ratio is changed
>> when scaling alpha vs. gravity, and if it is too small, it might not
>> even be the solver tolerance that is the problem.
>>
>> Juliane
>>
>>
>> On 04/24/2017 09:09 AM, Timo Heister wrote:
>>> Shangxin,
>>>
>>> I looked a little bit more into your example. Some observations:
>>> 1. You are using the "simple" model for a nondimensional computation.
>>> It is probably a better idea to use "nondimensional" instead. I will
>>> try to see if that makes a difference.
>>> 2. I haven't quite figured out how to quantify "don't make gravity too
>>> large", but as I expected, the difference increases the larger the
>>> gravity is. I think our pressure scaling or linear solver tolerance
>>> needs to take the size of the gravity into account but it currently
>>> doesn't.
>>> 3. A finer solver tolerance is likely important (see 2).
>>> 4. It looks like the buoyancy term can not be resolved adequately on
>>> the current mesh (if you plot T or rho, you can see that it jumps from
>>> 0 to 0.5 within a single cell. See attached.
>>> 5. If you plot RMS over time, you can see that the timesteps are quite
>>> large (especially for alpha>0.1). I am not sure if this is connected
>>> to 4) or not.
>>>
>>> Anyways, I will get back to you when I figure out more.
>>>
>>> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
>>>> Hi Timo, John, and others,
>>>>
>>>> I quickly made several new tests using the new Boussinesq approximation
>>>> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
>>>> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
>>>> CFL number don't help a lot. There is still order-of-magnitude difference of
>>>> the velocity statistics and time step size between g 7000&alpha 1, g
>>>> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
>>>> refinement 4 to see but global refinement 3 with quadratic element may be
>>>> already enough resolution. Something weird is still happening.
>>>>
>>>> Best,
>>>> Shangxin
>>>>
>>>>
>>>> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
>>>> wrote:
>>>>> Hi Scott, Hi Shangxin,
>>>>>
>>>>> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
>>>>> is certainly more reasonable, but it still might be worth it to try a value
>>>>> like 0.1 just to make sure nothing odd is going on there.
>>>>>
>>>>> Scott - Thanks for the explanation and definitely interested to see what
>>>>> solution(s) arise.
>>>>>
>>>>> Cheers,
>>>>> John
>>>>>
>>>>> *************************************************
>>>>> John Naliboff
>>>>> Assistant Project Scientist, CIG
>>>>> Earth & Planetary Sciences Dept., UC Davis
>>>>>
>>>>> On 04/21/2017 04:23 AM, Scott King wrote:
>>>>>
>>>>>
>>>>> John;
>>>>>
>>>>> See the section of the Aspect manual for the 2D incompressible Cartesian
>>>>> benchmarks. This is a trick used to try to circumvent the density term in
>>>>> the time derivative of the temperature equation, which is not constant (as
>>>>> it would be for Bousinessq). The small alpha makes that term nearly
>>>>> constant while keeping the buoyancy term as Ra. In 2D the manual shows this
>>>>> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical
>>>>> it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is
>>>>> more illconditioned to begin with or something about the iterations and
>>>>> tolerance levels for the solver is different between 2D and 3D. Or it
>>>>> needs to be different between the two and isn’t.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>> On Apr 20, 2017, at 12:16 PM, John Naliboff
>>>>> wrote:
>>>>>
>>>>> On a side note, I personally have trouble interpreting results that vary
>>>>> the Ra number by orders of magnitude through terms other than the viscosity.
>>>>> While this is certainly an interesting numerical case study, is there a
>>>>> different motivation for varying the Ra number through terms other than the
>>>>> viscosity?
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Aspect-devel mailing list
>>> Aspect-devel at geodynamics.org
>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>>
>> _______________________________________________
>> Aspect-devel mailing list
>> Aspect-devel at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bangerth at tamu.edu Tue Apr 25 05:31:17 2017
From: bangerth at tamu.edu (Wolfgang Bangerth)
Date: Tue, 25 Apr 2017 06:31:17 -0600
Subject: [aspect-devel] Linear solver A block tolerance & Linear solver
S block tolerance ?
In-Reply-To:
References:
Message-ID: <9f4b50f1-e5b5-f462-f445-fbb72277e967@tamu.edu>
On 04/24/2017 05:30 PM, Shangxin Liu wrote:
> Hi Timo,
>
> This may be unrelated to our alpha vs gravity discussion. But there are two
> new Global parameters I have no idea about their function:
>
> Linear solver A block tolerance and Linear solver S block tolerance.
>
> What are their mathematic meanings and functions, compared to linear solver
> tolerance?
They are discussed here (with corresponding entries in the manual):
https://github.com/geodynamics/aspect/blob/master/source/simulator/parameters.cc#L269
They correspond to the precondition that is discussed in the Kronbichler et
al. paper.
Best
Wolfgang
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth at colostate.edu
www: http://www.math.colostate.edu/~bangerth/
From bangerth at tamu.edu Tue Apr 25 05:21:20 2017
From: bangerth at tamu.edu (Wolfgang Bangerth)
Date: Tue, 25 Apr 2017 06:21:20 -0600
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To: <97f45d7b-f773-8d87-4cdf-fd7e83f965fa@gfz-potsdam.de>
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
<0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
<97f45d7b-f773-8d87-4cdf-fd7e83f965fa@gfz-potsdam.de>
Message-ID: <54d97330-431f-a115-5fa3-0a35c0bd01e8@tamu.edu>
On 04/24/2017 12:10 PM, Juliane Dannberg wrote:
> As far as I know we always use the full pressure (unless one chooses the
> density in the material model to only be the density deviations from the
> reference profile, in which case the computed pressure would be the dynamic
> pressure), and looking at the manual, I agree that we could document this better.
Yes, we use the full pressure. The full pressure, however, equals the dynamic
pressure if you use a material model in which the density has no constant term
and only contains the thermal expansion term, i.e.,
rho(T) = -\alpha T
There is a hydrostatic component of the pressure if the density is given as
rho(T) = rho_0 - \alpha T
Which of the two you use is up to you.
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth at colostate.edu
www: http://www.math.colostate.edu/~bangerth/
From heister at clemson.edu Tue Apr 25 06:27:26 2017
From: heister at clemson.edu (Timo Heister)
Date: Tue, 25 Apr 2017 09:27:26 -0400
Subject: [aspect-devel] Linear solver A block tolerance & Linear solver
S block tolerance ?
In-Reply-To: <9f4b50f1-e5b5-f462-f445-fbb72277e967@tamu.edu>
References:
<9f4b50f1-e5b5-f462-f445-fbb72277e967@tamu.edu>
Message-ID:
> This may be unrelated to our alpha vs gravity discussion
Yes, this is unrelated provided that your normal linear solver
tolerance is chosen appropriately.
On Tue, Apr 25, 2017 at 8:31 AM, Wolfgang Bangerth wrote:
> On 04/24/2017 05:30 PM, Shangxin Liu wrote:
>>
>> Hi Timo,
>>
>> This may be unrelated to our alpha vs gravity discussion. But there are
>> two
>> new Global parameters I have no idea about their function:
>>
>> Linear solver A block tolerance and Linear solver S block tolerance.
>>
>> What are their mathematic meanings and functions, compared to linear
>> solver
>> tolerance?
>
>
> They are discussed here (with corresponding entries in the manual):
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_geodynamics_aspect_blob_master_source_simulator_parameters.cc-23L269&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=c08Btfq4m9QEScXN3ZQwLZzzWQE7S8CYq1IYuzKV_Zk&m=8z3tJVPqzYcOQA2U2ajbTldOt_FUf4sTgEk7eCxjSIA&s=nM6gEmG1norfGMSsj0bwfhjuY6nP50Ep3AfKY7srnKY&e=
>
> They correspond to the precondition that is discussed in the Kronbichler et
> al. paper.
>
> Best
> Wolfgang
>
> --
> ------------------------------------------------------------------------
> Wolfgang Bangerth email: bangerth at colostate.edu
> www: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.math.colostate.edu_-7Ebangerth_&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=c08Btfq4m9QEScXN3ZQwLZzzWQE7S8CYq1IYuzKV_Zk&m=8z3tJVPqzYcOQA2U2ajbTldOt_FUf4sTgEk7eCxjSIA&s=0YzBnsO0bVT275l0QIJ9CKCs5tVCWlPLNhr-xiUF_e0&e=
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=c08Btfq4m9QEScXN3ZQwLZzzWQE7S8CYq1IYuzKV_Zk&m=8z3tJVPqzYcOQA2U2ajbTldOt_FUf4sTgEk7eCxjSIA&s=78T3IZSQ0agupzwIayZKgJVt5c8VNDqEk60dtU818sg&e=
--
Timo Heister
http://www.math.clemson.edu/~heister/
From philip.j.heron at durham.ac.uk Tue Apr 25 08:05:30 2017
From: philip.j.heron at durham.ac.uk (HERON, PHILIP J.)
Date: Tue, 25 Apr 2017 15:05:30 +0000
Subject: [aspect-devel] New UK User
Message-ID:
Hello all,
I just thought I would send a quick message to introduce myself - I'm Phil working at Durham University. I am looking to use ASPECT for a few different projects over the next few years (at least), and try and set up Durham University as a hub of ASPECT users (teaching and academic studies).
I will be installing ASPECT on a number of clusters over the coming weeks and I was wondering whether any other UK users have already done so - in particular for ARCHER or N8?
When I install ASPECT on these clusters I will make their process available if has any difficult points!
Talk to you all soon!
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From maxwellr at gmail.com Tue Apr 25 09:59:10 2017
From: maxwellr at gmail.com (Max Rudolph)
Date: Tue, 25 Apr 2017 09:59:10 -0700
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To: <97f45d7b-f773-8d87-4cdf-fd7e83f965fa@gfz-potsdam.de>
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
<0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
<97f45d7b-f773-8d87-4cdf-fd7e83f965fa@gfz-potsdam.de>
Message-ID:
One other idea - you could try scaling the viscosity with the magnitude of
the gravity for these calculations. because the hydrostatic pressure is
rho*g*d and the dimensionless dynamic pressure scales with 1/eta, if you
increase g an order of magnitude, you should be able to maintain constant
ratio between static and dynamic pressures by increasing the viscosity an
order of magnitude.
On Mon, Apr 24, 2017 at 11:10 AM, Juliane Dannberg
wrote:
> As far as I know we always use the full pressure (unless one chooses the
> density in the material model to only be the density deviations from the
> reference profile, in which case the computed pressure would be the dynamic
> pressure), and looking at the manual, I agree that we could document this
> better.
> Rene, Timo, please correct me if I am wrong.
>
> @Max: sorry, didn't see your email, we basically had the same idea you
> posted.
>
> On 04/24/2017 11:32 AM, Scott King wrote:
>
>
> Julia;
>
> I had thought that the new business formulation was only using only the
> dynamic pressure. Is that not the case? I had a hard time figuring that
> out from the manual.
>
> Best,
>
> Scott
>
> On Apr 24, 2017, at 12:39 PM, Juliane Dannberg
> wrote:
>
> Timo, Shangxin,
>
> if you have the model running already, another thing to check might be the
> ratio between the dynamic and static pressure (it is something that came up
> in a discussion between Rene, Wolfgang and me, and Rene mentioned that the
> problem we are talking about has quite a small Rayleigh number, so small
> dynamic pressures). This ratio is changed when scaling alpha vs. gravity,
> and if it is too small, it might not even be the solver tolerance that is
> the problem.
>
> Juliane
>
>
> On 04/24/2017 09:09 AM, Timo Heister wrote:
>
> Shangxin,
>
> I looked a little bit more into your example. Some observations:
> 1. You are using the "simple" model for a nondimensional computation.
> It is probably a better idea to use "nondimensional" instead. I will
> try to see if that makes a difference.
> 2. I haven't quite figured out how to quantify "don't make gravity too
> large", but as I expected, the difference increases the larger the
> gravity is. I think our pressure scaling or linear solver tolerance
> needs to take the size of the gravity into account but it currently
> doesn't.
> 3. A finer solver tolerance is likely important (see 2).
> 4. It looks like the buoyancy term can not be resolved adequately on
> the current mesh (if you plot T or rho, you can see that it jumps from
> 0 to 0.5 within a single cell. See attached.
> 5. If you plot RMS over time, you can see that the timesteps are quite
> large (especially for alpha>0.1). I am not sure if this is connected
> to 4) or not.
>
> Anyways, I will get back to you when I figure out more.
>
> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
>
> Hi Timo, John, and others,
>
> I quickly made several new tests using the new Boussinesq approximation
> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
> CFL number don't help a lot. There is still order-of-magnitude difference of
> the velocity statistics and time step size between g 7000&alpha 1, g
> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
> refinement 4 to see but global refinement 3 with quadratic element may be
> already enough resolution. Something weird is still happening.
>
> Best,
> Shangxin
>
>
> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
> wrote:
>
> Hi Scott, Hi Shangxin,
>
> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
> is certainly more reasonable, but it still might be worth it to try a value
> like 0.1 just to make sure nothing odd is going on there.
>
> Scott - Thanks for the explanation and definitely interested to see what
> solution(s) arise.
>
> Cheers,
> John
>
> *************************************************
> John Naliboff
> Assistant Project Scientist, CIG
> Earth & Planetary Sciences Dept., UC Davis
>
> On 04/21/2017 04:23 AM, Scott King wrote:
>
>
> John;
>
> See the section of the Aspect manual for the 2D incompressible Cartesian
> benchmarks. This is a trick used to try to circumvent the density term in
> the time derivative of the temperature equation, which is not constant (as
> it would be for Bousinessq). The small alpha makes that term nearly
> constant while keeping the buoyancy term as Ra. In 2D the manual shows this
> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical
> it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is
> more illconditioned to begin with or something about the iterations and
> tolerance levels for the solver is different between 2D and 3D. Or it
> needs to be different between the two and isn’t.
>
> Scott
>
>
>
> On Apr 20, 2017, at 12:16 PM, John Naliboff
> wrote:
>
> On a side note, I personally have trouble interpreting results that vary
> the Ra number by orders of magnitude through terms other than the viscosity.
> While this is certainly an interesting numerical case study, is there a
> different motivation for varying the Ra number through terms other than the
> viscosity?
>
>
>
>
>
>
> _______________________________________________
> Aspect-devel mailing listAspect-devel at geodynamics.orghttp://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
>
>
>
> _______________________________________________
> Aspect-devel mailing listAspect-devel at geodynamics.orghttp://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sdk at vt.edu Tue Apr 25 10:44:52 2017
From: sdk at vt.edu (Scott King)
Date: Tue, 25 Apr 2017 13:44:52 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
<8E4F44AF-EA1E-4D03-A2C8-7C629BE773B7@ucdavis.edu>
<9A19C582-401B-46A0-A86F-B4B3E43BE3FA@vt.edu>
<14c78284-16e5-b999-b00b-b8e319c234fa@ucdavis.edu>
<0953b89e-bc24-e5bc-835f-67e4627a13cb@gfz-potsdam.de>
<97f45d7b-f773-8d87-4cdf-fd7e83f965fa@gfz-potsdam.de>
Message-ID: <425B74E9-2ABB-417A-9CDA-E1C5F3E85E1E@vt.edu>
Thanks Max. The key is that we need to make alpha small otherwise there is a non-constant density in the energy equation so alpha and g are trading off for a specific reason. I don’t see how we can change g, alpha, and viscosity simultaneously and get the effect we need. It’s probably easier at this point to create a material that only uses dynamic pressure rather than continue the gymnastics to shoehorn the existing formulation into the case we are trying to solve.
> On Apr 25, 2017, at 12:59 PM, Max Rudolph wrote:
>
> One other idea - you could try scaling the viscosity with the magnitude of the gravity for these calculations. because the hydrostatic pressure is rho*g*d and the dimensionless dynamic pressure scales with 1/eta, if you increase g an order of magnitude, you should be able to maintain constant ratio between static and dynamic pressures by increasing the viscosity an order of magnitude.
>
> On Mon, Apr 24, 2017 at 11:10 AM, Juliane Dannberg > wrote:
> As far as I know we always use the full pressure (unless one chooses the density in the material model to only be the density deviations from the reference profile, in which case the computed pressure would be the dynamic pressure), and looking at the manual, I agree that we could document this better.
> Rene, Timo, please correct me if I am wrong.
>
> @Max: sorry, didn't see your email, we basically had the same idea you posted.
>
> On 04/24/2017 11:32 AM, Scott King wrote:
>>
>> Julia;
>>
>> I had thought that the new business formulation was only using only the dynamic pressure. Is that not the case? I had a hard time figuring that out from the manual.
>>
>> Best,
>>
>> Scott
>>
>>> On Apr 24, 2017, at 12:39 PM, Juliane Dannberg > wrote:
>>>
>>> Timo, Shangxin,
>>> if you have the model running already, another thing to check might be the ratio between the dynamic and static pressure (it is something that came up in a discussion between Rene, Wolfgang and me, and Rene mentioned that the problem we are talking about has quite a small Rayleigh number, so small dynamic pressures). This ratio is changed when scaling alpha vs. gravity, and if it is too small, it might not even be the solver tolerance that is the problem.
>>> Juliane
>>>
>>> On 04/24/2017 09:09 AM, Timo Heister wrote:
>>>> Shangxin,
>>>>
>>>> I looked a little bit more into your example. Some observations:
>>>> 1. You are using the "simple" model for a nondimensional computation.
>>>> It is probably a better idea to use "nondimensional" instead. I will
>>>> try to see if that makes a difference.
>>>> 2. I haven't quite figured out how to quantify "don't make gravity too
>>>> large", but as I expected, the difference increases the larger the
>>>> gravity is. I think our pressure scaling or linear solver tolerance
>>>> needs to take the size of the gravity into account but it currently
>>>> doesn't.
>>>> 3. A finer solver tolerance is likely important (see 2).
>>>> 4. It looks like the buoyancy term can not be resolved adequately on
>>>> the current mesh (if you plot T or rho, you can see that it jumps from
>>>> 0 to 0.5 within a single cell. See attached.
>>>> 5. If you plot RMS over time, you can see that the timesteps are quite
>>>> large (especially for alpha>0.1). I am not sure if this is connected
>>>> to 4) or not.
>>>>
>>>> Anyways, I will get back to you when I figure out more.
>>>>
>>>> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu wrote:
>>>>> Hi Timo, John, and others,
>>>>>
>>>>> I quickly made several new tests using the new Boussinesq approximation
>>>>> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
>>>>> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
>>>>> CFL number don't help a lot. There is still order-of-magnitude difference of
>>>>> the velocity statistics and time step size between g 7000&alpha 1, g
>>>>> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
>>>>> refinement 4 to see but global refinement 3 with quadratic element may be
>>>>> already enough resolution. Something weird is still happening.
>>>>>
>>>>> Best,
>>>>> Shangxin
>>>>>
>>>>>
>>>>> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff
>>>>> wrote:
>>>>>> Hi Scott, Hi Shangxin,
>>>>>>
>>>>>> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
>>>>>> is certainly more reasonable, but it still might be worth it to try a value
>>>>>> like 0.1 just to make sure nothing odd is going on there.
>>>>>>
>>>>>> Scott - Thanks for the explanation and definitely interested to see what
>>>>>> solution(s) arise.
>>>>>>
>>>>>> Cheers,
>>>>>> John
>>>>>>
>>>>>> *************************************************
>>>>>> John Naliboff
>>>>>> Assistant Project Scientist, CIG
>>>>>> Earth & Planetary Sciences Dept., UC Davis
>>>>>>
>>>>>> On 04/21/2017 04:23 AM, Scott King wrote:
>>>>>>
>>>>>>
>>>>>> John;
>>>>>>
>>>>>> See the section of the Aspect manual for the 2D incompressible Cartesian
>>>>>> benchmarks. This is a trick used to try to circumvent the density term in
>>>>>> the time derivative of the temperature equation, which is not constant (as
>>>>>> it would be for Bousinessq). The small alpha makes that term nearly
>>>>>> constant while keeping the buoyancy term as Ra. In 2D the manual shows this
>>>>>> works up to Ra=7000*1e10, alpha-1e-10. Trying to use this for 3D spherical
>>>>>> it breaks around 10^3/1e-3. It suggests either the 3D spherical matrix is
>>>>>> more illconditioned to begin with or something about the iterations and
>>>>>> tolerance levels for the solver is different between 2D and 3D. Or it
>>>>>> needs to be different between the two and isn’t.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 20, 2017, at 12:16 PM, John Naliboff
>>>>>> wrote:
>>>>>>
>>>>>> On a side note, I personally have trouble interpreting results that vary
>>>>>> the Ra number by orders of magnitude through terms other than the viscosity.
>>>>>> While this is certainly an interesting numerical case study, is there a
>>>>>> different motivation for varying the Ra number through terms other than the
>>>>>> viscosity?
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Aspect-devel mailing list
>>>> Aspect-devel at geodynamics.org
>>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>>> _______________________________________________
>>> Aspect-devel mailing list
>>> Aspect-devel at geodynamics.org
>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>>
>>
>> _______________________________________________
>> Aspect-devel mailing list
>> Aspect-devel at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rene.gassmoeller at mailbox.org Tue Apr 25 11:00:15 2017
From: rene.gassmoeller at mailbox.org (Rene Gassmoeller)
Date: Tue, 25 Apr 2017 18:00:15 -0000
Subject: [aspect-devel] ASPECT Newsletter #28
Message-ID: <20170425175804.030A3AC21E8@geodynamics.org>
Hello everyone!
This is ASPECT newsletter #28.
It automatically reports recently merged features and discussions about the ASPECT mantle convection code.
## Below you find a list of recently proposed or merged features:
#1456: [WIP] require deal.II 8.5.0 (proposed by tjhei) https://github.com/geodynamics/aspect/pull/1456
#1453: Better document a couple of parameters. (proposed by bangerth; merged) https://github.com/geodynamics/aspect/pull/1453
#1452: Rename tracers to particles (proposed by gassmoeller) https://github.com/geodynamics/aspect/pull/1452
#1451: Rename initial conditions plugins, namespaces, subsections (proposed by gassmoeller) https://github.com/geodynamics/aspect/pull/1451
#1450: Fix indent script (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1450
#1449: Rename boundary condition plugins, namespaces, functions (proposed by gassmoeller) https://github.com/geodynamics/aspect/pull/1449
#1447: Initial composition list (proposed by gassmoeller) https://github.com/geodynamics/aspect/pull/1447
#1446: Move buiter_et_al_2008_jgr benchmark into correct folder (proposed by naliboff; merged) https://github.com/geodynamics/aspect/pull/1446
#1444: update docker image to deal 8.5.0 (proposed by tjhei; merged) https://github.com/geodynamics/aspect/pull/1444
#1442: Remove changes.h, replace by bits (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1442
#1440: Rename benchmark folder (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1440
#1439: fix test output (proposed by tjhei; merged) https://github.com/geodynamics/aspect/pull/1439
#1438: Rename benchmark folder (proposed by gassmoeller) https://github.com/geodynamics/aspect/pull/1438
#1437: Remove empty subsections (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1437
#1436: Postprocess nonlinear iterations (proposed by jdannberg; merged) https://github.com/geodynamics/aspect/pull/1436
#1435: Remove boundary objects from spherical shell (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1435
#1434: update reference for user manual (proposed by tjhei; merged) https://github.com/geodynamics/aspect/pull/1434
#1433: make screen output of nonlinear solver schemes more consistent (proposed by jdannberg; merged) https://github.com/geodynamics/aspect/pull/1433
#1418: Modify strain weakening feature of visco_plastic material model and add a related benchmark and particle property (proposed by naliboff; merged) https://github.com/geodynamics/aspect/pull/1418
#1417: Fix bug in polygon_contains_point function (proposed by MFraters; merged) https://github.com/geodynamics/aspect/pull/1417
#1403: Add monotone spline options to utilties. (proposed by MFraters; merged) https://github.com/geodynamics/aspect/pull/1403
#1187: Add topography to coarse mesh box (proposed by anne-glerum; merged) https://github.com/geodynamics/aspect/pull/1187
#1038: List of initial conditions (proposed by gassmoeller; merged) https://github.com/geodynamics/aspect/pull/1038
## And this is a list of recently opened or closed discussions:
#1455: [post-2.0] Remove deprecated input parameters (opened) https://github.com/geodynamics/aspect/issues/1455
#1454: Fix a misplaced bar on the manual title page (opened) https://github.com/geodynamics/aspect/issues/1454
#1448: Require deal.II 8.5.0 (opened) https://github.com/geodynamics/aspect/issues/1448
#1445: One benchmark "buiter_et_al_2008" was not moved to the new "benchmarks" folder (opened and closed) https://github.com/geodynamics/aspect/issues/1445
#1443: A possible tiny bug in the temperature field initialization of the 3D spherical shell? (opened) https://github.com/geodynamics/aspect/issues/1443
#1441: Copy deal.II's workflow for changes.h (opened and closed) https://github.com/geodynamics/aspect/issues/1441
#1415: Some subsections in the parameter file do not have any parameters in them (closed) https://github.com/geodynamics/aspect/issues/1415
#1358: [Post 1.5] Rename top-level dir from 'benchmark' to 'benchmarks' (closed) https://github.com/geodynamics/aspect/issues/1358
#1048: doi's for plugins (closed) https://github.com/geodynamics/aspect/issues/1048
#927: Allow adding multiple initial conditions (closed) https://github.com/geodynamics/aspect/issues/927
#798: Move WGS 84 functions into utilities (closed) https://github.com/geodynamics/aspect/issues/798
#651: Artifacts in dynamic topography postprocessor (closed) https://github.com/geodynamics/aspect/issues/651
#300: Visualize nonlinear iterations (closed) https://github.com/geodynamics/aspect/issues/300
A list of all major changes since the last release can be found at https://aspect.dealii.org/doc/doxygen/changes_current.html.
Thanks for being part of the community!
Let us know about questions, problems, bugs or just share your experience by writing to aspect-devel at geodynamics.org, or by opening issues or pull requests at https://www.github.com/geodynamics/aspect.
Additional information can be found at https://aspect.dealii.org/, and https://geodynamics.org/cig/software/aspect/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From f_orellana at berkeley.edu Tue Apr 25 09:57:37 2017
From: f_orellana at berkeley.edu (FELIPE ORELLANA ROVIROSA)
Date: Tue, 25 Apr 2017 09:57:37 -0700
Subject: [aspect-devel] New UK User
In-Reply-To:
References:
Message-ID:
Hi Heron,
I am not in the UK, but welcome anyways.
In my experience, the most difficult parts are installing Trilinos
and deal.ii (which may be already in place on your clusters). Aspect is
large when installing, but not too much. You will perhaps want to recompile
it several times in the future regarding the different operation modes it
has: debug and optimized.
good luck,
Felipe
On Tue, Apr 25, 2017 at 8:05 AM, HERON, PHILIP J. <
philip.j.heron at durham.ac.uk> wrote:
> Hello all,
>
> I just thought I would send a quick message to introduce myself - I'm Phil
> working at Durham University. I am looking to use ASPECT for a few
> different projects over the next few years (at least), and try and set up
> Durham University as a hub of ASPECT users (teaching and academic studies).
>
> I will be installing ASPECT on a number of clusters over the coming weeks
> and I was wondering whether any other UK users have already done so - in
> particular for ARCHER or N8?
>
> When I install ASPECT on these clusters I will make their process
> available if has any difficult points!
>
> Talk to you all soon!
>
> Phil
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rene.gassmoeller at mailbox.org Tue Apr 25 13:27:55 2017
From: rene.gassmoeller at mailbox.org (Rene Gassmoeller)
Date: Tue, 25 Apr 2017 14:27:55 -0600
Subject: [aspect-devel] New UK User
In-Reply-To:
References:
Message-ID: <50b32157-b66a-578e-62b3-5310573380b4@mailbox.org>
Hi Phil,
welcome to the community! Yes installing ASPECT on clusters can be a bit
tricky, because they often have pretty particular setups for MPI and
math libraries. Getting help from the local IT people usually helps a
lot in these cases, but we can of course also offer help.
You probably saw the installation instructions in the manual, but I do
not know if you had a look into aspect/doc/install already, there is an
example installation script for the STAMPEDE cluster in Texas. From
taking a look at the ARCHER website it looks like a Cray-XC cluster. I
have some experience installing ASPECT on those (one at the HLRN in
Berlin, and the Lonestar also in Texas) and I will send you my notes in
a separate mail (they are a bit messy). Of course the software setup can
be pretty different between those systems so I can not guarantee it
works out of the box.
Let us know how it goes,
Rene
On 04/25/2017 09:05 AM, HERON, PHILIP J. wrote:
> Hello all,
>
> I just thought I would send a quick message to introduce myself - I'm
> Phil working at Durham University. I am looking to use ASPECT for a
> few different projects over the next few years (at least), and try and
> set up Durham University as a hub of ASPECT users (teaching and
> academic studies).
>
> I will be installing ASPECT on a number of clusters over the coming
> weeks and I was wondering whether any other UK users have already done
> so - in particular for ARCHER or N8?
>
> When I install ASPECT on these clusters I will make their process
> available if has any difficult points!
>
> Talk to you all soon!
>
> Phil
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jbnaliboff at ucdavis.edu Tue Apr 25 13:44:54 2017
From: jbnaliboff at ucdavis.edu (John Naliboff)
Date: Tue, 25 Apr 2017 13:44:54 -0700
Subject: [aspect-devel] New UK User
In-Reply-To: <50b32157-b66a-578e-62b3-5310573380b4@mailbox.org>
References:
<50b32157-b66a-578e-62b3-5310573380b4@mailbox.org>
Message-ID:
Hi Phil,
Indeed, welcome to the community! Echoing Rene's message below, the
installations on the clusters can at times be a bit tricky. If you do
have any issues, please email this list and more likely than not someone
will have encountered the problem before or have a quick suggestion.
If a number of people are likely to use ASPECT on certain clusters, it
might be worth having the IT folks install Trilinos and p4est as
system-wide libraries. From there, individual users can install there
own versions deal.II and ASPECT, although deal.II 8.5 installed
system-wide would likely be useful as well for most people initially.
You are probably aware of this already, but it is best to stick with the
GNU compilers.
Thanks for taking the initiative to get these packages installed on the
UK clusters! I know of few researchers at UCL and Imperial who likely be
interested in running ASPECT models on the national clusters at some
point in the next few years.
Cheers,
John
*************************************************
John Naliboff
Assistant Project Scientist, CIG
Earth & Planetary Sciences Dept., UC Davis
On 04/25/2017 01:27 PM, Rene Gassmoeller wrote:
>
> Hi Phil,
>
> welcome to the community! Yes installing ASPECT on clusters can be a
> bit tricky, because they often have pretty particular setups for MPI
> and math libraries. Getting help from the local IT people usually
> helps a lot in these cases, but we can of course also offer help.
>
> You probably saw the installation instructions in the manual, but I do
> not know if you had a look into aspect/doc/install already, there is
> an example installation script for the STAMPEDE cluster in Texas. From
> taking a look at the ARCHER website it looks like a Cray-XC cluster. I
> have some experience installing ASPECT on those (one at the HLRN in
> Berlin, and the Lonestar also in Texas) and I will send you my notes
> in a separate mail (they are a bit messy). Of course the software
> setup can be pretty different between those systems so I can not
> guarantee it works out of the box.
>
> Let us know how it goes,
>
> Rene
>
>
>
> On 04/25/2017 09:05 AM, HERON, PHILIP J. wrote:
>> Hello all,
>>
>> I just thought I would send a quick message to introduce myself - I'm
>> Phil working at Durham University. I am looking to use ASPECT for a
>> few different projects over the next few years (at least), and try
>> and set up Durham University as a hub of ASPECT users (teaching and
>> academic studies).
>>
>> I will be installing ASPECT on a number of clusters over the coming
>> weeks and I was wondering whether any other UK users have already
>> done so - in particular for ARCHER or N8?
>>
>> When I install ASPECT on these clusters I will make their process
>> available if has any difficult points!
>>
>> Talk to you all soon!
>>
>> Phil
>>
>>
>> _______________________________________________
>> Aspect-devel mailing list
>> Aspect-devel at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sxliu at vt.edu Wed Apr 26 12:32:20 2017
From: sxliu at vt.edu (Shangxin Liu)
Date: Wed, 26 Apr 2017 15:32:20 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep sizes
of the same Ra
Message-ID:
Hi Wolfgang and Juliane,
Thanks for clarifying. I have one more question/concern to confirm with
you. If I use a material model in which the density has no constant
term and only contains perturbation term to make the full pressure equals
the dynamic pressure, what will the density term in the temperature
equation be? If Boussinesq approximation formulation is used, I can see
that it should be the input reference density of the material model, yes?
However, if the compressible formulation is used, what will it be since the
input density in the material model is actually only the density
perturbation?
Best,
Shangxin
> On 04/24/2017 12:10 PM, Juliane Dannberg wrote:
> > As far as I know we always use the full pressure (unless one chooses the
> > density in the material model to only be the density deviations from the
> > reference profile, in which case the computed pressure would be the
> dynamic
> > pressure), and looking at the manual, I agree that we could document
> this better.
>
> Yes, we use the full pressure. The full pressure, however, equals the
> dynamic
> pressure if you use a material model in which the density has no constant
> term
> and only contains the thermal expansion term, i.e.,
> rho(T) = -\alpha T
> There is a hydrostatic component of the pressure if the density is given as
> rho(T) = rho_0 - \alpha T
>
> Which of the two you use is up to you.
>
> Best
> W.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From heister at clemson.edu Wed Apr 26 17:48:49 2017
From: heister at clemson.edu (Timo Heister)
Date: Wed, 26 Apr 2017 20:48:49 -0400
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID:
Shganxin,
if you use BA as the formulation, the density in the temperature comes
from the "adiabatic conditions" module. The density from the material
model is only used in the buoyancy term. See the section on
"formulation" in the manual.
On Wed, Apr 26, 2017 at 3:32 PM, Shangxin Liu wrote:
> Hi Wolfgang and Juliane,
>
> Thanks for clarifying. I have one more question/concern to confirm with you.
> If I use a material model in which the density has no constant term and only
> contains perturbation term to make the full pressure equals the dynamic
> pressure, what will the density term in the temperature equation be? If
> Boussinesq approximation formulation is used, I can see that it should be
> the input reference density of the material model, yes? However, if the
> compressible formulation is used, what will it be since the input density in
> the material model is actually only the density perturbation?
>
> Best,
> Shangxin
>
>
>>
>> On 04/24/2017 12:10 PM, Juliane Dannberg wrote:
>> > As far as I know we always use the full pressure (unless one chooses the
>> > density in the material model to only be the density deviations from the
>> > reference profile, in which case the computed pressure would be the
>> > dynamic
>> > pressure), and looking at the manual, I agree that we could document
>> > this better.
>>
>> Yes, we use the full pressure. The full pressure, however, equals the
>> dynamic
>> pressure if you use a material model in which the density has no constant
>> term
>> and only contains the thermal expansion term, i.e.,
>> rho(T) = -\alpha T
>> There is a hydrostatic component of the pressure if the density is given
>> as
>> rho(T) = rho_0 - \alpha T
>>
>> Which of the two you use is up to you.
>>
>> Best
>> W.
>>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw&m=Dh24C9ytkp-m1kQKFicR_XZxpkRuyYgvlTuoEi-CEJU&s=nn-8UqWaytfspMX-JMbzyTizqWKgXIUTYZEkLMbfErU&e=
--
Timo Heister
http://www.math.clemson.edu/~heister/
From dannberg at gfz-potsdam.de Wed Apr 26 20:56:35 2017
From: dannberg at gfz-potsdam.de (Juliane Dannberg)
Date: Wed, 26 Apr 2017 21:56:35 -0600
Subject: [aspect-devel] Far different velocity magnitudes & timestep
sizes of the same Ra
In-Reply-To:
References:
Message-ID: <85df0a65-cf53-879a-9965-578df79409d0@gfz-potsdam.de>
Also, if you want to solve for only the dynamic pressure (and hence have
only density
perturbations without the reference profile in the density in the
material model) and
run a compressible model, you can use the ALA formulation to do that. If
you want to
keep using ASPECT's "original" formulation, you can not just use a
density that only
contains the perturbations, because in this case this same density would
be used in the
temperature equations (so among other problems, the program would crash
because
the density would be negative in some parts of the domain).
This means you basically have to decide if you want to use BA/ALA/TALA
and then
you can also just solve for the dynamic pressure, or use our original
formulation with
the full pressure.
On 04/26/2017 06:48 PM, Timo Heister wrote:
> Shganxin,
>
> if you use BA as the formulation, the density in the temperature comes
> from the "adiabatic conditions" module. The density from the material
> model is only used in the buoyancy term. See the section on
> "formulation" in the manual.
>
> On Wed, Apr 26, 2017 at 3:32 PM, Shangxin Liu wrote:
>> Hi Wolfgang and Juliane,
>>
>> Thanks for clarifying. I have one more question/concern to confirm with you.
>> If I use a material model in which the density has no constant term and only
>> contains perturbation term to make the full pressure equals the dynamic
>> pressure, what will the density term in the temperature equation be? If
>> Boussinesq approximation formulation is used, I can see that it should be
>> the input reference density of the material model, yes? However, if the
>> compressible formulation is used, what will it be since the input density in
>> the material model is actually only the density perturbation?
>>
>> Best,
>> Shangxin
>>
>>
>>> On 04/24/2017 12:10 PM, Juliane Dannberg wrote:
>>>> As far as I know we always use the full pressure (unless one chooses the
>>>> density in the material model to only be the density deviations from the
>>>> reference profile, in which case the computed pressure would be the
>>>> dynamic
>>>> pressure), and looking at the manual, I agree that we could document
>>>> this better.
>>> Yes, we use the full pressure. The full pressure, however, equals the
>>> dynamic
>>> pressure if you use a material model in which the density has no constant
>>> term
>>> and only contains the thermal expansion term, i.e.,
>>> rho(T) = -\alpha T
>>> There is a hydrostatic component of the pressure if the density is given
>>> as
>>> rho(T) = rho_0 - \alpha T
>>>
>>> Which of the two you use is up to you.
>>>
>>> Best
>>> W.
>>>
>> _______________________________________________
>> Aspect-devel mailing list
>> Aspect-devel at geodynamics.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.geodynamics.org_cgi-2Dbin_mailman_listinfo_aspect-2Ddevel&d=DwIGaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw&m=Dh24C9ytkp-m1kQKFicR_XZxpkRuyYgvlTuoEi-CEJU&s=nn-8UqWaytfspMX-JMbzyTizqWKgXIUTYZEkLMbfErU&e=
>
>
From rene.gassmoeller at mailbox.org Fri Apr 28 20:22:55 2017
From: rene.gassmoeller at mailbox.org (Rene Gassmoeller)
Date: Fri, 28 Apr 2017 21:22:55 -0600
Subject: [aspect-devel] Development update: deal.II 8.5.0 and ASPECT
2.0.0.pre
Message-ID: <7225c501-7db3-805e-197b-61ec12a2a754@mailbox.org>
Hi all,
it has been a busy week in ASPECT's development and with the hackathon
approaching it is likely to stay that way at least for the next weeks.
Therefore I have switched the newsletter frequency to weekly until the
development cools down again (probably end of May). Nevertheless, there
have been two developments this week I would like to discuss and explain
a bit, since they are likely to affect all of us in some way.
1. With merging pull request #1456 (thanks Timo!) the development
version of ASPECT now requires deal.II 8.5.0 or newer, and the reference
test results are also created with that version. This will allow us to
clean some ugly code and use new features of deal.II during the
hackathon, and will also speed up some computations in spherical
geometries and all parallel models using particles. If you have used an
older version of deal.II before, your next upgrade of ASPECT will likely
take a bit more effort than usual, more so because of point 2.
2. As discussed at the last hackathon, ASPECT has developed a few
unfortunate naming conventions and other intricacies that are impossible
to fix in a compatible way. As we usually strive to keep plugins and
parameter files compatible to newer ASPECT version for as long as
possible, we have lived with some of those decisions for several years
now. However, the number of things we would have done differently if we
had the chance to change them grew over time. Therefore in a discussion
with all participants at the last hackathon we decided to make a major
version jump after ASPECT 1.5.0, consciously and sensibly breaking
existing files and plugins, and aim for a release of ASPECT 2.0.0 later
this year that again is stable for the years to come.
Within this week the first few of these breaking changes have been
implemented and will require updates to parameter files and source
plugins (boo!). However, in order to make the upgrade process as easy as
possible we introduced two conversion scripts in the doc/ directory that
will update most (if not all) files without manual work. Their usage is
explained in their comment sections, but to explain the 'most' in the
previous sentence: The script are simple 'find-and-replace' scripts, and
we can not guess your naming conventions for variables. If I e.g. had a
plugin with a private variable called 'tracer' that one might end up as
'particle' after the conversion, so please keep a backup of your files
and check the changes the scripts make for correctness. On the plus side
all of the code and parameter files within the official ASPECT
repository were converted with these scripts successfully, so we are
reasonably sure they work well.
As ASPECT 2.0.0 is far from out yet (current plans would be within the
last quarter of this year), there might be more significant changes
coming in, although we try to keep their number as small as possible and
merge them in batches to avoid frequent incompatible changes. Still, if
you have important deadlines looming, or simply do not need the newest
features, you might want to consider updating ASPECT only if necessary
in the next months, and be aware that it might involve a bit of work,
until ASPECT 2.0.0 is released.
The progress in major goals toward 2.0.0 is tracked in the github issue
#1090, and of course every major change will be listed on the website
http://aspect.dealii.org/doc/doxygen/changes_current.html. Please report
cases in which the update leads to problems on the mailing list so we
can see how to ease the transition.
Thanks for reading this wall of text,
Have a nice weekend,
Rene
--
Rene Gassmoeller
http://www.math.colostate.edu/~gassmoel/