Disclaimer:

This Page is just here for my own convenience. If you find it useful as well, fantastic. Read below to find out what meep++ is all about.

Svn access is at http://www.glenstark.net/Meeppp. Doxygen documentation is available here. Please let me know if you have any difficulties. If you want to contribute, write me.

Current status: working on making sources more flexible: adding source templates.

About Meep++

Meep++ is my attempt to refactor the excellent Meep package into an efficient library for developing C++ FDTD applications.

First of all, full respect and kudos to the Meep programmers, and current maintainers. They have provided an unparalleled resource for people who want to use FDTD to study photonic crystals. But for those of us who want to investigate new FDTD techniques, or apply FDTD in ways that are not easily supported by the ctl interface, the Meep code leaves a lot to be desired, while remaining the best option (thanks FSF!). Meep uses the Haskell language to auto-generate numeric code, and the current administrators do not support the C++ library. Rather they intend the package to be used via the ctl interface. This requires learning a new programming language for most people (one that is not very widespread), and is not as flexible or powerful as the C++ libraries. The autogenerated code is quite wasteful in parts, which is an issue for thus of us who are pushing the boundaries for the size of systems we want to simulate.

The C++ interface documentation is no longer being updated, and the user is told that the code is the documentation. Unfortunately, the code doesn’t follow any kind of naming conventions, has local and global variable names like “argh”, and “nastyX”, and isn’t easy to navigate or comprehend.

Fortunately, meep is GPL’d, so I’m refactoring the code a bit. It’s currently a work in progress. So far I’ve:

• removed the ctl interface.
• organized the code so that it’s significantly closer to following the “one module, one file” guideline, meaning it’s a lot easier to figure out where to look for the answer to your questions.
• Introduced a few basic naming conventions (m_ prefacing member data, eliminating single letter globals and members, capitalizing classes), to help the readability problem.
• eliminated a few inefficiencies (redundant memory initialization).
• created an incomplete Doxygen documentation for the libraries.

The next steps are, in no particular order:

• Refactor the main update loops. This is going to be challenging as this is entirely auto-generated. The goal is to make it easier to substitute in our own update routines, to allow us try new active and dispersive models.
• Finish the file seperation process.
• Benchmarks for comparison against the original meep code.
• implement our active material strategy.
• substitute templated code for the current haskel generated code, as well as the 2d/3d selection.
• add 1d support.
• finish Doxygen docu of the code.

If you want to help with any of these steps, that’d be great. Let me know.