mbdyn issueshttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues2022-11-23T22:01:25+01:00https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/296NetCDF support for misc elements (including user-defined)2022-11-23T22:01:25+01:00Pierangelo MasaratiNetCDF support for misc elements (including user-defined)Some elements are still missing support for NetCDF output, significantly many user-defined onesSome elements are still missing support for NetCDF output, significantly many user-defined onesAndrea ZanoniAndrea Zanonihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/295NetCDF support for nodes other than structural2023-05-11T16:55:20+02:00Pierangelo MasaratiNetCDF support for nodes other than structuralNetCDF support is missing from non-structural nodesNetCDF support is missing from non-structural nodesAndrea ZanoniAndrea Zanonihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/293Add function to staticize variables in math parser2022-11-16T10:30:18+01:00Pierangelo MasaratiAdd function to staticize variables in math parserUse case: when a string drive is used, if the string contains a variable that may need to be changed during parsing (e.g., a counter for repetitive objects, CURR_BLADE for example) and we want to use the value of that variable, we could ...Use case: when a string drive is used, if the string contains a variable that may need to be changed during parsing (e.g., a counter for repetitive objects, CURR_BLADE for example) and we want to use the value of that variable, we could use "static(CURR_BLADE)", or "eval(CURR_BLADE)" to take the variable's value, rather than dereference it all times (getting the unexpected value instead).Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/292"inertia" NetCDF support broken and undocumented2024-02-19T21:50:06+01:00Pierangelo Masarati"inertia" NetCDF support broken and undocumentedWhen "output" is set to "always", the "inertial" pseudo-element outputs garbage in the NetCDF database.
Furthermore, the output data are undocumented and incomplete (the text format contains more flavors).
Absolute/relative position/orie...When "output" is set to "always", the "inertial" pseudo-element outputs garbage in the NetCDF database.
Furthermore, the output data are undocumented and incomplete (the text format contains more flavors).
Absolute/relative position/orientation could be optional, or alternative; the option of using a node's frame as the moving relative frame could be interesting.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/289"Central" gravity field uses gravity with respect to node instead of center o...2022-11-04T09:42:09+01:00Pierangelo Masarati"Central" gravity field uses gravity with respect to node instead of center of massWhen using the "central" gravity model, it would be more appropriate to evaluate gravity acceleration at the element's center of mass rather than at the node's reference point. In this manner, one could use multiple bodies connected to ...When using the "central" gravity model, it would be more appropriate to evaluate gravity acceleration at the element's center of mass rather than at the node's reference point. In this manner, one could use multiple bodies connected to the same structural node to model the gravity gradient effect acting on a rigid spacecraft.Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/280File drivers and output elements do not work with UDP sockets2022-10-17T12:05:00+02:00Andrea ZanoniFile drivers and output elements do not work with UDP socketsSeems like the handling of the "create" option for file drivers and output element is incorrect when UDP sockets are employed.
File drivers should wait for incoming connections (i.e. the corresponding sockets should be created by MBDyn...Seems like the handling of the "create" option for file drivers and output element is incorrect when UDP sockets are employed.
File drivers should wait for incoming connections (i.e. the corresponding sockets should be created by MBDyn, to act as servers), while output elements should connect to an external solver, acting as clients, so the corresponding sockets should not be created by MBDyn.
I make a quick fix in the `fix_udp_stream` branch, which seems to work.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/277Implement spherical joint's dGetPrivData2022-10-05T22:19:25+02:00黃祥雍Implement spherical joint's dGetPrivDataI want to use private data of spherical joint, but I can't find it in input manual.Does someone know where it is?I want to use private data of spherical joint, but I can't find it in input manual.Does someone know where it is?https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/276Restart functionality and simulation divergence2022-11-28T14:07:18+01:00Rodolfo Curci PuracaRestart functionality and simulation divergenceHello everybody,
I'm using mbdyn coupling it with CFD and with the CFD case size increasing I'm having trouble to finish the simulation due to time constraint in the cluster. So, the restart functionality is important for me to continue...Hello everybody,
I'm using mbdyn coupling it with CFD and with the CFD case size increasing I'm having trouble to finish the simulation due to time constraint in the cluster. So, the restart functionality is important for me to continue the simulation.
From what I understood, reading the manual and the codes, there is the functionality of writing a file to restart the simulation, but doing tests, this file ended up generating numbers, in the element part of the file, like 1.996025e-320 that led to an `MathParser` error. Replacing these numbers type by zero solved the error, but the simulations did not converge after the restart and the residuals are much higher when compared to the case without the restart for the same timestep.
Well I would like to know if anyone is working on this problem or if not, I would like to help make this functionality work at least in principle for the beam structural part of the program. Any idea or hint what might be missing in the code so that this divergence does not occur in the continuity of the simulation?
Thanks!https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/267Participation in GSOC projects2022-09-13T15:28:06+02:00Aditya GujariaParticipation in GSOC projectsHello,
My name is Aditya and I am currently a student at RWTH Aachen pursuing the course CAME (Computer Aided Mechanical Engineering), although I am in the end phase of it. I wanted to participate in GSoC 2019 but due to some prior comm...Hello,
My name is Aditya and I am currently a student at RWTH Aachen pursuing the course CAME (Computer Aided Mechanical Engineering), although I am in the end phase of it. I wanted to participate in GSoC 2019 but due to some prior commitments, I could not do it. Nonetheless, I want to participate in one of the projects without participating in GSoC as an open-source contributor. The project that I want to take up is "Implement new integration schemes".
I am aware of numerical integrators for differential equations such as Central Difference Method (explicit), Newmark (implicit), etc. I have implemented them using python during my coursework and have also formulated a modified version of CDM.
I have some questions:
1) Can I just contribute to the code without participating in GSoC?
If the answer is yes to the above question, I have some further queries.
2) Since I would be working full-time in an organization, I would not be able to commit very regularly. Would that be acceptable?
3) Would it be possible to get some mentorship every now and then related to the project?
and if the project is still open
4) Is it possible for you to share some literature regarding the project?
Awaiting your kind response.
Yours sincerely,
Aditya Gujariahttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/266New integrators do not work with variable time steps2024-02-19T22:00:49+01:00Reinhard ReschNew integrators do not work with variable time stepsDear Professor Morandini,
It seems that none of the new step integrators at the development branch have been tested with variable time steps. The parameter dAlpha is completely ignored. I tried to fix it for multistage integrators, but ...Dear Professor Morandini,
It seems that none of the new step integrators at the development branch have been tested with variable time steps. The parameter dAlpha is completely ignored. I tried to fix it for multistage integrators, but it does not work with structural nodes so far. See this branch for an first attempt:
[multistage-variable-timestep](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/multistage-variable-timestep)https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/258Document integrators2024-01-09T21:06:48+01:00Marco MorandiniDocument integrators@10102934 , @10260632 : right now the input manualin the `integrators` branch documents only the `crank nicolson` , `ms2`, `ms3`, `ms4`, `hope`, `bdf`, and `implicit euler` integrators.
I see no mention of `ss2`, `ss3`, `ss4`, `Bathe`,...@10102934 , @10260632 : right now the input manualin the `integrators` branch documents only the `crank nicolson` , `ms2`, `ms3`, `ms4`, `hope`, `bdf`, and `implicit euler` integrators.
I see no mention of `ss2`, `ss3`, `ss4`, `Bathe`, `msstc3`, `mssth3`, `msstc4`, `mssth4`, `msstc5`, `mssth5`, `DIRK33`, `DIRK43`, `DIRK54`.
Furthermore, the cited `ZHANG-2021-COMPMECH-MS34` bibliographic entry is missing from the .bib file.
Since I'm finalizing the merge of integrators into develop, it would be great if you could send me the missing manual lines (and possibly add something about the integrators framework to the tecman).Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/257Document "enforce constraint equations"2023-02-21T22:39:47+01:00Marco MorandiniDocument "enforce constraint equations"I fear this (and possibly other options) is not documented.I fear this (and possibly other options) is not documented.Reinhard ReschReinhard Reschhttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/242Diagonally Implicit Runge-Kutta Methods2022-09-06T17:07:29+02:00Reinhard ReschDiagonally Implicit Runge-Kutta MethodsDear MBDyn Developers,
I was thinking about the implementation of a diagonal implicit Runge Kutta method for MBDyn.
Something like "sdirk4" from the NASA report [TM–2016–219173](https://www.researchgate.net/publication/299389630_Diagona...Dear MBDyn Developers,
I was thinking about the implementation of a diagonal implicit Runge Kutta method for MBDyn.
Something like "sdirk4" from the NASA report [TM–2016–219173](https://www.researchgate.net/publication/299389630_Diagonally_Implicit_Runge-Kutta_Methods_for_Ordinary_Differential_Equations_A_Review). For a prototype implementation applied to implicit ODE's see also the attached file:
[radau5.m](/uploads/634f906554176bec92e061f0bcf1ebc8/radau5.m)
One of the advantages of such a method would be better stability in case of a variable step size.
So, I would like to ask you about your opinion, if this kind of method would be feasible for MBDyn. Of course I understand, that currently the number of stages is limited by the number of states stored by structural nodes. So, either I do not perform a prediction between the stages, or I have to use the ["integrators"](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/integrators) branch as a starting point. In the first case only elements using automatic differentiation would be supported.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/241Rotation parameters do not account for large rotations2022-08-17T20:51:22+02:00Reinhard ReschRotation parameters do not account for large rotationsIt seems that the rotation parameters are computed from the rotation matrix by assuming only small rotations, because of the incremental rotation handling in MBDyn. However, if we are using automatic differentiation and line search based...It seems that the rotation parameters are computed from the rotation matrix by assuming only small rotations, because of the incremental rotation handling in MBDyn. However, if we are using automatic differentiation and line search based nonlinear solvers for example, we could use larger time steps with larger changes in the rotation matrix during the nonlinear solution phase. This could violate the assumption of small rotations.
```
class Param_Manip : public Vec3_Manip {
public:
Param_Manip() {};
inline void Manipulate(Vec3& v, const Mat3x3& m) const {
// singularity test
doublereal d = 1. + m.Trace();
if (fabs(d) < std::numeric_limits<doublereal>::epsilon()) {
silent_cerr("Param_Manip(): divide by zero, "
"probably due to singularity in rotation parameters" << std::endl);
throw ErrDivideByZero(MBDYN_EXCEPT_ARGS);
}
v = m.Ax()*(4./d);
};
};
```
So, I would like to propose a new algorithm for the calculation of the rotation parameters in order to eliminate this limitation of small rotations. See the attached file:
[rotation_matrix_to_rotation_param.m](/uploads/f816466a9c805a07ceed877cf252a20e/rotation_matrix_to_rotation_param.m)https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/235The Front1D gust model does not work as expected2022-07-29T16:16:51+02:00Pierangelo MasaratiThe Front1D gust model does not work as expected- The argument of the gust function should be f^T*x - V*t;
- the argument of "g" should be interpreted as the local position in the front's local reference time;
- in the example, a "start time" (actually, the origin of the gust's local ...- The argument of the gust function should be f^T*x - V*t;
- the argument of "g" should be interpreted as the local position in the front's local reference time;
- in the example, a "start time" (actually, the origin of the gust's local frame) should be added.
A fix is coming; likely breaks backward compatibility.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/211Problem when calculate the eigenvector of a pure bending beam.2022-06-05T14:32:04+02:00yujia weiProblem when calculate the eigenvector of a pure bending beam.Hi developer,
I am able to use arpack solver to calculate the correct eigenvectors of a beam. But when I apply y-symmetric constraint (y = 0, R1 = R3 = 0) by many total joints (supposes to have only pure vertical bending, no torsion), ...Hi developer,
I am able to use arpack solver to calculate the correct eigenvectors of a beam. But when I apply y-symmetric constraint (y = 0, R1 = R3 = 0) by many total joints (supposes to have only pure vertical bending, no torsion), no eigenvectors will show anymore. The total joints I apply are shown in the figure, every node at the beam is constrained at y, R1 and R3 with the reference nodes.
I can't figure out why, could you give me any tips on how to calculate the eigenvector of a pure bending beam. BTW I use a general three-node beam, linear viscoelastic generic material.
Thank you for your help. If you need my test cases please let me know.
Kind regards,
Yj
![ttjoints](/uploads/c49948c10fa9c4b70b62e8d157cb5dd3/ttjoints.PNG)https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/206Driven element's condition cannot depend on own element's private data2023-02-21T14:27:15+01:00Pierangelo MasaratiDriven element's condition cannot depend on own element's private dataThe condition of a driven element cannot depend on its own driven element's private data. Intuitively, a simple workaround should be that of using a "postponed" drive caller, later defined based on the driven element's private data. Ho...The condition of a driven element cannot depend on its own driven element's private data. Intuitively, a simple workaround should be that of using a "postponed" drive caller, later defined based on the driven element's private data. However, during the initialization of the element and during the element's private data lookup, the activation test is performed.Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/201Spline and Multilinear scalar function wrongly extrapolate when computing the...2022-05-05T21:53:20+02:00Marco MorandiniSpline and Multilinear scalar function wrongly extrapolate when computing the derivative if "do not extrapolate is set"https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/200Get rid of `USE_AUTODIFF`2022-05-29T21:32:58+02:00Marco MorandiniGet rid of `USE_AUTODIFF`We should sketch a strategy for getting rid of `USE_AUTODIFF` and allow selecting the Jacobian bulding strategy at runtime. See the last part of [this](https://public.gitlab.polimi.it/DAER/mbdyn/-/merge_requests/69#note_1846) comment an...We should sketch a strategy for getting rid of `USE_AUTODIFF` and allow selecting the Jacobian bulding strategy at runtime. See the last part of [this](https://public.gitlab.polimi.it/DAER/mbdyn/-/merge_requests/69#note_1846) comment and then [this](https://public.gitlab.polimi.it/DAER/mbdyn/-/merge_requests/69#note_1847) for a preliminary discussion. @mbdyn-user @10102934https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/186Improve coupling with other software2022-05-20T20:05:11+02:00Arvind NarayananImprove coupling with other softwareHi! I am interested to collaborate in this project to couple MBDyn with MATLAB and Octave as part of GSoC 2022. I used to work for MathWorks where I helped in development of Simulink. I come from a mechanical engineering background and h...Hi! I am interested to collaborate in this project to couple MBDyn with MATLAB and Octave as part of GSoC 2022. I used to work for MathWorks where I helped in development of Simulink. I come from a mechanical engineering background and hence, I feel I can contribute well to this project since I have some experience.Andrea ZanoniAndrea Zanoni