Free flight simulation software for linux

Flight Navigation Planner project is a tool for making flight plans based on known airports.

Flight Navigation Planner lets you make flight plans based on known airports, navaids, fixes, or cities.

You can use the sectional charts, wacs, or the vector/terrain planning charts.

It calculates headings, winds, time, and fuel. It features Airways-based Auto-Routing, Climb and Descent calculations (a/c type based), Fuel Stop Planning, Auto-Route around MOAS and Restricted Airspace, Hi-Res Weather Radar Overlay, Viewing of current sectional, wac, and IFR charts, the ability to see a route over TFRs, detailed nexrad radar overlays over your routes, Terrain Profiles with cloud ceilings, and the ability to upload flight plans to GPS.

Multi-Simulator Interface, in shrot MSI, is a simulation interconnection engine. In other words it is a program that connects simulations together by synchronizing their clocks and data. Multi-Simulation Interface serves the same purpose as HLA and supports most of HLAs functionality (and more).
The MSI is an HLA alternative. The major motivating factors in the design of the MSI are speed, interoperability, and ease of use.
The MSI was written as a cutting edge distributed simulation component to connect multiple instances of ATLs premiere simulation software, CSIM, and it can be used to interface any compatible simulations.
How does the MSI compare to HLA?
The MSI was originally created to be just a light weight HLA RTI. However, as it was written, limitations in HLA were discovered. The MSI is an improvement on both the design and implementation of HLA. Some highlights include:
A 1,536 to 1 reduction in size over the publicly available (until late 2002) HLA RTI.
At least one order of magnitude of bandwidth consumption less than the publicly available (until late 2002) HLA RTI.
The ability to subscribe to an object name in addition to a type.
Time synchronization that allows for proper causality when used with discrete event simulators.
Support for systems-of-systems (SoS) and hierarchically organized simulations.
Availability for many platforms.
MSI Concept - A Synchronized Data Broker
The concept behind MSI is the synchronized data broker. There are many connected software systems that posses state data that changes over the life of that system. In the case where these systems need to exchange this changing data with other systems and the other systems will exhibit the effects of this data on their own state, the synchronization of this data may need to be managed.
Historically the management of this data has been as simple as tagging it with the time of its release. If there is any conflict in the data the most recent version of the data is used. If the data is late an extrapolation can potentially be used. In SQL relational databases transactions and locking are used to ensure data integrity. Most data brokering services offer little or no sychronization, only delivery.
MSI Setup and Use
The MSI uses a XML stream through a direct socket connection for communications. This enables the MSI to be used from any programming language that can use sockets (C, C++, Java, Ada, Lisp, Perl, etc.). Also, the MSI was written with cross-platform libraries that make it portable to all the major OS platforms (Linux, Solaris, Mac OS X, Microsoft Windows, IRIX, HPUX, etc.).
The MSI is a single executable file and is distributed with example code for the simulator/federate side interface.
MSI Time Synchronization
The MSI time synchronizer can mix unconstrained with time constrained simulations. Each constrained simulation reports the time of the next event that will occur in that simulation/federate. This time may be artificially inflated to cause loose synchronization (less overhead but less guarantee of accuracy). The simulations/federates will advance to the announced time.
MSI Data Synchronization
The MSI implements a publish/subscribe data broker. The MSI is presently not validating, therefore it does not require a separate data format specification (like the HLA FOM). When data format validation is implemented, it will be an optional feature and not written in Lisp. This greatly reduces MSIs setup time. Also, not being locked to a predetermined data format allows for dynamic data types.
There are five commands associated with the MSI data broker: publish, subscribe, update, unsubscribe, destroy (destroy is not implemented yet). Simulations/federates may subscribe to object names in addition to object types. This allows simulations to subscribe to specific objects of a type without needing to receive updates of all objects of that type. The update command is both an incoming and outgoing command. When a simulation/federate receives an update command, it is expected to reflect the new values of that object.
The MSI has a very flexible publish and subscribe system. A federate may subscribe to an object type or an object name. In addition a federate may specify particular attributes of an object or object type. For example, if an object has attributes name, x, y, and z, a federate that only considers two dimensions may choose to subscribe only to name, x, and y.
The MSI also supports systems of systems and object hierarchy in simulations. A publishing federate may designate a parent object. Subscribers may then subscribe to the objects children.
MSI Messaging
The MSI allows simulations/federates to send messages (interactions in HLA) to each other. These messages can contain multiple attributes and be multicast to a specific group of simulations.
Recently Added Features
Removed external library dependencies to improve the portability and fragility of the MSI.
Added a better client library.
Improved documentation.
Enhancements:
- An XML parsing bug in the utilities library was fixed.
- The socket library was enhanced with more protocols, Win32 tricks, and the ability to key off of addresses as well as names.
- The --wait-for command line argument was added.
- Several internal bugs were fixed.
- More of the client library and the CSIM interface were flushed out.
- All standard functionality was tested.

