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/