Would it be reasonable to move defect examples (like 
"hydraulics_relative_hydraulic_proofofconcept") in a seperate folder? For 
example "branches/examples/version-3.0.0-defect"?

Provide a binary dynamically linked MBSim build in form of a tar.gz archive

[deleted issue]

What steps will reproduce the problem?
1. Build kernel without casadi-installation
2. configure works (doesn't find casadi however creates makefiles)
3. Compilation doesn't find "casadi/symbolic/fx/sx_function.hpp" in symbolic 
functions h.

What is the expected output? What do you see instead?

I would expect casadi to be a dependency of the kernel

[deleted issue]

Since now also to binary distribution of MBSim and co. is dynamically linked 
(even on Windows) the MBSim modules can be loaded as plugins (shared objects) 
at runtime. If so the MBSim Modules can initialize their ObjectFactory at 
runtime. This simplifies some parts of MBSim and MBSimXML. Moreover new modules 
can be included in mbsimxml without a required relink of mbsimflatxml!

MBSim Functions are now derived from Element to be able to call init(...) and 
initializeUsingXML(...) on these! Also getPath() is available with this change 
on Functions.

However this requires f->setParent(this) and f->init(stage) (and maybe 
f->setName(...)) to be called whenever a object containing a function f was 
created, initialized, ...

This is already done for most of the code except the following classes and/or 
files:
constitutive_laws.*
lcp_reformulation_functions.*
damping_functions.*
newton_method_jacobian_functions.*
criteria_functions.*
multi_dimensional_*_solver.*
nonlinear_algebra.*
piecewise_polynom_function.*
GeneralizedVelocityConstraint
GeneralizedAccelerationConstraint
Residuum
GeneralizedVelocityExcitation
GeneralizedAccelerationExcitation

Some of these classes are itself not derived from Element. This may be 
inconsistent or even incorrect and must be checked/fixed.

What steps will reproduce the problem?
1. Run an example (e.g. mechanics_basics_2pendulums) with valgrind 
--tool=massif ./main
  1.1 once with plotting
  1.2 once without
2. look at the ms_print output for the written files
3. See a memory increase due to plotting routines

It seems that due to plotting more and more memory gets allocate without 
freeing it again. This is a problem especially for large simulations that crash 
because of "bad_malloc" after a while.

General improvement of performance requested.

Implement a general root finding that works with all available integrators.

Currently a Group may be changed to connect it to other elements.
E.g. if a Group contains a Frame and a Link and the other side of the Link 
should be connected to a Frame outside of the Group the setConnect(...) of the 
Link in the Group must be called which change the Group being not closed in 
this case.

Possible Solution:
Implement Proxy elements for (all) elements which acts as a interface for a 
Group to the outside.

The Function[123] interface in MBSim uses now also fixed size vector (e.g. 
Vec3) arguments. The XML interface and ObjectFactory should use 
Function[123]_VV3S for these (add the fixed size after the V). This is 
currently done only partial and inconsitently. Fix it.

The fmatvec::Atom class provided now a general message handling functionallity. 
All MBSim code should be switched to this:

Details:
- Derive all MBSim classes from fmatvec::Atom (if not already done)
- Replace all occurence of std::cout<<... and std::cerr<<... by
  msg(Info)<<... or msg(Warn)<<...
- Maybe add more message types to fmatvec::Atom e.g. "Progress" for the
  time prints; "Warn2" for higher warning levels; ...
- But do not add a "Error" message type since errors should stop the
  simulation and hence throw MBSimError instead of printing messages
- Remove all DEBUGLEVEL, warnLevel, ... variables in MBSim and replace these
  by proper msgAct(<MessageLevel) calles.

All system updates and plots should be called by the integrator.

In LinkMechanics every contour and/or frame of the link creates 
direction-matrices for the non-smooth projection (init()-->unknownStage). 
However, only a reference should be enough and is done anyways (e.g. 
updateWRef()). 
Right now a hack (due to empty matrices) seems to solve the problem of 
unnecessary heap-allocation but conceptually this might not be the clean way to 
do it...

What steps will reproduce the problem?
1. Run example "mechanics_contacts_point_nurbsdisk" with 
ThetaTimeSteppingIntegrator and compare to a run with TimeSteppingIntegrator

With ThetaTimeSteppingIntegrator:
The example crashes

With TimeSteppingIntegrator:
The example seems to be okay.


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. compiling mbsim without openmbvcppinterface

What is the expected output? What do you see instead?
mbsim should compile

This is just a reminder to check from time to time if mbsim works without the 
an installed openmbvcppinterfac...

Move MBSim numerics to external library to be usable in other software projects.

MBSim has a "update on request" strategy:
e.g. explicitly call updateg(), updatezd(), ...

MBSimControl has as "update on demand" strategy:
if Signal::getSignal() is called the getSignal() function of all dependent 
signals are automatically called which updates all dependent signals 
automatically.

However all MBSimControl::Sensor's get their signal from MBSim elements:
e.g. MBSimControl::LinkDistanceSensor::getSingal() reads the distance from 
link->getg(). If the getSignal function is now triggered by another MBSim::Link 
it is not ensured that link->getg() is already updated by the corresponding 
MBSim::updateg() function because the evaluation order of Links is not define. 
Hence it may be possible that one gets the value for the last time step 
(without any notice). And using values form last time steps may cause 
instabillities.

What should/could we do here?!

DASPK integrator can't be used for some reasons:

1. Function names in Fortran code not unique. For this reason the whole 
integrator isn't compiled (see Makefile.am)

2. The integrator is implemented as an ode integrator. It may be implemented as 
a dae-integrator (see kernel version 0.1.3)

3. The integrator doesn't call system->update() during the integration. Only 
system->plot(), but not in every timestep.


Suggestion:
- The DASP integrator should be removed in this version
- A DAE integrator should be implemented. Maybe a Radau5DAE? In kernel version 
0.2.1 two DAE-Integrators where implemented (DASPK, Radau5DAE) from Robert 
Huber.

The C++ and the XML interface of Translation and Rotation (and derived classes) 
is inconsistent: In c++ a setAbc function should have a <abc> element in XML. 
This is wrong for e.g. <position>. Rework it in a consistent and clean way.

Implement e.g. a RigidBody21 (as it exists in a early MBSim version) having 2 
translational and 1 rotations degree of freedom. Such Body's should be much 
faster than the general ones.

The should build the model with the existing Body's and during the 
initialization phase of MBSim these Body's should be checked and converted, if 
possible, to special ones.

The automatic placement of the elements on the perlchain example seem not to 
work correctly, since the contact distance of some elements if far away from 0.

- time integration stores states only
- run postprocessing after time integration for non-state variables
- allow also online-processing of non-state variables for online plotting and 
visualisiation

Provide a parameter in runexamples.sh (e.g. makereference) to automatically run 
the examples and copy the h5-output to folder "reference".

For regularized contacts the actio=reactio principle is not fully fulfilled due 
to two contact points at different positions. A lever arm is active for 
tangential contacts.

Replace the Windows batch file mbsimxml.bat.in
and the UNIX shell script mbsimxml.in by a binary executable.
This prevents double coding and writing ugly Windows batch files.

The following steps will reproduce the problem:
1. Add a body to the MBS
2. Open the property dialog of the body, choose CompoundRigidBody in the 
visualisation tab and add a cube to the compound rigid body
3. Close the dialog and double click on the body in the 3D view

Implementation of special containers for special bodies, e.g. bodies with 
constant mass matrix, for performance reasons.

SpringDamper Klasse überarbeiten

Due to the flat hierarchy of the system, only the top level group (dynamic 
system solver) can comprise links. Iterations through subsystems can be omitted 
with respect to links.

Add a priority based mapping between XML namespaces and prefixes:
Each MBSim module should define a mapping between their namespace and a 
preferred prefix. Or better multiple prefixes with a priority.
This should be done using the ObjectFactory.

According to this information the writeXML function of MBSim should use proper 
prefixes including a proper namespace for the default (empty) prefix.
This will lead to more readable XML file generated by MBSim.

In the configure.ac of the mbsimFlexibleBody-module the standard 
"nurbs-lib-prefix" is "$prefix/lib". To fit to new compilers also 
"$prefix/lib64" should be considered automatically?!

merge branch version 3.0.0 back to the trunk 

The following examples are currently not running:

"example" ... "error in short"


electronics_dcdc_buck_converter ... "Assertion `i<m' failed"

xml_controlled_hydraulic_actuator ... "element HydraulicEnvironment: Schemas 
validity error : Element 
'{http://mbsim.berlios.de/MBSimHydraulics}HydraulicEnvironment': This element 
is not expected."

xml_chaintensioner ... "element HydraulicEnvironment: Schemas validity error : 
Element '{http://mbsim.berlios.de/MBSimHydraulics}HydraulicEnvironment': This 
element is not expected"

mechanics_initial_value_problem ... "error: cannot allocate an object of 
abstract type ‘initLink’"

mechanics_basics_simple_gear ... "void 
OpenMBV::CompoundRigidBody::addRigidBody(OpenMBV::RigidBody*): Assertion 
`rigidBody[i]->name!=rigidBody_->name' failed"

powertrain_planetary_gear ... "void 
OpenMBV::CompoundRigidBody::addRigidBody(OpenMBV::RigidBody*): Assertion 
`rigidBody[i]->name!=rigidBody_->name' failed"

xml_hydraulics_ballcheckvalve ... "element HydraulicEnvironment: Schemas 
validity error : Element 
'{http://mbsim.berlios.de/MBSimHydraulics}HydraulicEnvironment': This element 
is not expected."

mechanics_flexible_body_perlchain_cosserat ... "Speicherzugriffsfehler"

hydraulics_relative_hydraulic_proofofconcept ... "error: cannot allocate an 
object of abstract type ‘MBSim::Line’"

hydraulics_hydmec_trans ... "fatal error: mbsim/tree.h: Datei oder Verzeichnis 
nicht gefunden"

hydraulics_hydmec_rot ... "fatal error: mbsim/tree.h: Datei oder Verzeichnis 
nicht gefunden"

Wie am 28.02.2012 besprochen soll das Nurbs++ Paket eine eigene build-Routine 
bekommen. Bisher wurde es bei Bedarf mit dem Modul mbsimFlexbile mitkompiliert.

If found no delete request for the environment-class.

Implement plotting and visualisation of kinematic and kinetic values.
E.g. Frame velocity, Center of gravity position, ...

See MBSim-3.0.0

mbsim doesn't compile without the openmbv-cpp-interface due to missing 
#define-statements. please fix.