mbdyn issueshttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues2023-06-27T20:48:35+02:00https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/311Implementation of an generic solid element for large deformations and large s...2023-06-27T20:48:35+02:00Reinhard ReschImplementation of an generic solid element for large deformations and large strainI'm working at the implementation of a generic solid element for MBDyn ([solid-element](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/solid-element)). It uses a total Lagrange formulation and supports arbitrary constitutive laws incl...I'm working at the implementation of a generic solid element for MBDyn ([solid-element](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/solid-element)). It uses a total Lagrange formulation and supports arbitrary constitutive laws including hyper-elasticity. Static and dynamic models are supported including gravity loads and rigid body kinematics. Nodal Cauchy-stress and Green-Lagrange strains can be written to a new output file. The following types of elements are available right now:
- 8-node hexahedron
- 20 node hexahedron
- 20 node hexahedron with reduced integration
- 15 node pentahedron
- 10 node tetrahedron
An enhanced assumed strain formulation or fully incompressible materials are not supported right now.
If you know a good element type or a special feature to be included, please let me know!https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/331Constitutive Matrix Transformation from Elemental Stiffness matrix2023-06-09T10:33:28+02:00Connor SchultzConstitutive Matrix Transformation from Elemental Stiffness matrixHi all,
I am attempting to use a Nastran output elemental stiffness matrix and transform it into an MBDyn beam element constitutive matrix for a fully-coupled anisotropic beam. This practice is simple for isotropic beams, but the transf...Hi all,
I am attempting to use a Nastran output elemental stiffness matrix and transform it into an MBDyn beam element constitutive matrix for a fully-coupled anisotropic beam. This practice is simple for isotropic beams, but the transformation has proven to be much more complex for a beam with complex geometry and coupling. Has anybody gone through this exercise before? Is there a well-known transformation matrix or method that I am missing?
Thanks,
Connorhttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/330When "no text" is used with NetCDF, textual files are created anyway2023-06-09T00:07:22+02:00Pierangelo MasaratiWhen "no text" is used with NetCDF, textual files are created anywayThey correctly remain empty, but they should not be created at allThey correctly remain empty, but they should not be created at allPierangelo MasaratiPierangelo Masaratihttps://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/141NetCDF output incompatible with driven elements2023-05-03T18:21:54+02:00Marco MorandiniNetCDF output incompatible with driven elementsDriven element do not emit output when switched off. I fear that this is not accounted for with the current NetCDF output implementation.[payloaddrop_ncdf](/uploads/4dcb1a758f09797f19a5bc929e96a46b/payloaddrop_ncdf)Driven element do not emit output when switched off. I fear that this is not accounted for with the current NetCDF output implementation.[payloaddrop_ncdf](/uploads/4dcb1a758f09797f19a5bc929e96a46b/payloaddrop_ncdf)Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/134Use --disable-dependency-tracking if having trouble with creating .deps/ file...2023-03-24T07:37:58+01:00AliUse --disable-dependency-tracking if having trouble with creating .deps/ files (Was: MBDyn build instructions possibly out of date)_[Note: Title edited to highlight the issue]_
Hello, I am trying to use MBDyn as a new user and am encountering build related issues.
I am following the steps provided on https://www.mbdyn.org/?Software_Installation.
My system is Ubunt..._[Note: Title edited to highlight the issue]_
Hello, I am trying to use MBDyn as a new user and am encountering build related issues.
I am following the steps provided on https://www.mbdyn.org/?Software_Installation.
My system is Ubuntu 18.04 LTS, and the issue I am encountering is related to running make after configure.
My process is as follows:
- install all dependencies listed on the above webpage
- make gcc g++ gfortran libltdl-dev liblapack-dev libsuitesparse-dev libnetcdf-dev libnetcdf-cxx-dev autoconf automake libtool autotools-dev
- clone and checkout develop branch from https://public.gitlab.polimi.it/DAER/mbdyn.git
- run bootstrap script
- ./configure
- make
Specifically, my problem occurs at the "make" step where make appears to be looking for some *.Plo files which have not been created.
![image](/uploads/df42c81d813898f8873c0bf145aaf9a8/image.png)
Since make is looking for non-existent compiled objects, is this an issue of configuration or ...?
I am quite eager to use MBDyn, and so, any and all assistance in resolving this build issue would be greatly appreciated.
Best Regardshttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/327Strings read by the general parser are limited in size; extra chars are ignor...2023-03-14T15:51:19+01:00Pierangelo MasaratiStrings read by the general parser are limited in size; extra chars are ignored with no warningStrings read by the general parser (not the mathematical one) are limited in size to `BUFSIZ` (if defined; to 8192 chars otherwise). They are read up to the size of the buffer and the rest is ignored, without any warning. An appropriat...Strings read by the general parser (not the mathematical one) are limited in size to `BUFSIZ` (if defined; to 8192 chars otherwise). They are read up to the size of the buffer and the rest is ignored, without any warning. An appropriate error message should be returned. Alternatively, the size of the buffer should dynamically grow to accommodate the whole string. Although the latter could sound preferable, such long strings usually can (and should) be avoided by alternative means (e.g., in `string` drive callers by breaking up complex mathematical expressions into smaller bits, using `drive caller` cards, and calling the sub-expressions in the final string).Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/49Unexpected precedence behavior in math parser (unary minus vs. power)2023-02-25T17:55:21+01:00Pierangelo MasaratiUnexpected precedence behavior in math parser (unary minus vs. power)-2^2 evaluates to 4 (unary minus has higher precedence than binary power operator); I think this contrasts with usual conventions (I'd expect -2^2 to evaluate to -4). At any rate, precedence of arithmetic operators should be well docume...-2^2 evaluates to 4 (unary minus has higher precedence than binary power operator); I think this contrasts with usual conventions (I'd expect -2^2 to evaluate to -4). At any rate, precedence of arithmetic operators should be well documented.Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/324Rename NetCDF prefix for constitutive laws2023-02-22T15:10:31+01:00Pierangelo MasaratiRename NetCDF prefix for constitutive lawsfrom "CL" to "constitutiveLaw", for consistency and better readabilityfrom "CL" to "constitutiveLaw", for consistency and better readabilityPierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/325Add support for NetCDF output and private data to cont-contact module2023-02-22T15:10:07+01:00Pierangelo MasaratiAdd support for NetCDF output and private data to cont-contact moduleThe cont-contact module is missing NetCDF support for additional output, and is not exposing the corresponding data as private data. A fix is coming.The cont-contact module is missing NetCDF support for additional output, and is not exposing the corresponding data as private data. A fix is coming.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/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/323Rename private data of rod joint2023-02-19T18:10:20+01:00Pierangelo MasaratiRename private data of rod jointThe use of "F", "L", and "LPrime" is inconsistent; the new names are "f", "l", and "lP" are used instead. Also, the "constitutiveLaw" prefix is too verbose; "CL" is used instead. Backward compatibility is preserved, with a warning.The use of "F", "L", and "LPrime" is inconsistent; the new names are "f", "l", and "lP" are used instead. Also, the "constitutiveLaw" prefix is too verbose; "CL" is used instead. Backward compatibility is preserved, with a warning.Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/320GSoC-2023 Initial Contact2023-02-16T16:04:43+01:00gautam shettyGSoC-2023 Initial ContactGreetings everyone,
I am Gautam Shetty and am currently pursuing my bachelor's in Mechanical Engineering at IIT Roorkee. I am interested in contributing to the mbdyn community as a part of GSOC 2023.
I have completed step 1 of the entr...Greetings everyone,
I am Gautam Shetty and am currently pursuing my bachelor's in Mechanical Engineering at IIT Roorkee. I am interested in contributing to the mbdyn community as a part of GSOC 2023.
I have completed step 1 of the entry test. I created a model for a crank-slider mechanism by following the steps on this [site](https://www.sky-engin.jp/en/MBDynTutorial/index.html). I am currently working on steps 2 and 3. For the next step, I was thinking to modify the code such that we can create a phase portrait for any system by running the program multiple times for different inputs. However, I am having difficulty understanding where to start; any feedback regarding this would be appreciated.
Regarding the project selection, I was thinking to go for the ground vehicle model development project or the tire model one. I chose these projects because of my experience in developing vehicle dynamics models. I have created an MF5.2 tire model and a 14DOF full-vehicle model on MATLAB. I am the vehicle dynamics head of our institute's formula student team so I have also worked with other multibody software like ADAMS for suspension simulations.
Apart from these projects, I can also work on the ones related to implementing or optimizing various numerical methods.
I look forward to working with the mbdyn community.
Cheers, Gautam.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/321One-time leak in bistop constitutive law wrapper2023-02-11T19:50:57+01:00Pierangelo MasaratiOne-time leak in bistop constitutive law wrapperThe bistop constitutive law wrapper does not destroy neither the wrapped constitutive law nor the activation/deactivation condition drive callers. A fix is coming (spotted using valgrind)The bistop constitutive law wrapper does not destroy neither the wrapped constitutive law nor the activation/deactivation condition drive callers. A fix is coming (spotted using valgrind)Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/310Build not possible on UBUNTU 22.042023-01-01T21:21:51+01:00Rocco VicedominiBuild not possible on UBUNTU 22.04Build on UBUNTU 22.04 fails following the instructions provided:
In file included from wraptest.cc:61:
naivewrap.h:59:27: error: ISO C++17 does not allow dynamic exception specificationsBuild on UBUNTU 22.04 fails following the instructions provided:
In file included from wraptest.cc:61:
naivewrap.h:59:27: error: ISO C++17 does not allow dynamic exception specificationshttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/304Rigid body kinematics incomplete for structural displacement nodes2022-12-27T12:49:38+01:00Reinhard ReschRigid body kinematics incomplete for structural displacement nodesIt seems that the rigid body kinematics for displacement only nodes is not implemented properly because `Mass::AssVecRBK_int` and `Body::AssVecRBK_int` are not consistent regarding the contribution to the force equilibrium. See [body.cc:...It seems that the rigid body kinematics for displacement only nodes is not implemented properly because `Mass::AssVecRBK_int` and `Body::AssVecRBK_int` are not consistent regarding the contribution to the force equilibrium. See [body.cc:184](https://public.gitlab.polimi.it/DAER/mbdyn/-/blob/develop/mbdyn/struct/body.cc#L184).
```
void
Mass::AssVecRBK_int(SubVectorHandler& WorkVec)
{
const RigidBodyKinematics *pRBK = pNode->pGetRBK();
Vec3 s0;
integer iIdx = 0;
if (dynamic_cast<DynamicMass *>(this)) {
iIdx = 3;
}
s0 = pNode->GetXCurr()*dMass;
// force
Vec3 f;
f = pRBK->GetXPP()*dMass;
WorkVec.Sub(iIdx + 1, f);
}
```
```
void
Body::AssVecRBK_int(SubVectorHandler& WorkVec)
{
const RigidBodyKinematics *pRBK = pNode->pGetRBK();
Vec3 s0;
integer iIdx = 0;
if (dynamic_cast<DynamicBody *>(this)) {
iIdx = 6;
}
s0 = pNode->GetXCurr()*dMass + STmp;
// force
Vec3 f;
f = pRBK->GetXPP()*dMass;
f += pRBK->GetWP().Cross(s0);
f += pRBK->GetW().Cross(pRBK->GetW().Cross(s0));
WorkVec.Sub(iIdx + 1, f);
...
}
```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/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/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 Masarati