Skip to content

Changes

Page history
Updated to 2024 authored by Andrea Zanoni's avatar Andrea Zanoni
Show whitespace changes
Inline Side-by-side
GSoC-Project-Ideas.md
View page @ 3387d60f
# Ideas for Google Summer of Code projects
In this page you'll find some ideas for projects to be developed in the context of the [Google Summer of Code](https://summerofcode.withgoogle.com/). If you are a student looking forward to apply, please remember that these are just suggestions and general ideas, you are free, and actually encouraged, to propose you own project. You are also **strongly encouraged** to discuss with the regular developers your ideas before submitting an application.
In this page you'll find some ideas for projects to be developed in the context of the [Google Summer of Code](https://summerofcode.withgoogle.com/). If you are a student looking forward to apply, please remember that these are just suggestions and general ideas, you are free, and actually **strongly encouraged**, to propose you own project. You are also **strongly encouraged** to discuss with the regular developers your ideas before submitting an application.
\*\* 2021 GSoC Edition Update\*\* We updated some of the projects that you see in this list to the 2021, shortened, version of the Google Summer of Code program. Other project ideas remained pretty much unaltered, mainly because we see them mostly as general improvement frameworks, inside of which many individual projects are possible. If you are interested in working on any on them, get in contact with us in the [Issues](https://public.gitlab.polimi.it/DAER/mbdyn/-/issues) section: we will work out together a project.
\*\* 2022 GSoC Edition Update \*\* In the 2022 GSoC Edition, contributors will have the choice to submit proposals for short (175 hours) or long (350 hours). From most of the ideas you see in this list, projects of both types can be carved out. Contact us in the [Issues](https://public.gitlab.polimi.it/DAER/mbdyn/-/issues) section and we will discuss together how to structure your MBDyn GSoC project!
\*\* 2022 GSoC Edition Update \*\* In the 2022 GSoC Edition, contributors will have the choice to submit proposals for short (175 hours) or long (350 hours). From most of the ideas you see in this list, projects of both types can be carved out. Contact us in the [Issues](https://public.gitlab.polimi.it/DAER/mbdyn/-/issues) section and we will discuss together how to structure your MBDyn GSoC project!.
## Ideas by category
\*\* 2024 GSoC Edition Update \*\* In the 2024 GSoC Edition, contributors will have even more flexibility in submitting proposals. Projects can be carried out in short (90 hours), intermediate (175 hours) and long (300 hours) versions. As always, from the ideas that you see in this list, projects of all sized can be carved out, so the important thing is that you get in contact with us as soon as possible, in the [Issues](https://public.gitlab.polimi.it/DAER/mbdyn/-/issues) to discuss together how to best structure your proposal.
- **Modeling Capabilities**
- [Revamp the modal joint](#revamp-the-modal-joint)
- [Consistent inertia in beam elements](#consistent-inertia-in-beam-elements)
- [Friction in joints](#friction-in-joints)
- [Implement an Unsteady Vortex Lattice aerodynamic element](#implement-an-unsteady-vortex-lattice-aerodynamic-element)
- [Improve the cycloidal rotor module](#improve-the-cycloidal-rotor-module)
<!---
- [Ground Vehicle Model Development](#ground-vehicle-model-development)
- [Improve the tire model](#improve-the-tire-model)
- [Couple MBDyn with OpenFOAM](#couple-mbdyn-with-openfoam)
--->
- **IPC/RT**
- [Improve coupling with other software](#improve-coupling-with-other-software)
- [Improve co-simulation capabilities](#improve-co-simulation-capabilities)
- [Improve FMI support](#improve-fmi-support)
- **User Interface**
- [Python preprocessor development](#python-preprocessor-development)
- [Blendyn Development](#blendyn-development)
- [Flexible element graphical interface](#flexible-element-graphical-interface)
- **Miscellanea**
- [Test Suite Development](#test-suite-development)
- [Libraries update](#libraries-update)
- [Cascaded Analysis](#cascaded-analysis)
- [Package update](#package-update)
- [Configuration update](#configuration-update)
- [Automatic Differentiation](#automatic-differentiation)
---
---
## Modeling Capabilities
### Revamp the modal joint
MBDyn's modal joint implements a Component Mode Synthesis (CMS) deformable body. The CMS element interacts with the multibody model only in specific nodes (interface nodes). The full dynamics of the body is condensed into the superposition of the responses of its modes of vibrations, that it outputs in the form of the time histories of its modal coordinates, together with the ridig body motion of a specific node used to define the floating reference frame, the modal node.
The modal joint implementation can be improved in several different ways. For example, a possible roadmap would be:
- 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`
- `Mat3xN *pOffsetMBNodes --> std::vector`
- `Mat3xN *pRotMBNodes --> std::vector`;
- 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: 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 of modal joint in initial assembly.
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: linear algebra, physics, eigenanalysis\
**Priority**: High\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Pierangelo Masarati, Giuseppe Quaranta, Andrea Zanoni, Louis Gagnon
---
### Consistent inertia in beam elements
Currently, beam elements (much like most of the deformable structural components) only deal with the (visco-)elastic characteristic properties, whereas the modeling of the inertia properties of the component are delegated to a set of equivalent "rigid bodies", i.e. lumped inertia components.
This topic is aimed at introducing consistent inertia modeling for beam elements, i.e. inertia forces and moments are generated directly within the beam element structural component, starting from beam section inertia properties per unit span.
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: beam element, inertia properties\
**Priority**: Medium\
**Difficulty**: Low\
**Size**: 175 h\
**Mentors**: Pierangelo Masarati, Andrea Zanoni, Louis Gagnon
---
### Friction in Joints
It would be nice if every MBDyn joint could optionally add friction to its internal forces and moments.
A possible to-do list for the project would be:
- improve the friction model and add it to all or at least to some joints;
- implement contacts with non-flat surfaces.
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: mechanical friction\
**Priority**: Medium\
**Difficulty**: Intermediate\
**Size**: either 175 h or 350 h, depending on the number of joints accounted for\
**Mentors**: Marco Morandini
---
### Implement an unsteady Vortex Lattice aerodynamic element
MBDyn’s aerodynamic formulation is based on the unsteady strip theory formulation. While extremely useful to quickly obtain reasonably accurate solutions to many aeroelastic problems, it has many limitations: it is a 2D model, it relies on the availability of C81 aerodynamic coefficients' tables and the modelling of control surfaces is not feasible.
The project aims to develop an unsteady 3D vortex lattice element can be coupled with the finite volume MBDyn’s beams through the radial basis function interpolation method.
**This project will build upon the 2021 GSoC work of Shubhaditya Burela**
References:
- J. Katz & A. Plotkin, _Low-speed aerodynamics_, Cambridge Press, [link](https://www.cambridge.org/core/books/lowspeed-aerodynamics/077FAF851C4582F1B7593809752C44AE);
- J. Muruaa, R. Palacios, J. M. R. Graham, _Applications of the unsteady vortex-lattice method in aircraft aeroelasticity and flight dynamics_, Progress in Aerospace Sciences, [link](https://www.sciencedirect.com/science/article/abs/pii/S0376042112000620);
- Wikipedia page on VLM, [link](https://en.wikipedia.org/wiki/Vortex_lattice_method);
- Wikipedia page in RBF interpolation, [link](https://en.wikipedia.org/wiki/Radial_basis_function_interpolation).
**Category**: [Modeling Capabilities](#modeling-capabilities) \
**Programming Languages**: C++\
**Keywords**: aerodynamics, fluid-structure interaction, aeroelasticity \
**Priority**: Medium \
**Difficulty**: Intermediate \
**Size**: 350 h\
**Mentors**: Alessandro Cocco, Alberto Savino, Andrea Zanoni
---
<!---
### Ground vehicle model development
A [semi-trailer truck](https://www.mbdyn.org/userfiles/documents/examples/semitrailerPub.tar.bz2) model was developed in MBDyn and this was a first step into adapting the software to ground vehicle analysis. See an [animation](https://www.mbdyn.org/userfiles/documents/examples/animCamion.gif) of the truck in action. It would be nice to take some concepts used for such an analysis and implement them directly in the MBDyn code.
Some possible improvements include: - 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) - develop an output element anologous to the **aircraft instruments** element, that exposes relevant measures to potential vehicle control systems (e.g. vehicle sideslip angle, wheel angular velocities, tyre slips, yaw angular acceleration, etc.)
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: vehicle dynamics, mbdyn scripting, modules\
**Priority**: Low\
**Difficulty**: Intermediate\
**Size**: 175 h\
**Mentors**: Louis Gagnon, Andrea Zanoni
---
### Improve the tire model
The wheel4 module intends to reproduce 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.
Tentative to-do list:
- simplify the module documentation
- simplify the mathematical implementation
- implement a simpler 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
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: vehicle dynamics, modules, tire mechanics\
**Priority**: Low\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Louis Gagnon, Andrea Zanoni
---
### Couple MBDyn with OpenFOAM
The MBDyn software implements basic aerodynamic models which do not allow to properly model complex flow structures. A common approach is to rely on CFD simulations to validate the models used within MBDyn.
A more precise and faster approach would be to have the flow simulations embedded directly into the multibody dynamics model.
A preliminary model with a 1-DoF communication has been implemented and can serve as a starting point.
This project is open-ended, but some avenues for thought are:
- implement translation, rotation, or both into the fluid structure interaction approach
- allow for mesh deformation inside the flow solver, the multibody dynamics solver, or both
- use OpenFOAM as the client and MBDyn as the server for the simulation or attempt a different appproach which would require more substantial code changes to both OpenFOAM and MBDyn
Requirements:
- use MBDyn for the structural part
- use OpenFOAM for the fluid part
- provide one or more test cases that exemplify all of the features
- provide detailed installation instructions for anyone starting from the official releases of MBDyn and OpenFOAM
Documentation: If this project interests you, contact the MBDyn mailing list or the mentor to have the proper initial documentation
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: aerodynamics, fluid-structure interaction, OpenFOAM\
**Priority**: Low\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Louis Gagnon, TBD
--->
---
Furthermore, for the 2024 GSoC edition we completely re-structured the project proposals, learning from past experience.
### Improve the cycloidal rotor module
## GSoC Project Ideas
- **Pre-process**
- [Python Preprocessor Development](#python-preprocessor-development)
During the GSoC2016 a double multiple streamtube inflow model for [cycloidal rotors](https://en.wikipedia.org/wiki/Cyclorotor) was implemented into MBDyn. The code can be found [here](https://www.mbdyn.org/?News&id=28). It is desired to improve the current implementation by, for example, mitigating the following limitations:
- eliminate divergence issues by carefully checking and fixing the code;
- perform validation tests with experimental results;
- implement averaging and filtering.
For this project, the student should review the work done during 2016 and come up with his/her own suggestions.
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: aeronautics, rotorcraft\
**Priority**: Low\
**Difficulty**: Intermediate\
**Size**: 175 h\
**Mentors**: Louis Gagnon, Giuseppe Quaranta
---
## IPC/RT
### Improve coupling with other software
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 projects:
- add support for coupling with [SU2 CFD software](https://su2code.github.io/);
- 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).
**Category**: [IPC/RT](#ipc-rt)\
**Programming Languages**: C++, Python\
**Keywords**: fmi, co-simulation, Matlab, Octave, SU2, Scilab\
**Priority**: Low\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Pierangelo Masarati, Giuseppe Quaranta
---
### Improve co-simulation capabilities
Apart from improving interfaces/hooks to other popular software (during GSoC 2020, Runsen Zhang added support for force-displacement co-simulation with [Chrono::Engine](https://www.projectchrono.org/), see the module-chrono-interface/ user-defined element in modules/), a general coupling interface could also be improved from the points of co-simulation schemes:
- Decomposition techniques. Decomposition techniques used in co-simulation methods influence the stability of co-simulation obviously. A more general coupling interface should support all three decomposition types, namely force-force decomposition, force-displacement decomposition, and displacement-displacement decomposition.
- Co-simulation algorithms. Classic co-simulation algorithms can be structured as: Gauss-Seidel type, also called sequential/staggered type, or the Jacobian type, also called parallel type. It is better to provide a general coupling platform that supports these two co-simulation algorithms, to achieve parallel/sequential co-simulation with other software, or with MBDyn (MBDyn-MBDyn co-simulation).
- Extrapolation formulations. Extrapolation formulations are also essential in co-simulation with other software. A general coupling interface should provide some classic extrapolation formulations, and support the extrapolation formulations defined by users.
- Coupling by kinematic constraints. In co-simulation, different modules/subsystems can be connected through physical laws, or by kinematic constraints. For cases connected by kinematic constraints at position level, the overall system is Index 3, and stabilization methods, are usually required to obtain stable results. Therefore, the coupling interface could also involve different stabilization methods for co-simulation, such as the Baumgarte stabilization method, the projection method, and the Gear-Gupta-Leimkuhler methods.
Large projects:
- Add support for coupling with specific software (such as Matlab/Octave/Scilab, etc.), and involve the algorithmic requirements above.
- A general coupling module/element involving most algorithmic requirements above.
- MBDyn-MBDyn parallel co-simulation.
**Category**: [IPC/RT](#ipc-rt)\
**Programming Languages**: C++, Python\
**Keywords**: co-simulation\
**Priority**: Medium\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Runsen Zhang, Pierangelo Masarati, Andrea Zanoni
---
### Improve FMI support
During GSoC2016, the Functional Mock-up Interface (FMI) standard was implemented into MBDyn. The code can be seen [here](https://www.mbdyn.org/?News&id=28). The current implementation could be improved by, for example, mitigating the following limitations:
- the module does not support the string drive;
- a segmentation fault occurs if FMU with version 1.0 is used with simulation type not supported by the FMU
- requires a constant timestep for cosimulation
For this project, the student should review the work done during 2016 and come up with his/her own suggestions.
- **Modeling Capabilities**
- [Genetic Optimization Module](#genetic-optimization-module)
**Category**: [IPC/RT](#ipc-rt)\
**Programming Languages**: C++\
**Keywords**: fmi, co-simulation\
**Priority**: Low\
**Difficulty**: High\
**Size**: 350 h\
**Mentors**: Marco Morandini, Pierangelo Masarati
- **Post-process**
- [Blendyn Development](#blendyn-development)
- [Modal element visualization](#modal-element-visualization)
- [Interactive plotting tool](#interactive-plotting-tool)
---
- **IPC/RT**
- [Introduce ZeroMQ support](#introduce-zeromq-support)
- [MBDyn-DUST module](#mbdyn-dust-module)
## User Interface
## Pre-Process
### Python Preprocessor development
......@@ -319,12 +45,26 @@ The work will rely on the existing [MBDyn Python Preprocessor](https://public.gi
**Programming Languages**: Python\
**Keywords**: UI, pre-process **Priority**: Medium/High\
**Difficulty**: Low/Intermediate\
**Size**: 175 h\
**Mentors**: Andrea Zanoni\
**Mentors**: Andrea Zanoni, Alberto Savino, Andrea Colli\
**ENTRY TEST**: Complete step 1 of standard MBDyn GSoC [entry test](https://gitlab.polimi.it/Pub/mbdyn/wikis/Google-Summer-of-Code/Entry-Test), then write a simple parametric input file leveraging the Python Preprocessor.
---
## Modeling Capabilities
### Genetic Optimization Module
**TODO**
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C++\
**Keywords**: Optimization, Genetic Algorithms
**Difficulty**: Intermediate\
**Mentors**: Andrea Zanoni\
---
## Post-Process
### Blendyn development
MBDyn is a multibody dynamics solver which comes without any default graphical user interface for pre- and post-processing. There exist a few standalone post-processing tools based on [EasyAnim](https://www.mbdyn.org/?Software_Download___EasyAnim), [OpenDx](http://www.opendx.org/) and [Blender](https://www.blender.org/).
......@@ -352,7 +92,7 @@ It is simple to use and generates 3D animations that represent the exact model m
---
### Flexible element graphical interface
### Modal element graphical interface
MBDyn's modal joint implements a Component Mode Synthesis (CMS) deformable body. The CMS element interacts with the multibody model only in specific nodes (interface nodes). The full dynamics of the body is condensed into the superposition of the responses of its modes of vibrations, that it outputs in the form of the time histories of its modal coordinates, together with the rigid body motion of a specific node used to define the floating reference frame, the modal node.
......@@ -361,114 +101,49 @@ Currently, the post processing (i.e. the visualization of the superposition of t
**Category**: [User Interface](#user-interface)\
**Programming Languages**: Python\
**Keywords**: Blender, UI, post-process\
**Priority**: Low/Medium\
**Difficulty**: Intermediate\
**Size**: 175 h\
**Mentors**: Andrea Zanoni, Marco Morandini\
**Mentors**: Andrea Zanoni\
**ENTRY TEST**: Complete step 1 of standard MBDyn GSoC [entry test](https://gitlab.polimi.it/Pub/mbdyn/wikis/Google-Summer-of-Code/Entry-Test), visualize the results of your simulation using [Blendyn](https://github.com/zanoni-mbdyn/blendyn), simulate the [ssbeam](https://www.mbdyn.org/userfiles/documents/examples/ssbeam.tar.gz) MBDyn example, visualize the trajectory of at least one of the FEM nodes of the ssbeam beam model, using a software of your choice (e.g. Octave, Scilab, Python, gnuplot, ...): refer to section 8.12.32 of the MBDyn input manual to gather information about the modal element output.
---
## Miscellanea
---
### Test Suite Development
MBDyn needs a comprehensive test suite, that could be integrated to the CI/CD pipelines of Git-Lab. Whenever a commit is done on the development branch, the code should complied and the test suite should executed automatically. If a test fails, the developer should be informed about it by mail.
It would be the job of the GSoC contributor on one hand to implement the general framework for the test suite (e.g. using makefiles and python scripts) and on the other hand to implement selected test cases (e.g. based on textbook examples, literature research, existing tests from the MBDyn test library - currently mostly privately shared among developers - and/or the students own developments).
### Interactive Plotting Tool
**Category**: [Miscellanea](#miscellanea)\
**Programming Languages**: MBDyn, Python, GNU Autotools **Keywords**: testing, CI/CD\
**Priority**: High\
**Category**: [Post-process](#post-process)\
**Programming Languages**: Python\
**Keywords**: UI, post-process\
**Difficulty**: Low/Intermediate\
**Size**: either 175 or 350 h\
**Mentors**: Andrea Zanoni, Pierangelo Masarati, Marco Morandini
### Libraries Update
The internal libraries used by MBDyn have a somewhat complicated configuration and could be simplified. Some of them could be generally useful. Some ideas:
- make 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).
**Category**: [Miscellanea](#miscellanea)\
**Programming Languages**: C++, GNU autotools\
**Keywords**: libraries, software packaging\
**Priority**: High\
**Difficulty**: Intermediate\
**Size**: 350 h\
**Mentors**: Pierangelo Masarati, Marco Morandini
---
### 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; the typical use case is a static solution that prepares the initial configuration for a subsequent initial value problem.
**Category**: [Miscellanea](#miscellanea)\
**Programming Languages**: C++\
**Keywords**: simulation, model restart\
**Priority**: Medium/High\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Pierangelo Masarati, Marco Morandini
**Mentors**: Andrea Zanoni\
---
### Package Update
## IPC/RT
A number of modifications can be made to the MBDyn package to extend its usability and improve the user experience and learning curve: Some ideas:
### Introduce ZeroMQ support
- add a comprehensive test suite
- make it more compliant to GNU style
- implement CMake support
- improve Windows compatibility
**TODO**
**Category**: [Miscellanea](#miscellanea)\
**Programming Languages**: C++, GNU autotools, CMake scripting\
**Keywords**: software packaging, GNU autotools, software testing, GNU, cmake, Microsoft Windows **Priority**: Medium\
**Difficulty**: Easy\
**Size**: 175 h\
**Mentors**: Pierangelo Masarati, Louis Gagnon
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C/C++\
**Keywords**: Inter-Process Communication, Sockets
**Difficulty**: Intermediate\
**Mentors**: Andrea Zanoni\
---
### MBDyn-DUST Module
### Configuration update
**TODO**
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:
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C/C++\
**Keywords**: Inter-Process Communication, Co-Simulation
**Difficulty**: Intermediate/Advanced\
**Mentors**: Andrea Zanoni, Alberto Savino, Andrea Colli\
- 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
**TODO**
**Category**: [Miscellanea](#miscellanea)\
**Programming Languages**: C++, GNU autotools, make\
**Keywords**: software packaging, GNU autotools, make \
**Priority**: Medium\
**Category**: [Modeling Capabilities](#modeling-capabilities)\
**Programming Languages**: C/C++\
**Keywords**: Inter-Process Communication, Sockets
**Difficulty**: Intermediate\
**Size**: 175 h\
**Mentors**: Pierangelo Masarati
**Mentors**: Andrea Zanoni\
---
### 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.
This project aims at perfecting the automatic differentiation implementation of MBDyn. For example by
1. 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](http://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;
2. 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 optimize 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`)
**Category**: [Miscellanea](#miscellanea)\
**Programming Languages**: C++\
**Keywords**: simulation, automatic differentiation, code optimization\
**Priority**: Low\
**Difficulty**: Intermediate/High\
**Size**: 350 h\
**Mentors**: Pierangelo Masarati, Andrea Zanoni
\ No newline at end of file