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

Place segments over partitions of the background to limit memory footprint #1

Open
ma3ke opened this issue Mar 8, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@ma3ke
Copy link
Collaborator

ma3ke commented Mar 8, 2024

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.

@ma3ke ma3ke added the enhancement New feature or request label Mar 8, 2024
@ma3ke
Copy link
Collaborator Author

ma3ke commented Mar 12, 2024

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.

ma3ke added a commit that referenced this issue Apr 2, 2024
@ma3ke
Copy link
Collaborator Author

ma3ke commented Apr 2, 2024

Today, I tried this again based on our discussions from last week. Quite pleased with the progress I'm making now :)

Placement probability density function

To 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.

sigmoid_2024-04-02

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.

@ma3ke ma3ke mentioned this issue Apr 2, 2024
4 tasks
@ma3ke ma3ke linked a pull request Apr 2, 2024 that will close this issue
4 tasks
ma3ke added a commit that referenced this issue Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant