Dalhousie Geodynamics Group


Department of Oceanography
Dalhousie University
1355 Oxford Street
PO Box 15000
Halifax, NS, B3H 4R2
Canada




SOPALE

Sopale Nested

Processing SOPALE Output

Printing

MOZART

TMM (Thermo-mechanical Model)

old SOPALE documentation

Geodynamics home page

Sopale_nested: Introduction

Sopale Nested is a version of the plane strain ALE finite element software Sopale that solves thermal-mechanical creeping flows in a large-scale (LS) domain in which there is embedded a second small-scale (SS) sub-domain. Both the LS and SS models are defined in the SS domain. The purpose is to achieve a higher resolution solution in the SS domain by solving the problem sequentially for the LS domain and then the SS domain using boundary conditions derived from the LS solution. Therefore, under normal circumstances the finite element grid for the SS domain is defined by increasing the resolution of the LS grid by multiples m and n in the horizontal and vertical directions. This means that the LS grid in the SS domain is the SS grid decimated by m and n.

The two domains share a single cloud of Lagrangian tracking or tracer particles. The initial positions of these particles are nearly coincident with the nodes of the LS finite element grid and at the same density within model regions outside of the LS domain. Additional particles are added such that a x b particles are proportionately positioned within each SS element and the same distribution is extended throughout the LS domain. The density of particles, i.e. ma and nb, is chosen so that the model geometry and properties can be advected through both the LS and SS domains without loss of fidelity.

The initial conditions are defined for the entire model and are then transferred to the LS and SS domains. For each model timestep the problem is first solved iteratively on the LS domain using LS boundary conditions. The velocity and temperature from the LS solution at nodes that correspond to the boundary of the SS domain are linearly interpolated onto the boundary nodes of the SS domain and the problem is solved iteratively for the SS domain using these boundary conditions. The velocity boundary conditions are applied to the bottom and sides of the SS domain. The thermal boundary conditions in SS are applied to the top, bottom, and sides as temperature. Finally, the particle properties are updated and their positions advected using the LS and SS solutions for their respective domains.

For the LS calculation the thermal boundary conditions are temperature, heat flux or a combination, while for the SS calculation only temperature boundary conditions are used.

The LS and SS solutions remain coupled because the decimated SS solution replaces the LS solution in the SS part of the LS domain. In addition, the LS and SS solutions do not drift apart because the model properties are defined and transported by a single Lagrangian cloud of particles.

In the case that part of the boundary of the SS domain is a free surface, this part remains a free surface for the solution of the SS problem. That is, the LS solution is not used to define boundary conditions on the SS free surface. The decimated SS free surface solution replaces the equivalent LS solution.

Particles used to track the evolving properties of the model, for example those used to record pressure-temperature-time paths, are drawn from the Lagrangian cloud. They will therefore record the LS and SS solutions when in these respective domains.

Currently, the position of the SS domain does not move with time. However, there is no restriction on the position of the SS domain for each timestep so that various schemes can be employed to move to SS domain in any desired manner. This nested dual finite element modeling technique is accurate and robust when the LS solution provides accurate boundary conditions for the LS domain. This means that the velocity and temperature fields must be determined with sufficient accuracy by the LS solution in that part of the LS domain that is not covered by the SS domain. Computationally, the problem is solved using separate images of Sopale on two processors. The exchange of information required to implement the steps outlined above is achieved by message passing. In principle, multiple SS domains can be defined within an LS domain and SS domains can be nested within each other like Russian dolls.

Sopale was developed by Philippe Fullsack and augmented by members of the Dalhousie Geodynamics Group. Sopale Nested was developed from Sopale by Douglas Guptill and Bonny Lee, assisted by Chris Beaumont, and in part tested by Jared Butler.

Technical Overview

Sopale Nested is an extension of SOPALE. Where SOPALE is a one process application, Sopale Nested is a one or two process application. When run as a one process application, it is (one of) the current version(s) of SOPALE.

When run as a two process (LS and SS) application, the SS process solves a subset (on the eulerian grid) of the LS problem. This subset is (usually) solved at a finer resolution than the LS. These results are passed back to the LS each time step. This diagram illustrates the communication between the LS and SS copies of Sopale Nested.

The ability to run as a two process application is provided by MPI calls. The use of MPI means that the actual command to run Sopale Nested is different from, and more complicated than, the command to run SOPALE. The command parameters include "number of processes", and it is this parameter which determines whether Sopale Nested runs as a one process or two process application.

In order to preserve backward compatibility with existing input files for SOPALE, the parameters which define the SS grid properties are in a separate input file.

UserOverview

A sequence of slides describing changes during 2011, 2012 exists in odp and ppt format.



This page was last modified on Friday, 02-Nov-2012 10:07:03 ADT
Comments to geodynam at dal dot ca