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

Add dolfin timers #151

Merged
merged 3 commits into from
Dec 18, 2023
Merged

Add dolfin timers #151

merged 3 commits into from
Dec 18, 2023

Conversation

finsberg
Copy link
Collaborator

@finsberg finsberg commented Nov 9, 2023

As part of running convergence test we need ways to measure the time it takes for different methods.

Here I add dolfin timers to a few of the methods in the solver and model class. When running a program you can now add

import dolfin as d 

d.list_timings(
    d.TimingClear.keep,
    [
        d.TimingType.wall,
    ],
)

at the end, at it will list the time spent in the different methods. We can also save the results to a file using

res = d.timings(
    d.TimingClear.keep,
    [d.TimingType.wall, d.TimingType.user, d.TimingType.system],
)

from pathlib import Path

Path("timings.txt").write_text(res.str(True))

One question is whether we need the stopwatch class. Thoughts?

Copy link
Collaborator

@emmetfrancis emmetfrancis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. Are there advantages to using the dolfin timer that we don't have from the previously defined stopwatch class? If so, I am on board with changing the other stopwatches to dolfin timers wherever we might want to keep them.

@finsberg
Copy link
Collaborator Author

This looks good to me. Are there advantages to using the dolfin timer that we don't have from the previously defined stopwatch class? If so, I am on board with changing the other stopwatches to dolfin timers wherever we might want to keep them.

I think that if we can achieve the same with the dolfin timers then we should use that. The stopwatches in smart are really nice but in my opinion it might make more sense to move them out to a separate package since they don't really belong in smart. Also having our own implementation of stopwatches also means that there is one more thing we need to make sure is working as expected.

Copy link
Collaborator

@jorgensd jorgensd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@finsberg finsberg merged commit 32de3da into development Dec 18, 2023
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants