Re: [Meep-discuss] Continued with hdf5 thing
I guess your problem is NFS, which doesn't like parallel hdf5. Have a look at some of the related threads on the mailing list: http://www.mail-archive.com/search?l=meep-discuss%40ab-initio.mit.eduq=NFS Best, Matt On Sun, 24 Jan 2010, Lingyun Wang wrote: I solved this issue from the help of one of the mail list members (I accidentally deleted his / her email). Since I installed both mpich2 and openmpi, meep-mpi gets confused. So I deleted both and then install only openmpi. But I found out openmpi still not work as supposed. The hdf5 file needs super long time to finish writing, the whole program just idle on that point without progress. So I switched back to mpich2, and compiled parallel hdf5. The same thing happened. Still stuck on the hdf5 file thing. The cluster works OK. It's NFS enabled mpich2 shared with two quad PC linked with Gbs ethernet (crossover cable linked). If I just run mpirun -np 8 uptime it just returns things perfectly. Ip information PC1: 192.168.2.x1 PC2: 192.168.2.x2 ssh nfs can both log on each other without password. If I run single node meep-mpi with -np 4, the hdf5 is happy with it. However this hdf5 thing bothers me a lot. In the meep installation part, it mentions the parallel HDF5 library then does not work with serial code. Does this mean I should use serial hdf5 library instead for this scenario? Thank you! ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Tilted beam source
Hi Andrew, There is an easier and more elegant way to do this using meep sources with non-point sizes (lines in 2d or surfaces in 3d). To make a line source in meep, you just specify the source to have some width (for periodic structures it is usually the lattice width). You then specify an amplitude function that varies along the line. See this thread: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg01270.html That thread discusses planewaves and not beams, but you can do the same thing and use your amplitude function instead. That saves you the trouble of making a loop and creating a large number of sources in the source list. Best, Matt On Mon, 16 Nov 2009, Andrew York wrote: I needed a tilted, pulsed beam in one of my meep simulations, and I noticed a few others on the mailing list have asked for something similar. I decided to make my tilted-beam source out of a bunch of point sources, and it seemed to work pretty well. Hopefully someone else finds this useful, or points out an improvement. Here is my code: (define-param pi 3.14159265) (define-param dpml 3.0) (define-param len (+ 20 dpml)) (define-param wid (+ 20 dpml)) (set! geometry-lattice (make lattice (size len wid no-size))) (define-param beam-waist 2.5) ; beam sigma (gaussian beam width) (define-param rotation-angle (* (/ 22.5 360) 2 pi)) ; Degrees if you like them (define-param source-points 60) ; should be a big number (define-param source-size (* 4 beam-waist)) ; should be bigger than beam-waist (define-param src_list (list )) (do (( r_0 (/ source-size -2) (+ r_0 (/ source-size (- source-points 1))) )) (( r_0 (/ source-size 2))) ;for r_0 = -source-size/2 : source-size/source-points : source-size/2 (set! src_list (append src_list (list (make source (src (make gaussian-src (wavelength 1) (width 3) )) (amplitude (exp (- 0 (/ (* r_0 r_0) (* 2 beam-waist beam-waist) (component Ez) (center (* r_0 (sin rotation-angle)) (* r_0 (cos rotation-angle))) )) )) ) (set! sources src_list) (set! pml-layers (list (make pml (thickness dpml) ))) (set! resolution 10) (use-output-directory) (run-until (* 2 len) (to-appended ez (at-every 0.1 output-efield-z)) ) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Tilted beam source
Hi Andrew, Excuse me - I misunderstood your problem. You are correct, meep only supports line sources that are parallel to the domain boundaries, and your solution is the only possibility for having a tilted beam in meep as of yet. The quotation you cite below is a different problem altogether - Steven is refering to simulations with periodic boundary conditions. There, you can't have broadband, oblique incidence simulations for a single incidence angle. The periodic boundaries force each plane wave to have a separate, unique incidence angle. Best, Matt On Mon, 16 Nov 2009, Andrew York wrote: I have used line sources to generate pulsed Gaussian beams, but encountered difficulty when I tried to use the same technique to generate a tilted pulsed Gaussian beam. The method I tried first, unsuccessfully, was similar to what you suggest. Perhaps I do not properly understand your suggestion? In the thread you link to, the source is a horizontal line, with an amplitude that varies as e^(2 pi i k_x x): (define (my-amp-func p)(exp (* 0+2i pi kx (vector3-x p which generates a nice tilted plane wave. The problem I encountered is that a tilted pulsed Gaussian beam contains many different spatial frequencies at a horizontal or vertical source plane, and so I was not sure I could get away with a variation like e^(i k_x x). Steven seems to mention the same problem here: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/229 Specifically: ...because the magnitude of k depends on the frequency, you can't make a single source that produces light with a single angle (other than normal incidence) over a broad bandwidth ... You need to use a narrow-bandwidth source, and do multiple simulations if you want a transmission spectrum at a given angle. (I don't notice too much slowdown from having ~60 point sources, so I think using a narrow-bandwidth source and multiple simulations would be much slower.) But perhaps I am missing the point of your suggestion? I know it's not your job to write my code, but if you felt like constructing code that produced a tilted, pulsed Gaussian beam from a single source, I would be very interested to see it. On Mon, Nov 16, 2009 at 8:17 AM, matt matth...@ifh.ee.ethz.ch wrote: Hi Andrew, There is an easier and more elegant way to do this using meep sources with non-point sizes (lines in 2d or surfaces in 3d). To make a line source in meep, you just specify the source to have some width (for periodic structures it is usually the lattice width). You then specify an amplitude function that varies along the line. See this thread: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg01270.html That thread discusses planewaves and not beams, but you can do the same thing and use your amplitude function instead. That saves you the trouble of making a loop and creating a large number of sources in the source list. Best, Matt On Mon, 16 Nov 2009, Andrew York wrote: I needed a tilted, pulsed beam in one of my meep simulations, and I noticed a few others on the mailing list have asked for something similar. I decided to make my tilted-beam source out of a bunch of point sources, and it seemed to work pretty well. Hopefully someone else finds this useful, or points out an improvement. Here is my code: (define-param pi 3.14159265) (define-param dpml 3.0) (define-param len (+ 20 dpml)) (define-param wid (+ 20 dpml)) (set! geometry-lattice (make lattice (size len wid no-size))) (define-param beam-waist 2.5) ; beam sigma (gaussian beam width) (define-param rotation-angle (* (/ 22.5 360) 2 pi)) ; Degrees if you like them (define-param source-points 60) ; should be a big number (define-param source-size (* 4 beam-waist)) ; should be bigger than beam-waist (define-param src_list (list )) (do (( r_0 (/ source-size -2) (+ r_0 (/ source-size (- source-points 1))) )) (( r_0 (/ source-size 2))) ;for r_0 = -source-size/2 : source-size/source-points : source-size/2 (set! src_list (append src_list (list (make source (src (make gaussian-src (wavelength 1) (width 3) )) (amplitude (exp (- 0 (/ (* r_0 r_0) (* 2 beam-waist beam-waist) (component Ez) (center (* r_0 (sin rotation-angle)) (* r_0 (cos rotation-angle))) )) )) ) (set! sources src_list) (set! pml-layers (list (make pml (thickness dpml) ))) (set! resolution 10) (use-output-directory) (run-until (* 2 len) (to-appended ez (at-every 0.1 output-efield-z)) ) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] what does lambda mean?
That's simply notation for defining a procedure or a function. Here's an example: meep (define square (lambda (x) (* x x))) meep (square 4) 16 In that example, square is a procedure that takes one argument, x, and returns (* x x). You can read more about lambda expressions here: http://www.gnu.org/software/guile/manual/guile.html#Lambda Best, Matt On Wed, 28 Oct 2009, liu wrote: Hi, I have seen the following ctl file, --- (define mysource (lambda (t) (sin (* 10 t (define cs (list (make source (src (make custom-src (src-func mysource) (start-time start) (end-time end))) (component Ez) (center 0 0) (size 0 0 --- My question is what does lambda(t) mean? does it mean that the source is with a single frequency with amplitude changing sin(10t)? ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Centre point of a cone geometry object!
For a cone with peak, the center you specify in meep is at half the altitude (line from the peak that perpendicularly bisects the base). For a cone with two radii, I don't remember, but I guess it's the halfway point between the two bases. It's easy to check! Just make a test geometry and look at the output. Best, Matt On Wed, 12 Aug 2009, asadollahbaik a. (aa306) wrote: Dear Meep users, Does anyone know where the centre point of a cone is?! I think it is obvious to figure out where is the centre point for a cylinder, sphere, block, ellipsoid, but where not the cone geometry object! Thanks, Asa Asa Asadollahbaik PhD Research Student Materials Research Group Room 2045, Building 25 University of Southampton Highfield Avenue Southampton SO17 1BJ Phone Number : +44 (0) 23 8059 8365 Where is my vote? In opposition to the rigged Presidential Election in Iran on 12th of June 2009; In support of my brothers and sisters in Iran who endured the worst to get their right; In sympathy to those families who lost a family member on Saturday 20th of June 2009 - The Black Saturday; In the memory of NEDAs, SOHRABs and YAGHOUBs!!! ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] bug report - incorrect dataset size
I have some follow-up info for this thread. The problem still exists, but here I describe a simple way around it. My hack for getting around this is to just place the same metal block in the no-scatterer simulation. I can get away with that because there's a PML on top. The no-scatterer run will still behave more or less as free-space propagation of plane waves because the pml prevents most of the fields from reaching the reflector. Works great, just a bit non-intuitive in the sense that your first impulse is to define an empty geometry for the no-scatterer run. One might ask why the scatterer runs have metal on the simulation boundary. I have a back scatterer (metal on the underside of a scatterer) with a special shape, so Metallic boundaries are insufficient. A large gap between this back scatterer and the simulation boundary is wasted computation, since no fields pass the back scatterer. A small between the back scatterer and the domain boundary gap leads to some instabilities (which I can't explain very well). Zero gap wasn't possible because rounding/gridding errors shift the back scatterer such that either a small gap exists, or the scatter wraps up across the lattice boundary, causing the problems I've described. Maybe it's a useful description for someone :) Kind Regards, Matt On Wed, 10 Jun 2009, matt wrote: Yes, load-minus flux is from a simulation with exactly the same grid size and flux-plane size. The boundary conditions don't change in the scatterer run (k-point is set to the same vector, and there is no different call to meep-fields-set-boundary). What does change is that in the scatterer run a block of metal is placed on top of one of the lattice boundaries. Best, Matt On Wed, 10 Jun 2009, Steven G. Johnson wrote: On Jun 10, 2009, at 8:33 AM, matt wrote: When this happens however, the load-minus-flux fails with the following error: meep: incorrect dataset size (48000 vs. 96000) in load_dft_hdf5 ./test2-refl-flux_noscat_sim_0deg_75res_Hz.h5:ez_dft load-minus-flux has to be from a simulation with exactly the same grid size and flux-plane size. Did you change any of these details between your two calculations? Did you change the boundary conditions? ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] bug report - incorrect dataset size
Hello, I discovered a rather strange behavior in meep. I'm running some scattering simulations for a grating with a back-scatterer (PEC backing). I specify the back scatterer manually (instead of only setting a Metallic boundary condition) because it has a odd shape. Because of what I assume are rounding errors, the scatterer defined at the bottom of the domain wraps to the top of the domain. This is okay because I have a PML at the top. When this happens however, the load-minus-flux fails with the following error: meep: incorrect dataset size (48000 vs. 96000) in load_dft_hdf5 ./test2-refl-flux_noscat_sim_0deg_75res_Hz.h5:ez_dft This doesn't happen if I change the scatterer from metal to something else. I thought the problem might be whether meep is using complex fields, but forcing complex fields in the no-scatter run doesn't solve the problem. Here I have a minimal script that duplicates the problem: http://pastebin.com/f168203b6 I'm using meep version 1.0. Best, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] bug report - incorrect dataset size
Yes, load-minus flux is from a simulation with exactly the same grid size and flux-plane size. The boundary conditions don't change in the scatterer run (k-point is set to the same vector, and there is no different call to meep-fields-set-boundary). What does change is that in the scatterer run a block of metal is placed on top of one of the lattice boundaries. Best, Matt On Wed, 10 Jun 2009, Steven G. Johnson wrote: On Jun 10, 2009, at 8:33 AM, matt wrote: When this happens however, the load-minus-flux fails with the following error: meep: incorrect dataset size (48000 vs. 96000) in load_dft_hdf5 ./test2-refl-flux_noscat_sim_0deg_75res_Hz.h5:ez_dft load-minus-flux has to be from a simulation with exactly the same grid size and flux-plane size. Did you change any of these details between your two calculations? Did you change the boundary conditions? ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] subpixel averaging and dispersion
Thanks for your explanation. Just to clarify, could you elaborate as to why the convergence is first order with dispersion, but second order otherwise? In a test case where I have an analytic result (lossy slabs), I've found the covergence leaves room for wanting. Is there anything besides the resolution which might cause a very slight shift in frequency? The analytic result is a frequency domain method, using the same lorentz model for the perimittivities as the one I input into meep. Best Regards, Matt On Fri, 29 May 2009, Steven G. Johnson wrote: On May 29, 2009, at 11:55 AM, matt wrote: I was wondering how well eps-averaging works when the materials are defined as lossy. I guess that meep is basing it's averaging on eps_inf and not on the full complex permittivities. Is that correct? If so, what does it mean to have eps-averaging enabled with lossy materials present? Correct, Meep currently only does subpixel averaging of the nondispersive part of epsilon (and mu). The dispersive part is not averaged at all. This means that any sharp interfaces between dispersive materials will dominate the error, and you will probably get only first-order convergence, the same as if you do no no subpixel averaging at all. It's possible that the subpixel averaging may still improve the constant factor in the convergence if not the asymptotic convergence rate, if you also have a lot of interfaces between nondispersive materials or if the dispersion is small (i.e. if epsilon is close to \epsilon_\infty over your bandwidth). On the other hand, if the dispersion is large and most of your interfaces are between large-dispersion materials, then subpixel averaging may not help at all and you might as well turn it off. The subpixel averaging shouldn't hurt you, though, except possibly in performance. Steven ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] subpixel averaging and dispersion
Hello, I was wondering how well eps-averaging works when the materials are defined as lossy. I guess that meep is basing it's averaging on eps_inf and not on the full complex permittivities. Is that correct? If so, what does it mean to have eps-averaging enabled with lossy materials present? Kind Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] Polarization losses
Hello, I'm interested in simulating the absorption rate for some materials as discussed in the wiki page 'Materials in Meep'. There, it's stated with respect to the absorption rate dP/dt . E that Meep can keep track of this energy for the Lorentzian polarizability terms (but not for the conductivity terms), which for gain gives the amount of energy expended in amplifying the field. In the wiki Reference page however, I didn't find any indication of how to access the absorption rate or the Polarization field P. I also checked the mailing list but didn't find a relevant example. Is this possible, and are there any examples available of how to do this? Kind Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Meep-mpi installation help
Hi Andrew, Check this thread regarding the guile-config error: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00185.html I don't believe there are packages available for the latest meep version. Best, Matt On Fri, 15 May 2009, Andrew Galdes wrote: Hello all, I would like some assistance with installing the MPI version of Meep. The serial version configures and compiles fine but with the --with-mpi option the configure fails: Using Intel compiler with OpenMPI. ./configure prefix=/opt/shared/meep/1.0 --with-mpi ... checking for deflate in -lz... yes checking for H5Pcreate in -lhdf5... yes checking hdf5.h usability... yes checking hdf5.h presence... yes checking for hdf5.h... yes checking for H5Pset_mpi... no checking for H5Pset_fapl_mpio... no Looks like we have got 8 processors checking for guile-config... yes checking if linking to guile works... no configure: error: guile-config is broken System info: SLES 10, 64bit, Kernel 2.6.16.46-0.12-smp RPM guile packages installed: guile-1.8.1-72 guile-devel-1.8.1-72 Guile config version: guile-config - Guile version 1.8.1 Any help is appreciated. Also does anyone have an RPM of 64bit binaries for meep-mpi, or know where to get it? -Andrew G ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] frequency scaling in reflection spectrum
One thing I'm having trouble understanding is why this frequency scaling isn't visible in the libctl transmission coefficient output. Is there something special the meep flux computation does to repair the frequency scaling caused by the gaussian-derivative source? Kind Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] (no subject)
Hi, Have a look at this thread: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00412.html Best, Matt On Mon, 2 Feb 2009, Sivan, Yonatan wrote: Hi Meep users, I am relatively new to meep. Could anyone show me how to employ the perfect-electric-conductor/ perfect-magnetic-conductor/metal boundary condition in meep? I could not find an example in the meep-examples and everything I tried seems to have the wrong syntax. Thanks, Yonatan. ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] bug in interpolate procedure
This is caused by floating point arithmetic. Have a look at this thread: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00978.html Best, Matt On Fri, 30 Jan 2009, Antoine Monmayrant wrote: Hi everyone, I think I found something fishy with the procedure interpolate. It seems there is a rounding bug somewhere: meep (interpolate 9 (list 0.5 0)) (0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0) which is what I expected. However, if I interpolate the other way round I get this: meep (interpolate 9 (list 0 0.5)) (0 0.0501 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5) which is not exactly what I wanted. I don't get why I have this 0.0501 instead of 0.05. Did anyone come across this bug? Any fix for it? Cheers, Antoine ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] frequency scaling in reflection spectrum
Hello, To compute transmission spectra, I recently tried two approaches that came to two different results. The first approach is the standard way using flux planes as given in the meep examples on the webpage. In the second approach, I store the time data for points in a plane in front of the scatterer. I also do the same for a free space simulation. Then, using MATLAB, I analyze the transforms of the time data as follows: - Matlab snippet fstart = 195 * 1e12 / 3e8 / 1e6; % convert to meep units fstop = 330 * 1e12 / 3e8 / 1e6; % convert to meep units fcen = (fstart + fstop)/2; samplerate = 1/fcen/50; % field sampled at this rate in at-every dt = samplerate*1e-6/3e8;% convert time back into physical units % the following data comes from h5 files outputted by meep EN = fft(noscat_ez); % Ez values along plane without scatterer ES = fft(scat_ez); % Ez values along plane with scatterer HN = fft(noscat_hx); % Hx values along plane without scatterer HS = fft(scat_hx); % Hx values along plane with scatterer POWS = real( sum(conj(ES - EN) .* (HS - HN) , 2)); % Scattered power POWN = real( sum(conj(EN) .* HN , 2)); % Incident power POW = POWS ./ POWN; % Reflectivity f = (1/dt)/2*linspace(0,1,length(ES)/2+1); plot(f,-POW(1:floor(length(POW)/2+1)),'k'); - The attached plot shows a comparison of the two reflection spectra. There is an strong frequency shifting/scaling present. This is unrelated to the resolution of the simulation. This may be related to a previous unresolved discussion: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg02073.html http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00456.html Previously Prof. Johnson wrote When the pulse is this wide (in frequency), you can observe a computational detail: Meep's Gaussian pulse is not actually precisely a Guassian, it is the derivative of a Gaussian (this ensures that there is no net charge left in the computational cell after the pulse is gone, which prevents divergences in some cases with periodic boundaries). The difference between the two is small except for very broad Gaussians in frequency (short pulses in time). Because the main reason to use a short pulse is to get a broad-spectrum response, and you have to normalize such a response by the input spectrum anyway as explained in the manual, the exact shape of the spectrum shouldn't actually matter. As we can see in my example above, the normalization doesn't cure the problems caused by a shifting in the spectra (at least not in my matlab processing of the time data). I'm not sure if this is a bug in meep or if there's something I don't understand in the processing of the time data. Best Regards, Matt e2.png Description: Binary data ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] make check fails on h5test with lam-mpi
Hi Zheng,
Steven's fix works for me as well. I thought my problem was somehow
different because the failure mode appeared different, but this may just
be a difference between mpich and lam-mpi.
Just a very minor note for others; there is a missing right parenthesis
in http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg02231.html
that is, it should be
if (IF_EXCLUSIVE(am_master(), parallel || am_master())) {
not
if (IF_EXCLUSIVE(am_master(), parallel || am_master()) {
Best,
Matt
Hi, matt
H5Tset_size() in h5file::read or h5file::write throws out an error. We
may meet the same bug.
Read
http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg02205.html
for details.
Zheng
2008-12-7
___
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] make check fails on h5test with lam-mpi
When I run make check, on the test h5test, one of the processes shuts down, consistently. I have an ubuntu package install of lam-mpi as well as h5utils, and am compiling meep-mpi 0.20.3 manually. The repository packages installed are libhdf5-lam-1.6.5-0, libhdf5-lam-dev, liblam4, and lam4-dev. config.log doesn't show any clues. the configure command I used was ./configure CXX=mpic++ --prefix=/home/matthewm/usr --with-mpi --with-libctl=/home/matthewm/usr/share/libctl --with-blas=/usr/lib/libblas.so.3 --with-lapack=/usr/lib/liblapack.so.3 LDFLAGS=-L/usr/local/lib -L/home/matthewm/usr/lib CPPFLAGS=-I/usr/include -I/usr/include/mpi -I/home/matthewm/usr/include LD_LIBRARY_PATH=/usr/lib:/home/matthewm/usr/lib make check output: mpic++ -DHAVE_CONFIG_H -I. -I.. -I../src -I/usr/include -I/usr/include/mpi -I/home/matthewm/usr/include-O2 -MT h5test.o -MD -MP -MF .deps/h5test.Tpo -c -o h5test.o h5test.cpp mv -f .deps/h5test.Tpo .deps/h5test.Po /bin/bash ../libtool --tag=CXX --mode=link mpic++ -O2 -L/usr/local/lib -L/home/matthewm/usr/lib -o h5test.dac h5test.o ../src/libmeep_mpi.la -lhdf5 -lz -lgsl -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../.. -lharminv -llapack -lblas -lgfortranbegin -lgfortran -lm -lgcc_s -lfftw3 -lm mpic++ -O2 -o h5test.dac h5test.o -L/usr/local/lib -L/home/matthewm/usr/lib ../src/.libs/libmeep_mpi.a -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../.. -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6/../../../../lib -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6/../../.. /usr/lib/libhdf5.so -lpthread -lz -lgsl /home/matthewm/usr/lib/libharminv.a -L/lib/../lib -L/usr/lib/../lib -lfrtbegin /usr/lib/libg2c.so -llapack -lblas -lgfortranbegin -lgfortran -lgcc_s /usr/lib/libfftw3.so -lm mpirun -np 4 ./h5test.dac Using MPI version 1.2, 4 processes Checking check_2d_tm_identity_0_plane_eps_r... MPI_File_set_size: size argument must be the same on all processes MPI_File_set_size: size argument must be the same on all processes MPI_File_set_size: size argument must be the same on all processes HDF5: infinite loop closing library D,G,S,T,G,F,F,AC,FD,P,D,F,FD,P,FD,P,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD - One of the processes started by mpirun has exited with a nonzero exit code. This typically indicates that the process finished in error. If your process did not finish in error, be sure to include a return 0 or exit(0) in your C code before exiting the application. PID 18986 failed on node n0 (127.0.0.1) with exit status 1. - HDF5: infinite loop closing library D,G,S,T,G,F,F,AC,FD,P,D,F,FD,P,FD,P,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD HDF5: infinite loop closing library D,G,S,T,G,F,F,AC,FD,P,D,F,FD,P,FD,P,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD HDF5: infinite loop closing library D,G,S,T,G,F,F,AC,FD,P,D,F,FD,P,FD,P,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD,FD make[2]: *** [h5test.done] Error 1 ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Cause of wavelength shifts in Meep?
When you have a normalization run and a scatter run, the pulse is shifted in both simulations. The peak is shifted in both. It doesn't matter where the peak is because at each frequency you're only looking at the power/fields relative to the normalization run. This comparison will be correct no matter where the peak is. For a single run simulation however, the location of the peak is important. I think what you could do is run an empty simulation with no resonator in order to determine how large the shift is. You could then correct your results by this shift. It's a nonideal solution because it wastes a simulation. Be careful though - I'm not sure if the pulse gets shifted in frequency or if it is actually _stretched_ in frequency. Maybe someone who knows more could weigh in. Best, Matt On Sun, 28 Sep 2008, Andreas Francke wrote: Hi Matt, thanks for your answer. Let me answer personally since apparently I'm the only one who does not get the point here. You are right, indeed I didn't use the normalization suggested in the manual (divide by the incident power at each frequency to get the transmission spectrum, once with only the incident wave and no scattering structure, and once with the scattering structure, where the first calculation is used for normalization), but compared the flux between an input- and an output-port in the same structure during a single run. I understand that this is possibly a less precise determination of the power transmission, but it works to a certain degree. Anyway, I don't see why the normalization suggested in the manual should also correct for the wavelength shift? As I understand it corrects only over the power (of the resonance peaks, in my case). Whereas I need to simulate as realistically as possible not only the transmitted power but also the precise resonance positions (over a bandwidth of 0.1 centered on a normalized frequency 0.65, i.e. about 100 nm centered on 1550 nm). Therefore, true is that the shape of the spectrum doesn't matter for transmitted power, but the resonances will be shifted nevertheless. Or not? Best, Andreas. --- Sab 27/9/08, matt [EMAIL PROTECTED] ha scritto: Da: matt [EMAIL PROTECTED] Oggetto: Re: [Meep-discuss] Cause of wavelength shifts in Meep? A: Andreas Francke [EMAIL PROTECTED] Cc: meep-discuss@ab-initio.mit.edu Data: Sabato 27 settembre 2008, 17:47 Hi Andreas, If your source is very narrow band, does the shift reduce to zero? I was having a similar problem: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg02073.html Steven explained in a different thread why this is the case in meep: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00456.html His argument is that broadband simulations are only used for transfer responses where you normalize results, so it doesn't matter if the pulse has a shift (or isn't even really gaussian). In your case you don't have normalization. You just set off a pulse in your cavity and measure the resonances. If I understand correctly, the only way around the problem would be to run several narrowband simulations (this defeats the benefit of a time domain simulation). I would much rather prefer it if the gaussian sources of meep behaved the way one would expect them to, but this seems to cause some stability issues. Kind Regards, Matt On Sat, 27 Sep 2008, Andreas Francke wrote: Dear Steven and list, I'm simulating with Meep resonant cavities like add-drop ring and disk resonators and obtain the resonant spectrum with the flux function or harminv. Everything seems fine except that I noticed how the spectrum is always red or blue shifted relative to the source spectrum (i.e., using a Gaussian input pulse, the Gaussian profile of the output resonant spectrum is clearly shifted). It looks like that the the bandwidth of the source determines the output resonant peak positions (while, except for fwidth df, all the code remains unchanged): larger source bandwidth returns the same (or negligibly altered) FSR but with the spectrum profile largely red-shift, even of dozens of nm on a 1500 nm center source wavelength. The dimension of the cell seems to have a similar effect: in order to accomodate two cavities, doubling the cell size, leads to a double redshift. Moreover, I noticed that at some point when the refractive index is set beyond a threshold (say between 3.2 and 3.3 in my case) suddenly the spectrum is split, i.e. one sees two Gaussian spectra, one blue- the other red-shifted abruptly in an even more unpredictable manner. Working with higher resolution or simulation times won't change much the situation. I'm confused. I'm certainly missing something important here, but I can't give myself an explanation of this. Is it a numerical effect or is there some obvious physical explanation? Can anybody help? Andreas
Re: [Meep-discuss] Cause of wavelength shifts in Meep?
Hi Andreas, If your source is very narrow band, does the shift reduce to zero? I was having a similar problem: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg02073.html Steven explained in a different thread why this is the case in meep: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00456.html His argument is that broadband simulations are only used for transfer responses where you normalize results, so it doesn't matter if the pulse has a shift (or isn't even really gaussian). In your case you don't have normalization. You just set off a pulse in your cavity and measure the resonances. If I understand correctly, the only way around the problem would be to run several narrowband simulations (this defeats the benefit of a time domain simulation). I would much rather prefer it if the gaussian sources of meep behaved the way one would expect them to, but this seems to cause some stability issues. Kind Regards, Matt On Sat, 27 Sep 2008, Andreas Francke wrote: Dear Steven and list, I'm simulating with Meep resonant cavities like add-drop ring and disk resonators and obtain the resonant spectrum with the flux function or harminv. Everything seems fine except that I noticed how the spectrum is always red or blue shifted relative to the source spectrum (i.e., using a Gaussian input pulse, the Gaussian profile of the output resonant spectrum is clearly shifted). It looks like that the the bandwidth of the source determines the output resonant peak positions (while, except for fwidth df, all the code remains unchanged): larger source bandwidth returns the same (or negligibly altered) FSR but with the spectrum profile largely red-shift, even of dozens of nm on a 1500 nm center source wavelength. The dimension of the cell seems to have a similar effect: in order to accomodate two cavities, doubling the cell size, leads to a double redshift. Moreover, I noticed that at some point when the refractive index is set beyond a threshold (say between 3.2 and 3.3 in my case) suddenly the spectrum is split, i.e. one sees two Gaussian spectra, one blue- the other red-shifted abruptly in an even more unpredictable manner. Working with higher resolution or simulation times won't change much the situation. I'm confused. I'm certainly missing something important here, but I can't give myself an explanation of this. Is it a numerical effect or is there some obvious physical explanation? Can anybody help? Andreas. ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] shift in fft of meep data
I determined that the shift is somehow related to the bandwidth of my pulse. If I make the source very narrowband (170 to 190 THz), the FFT from Matlab ends up in the correct position. This may be related to a previous thread: http://ab-initio.mit.edu/pipermail/meep-discuss/2006-October/000463.html Best, Matt On Wed, 3 Sep 2008, Steven G. Johnson wrote: On Sep 3, 2008, at 1:19 PM, matt wrote: I'm pretty certain that the matlab script is correct. Is there something in meep which could be causing the frequency shift? No, I can't think of anything in Meep that could cause a frequency shift of that sort, assuming all your units are consistent and correct. However, your Matlab script is slightly off. The number of data points from the DC frequency to the Nyquist frequency, inclusive, is NFFT/2+1, not NFFT/2. So, you should have: f = (1/dt)/2*linspace(0,1,NFFT/2+1); y=plot(f,2*abs(A(1:NFFT/2+1))); if I'm reading your code correctly. (The DC frequency is bin 0 of the DFT, and Nyquist is the N/2-th bin, but because Matlab's indices are 1-based these become 1 and N/2+1, respectively.) Regards, Steven G. Johnson ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] shift in fft of meep data
I have a simple gaussian line source between 60 and 300 THz launched
into vacuum. I save the field data in an X slice at each time step,
then import the data for a point of the slice into matlab.
I then plot the FFT of the data, and find that the center frequency is
not 180 THz, but something a bit higher (188 THz).
I'm pretty certain that the matlab script is correct. Is there
something in meep which could be causing the frequency shift?
Kind Regards,
Matt
complete meep script: http://pastebin.com/f40f6a200
matlab fft script:
file = hdf5info('pulsetest2-refl-slice.noscat.h5');
refl_noscat = hdf5read(file.GroupHierarchy.Datasets);
file = hdf5info('pulsetest2-trans-slice.noscat.h5');
trans_noscat = hdf5read(file.GroupHierarchy.Datasets);
a = refl_noscat(:,2);
L = length(a);
c = 299792458;
dt = (1/80)*1e-6/c;
NFFT = 2^nextpow2(L); % Next power of 2 from length of data
A = fft(a,NFFT)/L;
f = (1/dt)/2*linspace(0,1,NFFT/2);
y=plot(f,2*abs(A(1:NFFT/2)));
grid on;
line([180e12 180e12],[0 0.05]); % line representing center freq
axis([0 400e12 0 0.05]);
___
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] problem with h5util
For some reason, the ubuntu version of h5utils provided with apt-get install h5utils does not have internally consistent paths/libraries for the colormaps. A temporary solution is the following: To convert the file foo.h5 into foo.png with colormap foomap h5topng -c /user/share/h5utils/colormaps/foomap foo.h5 This is ugly, but it works, and you can go about your work. You could make an alias or script to wrap this up nicely, but I'll check my own computer for config files to see if there's a more elegant solution. Note: This thread is essentially a duplication of http://ab-initio.mit.edu/pipermail/meep-discuss/2008-August/002052.html to which I've posted the same reply. Matt On Tue, Aug 26, 2008 at 5:01 AM, andika asyuda [EMAIL PROTECTED]wrote: good night meep user. my name is andika asyuda I have a question about h5util for ubuntu Recently, I just reinstalled my ubuntu and all my software. I found something strange about h5util, because there is something wrong with command h5topng and h5read command h5topng is followed with this statement: could not find colormap gray command h5read is followed with this statement : command not found there are nothing wrong with other commands this far What is going on with my h5util? I hope someone can figure out some thing. Thank you for the help with regard Andika Asyuda -- Be a better friend, newshound, and know-it-all with Yahoo! Mobilehttp://mobile.yahoo.com/. Try it now.http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20 ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] problem with h5util
Sorry, I made a mistake. The directory for the colormaps should be /usr/share/h5utils/colormaps, whereas I typed /user/share/... The command is then h5topng -c /usr/share/h5utils/colormaps/foomap foo.h5 On Tue, Aug 26, 2008 at 8:28 AM, Matt Eichenfield [EMAIL PROTECTED] wrote: For some reason, the ubuntu version of h5utils provided with apt-get install h5utils does not have internally consistent paths/libraries for the colormaps. A temporary solution is the following: To convert the file foo.h5 into foo.png with colormap foomap h5topng -c /user/share/h5utils/colormaps/ foomap foo.h5 This is ugly, but it works, and you can go about your work. You could make an alias or script to wrap this up nicely, but I'll check my own computer for config files to see if there's a more elegant solution. Note: This thread is essentially a duplication of http://ab-initio.mit.edu/pipermail/meep-discuss/2008-August/002052.html to which I've posted the same reply. Matt On Tue, Aug 26, 2008 at 5:01 AM, andika asyuda [EMAIL PROTECTED]wrote: good night meep user. my name is andika asyuda I have a question about h5util for ubuntu Recently, I just reinstalled my ubuntu and all my software. I found something strange about h5util, because there is something wrong with command h5topng and h5read command h5topng is followed with this statement: could not find colormap gray command h5read is followed with this statement : command not found there are nothing wrong with other commands this far What is going on with my h5util? I hope someone can figure out some thing. Thank you for the help with regard Andika Asyuda -- Be a better friend, newshound, and know-it-all with Yahoo! Mobilehttp://mobile.yahoo.com/. Try it now.http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20 ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] All colormaps missing for h5topng
For some reason, the ubuntu version of h5utils provided with apt-get install h5utils does not have internally consistent paths/libraries for the colormaps. A temporary solution is the following: To convert the file foo.h5 into foo.png with colormap foomap h5topng -c /usr/share/h5utils/colormaps/foomap foo.h5 This is ugly, but it works, and you can go about your work. You could make an alias or script to wrap this up nicely, but I'll check my own computer for config files to see if there's a more elegant solution. Note: This thread is essentially a duplication of http://ab-initio.mit.edu/pipermail/meep-discuss/2008-August/002067.html http://ab-initio.mit.edu/pipermail/meep-discuss/2008-August/002052.html to which I've posted the same reply. Matt On Wed, Aug 20, 2008 at 7:45 PM, Matt Eichenfield [EMAIL PROTECTED] wrote: To whom it may concern: I have seen that h5utils version 1.11.1 fixes a bug in version 1.11 wherein the program fails to find colormaps in h5topng. However, I am having the same problem using h5utils version 1.10-7ubuntu1, which I'm assuming is h5utils version 1.10. I got this version using apt-get install h5utils on August 20, 2008. Here are a couple examples of errors: $ h5topng -RZc dkbluered -C ring-eps-00.00.h5 ring-ez-*.h5 Could not find colormap dkbluered $ h5topng -R -C ring-eps-00.00.h5 ring-ez-*.h5 Could not find colormap gray Should I just remove h5utils using apt-get and manually install version 1.11? Is this a known issue in versions earlier than 1.11 as well? Thanks, Matt Eichenfield ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] k-vector selective detector
Hi Neal, Thanks for your explanation. If I understood correctly, the spatial FFT will give me an intensity as a function of k-vector (or angle), for a given wavelength. How do I then extract transmission and reflection spectra? Can these be separated into the contributions from each diffracted mode? Kind Regards, Matt On Wed, 20 Aug 2008, neal skinner wrote: Matt, Since you are asking about diffracted orders, I assume you are talking about a periodic structure. The concept of the spatial Fourier transform comes from a branch of optical science called Fourier Optics. One of the few textbooks I know of on the subject is *Introduction to Fourier Optics* by Joseph Goodman. The usual FT converts a time varying signal into a spectrum in the frequency domain. A spatial FT transforms a spatially varying signal or image at a plane into a spectrum of plane waves traveling in different directions or k vectors. If your image or wavefront at the reference plane is two dimension, then you need to compute a 2 dimensional spatial Fourier transform. If I was going to try this, I would use Taflove's method to compute the temporal FFT at each and every point in the unit cell. Then at each temporal frequency (wavelength), I would compute the 2 dimensional spatial FFT across the entire unit cell to give the diffraction pattern at each wavelength. You can use Matlab to compute 2-d FFTs that could be converted into spatial frequencies. I was actually thinking about this and going to try it a while back for frequency selective surfaces, but never got the time. I'm not sure if the new version of MEEP does FT's or not. If it does, it would save some work. I am sorry if this sound complicated, I guess it is, but I hope this helps. Good luck and Best regards, Neal ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Meep:no match
you need to put a \ in front of ? in the shell command line, like this: ~ meep a\?=true file.ctl That will get rid of the second error. On Mon, 18 Aug 2008, asadollahbaik a. (aa306) wrote: Dear Meep users. I am doing the transmission and reflection simulation for a pattern consisting of randomly oriented hexagonal lattices of dielectric rods in air. Following the example of transmission and reflection calculation in Meep homepage, the simulation has to be performed twice: once when there is no structure in between the source and monitors and the other when the structure is at the right place between the trans and refl monitors. My problem is with making this if bit to work. The command I am using is based on the structure below: (if a? (b=1) (b=0) ) a? would be the condition confiming the existence of the structure (when set to true) or the absence of the structure (when set to false), B=1 is the commands of making the structure ( set! Geometry ...) And b=0 sets the empty geometry (set! Geometry '() ) Unfortunately this does not work. It just works when I do not specify a? which would consider the default condition (a?=false). When I say for example a?=true I get the error : ERROR: Wrong type to apply: #unspecified Or Meep:no match when I use the university cluster. I need to use the if-command in this way because I have a very complicated geometry definition file. I guess my problem is more a scheme problem rather than a meep problem. (I am not a computer programmer). I really appreciate your help, Regards, Asa, Asa Asadollahbaik PhD Research Student Room 2045, Building 25 University of Southampton Highfield Avenue Southampton SO17 1BJ Phone Number : 023 8059 8365 ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] ask for your help
Hi Ryan, I can only offer some quick advice. First, I think you should try to take the time to really understand what you're trying before you run a simulation. Following the mailing list advice blindly won't help you get farther. You want to calculate the scattering of a 3D crystal slab. Your slab is oriented in the XY plane, and propagation is in Z dimension. What I think you want to try is to truncate your computation domain in the Z dimension using PML layers. This creates the illusion that you have infinite half spaces for waves to propagate in the +Z and -Z directions, without having to actually simulate all that space. Next, because your structure is an infinite and periodic slab plane, you can truncate the compuation domain in the X and Y dimensions using periodic boundary conditions. To do this, you have to choose a unit cell which will correspond to your periodicity. With your hexagonal lattice, this could correspond to a circle in the center of your cell, plus four quarter-circles in the corners, for example. In summary, PML in Z direction, periodicity in X and Y. For the latter you will want (set-param k-point (vector3 kx ky 0)), with kx equal to 1/sx, and ky equal to 1/sy. You can investigate whether your simulation is setup correctly by visualizing the epsilon function. Your unit cell should like it could tessellate into your full slab. Best, Matt On Tue, 12 Aug 2008, Ryan Hao wrote: Hi, Matt, Sorry to trouble you, but I really need to work out this problem (I am in big pressure, my supervisor is hurry for my results everyday). My assignment is simple: Incident a pulse in to 3D photonic crystals slab, use 3D FDTD method to calculate the zodd transmission spectrum. My structure is shown in pic1~3. + +++++ |y + ++++ | + +++++ |___X I was confused by Prof. Johnson, maybe I was too stupid: At first, I did not use Periodic Boundary Condition in my structure, he told me to use Periodic Boundary Condition in Y direction, add PML in X and Z directions On 07/08/2008, Steven G. Johnson [EMAIL PROTECTED] wrote: From a quick look at your structure, I would make two suggestions: First, if you want the transmission along a particular direction in the slab, your computational cell should be periodic in the direction perpendicular to the wave propagation. e.g. in your .ctl file the light is propagating in the x direction, your cell should be periodic in the y direction (no PML in y, only in x and z), and be only one period thick in the y direction. That will make your calculations a lot faster! More importantly, it will mean that your incident light (if your source is one period wide in the y direction) will correspond to a specific incident angle. But yesterday he told me that I should only apply the Periodic Boundary Condition in X direction (the light propagate direction) On 12/08/2008, Steven G. Johnson [EMAIL PROTECTED] wrote: If I recall correctly, only your X direction does not have PML. In that case only the X component of k matters; the k component is set by what direction you want your incident wave to come from. For normal- incident light, kx=0. Now I really confused whether to add Periodic Boundary Condition in Y direction or not. For my understanding, I should not add periodic boundary in y direction in my structure, because the fields in the Y direction will decay and will not periodically repeat (though the structure are periodically repeat) Mr. Matt, please understand, I should finish the job in June, I am in big pressure every day. Further more, there must be other mistakes in my CTL file. Please, could you please so kind to have a look of the attached CTL files, and if possible, correct or point out the possible mistakes? (I attached both CTL with and without periodic boundary ) I will great appreciate for your kind help~ -- == Sincerely Yours, Ryan Hao PhD candidate Wuhan National Laboratory for Optoelectronics College of Optoelectronic Science and Engineering, Huazhong University of Science Technology, Wuhan, 430074, P.R.CHINA Phone: 86-027-87792242-809(O) Website: http://www.wnlo.net/spm/People_Ryan_Hao.html http://wnlo.hust.edu.cn/spm/People_Group.html ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Two questions about the example holey waveguide in MEEP manual
Ryan, See this message for an example: http://osdir.com/ml/science.electromagnetism.meep.general/2007-12/msg00023.html In 3D, you would also add pml in the Z direction. Best, Matt On Tue, 12 Aug 2008, Ryan Hao wrote: Dear Professor, Sorry, the error message is Unbound variable: k-point. Could you please so kind to give an example for just specify one direction periodical, and other directions PML? Ryan hao On 12/08/2008, Ryan Hao [EMAIL PROTECTED] wrote: 2008/8/12 Steven G. Johnson [EMAIL PROTECTED] On Aug 11, 2008, at 7:58 AM, Ryan Hao wrote: If I only want the period in Y direction: (set-param! k-point (vector3 0 0 0)) ; firstly set the X,Y,Z directions into periodic boundary, because I saw many people do this in this mail list (set! pml-layers (list (make pml (direction X)(thickness dpml)) (make pml (direction Z)(thickness dpml)) )) ; secondly change the X,Z directions into PML The second line doesn't change the X and Z directions into PML. You are have the common misunderstanding that PML has something to do with the boundary condition. It doesn't. PML is not a boundary condition. You can use PML with any boundary condition, including periodic. What the second line does is to specify that the periodic X and Z directions have PML absorbing layers adjacent to those periodic boundaries. (Those directions are still periodic but the periodicity is irrelevant because waves are absorbed before they propagate back into the interior of the cell around the periodic boundaries.) When I do this, MEEP trace an error: infinite period for set- param! k-point Are you sure that is the *exact* error message? I searched through the source code of Meep, libctl, and Guile, and found no instances of the words infinite period, so I don't see how that error message could have been generated. Regards, Steven G. Johnson ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss -- == Sincerely Yours, Ryan Hao PhD candidate Wuhan National Laboratory for Optoelectronics College of Optoelectronic Science and Engineering, Huazhong University of Science Technology, Wuhan, 430074, P.R.CHINA Phone: 86-027-87792242-809(O) Website: http://www.wnlo.net/spm/People_Ryan_Hao.html http://wnlo.hust.edu.cn/spm/People_Group.html ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Using perfect metal in C++ interface
You can use this method, defined in polarization.cpp: structure::add_polarizability(double sigma(const vec ), double omega, double gamma, double delta_epsilon, double energy_saturation); There are some examples available in tests/known_results.cpp and tests/symmetry.cpp. On Tue, 5 Aug 2008, Jefferson Thomas wrote: Thank you all. It works. Could I also ask how to implement in C++ interface the dispersive materials like those described in http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial/Material_dispersion ? Thomas Jefferson 2008/8/5 Steven G. Johnson [EMAIL PROTECTED]: On Aug 4, 2008, at 4:42 PM, matt wrote: Return a value from your eps function which is large and negative. -1e20 should work. Or better yet, -HUGE_VAL (which is defined in math.h, and should give - Inf). Steven ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Using perfect metal in C++ interface
Could you explain how PEC is implemented exactly? Is the large, negative epsilon a Maxwellian interpretation of a PEC (if so, how?) or is there some hard-coded check in the code which sets the fields to zero if the epsilon is less than some value (if so, where in the code?) Some unrelated side questions - What does the second argument m refer to here?: fields::fields(structure *s, double m, bool store_pol_energy) : S(s-S), v(s-v), user_volume(s-user_volume), gv(s-gv), m(m) Also, is it correct that the subdirectory hsrc is now vestigial? On Mon, 4 Aug 2008, Steven G. Johnson wrote: On Aug 4, 2008, at 4:42 PM, matt wrote: Return a value from your eps function which is large and negative. -1e20 should work. Or better yet, -HUGE_VAL (which is defined in math.h, and should give - Inf). Steven ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Reflection calculation
Start off by making sure your flux planes are at least a wavelength (the longest one) away from the source plane or PML. Also make sure that the flux planes are a wavelength away from the scatterer. Make sure your PML is thick enough (one wavelength is safe). If your structure is very resonant, it can trap energy and lead to strange scattering values as well. Make sure you let the simulation run long enough by using the stop-when-fields-decayed feature. It may also help to use a more narrowband excitation. Hopefully that corrects it for you. If the simulation time becomes too long, you can try to gradually reduce all of those distances until the point where those errors become significant. Best, Matt On Tue, 5 Aug 2008, Minh Nguyen Huu wrote: Hi, I've ran into a strange problem when trying to calculate the reflection spectrum of the structure I'm trying to simulate. What I find is that for some frequencies the calculated values (after the second run with the reflector) are positive. The script I made is just a modified version of the script found on the website. If anybody ever ran into this problem or can direct me to an email where this problem has already been discussed, I would be very grateful. Kind regards, Minh _ Jouw nieuws en entertainment, vind je op MSN.nl! http://nl.msn.com/ ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Using perfect metal in C++ interface
Return a value from your eps function which is large and negative. -1e20 should work. For metallic computation domain boundaries you can do this: structure s(vol, eps); fields f(s); f.set_boundary(High, X, Metallic); f.set_boundary(Low, X, Metallic); f.set_boundary(High, Y, Metallic); f.set_boundary(Low, Y, Metallic); On Mon, 4 Aug 2008, Jefferson Thomas wrote: Hi, I would like to know how to use the perfect metal in the C++ interface. I can not find it in the documentation. Do I have to return some specific value from the eps function or it is done in a different way ? Thomas Jefferson ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Question on PML
Alex, My experience with plasmonic problems is that 2nm isn't fine enough of a resolution. I only got nice results with 0.5nm (I had to use a cluster). I was working with a Drude model for silver, not gold, but I imagine that you will have similar results. I don't think you can shave off much from your PML thickness, especially at with wavelengths as long as 1000nm. Unfortunately, I think the only answer to your question about whether 100nm is too thin in the one direction is to also try 200nm, 400nm, and so on, and see how your results converge. That's probably not reasonable for such a large problem, but I don't think there's any way around it. If your results differ from the Mie solution, I would also check your assumption about the periodicity being long enough by simply running the same problem without the periodicity and with PML in all three directions. A side note: One thing which would be really nice for problems like this is a Total-field Scattered-field approach to allow plane waves with PML in all directions. I tried the solution proposed by Andreas Unger previous on the list but found some problems with it. First, I couldn't make it work with broadband sources. Second, you can't initialize the field everywhere with an analytic planewave, so you have to let the sources propogate and settle (that is very costly for plasmonic problems like yours with huge computation domains). Also bothersome is that the scattered fields and total fields aren't actually stored separately, so you don't have access to the scattered field inside the total field region. Finally, having so many sources all around the computation domain make the simulation very slow. Best, Matt On Wed, 2 Jul 2008, Alexander Sprafke wrote: Hi Andreas, thanks for your quick response, I would not think that you can make things worse by putting a small pml but I think a pml with less than 5 cells also makes no sense. ok, I understand that such a small pml layer does not make much sense. I didn't mean to make it that small, maybe I shortly describe my problem: For a start I'd like to calculate scattering and absorption of a spherical gold nano particle (diameter 100nm, placed in center of computational cell, surrounded by flux-planes) and compare it to the analytical Mie solution. I use a resolution of 2 nm, my source (plane wave propagting along z, Ex polarized) works in the visible/nir region, i.e. 400...1000nm, so I think I should use pml thicknesses of 500nm (approx. 0.5-1 wavelengths) in the Z and Y direction. Since the particle itself represents a dipole source, I don't expect much radiation in the X direction, thats why I think I can reduce the pml thickness in that direction or even omit them. All in all my computational cell is now 2000nm(Z)*1600nm(Y)*1000nm(X). Using periodic boundary conditions and a x-cell size of 1000nm means that the next particle is 1000nm away, at that distance and polarization, coupling of nano particles is very weak (the opposite is true for the y direction). My question is if putting a pml layer of 100 or 200nm in that direction would give me unwanted reflections into my cell (and inside placed flux-planes) because it is smaller than the recommended 0.5 wavelengths or would help in ensuring that coupling of the particle with its neighbours is minimized. The reason I do all this is downsizing the computaional cell. Regards Alex Other comments on how I plan to validate Mie spectra using meep are also very welcome. Hallo Alex, usually a pml is designed to give a fixed reflectivity in case it is continuous space. When you now make the pml to thin, it will come to numerical reflections at the interface from the space to the pml and inside the pml. Because of the finite spatial sampling the discretised pml is not matched perfectly anymore where a continuous one would still be. I would not think that you can make things worse by putting a small pml but I think a pml with less than 5 cells also makes no sense. Andreas Alexander Sprafke schrieb: Dear meep community, dear Steven, the meep reference says about pml layers The thinner it is, the more numerical reflections become a problem. Lets say I have a pml layer which is too thin. Do these reflections come from propagating waves going through the pml layer and being reflected at the end of the computational cell, going through the pml layer again and entering the region of interest. Or is it the too-thin-pml layer itself? The reason I ask is the following: I'd like to downsize my computational cell. I have a simple structure from which I know that there is almost no scattering (- almost no coupling in case of periodic boundary condition) into one certain direction, so I think it is reasonable to omit the pml layer in that direction which would make the computational cell significantely smaller. I was wondering if I should still put a thin pml
[Meep-discuss] pmc material
Hello, I know from the mailing list that scalar permeabilities are not yet implemented. Does that also mean there is no way to define geometric objects like blocks or cylinders having a PMC material? Kind Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] time-averaged magnetic field amplitude
I discovered that this approach is incompatible with meep-mpi as-is. The h5math and file deletion needs to be run serially. I just output the files I need and use h5math from the command line, but that would require either a long h5math expression d1*d1 + d2*d2 + ..., or a bash script which operates on two h5 files at a time. I tried putting a (= 0 (meep-my-rank)) in the step function to serialize this, but then meep-mpi deadlocked as warned in the documentation. On Wed, 18 Jun 2008, matt wrote: Neat, thanks! For the time average amplitude of a complex field, I changed the convert-h5 function as shown below. It's very hokey because the field component is hard-coded into the function, but it works. Also, it's not really an average but rather a sum, which is okay if you just want a pretty picture. (define (convert-complex-h5 rm? convert-cmd . step-funcs) (define (convert fname) (if (and rm? (zero? (system (string-append convert-cmd \ fname :hz.i\ \ fname :hz.r\ (system (string-append rm \ fname \ (lambda (to-do) (let ((hooksave output-h5-hook)) (set! output-h5-hook convert) (map (lambda (f) (eval-step-func f to-do)) step-funcs) (set! output-h5-hook hooksave (define (complex-time-avg fname step-func) (let ((first-step? true)) (lambda (to-do) (if first-step? (begin ; just copy the output file to fname (set! first-step? false) ((convert-complex-h5 true (string-append h5math -e \sqrt(d1*d1 + d2*d2)\ fname ) step-func) to-do)) ;; otherwise, add the output file to fname ((convert-complex-h5 true (string-append h5math -e \d1 + sqrt(d2*d2 + d3*d3)\ fname fname ) step-func) to-do) On Tue, 17 Jun 2008, Steven G. Johnson wrote: On Jun 17, 2008, at 5:37 AM, matt wrote: I want meep to output the amplitude of the complex time-average magnetic field over the computation domain, as an h5 file. See e.g. http://thread.gmane.org/gmane.comp.science.electromagnetism.meep.general/1456 but I'm not looking for for the instantaneous magnetic field. I'm also not interested in the time-average flux or energy, which I could with flux-in-box or field-energy-in-box. Those two only give you time averages if you have time-harmonic complex fields (i.e. a CW source, with force-complex-fields?=true, and have waited for transients to disappear). But in the case of a time-harmonic source, the time-average field is simply zero. Steven ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] time-averaged magnetic field amplitude
Neat, thanks! For the time average amplitude of a complex field, I changed the convert-h5 function as shown below. It's very hokey because the field component is hard-coded into the function, but it works. Also, it's not really an average but rather a sum, which is okay if you just want a pretty picture. (define (convert-complex-h5 rm? convert-cmd . step-funcs) (define (convert fname) (if (and rm? (zero? (system (string-append convert-cmd \ fname :hz.i\ \ fname :hz.r\ (system (string-append rm \ fname \ (lambda (to-do) (let ((hooksave output-h5-hook)) (set! output-h5-hook convert) (map (lambda (f) (eval-step-func f to-do)) step-funcs) (set! output-h5-hook hooksave (define (complex-time-avg fname step-func) (let ((first-step? true)) (lambda (to-do) (if first-step? (begin ; just copy the output file to fname (set! first-step? false) ((convert-complex-h5 true (string-append h5math -e \sqrt(d1*d1 + d2*d2)\ fname ) step-func) to-do)) ;; otherwise, add the output file to fname ((convert-complex-h5 true (string-append h5math -e \d1 + sqrt(d2*d2 + d3*d3)\ fname fname ) step-func) to-do) On Tue, 17 Jun 2008, Steven G. Johnson wrote: On Jun 17, 2008, at 5:37 AM, matt wrote: I want meep to output the amplitude of the complex time-average magnetic field over the computation domain, as an h5 file. See e.g. http://thread.gmane.org/gmane.comp.science.electromagnetism.meep.general/1456 but I'm not looking for for the instantaneous magnetic field. I'm also not interested in the time-average flux or energy, which I could with flux-in-box or field-energy-in-box. Those two only give you time averages if you have time-harmonic complex fields (i.e. a CW source, with force-complex-fields?=true, and have waited for transients to disappear). But in the case of a time-harmonic source, the time-average field is simply zero. Steven ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] run interruption/field decay
That makes complete sense :)I'm not sure why I hadn't thought of this. I tried as you suggest, and it works perfectly. Thanks, Matt On Wed, 11 Jun 2008, Mischa Megens wrote: Has anyone else had this problem? Any ideas on a solution? I suppose you could save the results every once in a while? Say with (at-every ...) ? Then you could just stop whenever you want? Best, m. ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Absorption in an intrinsic germanium layer of a photodiode
Hi Mario, Sometimes impossible transmission coefficients arise from placing the flux lines too close to the scatterer. Try to make sure your flux lines are separated from the scatterer by a distance of a wavelength, and not right next to the scatterer as you describe. Also, make sure the flux lines are a wavelength away from sources or pml. You will probably need to increase the size of your air layers to do this. If this gets you good results, you can try to decrease the distances to the flux planes to speed up the simulation. Some other things you can check are to make sure your PML layers are thick enough, and also that you run the simulation long enough (to a small enough decay). If you had a loss-free system, you would be able to tell that your results are correct by observing the losses. Since you don't have this, you have to do several convergence analyses to see whether the losses converge when you increase the resolution, play with the source settings, increase the pml thickness, etc. Best, Matt On Tue, 3 Jun 2008, Mario Cao wrote: Hello, I send one question the 8th April and I have not got any reply. I would be very pleasured if somebody could help me one jsut give me some leads to go on. Thank you very much once again, Mario Cao --- At first, I want to thank you all the help you are offering in the meep-discuss mailing-list. My problem is that I have the following structure with different dielectric materials with dispersion and I want to calculate the absorption (the loss) only in the Germanium(Ge) layer, but I am not sure how. Source is placed in the first Air-layer(1) and the simulation is run in 2D (propagation direction is x) * *|* | | | | | *|* | | | | | *|* Air | Si | Ge | Si | Air | *|* | | | | | *|*__|__|__|__|__| *1 2 3 4 5 I tried to calculate the loss coefficient with the help of flux areas (lines) just before the Ge-layer and just after the Ge-layer. But the results are not the expected, because the transmission coefficient is greater than 1. (not logical) I do not know how to deploy this measure, because in the example of the tutorial Transmission spectrum around a waveguide bend there is one first simulation without dielectric and another one with dielectric. In my case with many dielectric-layers, it is possible to calculate the loss with the flux areas? How should be the first simulation? And if not, how could I calculate the absorption or loss of this layers? Thank you in advance. Best regards, Mario Cao PS: Sorry if my english is not very clear. ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] E and H for the same point
Do these texts answer your question? http://ab-initio.mit.edu/wiki/index.php/Meep_Introduction#Finite-difference_time-domain_methods http://ab-initio.mit.edu/wiki/index.php/Meep_Introduction#The_illusion_of_continuity_in_Meep Best, Matt On Tue, 3 Jun 2008, Juntao Xi wrote: Hi, Steven and Meepers, Now, I am working on the optical force simulation project. And mostly, the optical force is presented by the Maxwell stress tensor. (http://en.wikipedia.org/wiki/Maxwell_stress_tensor). As you know, Meep is using FDTD algorithms and the E output and H output have half-step difference. My question is that how I can get the E and H for the same point Regards Jun ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Band structure question
Hi Murtaza, One thing you could do is to not run the program in the background (by removing the at the end). Another option, if you want to run in the background, is to redirect stdin from /dev/null by adding this to the end of your program invokation: /dev/null Here's an explanation of why: Running an MPI job in the background is supported only when stdin is redirected. The mpirun process is still connected to the tty when a job is placed in the background. One of the things that mpirun polls for is input from stdin. If it happens to be polling for stdin when a user types in a window after putting an MPI job in the background, and stdin has not been redirected, the job will abort upon receiving a SIGTTIN signal. This behavior is intermittent, depending on whether mpirun happens to be looking for and sees any stdin input. The following examples show how to run an MPI job in the background. For a job that uses input_file as stdin: mpirun -np 2 ./a.out input_file output For a job that does not use stdin: mpirun -np 2 ./a.out /dev/null output from here: http://mrbayes.csit.fsu.edu/wiki/index.php/FAQ#How_do_I_run_MrBayes_MPI_.28parallel.29_version_in_the_background_on_an_SGI_machine.3F Best, Matt On Thu, 8 May 2008, Murtaza Askari wrote: Hi All, I am really new to MEEP and Linux. When I generate the band structure using parallel meep and gather the frequencies I see the following printed over and over again in my output file and it corrupts the list of frequencies for some of the k points. mpiexec_beast (handle_stdin_input 1067): stdin problem; if pgm is run in background, redirect from /dev/null How do I get rid of it? best regards Murtaza Askari PhD Candidate Photonics Research Group School of ECE Georgia Institute of Technology ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] resolution and cell width
Hello, For a quasi-1d simulation with periodic boundaries, I'd like to run a computation which is 3 pixels wide; 1 pixel in the middle for the domain, and 2 on either side for the periodic boundaries. When I try this: (set! sx (/ 3 resolution)) (set! geometry-lattice (make lattice (size sx sy no-size))) and check the resulting eps.h5 with h5ls, I find the h5 data is 4 pixels wide. I tried changing the resolution to make sure this didn't have something to do with fractional rounding of a pixel, but I was never able to get h5 data which was 3 pixels wide. Is this behavior to be expected? Kind Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Metallic boundaries
The method you're looking for is set_boundary:
void fields::set_boundary(boundary_side b, direction d,boundary_condition){
if (boundaries[b][d] != cond) {
boundaries[b][d] = cond;
chunk_connections_valid = false;
}
}
You can invoke it like this:
f.set_boundary(High, X, Metallic);
Side can be High or Low,
Direction X,Y,Z,R, or P,
Boundary condition Periodic, Metallic, or Magnetic
The most efficient way to define a waveguide is with metallic boundary
conditions, which let you trim the computation domain down to a minimum.
Cheers,
Matt
On Sat, 9 Feb 2008, Mani Chandra wrote:
Hi How does one set metal as the boundary condition of the waveguide
in the C++ interface. I mean what argument does structure take for
metals and also how does one set the dimensions of the boundary layer.
Can one set the boundaries of the waveguide as metal and avoid having
to even specify the boundaries of the computational cell? (cause
metals will not allow electric fields to pass anyway)
Thanking you,
Mani chandra
___
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] bug in output-png+h5 with meep-mpi
Hello, I noticed some strange behavior in output-png+h5 with meep-mpi 0.10.1 The png output is incorrect has white patches blocking the fields. If I run the h5topng -Zc dkbluered on the h5 ouput, the resuling png appears correct without the white patches. Non-parallel meep does not exhibit this behavior. I attached a sample png which illustrates what happens. Depending on the number of processors I run, the white patches can change their layout. For the attached image, I ran with four processors mpirun -np 4 meep-mpi silverrod1.ctl The code below will (hopefully) reproduce the error... As a side question, I never get perfect plane waves with this approach, even if I make the pml thick and let the simulation run for many time steps. Is there something else I should consider? Best, Matt (set! eps-averaging? false) (define-param s 1600) ; the size of the computational cell, not including PML (define-param dpml 400) ; thickness of PML layers (define sxy (+ s (* 2 dpml))) ; cell size, including PML (set! geometry-lattice (make lattice (size sxy sxy no-size))) (set! geometry '()) (set! pml-layers (list (make pml (thickness dpml (set-param! resolution (/ 1 10)) ;; pixels per distance unit (define ((pw-amp k x0) x) (exp (* 0+1i (vector3-dot k (vector3+ x x0) (define-param lcen 213) (define-param fcen (/ 1 lcen)) ; pulse center frequency (define-param df (/ fcen 100)) ; turn-on bandwidth (define-param kdir (vector3 1 1)) ; direction of k (length is irrelevant) (define k (vector3-scale (* 2 pi fcen) (unit-vector3 kdir))) ; k with correct length (define kxcos (vector3-x (unit-vector3 k))) ; direction cosine of k in x (define kycos (vector3-y (unit-vector3 k))) ; direction cosine of k in x (set! sources (list ; left (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Hz) (center (* -0.5 s) 0) (size 0 s) (amp-func (pw-amp k (vector3 (* -0.5 s) 0 ; bottom (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Hz) (center 0 (* -0.5 s)) (size s 0) (amp-func (pw-amp k (vector3 0 (* -0.5 s) )) (define-param T 10) ; run time (run-until T (at-beginning output-epsilon) (at-end (output-png+h5 Hz -Zc dkbluered)) (at-end output-tot-pwr)) new.png Description: Binary data ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] bug in output-png+h5 with meep-mpi
I'd like to have a 2D planewave of arbitrary incidence angle, z-invariant, with PML in x and y directions (all around the computation domain). I can almost get this with two line sources, but the waves aren't perfect (visually). I think what you propose only works for normal incidence. Best, Matt PLANE WAVES: --- You are working in 2D which means you want a line source in x-y in teh case of z-invariance. If you want a planewave propagating along z- then you should have no modulations on the x-y plane. If you want a 3D planewave that is obliquely incident to the x-y- plane that you are visualizing then we'd have the formulation that you've included below. Is this what you are trying to simulate? But all your reference points for the wavefronts are in 2D: (-0.5s, 0) and (0, -0.5s). This leads me to believe that you want a planewave with k-vector parallel to the x-y plane. that would make it a line source for your problem. For this I use the following amp-func: (define (line-source-dist pos) (abs (vector3* (vector3- pos line-source-center) line-source-unit-normal) ) ) (define (line-source-amp-func pos) (if ( (line-source-dist pos) 2) 0 (* 0.5 (- 1 (line-source-dist pos))) ) ) My amplitude function defines a line source whose strength varies linearly down to zero with distance from the line along the unit normal over an interval of 2 length-scales. With this I get nice z-invariant planewaves. cheers! Manoj matt wrote: Hello, I noticed some strange behavior in output-png+h5 with meep-mpi 0.10.1 The png output is incorrect has white patches blocking the fields. If I run the h5topng -Zc dkbluered on the h5 ouput, the resuling png appears correct without the white patches. Non-parallel meep does not exhibit this behavior. I attached a sample png which illustrates what happens. Depending on the number of processors I run, the white patches can change their layout. For the attached image, I ran with four processors mpirun -np 4 meep-mpi silverrod1.ctl The code below will (hopefully) reproduce the error... As a side question, I never get perfect plane waves with this approach, even if I make the pml thick and let the simulation run for many time steps. Is there something else I should consider? Best, Matt (set! eps-averaging? false) (define-param s 1600) ; the size of the computational cell, not including PML (define-param dpml 400) ; thickness of PML layers (define sxy (+ s (* 2 dpml))) ; cell size, including PML (set! geometry-lattice (make lattice (size sxy sxy no-size))) (set! geometry '()) (set! pml-layers (list (make pml (thickness dpml (set-param! resolution (/ 1 10)) ;; pixels per distance unit (define ((pw-amp k x0) x) (exp (* 0+1i (vector3-dot k (vector3+ x x0) (define-param lcen 213) (define-param fcen (/ 1 lcen)) ; pulse center frequency (define-param df (/ fcen 100)) ; turn-on bandwidth (define-param kdir (vector3 1 1)) ; direction of k (length is irrelevant) (define k (vector3-scale (* 2 pi fcen) (unit-vector3 kdir))) ; k with correct length (define kxcos (vector3-x (unit-vector3 k))) ; direction cosine of k in x (define kycos (vector3-y (unit-vector3 k))) ; direction cosine of k in x (set! sources (list ; left (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Hz) (center (* -0.5 s) 0) (size 0 s) (amp-func (pw-amp k (vector3 (* -0.5 s) 0 ; bottom (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Hz) (center 0 (* -0.5 s)) (size s 0) (amp-func (pw-amp k (vector3 0 (* -0.5 s) )) (define-param T 10) ; run time (run-until T (at-beginning output-epsilon) (at-end (output-png+h5 Hz -Zc dkbluered)) (at-end output-tot-pwr)) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] anisotropy in meep
Hello,
I'm having another look at this problem, after having put it off for a
while.
The easy part was on the libctl side; in the specifications file I
modified dielectric materials to have epsilon-tensor and scaled-
epsilon-tensor properties. If you provide no tensor when making your
dielectric, the material is assumed to be isotropic and the scaled
tensor will have the same dielectic constant along its diagonal.
If you want an anisotropic material, you can set epsilon to 1 and set
the epsilon-tensor to whatever you choose:
(define-class dielectric material-type
(define-property epsilon no-default 'number)
(define-property epsilon-tensor (matrix3x3 (vector3 1 0 0) (vector3 0 1 0)
(vector3 0 0 1)) 'matrix3x3)
(define-derived-property scaled-epsilon-tensor 'matrix3x3
(lambda (object)
(matrix3x3* (object-property-value object 'epsilon)
(object-property-value object 'epsilon-tensor
(define-property polarizations '() (make-list-type 'polarizability))
(define-property chi2 0 'number)
(define-property chi3 0 'number)
)
Resulting in this behavior:
meep (define a (make dielectric (epsilon 3)))
meep (define b (make dielectric (epsilon 1) (epsilon-tensor (matrix3x3
(vector3 4.8 0 0) (vector3 0 4.8 0) (vector3 0 0 5.2)
meep a
((dielectric material-type) (chi3 . 0) (chi2 . 0) (polarizations)
(epsilon-tensor . #(#(1 0 0) #(0 1 0) #(0 0 1))) (epsilon . 3)
(scaled-epsilon-tensor . #(#(3 0 0) #(0 3 0) #(0 0 3
meep b
((dielectric material-type) (chi3 . 0) (chi2 . 0) (polarizations)
(epsilon-tensor . #(#(4.8 0 0) #(0 4.8 0) #(0 0 5.2))) (epsilon . 1)
(scaled-epsilon-tensor . #(#(4.8 0 0) #(0 4.8 0) #(0 0 5.2
On the C side, things get trickier, and I'm a bit lost. There are
several things I don't understand in the code:
1) structure_chunk::set_epsilon (specified in
anisotropic_averaging.cpp) is passed a material_function. That class
has one-liner methods specified in meep.hpp, (eps(), sigma(), chi3(),
and chi2()).
public:
simple_material_function(double (*func)(const vec )) { f = func; }
virtual ~simple_material_function() {}
virtual double eps(const vec r) { return f(r); }
virtual double sigma(const vec r) { return f(r); }
virtual double chi3(const vec r) { return f(r); }
virtual double chi2(const vec r) { return f(r); }
};
I think when using the c++ interface, you define these functions yourself, like
this:
double eps(const vec p) {
vec r = p - center;
if (abs(r) rad) return er;
else return 1.0;
}
But how do these functions get informed or populated when running meep
via libctl? More specifically, how can material_functions access the
scaled-epsilon-tensor (matrix3x3) above?
2) Should a new subclass of material_function be defined? In
simple_material_function, eps, sigma, chi3, chi2 are all doubles, so
you can use that template-esque code above. Since the epsilon-tensor
is not a double, I should probably return a matrix3x3 struct (those
are typedef'ed in ctl.h, which I think meep.hpp is unaware of... ).
3) If I manage to set the inveps of structure_chunk, any subsequent
calls to set_epsilon() will clobber those values. This means the
interface should set inveps only after set_epsilon has been called?
4) Is it possible to set inveps in a way which takes advantage of the
existing anisotropic averaging code (which also sets inveps)?
These aren't related to this problem, but I'm still curious:
5) What's an IVEC?
6) What's a yucky_val???
Best,
Matt
On Wed, 10 Oct 2007, Steven G. Johnson wrote:
On Wed, 10 Oct 2007, matt wrote:
I'd like to follow up on these messages, where it was suggested that
hacks are possible for specifying anisotropic dielectrics.
http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00779.html
http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00067.html
Are these hacks documented somewhere? If not, could anyone who
successfully got anisotropy working clue us in on how they achieved
this?
Meep stores anisotropic dielectrics internally via the structure::inveps
data structure (which stores a 3x3 matrix of 1/epsilon at each point, or
rather the relevant row of that matrix at each Yee point). However, there
is currently no interface to specify this manually (it is only used for
the subpixel averaging). You would have to add a function to structure::
to set it.
Steven
___
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
___
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] h5topng generates upside down plot
This could have to do with a misinterpretation of meep coordinates. With the libctl interface, a 10x10 cell will have its center at (0,0), its bottom right at (5,5), and its top left at (-5,-5). The C++ interface is a bit different, with the origin corresponding to the top left corner of the computation domain. This behavior is sort-of documented here: http://ab-initio.mit.edu/wiki/index.php/Meep_C-plus-plus_Tutorial#Differences_from_libctl I say sort-of because it only defines the center and range for each interface, but not the orientation. You can search the complete archives here: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/ Happy New Year, Matt On Thu, 27 Dec 2007, Puck Ja wrote: Hi, I am new to MEEP and have found one issue with h5topng. After simulation, the field snap shot was generated with the command in tutorial: h5topng -S3 -Zc dkbluered -a yarg -A eps-00.00.h5 ez-000200.00.h5 But I have shifted the structure down in my simulation. The resulting png has structure shifted up. However, if I use octave open the *eps*.h5 file and plot it, the structure is correctly positioned. I couldn't find any switch to flip it using h5topng. Am I missing something? Thanks for the help. BTW, I tried to search the discussion group, but could not find a way to do in at http://ab-initio.mit.edu/pipermail/meep-discuss/ Is it possible to do a search of the whole archive? Much obliged for your help! Puck ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] plane wave generation
Hi Anatoliy, There are a few problems in the code you sent. One fundamental issue is PML thickness. If you want nice results, your PML should be at least one wavelength thick. In your code, the frequency corresponds to a wavelength five times thicker than your PML. This means waves are not properly matched by the pml layer, which will cause undesirable reflections. Your two options are to increase the frequency, or increase the PML thickness. Second, there are two ways to make nice continuous plane waves: 1) Periodic boundary conditions in one direction, PML in the other direction, and a source plane along one PML boundary. 2) PML in all directions, and a source plane along a PML boundary in each direction (if 2d, then two source planes along two PML boundaries, if 3d, then three source planes along three PML boundaries). Prof. Johnson explains how to do the latter somewhere on the mailing list. To do the former, I modified your code as follows: (define-param sy 6) ; the size of the computational cell NOT including PML inthe y direction (define-param sx 6) ; the size of the computational cell including PML inthe x direction (define-param dpml 4) ; the thickness of PML layer (define-param svert (+ sy (* 2 dpml))) (define-param frec 1) (define-param res 25) (define-param theta (/ pi 4)) (define kx (* frec (sin theta))) (define (my-amp-func p)(exp (* 0+2i pi kx (vector3-x p (set! k-point (vector3 kx 0 0)) (set! geometry-lattice (make lattice (size sx svert no-size))) (set! sources (list (make source (src (make continuous-src (frequency frec))) (component Hz) (center 0 (/ sy -2)) (size sx 0) (amp-func my-amp-func (set! pml-layers (list (make pml (thickness dpml) (direction Y (set! resolution res) (run-until 100 (at-end (output-png Ex -Zc dkbluered)) (at-end (output-png Ey -Zc dkbluered))) I changed some numbers, just to make it run faster. The important thing to note is that there is no PML in the X direction, and the boundary of computatation is adjusted accordingly. The source plane extends from the left to the right of the cell. Also, it may be more convenient for you to use output-png instead of h5topng at the command line. Best, Matt On Fri, 14 Dec 2007, Anatoliy Goncharenko wrote: Dear Meep users, Because the problem of scattering of the plane wave appears to be the classical problem, I expect that many people deal with it. Earlier, there was a broad discussion on signifying the plane wave source in Meep (see the subject oblique plane wave scattering) and some codes were developed. However, I am not sure that everything is correct in these codes. For checking, I have considered the plane wave in the empty 2d box following the way suggested earlier by Steven Johnson and Matt, http://ab-initio.mit.edu/pipermail/meep-discuss/2007-February/000704.html http://ab-initio.mit.edu/pipermail/meep-discuss/2007-February/000705.html (see my file below). Instead of the s-polarized wave, when the electric field is normal to the scattering (xy) plane, i.e., when there is the only (Ez) component of the electric field, I have dealt with the p-polarized wave, when the electric field is in the scattering plane. So, there are two components of the electric field, Ex and Ey, and correspondingly the only (Hz) component of the magnetic field. For simplicity, I have considered the plane wave incident at an angle of 45 degrees. Thus, I have signified Hz and computed Ex and Ey. It is clear, that both components, Ex and Ey, must be the same due to symmetry. It is easy to see, however, that it is not so: the field distribution is different for Ex and Ey. Who can tell me, where is a bug? Best regards, Anatoliy (define-param sy 10) ; the size of the computational cell including PML in the y direction (define-param sx 10) ; the size of the computational cell including PML in the x direction (define-param dpml 1) ; the thickness of PML layer (define-param frec 0.2) (define-param res 25) (define-param theta (/ pi 4)) (define kx (* frec (sin theta))) (define (my-amp-func p)(exp (* 0+2i pi kx (vector3-x p (set! k-point (vector3 kx 0 0)) (set! geometry-lattice (make lattice (size sx sy no-size))) (set! sources (list (make source (src (make continuous-src (frequency frec))) (component Hz) (center 0 -4) (size 8 0) (amp-func my-amp-func (set! pml-layers (list (make pml (thickness dpml (set! resolution res) (run-until 1000 (at-end output-efield-x) (at-end output-efield-y)) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Harminv doubt
Hi Daniel, Check this post: http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00161.html Best, Matt On Thu, 29 Nov 2007, Dani Infante wrote: I have been using harminv to calculate the frequencies and Q factors of the modes in a photonic crystal cavity and I have got strange negative values for the quality factors of some of the modes. What does it mean? I also attach the obtained results: harminv0:, frequency, imag. freq., Q, |amp|, amplitude, error harminv0:, 0.223306537028419, 2.45087478374015e-4, *-455.564965027799*, 0.324250754034816, 0.303479559920429+0.114187163037924i, 2.72315424282051e-6 harminv0:, 0.231230124064845, -6.5060745323059e-4, 177.703254794172, 4.73854011681368, -1.28125419198095-4.56203355250527i, 3.13943646554943e-6 harminv0:, 0.237885260939232, 0.00101896725040082, *-116.728609700487*, 1.41924201168144, 0.169824334481733+1.40904491877988i, 8.08320988300965e-7 harminv0:, 0.2417314616631, 1.47763412528991e-5, *-8179.67917517036*, 4.98580429145361, -4.88862325367867+0.979595383956763i, 2.63720368537054e-6 harminv0:, 0.260846325835526, 1.47439956861405e-5, *-8845.84923206146*, 1.1735991199864, 0.226993111365976-1.15143780632097i, 3.36001677162268e-6 harminv0:, 0.271510447723058, -0.002094677043, 64.8096202121396, 2.20957791725273, -1.4297893175926+1.68461778445705i, 1.67800656305732e-5 ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] anomaly in TEM parallel plate waveguide
Hello, I'm simulating the TEM mode of a simple parallel plate waveguide. It has periodic boundary conditions in x, metallic boundary conditions in y, and propagation vector in z. The propagation direction has PML in front and back. The attached images show an x-slice of the waveguide, with a strange anomaly near the top left, where the metallic boundary condition, source plane, and PML coincide on a line. The anomaly appears as the presence of an additional line source along the line where the source plane and the metallic boundary meet. (It doesn't matter which x-slice I present, the anomaly will always appear the same) This anomaly doesn't die out (compare images for t=200 with t=2000). It's hard to see from the images, but the anomaly seems to make the TEM wave non-perfect in the rest of the waveguide. I also tried using metallic blocks for the parallel plates, instead of setting the High and Low X boundaries to Metallic, but the result was the same. Is this a bug? Kind Regards, Matt xslice_t200.png Description: t200 xslice_t2000.png Description: t2000 ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Spatially varying sigma
Hi Ben, I misunderstood your problem. sigma expects a number and not a function, as you discovered. If I modify this function as follows, your code works because sigma_func gets evaluated: (define (make-polarizability-from-conductivity sigma_func omega_in) (make polarizability (omega omega_in) (gamma omega_in) (delta-epsilon (/ 1 omega_in)) (sigma (sigma_func 42)) ) ) You proably want to evaluate what you want sigma to be higher up in make-mat-from-eps-and-sigma. Instead of calling make-polarizability-from-conductivity and passing it a function, you only pass a single sigma value. Kind Regards, Matt As it happens, I've already read all these threads. I was specifically aware of the need to assign the polarizability I used to a simple-dielectric object. For that reason, I wrote a function initialize-polarizability, which assigns that polarizability to a size-0 object at infinity, as suggested by Dr. Johnson in one of those threads. - --Ben ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Spatially varying sigma
Hi Ben, I think what you want is possible with the ctl interface. I made a simple example based on a dielectric waveguide, and some contrived polarization values, and functions which vary both the permittivity and the sigma with respect to position. http://pastebin.com/f10731e93 I'm assuming that my example works because it runs and gives me an end result, but I haven't actually investigated whether the values of epsilon and sigma change as a function of position. Best Regards, Matt On Fri, 12 Oct 2007, Benjamin M. Schwartz wrote: matt wrote: You proably want to evaluate what you want sigma to be higher up in make-mat-from-eps-and-sigma. Instead of calling make-polarizability-from-conductivity and passing it a function, you only pass a single sigma value. Unfortunately, this is not the case. My goal is specifically to describe a material in which the electrical conductivity and permittivity vary continuously with position. Due to Meep's architecture, it is not possible to generate a new polarizability at each location. Instead, we are intended to use the sigma function to generate a single polarizability object whose behavior depends on position. If sigma is not meant to be passed as a function, then sigma and delta-epsilon are entirely redundant. Is this a bug, either in documentation or in implementation? - --Ben ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] anisotropy in meep
Hello, I'd like to follow up on these messages, where it was suggested that hacks are possible for specifying anisotropic dielectrics. http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00779.html http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00067.html Are these hacks documented somewhere? If not, could anyone who successfully got anisotropy working clue us in on how they achieved this? Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] meep-mpi and read-line
This was a very simple problem; guile 1.6.7 and 1.8.2 behave slightly differently. read-line works with (use-modules (ice-9 rdelim)) Regards, Matt On Mon, 13 Aug 2007, matt wrote: Hello, I have a meep script which opens a text file and sets some parameters according to values in that file. To do this I am using a function called (read-line). In non-parallelized meep, this is not a problem, but when I try to do this with meep-mpi I get the following error: mpirun -np 4 meep-mpi test.ctl Using MPI version 2.0, 4 processes ERROR: Unbound variable: read-line rank 1 in job 57 cariddi_60917 caused collective abort of all ranks exit status of rank 1: killed by signal 9 Is this intentional? If so, is there some alternative I can try? Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] serial hdf5 and meep-mpi
You were correct, it was an install problem. Thanks, Matt On Wed, 8 Aug 2007, Steven G. Johnson wrote: On Wed, 8 Aug 2007, matt wrote: % mpirun -np 4 meep-mpi mm1.ctl noscatrun.out echo finished meep: not compiled with HDF5, required for HDF5 outputmeep: [cli_0]: aborting job: application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0 Is this an install problem, or is there something I should do in the ctl file to implement said hacks? This looks like an installation problem; configure didn't find your HDF5 library. (If configure finds HDF5, it checks whether HDF5 was compiled with MPI support and otherwise it uses the serial hacks automatically.) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] meep-mpi and read-line
Hello, I have a meep script which opens a text file and sets some parameters according to values in that file. To do this I am using a function called (read-line). In non-parallelized meep, this is not a problem, but when I try to do this with meep-mpi I get the following error: mpirun -np 4 meep-mpi test.ctl Using MPI version 2.0, 4 processes ERROR: Unbound variable: read-line rank 1 in job 57 cariddi_60917 caused collective abort of all ranks exit status of rank 1: killed by signal 9 Is this intentional? If so, is there some alternative I can try? Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] serial hdf5 and meep-mpi
Hello, I'm trying to use the serial hdf5 libraries with meep-mpi. The Installation wiki page says: We have some hacks in our MPB and Meep software so that they can do parallel I/O even with the serial HDF5 library; these hacks work okay when you are using a small number of processors, but on large supercomputers we strongly recommend using the parallel HDF5. Also, from the discussion list, http://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg00036.html b) Use the serial HDF5, but give both nodes in your cluster write access to the same directory by using NFS or some cluster filesystem. Actually, this is a good idea anyway -- it's extremely annoying to use a cluster where you don't have a shared filesystem. I'm running meep-mpi using mpich, from an nfs directory. It's a single computer with 4 processors. I get the following error: % mpirun -np 4 meep-mpi mm1.ctl noscatrun.out echo finished meep: not compiled with HDF5, required for HDF5 outputmeep: [cli_0]: aborting job: application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0 Is this an install problem, or is there something I should do in the ctl file to implement said hacks? Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] how to define the infinite substrate in the calculation of transmission spectrum?
You can just make the substrate extend to the bottom of the computation domain. Have the PML overlap the substrate, and place your observation plane between the PML boundary and the GaAs-Substrate boundary. You should test the spacing to see how much space is needed between the observation plane and surrounding interfaces. A good starting point is one wavelength on either side, but this may be excessive in certain circumstances (for normal incidence you can get away with less). Matt On Thu, 2 Aug 2007, seathink wrote: Hi Steven and Meep users, The following structure has a larger glass substrate. The height of the substrate is nearly infinity campared with the SiO2 layer or GaAs layer. To calculate the transmission spectrum, how should we set the height of the substrate, the source position and the position of the observation plane? Thanks a lot. H Wan *** source plane || \/ air layer - SiO2 layer: 300 nm GaAs layer: 250nm Substrate (Glass): 1 mm = 10^6 nm air layer || \/ observation plane * ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] nonlinear complex fit
Hello, Thanks for your suggestion. It seems that a fitting complex data is not possible with grace. It's possible to fit one curve at a time (real, or imaginary, separately). Best Regards, Matt On Tue, 3 Jul 2007, Andreas Wilde wrote: matt wrote: Hello, I have the following data for a lossy material (nylon), and I'd like to find the parameters for meep's lorentzian model which fit the data: frequency (hz) real(eps) imag(eps) 60 3.7 -.0666 1e3 3.5 -.0651 1e6 3.14-.068452 1e8 3.0 -.06 3e9 2.84-.033228 2.5e10 2.73-.028665 There was an indication in a previous post that this is simple: G.J. Parker original patch posted by Steven, this does reduce memory requirements when using Lorentzians. i have no problems using five Lorentzians w/ this patch. one can write a stupid excel spread sheet to fit N lorentzians to a table of (experimental) complex epsilons... Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss Hello, under Unix/Linux you could use xmgrace to fit the parameters of the model. I don´t know if this is better or worse than using a spreadsheet, but it should be one possibility. andreas ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] nonlinear complex fit
Hello, I have the following data for a lossy material (nylon), and I'd like to find the parameters for meep's lorentzian model which fit the data: frequency (hz) real(eps) imag(eps) 60 3.7 -.0666 1e3 3.5 -.0651 1e6 3.14-.068452 1e8 3.0 -.06 3e9 2.84-.033228 2.5e10 2.73-.028665 There was an indication in a previous post that this is simple: G.J. Parker original patch posted by Steven, this does reduce memory requirements when using Lorentzians. i have no problems using five Lorentzians w/ this patch. one can write a stupid excel spread sheet to fit N lorentzians to a table of (experimental) complex epsilons... Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] unwanted dispersive behavior?
Hello, I'm solving a simple multilayer loss-free dielectric slab scattering problem, for the case of normal incidence. The problem is simple enough that it can be solved analytically. The analytic solution matches published results, so I have confidence in its correctness. As you can see in the attached plot, the resonance in the reflectivity is frequency shifted by about 10 percent, and the scaling isn't quite right. The meep result doesn't change when I 1) increase the resolution 2) calculate over a more narrowband frequency range 3) increase pml thickness 4) increase spacing between scatterer and flux planes 5) increase spacing between source and flux planes/scatterer 6) set eps-averaging? to false 7) increase decay-by (and run the sim longer) 8) change the gaussian excitation center frequency 9) change the gaussian excitation cutoff 10) calculate reflectivity based on a flux point instead of a flux plane Just looking at the curve width make me think there's some kind of dispersive behavior, but I have no idea where it could be coming from. Any ideas? Best Regards, Matt compare.png Description: meep_vs_analytic ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] unwanted dispersive behavior?
I'm happy that I found the problem, but extremely embarassed at my mistake and how long it took me to find it. I mistakenly used index of refraction data in place of permittivity data. Maybe I should consider a career in the aerospace industry. Thanks again for your help. Best Regards, Matt On Wed, 27 Jun 2007, matt wrote: That's not it. I set the resolution early in the script, and I'm able to confirm via h5ls that increasing the resolution in the script increases the size of problem. Best, Matt The problem turned out to be that they were calling (set! resolution ...) too late in the file. When you call add-flux to add a flux plane the fields are initialized and the resolution etc. is set; changing the resolution etc. after that point has no effect (unless you call reset-meep! or similar). Perhaps your problem is similar? ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] dispersive materials
Hello, Does anyone have any experience implementing lossy materials such as graphite, gold, silver, or other, using meep's lorentz model? That is, what omega, gamma, and delta-epsilon values work well for which materials in which frequency ranges, and according to which references? Every numerical solver has a different way of modeling dispersive materials. Right now, it's not very easy for a new user to jump in and run some simulation with some standard, well characterized lossy materials. They must find some references, and try to find the correct polarizability values which fits a curve to those references. It would be nice if we could share this info here on the mailing list, and perhaps even collect it on a wiki page. Best Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] why Q is negative?
This topic has been discussed on the list before: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/166/ http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/603/ http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/601/ Best, Matt On Sun, 22 Apr 2007, Andrew Andrew wrote: Hi Alex, I wait a longer time, but it doesn't work. I will show you some details. The control file is holey-wvg-bands.ctl which can be found in meep's example files. Because I want to find the Q of kx=0.4 and omega=0.1896, I use a narrow Gaussian beam(fcen=0.1896;df=0.2). I change the period of time during which meep run harminv, but Q is negative. a. the period of time: 300 Q: -2309084592929.25 b. the period of time: 1000 Q: -511315815.822925 c. the period of time: 2000 Q: -178141.950590549 d. the period of time: 2500 Q: -48410.6858973668 e. the period of time: 3000 harminv gives nothing. So waiting a longer time seems can't solve this problem. And now, I have two more questions. 1. How long should I wait? 2. Why harminv gives no result? Mario ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] Can't compile haminv 1.3.1 on cluster
The first scenario has something to do with an incorrect lapack install, or perhaps you just need to specify --with-lapack when running configure. I'm not familiar with the other errors. On Mon, 2 Apr 2007, Nicolas Tetreault wrote: Hi all, hopefully you can give me a hand with this. I can't compile harminv. I get errors during the compilation. Depending on the compiler used I either get: CC=gcc and F77=f77 or ifort gcc -g -O2 -o harminv harminv-main.o /usr/local/Cluster-Apps/intel/mkl/9.0.018/lib/em64t/libmkl_lapack32.so /usr/local/Cluster-Apps/intel/mkl/9.0.018/lib/em64t/libmkl.so -L/home/nt271/comp-apps/para/lib ./.libs/libharminv.a -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s ./.libs/libharminv.a(harminv.o)(.text+0x2114): In function `solve_eigenvects': /home/nt271/temp/harminv-1.3.1/harminv.c:497: undefined reference to `zgeev_' collect2: ld returned 1 exit status make[1]: *** [harminv] Error 1 make[1]: Leaving directory `/home/nt271/temp/harminv-1.3.1' make: *** [all] Error 2 When using CC=mpicc with F77=mpif77 or ifort or f77 I get: mpicc -DHAVE_CONFIG_H -I. -I. -I. -I/home/nt271/comp-apps/para/include -g -O2 -MT harminv.lo -MD -MP -MF .deps/harminv.Tpo -c harminv.c -o harminv.o -DHAVE_CONFIG_H -I. -I. -I. -I/home/nt271/comp-apps/para/include -g -O2 -MT harminv.lo -MD -MP -MF .deps/harminv.Tpo -c harminv.c -o harminv.o -I/usr/local/Cluster-Apps/infinipath/2.0/if-mpi/include/ /bin/sh ./libtool --tag=CC --mode=link mpicc -g -O2 -L/home/nt271/comp-apps/para/lib -o libharminv.la -rpath /usr/local/lib -version-info 2:4:0 harminv.lo /usr/local/Cluster-Apps/intel/mkl/9.0.018/lib/em64t/libmkl_lapack32.so /usr/local/Cluster-Apps/intel/mkl/9.0.018/lib/em64t/libmkl.so -lm -L/home/nt271/comp-apps/para/lib -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s rm -fr .libs/libharminv.a .libs/libharminv.la .libs/libharminv.lai ar cru .libs/libharminv.a harminv.o ranlib .libs/libharminv.a creating libharminv.la (cd .libs rm -f libharminv.la ln -s ../libharminv.la libharminv.la) if mpicc -DHAVE_CONFIG_H -I. -I. -I. -I/home/nt271/comp-apps/para/include -g -O2 -MT harminv-main.o -MD -MP -MF .deps/harminv-main.Tpo -c -o harminv-main.o harminv-main.c; \ then mv -f .deps/harminv-main.Tpo .deps/harminv-main.Po; else rm -f .deps/harminv-main.Tpo; exit 1; fi -DHAVE_CONFIG_H -I. -I. -I. -I/home/nt271/comp-apps/para/include -g -O2 -MT harminv-main.o -MD -MP -MF .deps/harminv-main.Tpo -c -o harminv-main.o harminv-main.c -I/usr/local/Cluster-Apps/infinipath/2.0/if-mpi/include/ harminv-main.c(126): error: floating-point operation result is out of range const double inf = 1.0 / 0.0; ^ harminv-main.c(158): warning #181: argument is incompatible with corresponding format string conversion DENSITY, ^ compilation aborted for harminv-main.c (code 2) make[1]: *** [harminv-main.o] Error 1 make[1]: Leaving directory `/home/nt271/temp/harminv-1.3.1' make: *** [all] Error 2 using CC=mpixx or CC=mpiCC stop the configure script with this error: checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes checking for C complex keyword... __complex__ checking for C complex I constant... unsupported configure: error: C doesn't support complex numbers. Here are the different compilers: gcc --version gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2) f77 --version GNU Fortran (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2) mpicc --version --version -I/usr/local/Cluster-Apps/infinipath/2.0/if-mpi/include/ icc (ICC) 9.1 20060818 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. ifort --version ifort (IFORT) 9.1 20060818 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. Any help highly appreciated! Nic ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] incorrect reflection coeff. calculation
Hello, My simple meep example is coming up with an incorrect result. I found some posts on the list regarding similar problems (incorrect reflection coefficient calculation), where the recommendation was to move the flux planes away from the source, by at least a wavelength. This did not solve the problem for me. In my example, I have a 2D simulation, with periodicity in X, and PML in Y. The scatterer is a dielectric slab with epsilon 9. The source is a plane wave source at the upper PML interface (the angle of incidence is 30 degrees). The field output looks great (see attached png; resized smaller for posting to list). To calculate the fluxes, I simple setup flux planes in front of and beyond the slab, and run the computation twice; with and without the slab. The coefficents are clearly wrong: transmission: 0.647382725227634, reflection: 3.21374994463727, loss: -2.8611326698649 code: http://www.pastebin.us/19072 The command to run that code, which also computes the coefficients is: meep no-scatterer\?=true compute-flux\?=true test.ctl meep no-scatterer\?=false output-finalfield\?=true compute-flux\?=true output-finalfield\?=true test.ctl | tee lastrun.out Best Regards, Matt test2.png Description: test2.png ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] metal as dispersive material
Hi Henry, I asked the same questions not too long ago, and Steven sent a reply. Original post: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/712 Reply: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/726 Cheers, Matt On Thu, 22 Mar 2007, CHING YAN HENRY NG wrote: Dear all, I have some problems about simulating metal film in meep. After I declare metal as material (suppose to be perfect metal), I use output-epsilon together with h5totxt to print out epsilon function. In fact, I have a line (set! eps-averaging? false) - no averaging however, the output is still like 1,1.090909090909091,2.4,inf,inf,inf, ... ,inf,inf,2.4,1.090909090909091,1 I guess for perfect metal, it should be -inf. It doesn't seem like a h5totxt print error because every things are positive here. Moreover, I suppose there is no eps averaging when I set eps-averageing to false. Are there still other controls parameters to subpress averaging? Now if I use dispersive material to pretend metal, a negative value on dielectric const will blow out the simulation. I guess it is the averaging issue but how can I completely turn off averaging? I hope my newb questions will be answered and other novices can avoid my mistakes I have made. Regards, Henry ___ YM - Â÷½u°T®§ ´Nºâ§A¨S¦³¤Wºô¡A§AªºªB¤Í¤´¥i¥H¯d¤U°T®§µ¹§A¡A·í§A¤Wºô®É´N¯à¥ß§Y¬Ý¨ì¡A¥ô¦ó»¡¸Ü³£ÉN¨«¥¢¡C http://messenger.yahoo.com.hk___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] tilting line source to produce plane wave
You can generate a plane wave of oblique incidence by using a couple different tricks in meep. All of these have been discussed before on previous threads: http://ab-initio.mit.edu/pipermail/meep-discuss/2007-February/000700.html http://ab-initio.mit.edu/pipermail/meep-discuss/2006-July/000228.html http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/706 http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/245 http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/229 I recall from an older thread (which I can't find), that there's a way to make a quasi-planewave from two point sources, placed at the corner of the computation domain. You can't arrange a line source to be oblique to the Yee grid, but you can make a line source which is parallel to the grid and creates an oblique wave. If you want to ignore the wave on the opposite side of your source line, place the source line at a PML interface. The PML will absorb the fields on the other side. Good Luck, Matt On Mon, 19 Feb 2007, MUHAMMAD Amin wrote: Hi, I want to discuss two issues: 1) I want to tilt line source at an angle to produce plane wave, I have tried axis but it seems that it is not supported with source. 2) Making a single line source and radiating it at an angle e.g, 45 degree. The line source also radiates at an angle -45 degree. How can I avoid it? i.e. propagation in +ve direction and not in -ve direction (set! eps-averaging? false) (define-param sxy 20) (set! geometry-lattice (make lattice (size sxy sxy no-size))) (set! pml-layers (list (make pml (thickness 1.0 (define ((my-amp k x0) x) (exp (* 0+1i (vector3-dot k (vector3+ x x0) (define-param fcen .5) (define-param df 0.02) (define-param kdir (vector3 1 1)) (define k (vector3-scale (* 2 pi fcen) (unit-vector3 kdir))) (set! k-point (vector3 0 0 0)) (set! sources (list ;left head (make source (src (make continuous-src (frequency fcen)(fwidth no-size))) (component Ez)(center (* s -0.3) 0) (size 8 0) (amp-func (my-amp k (vector3 (* s -0.3) 0)) Thanks ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] oblique plane wave scattering
The result I expect to see, with no scattering object, is a plane wave with angle theta. What I get however, is something which doesn't resemble a plane wave but is rather the result of reflections from the periodic boundary. The only angle which appears to give a correct result is the trivial case, theta=0. I'm trying to determine if my expectation is wrong, or just my implementation: (set! eps-averaging? false) (define-param s 11) ; the size of the computational cell, not including PML (define-param dpml 1) ; thickness of PML layers (define sxy (+ s (* 2 dpml))) ; cell size, including PML (set! geometry-lattice (make lattice (size s sxy no-size))) ;(set! geometry (list (make block (center 0 0) (size (/ s 4) (/ s 22) infinity) (material metal (set! pml-layers (list (make pml (thickness dpml) (direction Y (set-param! resolution 12) (define-param fcen 0.8) ; pulse center frequency (define-param df 0.02) ; turn-on bandwidth (define theta (/ pi 4)) (define kx (* fcen (sin theta))) (set! k-point (vector3 kx 0 0)) (define (my-amp-func p) (exp (* 2 pi kx (vector3-x p (set! sources (list (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Ez) (center 0 (* -0.5 s)) (size s 0) (amp-func my-amp-func (define-param T 400) ; run time (run-until T (at-beginning output-epsilon) (at-end output-efield-z)) Kind Regards, Matt On Mon, 12 Feb 2007, Steven G. Johnson wrote: On Mon, 12 Feb 2007, matt wrote: 1) is the purpose of the amp-func/wide source combo equivalent to having several phase shifted source points of zero width placed closely next to one another? Yes. Or rather, the purpose is to emulate infinitely many phase-shifted source points placed in a continuous unbounded region. 2) in the non-periodic example with PML in x and y, the plane wave seems to propogate from the top left corner of the computation cell, but the sources are specified along the left and bottom (as opposed to left and top, which is more intuitive). Why? Probably you are just confused by how you are visualizing the function. If I remember correctly, the top-left of an h5topng image corresponds to (x,y) = (0,0), with y increasing downward. 3) an oblique plane wave should have an x and y component. What I understood from your suggestions was that only one source will achieve this. Is that correct? That's correct. The other field components will be generated automatically via Maxwell's equations. (This is a consequence of symmetry...) Cordially, Steven G. Johnson ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] oblique plane wave scattering
Hello, I have a question about an older post to the list. The original poster was interested in oblique scattering of a plane wave on a crystal. The solution offered in the previous mailing can be used to find transmission and reflection due to a single element, but this is not what the original poster requests. The original request was for scattering due to a periodic structure (eg., a standard grating problem). Because of the PML boundaries in the proposed solution, the result is not periodic. Is it possible to have an oblique plane wave with periodic boundaries? The only way I can think to do this is to use a total/scattered field approach. Another post recommends a solution, but leaves out all detail: From http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/347/match=total+scattered+field There is no built-in support for this currently (in my own work I rarely need incident plane waves except in cases with periodic boundaries where it is easy). In principle this should be possible by using a box of appropriately-chosen E and H current sources, but that requires some attention to detail. Can anyone elaborate on this approach? As a side question, how would alter the code in the reply to acheive a plane wave at a different angle (e.g., 21 degrees of incidence, instead of 45?) Kind Regards, Matt --- From: Steven G. Johnson [EMAIL PROTECTED] Subject: Re: oblique scattering Newsgroups: gmane.comp.science.electromagnetism.meep.general Date: 2006-07-31 14:35:11 GMT (27 weeks, 6 days, 2 hours and 27 minutes ago) Mon, 31 Jul 2006, emil vinteler wrote: I want to calculate transmission and reflection spectrum in oblique scattering at angle 50 degrees from square lattice of polystiren spheres. I used the following ctl file, but I'm not sure if it's correct. Please tell me if I'm wrong. There are several problems with your file. First, just setting the k-point is not enough to get an angled source. The k-point only determines the boundary conditions of your simulation, and does not affect source planes. If you want a source plane where the amplitude varies as exp(ikx), you need to specify this yourself using the amp-fun property. See, for example, the attached file. Second, your k vector isn't correct, because the magnitude of k depends on the frequency. Remember, omega = c |k| in vacuum. Third, because the magnitude of k depends on the frequency, you can't make a single source that produces light with a single angle (other than normal incidence) over a broad bandwidth, as your control file attempts to do. You need to use a narrow-bandwidth source, and do multiple simulations if you want a transmission spectrum at a given angle. Good luck. Cordially, Steven G. Johnson ; This example creates an approximate TM planewave in vacuum ; propagating at a 45-degree angle, by using a couple of current sources ; with amplitude exp(ikx) corresponding to the desired planewave. (define-param s 11) ; the size of the computational cell, not including PML (define-param dpml 1) ; thickness of PML layers (define sxy (+ s (* 2 dpml))) ; cell size, including PML (set! geometry-lattice (make lattice (size sxy sxy no-size))) (set! pml-layers (list (make pml (thickness dpml (set-param! resolution 10) ; pw-amp is a function that returns the amplitude exp(ik(x+x0)) at a ; given point x. (We need the x0 because current amplitude functions ; in Meep are defined relative to the center of the current source, ; whereas we want a fixed origin.) Actually, it is a function of k ; and x0 that returns a function of x ... (define ((pw-amp k x0) x) (exp (* 0+1i (vector3-dot k (vector3+ x x0) (define-param fcen 0.8) ; pulse center frequency (define-param df 0.02) ; turn-on bandwidth (define-param kdir (vector3 1 1)) ; direction of k (length is irrelevant) (define k (vector3-scale (* 2 pi fcen) (unit-vector3 kdir))) ; k with correct length (define kxcos (vector3-x (unit-vector3 k))) ; direction cosine of k in x (define kycos (vector3-y (unit-vector3 k))) ; direction cosine of k in x (set! sources (list ; left (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Ez) (center (* -0.5 s) 0) (size 0 s) (amp-func (pw-amp k (vector3 (* -0.5 s) 0 ; bottom (make source (src (make continuous-src (frequency fcen) (fwidth df))) (component Ez) (center 0 (* -0.5 s)) (size s 0) (amp-func (pw-amp k (vector3 0 (* -0.5 s) )) (define-param T 400) ; run time (run-until T (at-end output-efield-z)) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
Re: [Meep-discuss] epsilon function (c vs. libctl)
Hi Steven, Yes, you're correct. For completeness, here are the results for the coarser resolution. Indeed, it seems that a higher resolution reduces the epsilon discrepancies. 20ppw [C++ finds one duplicate for a total of 12 points, libctl got 11 points. Duplicate was manually removed] libctl C++ Pct Diff a b abs(a-b)/a*100% 0.46600 0.46937 0.722231 0.63847 0.63490 0.558944 0.70052 0.69812 0.343073 0.70365 0.70135 0.327254 0.81999 0.81604 0.481117 0.86852 0.86694 0.181721 0.89094 0.89110 0.017461 0.94510 0.94228 0.298920 0.98007 0.97293 0.728422 0.98870 0.98235 0.641928 0.99296 0.99775 0.482598 80ppw (from previous email) libctl C++ Pct Diff a b abs(a-b)/a*100% 0.46864 0.46867 0.0080870 0.63829 0.64327 0.7806107 0.64429 0.64847 0.6479023 0.70878 0.70899 0.0293657 0.83324 0.71024 14.7610847 0.83853 0.83288 0.6739258 0.88855 0.88819 0.0403651 0.91237 0.91270 0.0363838 0.95640 0.95648 0.0079315 0.96689 0.96746 0.0589339 0.99507 0.99884 0.3790904 Perhaps a better way to check this is to examine the number of epsilon discrepancies using h5diff. (eg., 'h5diff ctl.20.h5 cpp.20.h5 -d .1') for 20ppw, the data set is 20x240 = 4800 points. for 80ppw, the data set is 80x960 = 76800 points. 20ppw%age of 480080ppw %age of 76800 no -d 192 4 %784 1.02% -d .1 80 1.67% 348 0.45% -d 124 0.5%68 0.09% For this particular example, increasing the resolution by a factor of four reduced the normalized discrepancy count between the cpp and ctl versions approximately by a factor of four. Best Regards, Matt On Tue, 17 Oct 2006, Steven G. Johnson wrote: On Tue, 17 Oct 2006, matt wrote: Increasing the resolution should minimize the errors you describe, so let's try changing the resolution of the example from 20 to 80. Note that the comparison you posted was incomplete, because you didn't show the differences for a resolution of 20 to see whether 80 was indeed smaller. ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] epsilon function (c vs. libctl)
Hello,
I'm trying to reproduce the results of the band diagram calculation on
the example page using the c interface.
holey-wvg-bands example:
http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial/Band_diagram%2C_resonant_modes%2C_and_transmission_in_a_holey_waveguide#Band_diagram
I noticed that my c results are not quite the same as the libctl
results, and I was trying to figure out why.
h5topng showed no obvious differences in dielectric functions, but a
closer inspection using h5diff revealed some significant differences,
apparently near the boundary of the cylindrical hole.
I checked to see if the conditions were possibly incorrect (perhaps I
should use = and not ) but this did not seem to have an effect.
c snippet:
double resolution = 20; // pixels per distance
const int sy = 12;
const double cellwidth = 1.0;
const vec center = vec((cellwidth / 2),(sy/2));
const double width = 1.2;
const double rad = 0.36;
const double epsr = 13.0;
double eps(const vec p) {
vec r = p - center;
if (abs(r.y()) = (width / 2) abs(r) rad)
return epsr;
else return 1.0;
}
Best Regards,
Matt
___
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] frequency spectra for arbitrary grid points
Hello, Is it possible to calculate spectra from a single point, using get-field-point, or only for flux regions? If so, how? Is there some disadvantage to using a single sensor point? Kind Regards, Matt ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] reintroducing units in meep
Excellent. If it helps anyone else, here's a new version incorporating Steven's suggestions. Best Regards, Matt (define-param unit 1e-3); base unit in meters (1e-3 = 1 mm) (define-param fh 3e9) ; frequency in hertz (define-param res_ppw 20) ; resolution in pixels per wavelength (define-param num_periods 10) ; number of periods to let simulation run for (define lam (/ 3e8 fh)) ; free space wavelength (meters) (define lamu (/ lam unit)) ; wavelength in base units (define fcen (/ unit lam)) ; source center frequency (define-param csize (* lamu 8)) ; make the cell size 8*lambda (set! geometry-lattice (make lattice (size csize csize no-size))) (set! geometry (list (make block (center 0 0) (size csize csize no-size) (material air (set! pml-layers (list (make pml (thickness 100 (set-param! resolution (/ res_ppw lamu)) ; set temporal width equal to 2 wavelength (set! sources (list (make source (src (make continuous-src (frequency fcen) (width 20))) (component Ez) (center 0 0 (use-output-directory) (run-until (* num_periods lamu) (at-every (/ lamu 10) (output-png Ez -S 2 -Zc dkbluered))) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] reintroducing units in meep
Hello, I'd like to reintroduce units in meep, but I'm not getting the results I'm expecting. Following the description in Units in Meep, let's say it's convenient for me to specify distances in millimeters. For a source frequency of 3 GHz, free space lambda is .1 meters, or 100 mm. The description tells me that I want to set the source frequency to 1/100 = .01. Next I define the cell size to be something large enough that I can see how long a wavelength is, but not so large that it takes a long time to compute. Let's make it half a wavelength. First I convert lambda to the base length I chose (1 mm), then divide by 2. The result I get is appears to have a wavelength which is much smaller than the size of the computation cell. (Also, something else I didn't understand, the source appears to turn off quickly, even though I don't specify a turn off time). Any ideas on where I'm going wrong here? Best Regards, Matt (define unit 1e-3) ; base unit in meters (1e-3 = 1 mm) (define fh 3e9) ; frequency in hertz (define lam (/ 3e8 fh)) ; free space wavelength in meters (define fcen (/ unit lam)) (define-param csize (/ (/ lam unit) 2)) ; make the cell size lam/2 (define-param eps 1) (set! geometry-lattice (make lattice (size csize csize no-size))) (set! geometry (list (make block (center 0 0) (size csize csize no-size) (material air (set! pml-layers (list (make pml (thickness 10 (set-param! resolution 10) (set! sources (list (make source (src (make continuous-src (frequency fcen))) (component Ez) (center 0 0 (use-output-directory) (run-until 200 (at-every 1.0 (output-png Ez -Zc bluered))) (exit) ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
[Meep-discuss] Re: [MayaVi-users] isosurface config hangs on inf dimension (fwd)
Hello, It seems that meep 0.9 + (output-dielectric) + h5tovtk doesn't output metals as very large negative values, but rather as inf values. mayavi doesn't like that (see forwarded message below). The simplest solution is to take h5tovtk -a output and simply replace all inf values with some other value, by doing this for example: sed -i s/inf/-1e20/g 2drods1-eps-00.00.vtk The disadvantage here is that you're forced to use ascii vtk output, and as stated in the h5tovtk man page, this not as compact as binary output. I'm a beginner at mayavi/vtk. Is there a better technique for viewing metallo-dielectric structures than using IsoSurface modules in mayavi? Kind Regards, Matt -- Forwarded message -- Date: Sun, 27 Aug 2006 09:49:31 -0400 From: Prabhu Ramachandran [EMAIL PROTECTED] To: Matt [EMAIL PROTECTED] Cc: mayavi-users@lists.sourceforge.net Subject: Re: [MayaVi-users] isosurface config hangs on inf dimension Matt == Matt [EMAIL PROTECTED] writes: Matt When I try adding an IsoSurface module for the attached Matt structure, the IsoSurface config window opens (sans topmost Matt horizontal scroll bar) and mayavi hangs. Matt The data contains very large negative values. In the Matt configure panel, Iso-surface value is filled in with the Matt value inf, minimum contour 1.0, and maximum contour inf. I would suggest you write out your data into ASCII VTK files before you play with binary file formats. VTK will not handle inf and nan values gracefully. When VTK reads your data file it thinks the minimum value of the scalars is 1.0 and the maximum is inf. Clearly, according to you, this is wrong. Matt It seems that mayavi only hangs with inf values present. Matt Is this a bug, or is there a workaround? I would suggest that you remove infs and nans from the data before you use VTK/MayaVi. cheers, prabhu ___ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
