TODO list
For Google Summer of Code (GSoC) click here.
MBDyn participated in GSoC 2015, 2016, and 2017, and is currently applying for GSoC 2018.
This page presents a list of ideas for possible future development (e.g. for Google Summer of Code; see for example MBDyn's participation in Google Summer of Code 2015)
Most projects require some knowledge of using (and programming for) Linux, because the software is mainly intended for such operating system and environment.
For more information do not hesitate to get in touch with the MBDyn community (e.g. using the mbdyn-users@mbdyn.org mailing list). In fact, please do get in touch with us to know more about these possible collaborations. It is much easier to prepare a good application for GSoC if you are already familiar with the project and the code.
If you are an experienced MBDyn user/developer, and want to become a mentor, please let us know.
The ideas presented here are a basis to stimulate interested students and developers; new ideas will happily be considered. We will also be happy to consider applications focusing on one specific item of a proposed project, as long as it justifies the amount of work planned.
Currently proposed development is grouped in these areas:
1. User Interface Components
2. Modeling Capabilities
3. Inter-Process Communication / Real-Time Simulation (IPC / RT)
4. Miscellaneous
Within each area, higher interest/priority topics come first.
1. User Interface Components
1.a Upgrade the standalone post-processing graphical interface based on Blender:
MBDyn is a tool which comes without any default graphical user interface. There exists a few standalone post-processing tools, based on EasyAnim, OpenDx and Blender, respectively. The one based on Blender is the most up-to-date; it can be easily used to visualize in 3D and render the model structure. However, there is room for improvement; for example, to plot time histories of selected variables, to show import progress and allow interrupting it, set the initial and final time of the import, automatically adjust timesteps when the results file changes, show time in seconds during animation, and allow to individually import elements even when there are no Blender objects in the scene. Other more complex improvements may be to
- complete the visualization of elements or simply of their "internal" reference frames (currently only an example case is present in the code)
- update MBDyn's input file when moving an object in the Blender interface which is linked to a MBDyn element
- allow running MBDyn directly from the Blender interface and animate the results in realtime
- allow importing the kinematics directly from NetCDF binary result files instead of from the general text-only output files.
Programming skills involved: Python, Blender
Skill level: easy/medium
1.b Preprocessing simplification
In its current state, owing to the absence of an interface it may be difficult for new users to understand the MBDyn scripting language. It would be beneficial to have an interface which simplifies and clarifies the generation of MBDyn input files, e.g. to produce "vertical" applications. For example, a Python pre-processor could be implemented, to produce valid MBDyn scripts.
Programming skills involved: (scripting) languages, MBDyn script
Skill level: easy/medium
1.c Flexible element graphical interface
Add flexible superelement (“modal” joint) support to existing post-processing tools (e.g. Blender, EasyAnim)
Programming skills involved: C++, Python, Blender, Finite Element Analysis
Skill level: easy/medium
1.d Additional preprocessing functionalities and driver options
The current MBDyn parser has a clear and consistent language. However, it does not let the user define if-else conditions, for-while loops, arrays of variables, and use of variables in the strings of node and element drives definitions. This leads the users to often rely on external scripting (e.g. Matlab or Python) to generate their own input files. This supplementary step creates additional opportunities for bugs to appear within a model. Adding these features directly to the MBDyn parser would thus make the generation of complex multibody models much simpler and more focused.
Another functionality which would simplify the generation of input files would be to allow defining drives with multiple inputs. A string drive with such a feature could be: "(Var1 < Var2) * Var3" and could also allow access to the value of a drive at times different from the current time (offset from the current time). These improved drive options could be implemented in a similar fashion than the node and element plugin variables.
Programming skills involved: C++, MBDyn scripting
Skill level: medium
2. Modeling Capabilities
2.a Revamp modal joint
- break down the modal joint element into a set of elements/components:
- modal database: FEM model; split const ( = instantiated once) and local (= duplicated) data;
- place const data in shared database, local data in modal joint; avoid unnecessary copy of memory;
- use standard containers for structured data
for example,
+ Mat3xN *pOffsetFEMNodes --> std::vector<Vec3> (same as d1rig?)
+ Mat3xN *pOffsetMBNodes --> std::vector<Vec3> (same as d2?)
+ Mat3xN *pRotMBNodes --> std::vector<Mat3x3> (not used???)
- define a modal dynamics as a "deformable body" element (the structural dynamics part of the existing element)
- define a modal clamp constraint element (as it is now, but separate from dynamics element)
- add a total modal joint (Was: specialized modal constraints, as opposed to clamping a node with the clamp constraint plus a regular joint) this makes it possible to add arbitrary elements connected to the modal element
- add support for “reference” definition based on modal database geometry
- implement/fix support for modal joint in initial assembly
Programming skills involved: C++
Skill level: easy/medium
2.b Ground vehicle model development
A semi-trailer truck model was recently developed in MBDyn script and this was a first step into adapting the software to ground vehicle analysis. It would be nice to take some concepts used for such an analysis and implement them directly in the MBDyn code.
- take the scripting tricks and joints used in the truck model and incorporate them directly into the MBDyn code
- improve the MBDyn output to include car, truck, and general ground vehicle data
- implement a set of general procedures to carry-on with a vehicle model (ie: SAE testing procedures for fuel consumption, stability, and maneuverability)
Programming skills involved: C++, MBDyn scripting, basic vehicle mechanics
Skill level: medium
2.c Wheel (tire model) module improvements
The wheel module developed in MBDyn models the dynamic behavior of tires using a rigid ring type of model. During the development of the module, various avenues were envisioned to accelerate the resolution procedure. The documentation and parameter definition of the model would also benefit from a simplification.
- simplify the module documentation
- simplify the mathematical implementation
- implement a clear parameter definition method
- add camber variation effects
- filter the road profile directly inside MBDyn instead of during preprocessing with other computing environments (e.g. Octave or Matlab)
- implement a lateral tire section profile (currently, only the longitudinal profile is considered by the model)
- simplify the ability to change the orientation of the tire
Programming skills involved: C++, linear algebra, latex, basic tire dynamics
Skill level: medium-advanced
2.d Friction in joints
Friction is not present in all joints from MBDyn, it would however be a nice feature to have it. Thus,
- improve friction and add it to all joints (suggestion: try a transition force from stick to slip that is higher than slip force)
- implement contacts with non-flat surfaces
Programming skills involved: C++, mechanical friction
Skill level: medium
2.e Cycloidal rotor module improvements
The cyclocopter module currently available in MBDyn models the inflow of a cycloidal rotor. It is however limited to 2D aerodynamics models; moreover, the implementation of the double multiple streamtube model is not yet stable. There are different approaches one may take to improve the code,
- improve the existing double multiple streamtube code (requires aerodynamic skills), or
- add a supplementary inflow model, using an external CFD solver such as OpenFOAM (requires CFD skills), or
- implement a panel code within MBDyn, possibly starting from the already existing vortexje-mbdyn implementation (https://github.com/tuhh-sn/vortexje-mbdyn) (realistic for someone new to aerodynamics)
Programming skills involved: C++
Skill level: medium
3. Inter-Process Communication / Real-Time Simulation (IPC / RT)
3.a FMI model exchange and co-simulation standard
Over the years, various interfaces to popular modeling software have been developed, in some cases even duplicated. However, the implementation in some cases remains unreliable. A good coupling interface rework is needed.
The most promising approach is to integrate into MBDyn an interface
that is based on the Functional Mock-up Interface (FMI) standard,
see https://www.fmi-standard.org/start.
Different libraries do exist to ease the effort, e.g. https://www.fmi-standard.org/downloads.
The work can be split into independent tasks, in order of priority (high to low).
- allow MBDyn to perform co-simulations as master
- allow MBDyn to import models
- allow MBDyn to perform co-simulations as slave
- allow MBDyn to export models
Programming skills involved: C++, scripting
Skill level: medium/advanced
3.b Flight dynamics module
Develop a generic flight dynamics module based on MBDyn and a generic interface with a flight simulation system. Use FlightGear for prototyping the system.
Programming skills involved: C++
Skill level: medium-difficult
3.c Implement or perfect the existing hooks to Matlab, Octave, Simulink, Scilab, and OpenFOAM
Over the years, various interfaces to popular modeling software have been developed, in some cases even duplicated. However, the implementation in some cases remains unreliable. A good coupling interface rework is needed:
- improve MATLAB hooks
- streamline Octave hooks
- add/improve Scilab hooks
- add/improve MATLAB/Octave/Scilab and Simulink/Scicos co-simulation interface.
Large project: turn MBDyn into a module for Simulink/Scicos (see contrib/SimulinkInterface/ ; need an implicit extension)
- add package-wide support for WinSocks in communication entities, including SimulinkInterface and ScicosInterface (using MSYS/MinGW)
Programming skills involved: C++, Matlab/Octave/Scilab/OpenFOAM
Skill level: medium
4. Miscellaneous
4.a Libraries update
The internal libraries used by MBDyn have a somewhat complicated configuration and could be simplified. Some of them could be generally useful. Specifically,
- make the libraries installable
- abstract libraries in a rational manner, to reduce/eliminate cross-dependencies
- replace standard features from broadly available libraries (e.g. STL, Boost); an example is to use shared pointers for features like constitutive laws, drive callers and so forth when useful (native C++ 2011 shared pointers are experimentally in use in some portions of code).
Programming skills involved: C++ libraries
Skill level: medium
4.b Package update
A number of modifications can be made to the MBDyn package to extend its usability and improve the user experience and learning curve:
- add a comprehensive test suite
- make it more compliant to GNU style
- improve windows compatibility
Programming skills involved: MBDyn, Linux
Skill level: easy
4.c Configuration update
The configuration of MBDyn can benefit from some improvements which would make it easier to use by a greater number of users. The tasks involved are:
- test for '_' appended to F77 symbols (recent autoconf does that), (or better: remove all F77 code)
- audit all the suite for not-so-GNU systems
- add check for make
Programming skills involved: autotools, make, Linux, compilation
Skill level: easy-medium
4.d Step size control
Implementation of an error estimator and automatic step size control.
Programming skills involved: C++
Skill level: easy-medium
4.e Cascaded analysis
Add support for cascaded models and solutions with rules for each solution to inherit the initial configuration from the final solution of another solution, possibly through "hard" restart; the typical use case is a static solution that prepares the initial configuration for a subsequent initial value problem.
Programming skills involved: C++
Skill level: medium-difficult
4.f Automatic differentiation
Automatic differentiation is a technique for generating the Jacobian matrix automatically, needed for the nonlinear solver, given the information of the residual vector which is coded in C++ language. At the moment almost all elements in MBDyn are using a hand-written contribution to the Jacobian matrix. That approach is time consuming, error prone and difficult to maintain. In addition to that, there is no easy way to check for the correctness of the Jacobian matrix.
Automatic differentiation is also implemented in MBDyn but it is still less efficient in terms of CPU time and size of generated machine code.
- Perform different benchmarks with open source template meta programming libraries for the matrix/vector domain like blitz++, armadillo and eigen3 and also for the scalar (automatic differentiation) domain like Adolc and CppAD.
Check also for recent papers in the area of automatic differentiation and template meta programming (e.g. on www.autodiff.org).
Create a report about the techniques those libraries are using (aliasing, lazy evaluation, common sub-expressions, order of memory access, code generation, or just in time code generation, tape mode or tapeless mode, sparse Jacobians). That report also should show how efficient those libraries are in comparison to our current implementation in terms of CPU time and code size. In addition to that it should show how hardware techniques like vectorization (sse/avx) and intrinsic functions of compilers are exploited.
- Use a different approach for evaluation of template meta expressions: Instead of scalar domain template meta programs and matrix/vector domain template meta programs, only one domain should be used in order to make it easier for the compiler to optimise the code in terms of CPU time and size of machine code. Make use of the most promising techniques from 1) for the implementation. This part is probably the most difficult task because large parts of the existing library have to be redesigned.
However a prototype implementation, which covers the most critical operation, namely the matrix-matrix products, is available and performs even better than equivalent Fortran code.
The following topics should be considered:
- Not all loops should be unrolled in order to reduce code size. In that way the instruction cache should be used less intensively and stall conditions of the CPU should be avoided.
- Add support for matrices and vectors with dynamic size.
- Automatically create temporary results for sub-expressions which are evaluated more than once.
- Implement a simple “cost model” in order to decide whether to create a temporary sub-expression or not.
- Use sequential memory access whenever possible.
- Use explicit vectorization for all derivatives and also for matrix vector products if the compiler supports it.
- Check for aliasing at compile time or at least at runtime. If runtime checking is required, checks should be done in debug mode only.
- Check if the __restrict__ keyword of C++ can help to improve performance.
- Perform benchmarks with Fortran code generated by automatic differentiation by source code transformation at different optimization levels (-O2, -O3, -Os).
Programming skills involved: C++
Skill level: easy-medium
4.g Velocity-level kinematic constraints
Implement velocity-level kinematic constraints for index reduction, and assess accuracy and numerical stability improvements vs. additional computational cost.
Programming skills involved: C++, multibody dynamics
Skill level: easy-medium
4.h Documentation update
- document the utilities in a separate man page (utils & scripts)
- update and audit the input manual (partially DONE)
- document output (partially DONE)
- document element private data names (partially DONE)
Programming skills involved: latex, MBDyn scripting, and possibly C++
Skill level: easy
More ideas can also be taken from our TODO lists:
Code:
Large Projects:
- implement binary, or hard, restart
- remove node/element type listing from "control data" block; use STL containers to keep track of model components (support partially DONE for elements, drivers and nodes)
- implement "smart" structural nodes, so that static/dynamic is detected
- implement optional binary/ascii output (NetCDF support partially DONE)
- abstract NetCDF use for aggregate data (e.g. Vec3); (partially DONE)
- add relative reference frame overall dynamics (modal element, gravity (?))
- add absolute/relative reference frame dynamics interface
- generalize inflow models for fixed wing lifting surfaces (partially DONE)
Medium Projects:
- recover existing soft restart
- add a "shell" (supporting scripting languages) element that executes external programs, and allow exploitation for entities like elements, drives, constitutive laws and so
- develop a trim control as external command that drives simulations.
- review output to allow selective ascii/binary output (partially DONE; see NetCDF)
- add friction to contacts
- rework modal element to use momentum and momenta moment instead of linear and angular velocities (so that a regular "dynamic" node can be used instead of the "modal" node)
- rework revolute joints to allow normal force to be computed as a combination of constraint reactions (based on constraint geometry)
- implement modal element binary data using NetCDF:
.fem:
femgen > ascii
femgen > netcdf
mbdyn < ascii > netcdf
.mod:
mbdyn > ascii
mbdyn > netcdf (in global output database)
- add sparse eigenvalue extraction (DONE, using ARPACK; check & improve)
- add matrix scaling (partially DONE; needs extensive testing)
Small Projects:
- add variant of "component" template drive caller that can be re-oriented using a constant rotation matrix.
- "shell" element, drive and so that executes unix commands including scripts, significantly matlab scripts (see module-octave).
- move critical Reynolds numbers from constants to fluid properties with pressure/temperature dependencies.
- add Reynolds dependence to AeroData
- improve symbolic constitutive law (based on GiNaC)
- move GiNaC constitutive laws and drives into a run-time loadable module
- move exception handling towards <stdexcept> (DONE otherwise)
- review/improve user-configurable statistics output (partially DONE; see "output:" statement in "problem" data block)
- add Matlab/Octave-compatible sparse matrix generation for sparse matrix eigenvalue analysis ("eigs"); (DONE)
- add selected output streamed on sockets for interactive analysis by implementing sort of "sensors", possibly based on the elements' "private data" (DONE; see "output elements" and RTAI-related features)
- add rot2any/any2rot utilities
- try to rewrite hydraulic nodes as scalar differential (?)
- add joints like:
- 2-node clamp (spherical + prismatic) (DONE: "total joint" family)
- "inplane" and "inline" between a node and the ground (DONE: "total pin joint")
- link to Taucs sparse solver: http://www.tau.ac.il/~stoledo/taucs (Marco Morandini is working at it)
- add aircraft instruments as sensors (e.g. writing measures to parameter nodes; refer to http://www.allstar.fiu.edu/aero/FlightIns.htm ):
- airspeed indicator
- ground speed indicator
- altimeter
- attitude indicator (pitch and bank)
- turn and slip indicator
- vertical speed indicator
- angle of attack indicator
(partially DONE: the "aircraft instruments" element provides measures as private data, and as output to .aer files).
- allow the FEM data filename as command-line arg in utils/femgen
- add orthogonality test when reading orientation matrix (DONE, with optional tolerance; warning only)
- append constitutive law output, if any, to elements' output (DONE infrastructure, shock absorber and rods)
- merge tool to generate ADAMS/View .cmd models from raw output (Gian Luca Ghiringhelli is working at it; OBSOLETE)
- add piecewise linear or other simple generic elastic constitutive laws (DONE: scalar function-based CL)
- generate a binary form of the .fem data for the modal element that can be loaded instead of the text version according to time stamps, to speed-up large models input (DONE)
- add an optional configuration-dependent constitutive law to the unconstrained displacements/rotations of selected joints:
- the revolute family (DONE differently: see the "deformable axial joint")
- ...
- implement an output trigger (replaces output frequency; DONE)
- modal element:
- add singularity checks (warn if modal k is singular; ???)
- add consistency checks of modal mass matrices (m = X^T*M*X; DONE)
- modal interface node: accelerations can be recovered for use in loose connections; design and implement a solution (DONE)
- use getopt(3) in utils/*
- use 3D (or 6D) templates for force and couple elements, preserving backward compatibility of the input as much as possible (DONE, 3D)
- add modal constraint: framework for generic constraints among modal variables; constraint that imposes the value of modal vars
- add "static" modal element (no dynamics equations)
- allow deformable hinge to have optional (useless) "position" spec
- output of incremental Euler vector (?)
- add elastic and viscous variants of linear time variant const law
- add record for damping matrix to modal input format (DONE, RECORD 13)
- define a UserDefinedElem class; inherit LoadableElem from it; allow UserDefined elements to be loaded run-time (obsoletes LoadableElem; UserDefinedElem, DONE)
- let symbolic constitutive law optionally know about "Time" & so
- allow math parser to generate expression tree (bison?, DONE, reusing MBDyn's parser to create expression tree, with contributions from Ankit Aggarwal within Google Summer of Code 2015)
- allow to switch on/off iteration, residual, ... output with meter
- allow configurable float, int, bool (string?) & hton in stream I/O (DONE [no hton], check)
- allow to specify parameters independently for each eigenanalysis
- implement coaxial rotor inflow model (which?)
- allow strain sign in hunt-crossley (now cont-contact) module (DONE; in all constitutive laws?)
- exponential viscoelastic const law 1D
Bugs/missing features:
- modal joint private data:
- currently uses lowercase "x", "w" to access FEM node motion in absolute frame; this is inconsistent with structural nodes, which use uppercase "X", "Omega", reserving "x", "omega" for motion in node frame
- no access to FEM node orientation is available
- access to FEM node motion also in modal joint reference frame would be desirable
- eliminate nasty dependence from f2c typedef's (doublereal and so)
- check "universal pin"
- fix etc/modal.d/MBDyn_NASTRAN_alter_[1-2].nas; allow the use of node sets to reduce the amount of FEM nodes that are passed to the model element (e.g. no nodes without inertia that do not participate in the interface)
- clarify how to increase the size of models utils/femgen can handle (change parameter(maxnod=20000,maxmod=1000) accordingly?)
- introduce references for hints (?)
- allow strings as mode names in modal elements (joint, force, ...)
- add SetInitialValue to modal element
- check initial assembly of joints in slidercrank_r example
- allow 0 modes in modal element (nearly useless, except for testing)
- UseSocket without host listens only on localhost (BY DESIGN)
- allow (configurable) preamble in communications with pairs {string,value}
- rework rejected modes handling in modal joint
- check initial assembly of "distance" when nodes velocity is not null
- check & fix NetCDF library detection
- allow re-orientation of FEM reference system in modal node
- allow offset & re-orientation of exported motion in external structural [mapping]
- optionally send "delta" instead of position in external structural [mapping]
- support float instead of double in NetCDF output
- support "med" in output
- reject "mt" from naive when configured without support
- allow "mt" from command-line (DONE; "-N" switch)
- allow make of mod-* and moddae-* modules
- implement support for pardiso linear solver when compiled with icc (need icc...)
- check "new" distance joint
- take care of nodes with output "off" in mbdyn2easyanim.sh
- allow "relative" node view in EasyAnim
- GetPosAbs/GetRotAbs dependent on other (pos, rot, ...) (WONTFIX; use Get.*Rel(AbsRefFrame, ...) instead)
- module-loadinc: improve initialization and handling of driven load increment element
- math parser: handle uninitialized values (DONE?)
- add capability to run-time load a generic (context-dependent?) "description" (generic DONE; context-dependent TODO)
|
