|
|
# 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 **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!.
|
|
|
|
|
|
**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 (350 hours) versions. As you can see from the ideas 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.
|
|
|
|
|
|
Furthermore, for the 2024 GSoC edition we completely re-structured the project proposals, learning from past experience.
|
|
|
|
|
|
## GSoC Project Ideas
|
|
|
- **Pre-process**
|
|
|
- [Python Preprocessor Development](#python-preprocessor-development)
|
|
|
|
|
|
- **Modeling Capabilities**
|
|
|
- [Genetic Optimization Module](#genetic-optimization-module)
|
|
|
|
|
|
- **Post-process**
|
|
|
- [Blendyn Development](#blendyn-development)
|
|
|
- [Complete NetCDF output implementation](#complete-netcdf-output-implementation)
|
|
|
|
|
|
- **IPC/RT**
|
|
|
- [Introduce ZeroMQ support](#introduce-zeromq-support)
|
|
|
- [MBDyn-DUST module](#mbdyn-dust-module)
|
|
|
|
|
|
## Pre-Process
|
|
|
|
|
|
### Python Preprocessor development
|
|
|
|
|
|
The [MBDyn Python Preprocessor](https://public.gitlab.polimi.it/DAER/mbdyn/tree/develop/contrib/PythonPreprocessor) is a tool that is currently intended to support and speed up the generation of input files, integrating the standard MBDyn input syntax with Python code. The preprocessor parses an input file searching for Python code wrapped by `#beginpreprocess` and `#endpreprocess` tags, and processes it generating portions of the final input file. See the examples in [contrib/PythonPreprocessor/examples](contrib/PythonPreprocessor/examples).
|
|
|
|
|
|
The aim is to enable the user to write a complete MBDyn model, from scratch, only using Python. The development of other preprocessing tools, for example GUI-based, will then be greatly facilitated.
|
|
|
|
|
|
The development process will be incremental:
|
|
|
|
|
|
1. extending the library of entities supported by the Preprocessor to cover all the available entities (up to here, this is a **90 hours project**):
|
|
|
- drive callers
|
|
|
- constitutive laws
|
|
|
- drivers
|
|
|
- nodes
|
|
|
- elements
|
|
|
2. adding classes that manage the MBDyn input file blocks defining the general behavior of the model and simulation:
|
|
|
- initial value
|
|
|
- control data
|
|
|
3. adding a class to hold an entire MBDyn Model (up to here, this is a **175 hours project**)
|
|
|
4. integrating the Python Preprocessor into Blendyn
|
|
|
5. adding special preprocessing procedures for flexible elements (meshing)
|
|
|
6. integrating in the Preprocessor special methods to generate parametric aeroelastic models of rotary-wing aicraft (getting here, will require a full **350 hours project**
|
|
|
|
|
|
NOTE: the work will start from on the existing [MBDyn Python Preprocessor](https://public.gitlab.polimi.it/DAER/mbdyn/tree/develop/contrib/PythonPreprocessor) code and possibly on the code written by [Aditya Baghat](https://gitlab.com/adityabhagat99) during the 2019 Google Summer of Code, that intended to build the groundworks for a FreeCAD GUI preprocessor. The repository holding Adityia code can be found [here](https://gitlab.com/zanoni-mbdyn/mbdynfreecadgui).
|
|
|
|
|
|
**Category**: [User Interface](#user-interface)\
|
|
|
**Programming Languages**: Python\
|
|
|
**Difficulty**: Low/Intermediate\
|
|
|
**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), compiling MBDyn from the `preprocess` branch, then write a simple parametric input file leveraging the Python Preprocessor. If you can, try to add support for a new MBDyn entity (e.g. a Drive Caller, see Section 2.6 of the Input Manual).
|
|
|
|
|
|
---
|
|
|
|
|
|
## Modeling Capabilities
|
|
|
### Genetic Optimization Module
|
|
|
|
|
|
The purpose of this project is to develop and MBDyn [module](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/home#what-are-run-time-loadable-modules-and-how-do-they-work) which implements a [genetic algorithm](https://en.wikipedia.org/wiki/Genetic_algorithm) (GA) which will solve optimization problems inside an MBDyn simulation run.
|
|
|
|
|
|
The module will implement a *super-element*, i.e. an element that will take inputs from a series of drives (which, in turn, can expose other entities private data) and output one or more optimized variables to another set of drives. The main structure will be similar to the one of the [hfelem module](modules/module-hfelem/module-hfelem.cc).
|
|
|
|
|
|
In their basic form, GAs are extremely simple to implement, therefore the preferred way in this GSoC project will be to develop one from scratch and keep external dependencies to a minimum. Linking of external GA optimization libraries will be considered only after a satisfactory level of functionality is reached with the *in-house* code.
|
|
|
|
|
|
Implementing the baseline GA solver, with the minimum required flexibility to be usable, is a **175 hours** project.
|
|
|
|
|
|
Developing a fully-featured GA solver, plus structuring the module so that also external GA optimization libraries can be linked is a **350 hours project**.
|
|
|
|
|
|
**Category**: [Modeling Capabilities](#modeling-capabilities)\
|
|
|
**Programming Languages**: C++\
|
|
|
**Keywords**: Optimization, Genetic Algorithms\
|
|
|
**Difficulty**: Intermediate/Advanced\
|
|
|
**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/).
|
|
|
|
|
|
However, [Blendyn](https://github.com/zanoni-mbdyn/blendyn), based on [Blender](https://www.blender.org/), is the most up-to-date.
|
|
|
|
|
|
See some example [videos](https://youtu.be/x5n0OgskIMc?list=PLTtFbiep140gc-f-x14ltv0N7YZNzvioF) of its output and the [tutorials](https://github.com/zanoni-mbdyn/blendyn/wiki/Tutorials) to understand better what Blendyn is about.
|
|
|
|
|
|
It is simple to use and generates 3D animations that represent the exact model movement and joints. Blendyn has got a great push in the development in the 2017 edition of the GSoC by the work of [Reddy Janga](https://github.com/janga1997) and the 2022 edition by [Do Tieng Dung](https://github.com/BryanGsep), but some desirable features are still missing and several other need completion of fixing. For example:
|
|
|
|
|
|
- only fixed timestep simulation output is currently supported, variable timestep should be allowed also
|
|
|
- support the live plotting of MBDyn signals, for example leveraging the NetCDF output `sync` feature
|
|
|
- support the plotting of signals derived from arbitrary compositions of MBDyn signals (e.g. the sum of two signals) (up to here, this is a **90 hours project**)
|
|
|
- support for the visualization of specific models, like for example aeroelastic models of rotary wing aicraft, biomechanical models of the human body, ecc... (getting here will require **175** or **350 hours**, depending on how many possibilities for specific models are introduced)
|
|
|
|
|
|
**Category**: [User Interface](#user-interface)\
|
|
|
**Programming Languages**: Python\
|
|
|
**Keywords**: Blender, UI, post-process\
|
|
|
**Difficulty**: Low/Intermediate\
|
|
|
**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), then use the Blender Python API (or console) to create a simple Blender model
|
|
|
|
|
|
---
|
|
|
|
|
|
### Complete NetCDF output implementation
|
|
|
|
|
|
MBDyn can output simulation results in [NetCDF](https://www.unidata.ucar.edu/software/netcdf/) format, speeding up significantly the manipulation of output data for visualization and processing. Currently, the support for binary output is still not complete among all the MBDyn entitites. For example, drives are currently not supported, nor are numerous user-defined elements contained in [modules](home#what-are-run-time-loadable-modules-and-how-do-they-work).
|
|
|
|
|
|
The aim of this project is to add the support for binary output to all the missing entities. A vast library of examples can be obtained simply looking at the current implementation for the supported entities.
|
|
|
|
|
|
The roadmap can be the following one:
|
|
|
- complete the binary output of 'standard' elements (e.g. plates are currently missing)
|
|
|
- add the binary output of reference frames
|
|
|
- add the binary output of drives (up to here, this is a **90 hours project**)
|
|
|
- complete the binary output of elements defined in [modules](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/home#what-are-run-time-loadable-modules-and-how-do-they-work)
|
|
|
- enable the user to output to NetCDF also solver diagnostics (e.g. residuals, iterations, jacobians) (up to here, this is a **175 hours project**)
|
|
|
|
|
|
|
|
|
**Category**: [Post-process](#post-process)\
|
|
|
**Programming Languages**: C++\
|
|
|
**Keywords**: post-process, NetCDF\
|
|
|
**Difficulty**: Low\
|
|
|
**Mentors**: Andrea Zanoni
|
|
|
|
|
|
---
|
|
|
|
|
|
## IPC/RT
|
|
|
|
|
|
### Introduce ZeroMQ support
|
|
|
|
|
|
MBDyn offers several possibilities to communicate with external processes: UNIX sockets, RTAI mailboxes or standard TCP/UDP sockets can be used to exchange data.
|
|
|
|
|
|
The purpose of this project is to add the support to [ZeroMQ](https://zeromq.org), an universal messaging library supporting the creation of high-level network structures and patterns.
|
|
|
|
|
|
The desired output is the implementation of a new `zeromq` `socket type` for the `Stream` `File Driver` and the `Stream Output`, which can allow to set up the desired pattern for the inboard or outboard data flow (Request/Reply, Pub/Sub, Pipeline, etc...)
|
|
|
|
|
|
Depending on the amount of flexibility/implemented features, this project can be scoped at **175 hours** or **350 hours**.
|
|
|
|
|
|
**Category**: [Modeling Capabilities](#modeling-capabilities)\
|
|
|
**Programming Languages**: C/C++\
|
|
|
**Keywords**: Inter-Process Communication, Sockets\
|
|
|
**Difficulty**: Intermediate\
|
|
|
**Mentors**: Andrea Zanoni
|
|
|
|
|
|
### MBDyn-DUST Module
|
|
|
|
|
|
MBDyn can be coupled with external software, allowing it to be inserted into co-simulation pipelines. The most common application is Fluid-Structure Interaction (FSI), which is the field for which MBDyn was initially developed.
|
|
|
|
|
|
[DUST](https://public.gitlab.polimi.it/DAER/dust) is a mid-fidelity aerodynamic solver, designed to provide fast estimated good enough for aircraft conceptual design. It is based on an
|
|
|
integral boundary element formulation of the aerodynamic problem and vortex-particle modelling of the wakes.
|
|
|
|
|
|
MBDyn is currently typically coupled with DUST using [preCICE](https://precice.org/). However, for most applications, this is a rather unnecessary complication, since all is requested from [preCICE](https://precice.org/) is to make the two software exchange data at each timestep and give each other the OK to go to to the next step at convergence.
|
|
|
|
|
|
This project aims at developing an *in-house* solution for the coupling, in the form of a MBDyn [module](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/home#what-are-run-time-loadable-modules-and-how-do-they-work). It will follow a similar pattern as the one from the 2020 GSoC edition from [Runsen Zhang](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/GSoC-Students-Blogs#a-user-defined-runtime-loadable-module-template-for-co-simulation-with-chronoengine), who created a template module for the co-simulation of MBDyn and [Chrono](https://projectchrono.org/).
|
|
|
|
|
|
**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
|
|
|
|
|
|
--- |
|
|
# 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 **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!.
|
|
|
|
|
|
**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 (350 hours) versions. As you can see from the ideas 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.
|
|
|
|
|
|
Furthermore, for the 2024 GSoC edition we completely re-structured the project proposals, learning from past experience.
|
|
|
|
|
|
## GSoC Project Ideas
|
|
|
- **Pre-process**
|
|
|
- [Python Preprocessor Development](#python-preprocessor-development)
|
|
|
|
|
|
- **Modeling Capabilities**
|
|
|
- [Genetic Optimization Module](#genetic-optimization-module)
|
|
|
|
|
|
- **Post-process**
|
|
|
- [Blendyn Development](#blendyn-development)
|
|
|
- [Complete NetCDF output implementation](#complete-netcdf-output-implementation)
|
|
|
|
|
|
- **IPC/RT**
|
|
|
- [Introduce MAVLink support](#introduce-mavlink-support)
|
|
|
- [MBDyn-DUST module](#mbdyn-dust-module)
|
|
|
|
|
|
## Pre-Process
|
|
|
|
|
|
### Python Preprocessor development
|
|
|
|
|
|
The [MBDyn Python Preprocessor](https://public.gitlab.polimi.it/DAER/mbdyn/tree/develop/contrib/PythonPreprocessor) is a tool that is currently intended to support and speed up the generation of input files, integrating the standard MBDyn input syntax with Python code. The preprocessor parses an input file searching for Python code wrapped by `#beginpreprocess` and `#endpreprocess` tags, and processes it generating portions of the final input file. See the examples in [contrib/PythonPreprocessor/examples](contrib/PythonPreprocessor/examples).
|
|
|
|
|
|
The aim is to enable the user to write a complete MBDyn model, from scratch, only using Python. The development of other preprocessing tools, for example GUI-based, will then be greatly facilitated.
|
|
|
|
|
|
The development process will be incremental:
|
|
|
|
|
|
1. extending the library of entities supported by the Preprocessor to cover all the available entities (up to here, this is a **90 hours project**):
|
|
|
- drive callers
|
|
|
- constitutive laws
|
|
|
- drivers
|
|
|
- nodes
|
|
|
- elements
|
|
|
2. adding classes that manage the MBDyn input file blocks defining the general behavior of the model and simulation:
|
|
|
- initial value
|
|
|
- control data
|
|
|
3. adding a class to hold an entire MBDyn Model (up to here, this is a **175 hours project**)
|
|
|
4. integrating the Python Preprocessor into Blendyn
|
|
|
5. adding special preprocessing procedures for flexible elements (meshing)
|
|
|
6. integrating in the Preprocessor special methods to generate parametric aeroelastic models of rotary-wing aicraft (getting here, will require a full **350 hours project**
|
|
|
|
|
|
NOTE: the work will start from on the existing [MBDyn Python Preprocessor](https://public.gitlab.polimi.it/DAER/mbdyn/tree/develop/contrib/PythonPreprocessor) code and possibly on the code written by [Aditya Baghat](https://gitlab.com/adityabhagat99) during the 2019 Google Summer of Code, that intended to build the groundworks for a FreeCAD GUI preprocessor. The repository holding Adityia code can be found [here](https://gitlab.com/zanoni-mbdyn/mbdynfreecadgui).
|
|
|
|
|
|
**Category**: [User Interface](#user-interface)\
|
|
|
**Programming Languages**: Python\
|
|
|
**Difficulty**: Low/Intermediate\
|
|
|
**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), compiling MBDyn from the `preprocess` branch, then write a simple parametric input file leveraging the Python Preprocessor. If you can, try to add support for a new MBDyn entity (e.g. a Drive Caller, see Section 2.6 of the Input Manual).
|
|
|
|
|
|
---
|
|
|
|
|
|
## Modeling Capabilities
|
|
|
### Genetic Optimization Module
|
|
|
|
|
|
The purpose of this project is to develop and MBDyn [module](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/home#what-are-run-time-loadable-modules-and-how-do-they-work) which implements a [genetic algorithm](https://en.wikipedia.org/wiki/Genetic_algorithm) (GA) which will solve optimization problems inside an MBDyn simulation run.
|
|
|
|
|
|
The module will implement a *super-element*, i.e. an element that will take inputs from a series of drives (which, in turn, can expose other entities private data) and output one or more optimized variables to another set of drives. The main structure will be similar to the one of the [hfelem module](modules/module-hfelem/module-hfelem.cc).
|
|
|
|
|
|
In their basic form, GAs are extremely simple to implement, therefore the preferred way in this GSoC project will be to develop one from scratch and keep external dependencies to a minimum. Linking of external GA optimization libraries will be considered only after a satisfactory level of functionality is reached with the *in-house* code.
|
|
|
|
|
|
Implementing the baseline GA solver, with the minimum required flexibility to be usable, is a **175 hours** project.
|
|
|
|
|
|
Developing a fully-featured GA solver, plus structuring the module so that also external GA optimization libraries can be linked is a **350 hours project**.
|
|
|
|
|
|
**Category**: [Modeling Capabilities](#modeling-capabilities)\
|
|
|
**Programming Languages**: C++\
|
|
|
**Keywords**: Optimization, Genetic Algorithms\
|
|
|
**Difficulty**: Intermediate/Advanced\
|
|
|
**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/).
|
|
|
|
|
|
However, [Blendyn](https://github.com/zanoni-mbdyn/blendyn), based on [Blender](https://www.blender.org/), is the most up-to-date.
|
|
|
|
|
|
See some example [videos](https://youtu.be/x5n0OgskIMc?list=PLTtFbiep140gc-f-x14ltv0N7YZNzvioF) of its output and the [tutorials](https://github.com/zanoni-mbdyn/blendyn/wiki/Tutorials) to understand better what Blendyn is about.
|
|
|
|
|
|
It is simple to use and generates 3D animations that represent the exact model movement and joints. Blendyn has got a great push in the development in the 2017 edition of the GSoC by the work of [Reddy Janga](https://github.com/janga1997) and the 2022 edition by [Do Tieng Dung](https://github.com/BryanGsep), but some desirable features are still missing and several other need completion of fixing. For example:
|
|
|
|
|
|
- only fixed timestep simulation output is currently supported, variable timestep should be allowed also
|
|
|
- support the live plotting of MBDyn signals, for example leveraging the NetCDF output `sync` feature
|
|
|
- support the plotting of signals derived from arbitrary compositions of MBDyn signals (e.g. the sum of two signals) (up to here, this is a **90 hours project**)
|
|
|
- support for the visualization of specific models, like for example aeroelastic models of rotary wing aicraft, biomechanical models of the human body, ecc... (getting here will require **175** or **350 hours**, depending on how many possibilities for specific models are introduced)
|
|
|
|
|
|
**Category**: [User Interface](#user-interface)\
|
|
|
**Programming Languages**: Python\
|
|
|
**Keywords**: Blender, UI, post-process\
|
|
|
**Difficulty**: Low/Intermediate\
|
|
|
**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), then use the Blender Python API (or console) to create a simple Blender model
|
|
|
|
|
|
---
|
|
|
|
|
|
### Complete NetCDF output implementation
|
|
|
|
|
|
MBDyn can output simulation results in [NetCDF](https://www.unidata.ucar.edu/software/netcdf/) format, speeding up significantly the manipulation of output data for visualization and processing. Currently, the support for binary output is still not complete among all the MBDyn entitites. For example, drives are currently not supported, nor are numerous user-defined elements contained in [modules](home#what-are-run-time-loadable-modules-and-how-do-they-work).
|
|
|
|
|
|
The aim of this project is to add the support for binary output to all the missing entities. A vast library of examples can be obtained simply looking at the current implementation for the supported entities.
|
|
|
|
|
|
The roadmap can be the following one:
|
|
|
- complete the binary output of 'standard' elements (e.g. plates are currently missing)
|
|
|
- add the binary output of reference frames
|
|
|
- add the binary output of drives (up to here, this is a **90 hours project**)
|
|
|
- complete the binary output of elements defined in [modules](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/home#what-are-run-time-loadable-modules-and-how-do-they-work)
|
|
|
- enable the user to output to NetCDF also solver diagnostics (e.g. residuals, iterations, jacobians) (up to here, this is a **175 hours project**)
|
|
|
|
|
|
|
|
|
**Category**: [Post-process](#post-process)\
|
|
|
**Programming Languages**: C++\
|
|
|
**Keywords**: post-process, NetCDF\
|
|
|
**Difficulty**: Low\
|
|
|
**Mentors**: Andrea Zanoni
|
|
|
|
|
|
---
|
|
|
|
|
|
## IPC/RT
|
|
|
|
|
|
### Introduce MavLink support
|
|
|
|
|
|
MBDyn offers several possibilities to communicate with external processes: UNIX sockets, RTAI mailboxes or standard TCP/UDP sockets can be used to exchange data.
|
|
|
|
|
|
The purpose of this project is to add the support to the [MAVLink](https://https://mavlink.io/en/), a lightweight messaging protocol born for communicating with drones.
|
|
|
|
|
|
The desired output is a module similar to [module-flightgear](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/develop/modules/module-flightgear?ref_type=heads), in which a new mode of operation of the file drivers of type `stream` and of the output elements of type `stream` is defined, allowing the user to select which MBDyn signal put into which MAVLink fields.
|
|
|
|
|
|
Depending on the amount of flexibility/implemented features, this project can be scoped at **90 hours** or **175 hours**.
|
|
|
|
|
|
**Category**: [Modeling Capabilities](#modeling-capabilities)\
|
|
|
**Programming Languages**: C/C++\
|
|
|
**Keywords**: Inter-Process Communication, Sockets\
|
|
|
**Difficulty**: Intermediate\
|
|
|
**Mentors**: Andrea Zanoni
|
|
|
|
|
|
### MBDyn-DUST Module
|
|
|
|
|
|
MBDyn can be coupled with external software, allowing it to be inserted into co-simulation pipelines. The most common application is Fluid-Structure Interaction (FSI), which is the field for which MBDyn was initially developed.
|
|
|
|
|
|
[DUST](https://public.gitlab.polimi.it/DAER/dust) is a mid-fidelity aerodynamic solver, designed to provide fast estimated good enough for aircraft conceptual design. It is based on an
|
|
|
integral boundary element formulation of the aerodynamic problem and vortex-particle modelling of the wakes.
|
|
|
|
|
|
MBDyn is currently typically coupled with DUST using [preCICE](https://precice.org/). However, for most applications, this is a rather unnecessary complication, since all is requested from [preCICE](https://precice.org/) is to make the two software exchange data at each timestep and give each other the OK to go to to the next step at convergence.
|
|
|
|
|
|
This project aims at developing an *in-house* solution for the coupling, in the form of a MBDyn [module](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/home#what-are-run-time-loadable-modules-and-how-do-they-work). It will follow a similar pattern as the one from the 2020 GSoC edition from [Runsen Zhang](https://public.gitlab.polimi.it/DAER/mbdyn/-/wikis/GSoC-Students-Blogs#a-user-defined-runtime-loadable-module-template-for-co-simulation-with-chronoengine), who created a template module for the co-simulation of MBDyn and [Chrono](https://projectchrono.org/).
|
|
|
|
|
|
**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
|
|
|
|
|
|
--- |