Project 1
Heated Plate Design Study
Summary
For this project, you are asked to
undertake a design study examining the tradeoffs in implementing a
simulation program. The program simulates the
spreading
of heat through a uniform two-dimensional metal plate. You will prepare
five versions of the program, compare them and write a report
describing what you learned.
Diffusion
Diffusion is a pervasive concept of
scientific computation. Diffusion is the process by which
a substance spreads as a result of its spontaneous movement from a
region
of higher to a region of lower concentration. The archtypical example
of
diffusion is the spreading of the molecules of one gaseous substance
within
another. Other examples include the spreading of heat through a uniform
medium,
the spreading of an organism through an ecology, the spread of disease
through a population, and
the spread of ideas.
Physicists model diffusion
using
Fick's Law:
. Fick's Law state
that the rate of change over time of
the
concentration C of some
substance
is proportional to a constant D (called
the Diffusion Constant) times the second derivative of concentration
with
respect to distance x. In
other words,
concentration of a substance changes faster where the concentration
gradiant
is higher. In the case of Fick's Law, an analytic solution is known
that
takes the following form:
,
where S reflects the initial
conditions, and t is time.
That is, the concentration in space decreases
exponentially in time, taking the form of what is
called a Gaussian
distribution.

In most cases, computers are unable
to solve differential equations.
Instead,
they approximate solutions using a discrete representation called a difference equation. In the case
of a
two-dimensional diffusion, the approximation takes the form of a
rectangular
lattice of points, where each interior point in the lattice is bounded
orthogonally
by four others.
This model leads to a particularly simple simulation of the heated
plate.
Just carve up the plate into a rectilinear grid. Then for each interior
point in
the grid, compute its temperature as the average of its four neighbors.
Assuming
that the edge values provide the initial conditions, then after a
reasonable
number of iterations, the interior values stabilize.
Pseudo Code
The following pseudo code illustrates
one way the computation might be
performed on a square grid of dimension d.
// Create arrays oldPlate and newPlate with linear dimension d
// plus two extra rows and columns to hold edge temperatures
oldPlate = new double[d + 2][d + 2];
newPlate = new double[d + 2][d + 2];
// Initialize the temperatures of the edge values and the plate itself
initialize(oldPlate, top, bot, left, right);
initialize(newPlate, top, bot, left, right);
// Loop until exit criteria are met, updating each newPlate cell from the
// average temperatures of the corresponding neighbors in oldPlate
while (! done()) {
for (int i = 1; i <= d; i++) {
for (int j = 1; j <= d; j++) {
// Compute lattice point temperature as average of neighbors
newPlate[i][j] = (oldPlate[i + 1][j] + oldPlate[i - 1][j] +
oldPlate[i][j + 1] + oldPlate[i][j - 1]) / 4.0;
}
}
// Swap the plates and continue
swap(oldPlate, newPlate);
}
Non-Functional Considerations
Software design problems are
dominated by tradeoffs among non-functional constraints. For this
problem, we will examine the following concerns:
- Performance:
Scientific simulations, such as weather prediction, are
performed on massive grids. The finer the grid spacing, the more
accurate are the predictions. But with massive grids, performance
becomes the
dominant quality factor
- Precision:
With any scientific measurement, whether empirical or
simulated, the number of significant digits must be kept in mind.
Computers and programming languages provide built-in data types and
libraries that vary in their computational precision; for example, int, long, float, and double. Moreover, iterative algorithms, such as
the one above, provide increasing precision the greater the number of
iterations undertaken, until platform issues, such as round-off error,
intrude
- Evolvability: Successful program
change over time as new features are added. Consequently, there is
value in designing general solutions that go beyond initial requirement
in anticipation of subsequent enhancements
- Usability: Simulations producing
large amounts of data may require accompanying visualizations to convey
their results. Visualizations have to be carefully designed to pay
appropriate attention to factors such as color, update rate, font, etc.
On
the input side, modeling complex scientific phenomena may require
extensive parameterization leading to complex configuration
controls in the user interface
Designing a satisficing solution
requires trading these factors off against
each other. For example, increased precision may degrade performance.
It is the designer's job to determine the appropriate mix that will
best
satisfy the customer. Determining this mix may require the designer
to build multiple prototypes and compare them. Doing this
systematically
is called conducting a design study.
Deliverables
This project has three deliverables:
a
series of programs, a description of the programs' designs and a
design-study report.
The
programs each perform a heated-plate simulation using different design
approaches;
the description conveys the design and the choices it implements; and
the report compares the approaches taken.
Programs
You should prepare five programs.
The first four should produce textual output; the fifth should have a
graphical user interface (GUI). Each program should be contained in its
own package according to the names given in parentheses below. (The naming convention is the
following: the first letter 't' or 'g' indicates whether a textual or graphical interface is
provided. The second letter 'p' or 'w' indicates whether the data type
used to hold temperature values is primitive or wrapped. The third letter
'd' or 'f' indicated whether double
precision or single precision floating
point computations are provided. The fourth letter 'a' of 'o' indicates
whether array
indexing or object
references are used to access neighboring elements. The last two
letters denote that a heating of plate is being simulated. For the
fifth program, the letters 'all' are interpolated to indicate that the
interface is capable of invoking multiple different simulations.)
- Implement the simple algorithm
described above where all
computations
are performed in double precision using a two-dimensional array of doubles
to represent the plate (tpdahp)
- Implement the same algorithm
using floating point computations on
an
array of floats (tpfahp).
- Implement the same algorithm
using floating point computations on
an
array of Floats (twfahp).
- Implement the algorithm with
each lattice point representing an
object
that communicates with its four neighbors. That is, object references
instead of array indices are used to access neighbors. Use doubles to hold temperature
values (tpdohp).
- Implement a GUI version that
enables
the user to execute any of the four previous versions and see a
visualization of the results (gallhp).
You are welcome but not required to
implement and study the other four variants (twdahp,
tpfohp,
twdohp,
twfohp).
It is tempting to implement the first
four programs above as a single executable. Because you will need to
measure lines of code and byte code size for each variant, you should
avoid this temptation. However, when you produce the fifth
program, you must not only incorporate the first four programs, but you
should make every effort to compactly combine them using good
object-oriented design techniques such as inheritance.
Your programs
should be written in
Java, as applications not as
applets. Compiling
them should not require any compiler options to be set and should not
require
any non-standard libraries. Program build should require invoking javac without any arguments. Each of the programs should conform
to the protocol description
below.
Program invocation (for Java) consists of program name followed by
arguments.
First Four Programs
Invocation: Invocation of the
programs should
take the form
java
<packageName>.Demo -d
# -l # -r # -t
# -b #
packageName
is
one of the four alternatives given
above: tpdahp, tpfahp, twfahp, tpdohp.
The
-d flag
indicates
that the next argument is the dimension of the square lattice (number
of rows
and
columns). It is a positive integer value greater than zero. The
-l,
-r, -t, and
-b options
respectively denote the edge temperatures for the left, right,
top,
and bottom edges. Their values are any integer between zero and one
hundred, inclusive. The Demo class
should contain only enough code (e.g. main
method) to start up the program and process the command line
arguments. All other code for each program should be placed in
separate classes
Output: The output of the program
is printed onto the standard output as a table
of temperature values, given to
two
decimal points of precision, for the lattice points. The table should
be
output one row per line; do not include the edge
values in the output table.
Fifth Program
The fifth program you are asked to
build adds a graphical user
interface (GUI)
to the heated plate simulation. It should be invoked with the command
java
gallhp.Demo. Whereas the
specifications of the first
four
programs are tightly constrained, you are free to design and build
whatever
GUI you feel satisfies the following objectives:
- It should be easy to use
- It should graphically depict the underlying physical phenomenon
using the
standard library API
- It should be structured in such a way that any of the four
computational
approachs you built in the first four programs can be invoked
That is, you should build a GUI that
allows a user to specify a
simulation
and display the results. The display can be animated, or it can just
show the
final results.
Notes
You may assume that all plate
temperatures
are in the range [0.0, 100.0]
inclusive.
Your plate should be initialized with a temperature of 0.0 at all
(non-edge)
points. The
algorithm
takes
some number of iterations for the temperatures in the plate to reach
their
final values. The finer the lattice, the more iterations it takes. Make
sure
that you allow your programs enough steps to get a meaningful final
value.
There are two ways to control termination: lack of change and iteration
count.
Lack of change means
that the temperatures of the grid cells have not changed significantly
since the last iteration; that is, no
progress has been made. You may also wish to have a fixed limit on the
number
of iterations as a safeguard against failure to stabilize due to bugs
or
round-off errors.
Design Description
Describe your design
for program five. This should include the following items.
- Overview:
Overall structure, metaphor, or architecture. Also, describe
what you feel is the single most troubling / interesting / complex
aspect
of the design. State this in the form of a question. Also state
possible answers to the question, your choice of approach, and why you
chose it
- Program
characteristics: For each of the five programs, its total lines
of code, the
total size of its class files, the number of classes, the number of
operations per class, the number of attributes per class, and the
number of inter-class dependencies (see next bullet)
- Static
description: What were the major classes used, and what were
their roles in the architecture? Refer to the accompanying class model
diagram.
(Major classes are top-level,
having their own Java files.) How
did they depend on each other? (Dependency
should be thought of in the sense of UML.) Prepare a table which, for
each major non-API class, lists all major non-API
classes it depends on and the nature of the dependencies. One way to
check whether your table is complete is to make sure that for each
non-API package you import there is at least one corresponding
dependency listed. Dependency types are described in the following table
Dependency
Type
|
UML
Stereotype
|
Description
|
calls
|
<<call>>
|
Source invokes target
|
creates
|
<<create>>
|
Source class creates an instance of target
|
instantiates
|
<<instantiate>>
|
Source operations creates an instance of target
|
uses as parameter
|
|
Source class contains operation with parameter of target
class
|
returns as result
|
|
Source class contains operation that returns result of
target class
|
sends a message to
|
<<send>>
|
Source sends message of type target
|
refers to globally
|
|
Source class refers to
target class, for example, to obtain static final values
|
- Class-model
design diagram: Major
classes,
including their non-private operations and attributes, subclass
derivations
and dependencies. This should not be an analysis diagram; it should not
contain any associations (other than aggregations and compositions);
and it decidedly should not be a diagram
automatically
generated from a
case tool examining the source code
- Dynamic
description: Describe how your program is expected to behave.
Discuss
control flows and data flows among the classes in the class-model
diagram. Refer to the accompanying sequence diagrams
- Sequence
diagrams: Provide UML sequence diagrams
illustrating
typical processing. At least one of these should describe execution of
one of the first four programs and at least one should describe how the
GUI
interacts with the rest of program five
- Low-level
design considerations: Describe your choices for major
algorithms and
data structure representations
- Non-functional
requirements: With which
non-functional requirements did your design have to deal? For each,
indicate how your design dealt with it. That is, explicitly state the
design
decisions that you had to make and your reasons for making them
- GUI design: Describe how you selected the user
controls and how you chose the particular
visualization
you ended up using. Also,
describe the interface between the
computational and user-interface pieces
of the program and why you chose to do it the way that you did
- Reflection: Provide a post-mortem evaluation of your
design and the resulting
implementation, specifically, what worked, what didn't and why?
This Design Description should take
no more than
five pages,
not counting the tables and diagrams.
Design Study
You should perform and report on a
design study of your five programs. Design studies are described here. Using the approach described
there, you should address the following items.
- Initial
conditions: Temperatures of the edges
- Coarseness
of the lattice: Size of the grid
- Precision:
Number of bits used for computation
- Relative
change stopping criterion: Minimum amount of relative change
(from 0.0 to 1.0) for the computation to continue
- Runtime
memory use: Bytes
- Performance:
Time, both fixed (independent of grid size) and varying (depending on
grid size)
- Number
of iterations: Steps taken until the results stabilize
- Model
representation:
Object oriented and array. Consider data access costs, wrapping costs
and code elegance
- Usability
(for the fifth program only): How you would determine the
usability of your presentation and controls? Note, you are not actually required to
perform a usability study, only indicate how you would perform such a
study
- Adaptability:
Subsequent projects may
make use of
the code that you built for this
exercise. One way
that this can be anticipated is to produce change scenarios. A change scenario is a description of
a likely future change and an estimation of the effect that it will
have on a design. Prepare at least six change scenarios for the
heated-plate simulation. Four of them should anticipate functional
changes, and two should discuss quality changes (changes to
non-functional requirements). For each you should describe the
enhancement and provide an assessment as to the
resilience of your design to this
change and why. Each change scenario should comprise about two
paragraphs
Limit the Design Study to eight
pages,
not
counting any tables, graphs or diagrams..
Demonstration
In addition to the programs and the
reports, you should prepare a fifteen minute presentation and demo. The
demo should include
actually running the fifth program. The presentation should present
your design and the major conclusions from your design study
Mechanics
- You should work on teams for this
project. Team membership for Atlanta students can be
found here. Team membership for Korean
students can be found here. Team membership
for the French students can be found here.
- Create a team Swiki page and place a
link to it from the class
Swiki Project 1 page. Include
links to the class Swiki pages for each team
member
- Place links to each of your
three deliverable
on your
team Swiki page, one of which is a link to a single tar file containing
the
source code
- You are free to use whatever
machines you wish to build and test your programs. You are free to run
your design studies on whatever machines you wish. However, your
program must successfully
build and execute on the the machine used by your grader without
intervention by you. You should arrange for this with the TA in
advance
- Your programs should be entirely buildable
from your sources and the SUN JDK APIs. That is, no third party source
code should be used
Grading
- The primary concern of this
project is design and not coding. You should spend considerable time
actually designing the programs, planning and executing the design
study and preparing your reports. I would rather see a functionally
incomplete (but executable program) than a slipshod report. The
approximate evaluation weights are 25% to the coding and 75% to the
report
- Grading criteria for the Design
Description is given here
- Grading criteria for the Design Study is
given here
Notes
- The emphasis of the project and
the class is on design, not Java and not programming. In particular, it
is easy to get
bogged down figuring out Swing. You should avoid
this. You are welcome to post messages to the newsgroup about Java,
Swing, and OO coding, and you are encouraged to answer other people's
questions. However, each team's design solution and actual code should
be
strictly its own. To help out with Swing, I have prepared a simple program
that
displays random shades
of red on a square grid. JavaDoc for the program can be found here
- Here is example output from running the command java tpdahp.Demo -d 3 -t 100 -b
0 -l 75 -r 50
- The previous point not
withstanding, you should produce well-engineered code. This includes
testing your program. Moreover, you may want to make use of your
solution to
this project on subsequent ones. Hence, effort spent producing a
general, well structured, commented program will likely pay dividends.
Sun's Java coding conventions can be found here
- This is a team project. All
team members are expected to participate. It is not acceptable to drop
out of communication with your teammates. For example, if you have an
intense assignment due for another class, notify your team in advance.
If you don't have time to respond to a lengthy message, send a short
response indicating when you will get back to him/her at some later
time. There will be an
opportunity at
the end of the term to recognize the contributions (or lack thereof)
of your teammates. Your teammates' comments will affect your course
grade
- A single speaker should make
your presentation although another team member can help with the demo