Performance: Why do large equilibrium splines slow down the code?
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- julia
- Domain
- performance
Research direction
Start by reading the spline evaluation calls made during ForceFreeStates ODE integration, especially how knot hints are used as mpsi grows. Compare performance across equilibrium sizes to identify what causes the slowdown. Done means explaining the scaling and showing whether an optimization makes runtime less sensitive to knot count.
Written by the indexing model from the issue text.
Description
Empirically, we all know larger mpsi slows down the ForceFreeStates.
The hand waving reason is the 10s of thousands of spline interpolations done during the ODE integration are a bit slower. But why would this be the case when we are using hints to cleanly provide the knot locations of interest and these are only slowly (and monotonically) incrementing? It seems like there would be effectively no search difference with knot number in this case. Is there some further optimization of the spline evaluation calls that would make this loop insensitive to the spline knot length? It seems like there should be.
@mgyoo86 might have some insights.
Possible topic for David Smitth ( @drsmith48 ) and UW hackathon
- Dominant language
- Julia
- Stars
- 11
- Forks
- 7
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 68
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenFUSIONToolkit/GPEC
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
OpenFUSIONToolkit/GPEC#644 ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
OpenFUSIONToolkit/GPEC#643 ·
Maintainers usually reply within 3 days
-
PerturbedEquilibrium - FEATURE - Complete the resistive perturbed-equilibrium workflow from Galerkin and matched resultsPossibly taken @matt-pharr claimed this 1 day ago. Openfeature
OpenFUSIONToolkit/GPEC#635 · 1 comment · 1 assignee ·
Maintainers usually reply within 3 days
-
test
Difficulty 4/5 3-5 days Newbie friendliness 25/100
OpenFUSIONToolkit/GPEC#633 · 2 comments ·
Maintainers usually reply within 3 days
-
Tearing - FEATURE - Add a general modified Rutherford equation for island evolutionPossibly taken @StuartBenjamin claimed this 1 day ago. Openfeature
OpenFUSIONToolkit/GPEC#630 · 1 assignee ·
Maintainers usually reply within 3 days
All issues in OpenFUSIONToolkit/GPEC
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Sienna-Platform/InfrastructureSystems.jl#675 ·
Maintainers usually reply within 2 days
-
TargetEncoder reuses the first level's shrinkage factor for all levels when m > 0Possibly taken @parth-patel010 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
JuliaAI/MLJTransforms.jl#95 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
SciML/RecursiveArrayTools.jl#687 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
SciML/Corleone.jl#179 ·
Maintainers usually reply within 1 day
-
Setup Aqua.jlOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
JuliaUQ/UncertaintyQuantification.jl#363 ·
Maintainers usually reply within 1 day