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

Issues in StructuredMaterial2D::get_value #16

Closed
dasu186 opened this issue May 11, 2020 · 1 comment
Closed

Issues in StructuredMaterial2D::get_value #16

dasu186 opened this issue May 11, 2020 · 1 comment

Comments

@dasu186
Copy link

dasu186 commented May 11, 2020

First of all, great work! Saw your talk at PW2020.

After importing a few layouts and seeing strange results, I became curious about the way the averaging is done when trying to get an average epsilon value. I think I understand the function correctly, but I also don't think it's doing what it's meant to be doing.

First of all, cell.get_area_ratio() will always either return 1, or 0, because it's defined from a rectangular grid.

if(cell.get_area_ratio() == 0) { break; } shouldn't be in the loop, but really should be a condition to go in the loop. It's not going to change between primitives. Of course that's very minor.

if(contains_p1 && contains_p2 &&
		   contains_p3 && contains_p4 &&
		   cell.get_area_ratio() == 1.0) {
				return prim->get_material(xd,yd);
		}

doesn't work if it's from a subsequent layer. Say you define a structure on top of a cladding. The first structure will give an overlap of say < 1 and correctly increments val and keeps on lopping, but on the second pass it will be overwritten by that return from the cladding. In the end, all the polygons must be kept so that a difference can be computed between them.

if(cell.get_area_ratio() > 0) { val += cell.get_area_ratio()*1.0; } will always increment val by 1 if gets through the condition. But is it really what it should do? It should really be the overlap that is "left" that contributes to val.

My final thought is that there should be a more efficient way for get_values than going grid point by grid point if you already have all the polygons in hand.

@dasu186
Copy link
Author

dasu186 commented May 12, 2020

Nevermind. It wasn't obvious at first that cell shrinks at each iteration and remains the difference. I hadn't looked enough at the GridCell class.

@dasu186 dasu186 closed this as completed May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant