Meep C-plus-plus Reference
From AbInitio
Revision as of 19:24, 7 November 2005 (edit) Stevenj (Talk | contribs) ← Previous diff |
Revision as of 23:14, 9 January 2008 (edit) Rmanoj (Talk | contribs) Next diff → |
||
Line 9: | Line 9: | ||
* The [[Meep C-plus-plus Tutorial|C++ tutorial]]. | * The [[Meep C-plus-plus Tutorial|C++ tutorial]]. | ||
* The original Meep manual, available from http://ab-initio.mit.edu/~meep/meep.pdf | * The original Meep manual, available from http://ab-initio.mit.edu/~meep/meep.pdf | ||
+ | |||
+ | |||
+ | |||
+ | == MEEP Design == | ||
+ | |||
+ | |||
+ | === volume and geometric_volume === | ||
+ | |||
+ | The '''geometric_volume''' class represents a rectangular box-like region, parallel to the xyz axes, in "continuous space" -- i.e. the corners can be at any points, not necessarily grid points. This is used, for example, whenever you want to specify the integral of some quantity (e.g. flux, energy) in a box-like region, and Meep interpolates from the grid as necessary to give an illusion of continuity. | ||
+ | |||
+ | The '''volume''' class is a box of pixels. It stores the resolution, the number of pixels in each direction, the origin, etcetera. Given a volume, there are functions to get the geometric volume corresponding to the bounding box, etcetera. There is a volume object associated with the whole computational grid, and with each chunk in the grid. There are various tricky aspects to the volume. One is associated with the Yee grid: it has to know about different field components stored at different points. Another is associated with the fact that boundary conditions (not only the overall grid boundaries, but also boundaries between chunks) are handled by an extra layer of "non-owned" pixels around the boundaries. So each chunk volume has "owned" grid points that the chunk is responsible for updating, and "non-owned" grid points that are updated using the boundary conditions. And thanks to the Yee grid (which complicates everything in FDTD, unfortunately), the set of owned and non-owned coordinates is different for each field component. The volume class keeps track of all this. | ||
+ | |||
+ | |||
== Deprecated interfaces == | == Deprecated interfaces == |
Revision as of 23:14, 9 January 2008
Meep |
Download |
Release notes |
FAQ |
Meep manual |
Introduction |
Installation |
Tutorial |
Reference |
C++ Tutorial |
C++ Reference |
Acknowledgements |
License and Copyright |
This page will eventually be a compact listing of the different functions and classes provided by the C++ interface.
Currently, we haven't had time to write anything here. However, there are several other sources of information about the C++ interface:
- The source code — reading the sources and headers is our own main reference.
- The test programs included in the
tests/
directory. - The C++ tutorial.
- The original Meep manual, available from http://ab-initio.mit.edu/~meep/meep.pdf
MEEP Design
volume and geometric_volume
The geometric_volume class represents a rectangular box-like region, parallel to the xyz axes, in "continuous space" -- i.e. the corners can be at any points, not necessarily grid points. This is used, for example, whenever you want to specify the integral of some quantity (e.g. flux, energy) in a box-like region, and Meep interpolates from the grid as necessary to give an illusion of continuity.
The volume class is a box of pixels. It stores the resolution, the number of pixels in each direction, the origin, etcetera. Given a volume, there are functions to get the geometric volume corresponding to the bounding box, etcetera. There is a volume object associated with the whole computational grid, and with each chunk in the grid. There are various tricky aspects to the volume. One is associated with the Yee grid: it has to know about different field components stored at different points. Another is associated with the fact that boundary conditions (not only the overall grid boundaries, but also boundaries between chunks) are handled by an extra layer of "non-owned" pixels around the boundaries. So each chunk volume has "owned" grid points that the chunk is responsible for updating, and "non-owned" grid points that are updated using the boundary conditions. And thanks to the Yee grid (which complicates everything in FDTD, unfortunately), the set of owned and non-owned coordinates is different for each field component. The volume class keeps track of all this.
Deprecated interfaces
Beware that some of the interfaces in the source code and in the old manual are now deprecated, as they have been superseded by newer features and may be removed at some point.
In particular, you should probably avoid:
- The
monitor_point
class. Just declare an array to store the fields you want, get them withfields::get_field
, and analyze them withdo_harminv
. Or, to accumulate the DFT as you run, use thedft_chunk
class viafields::add_dft
. - Slice and EPS output. This has been superseded by HDF5 output, which is much more flexible and efficient.