Skip to content

GitLab

Last edited by Pierangelo Masarati
Page history

Home

Welcome to the MBDyn Developers Wiki!

If you're just looking for information about what MBDyn is, what it can do and what you can do with it, please refer to the MBDyn official website. In short, MBDyn is a general-purpose, free Multibody Dynamics analysis software.

This Wiki will eventually become a place in which developers can get information that will speed up their learning curve about the code. At the moment, it contains some basic information primarily focused on the MBDyn GSoC participation.

Please be aware that we, as MBDyn developers, believe strongly in the free software philosophy. In our daily work and in the MBDyn development and testing, we work with GNU/Linux as our primary OS. Therefore, to contribute to MBDyn you should be at least somewhat familiar with GNU/Linux.

How to contribute

There are different ways you can contribute to MBDyn. For example:

  • using it and reporting bugs (for example opening an issue), fixing/adding tutorials, documentation, suggesting new features to be added to the TODO list, and so on;
  • submitting code that fix bugs or implement new features, and so on;
  • establishing a grant with DAER/Polimi to implement the features or develop the models you need (to establish a contact, please send an email to mbdyn@aero.polimi.it).

If you feel to go with the second option (submitting code), please read carefully and follow our Developers Guidelines

Google Summer of Code

We have been selected as participating Orgs in the 2015, 2016, 2017, 2019, 2020, and 2021 Google Summer of Code (GSoC). You can find more information in the dedicated Wiki page if you're interested in participating to the GSoC with us.

Some Frequently Asked Questions

Where can I find the developers' manual?

The short answer is: there is no developers' manual, sorry. A more detailed answer is: it is being authored; a draft copy is distributed within code in manual/tecman, but it's far from complete and in a very preliminary status. Essentially, developers committed themselves to writing some technical documentation for each new feature that is added to the code, while features already implemented will get documented whenever they need review for whatever reason. Eventually, this document will become complete enough to be called "developers' manual".

How to Report a Bug?

The preferred method, since MBDyn moved to Gitlab, is to open an Issue. Doing so will provide for better bug tracking and task assignments. Please make sure your request for help or bug report is well formulated. See Simon Tatham's "How to Report Bugs Effectively" or R. Clint Whaley's "Why are you such a jerk when answering user questions? AKA: how can I help you feel good about providing me with support?" for effective discussion of how help requests and bug reports should and SHOULD NOT be formulated. Many thanks to Simon and Clint for spelling out so clearly what we believe often are every free software developer's contrasting feelings with users. In general, before you post a request for help or report a bug, you should first:

  • read the most appropriate documentation, including the FAQs;
  • search the MBDyn users mailing list archives: someone might have already addressed the same issue, and the answer could be already there;
  • post your request, following the previously mentioned indications.

What are run-time loadable modules, and how do they work?

MBDyn supports run-time loadable modules. A run-time loadable module is a piece of code that is loaded during the execution of MBDyn through the module load statement, defined as

module load : <module_name> [ , <args> ... ] ;

where <module_name> is the name of the object that implements the module, which can be a full path (e.g. libmodule-xxx.la, /usr/local/libexec/libmodule-yyy.la or so). Each module must provide a function declared as

extern "C" int module_init(const char *module_name, void *pdm, void *php);

where the last two arguments give access to internal structures of the solver.

This function is invoked when the module is loaded. Any optional args that follow the module name can be interpreted within this function call.

The purpose of this function is usually to register some piece of code that may be used later. A typical use is to register the code that parses a user-defined drive caller, constitutive law, or even an element. Even fancier features can be augmented using run-time loadable modules.

Several examples of user-defined drive callers, constitutive laws, and elements are provided in subfolders of the modules/ folder.

f you need something fancy, that cannot be directly obtained using the built-in library of entities, or you want to develop something that you don't want to share with other users (remember that the whole code is GPL), you should consider implementing it using a run-time loadable module.

Have a look at subfolders of the modules/ folder, starting from those that are closer to what you want to implement; try to understand how things work, and make sure that you follow these instructions when building MBDyn.