Maintainer needed (experience with MBDyn)

[IshaanDesai]

Dear preCICE community, dear MBDyn community,

as you see, this repository is currently not actively maintained, but it is also not abandoned. As the preCICE developers have limited experience with MBDyn, we would very happily accept contributions to keep this project up-to-date.

If you have experience with MBDyn, maintaining the adapter (e.g. updating for new MBDyn versions, commenting on issues, reviewing pull requests) would be quite easy and you would have all the help you need from our side. Due to the low demand for this adapter, the time demand would be also low and, of course, on your own pace. Any help appreciated, for as long as you like.

Contribute to a quickly growing free/open-source project, be part of an enthusiastic community. Simply comment here if you can help. 🤗

[Ccaccia73]

Hi all,
someone of you might remember me spamming the forum with convergence issues. I've been working on a MBDyn adapter in the last year. This ended up with my master thesis, my supervisor is the main responsible of the MBDyn development. I'll give you the link to it as soon as it is available. I started from the adapter in the preCICE repository but I decided to follow a slightly different route, using some different constructs of MBDyn, writing it in C++ and trying to make the simulation more flexible.
Apart from the programming language, the main difference between my solution and the current one is that my adapter makes use of the MBDyn construct "external structural mapping", which allows to map a cloud of external points (the wet surface) with the structural nodes of MBDyn, allowing to decouple shape from structural properties.
My thesis brought some preliminary results, as that version of the adapter had some issues which could roughly go under the "added mass instability" problems, in fact the classical Turek-Hron FSI3 benchmark wasn't converging.
Just a few days ago I found a solution (or a workaround, we are debating...) to this issue and FSI3 too works well (some tests are still ongoing).
Meanwhile I've been starting to write some installation instructions and application examples to be inserted in the MBDyn website (here: https://gitlab.com/stilita/mbdyn-esm-adapter/-/wikis/Home , still in progress). I would be very glad to do the same for the preCICE website, if possible. On the other side I could maintain the current adapter (which I know a little bit, as it was an inspiration for mine).
I would be very happy to contribute somehow to this project.
kind regards
Claudio

[IshaanDesai]

Hi @Ccaccia73, thanks a lot for writing here and offering help with maintaining the adapter. One basic question: is your new adapter at least code skeleton wise similar to the current design? If you copied your adapter to a branch and opened a pull request how would it look in terms of number of changes? Will it be manageable to review the changes and run some tests?

Which fluid solver do you use for the Turek-Hron FSI3 benchmark? Is it possible for someone with no knowledge of MBDyn to run the case and check the results?

As soon as you are done with the documentation on the MBDyn GitLab we can discuss adding ti to the preCICE website repo

[Ccaccia73]

Hi @IshaanDesai, I would say that the skeleton is similar, in the sense that there exist two classes, one dealing with MBDyn and the other dealing with preCICE. The current adapter basically writes its own MBDyn configuration file, mine does not, also because the same configuration file is needed for some preliminary operations in MBDyn.

If you copied your adapter to a branch and opened a pull request how would it look in terms of number of changes? Will it be manageable to review the changes and run some tests?

Sorry, I don't exactly understand what you mean. Do you mean make a pull request of my adapter to the current one? I don't know... the current one is in python, mine in C++. and I have no idea what could be.

Which fluid solver do you use for the Turek-Hron FSI3 benchmark?

I used OpenFOAM.

Is it possible for someone with no knowledge of MBDyn to run the case and check the results?

It is not easy but not impossible. My idea is to provide some test cases (some of them coupled with a dummy fluid solver that I used to check how things work with MBDyn) and other cases (FSI2, FSI3 among others) which basically follow the common idea of having 2 shells in which you type ./runFluid and ./runSolid and, as long as you managed to compile everything, the simulation should run. Setting up a case from zero would be a different story. I started writing something about it, but it can be tricky.

[IshaanDesai]

Hi @Ccaccia73 it is good to know that the skeleton is similar.

The current adapter basically writes its own MBDyn configuration file, mine does not, also because the same configuration file is needed for some preliminary operations in MBDyn.

Okay this is indeed a major difference and would need to be clearly stated if both adapters are supported.

Do you mean make a pull request of my adapter to the current one? I don't know... the current one is in python, mine in C++. and I have no idea what could be.

Yes I meant how such a pull request would look like. If the languages themselves are different then I think the pull request would indeed be messy. I would suggest the following: you can open a pull request where the current python adapter exists in its original form and the C++ adapter is supported in a folder on the same branch. Basically we can just add the C++ adapter as an extension folder to the current repository. It would then be very helpful if you could update the README and provide steps on how to use the C++ variant.

My idea is to provide some test cases (some of them coupled with a dummy fluid solver that I used to check how things work with MBDyn)

We can provide the coupled cases with dummy solvers in this repository itself. Such cases are vital to help new users understand the working of the adapter. In the future such cases can also become integration tests which help in maintaining the adapter repository! For now I would suggest we can create a tutorials/ folder in this adapter repository and just provide the cases with documentation on how to run them.

other cases (FSI2, FSI3 among others) which basically follow the common idea of having 2 shells in which you type ./runFluid and ./runSolid and, as long as you managed to compile everything, the simulation should run.

For this I would recommend opening a pull request in the tutorials repository. I would be very happy to guide you in adding a tutorial there!

Setting up a case from zero would be a different story. I started writing something about it, but it can be tricky.

Having this information in the website documentation would be very helpful for new users who want to use the MBDyn-Adapter, but I would say this is not critical and we can work on this at a later point of time.

Thanks a lot for your work with the MBDyn-Adapter and I am looking forward to your contributions here 😄