-
Notifications
You must be signed in to change notification settings - Fork 40
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
Rework make_filter interface to accept either size_px or radius and d… #1776
base: pre/2.8
Are you sure you want to change the base?
Conversation
41d0ba0
to
46b6f2e
Compare
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.
Thanks @yaugenst . Looks good overall, a few details.
The main thing to discuss is the fact that this breaks backwards compabibility with the size
-> size_px
change. What are your thoughts on that? is autograd
so experimental that we can do this safely?
kernel_size = get_kernel_size_px(radius=radius, dl=dl) | ||
return (kernel_size,) if np.isscalar(kernel_size) else tuple(kernel_size) | ||
else: | ||
raise ValueError("Either 'size_px' or both 'radius' and 'dl' must be provided.") |
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.
to remove any ambiguity, it might be best to just only handle specific cases?
if size_px is not None and (radius is None and dl is None):
return (size_px,) if np.isscalar(size_px) else tuple(size_px)
elif radius is not None and dl is not None and size_px is None:
kernel_size = get_kernel_size_px(radius=radius, dl=dl)
return (kernel_size,) if np.isscalar(kernel_size) else tuple(kernel_size)
else:
raise ValueError("Either 'size_px' or both 'radius' and 'dl' must be provided.")
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.
Ah, my thinking was that if a kernel size in pixels is given, then that would take precedence over radius and dl. Maybe it makes sense to do this and warn the user? Or just error?
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.
up to you. but just need to clearly define what happens if all 3 are provided perhaps. I might suggest error or at least warn? seems like untented use.
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.
It is clearly defined, no? If size_px
is given then that takes precedence over everything else. The reason being that if you supply an explicit size in pixels for the filter, then you probably do not want to calculate a different size from other arguments? Maybe it's enough to add this to the docstring?
I thought this was a relatively common pattern, see for example the period
argument in np.interp.
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.
ok that's fine with me. I tend to be a bit conservative about things like this (tend towards erroring), if only to make things simpler, but if it's ok for numpy then I'm fine with it.
46b6f2e
to
0923c79
Compare
Yeah this is pretty unfortunate, but |
c145880
to
99c0cab
Compare
Let's change target of this to pre/2.8? |
Oh yeah was just in the process of doing that :) |
99c0cab
to
744f377
Compare
…l arguments, import all user-facing functions into the plugins/autograd namespace, and add tests
744f377
to
0ab7d2c
Compare
ff9f499
to
898f4c2
Compare
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 pretty good.
I'm having trouble visualizing the API / if there are any changes? especially to invdes? does it break backwards compatibility?
I also think it would make some sense to define the default parameters, especially for beta, as constants somewhere so we can tweak them more easily.
Thanks @yaugenst-flex
@@ -17,6 +17,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
|
|||
### Changed | |||
|
|||
### Changed |
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.
duplicate changelog?
Also maybe add a line saying that all user-facing features can be imported now directly from tidy3d.plugins.autograd
?
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.
will need to update this submodule to latest state of develop
@@ -152,6 +152,8 @@ Next on our roadmap (targeting 2.8 and 2.9, summer 2024) is to support: | |||
- `PoleResidue` and other dispersive models. | |||
- custom (spatially-dependent) dispersive models, allowing topology optimization with metals. | |||
|
|||
- `ComplexPolySlab` |
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.
remove this change? also, wondering if you ever updated this readme to reflect the field data operations (put them in the "supported" section?) if not, maybe we can do that in this PR?
idea is to have this README contain the latest state of released, in progress, and todo.
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.
these changes exist already in develop from the interp PR? should we merge develop
into pre/2.8
maybe?
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.
Oh yeah I guess they do. Does it maybe make sense to keep working on pre/2.8
for the features and then cherry-pick things for patches to develop
? That would prevent the branches from diverging too much.
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.
I'm not sure, guess first are we committed to merging this into 2.8 or should we just get it into develop? no real preference here.
Then, I think we generally merge develop into the pre branches before release, so it will happen eventually.
|
||
|
||
class AbstractFilter(Tidy3dBaseModel, abc.ABC): | ||
"""A filter class for creating and applying convolution filters. |
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.
maybe just An abstract class
since filter
is mentioned later?
else: | ||
raise ValueError(f"Unsupported filter_type: {filter_type}") | ||
|
||
if size_px is not None: |
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.
I thought we had something that handles this for us? yea basically maybe all of this could be make_filter(...)
?
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.
The reason for this is that I thought that we might be getting rid of the functional interface, i.e. make_filter()
. If you think we should keep it then I will reuse it here.
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.
if it doesn't re implement the same code, I'm fine keeping it.
|
||
def _dilate(array: np.ndarray, beta: float): | ||
return filtproj(array, beta=beta, eta=eta_dilate) | ||
filtproj: FilterAndProject |
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.
use pd.Field instead of docstrings
------- | ||
Callable | ||
A function that computes the erosion/dilation penalty for a given array. | ||
filtproj : FilterAndProject |
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.
hm, this is an interesting approach.. but maybe we need a good default value for this based on the default penalty params?
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.
Ah you mean not having the parametrization here be a customizable thing but built into the penalty? We can do that, wasn't sure which way is best.
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.
yea or (similar comment above) we can make the parameters (beta, eta, etc.) be the pd.Fields here.
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.
with good defaults
eta: float = 0.5, | ||
delta_eta: float = 0.01, | ||
padding: PaddingType = "reflect", | ||
) -> "ErosionDilationPenalty": |
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.
use future annotations
dl: Union[float, Tuple[float, ...]] = None, | ||
*, | ||
size_px: Union[int, Tuple[int, ...]] = None, | ||
beta: float = 100.0, |
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.
in my recent experience, this is probably too high. I might recommend like 20.. not sure if this breaks backwards compatibility technically
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.
It would, because that default is used in a bunch of notebooks 😀 should we change it anyways?
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.
probably... but perhaps a goal before 2.8 should be to figure out very good defaults for these things.
It doesn't break backwards compatibility, no, only if we decide to get rid of the functional interface altogether. |
let's leave the functional interface but introduce these new classes and maybe change notebooks to use the classes? |
…l arguments, import all user-facing functions into the plugins/autograd namespace, and add tests
Closes #1775