Simulation::Sensitivity is a general-purpose sensitivity analysis tool for user-supplied calculations and parameters.

SYNOPSIS

use Simulation::Sensitivity;
$sim = Simulation::Sensitiviy->new(
calculation => sub { my $p = shift; return $p->{alpha} + $p->{beta} }
parameters => { alpha => 1.1, beta => 0.2 },
delta => 0.1 );
$result = $sim->run;
print $sim->text_report($result);

Simulation::Sensitivity is a general-purpose sensitivity analysis tool. Given a user-written calculating function, a "base-case" of parameters, and a requested input sensitivity delta, this module will carry out a sensitivity analysis, capturing the output of the calculating function while varying each parameter positively and negatively by the specified delta. The module also produces a simple text report showing the percentage impact of each parameter upon the output.

The user-written calculating function must follow a standard form, but may make any type of computations so long as the form is satisfied. It must take a single argument -- a hash reference of parameters for use in the calculation. It must return a single, numerical result.

CONSTRUCTORS

new

my $sim = Simulation::Sensitivity->new(
calculation => sub { my $p = shift; return $p->{alpha} + $p->{beta} }
parameters => { alpha => 1.1, beta => 0.2 },
delta => 0.1 );

new takes as its argument a hash with three required parameters. calculation must be a reference to a subroutine and is used for calculation. It must adhere to the usage guidelines above for such functions. parameters must be a reference to a hash that represents the initial starting parameters for the calculation. delta is a percentage that each parameter will be pertubed by during the analysis. Percentages should be expressed as a decimal (0.1 to indicate 10%).

As a constructor, new returns a Simulation::Sensitivity object.

GENESIS (short for GEneral NEural SImulation System) is a general purpose simulation platform that was developed to support the simulation of neural systems ranging from subcellular components and biochemical reactions to complex models of single neurons, simulations of large networks, and systems-level models.

GENESIS has provided the basis for laboratory courses in neural simulation at Caltech, the Marine Biological Laboratory, the Crete, Trieste, Bangalore, and Obidos short courses in Computational Neuroscience, and at least 49 universities of which we are aware.

Most current GENESIS applications involve realistic simulations of biological neural systems. Although the software can also model more abstract networks, other simulators are more suitable for backpropagation and similar connectionist modeling.

Installation

1. Pick the place where you want to install the "genesis" directory tree. If you are making a system-wide installation as "root" user, /usr/local is a good choice. For a personal installation, without root privileges, you can use your home directory ("~"). Change to this directory and extract the genesis directory from the archive file genesis2.2.1-linux-bin.tar.gz. For example,

cd /usr/local
tar xvzf /mnt/cdrom/genesis2.2.1-linux-bin.tar.gz

or from wherever you have it (e.g.~/downloads/genesis2.2.1-linux-bin.tar.gz).

2. Change to the "genesis" directory and run the setup script that creates the ".simrc" GENESIS initialization file". Then copy .simrc to your home directory.

cd genesis
./binsetup
cp .simrc ~

3. Finallly, add the genesis directory to your search path, so that "genesis" can be found from any directory that you are in. If your login shell is bash, you can do this by editing the .bashrc file in your home directory to add the line

PATH=$PATH:/usr/local/genesis

at the end of the file. If you are using tcsh or csh as your command shell, add

set path=($path /usr/local/genesis)

to your .tcsh or .csh file.

At this point, you are ready to try running GENESIS. Change into the directory genesis/Scripts and try some of the tutorials suggested in the README file.

The FlightGear flight simulator project is an open-source, multi-platform, cooperative flight simulator development project. Source code for the entire project is available and licensed under the GNU General Public License.

The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing.

There are many exciting possibilities for an open, free flight sim. We hope that this project will be interesting and useful to many people in many areas.

FlightGear is a free flight simulator project. It is being developed through the gracious contributions of source code and spare time by many talented people from around the globe. Among the many goals of this project are the quest to minimize short cuts and "do things right", the quest to learn and advance knowledge, and the quest to have better toys to play with.

The idea for Flight Gear was born out of a dissatisfaction with current commercial PC flight simulators. A big problem with these simulators is their proprietariness and lack of extensibility. There are so many people across the world with great ideas for enhancing the currently available simulators who have the ability to write code, and who have a desire to learn and contribute. Many people involved in education and research could use a spiffy flight simulator frame work on which to build their own projects; however, commercial simulators do not lend themselves to modification and enhancement. The Flight Gear project is striving to fill these gaps.

There are a wide range of people interested and participating in this project. This is truly a global effort with contributors from just about every continent. Interests range from building a realistic home simulator out old airplane parts, to university research and instructional use, to simply having a viable alternative to commercial PC simulators.

