Free hydrodynamic model software for linux

JSBSim Flight Dynamics Model is an open source flight dynamics model (FDM) that compiles and runs under many operating systems, including Linux, Apple Macintosh, Microsoft Windows, Linux, IRIX, Cygwin (Unix on Windows), etc.
The FDM is essentially the physics/math model that defines the movement of an aircraft under the forces and moments applied to it using the various control mechanisms and from the forces of nature.
JSBSim has no native graphics. It can be run by itself as a standalone program, taking input from a script file and various aircraft configuration files; or, it can be run as an integrated part of a larger flight simulator implementation that includes a visual system.
The most notable example of the use of JSBSim is currently seen in the open source FlightGear simulator. JSBSim models the aerodynamic forces and moments by the classic coefficient buildup method.
JSBSim has seen the growth of a fairly large user base, with some of the more notable projects (of which I am aware) described on the Users page.
Main features:
- Fully configurable flight control system, aerodynamics, propulsion, landing gear arrangement, etc. through XML-based text file format.
- Rotational earth effects on the equations of motion (coriolis and centrifugal acceleration modeled).
- Configurable data output formats to screen, file, socket, or any combination of those.
Enhancements:
- This release includes new options for the standalone JSBSim executable, including improved real-time capability.
- This release also includes experimental (but tested) logic to reduce ground reactions jitter while on the ground.

Installation: The simplest way to compile this package is:

1. `cd to the directory containing the packages source code and type `./configure to configure the package for your system.
2. Running `configure might take a while. While running, it prints some messages telling which features it is checking for.
3. Type `make to compile the package.
4. Optionally, type `make check to run any self-tests that come with the package.
5. Type `make install to install the programs and any data files and
6. documentation.
7. You can remove the program binaries and object files from the source code directory by typing `make clean. To also remove the files that `configure created (so you can compile the package for a different kind of computer), type `make disclean. There is also a `make maintainer-clean target, but that is intended mainly for the packages developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution.

Yukatan data model project is the schema definition of the Yukatan webmail database.
The PostgreSQL database structures defined in this file can be used as a backend store of an email message handling application. The database should be created with the "UNICODE" encoding to properly support messages in different languages.
New data types
The special data types commonly used in the Yukatan data model have been made explicit by the introduction of seven new domains. The domains and the related COMMENT statements make field semantics more clear than before.
See the SQL schema file for more detailed documentation on these domains.
Explicitly named constraints
All the table constraints in the database are now explicitly named and documented. This change makes the database implementation more orthogonal and cleans up the documentation.
Renamed fields and tables
All the *address field names have been truncated to *addr, to make it visually clearer that they are always paired with the corresponding *name fields. The change also makes parts of the documentation less repetitive.
The referencesfield table has been renamed to referencefield to avoid the plural form in the table name. Also all the contained references* field names have been renamed to reference*.
Semantic changes
Quite a few changes have been made to the semantics of various fields. The unnecessarily tight constraints on sequence numbers have been replaced with clearer documentation, the format and encoding of most fields has been explicitly documented, and the previously allowed dual use of the enttext and enddata fields has been prohibited.
Dropped envelope data
The envelope data added in version 0.5 of the data model has for now been removed. The reason for the removal is that the envelope data is not an integral part of an email message, and I wanted to make the version 1.0 as clear as possible. The database now stores "email messages" - nothing less, nothing more. Envelope data can and probably will be reintroduced in an incremental version 1.x along with other extensions.
Enhancements:
- cleans up and documents the data model that has developed since version 0.1
- removal of the envelope data added in version 0.5
- enaming and redefinition of some of the fields and tables
- database structure has also been extensively documented

MyPageKit::MyModel is an example Derived Model Class implementing Backend Code for pagekit.org website.

This module provides a example of a Derived Model component (Business Logic) of a PageKit website.

It is also the code used for old the http://www.pagekit.org/ web site. It contains two methods, one for customizing the look and feel for the website, and another for processing new account sign ups.

It is a good starting point for building your backend for your PageKit website.

