On Sun, 6 Jan 2008, Manoj Rajagopalan wrote: > So the amp-func approach suggested below doesn't handle zero thickness > objects, right?
Not directly, although there are ways to do this. (The best way is to make your amp-func not return 1 or zero, but to return your object convolved with some smoothing kernel. e.g. linear interpolation corresponds to a triangular smoothing kernel.) > Have you considered using a scenegraph? In computer graphics parlance > this is nothing but a tree of objects, akin to what MEEP/ctlgeom uses > except that the nodes in the graphs are not just geometric objects but > also transformations. That way when we traverse the scenegraph from root > to leaf, we also apply all the transformations along the path to > generate the scene. Having a dag (directed acyclic graph) of objects and transformations is mainly useful in computer graphics because things are so dynamic. e.g. you have a person running through a house, and individual objects are transforming with a fixed relationship between subobjects that has to be maintained. That doesn't seem so useful in Meep -- occasionally you will have some objects or sources moving (e.g. to simulate Cerenkov radiation), but the motions/relationships are unlikely to be complicated enough that managing it manually will be a burden. In any case, a scene graph is just a data structure to represent a geometry. Meep already has a data structure to represent arbitrary geometries; that's not the issue here. The issue here is that it doesn't have built-in support for using these arbitrary shapes in all contexts (such as sources), for which the tricky part is proper interpolation to/from the grid; a scene graph doesn't make this any easier (or harder). To be honest, the interpolation isn't too hard for sources, because everything I would need (in particular, computing the overlap of a pixel with an object) is already implemented for the dielectric function. > I bet ctlgeom is already doing something like this. How would one > include rotations into this tree? This approach would be more efficient > in testing for inclusion of points inside the rotated source than the > amp-func approach you have suggested. The latter will test for each > point in the grid-aligned bounding bound whereas in the former approach > we would apply a "modeling transform" to convert the "world" coordinate > to the local coordinates of the rotated geometric object. Then inclusion > test will be easy. Checking whether a point is inside an object is trivial and is already implemented; there is no real difference in difficulty between applying the transformation to the point or to the object. That's not the issue here. > Since geometric objects accept vector3 parameters we only need consider > sources now because they don't have orientation primitives. A scenegraph > for this would be overkill. Simply adding an extra orientation parameter > may be enough. But if we do this would it be able to handle obliquely > oriented line and plane sources? If I were to do anything, I would support arbitrary geometric objects. This is just as easy as supporting rotated rectangles, because I would be using the ctlgeom code in any case. It seems to me that you are focusing on the wrong problem here -- how to describe the shape (easy, already implemented) vs. how to turn it into a working source interpolated properly onto the grid (which I know how to do using our existing code, it's just a matter of finding the time). In practice, it hasn't been a high priority because most FDTD calculations have no need for oddly-shaped sources, as far as I can tell, and there is a workaround already using amp-func. However, I've added it to the TODO list. Regards, Steven G. Johnson _______________________________________________ meep-discuss mailing list [email protected] http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
