Closed alxbilger closed 8 months ago
[ci-build][with-all-tests]
[ci-build][with-all-tests]
[ci-build][with-all-tests]
Another benchmark: examples/Demos/chainAll.scn
With parallelism
1000 iterations done in 41.8915 s ( 23.8712 FPS).
Without parallelism:
1000 iterations done in 91.9302 s ( 10.8778 FPS).
[ci-build][with-all-tests][force-full-build]
[ci-build][with-all-tests] (check for MacOS)
[ci-build][with-all-tests][force-full-build]
I don't understand why the dashboard says 2 scenes are failing. When I see the result, I see only one
CI sees apparently twice an error in advancedtimer .. strange
[ERROR] [AdvancedTimer::end] timer[Animate] does not correspond to last call to begin(cg_timer)
There is an error in the test because timer ids changed in this PR
[ci-depends-on] detected during build #13.
To unlock the merge button, you must
[ci-depends-on] detected during build #14.
To unlock the merge button, you must
The crash that happened on Windows also happens on the master branch on my computer. But I don't understand how it is not detected by the CI
The crash that happened on Windows also happens on the master branch on my computer. But I don't understand how it is not detected by the CI
Maybe it is random, it does not crash on mine (but I only tried like 2, 3 times) on msvc Nevertheless, I dont think this scene is working as intended anyway.... (the particules do not interact with the static mesh)
It seems strange that the factorization of the mapping propagation at the end of the time step makes the scene crashes.. Have you investigated it further @alxbilger ?
[ci-build][with-all-tests][force-full-build]
[ci-depends-on] detected during build #15.
To unlock the merge button, you must
[ci-build][with-all-tests][force-full-build]
Split all pipeline steps into smaller functions
Each step of the animation loop now corresponds to a function. For example, the following code:
is now in a function:
In the end, the pipeline is easier to read:
AnimateVisitor
AnimateVisitor
is no longer used. It was difficult to read its logic (the visitor called other visitors, it relies heavily on pruning which is easy to miss). Instead, I suggest to explicit all the steps from theAnimateVisitor
into theDefaultAnimationLoop
. This is closer to what is done in theFreeMotionAnimationLoop
. Plus, we can find common steps, which makes the code more consistent.Note also the introduction of
ComputeIsolatedForceVisitor
(see the comments in the code to understand its purpose).Multithreading
Since
AnimateVisitor
is no longer used,SolveVisitor
is used instead, providing optional multithreading, i.e. solving each ODE in parallel. Similar to what was done in theFreeMotionAnimationLoop
.Benchmark
Measured on
examples/Component/SolidMechanics/FEM/TetrahedronFEMForceField.scn
Without parallelism
With parallelism
The simulation is 2x faster. But there are 4 different objects, so we expected a speed-up of 4x. However, the speed-up is only about the
solve
function. Another time consuming function is theend event
when computing the von Misses stresses. Still, the solve function only shows a speedup of 2.68x, instead of 4x. I cannot explain it for now...[ci-depends-on https://github.com/sofa-framework/SofaPython3/pull/362]
By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).
Reviewers will merge this pull-request only if