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

Rework make_filter interface to accept either size_px or radius and d… #1776

Open
wants to merge 7 commits into
base: pre/2.8
Choose a base branch
from

Conversation

yaugenst-flex
Copy link
Contributor

…l arguments, import all user-facing functions into the plugins/autograd namespace, and add tests

Closes #1775

Copy link
Collaborator

@tylerflex tylerflex left a 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.")
Copy link
Collaborator

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.")

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

tidy3d/plugins/autograd/invdes/filters.py Outdated Show resolved Hide resolved
tidy3d/plugins/autograd/utilities.py Show resolved Hide resolved
tidy3d/plugins/autograd/utilities.py Show resolved Hide resolved
tidy3d/plugins/autograd/__init__.py Outdated Show resolved Hide resolved
CHANGELOG.md Show resolved Hide resolved
@yaugenst-flex yaugenst-flex force-pushed the yaugenst-flex/autograd-utilities branch from 46b6f2e to 0923c79 Compare June 19, 2024 15:09
@yaugenst-flex
Copy link
Contributor Author

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?

Yeah this is pretty unfortunate, but size is I think too ambiguous... I think (I hope) it's fine? I'm sure there will be other breaking changes too...

@yaugenst-flex yaugenst-flex force-pushed the yaugenst-flex/autograd-utilities branch from c145880 to 99c0cab Compare June 28, 2024 14:33
@tylerflex
Copy link
Collaborator

Let's change target of this to pre/2.8?

@yaugenst-flex yaugenst-flex changed the base branch from develop to pre/2.8 June 28, 2024 14:39
@yaugenst-flex
Copy link
Contributor Author

Oh yeah was just in the process of doing that :)

@yaugenst-flex yaugenst-flex force-pushed the yaugenst-flex/autograd-utilities branch from 99c0cab to 744f377 Compare July 1, 2024 10:29
@yaugenst-flex yaugenst-flex self-assigned this Jul 2, 2024
@yaugenst-flex yaugenst-flex force-pushed the yaugenst-flex/autograd-utilities branch from 744f377 to 0ab7d2c Compare July 8, 2024 14:21
@yaugenst-flex yaugenst-flex force-pushed the yaugenst-flex/autograd-utilities branch from ff9f499 to 898f4c2 Compare July 9, 2024 16:57
Copy link
Collaborator

@tylerflex tylerflex left a 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
Copy link
Collaborator

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?

Copy link
Collaborator

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`
Copy link
Collaborator

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.

Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.
Copy link
Collaborator

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:
Copy link
Collaborator

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(...)?

Copy link
Contributor Author

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.

Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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":
Copy link
Collaborator

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,
Copy link
Collaborator

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

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

@yaugenst-flex
Copy link
Contributor Author

I'm having trouble visualizing the API / if there are any changes? especially to invdes? does it break backwards compatibility?

It doesn't break backwards compatibility, no, only if we decide to get rid of the functional interface altogether.

@tylerflex
Copy link
Collaborator

let's leave the functional interface but introduce these new classes and maybe change notebooks to use the classes?

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

Successfully merging this pull request may close these issues.

autograd utilities suggestions
2 participants