-
Notifications
You must be signed in to change notification settings - Fork 113
FFM Surface Area calculation rewrite #242
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
Conversation
|
Hi Kuba! Awesome contribution, excited to check this out tomorrow! Planning to release 0.6.1 soon, and it would be great to have this in it. One question for my understanding, does the speedup come from not storing the contours in an array, or is it from finding the contours in cython? |
|
Hi Andrew! The speed up is mostly from not storing contours in an array. Scikitimage was already using cython internally for its contours function so we had to use cython to match its performance. |
|
Got it up and running without any trouble, thanks for updating the readme! I tried a couple of sims, and it is indeed quite fast. I did notice the results were a bit more different than expected, though. This first one (aft finocyl) was fairly close, but a bit more different than expected: |
|
Oh, nice! No need to apologize. I'll mess around with it a bit more tomorrow. Want to make sure it works well across multiple platforms, and when bundled into an executable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work!! Just a few things to clean up, and one thought. Basically, one of the things I've tried to maintain in openMotor is that where possible, the graphics shown to the user should be the exact data that the simulation calculations are being run on. That is, if you see something weird in the simulation results, it should also show up in the grain tab of the results widget, and the contour view on the grain preview widget. We now have two functions for finding contours, one that is used for simulations and one that is used for the UI. Though I think your implementation is so close to the previous contour finding function that it doesn't really matter, I'd prefer that we switch entirely to the new one so everything is consistent. Maybe it should take an argument that determines if it returns the contours or not?
Again, super excited about this contribution, thanks!
|
Hey! |
|
Working on the version with contours right now! The change in curves is from the way the code culls contours near the edge of the motor. I moved the tolerance behavior of the geometry.length function into these lines of code The code now checks the center point of a marching square and just removes that line segment instead of deleting a point from the final contour. I'll see if there is anything I can do to make it closer to the original, but it seems like it would require a decently sized rewrite to produce the exact same results |
|
Ok, the entire codebase should be using the new function now. I'll look into matching old behavior exactly, but I don't know if there is anything we could do without slowing the code down. |
|
Will take a final pass this week! |
reilleya
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fantastic, thanks for bearing with me! Before merging, please clean up a couple of newline issues (minor nitpicks) and then squash all of your commits down to a single one with a nice title/description.
This is going to make a lot of people happy, thank you for doing it!
scikit-image's "find_contours" function has been replaced with "_find_perimeter" which will can return a grains core perimeter directly, speeding up simulation time in FMM grains.
|
No worries Andrew! Thanks for helping with my messy formatting. Everything should be implemented, rebased, and squashed :) |
scikit-image's "find_contours" function has been replaced with "_find_perimeter" which will can return a grains core perimeter directly, speeding up simulation time in FMM grains.






Hey there!
My university team has been working with Finocyl grains and recently found a way to speed up FFM Sims.
A large part of the FFM grain simulation run time is spent getting contours from the SciKit image library.
The current implementation uses an open source Cython function to retrieve an array of line segments.
The array is never actually used for anything, open motors code just retrieves the sum length of all lines within the motor.
To work around this, we developed a Cython function titled “get_perimeter()"
The function sums the length of all the lines as it finds them, and never stores them into an array.
We ran some tests using profilers, and a fully Finocyl motor ran 6x faster during simulation.
There is a slight change in how lines on the edge of the motor are trimmed, resulting in a ~0.1% difference in pressure in our test simulations.
Please let me know if any changes need to be made!