VisualSPARK |
The Simulation Problem Analysis and Research Kernel (SPARK) is an
equation-based, object-oriented simulation
environment for constructing and running models of complex systems.
|
Software
Download VisualSPARK 2.01 (End-User License Required)
Documentation
New Features, bug fixes and changes
VisualSPARK Users Guide
SPARK Reference Manual
SPARK Atomic Class API pdf 
html 
SPARK Problem Driver API
pdf 
html 
Frequently Asked Questions (FAQ)
How to port atomic classes from SPARK 1.x to SPARK 2.x
All Technical Reports
SPARK Overview
Introduction
Describing Problems for SPARK Solution
User Interfaces
Tools for Writing SPARK Classes
Introduction
Simulation of a physical system requires development of a mathematical
model, usually composed of differential and/or algebraic equations.
These equations then must be solved at each point in time over some
interval of interest. The Simulation Problem Analysis and Research
Kernel (SPARK) is an object-oriented software system to perform such
simulations. By "object-oriented" we mean that components and
subsystems
are modeled as objects that can be interconnected to specify the model
of the entire system. Often the same component and subsystem models
can be used in many different system models, saving the work of
redevelopment.
SPARK may be thought of as a general differential/algebraic equation solver. This means that it can be used to solve any kind of mathematical problem described in terms of a set of differential and algebraic equations. The term continuous systems is often used to describe this class of problems. Typical examples include building heating and cooling systems, heat transfer analysis, and biological processes. Models are expressed as systems of interconnected objects, either created by the user or selected from a library. An HVAC tool kit library comes with SPARK.
Since SPARK objects are equation-based rather than algorithmic, they are input/output free. That is, there is no assumed directionality, so that a single model can be used to solve problems with various specified inputs. SPARK is unique in its ability to apply graph theory to automatically determine efficient solution strategies, often resulting in significant speed advantages as well as modeling convenience.
Describing Problems for SPARK Solution
Naturally, model descriptions must be expressed in some
formal way. SPARK class models are described in a textual
language that is similar to other simulation programming languages
except that it is non-procedural. That is, it is not necessary to
order the equations, nor to express them as assignment statements. This
property derives from the input/output free manner in which the object
classes are defined, and from the use of mathematical graphs
to find an appropriate solution sequence.
In SPARK, the smallest programming element is a class consisting of an
individual equation, called an atomic class. Then,
macro classes
bring together several atomic classes (and possibly other macro
classes) into a higher level unit. Problem models are similarly
described, using the atomic and macro classes, and placed in a problem
specification file. When the problem is processed by SPARK, the problem
specification file is converted to a program, which gets compiled,
linked and executed to solve the problem for given boundary
conditions.
User Interfaces
Tools for Writing SPARK Classes
To simplify these tasks, VisualSPARK comes with a symbolic manipulation tool
called SPARKSYM. With this tool the user need specify only the atomic class
equation, from
which all necessary inverses and supporting C++ functions are generated
automatically through symbolic manipulation.
Describing a problem for SPARK solution begins by breaking it down in
an object-oriented way. This means thinking about
the problem in terms of its components, with each component to be
represented by a SPARK object. Then, a model is developed for each
component not already present in a SPARK library. Since there may be
several components of the same kind, SPARK object models, i.e.,
equations or groups of equations, are defined in a generic manner,
called classes. Classes serve as templates for
creating any number of
like objects that may be needed in a problem. The problem model is
then completed by linking objects together, thus indicating how
they interact, and specifying data values that specialize the model to
represent the actual problem to be solved.
The user interface provided by VisualSPARK
allows for the creation of text-based classes and problems using the
SPARK language directly, as well as for problem execution. Post
processing for visualization of results is supported.
While specifying problems in the SPARK language using existing classes
is relatively easy, writing SPARK class models can be tedious. One
necessary task is deriving the inverses for the class equation, i.e.,
closed-form solutions for several or all variables that occur in the
equation. The labor of this task is multiplied in certain kinds of
problems, such as those described in terms of partial differential
equations. Such equations have to first be expressed as sets of
ordinary differential equations, replicated many times with slight
variations.