So the amp-func approach suggested below doesn't handle zero thickness objects, right?
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. The scenegraph is technically a tree though it ends up becoming a directed acyclic graph because nodes/leaves can be shared. for example, we may have exactly one box as a leaf but two paths to it from the root - one direct and the other with a translation node (parameterized by a vector). This way the scene becomes two boxes at different locations. 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. 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? Thanks Manoj Steven G. Johnson wrote: > On Sun, 6 Jan 2008, Manoj Rajagopalan wrote: >> So right now is there a way to create a rotated box source? I only see a >> "size" parameter in the source, no hints for orientation > > Well, you could do it by passing an amp-func parameter that is zero > outside the rotated box (or any other shape of your choice, for that > matter). In this case the size/center parameters are just the bounding > box. > > (The geometric_volume parameters themselves, as specified in the libctl > front-end by size/volume, are always boxes aligned with the grid.) > > [Geometric objects (cylinders, blocks, etcetera) used to defined the > dielectric function etcetera can be oriented arbitrarily.] > > Actually, it would be pretty easy to write a function for the front-end > that allowed the user to pass arbitrary geometric objects for the source > shape [the implementation would just use the amp-func method mentioned > above, internally, although I would probably want to do more sophisticated > averaging around object boundaries and handle zero-thickness objects], if > people were interested in such a feature. I've never needed such a thing > myself. > > Regards, > Steven G. Johnson > > _______________________________________________ > meep-discuss mailing list > [email protected] > http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss > > _______________________________________________ meep-discuss mailing list [email protected] http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
