-
Notifications
You must be signed in to change notification settings - Fork 0
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
Place segments over partitions of the background to limit memory footprint #1
Comments
I have attempted this last week and ran into great trouble with the bookkeeping that is required. It may require rethinking the architecture of the program, such that the background is always passed around with its padding and slicing information. The operations on the background—or rather, the associated metadata—can be implemented in an encapsulated manner. This will limit the amount of index-fiddling that is required throughout the program. For now, I am going to hold off on touching this, despite the memory issues. Here, I will document any thoughts I have about this matter in the meantime. |
Today, I tried this again based on our discussions from last week. Quite pleased with the progress I'm making now :) Placement probability density functionTo make sure that the densities do not become too high during the initial ('white') pass, valid placements are accepted according to a sigmoid function. A placement in the first half of a domain is always accepted, but a placement in the second half is subject to the function like the one I will describe here. The function I currently use can be found here: https://www.desmos.com/calculator/cdyqdxvjmy. Expressed in Python, I use the following function: def trail_off(v: float) -> float:
"""
Takes a value `v` in the range `0.0 <= v <= 1.0` and returns a probability
according to a sigmoid density distribution, such that this probability
is 1.0 for `v == 0.0` and goes to 0.0 as `v` approaches 1.0.
"""
return 1 - 1 / (1 + np.exp(-12 * (v - 0.5))) Over a range from -1.0 to 2.0, this produces the following curve. Let me know if you have any thoughts on whether this fits the use case. I intend to expand on the reasoning here in a more thorough manner, as this does require some more proof that it is sufficient. |
Working with and convolving over the complete occupation map (background) is feasible for many system sizes.
However, for larger systems (approaching (~350 nm)3) the memory footprint becomes a limiting factor.
In order to still pack such systems, it may become necessary to apply the placement procedure over smaller sections of the occupation map.
Of course, these system sizes imply access to computational resources that allow one to just throw more memory at the problem. But, despite the additional bookkeeping overhead this strategy may require, some improvements in runtime are not out of the question.
The text was updated successfully, but these errors were encountered: