Meep FDTD and Julia

Regarding the FDTD solver Meep: GitHub - NanoComp/meep: free finite-difference time-domain (FDTD) software for electromagnetic simulations. Does anyone have any interest in either a Julia package to interface with Meep, or an actual port of the software into native Julia? I’m considering working on this, but it’s a fairly significant effort and I thought it was worth first gauging what other users and vested interests thought.

From a quick look through the C++ code, here’s some random thoughts I’d have on a native port:

  • Pro: I can definitely see patterns where Julia features could make the codebase simpler, e.g.: parametric types, multiple dispatch, etc.
  • Pro: Some of the dependency management would be a bit simpler for end-users who can rely on Julia’s Pkg system vs dealing directly with system-installed C++ libraries.
  • Con: Requiring the use of Julia’s Pkg system to install and manage dependencies could make Meep more difficult to install on systems that aren’t connected to the open internet.
  • Pro: Having the codebase in Julia might lower the bar to entry for potential developers with the required education/background but without a background in C++.
  • Con: Without a transition of the existing user/developer community, there’s going to be some maintenance burden (possibly on both sides) to cross-port/implement continued improvements.
12 Likes

@stevengj I recently watched your Meepcon 2022 talk; do you have any insight into ongoing work or potential cross-interest between the Julia/Meep communities?

1 Like

We’re definitely interested in talking with people working on FDTD in Julia, and @smartalecH (another Meep developer) also has an interest in Julia.

4 Likes

I’m working to open source an FDTD engine we wrote in Julia. It is heavily based on meep and uses many of the meep semantics (chunking, heterogenous stencils, etc). We’ve also written it to work on many (distributed) GPU platforms.

I’ve started the process internally, but my company requires extensive privacy and legal reviews. So it will take some time.

Many of the pros you listed (eg multiple dispatch) indeed made writing something like this much much easier in Julia.

We’re hoping to engage the community once we get approval and can open source the code.

11 Likes

Just chiming in that my company has an interest in this and I would be able to devote time to contribute!

1 Like

Mentioning an FDTD package being developed by @pxshen for completeness.

As a user of meep, I’m very interested in an FDTD package or meep interface for Julia.

1 Like

Thanks @garrek for informing me. And @smartalecH definitely curious to see your work. In comparison my package is designed to be minimalist and hackable - AD compatible for inverse design without custom adjoints. Its forward simulation and adjoints are not heavily optimized for speed or as feature rich like Meep or a Julia port of Meep. BTW a new differentiable FDTD package built purely for speed is fdtdz by Stanford spin off spinsphotonics

BTW a new differentiable FDTD package built purely for speed is fdtdz by Stanford spin off spinsphotonics

@pxshen I’ve met with Jesse a few times to talk about fdtdz. He’s done a good job, and approaches things rather uniquely. Fun fact: he actually tried to implement everything in Julia at first, but couldn’t leverage all the Cuda features he wanted at the time (Cuda.jl has come a long way since then).

He’s got a good jax wrapper around his ptx kernels if anyone’s interested.

2 Likes

Cool, yeah he treats it like an embedded systems problem almost, really optimizing around the memory hierarchy.

Re: Meep, some features if ported or wrapped as separate packages or modules might be of benefit to broader Julia community:

  • geometry creation (nice if can be differentiable)
  • materials library
  • GDSII reader
  • postprocessing eg farfield transform s
  • mode solver

My understanding is that well-implemented FDTD for CPU is usually constrained by memory bandwidth, so anything you can do to improve cache efficiency and alleviate memory bottlenecks will lead to big improvements.

1 Like

This sounds awesome, @smartalecH! I would love to know more about it when you’re able to share more info.

1 Like

(You can call Meep already from Julia using PyCall.jl or PythonCall.jl)

4 Likes

What do you guys use for solving waveguide modes? I’ve been using Femwell and importing into Julia but it’s kinda clunky

Currently MPB, mainly because I wrote it before Meep (which has the advantage of supporting periodic-waveguide modes, and the disadvantages of finding ω(k), requiring a Newton solve for k(ω), as well as not supporting dispersive materials). We’ve thought about plugging in additional mode solvers, e.g. wgms3d.

If you only want to support constant cross-section waveguides, an FDFD mode solver shouldn’t be hard to write. In principle one should write a mode solver that uses exactly the same spatial discretization as your FDTD code, including a discretized propagation direction and discretized time (there is a correction factor for the frequency discussed in our Meep paper), so that you exactly match the numerical dispersion of your FDTD code.

3 Likes

@pxshen check out VectorModeSolver, an FDFD mode solver based on EMpy but written in Julia.

2 Likes