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.
VisualSPARK is the SPARK program with a graphical user interface to simplify use of the program.
The "SPARK Overview" provides a brief description of the program. Details on using SPARK are given in the SPARK Reference Manual and VisualSPARK Users Guide, which can be downloaded without registering for the program. SPARK was developed by LBNL and Ayres Sowell Associates with support from the Assistant Secretary for Energy Efficiency and Renewable Energy, Office Of Building Technology Programs of the U.S. Department of Energy; the DOE program manager is Dru Crawley.

The SPARK energy simulation program is neither sponsored by nor affiliated with SPARC International, Inc., and is not based on SPARC architecture. In addition, the SPARK energy simulation program is not associated with the SPARK programming language and toolset from Praxis Critical Systems Limited.


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
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.

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
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.

Tools for Writing SPARK Classes
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.

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.