Yes. See the sections on
Parallel computation and
Distributed Meshes for more information
I do essentially all development work on various versions of SuSe Linux, using the GCC and Intel compilers. I use the MPICH implementation of MPI.
Sundance is known to run on Linux (using GCC 3.3, 3.4 and Intel compilers), Mac OSX, and Cygwin.
In general, it should run on any reasonable Unix-like environment with an ANSI C++ compiler and a good implementation of the STL. A general rule is that if you can make Trilinos and the STL work on your platform, then Sundance will present no problem.
Yes, but it must be built under Cygwin.
Unless you work at Sandia National Laboratories or are one of my external collaborators on algorithmic research projects, I will probably not have time to do so. I am happy to advise you on doing your own port, however. A general rule is that if you can make Trilinos and the STL work on your platform, then
Sundance will present no problem.
The history of the name is that it is the title of a short story I happened to read one evening while taking a break from writing some of the initial classes for my as-yet-anonymous symbolic PDE simulator. The tradition at Sandia is to give codes names with a flavor of the American Southwest, and while reading the story it occurred to me that
Sundance was an appropriate choice of name for this code. Other than that, it has no particular significance. I have been unable to reverse engineer a useful acronym out of it.
Because I am extremely lazy and don't want to spend more than a day's time or more than 100 lines of code to develop a simulator for a new problem. Therefore, I spent several years writing many thousand lines of code to develop a tool to let me be lazy.
As for why Sandia actually paid me to do such a thing: such a flexible code simplifies the use of various advanced algorithms we are developing for solvers and optimizers.
If it's simple, yes, though I may not get to it yesterday. If it's more complex to add, I'll be able to get to it only as time and funding allow.
Probably yes, if your code is flexible enough. The
Sundance symbolic engine is completely independent of the implementation of the mesh, basis functions, fields, and other finite-element issues. The key step for using
Sundance with your favorite finite-element code is to write an object called an evalution mediator (derived from an abstract class called an AbstractEvalMediator) that implements several callback methods for getting values of field variables from your FE code.
If you have a mesh class that is more capable than my BasicSimplicialMesh mesh subtype, then a particularly useful means of interfacing with your code would be to wrap your mesh class in the Sundance MeshBase interface, allowing your mesh to be used in Sundance simulations.
I detest the autotools -- as a developer, I find them extremely cumbersome to work with, and as a user I find them finicky and near-impossible to debug when things go wrong -- but for better or worse they are the
de facto standard for configuring software on Unix-like systems. In particular, they are used by Trilinos. Because
Sundance is built on top of Trilinos, using a common configuration system was a logical choice. My apologies; I don't like it either.
The method of discretization is determined by a number of factors: the choice of weak formulation of a problem, the choice of basis functions for each field, the choice of quadrature rules for integration, and by the choice of stabilization scheme (if any) used.
For example, the Navier-Stokes equations of incompressible fluid mechanics can be written in either pressure-velocity form or vorticity-streamfunction form, each of which leads to different discretization issues. With the pressure-velocity form, a naive choice of basis functions will likely lead to an unstable scheme; a suitable combination of bases for velocity and pressure must be used, or alternatively, the system can be stabilized by adding certain non-physical terms to the equation set.
Sundance allows essentially any choice of weak formulation, and then the choice of basis functions and quadrature rules is limited by the set that has been implemented at this time.
Yes.
Sundance isn't any particular type of simulation code, it is a system of components with which one can create a simulation code. It is thus possible to use
Sundance to write simulators for virtually any kind of PDE for any field of science or engineering. It is possible to use
Sundance components to write static or dynamic, linear or nonlinear, forward or inverse problems.
See the tutorial for examples of different simulators developed in Sundance.
Yes; stabilization terms can be represented by the expression language just like any other term. There are two ways in which stabilization terms differ from the usual terms in weak forms: they include mesh-specific information (usually a cell diameter), and they drop surface terms that arise during integrations by parts. The cell diameter can be represented with a CellDiameterExpr object, and the surface terms are left out implicitly.
The tutorial contains an example of pressure stabilization of the Navier-Stokes equations.
See the section on
Boundary Conditions in the online user's guide.
Not at present, and there are no near-term plans to add this capability. It is often possible to find local approximations to nonlocal BCs.
Nonreflecting boundary conditions are, in general, nonlocal and thus cannot be implemented exactly in
Sundance. There are, however, local approximations to nonreflecting boundary conditions and these can be implemented without difficulty. See, for instance, Jin's book on finite elements for electromagnetics.
Most of my work involves fluid mechanics rather than structural mechanics, so there is at present no capability for identifying regions of contact between two meshes (or two parts of the same mesh) in
Sundance.
Contact is an important problem, and if someone at Sandia wants to use Sundance for optimizing contact simulations, I will be happy to accept funding to add it. However, due to the nature of my own work, I cannot at this time justify the effort to do so.
All of the above.
Sundance is not tied to a particular mesh file format. There is an abstract, extensible interface for
Mesh Readers. To work with your favorite mesh file format, one would write a MeshReader subtype for that format. Such a reader is typically a couple of hundred lines of code, but need be done only once per format. An alternative to writing a
Sundance MeshReader is to find (or write) a translator from your favorite format to one of those currently present in
Sundance.
Currently, MeshReaders have been implemented for the Exodus/NetCDF and Triangle formats.
None, other than trivial meshers for lines and rectangles for use in testing. Third-party meshers such as
Cubit or
Triangle are better than anything I could write, so I have concentrated on reading meshes output from such codes. It is in principle possible to wrap such a mesher and link it into
Sundance, but the configuration headaches that would entail make it not worth the effort. Thus, except for lines and rectangles,
Sundance meshes are always read from files rather than generated at runtime.
The mesh interface supports either, but only simplicial elements have been implemented. There are no immediate plans to do non-simplicial elements.
Not at present. I have plans to add Philippe Pebay's elegant communication-free parallel mesh refinement scheme, but have not yet done so.
Simplicial cells only, in 1, 2, and 3 dimensions.
Currently, Lagrange orders 1 and 2 only. Implementation of more general elements through Robert Kirby's
FIAT code is underway.
Gaussian quadrature on lines, Gauss/Dunavant quadrature on triangles, and Gauss/Xi on tetrahedra. I have implemented the rules for triangles and tets by typing in the numbers from the papers of Dunavant and Xi, so such rules are not available for arbitrary order. If you want to compute, or type in, rules for other orders I will be happy to add them to the code.
Please do, though addition of new basis types would best be done through Robert Kirby's
FIAT code, which is a very general system for generating efficient code for basis evaluation.
Implementation of more general elements through Robert Kirby's
FIAT code is underway.
I have no near-term plans to add non-simplicial meshes.
Sundance uses the Trilinos family of solvers. Many linear solvers are available, both iterative and direct. A number of types of preconditioning are available: in particular domain decomposition and incomplete factorization through Ifpack, and algebraic multilevel through ML. All Trilinos iterative solvers and preconditioners are fully parallel. Direct solvers such as Super LU and UMFPACK are available through the Amesos package; not all Amesos solvers are capable of parallel solves.
For nonlinear solvers, the NOX subpackage of Trilinos is used. Numerous options for solver method, update, line search, and convergence checking are available in NOX.
Most solvers in Trilinos are iterative, but direct solvers are available through the Amesos package.
Multilevel solvers are available to
Sundance through the ML algebraic multilevel package within Trilinos.
Trilinos has a fairly extensive set of iterative solvers and preconditioners to choose from. If your favorite algorithm isn't there, or if you really want to use some particular code you know and trust, it is possible to use the TSFCore interfaces to make your solver work with Trilinos.
There is no high-level support for setting up eigenvalue problems, but it can be done easily nonetheless. The simplest thing to do is to write two "phony" linear problems, one for the mass matrix and one for the stiffness matrix, and then extract the operators from these problems (see below) and feed them to your favorite eigensolver.
Yes, through the
getOperator() and
getRHS() methods of LinearProblem, which return the stiffness matrix and load vector as Trilinos
LinearOperator<double> and
Vector<double> objects. It is then possible to use these high-level objects in a representation-independent solver, or to use the
ptr() method and an appropriate
dynamic_cast to extract a reference-counted pointer to the underlying concrete representation and manipulate as you will.