Config::Model provides a framework to help in validating the semantic content of configuration data. The project can also be used to provide a semantic check of options of a complex program like mplayer or transcode.
For most complex software, configuration upgrade is a difficult task for most people. By using Config::Model, a software can provide a smooth upgrade path for their users.
How does this work ?
Using this project, a typical configuration validation tool will be made of 3 parts :
The user interface
The validation engine which is in charge of validating all the configuration information provided by the user.
The storage facility that store the configuration information
Dont we already have some configuration validation tools ?
Youre probably thinking of tools like webmin. Yes, these tools exist and work fine, but they have their set of drawbacks.
Usually, the validation of configuration data is done with a script which performs semantic validation and often ends up being quite complex (e.g. 2500 lines for Debians xserver-xorg.config script which handles xorg.conf file).
In most cases, the configuration model is expressed in instructions (whatever programming language is used) and interspersed with a lot of processing to handle the actual configuration data.
Whats the advantage of this project ?
The Config::Model projects provide a way to get a validation engine where the configuration model is completely separated from the actual processing instruction.
The configuration model is expressed in a declarative form (i.e. a Perl data structure) which is always easier to maintain than a lot of code.
The declaration specifies:
the structure of the configuration data (which can be queried by generic user interfaces)
the properties of each element (boundaries, check, integer or string, enum like type ...)
the default values of parameters (if any)
mandatory parameters
the targeted audience (intermediate, advance, master)
on-line help (for ach parameter or value of parameter)
the level of expertise of each parameter (to hide expert parameters from newbie eyes)
So, in the end:
maintenance and evolution of the configuration content is easier
user will see a *common* interface for *all* programs using this project.
user will not see advanced parameters
upgrade of configuration data is easier and sanity check is performed
audit of configuration is possible to check what was modified by the user compated to default values
What about the user interface ?
Config::Model will also come with a Curses::UI interface that queries the users model and generate the relevant user screens.
What about data storage ?
Since the syntax of configuration files vary wildly form one program to another, most people who want to use this framework will have to provide a dedicated parser/writer.
Nevertheless, this project can also provide a writer/parser for most common format: like ini style file, or provide an interface to the Elektra or debconf projects. This point is open for discussion.
It is entirely possible for a single configuration model to use several parsers and writers so one model will ensure the consistency of several configuration files together.
Enhancements:
- The Xorg model was updated to Config::model version 0.609.
- Some bugs were fixed.

GO::Model::Term is a term or concept in an ontology.

SYNOPSIS

# From a file
use GO::Parser;
my $parser = new GO::Parser({handler=>obj}); # create parser object
$parser->parse("gene_ontology.obo"); # parse file -> objects
my $graph = $parser->handler->graph; # get L object
my $term = $graph->get_term("GO:0001303"); # fetch a term by ID
printf "Term %s %sn", $term->name, $term->acc;

# From a GO Database (requires go-db-perl)
my apph = GO::AppHandle->connect(-dbname=>$dbname);
my $term = $apph->get_term({acc=>00003677});
printf "Term:%s (%s)nDefinition:%snSynonyms:%sn",
$term->name,
$term->public_acc,
$term->definition,
join(", ", @{$term->synonym_list});

Represents an Ontology term; the same class is used for process, compartment and function
currently, a Term is not aware of its Relationships; to find out how a term is related to other terms, use the a GO::Model::Graph object, which will give you the GO::Model::Relationship objects; for example

$rels = $graph->get_parent_relationships($term->acc);

XML Tree Object Model Parser is an easy to use XML parser designed to provide an easy and simple to use library for parsing XML configuration files. It is split into two components.

The first one is the Parser itself, which uses J2SE 1.4 XML Parsing API, and the second one is what I call XML Tree Object Model, which is a XMLTree containing all of the XML Nodes or Elements in that tree.

The basic idea behind XTOM is to parse the XML file into an XMLTree and then navigate the elements of that tree by refering to them by the path, such as one/two/three.

The idead behind the navigation system came from Jakartas Digester. XTOM just simplifies it to increase the developement of XML based applications.

Bio::Tools::Run::PiseApplication::align2model is a Bioperl class for align2model - create a multiple alignment of sequences to an existing model.

Parameters:

align2model (String)

run (String)
Run name

db (Sequence)
Sequences to align (-db)

model_file (InFile)
Model (-i)
pipe: sam_model

id (String)
Sequence identifier(s) selection (separated by commas) (-id)

nscoreseq (Integer)
Maximum number of sequences to be read (-nscoreseq)

adpstyle (Excl)
Dynamic programming style (-adpstyle

SW (Excl)
Sequence scoring (-SW)

auto_fim (Switch)
Add FIMs automatically (-auto_fim)

jump_in_prob (Float)
Probability cost of jumping into the center of the model (-jump_in_prob)

jump_out_prob (Float)
Probability cost of jumping out the center of the model (-jump_out_prob)

a2mdots (Switch)
Print dots to fill space need for other sequences insertions (-a2mdots)

dump_parameters (Excl)
(-dump_parameters)