Skip to content

Commit e73103f

Browse files
tomflexcomputetomflexcompute
authored
Merge pull request #26 from flexcompute/tom/faq_update
Change titles to all lower case for consistency
2 parents 802f861 + 7e24a37 commit e73103f

13 files changed

+230
-230
lines changed

‎_faqs/Can-you-convert-a-lumerical-script-file-to-Tidy3D.md renamed to ‎_faqs/can-you-convert-a-lumerical-script-file-to-tidy3d.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
1-
---
2-
title: Can you convert a lumerical script file to Tidy3D?
3-
date: 2023-10-24 19:16:52
4-
enabled: true
5-
category: "Simulations"
6-
---
7-
8-
[This repo](https://github.com/hirako22/Lumerical-to-Tidy3D-Converter) offers a limited ability to convert `.lsf` project files to Tidy3D skeleton files in Python. Not every command in the `lsf` file is covered. The `lsf` project files often have default values/conventions that are not specified, so the created Tidy3D script will often need additional specification. Always be sure to check over the created Tidy3D script to see if any values are missing or if any objects have not been parsed.
9-
1+
---
2+
title: Can you convert a lumerical script file to Tidy3D?
3+
date: 2023-10-24 19:16:52
4+
enabled: true
5+
category: "Simulations"
6+
---
7+
8+
[This repo](https://github.com/hirako22/Lumerical-to-Tidy3D-Converter) offers a limited ability to convert `.lsf` project files to Tidy3D skeleton files in Python. Not every command in the `lsf` file is covered. The `lsf` project files often have default values/conventions that are not specified, so the created Tidy3D script will often need additional specification. Always be sure to check over the created Tidy3D script to see if any values are missing or if any objects have not been parsed.
9+

‎_faqs/How-are-results-normalized.md renamed to ‎_faqs/how-are-results-normalized.md

Lines changed: 64 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -1,64 +1,64 @@
1-
---
2-
_schema: default
3-
title: How are results normalized?
4-
date: 2023-10-24 15:21:50
5-
enabled: true
6-
category: Sources
7-
_inputs:
8-
title:
9-
type: text
10-
label: QUESTION TITLE
11-
enabled:
12-
type: switch
13-
hidden: true
14-
date:
15-
type: datetime
16-
label: DATE
17-
instance_value: NOW
18-
category:
19-
type: select
20-
options:
21-
values: data.faq_categories
22-
value_key: key
23-
preview:
24-
text:
25-
- key: category_name
26-
---
27-
In many cases, Tidy3D simulations can be run, and well-normalized results can be obtained without normalizing/empty runs. This is because care is taken internally to normalize the injected power, as well as the output
28-
results, in a meaningful way. To understand this, there are two separate normalizations that happen, outlined below. Both are discussed with respect to frequency-domain results, as those are the most commonly used.
29-
30-
## Source spectrum normalization
31-
32-
Every source has a spectrum associated to its particular time dependence that is imprinted on the fields injected in the simulation. Usually, this is somewhat arbitrary, and it is most convenient to take it out of the frequency-domain results. By default, after a run, Tidy3D normalizes all frequency-domain results by the spectrum of the first
33-
source in the list of sources in the simulation. This choice can be modified using the `Simulation.normalize_index`{: .interpreted-text role="py:obj"} attribute, or normalization can be turned off by setting that to `None`. Results can even be renormalized after the simulation run using [SimulationData.renormalize()](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.SimulationData.html#tidy3d.SimulationData.renormalize){: .color-primary-hover}. If multiple sources are used, but they all have the same time dependence, the default normalization is still meaningful. However, if different sources have a different time dependence, then it may not be
34-
possible to obtain well-normalized results without a normalizing run.
35-
36-
This type of normalization is applied directly to the frequency-domain results. The custom pulse amplitude and phase defined in `SourceTime.amplitude`{: .interpreted-text role="py:obj"} and `SourceTime.phase`{: .interpreted-text role="py:obj"}, respectively, are **not** normalized out. This gives the user control over a (complex) prefactor that can be applied to scale any source. Additionally, the power injected by each type of source may have some special normalization, as outlined below.
37-
38-
## Source power normalization
39-
40-
Source power normalization is applied depending on the source type. In the cases where normalization is applied, the actual injected power may differ slightly from what is described below due to finite grid effects. The normalization should become exact with sufficiently high resolution. That said, in most cases the error is negligible even at default resolution.
41-
42-
The injected power values described below assume that the source spectrum normalization has also been applied.
43-
44-
- [PointDipole](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PointDipole.html#tidy3d.PointDipole){: .color-primary-hover}: The point dipole source represents an infinitesimal antenna with a fixed current density. The normalization is such that the power injected by the source in a homogeneous material of refractive index $n$ at frequency $\omega = 2\pi f$ is approximately given as follows
45-
46-
* $\frac{\omega^2}{12\pi}\frac{\mu_0 n}{c}$, 3D simulation, electric current
47-
* $\frac{\omega^2}{12\pi}\frac{\epsilon_0 n^3}{c}$, 3D simulation, magnetic current
48-
* $\frac{\omega \mu_0}{16}$, 2D TE simulation, electric current
49-
* $\frac{\omega \mu_0}{8}$, 2D TM simulation, electric current
50-
* $\frac{\omega \epsilon_0 n^2}{8}$, 2D TE simulation, magnetic current
51-
* $\frac{\omega \epsilon_0 n^2}{16}$, 2D TM simulation, magnetic current
52-
53-
There can be a small difference in the true power compared to the analytical values above due to the finite grid. Note that the current source definition used in Tidy3D is different from the definition of an electric dipole composed of two separated, oscillating electric charges, which is also common. The power normalization differs by a factor of $\omega^2$ for electric dipoles, and $\mu_0^2 \omega^2$ for magnetic dipoles.
54-
55-
- [UniformCurrentSource](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.UniformCurrentSource.html#tidy3d.UniformCurrentSource){: .color-primary-hover}: No extra normalization applied.
56-
57-
- [CustomFieldSource](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.CustomFieldSource.html#tidy3d.CustomFieldSource){: .color-primary-hover}: No extra normalization applied.
58-
59-
- [ModeSource](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.ModeSource.html#tidy3d.ModeSource){: .color-primary-hover},
60-
[PlaneWave](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PlaneWave.html#tidy3d.PlaneWave){: .color-primary-hover},
61-
[GaussianBeam](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.GaussianBeam.html#tidy3d.GaussianBeam){: .color-primary-hover},
62-
[AstigmaticGaussianBeam](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.AstigmaticGaussianBeam.html#tidy3d.AstigmaticGaussianBeam){: .color-primary-hover}: Normalized to inject 1W power at every frequency. If supplied `SourceTime.num_freqs`{: .interpreted-text role="py:obj"} is `1`, this normalization is only exact at the central frequency of the associated [SourceTime](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.components.source.SourceTime.html#tidy3d.components.source.SourceTime){: .color-primary-hover} pulse but should still be very close to 1W at nearby frequencies too. Increasing `num_freqs` can be used to make sure the normalization works well for a broadband source. The correct usage for a [PlaneWave](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PlaneWave.html#tidy3d.PlaneWave){: .color-primary-hover} source is to span the whole simulation domain for a simulation with periodic (or Bloch) boundaries, in which case the normalization of this technically infinite source is equivalent to 1W per unit cell. For the other sources which have a finite extent, the normalization is correct provided that the source profile decays by the boundaries of the source plane. Verifying that this is the case is always advised, as otherwise results may be spurious beyond just the normalization (numerical artifacts will be present at the source boundary).
63-
64-
- `TFSFSource`{: .interpreted-text role="class"}: Normalized to inject $1W/μm^{2}$ in the direction of the source injection axis. This is convenient for computing scattering and absorption cross-sections without the need for additional normalization. Note that for angled incidence, a factor of $1/\cos(\theta)$ needs to be applied to convert to the power carried by the plane wave in the propagation direction, which is at an angle $\theta$ with respect to the injection axis. Note also that when the source spans the entire simulation domain with periodic or Bloch boundaries, the conversion between the normalization of a `TFSFSource`{: .interpreted-text role="class"} and a [PlaneWave](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PlaneWave.html#tidy3d.PlaneWave){: .color-primary-hover} is just the area of the simulation domain in the plane normal to the injection axis.
1+
---
2+
_schema: default
3+
title: How are results normalized?
4+
date: 2023-10-24 15:21:50
5+
enabled: true
6+
category: Sources
7+
_inputs:
8+
title:
9+
type: text
10+
label: QUESTION TITLE
11+
enabled:
12+
type: switch
13+
hidden: true
14+
date:
15+
type: datetime
16+
label: DATE
17+
instance_value: NOW
18+
category:
19+
type: select
20+
options:
21+
values: data.faq_categories
22+
value_key: key
23+
preview:
24+
text:
25+
- key: category_name
26+
---
27+
In many cases, Tidy3D simulations can be run, and well-normalized results can be obtained without normalizing/empty runs. This is because care is taken internally to normalize the injected power, as well as the output
28+
results, in a meaningful way. To understand this, there are two separate normalizations that happen, outlined below. Both are discussed with respect to frequency-domain results, as those are the most commonly used.
29+
30+
## Source spectrum normalization
31+
32+
Every source has a spectrum associated to its particular time dependence that is imprinted on the fields injected in the simulation. Usually, this is somewhat arbitrary, and it is most convenient to take it out of the frequency-domain results. By default, after a run, Tidy3D normalizes all frequency-domain results by the spectrum of the first
33+
source in the list of sources in the simulation. This choice can be modified using the `Simulation.normalize_index`{: .interpreted-text role="py:obj"} attribute, or normalization can be turned off by setting that to `None`. Results can even be renormalized after the simulation run using [SimulationData.renormalize()](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.SimulationData.html#tidy3d.SimulationData.renormalize){: .color-primary-hover}. If multiple sources are used, but they all have the same time dependence, the default normalization is still meaningful. However, if different sources have a different time dependence, then it may not be
34+
possible to obtain well-normalized results without a normalizing run.
35+
36+
This type of normalization is applied directly to the frequency-domain results. The custom pulse amplitude and phase defined in `SourceTime.amplitude`{: .interpreted-text role="py:obj"} and `SourceTime.phase`{: .interpreted-text role="py:obj"}, respectively, are **not** normalized out. This gives the user control over a (complex) prefactor that can be applied to scale any source. Additionally, the power injected by each type of source may have some special normalization, as outlined below.
37+
38+
## Source power normalization
39+
40+
Source power normalization is applied depending on the source type. In the cases where normalization is applied, the actual injected power may differ slightly from what is described below due to finite grid effects. The normalization should become exact with sufficiently high resolution. That said, in most cases the error is negligible even at default resolution.
41+
42+
The injected power values described below assume that the source spectrum normalization has also been applied.
43+
44+
- [PointDipole](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PointDipole.html#tidy3d.PointDipole){: .color-primary-hover}: The point dipole source represents an infinitesimal antenna with a fixed current density. The normalization is such that the power injected by the source in a homogeneous material of refractive index $n$ at frequency $\omega = 2\pi f$ is approximately given as follows
45+
46+
* $\frac{\omega^2}{12\pi}\frac{\mu_0 n}{c}$, 3D simulation, electric current
47+
* $\frac{\omega^2}{12\pi}\frac{\epsilon_0 n^3}{c}$, 3D simulation, magnetic current
48+
* $\frac{\omega \mu_0}{16}$, 2D TE simulation, electric current
49+
* $\frac{\omega \mu_0}{8}$, 2D TM simulation, electric current
50+
* $\frac{\omega \epsilon_0 n^2}{8}$, 2D TE simulation, magnetic current
51+
* $\frac{\omega \epsilon_0 n^2}{16}$, 2D TM simulation, magnetic current
52+
53+
There can be a small difference in the true power compared to the analytical values above due to the finite grid. Note that the current source definition used in Tidy3D is different from the definition of an electric dipole composed of two separated, oscillating electric charges, which is also common. The power normalization differs by a factor of $\omega^2$ for electric dipoles, and $\mu_0^2 \omega^2$ for magnetic dipoles.
54+
55+
- [UniformCurrentSource](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.UniformCurrentSource.html#tidy3d.UniformCurrentSource){: .color-primary-hover}: No extra normalization applied.
56+
57+
- [CustomFieldSource](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.CustomFieldSource.html#tidy3d.CustomFieldSource){: .color-primary-hover}: No extra normalization applied.
58+
59+
- [ModeSource](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.ModeSource.html#tidy3d.ModeSource){: .color-primary-hover},
60+
[PlaneWave](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PlaneWave.html#tidy3d.PlaneWave){: .color-primary-hover},
61+
[GaussianBeam](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.GaussianBeam.html#tidy3d.GaussianBeam){: .color-primary-hover},
62+
[AstigmaticGaussianBeam](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.AstigmaticGaussianBeam.html#tidy3d.AstigmaticGaussianBeam){: .color-primary-hover}: Normalized to inject 1W power at every frequency. If supplied `SourceTime.num_freqs`{: .interpreted-text role="py:obj"} is `1`, this normalization is only exact at the central frequency of the associated [SourceTime](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.components.source.SourceTime.html#tidy3d.components.source.SourceTime){: .color-primary-hover} pulse but should still be very close to 1W at nearby frequencies too. Increasing `num_freqs` can be used to make sure the normalization works well for a broadband source. The correct usage for a [PlaneWave](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PlaneWave.html#tidy3d.PlaneWave){: .color-primary-hover} source is to span the whole simulation domain for a simulation with periodic (or Bloch) boundaries, in which case the normalization of this technically infinite source is equivalent to 1W per unit cell. For the other sources which have a finite extent, the normalization is correct provided that the source profile decays by the boundaries of the source plane. Verifying that this is the case is always advised, as otherwise results may be spurious beyond just the normalization (numerical artifacts will be present at the source boundary).
63+
64+
- `TFSFSource`{: .interpreted-text role="class"}: Normalized to inject $1W/μm^{2}$ in the direction of the source injection axis. This is convenient for computing scattering and absorption cross-sections without the need for additional normalization. Note that for angled incidence, a factor of $1/\cos(\theta)$ needs to be applied to convert to the power carried by the plane wave in the propagation direction, which is at an angle $\theta$ with respect to the injection axis. Note also that when the source spans the entire simulation domain with periodic or Bloch boundaries, the conversion between the normalization of a `TFSFSource`{: .interpreted-text role="class"} and a [PlaneWave](https://docs.flexcompute.com/projects/tidy3d/en/latest/api/_autosummary/tidy3d.PlaneWave.html#tidy3d.PlaneWave){: .color-primary-hover} is just the area of the simulation domain in the plane normal to the injection axis.

0 commit comments

Comments
 (0)