mbdyn issueshttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues2021-04-24T22:49:55+02:00https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/15Gravity not used in initial joint assembly2021-04-24T22:49:55+02:00Pierangelo MasaratiGravity not used in initial joint assemblyDespite adding "use: gravity, in assembly;" to the control data block, gravity is not used in initial joint assemblyDespite adding "use: gravity, in assembly;" to the control data block, gravity is not used in initial joint assemblyPierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/18Build with CMake2019-05-31T01:14:36+02:00Rafael MudafortBuild with CMakeHas a build environment configured with CMake been considered? I've started to build this up in mbdyn and the complication lies in understanding which modules are connected, but someone with more knowledge may be able to build this up qu...Has a build environment configured with CMake been considered? I've started to build this up in mbdyn and the complication lies in understanding which modules are connected, but someone with more knowledge may be able to build this up quicker.
Some advantages to CMake are
- simpler support for cross platform and cross compiler
- simpler methods for adding new files
- I'm familiar with it so I can use it easier :)
I can continue to try this out slowly, but I'm wondering if you've thought about it and decided to not go with cmake for a particular reason.
Thanks!
Rafaelhttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/20Create Flatpak application2019-07-08T14:44:03+02:00Richard CrozierCreate Flatpak applicationThis issue is to discuss the creation of a Flatpak application for distribution on [Flathub](https://flathub.org/home). Flatpak provides a means of easily distributing applications to a wide range of Linux systems, with a single configur...This issue is to discuss the creation of a Flatpak application for distribution on [Flathub](https://flathub.org/home). Flatpak provides a means of easily distributing applications to a wide range of Linux systems, with a single configuration to set up.
This is something I might like to work on in the future, but would like to know if it will be used if I do so. Is this something that the MBDyn developers would like? It would make it much easier for users to get MBDyn.
The [Octave](https://github.com/flathub/org.octave.Octave) Flatpak configuration could be used as a starting point for MBDyn as it uses many of the same libraries (would probably just need cut down a bit).https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/23New branch to return current simulation time with structural external force k...2021-02-14T17:18:25+01:00Richard CrozierNew branch to return current simulation time with structural external force kinematicsI just pushed a new branch, strext-send-time which contains my first attempt at modifying MBDyn to send the current simulation time along with the node kinematics to the external program. This is useful, particularly if you are doing any...I just pushed a new branch, strext-send-time which contains my first attempt at modifying MBDyn to send the current simulation time along with the node kinematics to the external program. This is useful, particularly if you are doing anything other than the basic fixed time step scheme, as otherwise it is a bit of a pain to get this information.
I'm interested in getting comments on this, first of all, is it welcome? I've already got it working at least for the basics structural external force, at least when there is not reference node. I've not tested it with a reference node yet.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/27out-of-source-tree build fails to build modules2024-02-07T07:47:12+01:00Richard Crozierout-of-source-tree build fails to build modulesIf you attempt to build in a directory other than the source directory (VPATH build) with a module enabled, the module is not built, it fails with e.g. "No rule to make target for 'module-XXX.cc'.If you attempt to build in a directory other than the source directory (VPATH build) with a module enabled, the module is not built, it fails with e.g. "No rule to make target for 'module-XXX.cc'.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/28Building with --enable-debug fails with error: ‘_assert’ was not declared in ...2024-02-07T07:33:23+01:00Richard CrozierBuilding with --enable-debug fails with error: ‘_assert’ was not declared in this scopeIf I configure like this:
```
configure --with-module=fabricate \
LDFLAGS="-rdynamic" \
--enable-runtime-loading \
--enable-debug \
--with-boost \
--prefix=/usr/local \
...If I configure like this:
```
configure --with-module=fabricate \
LDFLAGS="-rdynamic" \
--enable-runtime-loading \
--enable-debug \
--with-boost \
--prefix=/usr/local \
--enable-install_test_progs=no \
--with-umfpack \
--with-metis=no \
--with-ginac=yes \
CXXFLAGS="$CXXFLAGS -std=c++11" \
CPPFLAGS="$CPPFLAGS -I/usr/include/suitesparse"
```
I get the following error:
```
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../include -I../../include -I./../../include -I./../../libraries/libmbutil -I./../../libraries/libmbmath -I./../../mbdyn -I/usr/include/suitesparse -std=c++11 -pthread -MT mynewmem.lo -MD -MP -MF .deps/mynewmem.Tpo -c mynewmem.cc -fPIC -DPIC -o .libs/mynewmem.o
myassert.cc: In function ‘void _Assert(const char*, int, const char*)’:
myassert.cc:82:4: error: ‘_assert’ was not declared in this scope
_assert(msg, file, line);
^~~~~~~
myassert.cc:82:4: note: suggested alternative: ‘_Assert’
_assert(msg, file, line);
^~~~~~~
_Assert
```
This is on Ubuntu 18.04https://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/53Non-informative memory allocation failures2020-05-30T07:55:33+02:00Pierangelo MasaratiNon-informative memory allocation failuresWhen memory allocation fails, the code exits with a rather generic and non-informative error message. This is related to fairly old and no longer working memory debugging and management.When memory allocation fails, the code exits with a rather generic and non-informative error message. This is related to fairly old and no longer working memory debugging and management.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/58Added mass element2020-06-28T15:52:13+02:00Richard CrozierAdded mass elementI am opening an issue to discuss the addition of an added mass element to MBDyn which adds apparent mass (and inertia) when a body moves through fluid (more information here: https://en.wikipedia.org/wiki/Added_mass). I began some work t...I am opening an issue to discuss the addition of an added mass element to MBDyn which adds apparent mass (and inertia) when a body moves through fluid (more information here: https://en.wikipedia.org/wiki/Added_mass). I began some work to create such an element, using as a starting point the body element. I have pushed this work to Gitlab to the branch [added_mass_element](https://public.gitlab.polimi.it/DAER/mbdyn/-/tree/added_mass_element).
The element can now be used, and an example simple test case is shown below, which applies a 1N force in each of the X, Y and Z directions. The resulting node velocity is shown in the attached figure, which demonstrates the 1N force in each direction resulting in a different acceleration in each direction as expected.
![image](/uploads/6e7906d482aad3ca415759a638a68a55/image.png)
At the moment the main issue is that the added mass terms are essentially locked to the global frame, while the added inertia rotates with the attached node. This is because I have simply started from the body element, and modified it so that the mass term is a three element vector, but I have not yet introduced any change to the orientation of the forces. I wonder if anyone could help with this part?
If anyone else is interested it would be good to have someone else review the element, and other changes. I had to change some core code to make this work, for example I changed AutomaticStructElem::ComputeAccelerations to internally store the mass as a three element vector, by default all the values are the same. Again I haven't accounted for the orientation of the node here (and haven't even really thought about whether I need to do this here).
Test file:
```
begin: data;
problem: initial value;
end: data;
# initial value problem
begin: initial value;
initial time: 0.0;
final time: 5.0;
time step: 0.01;
tolerance: 0.0000001;
max iterations: 20;
linear solver: naive ;
end: initial value;
begin: control data;
structural nodes: 1;
added masses: 1;
forces: 1;
default orientation: orientation matrix;
output results: netcdf, no text;
end: control data;
begin: nodes;
# 6 DOF structural node
structural : 1, dynamic, # label, type
position, 0.0, 0.0, 0.0, # absolute position
orientation,
matr,
1.0, 0.0, 0.0,
0.0, 1.0, 0.0,
0.0, 0.0, 1.0, # absolute orientation
velocity, 0.0, 0.0, 0.0, # absolute velocity
angular velocity, 0.0, 0.0, 0.0, # absolute angular velocity
accelerations, no
; # end structural node
end: nodes;
begin: elements;
# added mass
added mass : 2, 1, # label, node label
1.0, 2.0, 3.0, # added mass in x, y and z
0.0, 0.0, 0.0, # relative centre of mass
matr,
1.0, 0.0, 0.0,
0.0, 1.0, 0.0,
0.0, 0.0, 1.0 # added inertia matrix
; # end added mass
force : 3,
absolute,
1,
position, reference, node, null,
component,
const, 1.0,
const, 1.0,
const, 1.0
; # end structural force
end: elements;
```https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/61Inconsistencies and too little info in error messages from math parser2020-12-06T12:15:41+01:00Pierangelo MasaratiInconsistencies and too little info in error messages from math parserThe math parser is often very little informative and inconsistent about errors in expressions. For example, using an undefined variable like this
`set: 2*x;`
gives "(unexpected token) at line 1", whereas
`set: x*2;`
correctly gives "(un...The math parser is often very little informative and inconsistent about errors in expressions. For example, using an undefined variable like this
`set: 2*x;`
gives "(unexpected token) at line 1", whereas
`set: x*2;`
correctly gives "(unable to find variable "default::x") at line 1".
A thorough revision would be advisable.https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/64Drive callers with/without argument (model::drive function, etc.)2021-02-14T17:17:30+01:00Pierangelo MasaratiDrive callers with/without argument (model::drive function, etc.)The model::drive function requires two arguments: the label of the drive caller, and the value. However, some drive callers do not use the value. Passing it should either be optional (Time would be used, if required), or drive callers ...The model::drive function requires two arguments: the label of the drive caller, and the value. However, some drive callers do not use the value. Passing it should either be optional (Time would be used, if required), or drive callers should be able to tell whether they can honor the value argument. An example is attached [variabledrive](/uploads/7c6f2cf2256baac35066505fb1306b54/variabledrive)Pierangelo MasaratiPierangelo Masaratihttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/89./libtool: No such file or directory when configuring2021-10-14T11:19:17+02:00Alessandro Barbierilssndrbarbieri@gmail.com./libtool: No such file or directory when configuring```
checking for ltdl.h... yes
checking for lt_dlinit in -lltdl... yes
./configure: line 31406: ./libtool: No such file or directory
```
at line 31406 of `configure` there is this
```
EXPORT_DYNAMIC_FLAG_SPEC=`(./libtool --config; echo ...```
checking for ltdl.h... yes
checking for lt_dlinit in -lltdl... yes
./configure: line 31406: ./libtool: No such file or directory
```
at line 31406 of `configure` there is this
```
EXPORT_DYNAMIC_FLAG_SPEC=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh`
```https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/91mpi c++ is deprecated2022-07-02T14:46:42+02:00Marco Morandinimpi c++ is deprecatedmpi c++ wrappers are [deprecated](https://github.com/mpi-forum/mpi-forum-historic/issues/150) since mpi-3, we should either
- use boost MPI
- use c MPI
- get rid of Schurmpi c++ wrappers are [deprecated](https://github.com/mpi-forum/mpi-forum-historic/issues/150) since mpi-3, we should either
- use boost MPI
- use c MPI
- get rid of Schurhttps://public.gitlab.polimi.it/DAER/mbdyn/-/issues/97error: Could not locate SuperLU2021-09-05T00:29:07+02:00Alessandro Barbierilssndrbarbieri@gmail.comerror: Could not locate SuperLUconfiguring with `--with-superlu`
```
checking for dsp_defs.h... no
checking for pdsp_defs.h... no
checking for util.h... no
configure: error: Could not locate SuperLU
```
but I have superlu installed (https://crd-legacy.lbl.gov/~xiaoye/...configuring with `--with-superlu`
```
checking for dsp_defs.h... no
checking for pdsp_defs.h... no
checking for util.h... no
configure: error: Could not locate SuperLU
```
but I have superlu installed (https://crd-legacy.lbl.gov/~xiaoye/SuperLU/)
```
* Searching for superlu ...
* Contents of sci-libs/superlu-5.2.2:
/usr/include/superlu/slu_Cnames.h
/usr/include/superlu/slu_cdefs.h
/usr/include/superlu/slu_dcomplex.h
/usr/include/superlu/slu_ddefs.h
/usr/include/superlu/slu_scomplex.h
/usr/include/superlu/slu_sdefs.h
/usr/include/superlu/slu_util.h
/usr/include/superlu/slu_zdefs.h
/usr/include/superlu/superlu_enum_consts.h
/usr/include/superlu/supermatrix.h
/usr/lib/debug/usr/lib64/libsuperlu.so.5.2.2.debug
/usr/lib64/cmake/superlu/superluConfig.cmake
/usr/lib64/cmake/superlu/superluConfigVersion.cmake
/usr/lib64/cmake/superlu/superluTargets-gentoo.cmake
/usr/lib64/cmake/superlu/superluTargets.cmake
/usr/lib64/libsuperlu.so -> libsuperlu.so.5
/usr/lib64/libsuperlu.so.5 -> libsuperlu.so.5.2.2
/usr/lib64/libsuperlu.so.5.2.2
/usr/lib64/pkgconfig/superlu.pc
/usr/share/doc/superlu-5.2.2/README
```https://public.gitlab.polimi.it/DAER/mbdyn/-/issues/103libltdl isn't linked2021-10-22T00:23:29+02:00Alessandro Barbierilssndrbarbieri@gmail.comlibltdl isn't linkedConfigured with `./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-trac...Configured with `./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/mbdyn-1.7.3_p20210925 --htmldir=/usr/share/doc/mbdyn-1.7.3_p20210925/html --with-sysroot=/ --libdir=/usr/lib64 --disable-static --disable-Werror --enable-runtime-loading --with-lapack --without-charm --without-g2c --without-goto --without-harwell --without-pardiso --without-rtai --without-static-modules --without-strumpack --without-wsmp --enable-autodiff --enable-crypt --disable-debug --enable-eig --enable-mbc --enable-multithread-naive --enable-netcdf --enable-octave --enable-octave-utils --enable-python --disable-schur --disable-install_test_progs --enable-multithread --with-ann --with-arpack --with-boost --with-bullet --with-ginac --with-jdqz --without-metis --with-openblas --with-pam --with-pastix --with-qrupdate --with-rt --with-sasl2 --with-klu --with-suitesparseqr --with-umfpack --without-superlu --with-threads --with-y12 --enable-sparse-autodiff --disable-debug-mpi --without-mpi --with-module="asynchronous_machine autodiff_test ballbearing_contact bullet charm constlaw-f90 constlaw-f95 constlaw cont-contact controller convtest cyclocopter damper-gandhi damper-graall damper-hydraulic damper diff dot drive-test drive dummy eu2phi fab-electric fab-motion fab-sbearings fabricate flightgear friction friction3 hfelem hid hunt-crossley hydrodynamic_plain_bearing hydrodynamic_plain_bearing2 imu indvel inline_friction inplane_friction journal_bearing leapmotion loadinc marble md mds minmaxdrive multi_step_drive muscles namespace nodedistdrive nonsmooth-node ns octave randdrive rollercoaster rotor-loose-coupling scalarfunc switch_drive tclpgin triangular_contact uni_in_plane wheel2 wheel4"`
Seems that libltdl isn't linked
```
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../include -I../include -I./../include -I./../libraries/libmbutil -I./../libraries/libmbmath -I./../libraries/libmbwrap -I./../libraries/libmbc -I./../mbdyn/base -I./../mbdyn/struct -I./../
mbdyn/thermo -I./../mbdyn/aero -I./../mbdyn/elec -I./../mbdyn/hydr -D_GLIBCXX_ASSERTIONS -Os -pipe -march=native -fdiagnostics-color=always -fexceptions -Wformat -fstack-clash-protection -I/usr/include/bullet -march=native -mtune=nati
ve -pthread -c -o mbdyn.o mbdyn.cc
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../include -I../include -I./../include -I./../libraries/libmbutil -I./../libraries/libmbmath -I./../libraries/libmbwrap -I./../libraries/libmbc -I./../mbdyn/base -I./../mbdyn/struct -I./../
mbdyn/thermo -I./../mbdyn/aero -I./../mbdyn/elec -I./../mbdyn/hydr -D_GLIBCXX_ASSERTIONS -Os -pipe -march=native -fdiagnostics-color=always -fexceptions -Wformat -fstack-clash-protection -I/usr/include/bullet -march=native -mtune=nati
ve -pthread -c -o ginac_mbdyn_abs.o ginac_mbdyn_abs.cc
libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Os -pipe -march=native -fdiagnostics-color=always -fexceptions -Wformat -fstack-clash-protection -I/usr/include/bullet -march=native -mtune=native -pthread -Wl,-O1 -Wl,--as-nee
ded -Wl,--sort-common -pthread -o mbdyn mbdyn.o ginac_mbdyn_abs.o ../mbdyn/base/libbase.la aero/libaero.la struct/libstruct.la elec/libelec.la thermo/libthermo.la hydr/libhydr.la base/libbase.la ../libraries/libmbc/libmbc_static.la ..
/libraries/libmbwrap/libmbwrap.la ../libraries/libann/libmbann.la -lginac -lcln /var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0/libraries/liby12/liby12.la -lm -L/usr/lib -lpastix -
lpastix_kernels -lspm -lhwloc -lqrupdate -lspqr -lcholmod -larpack -ljdqz -llapack -lumfpack -lcholmod -lm -lcamd -lm -lccolamd -lm -lcolamd -lm -lamd -lm -lklu -lamd -lcolamd -lbtf -lsasl2 -lcrypt -lpam -lpam_misc -ldl -lcrypt -lnetc
df_c++4 -lnetcdf -lrt -lann -loctinterp -loctave -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -L/usr/lib64/octave/6.3.0 -Wl,-rpath=/usr/lib64/octave/6.3.0 -lcblas -lf77blas -latlas -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1 -L/usr/lib/g
cc/x86_64-pc-linux-gnu/10.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../.
./.. -lgfortran -lm -lquadmath -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-li
nux-gnu/lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../.. -lgfortran -lm -lquadmath -lm -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../lib64 -L/lib/../li
b64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../.. -lgfortran -lm -lquadmath -lsuitesparseconfig -lrt -lm
-lsuitesparseconfig -lm -lrt -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-lin
ux-gnu/lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../.. -lgfortran -lm -lquadmath -lginac -lcln -lsuitesparseconfig -lrt -lm -lsuitesparseconfig -lm -lrt -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1 -L/
usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-pc-linux-gnu/10
.3.1/../../.. -lgfortran -lm -lquadmath
libtool: link: x86_64-pc-linux-gnu-g++ -Os -pipe -march=native -fdiagnostics-color=always -fexceptions -Wformat -fstack-clash-protection -I/usr/include/bullet -march=native -mtune=native -pthread -Wl,-O1 -Wl,--as-needed -Wl,--sort-commo
n -pthread -o mbdyn mbdyn.o ginac_mbdyn_abs.o -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-rpath=/usr/lib64/octave/6.3.0 ../mbdyn/base/.libs/libbase.a aero/.libs/libaero.a struct/.libs/libstruct.a elec/.libs/libelec.a thermo/.libs/li
bthermo.a hydr/.libs/libhydr.a base/.libs/libbase.a ../libraries/libmbc/.libs/libmbc_static.a -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/u
sr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../.. ../libraries/libmbwrap/.libs/libmbwrap.a -lpthread -L/usr/lib ../libraries/libann/.
libs/libmbann.a /var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0/libraries/liby12/.libs/liby12.a -lpastix -lpastix_kernels -lspm -lhwloc -lqrupdate -lspqr -larpack -ljdqz -llapack -l
umfpack -lcholmod -lcamd -lccolamd -lklu -lamd -lcolamd -lbtf -lsasl2 -lpam -lpam_misc -ldl -lcrypt -lnetcdf_c++4 -lnetcdf -lann -loctinterp -loctave -L/usr/lib64/octave/6.3.0 -lcblas -lf77blas -latlas -lginac -lcln -lsuitesparseconfig
-lrt -lgfortran -lm -lquadmath -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../mbdyn/base/.libs/libbase.a(dataman3.o): in function `DataManager::ReadControl(MBDynParser&, char const*)':
dataman3.cc:(.text+0x19a5): undefined reference to `lt_dladdsearchdir'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: dataman3.cc:(.text+0x1ab9): undefined reference to `lt_dlsetsearchpath'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../mbdyn/base/.libs/libbase.a(mbpar.o): in function `MBDynParser::ModuleLoad_int()':
mbpar.cc:(.text+0x3fe3): undefined reference to `lt_dlopenext'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: mbpar.cc:(.text+0x3ff4): undefined reference to `lt_dlerror'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: mbpar.cc:(.text+0x4125): undefined reference to `lt_dlsym'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: mbpar.cc:(.text+0x4133): undefined reference to `lt_dlerror'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../mbdyn/base/.libs/libbase.a(modules.o): in function `module_initialize()':
modules.cc:(.text+0xe6): undefined reference to `lt_dlinit'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: modules.cc:(.text+0x186): undefined reference to `lt_dlsetsearchpath'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../mbdyn/base/.libs/libbase.a(modules.o): in function `module_finalize()':
modules.cc:(.text+0x83): undefined reference to `lt_dlexit'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../mbdyn/base/.libs/libbase.a(loadable.o): in function `LoadableElem::~LoadableElem()':
loadable.cc:(.text+0x44c): undefined reference to `lt_dlclose'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: ../mbdyn/base/.libs/libbase.a(loadable.o): in function `LoadableElem::GetCalls(MBDynParser&)':
loadable.cc:(.text+0x703): undefined reference to `lt_dlopenext'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: loadable.cc:(.text+0x715): undefined reference to `lt_dlerror'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: loadable.cc:(.text+0x877): undefined reference to `lt_dlsym'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: loadable.cc:(.text+0x885): undefined reference to `lt_dlerror'
collect2: error: ld returned 1 exit status
remake[2]: directory '/var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0/mbdyn'
remake[2]: *** [mbdyn] error 1
remake[2]: Leaving directory '/var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0/mbdyn'
remake[1]: directory '/var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0/mbdyn'
remake[1]: *** [all-recursive] error 1
remake[1]: Leaving directory '/var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0/mbdyn'
remake: directory '/var/tmp/portage/sci-physics/mbdyn-1.7.3_p20210925/work/mbdyn-ae57618c4e7b030b59707b8c156a6e2a94a6efd0'
remake: *** [all-recursive] error 1
```https://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/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/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/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/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?