Is it clear for the user that with sync-mode="on", they could create their own deadlock?

In general, I am a bit afraid that we are opening another box for v3.0 🙈

I don't think that user events should be synchronised and in this PR they aren't. This can always be done in user code.

Right now, I don't see the real use-case for these API functions. Main reasons:

• the adapters speak the language of the solvers and if the solver is performance oriented, they will have their own performance instrumentation, which is also more natural to use then
• for tools like ASTE, the interesting part happens in preCICE, not in ASTE
• we already measure the solver.advance calls which are a summary of the solver events within a time-step

To me this API sound more like an extension of the framework we want to couple.

the adapters speak the language of the solvers and if the solver is performance oriented, they will have their own performance instrumentation, which is also more natural to use then

Yes in theory.
In practise, this doesn't seem to be straight forward though (FEniCS, OpenFOAM). Maybe we can get some input by other adapter devs here: @BenjaminRodenberg @IshaanDesai @MakisH @uekerman

A valuable use-case in my mind is allowing to profile adapters of commercial and/or closed-source codes such as Fluent @mtree22 or TAU.
Some tools like CalculiX also don't use profiling themselves.

for tools like ASTE, the interesting part happens in preCICE, not in ASTE

True.

However, it would remove the need for custom profiling inside ASTE.
Given that ASTE is basically pure IO and distributed filesystems tend to be slow, it may be interesting to profile the time spend creating output files for example. Especially as we use ASTE on big distributed machines.

Other tools could profit from this functionality, prime example being the micro-manager @IshaanDesai.

Hopefully I tagged enough people to get some input 😉

IMO, this is useful, but I would postpone it to 3.x.

This API would be quite useful in the Micro Manager. But the names of the functions confused me a bit, wouldn't startProfiling("name") and stopProfiling() make more sense?

This will also work nicely with #1673

@IshaanDesai are you using this API? Would you support introducing this feature into preCICE?

@MakisH how do you see the value of such an API for analysing the performance of adapter code?

@MakisH how do you see the value of such an API for analysing the performance of adapter code?

On the one hand, I feel we risk getting into foreign territories by integrating such features into preCICE itself (profiling, logging, potentially more).

On the other hand, the nice aspect in both is not so much the "we already can do it, so why not", but the fact that the adapter and preCICE events/logs are in the same place and format, so they can be analyzed in context. Hence, it also fits the standardization context.

In the OpenFOAM adapter, we already implemented custom profiling for the reference paper, which would have been much easier if this feature existed already: precice/openfoam-adapter#256 Because the adapter now has profiling, there is no pressing need for the preCICE profiling at the moment.

Still, I guess this could be mildly interesting in case a user comes with their own code and claim that they have performance issues. We can already distinguish between the time in preCICE and outside preCICE, but we could then also point them to more specific directions to improve the runtime of their code. But I don't think this is our job at the moment, and profiling mainly makes sense for us in the context of evaluating and publishing our adapters.

I would see this as a "nice to have if it does not introduce any debt, but low priority".

On the other hand, the nice aspect in both is not so much the "we already can do it, so why not", but the fact that the adapter and preCICE events/logs are in the same place and format, so they can be analyzed in context. Hence, it also fits the standardization context.

The profiling and logging in the adapter always boils down to the question:

Does the solver already provide this functionality in an accessible way?

If the answer is no, then such an API is very useful.
If the answer is yes, then it is most natural for the end user to use the solver solution.
This makes standardization difficult though.

In the OpenFOAM adapter, we already implemented custom profiling for the reference paper, which would have been much easier if this feature existed already: precice/openfoam-adapter#256 Because the adapter now has profiling, there is no pressing need for the preCICE profiling at the moment.

The upside of the preCICE profiling is that it is robust to failures, works for parallel solvers even outside MPI environments, and comes with tooling.

Have you tried the OpenFOAM timers when running with mpi?

The profiling and logging in the adapter always boils down to the question:

Does the solver already provide this functionality in an accessible way?

If the answer is no, then such an API is very useful.

Yes, but provided that profiling itself is indeed useful (for more people than just us).

Have you tried the OpenFOAM timers when running with mpi?

These custom timers do not do anything special to account for discrepancies between ranks. We just measure the main rank.

are you using this API? Would you support introducing this feature into preCICE?

Currently not using this API, and right now I do not see an urgent use case. I am currently trying to profile functionality in the Micro Manager, and not functionality related to coupling. For multiscale scenarios, the coupling itself is one of the cheapest operations, and hence not the focus of profiling.