From 0b460cdd24f28b5c9576e9fc2d3854056c4545c5 Mon Sep 17 00:00:00 2001 From: Ardavan Oskooi Date: Tue, 30 Mar 2021 18:07:12 -0700 Subject: [PATCH] tweaks and minor fixes to docs (#1540) --- doc/docs/Acknowledgements.md | 2 +- doc/docs/Build_From_Source.md | 2 +- doc/docs/FAQ.md | 6 +----- doc/docs/Parallel_Meep.md | 4 ++-- doc/docs/Perfectly_Matched_Layer.md | 5 +++++ doc/docs/Python_Tutorials/AdjointSolver.md | 21 --------------------- doc/docs/Subpixel_Smoothing.md | 4 ++-- doc/docs/index.md | 2 +- python/geom.py | 12 ++++++------ python/source.py | 2 +- python/tests/chunk_layout.py | 1 - src/structure.cpp | 6 ++---- 12 files changed, 22 insertions(+), 45 deletions(-) delete mode 100644 doc/docs/Python_Tutorials/AdjointSolver.md diff --git a/doc/docs/Acknowledgements.md b/doc/docs/Acknowledgements.md index 295c7b2b1..94b5171d3 100644 --- a/doc/docs/Acknowledgements.md +++ b/doc/docs/Acknowledgements.md @@ -5,7 +5,7 @@ Authors ------- -Meep originated as part of graduate research at [MIT](https://en.wikipedia.org/wiki/Massachusetts_Institute_of_Technology) with initial contributions by [Steven G. Johnson](http://math.mit.edu/~stevenj/), [Ardavan Oskooi](http://ab-initio.mit.edu/~oskooi/), [David Roundy](http://physics.oregonstate.edu/~roundyd/), [Mihai Ibanescu](https://www.linkedin.com/in/mihai-ibanescu-2b147825/), and [Peter Bermel](http://web.ics.purdue.edu/~pbermel/). Currently, the Meep project is maintained by [Simpetus](http://www.simpetus.com) and the developer community on [GitHub](https://github.com/NanoComp/meep). [Christopher Hogan](https://github.com/ChristopherHogan) and [M.T. Homer Reid](http://homerreid.dyndns.org/) lead the development of the [Python interface](Python_User_Interface.md), [mode-decomposition feature](Python_Tutorials/Mode_Decomposition.md), and [GDSII import routines](Python_Tutorials/GDSII_Import.md). M.T. Homer Reid and [Alec Hammond](https://github.com/smartalecH/) developed the [adjoint solver](Python_Tutorials/AdjointSolver.md). [Alex Cerjan](http://www.alexcerjan.com/) assisted with adding support for saturable absorption via [multilevel atomic gain media](Materials.md#saturable-gain-and-absorption). Alec Hammond developed the [visualization module](Python_User_Interface.md#data-visualization). [Yidong Chong](http://www1.spms.ntu.edu.sg/~ydchong/bio.html) and Alex Cerjan added support for [gyrotropic media](Materials.md#gyrotropic-media). +Meep originated as part of graduate research at [MIT](https://en.wikipedia.org/wiki/Massachusetts_Institute_of_Technology) with initial contributions by [Steven G. Johnson](http://math.mit.edu/~stevenj/), [Ardavan Oskooi](http://ab-initio.mit.edu/~oskooi/), [David Roundy](http://physics.oregonstate.edu/~roundyd/), [Mihai Ibanescu](https://www.linkedin.com/in/mihai-ibanescu-2b147825/), and [Peter Bermel](http://web.ics.purdue.edu/~pbermel/). Currently, the Meep project is maintained by [Simpetus](http://www.simpetus.com) and the developer community on [GitHub](https://github.com/NanoComp/meep). [Christopher Hogan](https://github.com/ChristopherHogan) and [M.T. Homer Reid](http://homerreid.dyndns.org/) lead the development of the [Python interface](Python_User_Interface.md), [mode-decomposition feature](Python_Tutorials/Mode_Decomposition.md), and [GDSII import routines](Python_Tutorials/GDSII_Import.md). M.T. Homer Reid and [Alec Hammond](https://github.com/smartalecH/) developed the [adjoint solver](Python_Tutorials/Adjoint_Solver.md). [Alex Cerjan](http://www.alexcerjan.com/) assisted with adding support for saturable absorption via [multilevel atomic gain media](Materials.md#saturable-gain-and-absorption). Alec Hammond developed the [visualization module](Python_User_Interface.md#data-visualization). [Yidong Chong](http://www1.spms.ntu.edu.sg/~ydchong/bio.html) and Alex Cerjan added support for [gyrotropic media](Materials.md#gyrotropic-media). Referencing ----------- diff --git a/doc/docs/Build_From_Source.md b/doc/docs/Build_From_Source.md index 01b91b4cd..2b679fc2a 100644 --- a/doc/docs/Build_From_Source.md +++ b/doc/docs/Build_From_Source.md @@ -91,7 +91,7 @@ If you are not the system administrator of your machine, and/or want to install ### Python -If you have Python on your system, then the Meep compilation scripts automatically build and install the `meep` Python module, which works with both the serial and parallel (MPI) versions of Meep. Note: Meep's [visualization module](Python_User_Interface.md#data-visualization) includes animation routines which require [matplotlib](https://matplotlib.org/) version `3.1`+ and the [adjoint solver](Python_Tutorials/AdjointSolver.md) requires [autograd](https://github.com/HIPS/autograd). +If you have Python on your system, then the Meep compilation scripts automatically build and install the `meep` Python module, which works with both the serial and parallel (MPI) versions of Meep. Note: Meep's [visualization module](Python_User_Interface.md#data-visualization) includes animation routines which require [matplotlib](https://matplotlib.org/) version `3.1`+ and the [adjoint solver](Python_Tutorials/Adjoint_Solver.md) requires [autograd](https://github.com/HIPS/autograd). By default, Meep's Python module is installed for the program `python` on your system. If you want to install using a different Python program, e.g. `python3`, pass `PYTHON=python3` (or similar) to the Meep `configure` script. An Anaconda (`conda`) [package for Meep](Installation.md#conda-packages) is also available on some systems. diff --git a/doc/docs/FAQ.md b/doc/docs/FAQ.md index 3d708a5ec..b5403ddb5 100644 --- a/doc/docs/FAQ.md +++ b/doc/docs/FAQ.md @@ -421,10 +421,6 @@ Yes. An official [Python interface](Python_User_Interface.md) was released in [v At least 8 pixels per wavelength in the lossless dielectric material with the highest index. Resolving the [skin depth of metals](https://en.wikipedia.org/wiki/Skin_effect), which is typically tens of nanometers at optical frequencies, will require a pixel size of comparable dimensions since [subpixel averaging does not apply to dispersive materials](Subpixel_Smoothing.md#what-about-dispersive-materials). -### What is a good rule of thumb for the PML thickness? - -Around half the wavelength, typically. (Note that the boundary condition, metallic or periodic, is essentially irrelevant to the operation of the PML.) PML allows inhomogeneous materials like waveguides as long as the materials are only varying in the boundary-*parallel* directions; wave media that are inhomogeneous in the boundary-normal directions (e.g., gratings or other periodic structures, oblique waveguides, etc.) as well as unusual waveguides with backward-wave modes cause PML to break down, in which case one alternative is a thicker non-PML [absorber](Python_User_Interface.md#absorber) as described in [Perfectly Matched Layers](Perfectly_Matched_Layer.md). - ### What is Meep's frequency-domain solver and how does it work? Meep contains a [frequency-domain solver](Python_User_Interface.md#frequency-domain-solver) that directly computes the steady-state fields produced in a geometry in response to a [continuous-wave (CW) source](https://en.wikipedia.org/wiki/Continuous_wave), using an [iterative linear solver](https://en.wikipedia.org/wiki/Iterative_method) instead of time-stepping. This is possible because the FDTD timestep can be used to formulate a frequency-domain problem via an iterative linear solver. The frequency-domain response can often be determined using many fewer timesteps while exploiting the FDTD code almost without modification. For details, see Section 5.3 ("Frequency-domain solver") of [Computer Physics Communications, Vol. 181, pp. 687-702, 2010](http://ab-initio.mit.edu/~oskooi/papers/Oskooi10.pdf). @@ -495,4 +491,4 @@ The second approach is based on a full nonlinear simulation of the Raman process ### Does Meep support adjoint-based optimization? -Yes. Meep contains an [adjoint solver](Python_Tutorials/AdjointSolver.md) which can be used for sensitivity analysis and automated design optimization with respect to a grid of $\varepsilon$ values (also known as "density-based" topology optimization). (Of course, you can always use finite differences or similar methods to compute sensitivities for other parameters, as well as derivative-free optimization methods. However, such methods become increasingly impractical for ≳ 10 parameters.) +Yes. Meep contains an [adjoint solver](Python_Tutorials/Adjoint_Solver.md) which can be used for sensitivity analysis and automated design optimization with respect to a grid of $\varepsilon$ values (also known as "density-based" topology optimization). (Of course, you can always use finite differences or similar methods to compute sensitivities for other parameters, as well as derivative-free optimization methods. However, such methods become increasingly impractical for ≳ 10 parameters.) diff --git a/doc/docs/Parallel_Meep.md b/doc/docs/Parallel_Meep.md index 8ac9c5ec1..ab226992c 100644 --- a/doc/docs/Parallel_Meep.md +++ b/doc/docs/Parallel_Meep.md @@ -57,7 +57,7 @@ Meep also supports [thread-level parallelism](https://en.wikipedia.org/wiki/Task ### Optimization Studies of Parallel Simulations -When running Meep simulations as part of an optimization study (e.g., via the [adjoint solver](Python_Tutorials/AdjointSolver.md)), in order to keep all processes synchronized *every* process runs the same optimization algorithm on the same optimization variables. The overhead of duplicating the computational cost of the optimization algorithm and storage of the design variables across all processes is negligible compared to those of the Meep simulation. +When running Meep simulations as part of an optimization study (e.g., via the [adjoint solver](Python_Tutorials/Adjoint_Solver.md)), in order to keep all processes synchronized *every* process runs the same optimization algorithm on the same optimization variables. The overhead of duplicating the computational cost of the optimization algorithm and storage of the design variables across all processes is negligible compared to those of the Meep simulation. For comparison, consider the scenario where the optimization runs on just a single master process. That would mean that during each iteration of the optimization after the Meep simulation has computed the objective function (and its gradient), only the master process uses this information to update the optimization parameters (i.e., the design region). The master process would then need to send the updated design region to the other processes so that they could all begin the next Meep simulation. As a result, additional bookkeeping is required to synchronize the processes. @@ -99,7 +99,7 @@ Technical Details When you run Meep under MPI, the following is a brief description of what is happening behind the scenes. For the most part, you shouldn't need to know this stuff. Just use the same Python/Scheme script file exactly as you would for a uniprocessor simulation. -First, every MPI process executes the Python/Scheme file in parallel. The processes communicate however, to only perform one simulation in sync with one another. In particular, the cell is divided into "chunks", one per process, to roughly equally divide the work and the memory. For additional details, see [Chunks and Symmetry](Chunks_and_Symmetry.md) as well as Section 2.2 ("Grid chunks and owned points") of [Computer Physics Communications, Vol. 181, pp. 687-702, 2010](http://ab-initio.mit.edu/~oskooi/papers/Oskooi10.pdf). +First, every MPI process executes the Python/Scheme file in parallel. The processes communicate however, to only perform one simulation in sync with one another. In particular, the cell is divided into "chunks," one per process, to roughly equally divide the work and the memory. For additional details, see [Chunks and Symmetry](Chunks_and_Symmetry.md) as well as Section 2.2 ("Grid chunks and owned points") of [Computer Physics Communications, Vol. 181, pp. 687-702, 2010](http://ab-initio.mit.edu/~oskooi/papers/Oskooi10.pdf). When you time-step via Python's `meep.Simulation.run(until=...)` or Scheme's `run-until`, etc., the chunks are time-stepped in parallel, communicating the values of the pixels on their boundaries with one another. In general, any Meep function that performs some collective operation over the whole cell or a large portion thereof is parallelized, including: time-stepping, HDF5 I/O, accumulation of flux spectra, and field integration via `integrate_field_function` (Python) or `integrate-field-function` (Scheme), although the *results* are communicated to all processes. diff --git a/doc/docs/Perfectly_Matched_Layer.md b/doc/docs/Perfectly_Matched_Layer.md index 32cc76de4..63a5505a0 100644 --- a/doc/docs/Perfectly_Matched_Layer.md +++ b/doc/docs/Perfectly_Matched_Layer.md @@ -64,3 +64,8 @@ For an $E_y$-polarized source and `is_integrated=True`, the wavefronts are plana In the future, `is_integrated=True` will be set automatically for sources extending into the PML ([#1049](https://github.com/NanoComp/meep/issues/1049)). + +What is a Good Rule of Thumb for the PML thickness? +--------------------------------------------------- + +Around half the wavelength, typically. (Note that the boundary condition, metallic or periodic, is essentially irrelevant to the operation of the PML.) PML allows inhomogeneous materials like waveguides as long as the materials are only varying in the boundary-*parallel* directions; wave media that are inhomogeneous in the boundary-normal directions (e.g., gratings or other periodic structures, oblique waveguides, etc.) as well as unusual waveguides with backward-wave modes cause PML to break down, in which case one alternative is a thicker non-PML [absorber](Python_User_Interface.md#absorber). \ No newline at end of file diff --git a/doc/docs/Python_Tutorials/AdjointSolver.md b/doc/docs/Python_Tutorials/AdjointSolver.md deleted file mode 100644 index a82548dbd..000000000 --- a/doc/docs/Python_Tutorials/AdjointSolver.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -# Adjoint Solver ---- - -Meep contains a density-based adjoint solver for efficiently computing the gradient of an objective function with respect to the permittivity on a discrete spatial grid in a subregion of the cell. Regardless of the number of degrees of freedom for the grid points, just **two** separate timestepping runs are required. The first run is the "forward" calculation to compute the objective function. The second run is the "adjoint" calculation which involves a special type of source distribution and postprocessing applied to the results. This module is implemented entirely in Python using [autograd](https://github.com/HIPS/autograd) and does not involve modifications to the C++ [`libmeep`](../Chunks_and_Symmetry.md) core library. At a higher level, the module implements functionality for wrapping a numerical optimizer around the gradient computation to enable automated design optimization. - -Six Jupyter notebooks that demonstrate usage of the adjoint solver are available: - -- [Introduction](https://nbviewer.jupyter.org/github/NanoComp/meep/blob/master/python/examples/adjoint_optimization/01-Introduction.ipynb) - -- [Waveguide Bend Optimization](https://nbviewer.jupyter.org/github/NanoComp/meep/blob/master/python/examples/adjoint_optimization/02-Waveguide_Bend.ipynb) - -- [Filtering and Thresholding Design Parameters and Broadband Objective Functions](https://nbviewer.jupyter.org/github/NanoComp/meep/blob/master/python/examples/adjoint_optimization/03-Filtered_Waveguide_Bend.ipynb) - -- [Design of a Symmetric Broadband Splitter](https://nbviewer.jupyter.org/github/NanoComp/meep/blob/master/python/examples/adjoint_optimization/04-Splitter.ipynb) - -- [Broadband Objective Function using Epigraph Formulation](https://nbviewer.jupyter.org/github/NanoComp/meep/blob/master/python/examples/adjoint_optimization/05-Minimax.ipynb) - -- [Objective Function based on Near to Far-Field Transformation](https://nbviewer.jupyter.org/github/NanoComp/meep/blob/master/python/examples/adjoint_optimization/Near2Far-Optimization-with-Epigraph-Formulation.ipynb) - -More documentation will be available soon. diff --git a/doc/docs/Subpixel_Smoothing.md b/doc/docs/Subpixel_Smoothing.md index d0c0195b5..248f41e26 100644 --- a/doc/docs/Subpixel_Smoothing.md +++ b/doc/docs/Subpixel_Smoothing.md @@ -147,7 +147,7 @@ It is possible that the subpixel averaging may still improve the constant factor What Happens When Subpixel Smoothing is Disabled? ------------------------------------------------- -When subpixel smoothing is disabled by either (1) setting `eps_averaging=False` in the [`Simulation`](Python_User_Interface.md#the-simulation-class) constructor or (2) using a [material function](Subpixel_Smoothing.md#enabling-averaging-for-material-function) (as is typical in the [adjoint solver](Python_Tutorials/AdjointSolver.md)), each electric field component $(E_x, E_y, E_z)$ in a given voxel is individually assigned a scalar permittivity (for isotropic materials) based on whatever the value of the permittivity is at that position in the [Yee grid](Yee_Lattice.md). This results in [staircasing artifacts](Subpixel_Smoothing.md) due to the discontinuous material interfaces as well as the staggered nature of the Yee grid points. Any change in the resolution which shifts the location of the Yee grid points relative to the material interfaces will result in unpredictable changes to any computed quantities. The coordinates the Yee grid points can be obtained using a [field function](Field_Functions.md#coordinates-of-the-yee-grid) which can be useful for debugging. +When subpixel smoothing is disabled by either (1) setting `eps_averaging=False` in the [`Simulation`](Python_User_Interface.md#the-simulation-class) constructor or (2) using a [material function](Subpixel_Smoothing.md#enabling-averaging-for-material-function) (as is typical in the [adjoint solver](Python_Tutorials/Adjoint_Solver.md)), each electric field component $(E_x, E_y, E_z)$ in a given voxel is individually assigned a scalar permittivity (for isotropic materials) based on whatever the value of the permittivity is at that position in the [Yee grid](Yee_Lattice.md). This results in [staircasing artifacts](Subpixel_Smoothing.md) due to the discontinuous material interfaces as well as the staggered nature of the Yee grid points. Any change in the resolution which shifts the location of the Yee grid points relative to the material interfaces will result in unpredictable changes to any computed quantities. The coordinates the Yee grid points can be obtained using a [field function](Field_Functions.md#coordinates-of-the-yee-grid) which can be useful for debugging. Subpixel Smoothing vs. Bilinear Interpolation --------------------------------------------- @@ -190,7 +190,7 @@ There are three important items to note. (1) The pixel grid and prism representa Since the interpolated pixel grid has already been smoothed to a continuous $\varepsilon(x,y)$ function, subpixel smoothing (which is not supported for `epsilon_input_file`) is not really necessary once the Yee grid resolution exceeds the input image resolution. This can be seen in the above plot: for Meep Yee grid resolutions of 80 (equal to the pixel grid resolution of the HDF5 file) and above, the changes in the results are much smaller than those at lower resolutions. Also, higher-order interpolation schemes are not necessary because the Yee discretization is already essentially equivalent to linear interpolation. -As a practical matter, increasing the Meep resolution beyond the resolution of a non-interpolated pixel grid is not physically meaningful because this is trying to resolve the individual pixels of an imported image. In the case of a pixel grid imported via `epsilon_input_file`, this is not an issue because the bilinear interpolation is performed automatically by default. However, no built-in interpolation is provided for a material function; it must be provided by the user (i.e., convolving the discontinuous material function with a smoothing kernel as demonstrated [below](#interpolation-techniques-for-material-function)). As a corollary, when designing structures using a pixel grid (e.g., as in the [adjoint solver](Python_Tutorials/AdjointSolver.md)), the pixel density of the degrees of freedom should typically be at least as big as the Meep resolution if not greater. +As a practical matter, increasing the Meep resolution beyond the resolution of a non-interpolated pixel grid is not physically meaningful because this is trying to resolve the individual pixels of an imported image. In the case of a pixel grid imported via `epsilon_input_file`, this is not an issue because the bilinear interpolation is performed automatically by default. However, no built-in interpolation is provided for a material function; it must be provided by the user (i.e., convolving the discontinuous material function with a smoothing kernel as demonstrated [below](#interpolation-techniques-for-material-function)). As a corollary, when designing structures using a pixel grid (e.g., as in the [adjoint solver](Python_Tutorials/Adjoint_Solver.md)), the pixel density of the degrees of freedom should typically be at least as big as the Meep resolution if not greater. In terms of runtime performance, for structures based on a frequency-independent permittivity, anisotropic subpixel smoothing will generally consume more memory (due to the additional off-diagonal elements of the permittivity tensor) and have a slower time-stepping rate (again due to the anisotropic permittivity tensor which couples different field components during the field updates) than a simple scalar interpolation technique. The gains in accuracy from the anisotropic smoothing though should far outweigh this small performance penalty. diff --git a/doc/docs/index.md b/doc/docs/index.md index ecfea5894..e6dd15b0f 100644 --- a/doc/docs/index.md +++ b/doc/docs/index.md @@ -22,7 +22,7 @@ - ε/μ and field import/export in the [HDF5](https://en.wikipedia.org/wiki/HDF5) data format. - [GDSII](Python_User_Interface.md#gdsii-support) file import for planar geometries. - Field analyses including [Poynting flux](Python_Tutorials/Basics.md#transmittance-spectrum-of-a-waveguide-bend), [mode decomposition](Python_Tutorials/Mode_Decomposition.md) (for [S-parameters](Python_Tutorials/GDSII_Import.md)), [energy density](Python_User_Interface.md#energy-density-spectra), [near to far transformation](Python_Tutorials/Near_to_Far_Field_Spectra.md), [frequency extraction](Python_Tutorials/Basics.md#modes-of-a-ring-resonator), [local density of states](Python_Tutorials/Local_Density_of_States.md) (LDOS), [modal volume](Python_User_Interface.md#field-computations), [scattering cross section](Python_Tutorials/Basics.md#mie-scattering-of-a-lossless-dielectric-sphere), [Maxwell stress tensor](Python_Tutorials/Optical_Forces.md), [absorbed power density](Python_Tutorials/Basics.md#absorbed-power-density-map-of-a-lossy-cylinder), [arbitrary functions](Field_Functions.md); completely programmable. -- [Adjoint solver](Python_Tutorials/AdjointSolver.md) for **sensitivity analysis** and **automated design optimization**. +- [Adjoint solver](Python_Tutorials/Adjoint_Solver.md) for **sensitivity analysis** and **automated design optimization**. - [Visualization routines](Python_User_Interface.md#data-visualization) for the simulation domain involving geometries, fields, boundary layers, sources, and monitors. Time-Domain Simulation diff --git a/python/geom.py b/python/geom.py index 065b785c0..2be943da7 100755 --- a/python/geom.py +++ b/python/geom.py @@ -550,12 +550,12 @@ def __init__(self,grid_size,medium1,medium2,weights=None,grid_type="U_DEFAULT",d The subpixel smoothing is based on an adaptive quadrature scheme with properties `subpixel_maxeval` and `subpixel_tol` which can be specified using the `Simulation` constructor. - Grids which are symmetric (e.g., mirror, rotation) must be explicitly defined. One way to implement this is by overlapping - a given `MaterialGrid` object with a symmetrized copy of itself. In the case of spatially overlapping `MaterialGrid` - objects (with no intervening objects), any overlapping points are computed using the method `grid_type` which is one of - `"U_MIN"` (minimum of the overlapping grid values), `"U_PROD"` (product), `"U_MEAN"` (mean), `"U_DEFAULT"` - (topmost material grid). In general, these `"U_*"` options allow you to combine any material grids that overlap - in space with no intervening objects. + It is possible to overlap any number of different `MaterialGrid`s. This can be useful for defining grids which are symmetric + (e.g., mirror, rotation). One way to set this up is by overlapping a given `MaterialGrid` object with a symmetrized copy of + itself. In the case of spatially overlapping `MaterialGrid` objects (with no intervening objects), any overlapping points are + computed using the method `grid_type` which is one of `"U_MIN"` (minimum of the overlapping grid values), `"U_PROD"` (product), + `"U_MEAN"` (mean), `"U_DEFAULT"` (topmost material grid). In general, these `"U_*"` options allow you to combine any material + grids that overlap in space with no intervening objects. """ self.grid_size = mp.Vector3(*grid_size) self.medium1 = medium1 diff --git a/python/source.py b/python/source.py index 17caad175..e06d39a84 100644 --- a/python/source.py +++ b/python/source.py @@ -376,7 +376,7 @@ def __init__(self, """ Construct an `EigenModeSource`. - + **`eig_band` [`integer` or `DiffractedPlanewave`]** — Either the index *n* (1,2,3,...) of the desired band + + **`eig_band` [`integer` or `DiffractedPlanewave` class]** — Either the index *n* (1,2,3,...) of the desired band ω*n*(**k**) to compute in MPB where 1 denotes the lowest-frequency band at a given **k** point, and so on, or alternatively a diffracted planewave in homogeneous media. diff --git a/python/tests/chunk_layout.py b/python/tests/chunk_layout.py index b88951839..e49e48c9a 100644 --- a/python/tests/chunk_layout.py +++ b/python/tests/chunk_layout.py @@ -43,7 +43,6 @@ def test_chunk_layout_binary_partition(self): sim = mp.Simulation(cell_size=cell_size, resolution=10, - num_chunks=5, chunk_layout=chunk_layout) sim.init_sim() diff --git a/src/structure.cpp b/src/structure.cpp index 5a474e311..23d68c5b1 100644 --- a/src/structure.cpp +++ b/src/structure.cpp @@ -111,8 +111,6 @@ void structure::choose_chunkdivision(const grid_volume &thegv, int desired_num_c // create the chunks: std::vector chunk_volumes = meep::choose_chunkdivision(gv, v, desired_num_chunks, s); - int my_num_chunks = chunk_volumes.size(); - // initialize effort volumes num_effort_volumes = 1; effort_volumes = new grid_volume[num_effort_volumes]; @@ -125,9 +123,9 @@ void structure::choose_chunkdivision(const grid_volume &thegv, int desired_num_c // Break off PML regions into their own chunks num_chunks = 0; - chunks = new structure_chunk_ptr[my_num_chunks * num_effort_volumes]; + chunks = new structure_chunk_ptr[chunk_volumes.size() * num_effort_volumes]; for (size_t i = 0, stop = chunk_volumes.size(); i < stop; ++i) { - const int proc = i * count_processors() / my_num_chunks; + const int proc = i * count_processors() / chunk_volumes.size(); for (int j = 0; j < num_effort_volumes; ++j) { grid_volume vc; if (chunk_volumes[i].intersect_with(effort_volumes[j], &vc)) {