Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional data in precice-profiling #2123

Open
davidscn opened this issue Oct 30, 2024 · 4 comments · May be fixed by #2127
Open

Additional data in precice-profiling #2123

davidscn opened this issue Oct 30, 2024 · 4 comments · May be fixed by #2127
Assignees
Labels
question Everybody is invited to answer this question or give any hint. usability This issue will make preCICE easier for non-expert users
Milestone

Comments

@davidscn
Copy link
Member

Please describe the problem you are trying to solve.

Our events have the option to commit data, which is not a duration value.

void addData(std::string_view key, int value);

However, accessing the generated data through our CLI is not really possible. There is apparently some opportunity so export the data to a csv data frame, but this option is not even documented somewhere.

The event data is useful if you want to connect an event duration to a certain data value, e.g., the size of your rank-local meshes certainly affects the time the mapping requires on this rank. We use this, e.g., in the RBF Solver to track the number of iterations:

eRescaling.addData("Iterations", _solver.getIterationNumber());

Describe the solution you propose.

We should provide access to this data through the CLI we currently have. I am not sure how this data was treated in previous preCICE versions (or previous versions of our event tool).

We could consider to print something like an EventData table

precice-profiling analyze Fluid --show-data

or simply always give an additional table with the data.

Describe alternatives you've considered

An alternative could be to integrate the table into our 'usual' event timings. The key would then be eventName key and instead of a duration, the table then contains the data value. However, this becomes problematic if we change units in this table.

Overall, I think having the data more accessible would greatly enhance their application.

@davidscn davidscn added question Everybody is invited to answer this question or give any hint. usability This issue will make preCICE easier for non-expert users labels Oct 30, 2024
@uekerman
Copy link
Member

I agree that it would be good to add some post-processing for such data.
Could you give example data on how such an EventData table could look like?

@fsimonis fsimonis added this to the Version 3.2.0 milestone Nov 6, 2024
@fsimonis fsimonis self-assigned this Nov 11, 2024
@fsimonis fsimonis linked a pull request Nov 11, 2024 that will close this issue
7 tasks
@fsimonis
Copy link
Member

fsimonis commented Nov 25, 2024

I am struggling a bit with how to present this output in a human-readable format.
Displaying all of it as a big table would be total overkill.

Maybe a "report" format is more readable. For serial participants this could look like this:

Connections
Fluid: min: 1, avg: 1, max: 1
Solid: min: 1, avg: 1, max: 1

For parallel participants displaying every rank will be unreadable. We could handle primary and secondaries separately, and annotate on which rank the min and max are present:

Connections
Fluid:
  Primary: min: 3, avg: 3, max: 3
  Secondaries: min: 2 (r1), avg: 2, max: 4 (r2)
Solid:
  Primary: min: 3, avg: 3, max: 3
  Secondaries: min: 2 (r1), avg: 2, max: 4 (r2)

@uekerman
Copy link
Member

My gut feeling is that the presentation depends on the type of data. What data do we currently have? Anything else besides connections and number of iterations?

@fsimonis
Copy link
Member

What data do we currently have?

p2p communication connections
pou mapping n clusters
petsc mapping rescaling iterations
petsc mapping solve iterations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Everybody is invited to answer this question or give any hint. usability This issue will make preCICE easier for non-expert users
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants