On Sep 14, 2009, at 1:13 PM, Adam Fedor wrote:

I'm trying to do a 3D simulation of a structure. I create the structure out of multiple blocks. The problem I have is that, in certain locations, there is an artifact in the epsilon geometry where two blocks are adjacent to each other - I get a line of some other epsilon where the two blocks meet, e.g.

X
^
|
--->Y                Block 1                 Block 2

                1.6 1.6 1.6 1.3
                2.3 2.3 2.3 1.6
                2.3 2.3 2.3 1.6
                2.3 2.3 2.3 1.6
                2.3 2.3 2.3 1.6
                2.3 2.3 2.3 1.6 1.6 2.3 2.3 2.3 2.3
                2.3 2.3 2.3 1.6 1.6 2.3 2.3 2.3 2.3
                2.3 2.3 2.3 1.6 1.6 2.3 2.3 2.3 2.3
                2.3 2.3 2.3 1.6 1.6 2.3 2.3 2.3 2.3
                2.3 2.3 2.3 1.6 1.6 2.3 2.3 2.3 2.3
                ...etc...

(All the 1.6 values that are between the blocks should be 2.3). The artifacts do not seem to depend on the resolution I set or whether eps averaging is on or off. However, if I shift the block (in the Y direction), the problem goes away. I'm using meep 1.1.1. I'm fairly sure this is some kind of rounding error, as if I increase the 'mfs' value in the example file below even slightly, to say 0.200001, the artifacts disappear.

You're right that this is almost certainly a rounding error. If your block boundary ends exactly on a pixel location (more precisely, exactly on a Yee grid point), it is going to be basically random whether Meep considers the block to contain that pixel or not.

Of course, it will still converge to the correct result as you increase the resolution, because the artifact is at most one pixel thick. (Unfortunately, the convergence will be only first-order.)

Subpixel averaging would fix this, but Meep's subpixel averaging (even when it is turned on) only affects pixels that contain at most one object interface. In your case, the boundary pixels contain two object interfaces, and Meep punts in this case (the analytical geometry calculations are too messy to compute the overlap of a pixel with multiple objects, and brute-force numerical integration is too slow) and instead just uses the epsilon at the grid point.

The simple fix, as you observed, is that when you want to objects to touch like this you can just add a tiny padding to the object size (e.g. 1e-8 should be more than enough), or specify your geometry in some other way that doesn't involve exactly tangent surfaces.

Steven

_______________________________________________
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss

Reply via email to