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.
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.
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.
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.