Adapter advance with multiple interfaces

Using preCICE
1

Hi,
I understand that it is probably a hard question to answer without much context. I am extending my adapter to deal with multiple interfaces. As seen in other adapters, I defined an array of interfaces and performed the usual operations cycling through them. Everything looks ok until I perform “writeData” on each interface:

for( auto itr :interfaces){
    participant->writeData(itr->mesh, itr->dataName, itr->vertexIDs, itr->writeVector);
}
participant->advance(current_dt);

My code goes through the for loop and exits it but apparently gets stuck in “advance”. Any suggestions on why this could happen and what to check?
Thanks
Claudio

2

Everything looks ok until I perform “writeData” on each interface:

Are you saying that the advance() only hangs when you call writeData() before?
This would be highly suspicious as writeData() only overrides data in an existing buffer.

Of course, it’s difficult to know what is going on without a preCICE version and configuration. I assume there is a reason you are not providing them. Here are some general ideas.

In case of a parallel solver:

  • Are all ranks in the hanging participant reaching advance?
  • Is it possible that there is a significant difference between partitions of your mesh, which may lead to one rank taking significantly longer and forcing others to wait?

In case of a serial solver:

  • What is the last debug output of your solver? You can enable debug in release builds if that helps with the runtime.
  • Have you tried enabling <profiling mode="all"/> and see which events are the last before the application hangs? Performance analysis | preCICE - The Coupling Library
  • Is it possible to launch the application using a debugger and Ctrl-C when it hangs? Printing the backtrace at that point should give you a good idea where it gets stuck.
3

Hi @fsimonis,
thank you for the hints. Actually, everything was hanging because of a wrong precice configuration. I was setting up different coupling schemes between the same participants, which was not correct.
Claudio

4

Sounds like an upvote for this one :sweat_smile:

1 Like
5

Probably yes :joy:
I have an interface with one-way coupling and the other one with two-way implicit coupling.
But it seems to work for now.

6

I was able to extend another new check to also check for consistent configuration. Let’s not waste more time with silly mistakes like this :sweat_smile:

1 Like