[pre-ANN] Differentiable FDTD for inverse design in photonics, acoustics and RF

Package Announcements
, , , ,
41

Beautiful. :slight_smile: Works perfectly. I ran a check with 2D on the first one for speed / I’ll run tests on the other case later, but overall, excellent work!

1 Like
42

Thanks for being an early tester! We ironed out issues and released a new notebook with examples. If you’re benchmarking speed I’ll need to separate out the compilation part (todo list). Here are some inverse designs of wavelength domain demultiplexer and symmetric crossing, all in just few lines of code.

download (2)
download (2)750×562 61.4 KB

download (1)
download (1)1200×900 75.5 KB

4 Likes
43

We compiled Julia FDTD backend to binary with PackageCompiler.jl so it’s much faster now. New notebook w/ installation, sparams and inverse design at Google Colab

4 Likes
44

We implemented tensor subpixel smoothing for accuracy and adaptive grid for speed. Please contact us for latest installation binaries. New notebook Google Colab

3 Likes
45

Thanks for the great work!

Is it possible to just add the package without the compiled binary?
I am just interested in learning the features of the package at this stage.

Also what do you think about working in julia without the gdsfactory

46

Thanks! Yes, but I haven’t documented the base Julia API. Problem is that our paying customers have zero interest in learning Julia. They’re used to a GUI like Lumerical or simple Python eg Tidy3D or gdsfactory.

We only use gdsfactory for editing gds and rasterizing voxels from gds. You’re welcome to provide voxels thru any means.

Frankly, unless you provide funding, Julia docs is unlikely to happen soon. Sorry I have to meet where my customers are :confused:

What’s your use case?

47

I am just learning :slight_smile:

My main interest is in the RF and metamaterials. So I am trying to find out if this package can be useful to me

48

Why did you write it in Julia if you don’t plan on supporting a Julia front end? Seems odd to me. I would have just wrote in in JAX then.

49

Started out fullstack Julia but customers all insist on using Python. But I stuck with Julia because the range of native Julia you can automatically differentiate is vastly greater than the range of native Python that JAX can AD. Plus I hacked Julia to write Maxwell’s equations verbatim. Try doing that with JAX :wink:

image
image358×278 5.29 KB

4 Likes
50

Cool. FE or BVM is generally preferred for RF. We plan on doing a Python frontend for metamaterials soon. Do you mean 3D RF metamaterials or planar microstrip?

51

Dang so the customers really want Python that bad? This is the problem with Julia which is quite a conundrum. Sorry, I won’t hijack your thread anymore.

52

I spoke too harshly - would be nice to document the Julia API - docs did exist but fell out of date. Khronos.jl isn’t documented either but at least has Julia API examples. Half the work is in setting up the geometry, and most of the tooling there is thru gdsfactory or some GUI modeler. Have to interact with non-Julia tooling anyways…

So most customers grew up on Synopsys, Lumerical, ANSYS HFSS - all GUIs. Maybe Meep or Tidy3D - Python scripting. You can’t expect them to learn Julia just to use your tool.

In applications where there’s an existing (eg non-Julia) tooling ecosystem, I found it more natural to relegate Julia to backend. Sadly Julia doesn’t solve the two language problem.

Also I wish for much better standalone binary compilation in Julia. PkgCompilers.jl has come a long way but still lots of issues…

1 Like
53

Both.
Do you have a list of what is supported and what is not?

54

I plan to implement at least microstrip but might take some time. FDTD not great for metals. It’s easier if you assume lossless conductor.