Flight Dynamics Models

With FlightGear it is possible to choose between three primary Flight Dynamics Models. It is possible to add new dynamics models or even interface to external "proprietary" flight dynamics models:

1. JSBSim: JSBSim is a generic, 6DoF flight dynamics model for simulating the motion of flight vehicles. It is written in C++. JSBSim can be run in a standalone mode for batch runs, or it can be the driver for a larger simulation program that includes a visuals subsystem (such as FlightGear.) In both cases, aircraft are modeled in an XML configuration file, where the mass properties, aerodynamic and flight control properties are all defined.

2. YASim: This FDM is an integrated part of FlightGear and uses a different approach than JSBSim by simulating the effect of the airflow on the different parts of an aircraft. The advantage of this approach is that it is possible to perform the simulation based on geometry and mass information combined with more commonly available performance numbers for an aircraft. This allows for quickly constructing a plausibly behaving aircraft that matches published performance numbers without requiring all the traditional aerodynamic test data.

3. UIUC: This FDM is based on LaRCsim originally written by the NASA. UIUC extends the code by allowing aircraft configuration files instead and by adding code for simulation of aircraft under icing conditions.

UIUC (like JSBSim) uses lookup tables to retrieve the component aerodynamic force and moment coefficients for an aircraft... and then uses these coefficients to calculate the sum of the forces and moments acting on the aircraft.

Extensive and Accurate World Scenery Data Base

Over 20,000 real world airports included in the full scenery set.
Correct runway markings and placement, correct runway and approach lighting.
Taxiways available for many larger airports (even including the green center line lights when appropriate.)
Sloping runways (runways change elevation like they usually do in real life.)
Directional airport lighting that smoothly changes intensity as your relative view direction changes.
World scenery fits on 3 DVDs. (Im not sure thats a feature or a problem!) But it means we have pretty detailed coverage of the entire world.
Accurate terrain worldwide, based on the most recently released SRTM terrain data.) 3 arc second resolution (about 90m post spacing) for North and South America, Europe, Asia, Africa, and Australia.
Scenery includes all vmap0 lakes, rivers, roads, railroads, cities, towns, land cover, etc.
Nice scenery night lighting with ground lighting concentrated in urban areas (based on real maps) and headlights visible on major highways. This allows for realistic night VFR flying with the ability to spot towns and cities and follow roads.
Scenery tiles are paged (loaded/unloaded) in a separate thread to minimize the frame rate hit when you need to load new areas.

Accurate and Detailed Sky Model

FlightGear implements extremely accurate time of day modeling with correctly placed sun, moon, stars, and planets for the specified time and date. FlightGear can track the current computer clock time in order to correctly place the sun, moon, stars, etc. in their current and proper place relative to the earth. If its dawn in Sydney right now, its dawn in the sim right now when you locate yourself in virtual Sidney. The sun, moon, stars, and planets all follow their correct courses through the sky. This modeling also correctly takes into account seasonal effects so you have 24 hour days north of the arctic circle in the summer, etc. We also illuminate the correctly placed moon with the correctly placed sun to get the correct phase of the moon for the current time/date, just like in real life.

Flexible and Open Aircraft Modeling System

FlightGear has the ability to model a wide variety of aircraft. Currently you can fly the 1903 Wright Flyer, strange flapping wing "ornithopters", a 747 and A320, various military jets, and several light singles. FlightGear has the ability to model those aircraft and just about everything in between.

FlightGear has extremely smooth and fluid instrument animation that updates at the same rate as your out-the-window view updates (i.e. as fast as your computer can crank, and not artificially limited and chunky like in some sims.)

FlightGear has the infrastructure to allow aircraft designers to build fully animated, fully operational, fully interactive 3d cockpits (which even update and display correctly from external chase plane views.)

FlightGear realistically models real world instrument behavior. Instruments that lag in real life, lag correctly in FlightGear, gyro drift is modeled correctly, the magnetic compass is subject to aircraft body forces -- all those things that make real world flying a challenge.

FlightGear also accurately models many instrument and system failures. If the vacuum system fails, the HSI gyros spin down slowly with a corresponding degradation in response as well as a slowly increasing bias/error.

Moderate Hardware Requirements

The intention of FlightGear is to look nice, but not at the expense of other aspects of a realistic simulator. Our focus is not on competing in the "game" market and not on the ultra-flashy graphic tricks.

The result is a simulator with moderate hardware requirements to run at smooth frame rates. You can be reasonably happy on a $500-1000 (USD) machine (possibly even less if you are careful) and dont necessarily need $3000 (USD) worth of new hardware like you do with the many of the newest games.

