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

Exposing tidy3d source bandwidth through gplugins #275

Open
pascualmunoz opened this issue Dec 12, 2023 · 8 comments
Open

Exposing tidy3d source bandwidth through gplugins #275

pascualmunoz opened this issue Dec 12, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@pascualmunoz
Copy link

pascualmunoz commented Dec 12, 2023

Feature request
tidy3d allows for a broadband Gaussian pulse source, set as described here:

https://docs.flexcompute.com/projects/tidy3d/en/latest/faq.html#what-source-bandwidth-should-i-use-for-my-simulation

and built as shown in their code:

https://github.com/flexcompute/tidy3d/blob/f60bf47f84264bc622e548fa41dfc344fb85ceaf/tidy3d/plugins/smatrix/smatrix.py#L231C4-L231C4

While gplugins/tidy3d write_sparameters have a 'bandwidth' parameter, it seems to me is only used to establish the frequency limits of S-parameter calculation, but the source time / frequency width is not set by gplugins.

Wanted solution
If I am not mistaken above, is it sensitive to expose the fwidth parameter through gplugins?

@pascualmunoz pascualmunoz added the enhancement New feature or request label Dec 12, 2023
@joamatab
Copy link
Contributor

@yaugenst
Copy link
Collaborator

yaugenst commented Dec 12, 2023

the plugin uses the tidy3d componentmodeler for sparameter calculation, which automatically sets the source bandwidth as per the code that you linked. if you need more flexibility, you can use the tidy3d component‘s get_simulation method directly, which gives you a plain tidy3d simulation object that you can modify as needed.
what exactly is the functionality that you are missing? do you need to set the source time differently than how it is done in the componentmodeler?

@pascualmunoz
Copy link
Author

pascualmunoz commented Dec 12, 2023

Thanks both for your kind replies.

@pascualmunoz
Copy link
Author

Hi Pascual,

i think we expose all tidy3d.Simulation args in the plugin

https://gdsfactory.github.io/gplugins/_autosummary/gplugins.tidy3d.write_sparameters.html#gplugins.tidy3d.write_sparameters

@yaugenst @tylerflex @heitzmann @momchil-flex

Hi Joaquín,

I've gone through the list of exposed parameters, I also had a look at the very detailed examples you give in:

https://gdsfactory.github.io/gplugins/notebooks/tidy3d_00_tidy3d.html?highlight=componentmodeler

I still wonder how one can specify a CW source to tidy3D through gplugins resorting to ContinuousWave function. Apparently that is possible in tidy3D but I can't find more documentation than:

https://docs.flexcompute.com/projects/tidy3d/en/v1.5.0/_autosummary/tidy3d.ModeSource.html?highlight=continuouswave

What do you think?

Best.

@momchil-flex
Copy link

To chime in, it's highly unlikely that you actually need a CW source, unless you're doing nonlinear photonics and really need to control the total power in the simulation (make sure it's at a single frequency). I think in tidy3d we only enabled ContinuousWave source only when we introduced nonlinear materials. Using a CW source also means that the in-built normalization will not work since the fields do not decay by the end of the simulation, and manual normalization will be needed.

Typically sources in FDTD can be pretty broadband, and the source bandwidth should have no noticeable effect on the results, as long as the entire spectrum of interest is covered by the source. If the fields decay by the end of the simulation, the frequency-domain fields recorded via the Fourier trasnfrom of the time-domain ones are actually mathematically equivalent to an actual frequency-domain solve (or a CW source with proper normalization).

@yaugenst
Copy link
Collaborator

Hi Pascual,

I think there is some confusion here. What the gplugins tidy3d plugin does is it provides a base class (called the Tidy3DComponent defined here) that knows how to assemble a tidy3d structure from a gdsfactory component and layerstack. This class also exposes two methods, get_simulation() (defined here) and get_component_modeler() (defined here), where the get_simulation() method assembles individual tidy3d simulations from a particular geometry and returns a regular tidy3d simulation object and get_component_modeler() assembles a regular tidy3d component modeler from such a simulation object. The sources and monitors are added by the component modeler automatically as defined by the ports. What our plugin does is essentially provide all the geometrical information about the layerstack, the component, and the ports to those two functions.
However, at each step of this process, you can pass arbitrary keyword arguments, which are passed directly to the corresponding tidy3d functions, so there is no loss of generality there.

The write_sparameters() function is just a convenience wrapper around those aforementioned methods, which gathers those steps into a single function with some optional plotting, caching, and sparameter extraction sprinkled in, but it's not really necessary. You can directly call the Tidy3DComponent's get_component_modeler() method to get a normal tidy3d component modeler, which works exactly as described in the tidy3d documentation here.

With the write_sparameters() function you indeed lose out on some flexibility, so if you need more control over your simulations, then I would advise to use the get_simulation() or get_component_modeler() methods directly.
Sorry that this is not very well documented, we are working on it!

@pascualmunoz
Copy link
Author

To chime in, it's highly unlikely that you actually need a CW source, unless you're doing nonlinear photonics and really need to control the total power in the simulation (make sure it's at a single frequency). I think in tidy3d we only enabled ContinuousWave source only when we introduced nonlinear materials. Using a CW source also means that the in-built normalization will not work since the fields do not decay by the end of the simulation, and manual normalization will be needed.

Typically sources in FDTD can be pretty broadband, and the source bandwidth should have no noticeable effect on the results, as long as the entire spectrum of interest is covered by the source. If the fields decay by the end of the simulation, the frequency-domain fields recorded via the Fourier trasnfrom of the time-domain ones are actually mathematically equivalent to an actual frequency-domain solve (or a CW source with proper normalization).

Thanks for the advice.

@pascualmunoz
Copy link
Author

Hi Pascual,

I think there is some confusion here. What the gplugins tidy3d plugin does is it provides a base class (called the Tidy3DComponent defined here) that knows how to assemble a tidy3d structure from a gdsfactory component and layerstack. This class also exposes two methods, get_simulation() (defined here) and get_component_modeler() (defined here), where the get_simulation() method assembles individual tidy3d simulations from a particular geometry and returns a regular tidy3d simulation object and get_component_modeler() assembles a regular tidy3d component modeler from such a simulation object. The sources and monitors are added by the component modeler automatically as defined by the ports. What our plugin does is essentially provide all the geometrical information about the layerstack, the component, and the ports to those two functions. However, at each step of this process, you can pass arbitrary keyword arguments, which are passed directly to the corresponding tidy3d functions, so there is no loss of generality there.

The write_sparameters() function is just a convenience wrapper around those aforementioned methods, which gathers those steps into a single function with some optional plotting, caching, and sparameter extraction sprinkled in, but it's not really necessary. You can directly call the Tidy3DComponent's get_component_modeler() method to get a normal tidy3d component modeler, which works exactly as described in the tidy3d documentation here.

With the write_sparameters() function you indeed lose out on some flexibility, so if you need more control over your simulations, then I would advise to use the get_simulation() or get_component_modeler() methods directly. Sorry that this is not very well documented, we are working on it!

Many tnanks for the detailed overview, that certainly helps much!

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

No branches or pull requests

4 participants