Following up, I've discovered that this is completely my fault, and it took me an embarrassingly long time to understand what was happening. Here are the details:
My contour data is spaced at 50 nm intervals in the Z-axis. So, I created my grid_volume with 0.05 micron resolution. In the eps function, I check the p.z() value, do some math according to the pixel location, and return a value accordingly. However, if I now understand correctly, when initializing the structure, the material properties at the Yee grid points are initialized directly from this function. Not realizing this, I was basically returning "air" for any pixel with a z location that wasn't an integer multiple of 0.05. In hindsight, I'm not totally sure where I had thought the in-between grid points were getting their material properties--maybe interpolation from the nearest neighbors. Once I changed the eps function to appropriately return values for ANY z location, the whole values of 1, 4, and 6 were clearly assigned, with intermediate values only at the interfaces. This mistake was clearly due to my misunderstanding of what the Meep routines actually do. And I think I understand now why output_hdf5 can't be used to directly verify the values on the grid as specified, because the grid used in the simulation isn't strictly identical to the grid you request. Some additional notes: In this process, I created a separate routine to process the contour data and create a custom eps file that I could load in the main Meep simulation routine. As expected, it speeds initialization considerably when eps averaging isn't used. Furthermore, it should allow me to realistically use averaging with the time I'm saving. Also, the separate processing routine, which creates a grid with double spacing (0.025 as opposed to 0.05; to provide values for the in-between Yee grid points), takes a similar amount of time to run as the set_epsilon step in the original routine, which supports the ideas that 1) set_epsilon initializes 8x as many points (because 3D) as I requested from the eps function, and 2) that the majority of time spent in set_epsilon was used to translate contour data into the dielectric grid, so indeed, no subpixel averaging was being done. Right now, I'm testing subpixel averaging with the pre-processed eps file to see if the time it takes will be reasonable for me. Either way, thanks to anyone who read this and took the time to think about my problem. On Wed, Nov 6, 2013 at 1:30 PM, John Ball <ballman2...@gmail.com> wrote: > Hello, > > I'm new to the discussion board, and I've been trying to find a reason for > a problem similar to what is discussed here: > > http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg04994.html > > Namely, I am trying to read an input file for the dielectric function. The > original data comes in contour format rather than pixel-dependent epsilon > values, so currently I'm reading that file and using its contents to decide > upon a pixel-dependent dielectric function. That process takes a long time, > so I had the idea to load the resulting eps.h5 file that output_hdf5 > creates for future runs. In short, the first run creates the dielectric > grid and the eps.h5 file, and subsequent runs can just read that file. > > In practice, I've noticed that the values in the eps file, while > qualitatively similar to the input data, don't match the values I'm > returning from the eps function. The function basically checks the pixel > value for three specific conditions and returns either 6, 4, or 1 > accordingly (the values are fictitious, just for testing right now). > However, in the eps file, I see a range of values from 1 to 2.25 (where the > maximum value of 2.25 replaces epsilon at those places I attempted to > return a 6.0). > > Suspecting that subpixel averaging was changing the actual values, I > started checking the source code to make sure averaging is disabled. > However, the structure() constructor sets use_anisotropic_averaging = false > by default, and I'm doing nothing to change that (I never call set_epsilon > after initializing the structure). As a test, using the same eps function, > I set a simple check that returns the arbitrary value of 3.2 if p.x()<1. > In the output eps.h5 file, I see some averaging near x=1, but the eps = 3.2 > values are intact for x<1. > > So, some sort of manipulation of the dielectric function is still > occurring. At the FAQ > (http://ab-initio.mit.edu/wiki/index.php/Meep_FAQ<http://ab-initio.mit.edu/wiki/index.php/Meep_FAQ>), > I read that "even though the internal ε values are indeed discontinuous > when you disable subpixel averaging, the *output* file will still contain > some "averaged" values at interfaces due to the interpolation from the Yee > grid to the center-pixel grid." So, I suspect this interpolation is the > cause, but I don't understand how values of 6.0 are being interpolated to > 2.25. Admittedly, the 6.0 regions are rather narrow, so I broadened those > regions considerably (by tens of pixels) to see if that would fix this > "over-smoothing". However, doing this made no difference for the 6.0->2.25 > replacement. > > At this stage, it seems to me that the easiest thing to do would be to > create a separate script to read the contour file, process it, and output > my own eps file to be read prior to subsequent simulations (taking subpixel > averaging and the Yee grid out of the loop entirely). That way, I could > guarantee reproducibility. However, I'm still concerned about why the > values I"m returning from the epsilon dielectric function are being > adjusted so considerably. Can anyone explain to me what I might be missing > about how structures and their dielectric functions are established? > > Thanks for any help in advance, and have a good day! > John Ball >
_______________________________________________ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