That said, the more hardware you throw at FlightGear, the better it looks and runs, so dont feel like you have to chuck your expensive new hardware if you just purchased it. :-)

Internal Properties EXPOSED!

FlightGear allows users and aircraft designers access to a very large number of internal state variables via numerous internal and external access mechanisms. These state variables are organized into a convenient hierarchal "property" tree.

Using the properties tree it is possible to monitor just about any internal state variable in FlightGear. Its possible to remotely control FlightGear from an external script. You can create model animations, sound effects, instrument animations and network protocols for about any situation imaginable just by editing a small number of human readable configuration files. This is a powerful system that makes FlightGear immensely flexible, configurable, and adaptable.

Networking options

A number of networking options allow FlightGear to communicate with other instances of FlightGear, GPS receivers, external flight dynamics modules, external autopilot or control modules, as well as other software such as the Open Glass Cockpit project and the Atlas mapping utility.

A generic input/output option allows for a user defined output protocol to a file, serial port or network client.

A multi player protocol is available for using FlightGear on a local network in a multi aircraft environment, for example to practice formation flight or for tower simulation purposes.

The powerful network options make it possible to synchronize several instances of FlightGear allowing for a multi-display, or even a cave environment. If all instances are running at the same frame rate consistently, it is possible to get extremely good and tight synchronization between displays.

Flight Gear and its source code have intentionally been kept open, available, and free. In doing so, we are able to take advantage of the efforts of tremendously talented people from around the world. Contrast this with the traditional approach of commercial software vendors, who are limited by the collective ability of the people they can hire and pay. Our approach brings its own unique challenges and difficulties, but we are confident (and other similarly structured projects have demonstrated) that in the long run we can outclass the commercial "competition."

Contributing to Flight Gear can be educational and a lot of fun. A long time developer, Curtis Olson, had this to say about working on Flight Gear:

Personally, Flight Gear has been a great learning experience for me. I have been exposed to many new ideas and have learned a tremendous amount of "good stuff" in the process of discussing and implementing various Flight Gear subsystems. If for no other reason, this alone makes it all worth while.

Cell Electrophysiology Simulation Environment (CESE) is a comprehensive framework specifically designed to perform computational electrophysiological simulations, for example, simulations of cardiac myocyte electrical activity.
Cell Electrophysiology Simulation Environment is useful for simulations of action potentials, individual ionic currents, and changes in ionic concentrations.
CESE is a cross-platform program, it runs on any system that has Java runtime environment (JRE) version 1.4 or above. It was tested on Windows, Linux, Solaris, MacOS X, and AIX.
CESE users
CESE is an integrated environment for performing computational simulations using a variety of electrophysiological models.
At this stage CESE allows creation and execution of the single-cell models (containing both Hodgkin-Huxley (HH) and Markovian current formulations). Models of electrical activity of cardiac myocytes with source code are included in the CESE distribution. We hope to extend the number of available models, and add certain neuronal models in the future.
The main strength of CESE is in its uniformity ? a program interface remains the same for different types of models. You can easily switch between models and compare simulation outputs. Model parameters can be modified, selected for output and/or clamped in the same, standard way.
CESE extends the conventional electrophysiological meaning of the "voltage clamp". You can clamp virtually any model variable, including voltage (membrane potential), total or individual ionic currents, ionic concentrations, temperature, gating variables, etc. The clamping commands can be complex piece-wise functions, individually set for the model variable of interest. This opens endless possibilities for the exploration of complex model behavior.
CESE provides simple, but efficient data visualizations. Simulation results can be presented in the graphic and tabulated forms. Plots can be customized, and regions of interest zoomed.
Even though CESE was not designed to be a data analysis tool, you can generate current-voltage relationships (I-Vs) and calculate statistical parameters for a given signal within the program. You can export your data to ASCII, Axon Text File (ATF), and NetCDF formats to continue analysis in your favorite package.
CESE developers
CESE was created from the ground up to incorporate the best programming practices available to Java developers, both in terms of user interface consistency and code clarity and reuse. Wherever possible, CESE rely on available Java APIs (for example Java2D, JavaBeans, JAXP) to simplify the code.
Model creation requires a number of house-keeping functions to be coded ? these include ODE integrators, routines for handling model parameters, saving/restoring model state, visualizing simulation results, etc. CESE provides you with implementation for these routines, hence, you can concentrate on writing the code for concrete ionic current(s), and CESE will handle the rest.
CESE is not trying to create complicated programming frameworks on its own ? rather, it utilizes core Java APIs. For example, models are Java components conforming to the JavaBeans specification. We use XML to specify clamping commands, and Java object serialization to save/restore model parameters.
Enhancements:
- This release improves results printing, adds export to the scalable vector graphics (SVG) format, improves support for continuous simulations, and fixes many bugs in plot rendering and model switching.