\end{table}
-Additionally three interfaces are defined for the components,
-\code{MotorMount}, \code{Clusterable} and \code{RadialParent}.
-Components implementing the \code{Motor\-Mount} interface, currently
-\code{BodyTube} and \code{InnerTube}, can function as motor mounts and
-have motors loaded in them. The \code{Clusterable} interface
-signifies that the component can be clustered in various
-configurations. Currently only the \code{InnerTube} component can be
-clustered. Components and motors that are attached to a clustered
-inner tube are automatically replicated to all tubes within the
-cluster. The \code{RadialParent} interface allows inner components to
-automatically identify their correct inner and outer radii based on
-their parent and sibling components. For example, a coupler tube can
-automatically detect its radius based on the inner radius of
-the parent body tube.
+Additionally four interfaces are defined for the components,
+\code{MotorMount}, \code{Clusterable}, \code{Radial\-Parent} and
+\code{Coaxial}. Components implementing the \code{Motor\-Mount}
+interface, currently \code{Body\-Tube} and \code{Inner\-Tube}, can
+function as motor mounts and have motors loaded in them. The
+\code{Clusterable} interface signifies that the component can be
+clustered in various configurations. Currently only the
+\code{Inner\-Tube} component can be clustered. Components and motors
+that are attached to a clustered inner tube are automatically
+replicated to all tubes within the cluster. The \code{Radial\-Parent}
+interface allows inner components to automatically identify their
+correct inner and outer radii based on their parent and sibling
+components. For example, a coupler tube can automatically detect its
+radius based on the inner radius of the parent body tube.
+\code{Coaxial} on the other hand provides a generic interface for
+accessing and modifying properties of fixed-radius components.
Since the software functionality is divided into different packages,
One of the key aspects in the design of the simulation implementation
was extensibility. Therefore all aerodynamic calculation code is
separated in the package \code{aerodynamics} and all simulation code
-is in the package \code{simulator}.
-
-The basis for aerodynamic calculations is the abstract class
-\code{Aerodynamic\-Calculator}, while the simulators are subclasses of
-the \code{Flight\-Simulator} class. This allows adding new
+is in the package \code{simulator}. This allows adding new
implementations of the aerodynamic calculators and simulators
independently. For example, a simulator using Euler integration was
written in the early stages of development, and later replaced by the
the aerodynamic forces, such as CFD, could be implemented and used by
the existing simulators.
+The basis for all aerodynamic calculations is the interface
+\code{Aerodynamic\-Calculator}. The current implementation, based on
+the Barrowman methods, is implemented in the class
+\code{Barrowman\-Calculator}. This implementation caches mid-results
+for performance reasons.
+
+Flight simulation is split into the
+interfaces \code{Simulation\-Engine}, which is responsible for
+maintaining the flow of the simulation and handling events (such as
+motor ignition), and \code{Simulation\-Stepper}, which is responsible
+for taking individual time steps while simulating (using {\it e.g.}
+RK4 iteration).
+
Similar abstraction has been performed for the atmospheric temperature
-and pressure model by the abstract class \code{AtmosphericModel} and
-different rocket motor types by the \code{Motor} class, among others.
+and pressure model with the \code{Atmospheric\-Model} interface, the
+gravity model with \code{Gravity\-Model}, the wind modelling with
+\code{Wind\-Model} and different rocket motor types by the
+\code{Motor} class, among others.
Simulation listeners are pieces of code that can dynamically be
configured to listen to and interact with a simulation while it is
-running. The listeners are called after each simulation step, at each
-simulation event and both when the flight conditions and aerodynamic
-forces have been calculated. The listeners may simply gather flight
-data for use outside the simulation or modify the rocket or simulation
-during the flight. This allows great potential for extensibility both
+running. The listeners are called before and after each simulation
+step, each simulation event and any calculations performed during
+flight simulation. The listeners may simply gather flight data for
+use outside the simulation or modify the rocket or simulation during
+the flight. This allows great potential for extensibility both
internally and externally.
Listeners are used internally for various purposes such as retrieving
handling directly within the simulation code.
Listeners can also be used to modify the simulation or the rocket
-during its flight. The successor project of Haisunäätä will include
-an active roll stabilization system, where a flight computer will
-measure the roll rate using two magnetometers and use a PID controller
-to adjust two auxiliary fins to cancel out the roll inevitably
-produced by imperfections in the main fins. A simulation listener was
-written that first simulated the PID controller purely in Java, which
+during its flight. The successor project of Haisunäätä included
+an active roll stabilization system, where a flight computer
+measured the roll rate using two magnetometers and used a PID controller
+to adjust two auxiliary fins to cancel out any roll produced by
+inevitable imperfections in the main fins. A simulation listener was
+written that initially simulated the PID controller purely in Java, which
modified the cant angle of the auxiliary fins during the simulation.
Later a similar listener interfaced the external flight computer
-directly using a serial data link. The listener fed the flight data
-to the controller which computed and reported the control actions back
-to the simulator. This system helped identify and fix numerous bugs
-in the flight computer software, which would have otherwise been
-nearly impossible to fully test. It is expected that the simulation
-listeners will be an invaluable tool for more ambitious model rocket
-enthusiasts.
-
-A listener is produced by implementing the \code{SimulationListener}
-interface or by extending the \code{AbstractSimulationListener}
-class. The UI includes the option of defining custom simulation
-listeners to be utilized during flight simulation.
+directly using a serial data link. The listener fed the simulated
+flight data to the controller which computed and reported the control
+actions back to the simulator. This system helped identify and fix
+numerous bugs in the flight computer software, which would have
+otherwise been nearly impossible to fully test. It is expected that
+the simulation listeners will be an invaluable tool for more ambitious
+model rocket enthusiasts.
+
+A listener is produced by implementing the \code{Simulation\-Listener}
+and optionally \code{Simulation\-Event\-Listener} and
+\code{Simulation\-Computation\-Listener} interfaces, or by extending
+the \code{Abstract\-Simulation\-Listener} class. The UI includes the
+option of defining custom simulation listeners to be utilized during
+flight simulation.
\subsection{Warnings}
\label{fig-plotting}
\end{figure}
-
-\section{Future enhancements}
-
-Numerous features have been planned and taken into account during the
-design of the software. Below are listed a few of the planned
-features and how they have been taken into account:
-
-{\it Alternative aerodynamic calculators.} For example CFD could be
-used to calculate the aerodynamic properties, allowing even better
-simulation accuracy. The calculators have been abstracted by the
-\code{AerodynamicCalculator} class so they can easily be
-interchanged.
-
-{\it Alternative simulators.} These could take into account for
-example the curvature of the Earth and include the Coriolis effect.
-New simulators can be created by extending the abstract
-\code{FlightSimulator} class.
-
-{\it Export and import of flight data.} The simulated data could be
-exported for further analysis as comma separated values (CSV).
-Similarly, experimental data could be imported either from files or
-directly from altimeters. Support for imported data already exists in
-the core functionalities.
-
-{\it Importing database files.} The motor database is easily
-extendable to read external thrust curves. Also data of commercially
-available rocket components could be imported and available in the
-component edit dialog.
-
-{\it Further UI enhancements.} These could include for example a 3D
-view of the rocket, an animation of the rocket flight, a ``wizard''
-dialog for easily creating new designs, {\it etc.}
-
+Advanced users may also export the flight data in CSV format for
+further analysis using other tools.
+
+%
+%\section{Future enhancements}
+%
+%Numerous features have been planned and taken into account during the
+%design of the software. Below are listed a few of the planned
+%features and how they have been taken into account:
+%
+%{\it Alternative aerodynamic calculators.} For example CFD could be
+%used to calculate the aerodynamic properties, allowing even better
+%simulation accuracy. The calculators have been abstracted by the
+%\code{AerodynamicCalculator} interface so they can easily be
+%interchanged.
+%
+%{\it Alternative simulators.} These could take into account for
+%example the curvature of the Earth and include the Coriolis effect.
+%New simulators can be created by implementing the
+%\code{Simulation\-Stepper} interface.
+%
+%{\it Export and import of flight data.} The simulated data could be
+%exported for further analysis as comma separated values (CSV).
+%Similarly, experimental data could be imported either from files or
+%directly from altimeters. Support for imported data already exists in
+%the core functionalities.
+%
+%{\it Importing database files.} The motor database is easily
+%extendable to read external thrust curves. Also data of commercially
+%available rocket components could be imported and available in the
+%component edit dialog.
+%
+%{\it Further UI enhancements.} These could include for example a 3D
+%view of the rocket, an animation of the rocket flight, a ``wizard''
+%dialog for easily creating new designs, {\it etc.}
+%
projects / debian / openrocket / blobdiff