Skip to content

Changes

Page history
Update GSoC Students Blogs authored by Andrea Zanoni's avatar Andrea Zanoni
Hide whitespace changes
Inline Side-by-side
GSoC-Students-Blogs.md
View page @ e32aa37b
# Google Summer of Code Students Blogs
This page collects our GSoC students blogs: they will post regular updates about their progress during their GSoC experience.
## 2024 GSoC Student Blog
[Shimul Baidya](@shimul.cse31) is our 2024 GSoC Contributor, working on the development of the Python Preprocessor.
You can follow the project at issue #358 and here below Shimul will write his weekly blog.
## 2022 GSoC Students Blog
You can find the final report of [TIẾN DŨNG ĐỖ](@tiendung.do1907), our 2022 GSoC student working on improving Blendyn, [here](https://github.com/BryanGsep/Blendyn-Development/blob/main/README.md).
Below, his weekly blog.
### Blendyn Improvements
* **Author**: [TIẾN DŨNG ĐỖ](@tiendung.do1907)
* **Mentors**: [Andrea Zanoni](@10260632), [Marco Morandini](@marco.morandini)
Blendyn is one of MBDyn post-processor which is built as an addons of
Blender. Blendyn's structure and most of its function implemented in 2017.
However, some of its function is out of date and their is some new ideas
for improvement. In 2022 GSoC, we planed to update and implement some
Blendyn features as follow:
1. Adding two new plotting engines `matplotlib` and `bokeh` into plotting.
2. Finding an optimal way to visualize some missing element such as `beam slider`,
`modal`.
3. Visualise internal forces and stress/strain fields of deformable
components `beam2`, `beam3`, `shell4`, `membrance` during animation.
4. Improving UI interface
My code could be seen on `devel2` branch of [Blendyn
Github](https://github.com/zanoni-mbdyn/blendyn) (**EDIT**: the code is now merged in the `master` and `devel` branches)
#### GSoC Bonding Time
Before coding, I spent time to install and learn how to use necessary
library such as `matplotlib`, `bokeh`, `pygal`. Then, I tested some
Blendyn feature with [Blendyn
Tutorial](https://github.com/zanoni-mbdyn/blendyn/wiki/Tutorials)
and reading throught the code structure to get to know how
Blendyn work in general.
#### First Week: June 13th - June 19th
In this week, I read carefully plotting code in `plot.py`. Then, I start
to create `matplotlib.py` python file and implement `matplotlib`.
1. Adding `matplotlib` library information into dependency list in
`dependencies.py`
2. Create the following operator:
`BLENDYN_OT_mplot_var_scene`
`BLENDYN_OT_mplot_var_object`
`BLENDYN_OT_mplot_variables_list`
`BLENDYN_OT_mplot_var_sxx_scene`
`BLNEDYN_OT_mplot_var_sxx_object`
`BLENDYN_OT_mplot_trajectory_scene`
`BLENDYN_OT_mplot_trajectory_object`
3. Create `plot engine` choosing function into plotting panels and
add `Trajectory` option into `plot type`.
4. Moving `Pygal plotting function` into new python file name `pygallib,py`
#### Second Week: June 20th - June 26th
This week, I continue to implementing `bokeh` plotting engine into Blendyn:
1. Adding `bokeh` library information into dependency list in `dependencies.py`
2. Create the following operator:
`BLENDYN_OT_bplot_var_scene`
`BLENDYN_OT_bplot_var_object`
`BLENDYN_OT_bplot_variables_list`
`BLENDYN_OT_bplot_var_sxx_scene`
`BLNEDYN_OT_bplot_var_sxx_object`
`BLENDYN_OT_bplot_trajectory_scene`
`BLENDYN_OT_bplot_trajectory_object`
3. Adding `Bokeh` into plotting engine in plotting panel.
#### Third Week: June 27th - July 3rd
This week, I test my code by plotting different MBDyn output variables with new
`operator` function. Then, I fixed some bugs.
1. Register new `operator` function `__init__.py`
2. Create two options `show in localhost` and `save as png` when plotting with `bokeh` engine
#### Fourth Week: July 4th - July 10th
This week, I fucus on reading material and exsiting code about two elements `beam slider` and `modal`. Then, I
thought about how to design and visualize them in blender.
#### Fifth Week: July 11th - July 17th
This week, I start to implement `automatic import` functions of `beam slider`
1. Create a new Python file name `beamsliderlib.py`
2. Implementing `automatic import` functions as follow:
`BLENDYN_OT_import_beam_slider`
`parse_beam_slider`
`beam_slider_info_draw`
`spawn_beam_slider_element`
3. Adding `parse_beam_slider` into `joint_type` list in
`elementlib.py`
4. Drawing `beam slider` symbol in `joints.blend` (it looks
like a hollow cylinder)
#### Sixth Week: July 18th - July 24th
This week, I focused on visualize and automatic import
`modal` joint as a Blendyn Component.
1. Create a new Python file name `modallib.py`
2. Implementing `automatic import` functions as follow:
`BLENDYN_OT_import_modal`
`parse_modal`
`modal_info_draw`
`spawn_modal_element`
3. Adding `parse_modal` into `joint_type` list in
`elementlib.py`
4. Drawing `modal` symbol in `joints.blend` (it looks
like a spherical surface)
5. Adding `add_comp_armature_bones_modal` into
`add_mesh_component` to enable visualize `modal`
as a Blendyn Component
6. Implementing some functions in `component.py` as follow
`BLENDYN_OT_element_add_node`
`BLENDYN_OT_element_add_all_selected_nodes`
`BLENDYN_OT_element_remove_node`
`BLENDYN_OT_element_remove_all_nodes`
`BLENDYN_OT_element_add_new_connect`
`BLENDYN_OT_element_remove_connect`
`BLENDYN_OT_element_remove_all_connects`
7. Modifying `BLENDYN_PT_components` to create suitable UI
for importing `modal`
#### Seventh Week: July 25th - July 31st
This week, I read material related to visualization of internal force and internal moment. I also think about the method to visualize them (Using Blender Shader Node or Blender Texture).
#### Eighth Week: August 1st - August 7th
This week, I decide to change the visualizing method for `modal`. This method force Blender reading `modal node` information dirrectly from `.fem` file and animate them using data of `q` value from `.mod` file.
1. Creating `parse_modal_fem_file`, `spawn_modal_node_obj` which read data from `.fem` file and import `modal node` into screen.
2. Modifying `set_motion_paths_netcdf` and `set_motion_paths_mov` to allow them read data from `.mod` file, locate new position and rotation of `modal nodes` and insert keyframe for each time point.
4. Improving the function for `Nskip` (Number of skip lines) for loading frequency `>1`
5. Deleting UI panel in sixth week and make a new suitable UI in `MBDyn Components` section with some new `operator` class:
`BLENDYN_OT_select_modal_fem_file`, `BLENDYN_OT_read_modal_fem_file`, `BLENDYN_OT_modal_node_import_all`
7. Modifying `add_comp_armature_bones_modal`
#### Nineth Week: August 8th - August 14th
This week, I focus on visualisation of `beam2`.
1. Creating new python file named `stresslib.py`
2. Designing `Shader Nodes` and their connections
3. Adding new functions for `beam2`'s stress visualisation:
`beam2_import_stress`, `setup_import_stress`, `BLENDYN_OT_import_stress`, `beam2_update_stress`, `update_stress`
4. Adding `update_stress` into `set_motion_paths_netcdf` and `set_motion_paths_mov`
#### Tenth Week: August 15th - August 21st
This week, I focus on visualisation of `beam3`.
1. Designing `Shader Nodes` and their connections (Using `ColorRanp` shader node and `linear` interpolation method)
2. Adding new functions for `beam3`'s stress visualisation:
`beam3_import_stress`, `beam3_update_stress`, `BLENDYN_OT_color_boundary_autosetup`
3. Modifying `BLENDYN_PT_import` to enbale user import stress if possible
#### Eleventh Week: August 22nd - August 28th
This week, I focus in visualisation of `shell4` and `membrane4` elements
1. Designing `Shader Nodes` and their connections
2. Adding new functions for `shell4` and `membrane4`'s stress visualisation:
`shell4_import_stress`, `shell4_update_stress`, `membrane4_import_stress` and `membrane4_update_stress`
#### Twelveth and Thirteenth Week: August 29th - September 12th
This week, I spend my time to test all implemented functions with various example and fix their bugs
1. Deleting unnecessary codes
2. Fixing bugs in `parse_modal_fem_file`
3. Modifying `set_motion_paths_netcdf` and `set_motion_paths_mov` with new method of calculating `modal node` position
4. Completing documents for GSoC 2022
## 2021 GSoC Students Blog
[Satyam Kumar](@skdbsp123) and [Shubhaditya Burela](@shubhadityaburela), our 2021 GSoC students, will post here their weekly development blogs
* Satyam Kumar: [Convergence Criteria](#convergence-criteria-update)
* Shubhaditya Burela: [VLM Solver](#implementation-of-an-unsteady-vortex-lattice-method)
### Convergence Criteria Update
* **Author**: [Satyam Kumar](@skdbsp123)
* **Mentors**: [Marco Morandini](@marco.morandini), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 75](#75)
The convergence criteria determine if the result of the simulation during a timestep has been sufficiently accurate to advance to the next timestep. The goal of this project is to upgrade the currently implemented convergence criteria, by:
* flagging different equations and variables according to their physical dimensions;
* computing different residual norms for different physical domains;
* for each physical domain, computing a reference comparison value for the convergence check;
* developing and test the new convergence test.
#### First Week: June 7th-13th
In the first week, I focused on understanding the program flow. I ran the program for multiple test cases line by line using GDB.
Then I focused on understanding the class hierarchy of `NonlinearProblems`,
`StepIntegrators`, `NonlinearSolvers`, and other related classes.
I tried to understand how the residuals are calculated and how the convergence test is currently being used.
#### Second Week: June 14th-20th
In the second week, I created a new branch `gsoc-convergence-test`, then rebased it to `develop` branch. I focused on the `AbsRes` vector.
- I added the `AbsRes` vector to the `NonlinearSolverTestRelNorm`
- made the required changes in `NonlinearProblem::Residual` method and in all the subclasses, added
- added `GetAbsRes` method to `NonlinearSolverTest` class.
- defined the new `MakeTest` for `NonlinearSolverTestRelNorm`.
#### Third Week: June 21th-27th
In the third week, I completed the remaining part of codes for `NonlinearSolverTestRelNorm` and then starting planning the way to get dimensions of equations of elements and nodes. I declared a test function `GetEquationDimension` in the class `DofOwnerOwner` and overridden it in some classes in order to check if they are properly functioning or not. I used the case of double pendulum, and was successful in creating test function `GetEquationDimension` at the required places.
#### Fourth Week: June 28th-July 4th
In the fourth week, I focused on getting the proper dimensions of the elements and nodes. I successfully created the complete function `GetEquationDimension` for the the following classes
1. StructDispNode
2. StructNode
3. DynamicStructDispNode
4. DynamicStructNode
5. PlaneHingeJoint
6. PlanePinJoint
7. ClampJoint
Later I started working on the idea to store the indices of components of equations in a map of their corresponding dimensions.
#### Fifth Week: July 5th-11th
In the fifth week, I made changes in the class `NonlinearSolverTestSepNorm` in order to use the map of dimension and indices. Then I created two functions:
1. SetElemDimensionIndices()
2. SetNodeDimensionIndices()
I accessed these functions from `Solver::Prepare` and now we can move forward to code the `MakeTest` function of our new class `NonlinearSolverTestSepNorm`.
#### Sixth Week: July 12th-18th
In the sixth week, I completed the code of `MakeTest` function for `NonlinearSolverTestSepNorm`. Then I tested the code for three example cases
1. freely falling body
2. double pendulum
3. cantilever beam
#### Seventh Week: July 19th-25th
In the seventh week, I worked on making `GetEquationDimension` pure virtual.
I created the function for some subclasses of `Nodes` and I the work is still in progress.
#### Eighth Week: July 26th-August 1st
In the eighth week, I continued to add `GetEquationDimension` method for subclasses of `ElemWithDofs`.
#### Ninth Week: August 2nd-8th
In the ninth week, I completed adding `GetEquationDimension` method to add the required classes. I added all the files in the [commit](https://public.gitlab.polimi.it/DAER/mbdyn/-/commit/2fb5c183384641d356bbefc807439ea4d1a9264a).
I started adding `DefineEq` method to the classes where they are not already present.
### Implementation of an Unsteady Vortex Lattice Method
* **Author**: [Shubhaditya Burela](@shubhadityaburela)
* **Mentors**: [Alessandro Cocco](@alessandro.cocco), [Alberto Savino](@alberto.savino), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 74](#74)
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.
#### First Week: June 7th-13th
In this first week, I started with understanding the UVLM code in MATLAB. The MATLAB code is to be replicated into C++ and implemented into a module which can then be loaded during runtime for which I started looking and understanding the module-template2 which gives an idea about how to implement a user-defined element. Next week I will start coding the UVLM method into C++ on the lines of the MATLAB code.
#### Second Week: June 14th-20th
In second week, I started coding basic classes for the input conditions of the UVLM problem. The plan now is to create an interface between MBDyn and an external UVLM solver library written in C++ and perform co-simulation. The MBDyn will handle the structural part and the UVLM library will handle the aerodynamic part of the simulation. The continuing work which follows is creating classes for Aerogrid generation and for performing a complete simulation of the aerodynamic part.
#### Third Week: June 21st-27th
In the third week, I continued with writing classes for the aero solver,
- I created `uvlmInterfaceBaseElem` class and added necessary structs like `MBDyn_UVLM_VMopts`, `MBDyn_UVLM_UVMopts` and `MBDyn_UVLM_Flightconditions` for the input handling.
- I defined `MBDyn_UVLM_AeroTimeStepInfo` class for defining the input arrays and matrices which will be used by the UVLM solver.
- I created another class called `Aero_Inputs` which takes in the raw inputs from the parser and creates necessary input arrays and matrices for use in the aero solver.
- Class `Aerogrid` is currently being written by me which will then handle the grid generation of the Aero solver.
#### Fourth Week: June 28th-July 4th
In the fourth week, I proceeded with the Aerogrid class.
- I wrote methods: `calculate_dimensions`, `add_timestep`, `generate_zeta` and `generate_mapping`.
- I created another class and its corresponding methods for straight wake generation called `StraightWake`.
- I also wrote `module-uvlm.h` and `module-uvlm.cc` files to a greater extent thus including the structural information which must be fed to the aero side of the code.
#### Fifth Week: July 5th-July 11th
In the fifth week, I implemented the function `generate_strip` which is the main function that creates the coordinates of the solid grid vertices. With this function, all the input arrays and the matrices required for the UVLM solver are now formulated.
#### Sixth Week: July 12th-July 18th
In the sixth week, I concentrated more on writing functions for the `UvlmInterfaceBaseElem` class. The constructor for the class was written along with the member functions `SetValue`, `Update`, `AfterConvergence`, `AfterPredict`, `BeforePredict`.
#### Seventh Week: July 19th-July 25th
In the seventh week, I proceeded forward with writing functions for the `UvlmInterfaceBaseElem` class. `MBDyn_UVLM_UpdateUVLMModel()`, `MBDyn_UVLM_SendDataToBuf_Curr()`, `MBDyn_UVLM_SendDataToBuf_Prev()`, `MBDyn_UVLM_RecvDataFromBuf()`.
#### Eighth Week: July 26th-August 1st
In the eighth week, I started writing the functions `MBDyn_UVLM_Model_RecvFromBuf` and `MBDyn_UVLM_Model_SendToBuf` which receive the kinematic data from the MBDyn subsystem and send the computed data back to the MBDyn system respectively.
#### Ninth Week: August 2nd-August 8th
In the ninth week, I started writing the functions `MBDyn_UVLM_Model_Init` and `MBDyn_UVLM_Model_DoStepDynamics` which initializes the UVLM solver and performs a step of time integration for the UVLM solver respectively.
#### Tenth Week: August 9th-August 15th
In the tenth week, I combined all the functions together to create four different files `module-uvlm.cc`, `module-uvlm.h`, `mbdyn_uvlm.cc` and `mbdyn_uvlm.h`. These files are the final files that will be used for running the simulation for the UVLM-MBDyn coupled solver.
## 2020 GSoC Students Blogs
[Runsen Zhang](@buaa_zhangrunsen) and [Boyan Zhou](@steven.b.zhou), our 2020 GSoC
students, will post here their weekly development blogs.
* Runsen Zhang: [MBDyn -- Chrono::Engine interface](#a-user-defined-runtime-loadable-module-template-for-co-simulation-with)
* Boyan Zhou: [Embedded Optimization](#embedded-optimization)
### A user-defined runtime loadable module template for co-simulation with [Chrono::Engine](http://projectchrono.org/)
* **Author**: [Runsen Zhang](@buaa_zhangrunsen)
* **Mentors**: [Pierangelo Masarati](@10102934), [Andrea Zanoni](@10260632)
* **Branch**: [`gsoc_chrono_interface`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_chrono_interface)
* **Issue**: [Issue 54](#54)
The goal of the project is to enable tight coupling co-simulation with [Chrono::Engine](https://projectchrono.org/) (C::E).
The MBDyn-C::E interface will be developed into a runtime loadable module, so that users can built their own C::E models with the
interface in the opaque object, and link it to the MBDyn’s module.
```mermaid
graph LR
A["Nodes <br /> (MBDyn)"] -->|Motion|B
subgraph module [runtime module]
B(Object<br /> Chrono::Engine)
end
B --> |Forces| C["Nodes<br />(MBDyn)"]
```
**Objectives**:
* Minimum: interface for single node in MBDyn & in C::E
MBDyn-side code for MBDyn module
* C::E-side code for MBDyn-C::E interface
* C::E code for example (e.f. a mass, or a mass and a spring, ...)
* Desired: interface for arbitrary number of nodes
#### First Week: June 1st-7th
In the first week, my mentors and I settled on the plan.
The scope of the first part of my plan is to built the MBDyn user-defined element, that
can achieve the tight coupling co-simulation. This defined-element is like the external
structural force element, and can call the simulation of a C::E model.
I summarised the coupling procedure in the co-simulation of C::E system, and
corresponded each step to the simulation process in MBDyn. And according to this, I am
starting writing the MBDyn-side codes. When this part works, I will test it using a
simple C::E model, and show them to the mentors.
#### Second Week: June 8th-14th
The following Files are created:
* ce_models.cc.
* mass1.mbd.
* mbdyn_ce.cc.
* module-chrono-interface.cc.
* libCE_models.so. （generated by files ce_models.cc, mbdyn_ce.cc, and mbdyn_ce.h）
In this week, the library "libCE_models.so" including an easy C::E model is generated, and connected to the MBDyn module::module-chrono-interface. And now, the C::E model and the MBDyn model could be loaded and solved in the meantime. In next week, attention will be paid to the data exchange between two solvers.
#### Third Week: June 15th-21st
In this week, I am working on the functions used in the co-simulation. Some functions are defined and added to the module. Through these functions, all coupling variables are saved in two std::vector containers in each iteration, and two solvers could send and receive data through these functions. More details will be defined in the following week.
#### Fourth Week: June 22nd-28th
In this week, I am working on the functions used in the co-simulation, and defined the following functions to construct the problem:
* AssRes();
* MBDyn_CE_RecvDataFromBuf();
* MBDyn_CE_SendDataToBuf().
And a demo that does not exchange coupling variables is run to test the code.
In next week, I will pay attention to imposing the motion to the selected bodies in C::E model.
#### Fifth Week: June 29th-July 5th
In this week, the codes for one coupling node is almost finished. I complied the codes, but didn't test them. Besides, the current codes need to be more general for a general coupling node, and that's what I will focus on next week.
#### Sixth Week: July 6th-July 12nd
In this week, the codes for one coupling node is tested by the two-dimension two-mass example. It seems that everything is OK. In next week, I will check the codes with different three-dimension examples. Besides, I will also think about how to impose coupling velocities to C::E bodies.
#### Seventh Week: July 13rd-July 19th
In this week, two examples, three-dimensional two-mass oscillator system and a three-dimensional pendulum system, are tested using the module-chrono-interface. It follows that results obtained are consistent with those obtained from the co-simulaiton using sockets, and the monolithic methods. As for the velocities problem, I didn't find a suitable interface in Chrono, so I think I would try to use some interpolation methods in Chrono to generate high-order position lines that include the information about velocities.
#### Eighth Week: July 20th-July 26th
To impose velocities to bodies in C::E, I may need more time to know the interpolation methods about quaternion. In the meantime, I added a check process to ensure that two codes have the consistent initial conditions, and improved codes for arbitrary number of nodes. The codes are complied successfully. In next week, I will test a multi-node case.
#### Ninth and tenth Weeks: July 27th-August 9th
To impose velocities to bodies in C::E, I try to use the SetPoint() function in Chrono, which gives the C::E motor information about the position, velocity, and acceleration. The codes are compiled, and tested. It follows that the results agree with those obtained from the linear interpolation method used before. However, some oscillations are observed on the velocity and acceleration levels. I need to know why these oscillations happen and how to avoid them.
### Embedded Optimization
* **Author**: [Boyan Zhou](@steven.b.zhou)
* **Mentors**: [Andrea Zanoni](@10260632), [Pierangelo Masarati](@10102934)
* **Branch**: [`gsoc_optimization`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_optimization)
* **Issue**: [Issue 55](#55)
The goal of the project is to enable the solution of **overactuated** inverse dynamics
problems directly in the MBDyn code.
The goal is for the developed code to enable the problems
* **fully determined overactuated**
* **underdetermined overactuated**
**Objectives**
* Minimum: enable the **overactuated** problems solving the underdetermined inverse
dynamics problem with a minimum norm solution;
* Desired: allow bounds to be added to the actuation (generalized) forces;
* Desired: allow the user to select the functional of the actuation (generalized) forces
to be minimized;
* Desired: allow for arbitrary contraints to be added.
#### First Week: June 1st-7th
My first week was mainly spent on studying the problem:
* read through inverse dynamic problem in techman, figure out different problem types;
* modified `mbdyn/base/invdyn.h`;
* start to read `mbdyn/base/invsolver.cc` and `mbdyn/base/invdataman.cc`
I am now working on the code and I think I will able to do more next week.
#### Second Week: June 8th-14th
After modified the following files:
* mbdyn/base/invsolver.cc
* mbdyn/base/invdataman.cc
overactuated problems can now be recognized by the parser and the inverse dynamics solver.
Changes with regard to the related files has been committed to gsoc_optimization branch
#### Third Week: June 15th-21st
Modified following functions to construct the problem:
* DataManager::AssConstrRes()
* DataManager::AssRes()
* DataManager::AssConstrJac()
The next step is to build up the solution.
#### Forth Week: June 22nd-28th
Test the input file 'planar_3link_ergo2_oa.mbd', and Made several discoveries:
* program stops at 10th step, when dealing with InverseDynamics::INVERSE_DYNAMICS
* program stops because the input matrix for UTSolve becomes singular
* problem at the inverse dynamics step is not actually written as a 'simple' linear problem, but as the iterative linear problem given by the solution of Newton-Raphson
Maybe the next step is to convert the problem to a simpler, single-step solution of the underlining linear problem.
#### Fifth Week: June 29th-July 5th
We find out that problem at the inverse dynamics step is formulated the
right way, so we just need to understand why it is not given the expected
results.
Also, I start to build up a check for the inverse dynamics problem, checking for input size, solver type, etc.
#### Sixth Week: July 6th-12nd
* Check the input and output, found many functions regarding inverse dynamic problems are NO_OP.
* Check the UTSolve(), found something strange (not sure if it is a bug).
* Try to trace the input matrix.
* Building Checks for inverse dynamic problems.
## 2021 GSoC Students Blog
[Satyam Kumar](@skdbsp123) and [Shubhaditya Burela](@shubhadityaburela), our 2021 GSoC students, will post here their weekly development blogs
* Satyam Kumar: [Convergence Criteria](#convergence-criteria-update)
* Shubhaditya Burela: [VLM Solver](#implementation-of-an-unsteady-vortex-lattice-method)
### Convergence Criteria Update
* **Author**: [Satyam Kumar](@skdbsp123)
* **Mentors**: [Marco Morandini](@marco.morandini), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 75](#75)
The convergence criteria determine if the result of the simulation during a timestep has been sufficiently accurate to advance to the next timestep. The goal of this project is to upgrade the currently implemented convergence criteria, by:
* flagging different equations and variables according to their physical dimensions;
* computing different residual norms for different physical domains;
* for each physical domain, computing a reference comparison value for the convergence check;
* developing and test the new convergence test.
#### First Week: June 7th-13th
In the first week, I focused on understanding the program flow. I ran the program for multiple test cases line by line using GDB.
Then I focused on understanding the class hierarchy of `NonlinearProblems`,
`StepIntegrators`, `NonlinearSolvers`, and other related classes.
I tried to understand how the residuals are calculated and how the convergence test is currently being used.
#### Second Week: June 14th-20th
In the second week, I created a new branch `gsoc-convergence-test`, then rebased it to `develop` branch. I focused on the `AbsRes` vector.
- I added the `AbsRes` vector to the `NonlinearSolverTestRelNorm`
- made the required changes in `NonlinearProblem::Residual` method and in all the subclasses, added
- added `GetAbsRes` method to `NonlinearSolverTest` class.
- defined the new `MakeTest` for `NonlinearSolverTestRelNorm`.
#### Third Week: June 21th-27th
In the third week, I completed the remaining part of codes for `NonlinearSolverTestRelNorm` and then starting planning the way to get dimensions of equations of elements and nodes. I declared a test function `GetEquationDimension` in the class `DofOwnerOwner` and overridden it in some classes in order to check if they are properly functioning or not. I used the case of double pendulum, and was successful in creating test function `GetEquationDimension` at the required places.
#### Fourth Week: June 28th-July 4th
In the fourth week, I focused on getting the proper dimensions of the elements and nodes. I successfully created the complete function `GetEquationDimension` for the the following classes
1. StructDispNode
2. StructNode
3. DynamicStructDispNode
4. DynamicStructNode
5. PlaneHingeJoint
6. PlanePinJoint
7. ClampJoint
Later I started working on the idea to store the indices of components of equations in a map of their corresponding dimensions.
#### Fifth Week: July 5th-11th
In the fifth week, I made changes in the class `NonlinearSolverTestSepNorm` in order to use the map of dimension and indices. Then I created two functions:
1. SetElemDimensionIndices()
2. SetNodeDimensionIndices()
I accessed these functions from `Solver::Prepare` and now we can move forward to code the `MakeTest` function of our new class `NonlinearSolverTestSepNorm`.
#### Sixth Week: July 12th-18th
In the sixth week, I completed the code of `MakeTest` function for `NonlinearSolverTestSepNorm`. Then I tested the code for three example cases
1. freely falling body
2. double pendulum
3. cantilever beam
#### Seventh Week: July 19th-25th
In the seventh week, I worked on making `GetEquationDimension` pure virtual.
I created the function for some subclasses of `Nodes` and I the work is still in progress.
#### Eighth Week: July 26th-August 1st
In the eighth week, I continued to add `GetEquationDimension` method for subclasses of `ElemWithDofs`.
#### Ninth Week: August 2nd-8th
In the ninth week, I completed adding `GetEquationDimension` method to add the required classes. I added all the files in the [commit](https://public.gitlab.polimi.it/DAER/mbdyn/-/commit/2fb5c183384641d356bbefc807439ea4d1a9264a).
I started adding `DefineEq` method to the classes where they are not already present.
### Implementation of an Unsteady Vortex Lattice Method
* **Author**: [Shubhaditya Burela](@shubhadityaburela)
* **Mentors**: [Alessandro Cocco](@alessandro.cocco), [Alberto Savino](@alberto.savino), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 74](#74)
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.
#### First Week: June 7th-13th
In this first week, I started with understanding the UVLM code in MATLAB. The MATLAB code is to be replicated into C++ and implemented into a module which can then be loaded during runtime for which I started looking and understanding the module-template2 which gives an idea about how to implement a user-defined element. Next week I will start coding the UVLM method into C++ on the lines of the MATLAB code.
#### Second Week: June 14th-20th
In second week, I started coding basic classes for the input conditions of the UVLM problem. The plan now is to create an interface between MBDyn and an external UVLM solver library written in C++ and perform co-simulation. The MBDyn will handle the structural part and the UVLM library will handle the aerodynamic part of the simulation. The continuing work which follows is creating classes for Aerogrid generation and for performing a complete simulation of the aerodynamic part.
#### Third Week: June 21st-27th
In the third week, I continued with writing classes for the aero solver,
- I created `uvlmInterfaceBaseElem` class and added necessary structs like `MBDyn_UVLM_VMopts`, `MBDyn_UVLM_UVMopts` and `MBDyn_UVLM_Flightconditions` for the input handling.
- I defined `MBDyn_UVLM_AeroTimeStepInfo` class for defining the input arrays and matrices which will be used by the UVLM solver.
- I created another class called `Aero_Inputs` which takes in the raw inputs from the parser and creates necessary input arrays and matrices for use in the aero solver.
- Class `Aerogrid` is currently being written by me which will then handle the grid generation of the Aero solver.
#### Fourth Week: June 28th-July 4th
In the fourth week, I proceeded with the Aerogrid class.
- I wrote methods: `calculate_dimensions`, `add_timestep`, `generate_zeta` and `generate_mapping`.
- I created another class and its corresponding methods for straight wake generation called `StraightWake`.
- I also wrote `module-uvlm.h` and `module-uvlm.cc` files to a greater extent thus including the structural information which must be fed to the aero side of the code.
#### Fifth Week: July 5th-July 11th
In the fifth week, I implemented the function `generate_strip` which is the main function that creates the coordinates of the solid grid vertices. With this function, all the input arrays and the matrices required for the UVLM solver are now formulated.
#### Sixth Week: July 12th-July 18th
In the sixth week, I concentrated more on writing functions for the `UvlmInterfaceBaseElem` class. The constructor for the class was written along with the member functions `SetValue`, `Update`, `AfterConvergence`, `AfterPredict`, `BeforePredict`.
#### Seventh Week: July 19th-July 25th
In the seventh week, I proceeded forward with writing functions for the `UvlmInterfaceBaseElem` class. `MBDyn_UVLM_UpdateUVLMModel()`, `MBDyn_UVLM_SendDataToBuf_Curr()`, `MBDyn_UVLM_SendDataToBuf_Prev()`, `MBDyn_UVLM_RecvDataFromBuf()`.
#### Eighth Week: July 26th-August 1st
In the eighth week, I started writing the functions `MBDyn_UVLM_Model_RecvFromBuf` and `MBDyn_UVLM_Model_SendToBuf` which receive the kinematic data from the MBDyn subsystem and send the computed data back to the MBDyn system respectively.
#### Ninth Week: August 2nd-August 8th
In the ninth week, I started writing the functions `MBDyn_UVLM_Model_Init` and `MBDyn_UVLM_Model_DoStepDynamics` which initializes the UVLM solver and performs a step of time integration for the UVLM solver respectively.
#### Tenth Week: August 9th-August 15th
In the tenth week, I combined all the functions together to create four different files `module-uvlm.cc`, `module-uvlm.h`, `mbdyn_uvlm.cc` and `mbdyn_uvlm.h`. These files are the final files that will be used for running the simulation for the UVLM-MBDyn coupled solver.
## 2020 GSoC Students Blogs
[Runsen Zhang](@buaa_zhangrunsen) and [Boyan Zhou](@steven.b.zhou), our 2020 GSoC
students, will post here their weekly development blogs.
* Runsen Zhang: [MBDyn -- Chrono::Engine interface](#a-user-defined-runtime-loadable-module-template-for-co-simulation-with)
* Boyan Zhou: [Embedded Optimization](#embedded-optimization)
### A user-defined runtime loadable module template for co-simulation with [Chrono::Engine](http://projectchrono.org/)
* **Author**: [Runsen Zhang](@buaa_zhangrunsen)
* **Mentors**: [Pierangelo Masarati](@10102934), [Andrea Zanoni](@10260632)
* **Branch**: [`gsoc_chrono_interface`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_chrono_interface)
* **Issue**: [Issue 54](#54)
The goal of the project is to enable tight coupling co-simulation with [Chrono::Engine](https://projectchrono.org/) (C::E).
The MBDyn-C::E interface will be developed into a runtime loadable module, so that users can built their own C::E models with the
interface in the opaque object, and link it to the MBDyn’s module.
```mermaid
graph LR
A["Nodes <br /> (MBDyn)"] -->|Motion|B
subgraph module [runtime module]
B(Object<br /> Chrono::Engine)
end
B --> |Forces| C["Nodes<br />(MBDyn)"]
```
**Objectives**:
* Minimum: interface for single node in MBDyn & in C::E
MBDyn-side code for MBDyn module
* C::E-side code for MBDyn-C::E interface
* C::E code for example (e.f. a mass, or a mass and a spring, ...)
* Desired: interface for arbitrary number of nodes
#### First Week: June 1st-7th
In the first week, my mentors and I settled on the plan.
The scope of the first part of my plan is to built the MBDyn user-defined element, that
can achieve the tight coupling co-simulation. This defined-element is like the external
structural force element, and can call the simulation of a C::E model.
I summarised the coupling procedure in the co-simulation of C::E system, and
corresponded each step to the simulation process in MBDyn. And according to this, I am
starting writing the MBDyn-side codes. When this part works, I will test it using a
simple C::E model, and show them to the mentors.
#### Second Week: June 8th-14th
The following Files are created:
* ce_models.cc.
* mass1.mbd.
* mbdyn_ce.cc.
* module-chrono-interface.cc.
* libCE_models.so. （generated by files ce_models.cc, mbdyn_ce.cc, and mbdyn_ce.h）
In this week, the library "libCE_models.so" including an easy C::E model is generated, and connected to the MBDyn module::module-chrono-interface. And now, the C::E model and the MBDyn model could be loaded and solved in the meantime. In next week, attention will be paid to the data exchange between two solvers.
#### Third Week: June 15th-21st
In this week, I am working on the functions used in the co-simulation. Some functions are defined and added to the module. Through these functions, all coupling variables are saved in two std::vector containers in each iteration, and two solvers could send and receive data through these functions. More details will be defined in the following week.
#### Fourth Week: June 22nd-28th
In this week, I am working on the functions used in the co-simulation, and defined the following functions to construct the problem:
* AssRes();
* MBDyn_CE_RecvDataFromBuf();
* MBDyn_CE_SendDataToBuf().
And a demo that does not exchange coupling variables is run to test the code.
In next week, I will pay attention to imposing the motion to the selected bodies in C::E model.
#### Fifth Week: June 29th-July 5th
In this week, the codes for one coupling node is almost finished. I complied the codes, but didn't test them. Besides, the current codes need to be more general for a general coupling node, and that's what I will focus on next week.
#### Sixth Week: July 6th-July 12nd
In this week, the codes for one coupling node is tested by the two-dimension two-mass example. It seems that everything is OK. In next week, I will check the codes with different three-dimension examples. Besides, I will also think about how to impose coupling velocities to C::E bodies.
#### Seventh Week: July 13rd-July 19th
In this week, two examples, three-dimensional two-mass oscillator system and a three-dimensional pendulum system, are tested using the module-chrono-interface. It follows that results obtained are consistent with those obtained from the co-simulaiton using sockets, and the monolithic methods. As for the velocities problem, I didn't find a suitable interface in Chrono, so I think I would try to use some interpolation methods in Chrono to generate high-order position lines that include the information about velocities.
#### Eighth Week: July 20th-July 26th
To impose velocities to bodies in C::E, I may need more time to know the interpolation methods about quaternion. In the meantime, I added a check process to ensure that two codes have the consistent initial conditions, and improved codes for arbitrary number of nodes. The codes are complied successfully. In next week, I will test a multi-node case.
#### Ninth and tenth Weeks: July 27th-August 9th
To impose velocities to bodies in C::E, I try to use the SetPoint() function in Chrono, which gives the C::E motor information about the position, velocity, and acceleration. The codes are compiled, and tested. It follows that the results agree with those obtained from the linear interpolation method used before. However, some oscillations are observed on the velocity and acceleration levels. I need to know why these oscillations happen and how to avoid them.
### Embedded Optimization
* **Author**: [Boyan Zhou](@steven.b.zhou)
* **Mentors**: [Andrea Zanoni](@10260632), [Pierangelo Masarati](@10102934)
* **Branch**: [`gsoc_optimization`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_optimization)
* **Issue**: [Issue 55](#55)
The goal of the project is to enable the solution of **overactuated** inverse dynamics
problems directly in the MBDyn code.
The goal is for the developed code to enable the problems
* **fully determined overactuated**
* **underdetermined overactuated**
**Objectives**
* Minimum: enable the **overactuated** problems solving the underdetermined inverse
dynamics problem with a minimum norm solution;
* Desired: allow bounds to be added to the actuation (generalized) forces;
* Desired: allow the user to select the functional of the actuation (generalized) forces
to be minimized;
* Desired: allow for arbitrary contraints to be added.
#### First Week: June 1st-7th
My first week was mainly spent on studying the problem:
* read through inverse dynamic problem in techman, figure out different problem types;
* modified `mbdyn/base/invdyn.h`;
* start to read `mbdyn/base/invsolver.cc` and `mbdyn/base/invdataman.cc`
I am now working on the code and I think I will able to do more next week.
#### Second Week: June 8th-14th
After modified the following files:
* mbdyn/base/invsolver.cc
* mbdyn/base/invdataman.cc
overactuated problems can now be recognized by the parser and the inverse dynamics solver.
Changes with regard to the related files has been committed to gsoc_optimization branch
#### Third Week: June 15th-21st
Modified following functions to construct the problem:
* DataManager::AssConstrRes()
* DataManager::AssRes()
* DataManager::AssConstrJac()
The next step is to build up the solution.
#### Forth Week: June 22nd-28th
Test the input file 'planar_3link_ergo2_oa.mbd', and Made several discoveries:
* program stops at 10th step, when dealing with InverseDynamics::INVERSE_DYNAMICS
* program stops because the input matrix for UTSolve becomes singular
* problem at the inverse dynamics step is not actually written as a 'simple' linear problem, but as the iterative linear problem given by the solution of Newton-Raphson
Maybe the next step is to convert the problem to a simpler, single-step solution of the underlining linear problem.
#### Fifth Week: June 29th-July 5th
We find out that problem at the inverse dynamics step is formulated the
right way, so we just need to understand why it is not given the expected
results.
Also, I start to build up a check for the inverse dynamics problem, checking for input size, solver type, etc.
#### Sixth Week: July 6th-12nd
* Check the input and output, found many functions regarding inverse dynamic problems are NO_OP.
* Check the UTSolve(), found something strange (not sure if it is a bug).
* Try to trace the input matrix.
* Building Checks for inverse dynamic problems.
# Google Summer of Code Students Blogs
This page collects our GSoC students blogs: they will post regular updates about their progress during their GSoC experience.
## 2024 GSoC Student Blog
[Shimul Baidya](@shimul.cse31) is our 2024 GSoC Contributor, working on the development of the Python Preprocessor.
You can follow the project at issue #358.
## 2022 GSoC Students Blog
You can find the final report of [TIẾN DŨNG ĐỖ](@tiendung.do1907), our 2022 GSoC student working on improving Blendyn, [here](https://github.com/BryanGsep/Blendyn-Development/blob/main/README.md).
Below, his weekly blog.
### Blendyn Improvements
* **Author**: [TIẾN DŨNG ĐỖ](@tiendung.do1907)
* **Mentors**: [Andrea Zanoni](@10260632), [Marco Morandini](@marco.morandini)
Blendyn is one of MBDyn post-processor which is built as an addons of
Blender. Blendyn's structure and most of its function implemented in 2017.
However, some of its function is out of date and their is some new ideas
for improvement. In 2022 GSoC, we planed to update and implement some
Blendyn features as follow:
1. Adding two new plotting engines `matplotlib` and `bokeh` into plotting.
2. Finding an optimal way to visualize some missing element such as `beam slider`,
`modal`.
3. Visualise internal forces and stress/strain fields of deformable
components `beam2`, `beam3`, `shell4`, `membrance` during animation.
4. Improving UI interface
My code could be seen on `devel2` branch of [Blendyn
Github](https://github.com/zanoni-mbdyn/blendyn) (**EDIT**: the code is now merged in the `master` and `devel` branches)
#### GSoC Bonding Time
Before coding, I spent time to install and learn how to use necessary
library such as `matplotlib`, `bokeh`, `pygal`. Then, I tested some
Blendyn feature with [Blendyn
Tutorial](https://github.com/zanoni-mbdyn/blendyn/wiki/Tutorials)
and reading throught the code structure to get to know how
Blendyn work in general.
#### First Week: June 13th - June 19th
In this week, I read carefully plotting code in `plot.py`. Then, I start
to create `matplotlib.py` python file and implement `matplotlib`.
1. Adding `matplotlib` library information into dependency list in
`dependencies.py`
2. Create the following operator:
`BLENDYN_OT_mplot_var_scene`
`BLENDYN_OT_mplot_var_object`
`BLENDYN_OT_mplot_variables_list`
`BLENDYN_OT_mplot_var_sxx_scene`
`BLNEDYN_OT_mplot_var_sxx_object`
`BLENDYN_OT_mplot_trajectory_scene`
`BLENDYN_OT_mplot_trajectory_object`
3. Create `plot engine` choosing function into plotting panels and
add `Trajectory` option into `plot type`.
4. Moving `Pygal plotting function` into new python file name `pygallib,py`
#### Second Week: June 20th - June 26th
This week, I continue to implementing `bokeh` plotting engine into Blendyn:
1. Adding `bokeh` library information into dependency list in `dependencies.py`
2. Create the following operator:
`BLENDYN_OT_bplot_var_scene`
`BLENDYN_OT_bplot_var_object`
`BLENDYN_OT_bplot_variables_list`
`BLENDYN_OT_bplot_var_sxx_scene`
`BLNEDYN_OT_bplot_var_sxx_object`
`BLENDYN_OT_bplot_trajectory_scene`
`BLENDYN_OT_bplot_trajectory_object`
3. Adding `Bokeh` into plotting engine in plotting panel.
#### Third Week: June 27th - July 3rd
This week, I test my code by plotting different MBDyn output variables with new
`operator` function. Then, I fixed some bugs.
1. Register new `operator` function `__init__.py`
2. Create two options `show in localhost` and `save as png` when plotting with `bokeh` engine
#### Fourth Week: July 4th - July 10th
This week, I fucus on reading material and exsiting code about two elements `beam slider` and `modal`. Then, I
thought about how to design and visualize them in blender.
#### Fifth Week: July 11th - July 17th
This week, I start to implement `automatic import` functions of `beam slider`
1. Create a new Python file name `beamsliderlib.py`
2. Implementing `automatic import` functions as follow:
`BLENDYN_OT_import_beam_slider`
`parse_beam_slider`
`beam_slider_info_draw`
`spawn_beam_slider_element`
3. Adding `parse_beam_slider` into `joint_type` list in
`elementlib.py`
4. Drawing `beam slider` symbol in `joints.blend` (it looks
like a hollow cylinder)
#### Sixth Week: July 18th - July 24th
This week, I focused on visualize and automatic import
`modal` joint as a Blendyn Component.
1. Create a new Python file name `modallib.py`
2. Implementing `automatic import` functions as follow:
`BLENDYN_OT_import_modal`
`parse_modal`
`modal_info_draw`
`spawn_modal_element`
3. Adding `parse_modal` into `joint_type` list in
`elementlib.py`
4. Drawing `modal` symbol in `joints.blend` (it looks
like a spherical surface)
5. Adding `add_comp_armature_bones_modal` into
`add_mesh_component` to enable visualize `modal`
as a Blendyn Component
6. Implementing some functions in `component.py` as follow
`BLENDYN_OT_element_add_node`
`BLENDYN_OT_element_add_all_selected_nodes`
`BLENDYN_OT_element_remove_node`
`BLENDYN_OT_element_remove_all_nodes`
`BLENDYN_OT_element_add_new_connect`
`BLENDYN_OT_element_remove_connect`
`BLENDYN_OT_element_remove_all_connects`
7. Modifying `BLENDYN_PT_components` to create suitable UI
for importing `modal`
#### Seventh Week: July 25th - July 31st
This week, I read material related to visualization of internal force and internal moment. I also think about the method to visualize them (Using Blender Shader Node or Blender Texture).
#### Eighth Week: August 1st - August 7th
This week, I decide to change the visualizing method for `modal`. This method force Blender reading `modal node` information dirrectly from `.fem` file and animate them using data of `q` value from `.mod` file.
1. Creating `parse_modal_fem_file`, `spawn_modal_node_obj` which read data from `.fem` file and import `modal node` into screen.
2. Modifying `set_motion_paths_netcdf` and `set_motion_paths_mov` to allow them read data from `.mod` file, locate new position and rotation of `modal nodes` and insert keyframe for each time point.
4. Improving the function for `Nskip` (Number of skip lines) for loading frequency `>1`
5. Deleting UI panel in sixth week and make a new suitable UI in `MBDyn Components` section with some new `operator` class:
`BLENDYN_OT_select_modal_fem_file`, `BLENDYN_OT_read_modal_fem_file`, `BLENDYN_OT_modal_node_import_all`
7. Modifying `add_comp_armature_bones_modal`
#### Nineth Week: August 8th - August 14th
This week, I focus on visualisation of `beam2`.
1. Creating new python file named `stresslib.py`
2. Designing `Shader Nodes` and their connections
3. Adding new functions for `beam2`'s stress visualisation:
`beam2_import_stress`, `setup_import_stress`, `BLENDYN_OT_import_stress`, `beam2_update_stress`, `update_stress`
4. Adding `update_stress` into `set_motion_paths_netcdf` and `set_motion_paths_mov`
#### Tenth Week: August 15th - August 21st
This week, I focus on visualisation of `beam3`.
1. Designing `Shader Nodes` and their connections (Using `ColorRanp` shader node and `linear` interpolation method)
2. Adding new functions for `beam3`'s stress visualisation:
`beam3_import_stress`, `beam3_update_stress`, `BLENDYN_OT_color_boundary_autosetup`
3. Modifying `BLENDYN_PT_import` to enbale user import stress if possible
#### Eleventh Week: August 22nd - August 28th
This week, I focus in visualisation of `shell4` and `membrane4` elements
1. Designing `Shader Nodes` and their connections
2. Adding new functions for `shell4` and `membrane4`'s stress visualisation:
`shell4_import_stress`, `shell4_update_stress`, `membrane4_import_stress` and `membrane4_update_stress`
#### Twelveth and Thirteenth Week: August 29th - September 12th
This week, I spend my time to test all implemented functions with various example and fix their bugs
1. Deleting unnecessary codes
2. Fixing bugs in `parse_modal_fem_file`
3. Modifying `set_motion_paths_netcdf` and `set_motion_paths_mov` with new method of calculating `modal node` position
4. Completing documents for GSoC 2022
## 2021 GSoC Students Blog
[Satyam Kumar](@skdbsp123) and [Shubhaditya Burela](@shubhadityaburela), our 2021 GSoC students, will post here their weekly development blogs
* Satyam Kumar: [Convergence Criteria](#convergence-criteria-update)
* Shubhaditya Burela: [VLM Solver](#implementation-of-an-unsteady-vortex-lattice-method)
### Convergence Criteria Update
* **Author**: [Satyam Kumar](@skdbsp123)
* **Mentors**: [Marco Morandini](@marco.morandini), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 75](#75)
The convergence criteria determine if the result of the simulation during a timestep has been sufficiently accurate to advance to the next timestep. The goal of this project is to upgrade the currently implemented convergence criteria, by:
* flagging different equations and variables according to their physical dimensions;
* computing different residual norms for different physical domains;
* for each physical domain, computing a reference comparison value for the convergence check;
* developing and test the new convergence test.
#### First Week: June 7th-13th
In the first week, I focused on understanding the program flow. I ran the program for multiple test cases line by line using GDB.
Then I focused on understanding the class hierarchy of `NonlinearProblems`,
`StepIntegrators`, `NonlinearSolvers`, and other related classes.
I tried to understand how the residuals are calculated and how the convergence test is currently being used.
#### Second Week: June 14th-20th
In the second week, I created a new branch `gsoc-convergence-test`, then rebased it to `develop` branch. I focused on the `AbsRes` vector.
- I added the `AbsRes` vector to the `NonlinearSolverTestRelNorm`
- made the required changes in `NonlinearProblem::Residual` method and in all the subclasses, added
- added `GetAbsRes` method to `NonlinearSolverTest` class.
- defined the new `MakeTest` for `NonlinearSolverTestRelNorm`.
#### Third Week: June 21th-27th
In the third week, I completed the remaining part of codes for `NonlinearSolverTestRelNorm` and then starting planning the way to get dimensions of equations of elements and nodes. I declared a test function `GetEquationDimension` in the class `DofOwnerOwner` and overridden it in some classes in order to check if they are properly functioning or not. I used the case of double pendulum, and was successful in creating test function `GetEquationDimension` at the required places.
#### Fourth Week: June 28th-July 4th
In the fourth week, I focused on getting the proper dimensions of the elements and nodes. I successfully created the complete function `GetEquationDimension` for the the following classes
1. StructDispNode
2. StructNode
3. DynamicStructDispNode
4. DynamicStructNode
5. PlaneHingeJoint
6. PlanePinJoint
7. ClampJoint
Later I started working on the idea to store the indices of components of equations in a map of their corresponding dimensions.
#### Fifth Week: July 5th-11th
In the fifth week, I made changes in the class `NonlinearSolverTestSepNorm` in order to use the map of dimension and indices. Then I created two functions:
1. SetElemDimensionIndices()
2. SetNodeDimensionIndices()
I accessed these functions from `Solver::Prepare` and now we can move forward to code the `MakeTest` function of our new class `NonlinearSolverTestSepNorm`.
#### Sixth Week: July 12th-18th
In the sixth week, I completed the code of `MakeTest` function for `NonlinearSolverTestSepNorm`. Then I tested the code for three example cases
1. freely falling body
2. double pendulum
3. cantilever beam
#### Seventh Week: July 19th-25th
In the seventh week, I worked on making `GetEquationDimension` pure virtual.
I created the function for some subclasses of `Nodes` and I the work is still in progress.
#### Eighth Week: July 26th-August 1st
In the eighth week, I continued to add `GetEquationDimension` method for subclasses of `ElemWithDofs`.
#### Ninth Week: August 2nd-8th
In the ninth week, I completed adding `GetEquationDimension` method to add the required classes. I added all the files in the [commit](https://public.gitlab.polimi.it/DAER/mbdyn/-/commit/2fb5c183384641d356bbefc807439ea4d1a9264a).
I started adding `DefineEq` method to the classes where they are not already present.
### Implementation of an Unsteady Vortex Lattice Method
* **Author**: [Shubhaditya Burela](@shubhadityaburela)
* **Mentors**: [Alessandro Cocco](@alessandro.cocco), [Alberto Savino](@alberto.savino), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 74](#74)
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.
#### First Week: June 7th-13th
In this first week, I started with understanding the UVLM code in MATLAB. The MATLAB code is to be replicated into C++ and implemented into a module which can then be loaded during runtime for which I started looking and understanding the module-template2 which gives an idea about how to implement a user-defined element. Next week I will start coding the UVLM method into C++ on the lines of the MATLAB code.
#### Second Week: June 14th-20th
In second week, I started coding basic classes for the input conditions of the UVLM problem. The plan now is to create an interface between MBDyn and an external UVLM solver library written in C++ and perform co-simulation. The MBDyn will handle the structural part and the UVLM library will handle the aerodynamic part of the simulation. The continuing work which follows is creating classes for Aerogrid generation and for performing a complete simulation of the aerodynamic part.
#### Third Week: June 21st-27th
In the third week, I continued with writing classes for the aero solver,
- I created `uvlmInterfaceBaseElem` class and added necessary structs like `MBDyn_UVLM_VMopts`, `MBDyn_UVLM_UVMopts` and `MBDyn_UVLM_Flightconditions` for the input handling.
- I defined `MBDyn_UVLM_AeroTimeStepInfo` class for defining the input arrays and matrices which will be used by the UVLM solver.
- I created another class called `Aero_Inputs` which takes in the raw inputs from the parser and creates necessary input arrays and matrices for use in the aero solver.
- Class `Aerogrid` is currently being written by me which will then handle the grid generation of the Aero solver.
#### Fourth Week: June 28th-July 4th
In the fourth week, I proceeded with the Aerogrid class.
- I wrote methods: `calculate_dimensions`, `add_timestep`, `generate_zeta` and `generate_mapping`.
- I created another class and its corresponding methods for straight wake generation called `StraightWake`.
- I also wrote `module-uvlm.h` and `module-uvlm.cc` files to a greater extent thus including the structural information which must be fed to the aero side of the code.
#### Fifth Week: July 5th-July 11th
In the fifth week, I implemented the function `generate_strip` which is the main function that creates the coordinates of the solid grid vertices. With this function, all the input arrays and the matrices required for the UVLM solver are now formulated.
#### Sixth Week: July 12th-July 18th
In the sixth week, I concentrated more on writing functions for the `UvlmInterfaceBaseElem` class. The constructor for the class was written along with the member functions `SetValue`, `Update`, `AfterConvergence`, `AfterPredict`, `BeforePredict`.
#### Seventh Week: July 19th-July 25th
In the seventh week, I proceeded forward with writing functions for the `UvlmInterfaceBaseElem` class. `MBDyn_UVLM_UpdateUVLMModel()`, `MBDyn_UVLM_SendDataToBuf_Curr()`, `MBDyn_UVLM_SendDataToBuf_Prev()`, `MBDyn_UVLM_RecvDataFromBuf()`.
#### Eighth Week: July 26th-August 1st
In the eighth week, I started writing the functions `MBDyn_UVLM_Model_RecvFromBuf` and `MBDyn_UVLM_Model_SendToBuf` which receive the kinematic data from the MBDyn subsystem and send the computed data back to the MBDyn system respectively.
#### Ninth Week: August 2nd-August 8th
In the ninth week, I started writing the functions `MBDyn_UVLM_Model_Init` and `MBDyn_UVLM_Model_DoStepDynamics` which initializes the UVLM solver and performs a step of time integration for the UVLM solver respectively.
#### Tenth Week: August 9th-August 15th
In the tenth week, I combined all the functions together to create four different files `module-uvlm.cc`, `module-uvlm.h`, `mbdyn_uvlm.cc` and `mbdyn_uvlm.h`. These files are the final files that will be used for running the simulation for the UVLM-MBDyn coupled solver.
## 2020 GSoC Students Blogs
[Runsen Zhang](@buaa_zhangrunsen) and [Boyan Zhou](@steven.b.zhou), our 2020 GSoC
students, will post here their weekly development blogs.
* Runsen Zhang: [MBDyn -- Chrono::Engine interface](#a-user-defined-runtime-loadable-module-template-for-co-simulation-with)
* Boyan Zhou: [Embedded Optimization](#embedded-optimization)
### A user-defined runtime loadable module template for co-simulation with [Chrono::Engine](http://projectchrono.org/)
* **Author**: [Runsen Zhang](@buaa_zhangrunsen)
* **Mentors**: [Pierangelo Masarati](@10102934), [Andrea Zanoni](@10260632)
* **Branch**: [`gsoc_chrono_interface`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_chrono_interface)
* **Issue**: [Issue 54](#54)
The goal of the project is to enable tight coupling co-simulation with [Chrono::Engine](https://projectchrono.org/) (C::E).
The MBDyn-C::E interface will be developed into a runtime loadable module, so that users can built their own C::E models with the
interface in the opaque object, and link it to the MBDyn’s module.
```mermaid
graph LR
A["Nodes <br /> (MBDyn)"] -->|Motion|B
subgraph module [runtime module]
B(Object<br /> Chrono::Engine)
end
B --> |Forces| C["Nodes<br />(MBDyn)"]
```
**Objectives**:
* Minimum: interface for single node in MBDyn & in C::E
MBDyn-side code for MBDyn module
* C::E-side code for MBDyn-C::E interface
* C::E code for example (e.f. a mass, or a mass and a spring, ...)
* Desired: interface for arbitrary number of nodes
#### First Week: June 1st-7th
In the first week, my mentors and I settled on the plan.
The scope of the first part of my plan is to built the MBDyn user-defined element, that
can achieve the tight coupling co-simulation. This defined-element is like the external
structural force element, and can call the simulation of a C::E model.
I summarised the coupling procedure in the co-simulation of C::E system, and
corresponded each step to the simulation process in MBDyn. And according to this, I am
starting writing the MBDyn-side codes. When this part works, I will test it using a
simple C::E model, and show them to the mentors.
#### Second Week: June 8th-14th
The following Files are created:
* ce_models.cc.
* mass1.mbd.
* mbdyn_ce.cc.
* module-chrono-interface.cc.
* libCE_models.so. （generated by files ce_models.cc, mbdyn_ce.cc, and mbdyn_ce.h）
In this week, the library "libCE_models.so" including an easy C::E model is generated, and connected to the MBDyn module::module-chrono-interface. And now, the C::E model and the MBDyn model could be loaded and solved in the meantime. In next week, attention will be paid to the data exchange between two solvers.
#### Third Week: June 15th-21st
In this week, I am working on the functions used in the co-simulation. Some functions are defined and added to the module. Through these functions, all coupling variables are saved in two std::vector containers in each iteration, and two solvers could send and receive data through these functions. More details will be defined in the following week.
#### Fourth Week: June 22nd-28th
In this week, I am working on the functions used in the co-simulation, and defined the following functions to construct the problem:
* AssRes();
* MBDyn_CE_RecvDataFromBuf();
* MBDyn_CE_SendDataToBuf().
And a demo that does not exchange coupling variables is run to test the code.
In next week, I will pay attention to imposing the motion to the selected bodies in C::E model.
#### Fifth Week: June 29th-July 5th
In this week, the codes for one coupling node is almost finished. I complied the codes, but didn't test them. Besides, the current codes need to be more general for a general coupling node, and that's what I will focus on next week.
#### Sixth Week: July 6th-July 12nd
In this week, the codes for one coupling node is tested by the two-dimension two-mass example. It seems that everything is OK. In next week, I will check the codes with different three-dimension examples. Besides, I will also think about how to impose coupling velocities to C::E bodies.
#### Seventh Week: July 13rd-July 19th
In this week, two examples, three-dimensional two-mass oscillator system and a three-dimensional pendulum system, are tested using the module-chrono-interface. It follows that results obtained are consistent with those obtained from the co-simulaiton using sockets, and the monolithic methods. As for the velocities problem, I didn't find a suitable interface in Chrono, so I think I would try to use some interpolation methods in Chrono to generate high-order position lines that include the information about velocities.
#### Eighth Week: July 20th-July 26th
To impose velocities to bodies in C::E, I may need more time to know the interpolation methods about quaternion. In the meantime, I added a check process to ensure that two codes have the consistent initial conditions, and improved codes for arbitrary number of nodes. The codes are complied successfully. In next week, I will test a multi-node case.
#### Ninth and tenth Weeks: July 27th-August 9th
To impose velocities to bodies in C::E, I try to use the SetPoint() function in Chrono, which gives the C::E motor information about the position, velocity, and acceleration. The codes are compiled, and tested. It follows that the results agree with those obtained from the linear interpolation method used before. However, some oscillations are observed on the velocity and acceleration levels. I need to know why these oscillations happen and how to avoid them.
### Embedded Optimization
* **Author**: [Boyan Zhou](@steven.b.zhou)
* **Mentors**: [Andrea Zanoni](@10260632), [Pierangelo Masarati](@10102934)
* **Branch**: [`gsoc_optimization`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_optimization)
* **Issue**: [Issue 55](#55)
The goal of the project is to enable the solution of **overactuated** inverse dynamics
problems directly in the MBDyn code.
The goal is for the developed code to enable the problems
* **fully determined overactuated**
* **underdetermined overactuated**
**Objectives**
* Minimum: enable the **overactuated** problems solving the underdetermined inverse
dynamics problem with a minimum norm solution;
* Desired: allow bounds to be added to the actuation (generalized) forces;
* Desired: allow the user to select the functional of the actuation (generalized) forces
to be minimized;
* Desired: allow for arbitrary contraints to be added.
#### First Week: June 1st-7th
My first week was mainly spent on studying the problem:
* read through inverse dynamic problem in techman, figure out different problem types;
* modified `mbdyn/base/invdyn.h`;
* start to read `mbdyn/base/invsolver.cc` and `mbdyn/base/invdataman.cc`
I am now working on the code and I think I will able to do more next week.
#### Second Week: June 8th-14th
After modified the following files:
* mbdyn/base/invsolver.cc
* mbdyn/base/invdataman.cc
overactuated problems can now be recognized by the parser and the inverse dynamics solver.
Changes with regard to the related files has been committed to gsoc_optimization branch
#### Third Week: June 15th-21st
Modified following functions to construct the problem:
* DataManager::AssConstrRes()
* DataManager::AssRes()
* DataManager::AssConstrJac()
The next step is to build up the solution.
#### Forth Week: June 22nd-28th
Test the input file 'planar_3link_ergo2_oa.mbd', and Made several discoveries:
* program stops at 10th step, when dealing with InverseDynamics::INVERSE_DYNAMICS
* program stops because the input matrix for UTSolve becomes singular
* problem at the inverse dynamics step is not actually written as a 'simple' linear problem, but as the iterative linear problem given by the solution of Newton-Raphson
Maybe the next step is to convert the problem to a simpler, single-step solution of the underlining linear problem.
#### Fifth Week: June 29th-July 5th
We find out that problem at the inverse dynamics step is formulated the
right way, so we just need to understand why it is not given the expected
results.
Also, I start to build up a check for the inverse dynamics problem, checking for input size, solver type, etc.
#### Sixth Week: July 6th-12nd
* Check the input and output, found many functions regarding inverse dynamic problems are NO_OP.
* Check the UTSolve(), found something strange (not sure if it is a bug).
* Try to trace the input matrix.
* Building Checks for inverse dynamic problems.
## 2021 GSoC Students Blog
[Satyam Kumar](@skdbsp123) and [Shubhaditya Burela](@shubhadityaburela), our 2021 GSoC students, will post here their weekly development blogs
* Satyam Kumar: [Convergence Criteria](#convergence-criteria-update)
* Shubhaditya Burela: [VLM Solver](#implementation-of-an-unsteady-vortex-lattice-method)
### Convergence Criteria Update
* **Author**: [Satyam Kumar](@skdbsp123)
* **Mentors**: [Marco Morandini](@marco.morandini), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 75](#75)
The convergence criteria determine if the result of the simulation during a timestep has been sufficiently accurate to advance to the next timestep. The goal of this project is to upgrade the currently implemented convergence criteria, by:
* flagging different equations and variables according to their physical dimensions;
* computing different residual norms for different physical domains;
* for each physical domain, computing a reference comparison value for the convergence check;
* developing and test the new convergence test.
#### First Week: June 7th-13th
In the first week, I focused on understanding the program flow. I ran the program for multiple test cases line by line using GDB.
Then I focused on understanding the class hierarchy of `NonlinearProblems`,
`StepIntegrators`, `NonlinearSolvers`, and other related classes.
I tried to understand how the residuals are calculated and how the convergence test is currently being used.
#### Second Week: June 14th-20th
In the second week, I created a new branch `gsoc-convergence-test`, then rebased it to `develop` branch. I focused on the `AbsRes` vector.
- I added the `AbsRes` vector to the `NonlinearSolverTestRelNorm`
- made the required changes in `NonlinearProblem::Residual` method and in all the subclasses, added
- added `GetAbsRes` method to `NonlinearSolverTest` class.
- defined the new `MakeTest` for `NonlinearSolverTestRelNorm`.
#### Third Week: June 21th-27th
In the third week, I completed the remaining part of codes for `NonlinearSolverTestRelNorm` and then starting planning the way to get dimensions of equations of elements and nodes. I declared a test function `GetEquationDimension` in the class `DofOwnerOwner` and overridden it in some classes in order to check if they are properly functioning or not. I used the case of double pendulum, and was successful in creating test function `GetEquationDimension` at the required places.
#### Fourth Week: June 28th-July 4th
In the fourth week, I focused on getting the proper dimensions of the elements and nodes. I successfully created the complete function `GetEquationDimension` for the the following classes
1. StructDispNode
2. StructNode
3. DynamicStructDispNode
4. DynamicStructNode
5. PlaneHingeJoint
6. PlanePinJoint
7. ClampJoint
Later I started working on the idea to store the indices of components of equations in a map of their corresponding dimensions.
#### Fifth Week: July 5th-11th
In the fifth week, I made changes in the class `NonlinearSolverTestSepNorm` in order to use the map of dimension and indices. Then I created two functions:
1. SetElemDimensionIndices()
2. SetNodeDimensionIndices()
I accessed these functions from `Solver::Prepare` and now we can move forward to code the `MakeTest` function of our new class `NonlinearSolverTestSepNorm`.
#### Sixth Week: July 12th-18th
In the sixth week, I completed the code of `MakeTest` function for `NonlinearSolverTestSepNorm`. Then I tested the code for three example cases
1. freely falling body
2. double pendulum
3. cantilever beam
#### Seventh Week: July 19th-25th
In the seventh week, I worked on making `GetEquationDimension` pure virtual.
I created the function for some subclasses of `Nodes` and I the work is still in progress.
#### Eighth Week: July 26th-August 1st
In the eighth week, I continued to add `GetEquationDimension` method for subclasses of `ElemWithDofs`.
#### Ninth Week: August 2nd-8th
In the ninth week, I completed adding `GetEquationDimension` method to add the required classes. I added all the files in the [commit](https://public.gitlab.polimi.it/DAER/mbdyn/-/commit/2fb5c183384641d356bbefc807439ea4d1a9264a).
I started adding `DefineEq` method to the classes where they are not already present.
### Implementation of an Unsteady Vortex Lattice Method
* **Author**: [Shubhaditya Burela](@shubhadityaburela)
* **Mentors**: [Alessandro Cocco](@alessandro.cocco), [Alberto Savino](@alberto.savino), [Andrea Zanoni](@10260632)
* **Issue**: [Issue 74](#74)
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.
#### First Week: June 7th-13th
In this first week, I started with understanding the UVLM code in MATLAB. The MATLAB code is to be replicated into C++ and implemented into a module which can then be loaded during runtime for which I started looking and understanding the module-template2 which gives an idea about how to implement a user-defined element. Next week I will start coding the UVLM method into C++ on the lines of the MATLAB code.
#### Second Week: June 14th-20th
In second week, I started coding basic classes for the input conditions of the UVLM problem. The plan now is to create an interface between MBDyn and an external UVLM solver library written in C++ and perform co-simulation. The MBDyn will handle the structural part and the UVLM library will handle the aerodynamic part of the simulation. The continuing work which follows is creating classes for Aerogrid generation and for performing a complete simulation of the aerodynamic part.
#### Third Week: June 21st-27th
In the third week, I continued with writing classes for the aero solver,
- I created `uvlmInterfaceBaseElem` class and added necessary structs like `MBDyn_UVLM_VMopts`, `MBDyn_UVLM_UVMopts` and `MBDyn_UVLM_Flightconditions` for the input handling.
- I defined `MBDyn_UVLM_AeroTimeStepInfo` class for defining the input arrays and matrices which will be used by the UVLM solver.
- I created another class called `Aero_Inputs` which takes in the raw inputs from the parser and creates necessary input arrays and matrices for use in the aero solver.
- Class `Aerogrid` is currently being written by me which will then handle the grid generation of the Aero solver.
#### Fourth Week: June 28th-July 4th
In the fourth week, I proceeded with the Aerogrid class.
- I wrote methods: `calculate_dimensions`, `add_timestep`, `generate_zeta` and `generate_mapping`.
- I created another class and its corresponding methods for straight wake generation called `StraightWake`.
- I also wrote `module-uvlm.h` and `module-uvlm.cc` files to a greater extent thus including the structural information which must be fed to the aero side of the code.
#### Fifth Week: July 5th-July 11th
In the fifth week, I implemented the function `generate_strip` which is the main function that creates the coordinates of the solid grid vertices. With this function, all the input arrays and the matrices required for the UVLM solver are now formulated.
#### Sixth Week: July 12th-July 18th
In the sixth week, I concentrated more on writing functions for the `UvlmInterfaceBaseElem` class. The constructor for the class was written along with the member functions `SetValue`, `Update`, `AfterConvergence`, `AfterPredict`, `BeforePredict`.
#### Seventh Week: July 19th-July 25th
In the seventh week, I proceeded forward with writing functions for the `UvlmInterfaceBaseElem` class. `MBDyn_UVLM_UpdateUVLMModel()`, `MBDyn_UVLM_SendDataToBuf_Curr()`, `MBDyn_UVLM_SendDataToBuf_Prev()`, `MBDyn_UVLM_RecvDataFromBuf()`.
#### Eighth Week: July 26th-August 1st
In the eighth week, I started writing the functions `MBDyn_UVLM_Model_RecvFromBuf` and `MBDyn_UVLM_Model_SendToBuf` which receive the kinematic data from the MBDyn subsystem and send the computed data back to the MBDyn system respectively.
#### Ninth Week: August 2nd-August 8th
In the ninth week, I started writing the functions `MBDyn_UVLM_Model_Init` and `MBDyn_UVLM_Model_DoStepDynamics` which initializes the UVLM solver and performs a step of time integration for the UVLM solver respectively.
#### Tenth Week: August 9th-August 15th
In the tenth week, I combined all the functions together to create four different files `module-uvlm.cc`, `module-uvlm.h`, `mbdyn_uvlm.cc` and `mbdyn_uvlm.h`. These files are the final files that will be used for running the simulation for the UVLM-MBDyn coupled solver.
## 2020 GSoC Students Blogs
[Runsen Zhang](@buaa_zhangrunsen) and [Boyan Zhou](@steven.b.zhou), our 2020 GSoC
students, will post here their weekly development blogs.
* Runsen Zhang: [MBDyn -- Chrono::Engine interface](#a-user-defined-runtime-loadable-module-template-for-co-simulation-with)
* Boyan Zhou: [Embedded Optimization](#embedded-optimization)
### A user-defined runtime loadable module template for co-simulation with [Chrono::Engine](http://projectchrono.org/)
* **Author**: [Runsen Zhang](@buaa_zhangrunsen)
* **Mentors**: [Pierangelo Masarati](@10102934), [Andrea Zanoni](@10260632)
* **Branch**: [`gsoc_chrono_interface`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_chrono_interface)
* **Issue**: [Issue 54](#54)
The goal of the project is to enable tight coupling co-simulation with [Chrono::Engine](https://projectchrono.org/) (C::E).
The MBDyn-C::E interface will be developed into a runtime loadable module, so that users can built their own C::E models with the
interface in the opaque object, and link it to the MBDyn’s module.
```mermaid
graph LR
A["Nodes <br /> (MBDyn)"] -->|Motion|B
subgraph module [runtime module]
B(Object<br /> Chrono::Engine)
end
B --> |Forces| C["Nodes<br />(MBDyn)"]
```
**Objectives**:
* Minimum: interface for single node in MBDyn & in C::E
MBDyn-side code for MBDyn module
* C::E-side code for MBDyn-C::E interface
* C::E code for example (e.f. a mass, or a mass and a spring, ...)
* Desired: interface for arbitrary number of nodes
#### First Week: June 1st-7th
In the first week, my mentors and I settled on the plan.
The scope of the first part of my plan is to built the MBDyn user-defined element, that
can achieve the tight coupling co-simulation. This defined-element is like the external
structural force element, and can call the simulation of a C::E model.
I summarised the coupling procedure in the co-simulation of C::E system, and
corresponded each step to the simulation process in MBDyn. And according to this, I am
starting writing the MBDyn-side codes. When this part works, I will test it using a
simple C::E model, and show them to the mentors.
#### Second Week: June 8th-14th
The following Files are created:
* ce_models.cc.
* mass1.mbd.
* mbdyn_ce.cc.
* module-chrono-interface.cc.
* libCE_models.so. （generated by files ce_models.cc, mbdyn_ce.cc, and mbdyn_ce.h）
In this week, the library "libCE_models.so" including an easy C::E model is generated, and connected to the MBDyn module::module-chrono-interface. And now, the C::E model and the MBDyn model could be loaded and solved in the meantime. In next week, attention will be paid to the data exchange between two solvers.
#### Third Week: June 15th-21st
In this week, I am working on the functions used in the co-simulation. Some functions are defined and added to the module. Through these functions, all coupling variables are saved in two std::vector containers in each iteration, and two solvers could send and receive data through these functions. More details will be defined in the following week.
#### Fourth Week: June 22nd-28th
In this week, I am working on the functions used in the co-simulation, and defined the following functions to construct the problem:
* AssRes();
* MBDyn_CE_RecvDataFromBuf();
* MBDyn_CE_SendDataToBuf().
And a demo that does not exchange coupling variables is run to test the code.
In next week, I will pay attention to imposing the motion to the selected bodies in C::E model.
#### Fifth Week: June 29th-July 5th
In this week, the codes for one coupling node is almost finished. I complied the codes, but didn't test them. Besides, the current codes need to be more general for a general coupling node, and that's what I will focus on next week.
#### Sixth Week: July 6th-July 12nd
In this week, the codes for one coupling node is tested by the two-dimension two-mass example. It seems that everything is OK. In next week, I will check the codes with different three-dimension examples. Besides, I will also think about how to impose coupling velocities to C::E bodies.
#### Seventh Week: July 13rd-July 19th
In this week, two examples, three-dimensional two-mass oscillator system and a three-dimensional pendulum system, are tested using the module-chrono-interface. It follows that results obtained are consistent with those obtained from the co-simulaiton using sockets, and the monolithic methods. As for the velocities problem, I didn't find a suitable interface in Chrono, so I think I would try to use some interpolation methods in Chrono to generate high-order position lines that include the information about velocities.
#### Eighth Week: July 20th-July 26th
To impose velocities to bodies in C::E, I may need more time to know the interpolation methods about quaternion. In the meantime, I added a check process to ensure that two codes have the consistent initial conditions, and improved codes for arbitrary number of nodes. The codes are complied successfully. In next week, I will test a multi-node case.
#### Ninth and tenth Weeks: July 27th-August 9th
To impose velocities to bodies in C::E, I try to use the SetPoint() function in Chrono, which gives the C::E motor information about the position, velocity, and acceleration. The codes are compiled, and tested. It follows that the results agree with those obtained from the linear interpolation method used before. However, some oscillations are observed on the velocity and acceleration levels. I need to know why these oscillations happen and how to avoid them.
### Embedded Optimization
* **Author**: [Boyan Zhou](@steven.b.zhou)
* **Mentors**: [Andrea Zanoni](@10260632), [Pierangelo Masarati](@10102934)
* **Branch**: [`gsoc_optimization`](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/gsoc_optimization)
* **Issue**: [Issue 55](#55)
The goal of the project is to enable the solution of **overactuated** inverse dynamics
problems directly in the MBDyn code.
The goal is for the developed code to enable the problems
* **fully determined overactuated**
* **underdetermined overactuated**
**Objectives**
* Minimum: enable the **overactuated** problems solving the underdetermined inverse
dynamics problem with a minimum norm solution;
* Desired: allow bounds to be added to the actuation (generalized) forces;
* Desired: allow the user to select the functional of the actuation (generalized) forces
to be minimized;
* Desired: allow for arbitrary contraints to be added.
#### First Week: June 1st-7th
My first week was mainly spent on studying the problem:
* read through inverse dynamic problem in techman, figure out different problem types;
* modified `mbdyn/base/invdyn.h`;
* start to read `mbdyn/base/invsolver.cc` and `mbdyn/base/invdataman.cc`
I am now working on the code and I think I will able to do more next week.
#### Second Week: June 8th-14th
After modified the following files:
* mbdyn/base/invsolver.cc
* mbdyn/base/invdataman.cc
overactuated problems can now be recognized by the parser and the inverse dynamics solver.
Changes with regard to the related files has been committed to gsoc_optimization branch
#### Third Week: June 15th-21st
Modified following functions to construct the problem:
* DataManager::AssConstrRes()
* DataManager::AssRes()
* DataManager::AssConstrJac()
The next step is to build up the solution.
#### Forth Week: June 22nd-28th
Test the input file 'planar_3link_ergo2_oa.mbd', and Made several discoveries:
* program stops at 10th step, when dealing with InverseDynamics::INVERSE_DYNAMICS
* program stops because the input matrix for UTSolve becomes singular
* problem at the inverse dynamics step is not actually written as a 'simple' linear problem, but as the iterative linear problem given by the solution of Newton-Raphson
Maybe the next step is to convert the problem to a simpler, single-step solution of the underlining linear problem.
#### Fifth Week: June 29th-July 5th
We find out that problem at the inverse dynamics step is formulated the
right way, so we just need to understand why it is not given the expected
results.
Also, I start to build up a check for the inverse dynamics problem, checking for input size, solver type, etc.
#### Sixth Week: July 6th-12nd
* Check the input and output, found many functions regarding inverse dynamic problems are NO_OP.
* Check the UTSolve(), found something strange (not sure if it is a bug).
* Try to trace the input matrix.
* Building Checks for inverse dynamic problems.