[Meep-discuss] Meep installation notes for macOS Sierra, July 2017

[Filip Dominec]

[On behalf of John Weiner, I forward his experience with installation
of MEEP on Mac OS. John's kind contribution follows. -- Filip]

Dear Meep Users and Developers,

I have been able to install meep-1.3 on two different iMacs (one in
Washington DC( Sierra 10.12.5) and the other in Paris (Sierra 10.12.6)
during the month of July 2017.  This message recounts what I did.  I
hope it works for you, but even in these two very similar
circumstances the tactics for a successful build was not exactly the
same.  I hope it proves useful to users who want to install meep on
macOS.

The point of departure was the “installation guide for Sierra based on
HomeBrew" in meep-discuss,
 https://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg05719.html

I also used HomeBrew to install some of the prerequisite packages.

1. Install home-brew if you don’t already have it.  You can get it
googling for the home-brew web site.  It is a package handler
analogous to apt or apt-get in Ubuntu Linux.

2. Open a terminal session and, once home-brew is installed,

brew doctor  (analyses the system for potential conflicts and problems)
brew update (update all the home-brew packages.

3. brew install libunistring, pkg-config, libffi, bdw-gc, readline,
hdf5, openblas, fftw, gsl, automake, and autoconf.  Some of these
packages might be already on your system.

4. The Washington iMac seemed to require the installation of gettext
as well the packages above, so you might as well install getttext.

5. Download from the gnu index site the tarball for guile-2.0.11.  Any
version later than this one generates errors in meep.  Don’t install
guile with home-brew.  Even if you specify the guile-2.0 series,
home-brew will install guile-2.0.14, which does not work with meep.

6. The build of guile-2.0.11 was the hardest part of this task.  The
overall method is the typical unix install procedure:
after extracting the tarball with tar-xvd, cd to the guile-2.0.11 
directory.
You should find an executable configure file.  The command is 
./configure
By default the installation will be in /usr/local.  If you want it
somewhere else, on the ./configure command line: prefix=/your/prefix.
On the same ./configure command line set LDFLAGS and CPPFLAGS with
all the relevant paths for the previously installed prerequisites so
that the compiler and linker will be able to find   the lib and
include directories.  Home-brew instalsl a symlink in /usr/local/opt
for most (but not all) of the installed programs.
You also should specify on the ./configure command line LIBFFI_CFLAGS
for the include directory and LIBFFI_LIBS for the static and dynamic
libraries where ffi can be found.  For some reason ffi seems to
require these   additional environmental variables in order to find
the latest version of ffi.

7. Take a deep breath and press return.  If the configure script runs
to completion, breath a sigh of relief and go on to make.  If not, you
can cat config.log|grep “some key word" to see what wentwrong.

8. If you get to make, take another deep breath. You will see lots of
warnings, but the make will only stop with errors.  At first I got a
lot of errors from “missing symbols”, but it was because I had
forgotten to add an l flag (for dynamic libraries) to the
LDFLAGS="-L/path/to/ffi.  It should be LDFLAGS=-L/path/to/ffi -lffi”.

9. A persistant error was due to the stime.c file in
…/libguile/stime.c that comes with the tarball.  This is a documented
bug in guile-2.0.11 and there is a patch somewhere that is supposed to
work.  However, I just downloaded and extracted the current version of
guile (2.2.2) and copied the stime.c file to my
…/guile-2.0.11/libguile directory and did the configure and make
sequence again.  That solved the problem for me.  The make command can
be run with make V=1 to see the details of what is going on at each
step.  For linker problems I found it useful to actually see what lib
and include paths the linker was actually using and in what sequence.

10.  The last step is sudo make install.  I had not problems with this
step if I was able to get that far.

11.  A quick check that guile is working is to type at the prompt,
guile —version.  You should get the guile prompt with the version
information.  It should be 2.0.11.

12. Once the guile hurdle was overcome the rest was relatively straightforward.

13. From the meep ab initio site you can get the tarballs for h5utils,
harminv, libctl, mob, and meep.  You need to get the libpng-1.4.20
package from the download site.  The configure, make, sudo make
install went smoothly without a lot of LDFLAGS and CPPFLAGS
specifications.

14. Finally I typed meep and got the prompt and the correct version.
Then I went through the meep abi initio tutorial and everything worked
as expected.  When meep runs you get a “some stuff is   deprecated”
message at the end, but for now at least it does not interfere with
mee

Re: [Meep-discuss] TE polarized photonic band structure of metallic photonic crystals

[Filip Dominec]

Hi, would you please describe to all what is the reported issue with
the TE mode?
Filip

2017-01-19 11:00 GMT+01:00, Aliasghar Sedghi :
> Dear meep users,
> I have calculated the band structure of PCs composed of metallic rods
> (Drude model) embedded in an air background using meep. There is no
> problem for TM mode (Ez) but I don't know why it is wrong for TE mode
> (Hz). The ctl file is attached.
> Regards,
> Aliasghar
>

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

Re: [Meep-discuss] Compiling Meep 1.3 on Debian 8.5 (uniprocessor, not MPI); First three tutorials

[Filip Dominec]

nitio.mit.edu/wiki/index.php/Harminv
>
>  (The last change to this page was in 2015-03-31.)
>
>I downloaded:
>
>   http://ab-initio.mit.edu/harminv/harminv-1.4.tar.gz
>
>and untargzipped it to:
>
>   /xx/meep-build/harminv/harminv-1.4/
>
>From there:
>
>   ./configure
>
>seemed to run OK to the point of an error:
>
>cannot compile a simple Fortran program
>
>By right clicking the gfortran-4.9 item in Synaptic and selecting
>Properties > Installed files, I ascertained that the compiler was:
>
>/usr/bin/gfortran-4.9
>
>Following the instructions on the Harminv installation page, I gave
>this command instead:
>
>   ./configure F77=/usr/bin/gfortran-4.9
>
>This produced the Makefile and no errors.  Then I could give the next
>command:
>
>   make
>
>Next, for the installation command to run as root I want to be able
>to give this command from a non-root shell:
>
>   sudo make install
>
> (See my 2015-04-20 email for how I has set up my mortal account
>  a sudoer.)
>
>
> GNU Guile
>
>   Searching Synaptic for "guile" indicated that no packages with names
>   including "guile" had been installed.  The minimum version for Meep
>   is 1.6.  I installed:
>
>  guile-2.0  2.0.11+1-9
>  guile-2.0-libs 2.0.11+1-9
>  guile-2.0-dev  2.0.11+1-9  (This brought in many other packages.)
>
>
> libctl
>
>   I installed these packages.
>
>libctl-dev   3.2.2-2
>libctl-doc   3.2.2-2
>libctl5  3.2.2-2
>
>
>
> HDF5  (This is where the trouble begins . . .   I did this next set of
> installations, but I suggest that you don't.  See my notes below
> starting at AAA for how to compile HDF5 for uniprocessor AKA "serial"
> systems, that is not MPI meep.)
>
>   I installed:
>
> h5utils 1.12.1-2.1+b2
>
>   which brought in:
>
> hdf5-tools  1.8.13+docs-15+deb8ul
> libhdf5-8   1.8.13+docs-15+deb8ul
>
>   Since we want the -dev packages too, I installed:
>
> libhdf5-dev 1.8.13+docs-15+deb8ul
>
>   which brought in:
>
> hdf5-helpers1.8.13+docs-15+deb8ul
> libhdf5-cpp-8   1.8.13+docs-15+deb8ul
> libjpeg-dev 1:1.3.1-12
> libjpeg62-turbo-dev 1:1.3.1-12
>
>   I have no real idea what these packages are, other than that the
>   H5utils are vital for using Meep:
>
>  http://ab-initio.mit.edu/wiki/index.php/H5utils
>
>   I later recognized that Meep uses a shared library for the many
>   HDF5 functions it typically has, and which most people want.
>   This set of packages turned out to be incompatible with the Meep
>   configure system.  I discuss this, and the fix for it, below.
>
>
> From http://ab-initio.mit.edu/wiki/index.php/Meep_download I downloaded
> meep-1.3.tar.gz and untargzipped it to:
>
>   /xx/meep-build/meep-1.3/
>
>
> and from there:
>
>   ./configure F77=/usr/bin/gfortran-4.9
>
> There were no errors.  Then:
>
>   make
>   sudo make install
>
> This all went without errors, which is quite remarkable considering how
> many packages are required.  Then I ran the self-tests:
>
>   make check
>
> The known_results test took less than 3 minutes.  (7 minutes last time,
> but the machine's memory system was running slower then.)  One test -
> near2far - failed.  This concerns the new feature added in 1.3:  "New
> near-to-far-field functionality: given a bounding surface, automatically
> computes the Fourier-transformed field in any desired grid of
> 'far-field' points arbitrarily far away."  As instructed, I am about
> to email the test results to m...@ab-initio.mit.edu.  I will send the
> file meep-1.3/tests/near2far.log.
>
> I also dumped the help material in Meep's configure file:
>
>   ./configure --help > configure-help.txt
>
>
> However, all was not well . . .  I should be able to run the interactive
> commands at the start of the tutorial:
>
>   http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial
>
> - - - -
>
> (set! geometry-lattice (make lattice (size 16 8 no-size)))
>
> (set! geometry (list
>   (make block (center 0 0) (size infinity 1 infinity)
> (material (make dielectric (epsilon 12))
>
> (set! sources (list
>  (make source
>(src (make continuous-src (frequency 0.15)))
>(component Ez)
>(center -7 0
>
> (set! pml-layers (list (make pml (thickness 1.0)))

Re: [Meep-discuss] trying to find charge density of metamaterials

[Filip Dominec]

Hi, assuming you are able to compute a time-domain simulation of the
metamaterial unit cell, there should be no big problem to 1) resolve
the resonance frequencies of each mode, then to 2) switch to a
narrow-band source with the actual frequency of the mode you are
interested in, 3) record the electric field in the volume just after
the source terminates, and to 4) resolve the charge density as the
divergence of the electric field vector (vector processing and
visualisation is possible, e.g., with Paraview).

It should typically detect sharp peaks at metallic edges and corners,
while the Mie resonances in dielectric resonators should be relatively
weaker. For ordinary metamaterial designs, one gains some intuition
about this quite fast. I do not think there would be any challenging
science in solving Maxwell equations for a metamaterial unit cell.

Regards
Filip

2016-10-26 5:51 GMT+02:00, Heligman, Daniel M. :
> Hi,
>
>
> I was wondering if there is a way to find the charge density or near-fields
> in metamaterials from a simulation. I am trying to find the charge density
> at the resonant frequency.
>
>
> Best,
>
> Daniel Heligman
>

___
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-discuss Digest, Vol 127, Issue 1

[Filip Dominec]

Excuse my little advertisement, but here I have written script that
compiles the freshest version of MEEP on your Ubuntu system:
https://github.com/FilipDominec/python-meep-install/blob/master/python-meep-install.sh

It was tested on many systems and it should work out-of-the-box also
on your version of Ubuntu. If you are not going to use python-meep,
you can spare some megabytes skipping the last few lines of the
script.

Regards,
Filip


>> Message: 1
>> Date: Thu, 6 Oct 2016 14:13:00 + (UTC)
>> From: Muhammad Hanif Ahmed Khan Khushik 
>> To: "meep-discuss@ab-initio.mit.edu" 
>> Subject: [Meep-discuss] Complete list of STEPS to install meep on
>> ubuntu  14.04 LTS version
>> Message-ID: <688363784.9349489.1475763180...@mail.yahoo.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello everyoneI installed meep sometime before on ubuntu on VMware. I
>> found my laptop's processing time was increased.So I decided to purchase
>> a
>> new laptop with only ubuntu on it. Now  I have a laptop with ubuntu as
>> its
>> operating system. I am feeling difficulty in installing meep and its
>> various packages as I have forgotten the steps which I toop to install
>> meep
>> last time. Is there any document which illustrates all the steps to
>> install
>> meep along with all the necessary and supporting packages. If there is
>> any
>> kindly help me. If there is no any can any one make it this will be
>> helpful
>> for all the people who want to work on meep. I think one of the most
>> tricky
>> part to work on meep is its installation. Waiting for someone's quick
>> and
>> helpful reply
>>
>> RegardsKhushk

___
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 about permittivity and permeability

[Filip Dominec]

Hi, since MEEP uses relative permittivity and permeability which have
no physical dimension, there is no need to convert units.

Filip



2016-09-16 22:43 GMT+02:00, Heligman, Daniel M.
:
> Hi,
>
>
> I have a simple question. Is the a conversion between SI and meep units for
> permittivity and permeability or are they the same in meep units?
>
>
> Best,
>
> Daniel Heligman
>

___
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 slow after Ubuntu 16.04 upgrade

[Filip Dominec]

If you disable subpixel averaging, does the computational time return
to usual values?

2016-09-01 14:47 GMT+02:00, Jisha C P :
> Hello,
> Thank you for your reply.
> Currently, the code is without multi-processing. With multiprocessing with
> 2 cores, time needed is reduced by little over half.
> I do use hdf5 export, but only at the end and the time needed is
> negligible.
> The problem is at the "initialization", which seems to run for ever
> printing subpixel averaging. Once it is done, the time stepping runs
> normally without taking too much time.
> Other computational tools are running normally, for example matlab, I have
> not seen any performance drop after the Ubuntu upgrade.
> Best regards,
> Jisha
>
>
> On Thu, Sep 1, 2016 at 2:13 PM, Filip Dominec 
> wrote:
>
>> Hi,
>> 1) Do you use multiprocessing?  If so, which implementation, MPICH or
>> OpenMPI?
>> 2) Do you use HDF5 export? If so, which kind of HDF libraries,
>> MPI-enabled or "serial"? The latter is known to be very slow when used
>> in multiprocessing setup, though they should not alter subpixel
>> averaging.
>> 3) Did the FDTD time-stepping speed drop, too, or is it just the
>> initialization? Did you observe performance drop with other
>> computational tools as well?
>>
>> Filip
>>
>>
>>
>

___
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 slow after Ubuntu 16.04 upgrade

[Filip Dominec]

Hi,
1) Do you use multiprocessing?  If so, which implementation, MPICH or OpenMPI?
2) Do you use HDF5 export? If so, which kind of HDF libraries,
MPI-enabled or "serial"? The latter is known to be very slow when used
in multiprocessing setup, though they should not alter subpixel
averaging.
3) Did the FDTD time-stepping speed drop, too, or is it just the
initialization? Did you observe performance drop with other
computational tools as well?

Filip


2016-09-01 9:48 GMT+02:00, Jisha C P :
> Dear MEEP users,
> My MEEP codes are running slower after I upgraded to Ubuntu 16.04 from
> 14.04. Earlier if a code took, for example, 1 minute to run, the same code
> now takes 10 minutes to run.
> Does anyone else have this problem?
> There are no errors, but the subpixel averaging is now taking much longer
> to finish than before.
> Any suggestion to fix this is appreciated.
> Thank you.
> Best regards,
> Jisha
>

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

Re: [Meep-discuss] LDOS calculation in Python-Meep

[Filip Dominec]

Dear Eduardo,
I marked your question as
https://github.com/FilipDominec/python-meep-utils/issues/5 and will
try to find a solution in python-meep.

Filip

2016-08-31 11:55 GMT+02:00, EDUARDO CABRERA GRANADO :
> Dear Meep community,
>
> I am a complete begginer with MEEP and currently I am trying to test the
> capabilities of the Python-Meep interface to carry on some simulations. I
> have been trying to calculate LDOS by adding to the code the following
> lines to my code:
>
> ldos = meep.dft_ldos(freq-fwidth/2, freq + fwidth/2, Nfreq)
>
> where freq is the central frequency of the Gaussian source, fwidth its
> bandwidth and Nfreq the number of frequencies in that interval where LDOS
> is calculated.
>
> Then, at each temporal step I added
>
> ldos.update(f)
>
> "f" being the fields created with meep.fields,
>
> The object ldos has the method ldos (ldos.ldos) which, I assume, it should
> store the values of the ldos calculated. However, trying to access them
> gives:
>
> Swig Object of type 'double *' at 0x7f5dacdc6e10
>
> Looking around it seems that swig cannot determine the size of the array so
> there is not access to its values from Python (
> http://stackoverflow.com/questions/5822529/swig-returning-an-array-of-doubles).
> Modifying the swig file scares me a little bit (quite
> a lot actually).
>
> So my questions are: am I right or am I doing something wrong?. Is there
> any workaround to get the values of the ldos calculation in Python-Meep or
> Scheme or C++ interface for MEEP are needed to get them?. Anyone tried this
> before?.
>
>
> Thank you in advanced for any help!
>
> Eduardo
>
> P.S. Thanks a lot also to the developers of MEEP and specially to Filip
> Dominec for his excellent python-meep-utils and materials scripts.
>

___
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 Source

[Filip Dominec]

Dear Craig,
if I do not miss something, you may easily define a (perpendicular or
even oblique) plane wave source as shown in
https://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg03088.html

F.

2016-08-26 7:51 GMT+02:00, Craig Milde :
> Hi meep discussion list,
>
>
> I am attempting to set up a plane wave source in meep and am considering
> possibilities for how to do it.
>
>
> The way I am attempting to do it is by setting up many Gaussian sources in a
> line near the boundary, then using periodic boundary conditions so that
> these sources repeat outside of the grid, making a plane wave.
>
> The issue with this is it's creating some very unfriendly code, which I
> believe could be handled nicely with a for-loop.
>
> My code right now looks like this:
>
>
> (set! sources
>
>(list
>
>   (make source
>
>   (src
>
>   (make gaussian-src
>
>   (wavelength waveLeng)
>
>   (fwidth df)
>
>   )
>
>   )
>
> (component Ey) (center 0 60 0)
>
>   )
>
>
>   (make source
>
>   (src
>
>   (make gaussian-src
>
>   (frequency fcen)
>
>   (fwidth df)
>
>   )
>
>   )
>
>   (component Ey) (center 1 60 0)
>
>   (make source 3,4,5,6,7... etc)
>
>   )
>
>)
>
> )
>
>
> Does anyone know if there is a way to handle this like
>
>
> (set! sources
>
>(list
>
>   (for (y=0; y
> (make source
>
> (src
>
> (make gaussian-src
>
> (wavelength waveLeng)
>
> (fwidth df)
>
> )
>
> )
>
>  )
>
>  (component Ey) (center 0 y 0)
>
>   )
>
>)
>
> )
>
> or perhaps knows if there is another way to nicely input a plane wave
> Gaussian source?
>
>
> Thanks very much,
>
> Craig
>

___
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 output interpretation

[Filip Dominec]

Dear Craig,
from your e-mail it is not clear what steps you actually tried to
extract the field data from the HDF file. Can you run, e.g., this?

h5tovtk input.h5 -o output.vtk
paraview output.vtk

You should be able to add some monitor plane in paraview and browse
the field records as you wish.
Filip


2016-08-11 0:19 GMT+02:00, Craig Milde :
> Hello MEEP discussion list,
>
>
> My name is Craig, I'm an undergraduate studying physics and started working
> with MEEP recently but am having some issues with interpretation of data.
>
> I'm trying to run a simulation and output the various components like
> e-field,h-field. When I get output it comes in an .h5 file format that is
> very large (150mb/field)
>
> When I try to read the electric field outputs with MATLAB I get confusing
> information like:
>
> HDF5 e-000200.00.h5
> Group '/'
> Dataset 'ex.i'
> Size:  1521x2101
> MaxSize:  1521x2101
> Datatype:   H5T_IEEE_F64LE (double)
> ChunkSize:  []
> Filters:  none
> FillValue:  0.00
>
>
> I was hoping I would be able to view the electric field's values in each Yee
> cell at set time steps, but perhaps I am misunderstanding MEEP.
>
> I will include my code also:
>
>
> (set! geometry-lattice(make lattice (size 210 152 no-size))); this sets up
> the domain space with default space being air (epsilon = 1) and infinite in
> the z-dir
> (set! pml-layers (list(make pml (thickness 10) (direction X) (side High;
> this sets up a PML 10 layers thick at the x+ boundry
> (set-param! resolution 10)
> (set! k-point (vector3 1 0 0)); by initializing this vector, it sets up
> periodic (bloch) conditions by default along all the bdrys and by setting
> ky=kz=0, we are only allowing wavevectors to propogate in the x-dir
> *(set-param! time-step-dt 0.01); sets the time-step
> (define-param fcen 1.0); pulse center freq.
> (define-param df 2.0); pulse width freq.
> (set! sources (list (make source (src (make gaussian-src (frequency fcen)
> (fwidth df))) (component Ey) (center 0 76 0; places a TM-polarized
> plane-wave source (I think) @ (0, 76, 0)
>
> (set! geometry (list (make block (center 100 0 0) (size 100 33 infinity)
> (make dielectric (epsilon -2.522) (E-susceptibilities (make
> drude-susceptibility (frequency 0.0333) (gamma 0.000226) (sigma 1)
> (make block (center 100 61 0) (size 100 30 infinity) (make dielectric
> (epsilon -2.522) (E-susceptibilities (make drude-susceptibility (frequency
> 0.0333) (gamma 0.000226) (sigma 1)
> (make block (center 100 119 0) (size 100 33 infinity) (make dielectric
> (epsilon -2.522) (E-susceptibilities (make drude-susceptibility (frequency
> 0.0333) (gamma 0.000226) (sigma 1)
> )); This places blocks of dispersive silver in the center of the
> 'waveguide'
>
> (set! geometry (list (make block (center 100 33 0) (size 100 28 infinity)
> (make medium (epsilon 7.835) (D-conductivity (/ (* 2 pi 0.0334 0.392)
> 7.835 (make block (center 100 91 0) (size 100  28 infinity) (make medium
> (epsilon 7.835) (D-conductivity (/ (* 2 pi 0.0334 0.392) 7.835)); this
> sets up the dielectric layers
>
> (run-until 200
> (at-beginning output-epsilon)
> (at-end output-efield)(at-end output-hfield)(at-end output-bfield)(at-end
> output-dfield)(at-end output-sfield)); runs for 200 time steps.
>
>
>
> Can anyone shed some insight on how to get meaningful data out of MEEP? It
> seems very powerful and I would love to get more acquainted with it.
>
>
> Thanks to anyone for reading,
>
> Craig
>

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

Re: [Meep-discuss] 3D Plane Wave source

[Filip Dominec]

Dear Saket, just define the source amplitude as a harmonic function,
with the periodicity corresponding by the desired transverse component
of the wave vector. Filip

2016-07-27 21:03 GMT+02:00, saket wankhade :
> Dear meep users,
>  I need a tilted plane wave source with both Ex and Ez
> component in my simualtion. Does anyone have idea how to deal with it ?
>  Any suggestion would be greatly appreciated.
>
> Thank you!
>

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

Re: [Meep-discuss] Getting grid points/time points of meep simulation

[Filip Dominec]

Maybe it helps somebody if I mention that the python-meep interface 
solves the previous questions, since
1) each individual time step is accessible within a cycle (see 
https://github.com/FilipDominec/python-meep-utils/blob/master/scatter.py#L88), 
and
2) for every point in the grid, MEEP calls a custom routine during the 
structure definition (see e.g. 
https://github.com/FilipDominec/python-meep-utils/blob/master/metamaterial_models.py#L81)


At the same moment I should add that the python-meep interface is not 
oficially supported and may miss some of the features that are provided 
by libctl in the Scheme-based interface.

Regards,
Filip

On 28.6.2016 21:31, John B. Sigman wrote:

Thanks Mischa!

What about getting time points?
I’ve had a nightmare of a time getting it to do this elegantly for time, too. 
Currently I’m calling another step function:

   (at-beginning output-grid-points)
   (during-sources (to-appended "ex" (at-every 0.05 output-efield-x))
   (to-appended "time" (at-every 0.05 
output-time-points))
   )

which call the functions:

(define (get-coordinates r eps)
   (vector3-z r))
(define (get-time r eps)
   (meep-round-time))
(define (output-grid-points) (output-field-function "grid-points" (list 
Dielectric) get-coordinates))
(define (output-time-points) (output-field-function "time" (list Dielectric) 
get-time))



but it is still very contrived to access this data. There don’t seem to be any 
documents on how to write your own hdf5 output functions, or how exactly the 
predefined ones work.



On Jun 25, 2016, at 5:14 PM, Mischa Megens  wrote:

Hi John,

I suppose a convenient way to get grid points would be to use
(output-real-field-function name cs func)
Define the function to return the coordinate component you are
interested in, i.e.,
(define (f r eps) (vector3-x r))
It might even work without the eps, I haven't tried.
The reference page
http://ab-initio.mit.edu/wiki/index.php/Meep_field-function_examples
gives some more details.

Success,
Mischa


On 6/24/2016 6:48 PM, John B. Sigman wrote:

This has been asked several times in the help forums, but seems to be 
unanswered. Is there an elegant way to get grid points and time points for the 
field values I output?

Other than, of course, tracking the simulation I set up and reconstructing the 
(assumed) linear points in between the boundaries?

Thanks
Johnny
___
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] Compuation of electric field

[Filip Dominec]

Hi, I would rather guess the images Saket gets are really full black, 
which would mean that there are "NaN" values in the output of the 
computation. This may result from some numerical instability. I suggest 
to try first to halve the simulation time until the field gets finite. 
Then one can determine where the instability starts.


Filip



On 5.6.2016 16:09, David Kleiven wrote:

Hi

by black images, do you mean greyscale images?
If so, you can change the colormap by adding the -Zc option. To use 
the dkbluered map you can add /-Zc dkbluered/ as option to the h5topng 
command.


More info on colormaps: 
http://ab-initio.mit.edu/wiki/index.php/Color_tables_in_h5topng


This example works for me:
h5topng file.h5 -Zc dkbluered

Hope this helps.

David



On Sat, Jun 4, 2016 at 7:25 PM, saket wankhade 
mailto:saketwankh...@gmail.com>> wrote:


Dear meep users,
I am trying to compute electric field
distribution at wavelength 550nm.My problem is that I get black
images after applying h5topng command.Does any one have idea how
to deal with it ?

Here is my .ctl file a=1um ,lambda=550nm


(define-param resl 200);
(define-param dpml 0.5) ; thickness of PML layers
(define-param sx 0.07) ;
(define-param sz 0.07)
(define-param rad 0.03)
(set-param! k-point (vector3 0 0 0))
;(define sx0 (+ sx (* 2 dpml)))
(define sy 1);
(define sy0 (+ sy (* 2 dpml))) ;

(set! ensure-periodicity true)
(define background (make dielectric (epsilon 1.000 )))
(set! eps-averaging? false)
(set! force-complex-fields? false)
(set! Courant 0.5)
(set! output-single-precision? true)


(define gold (make dielectric (epsilon 1)
(polarizations
(make polarizability
(omega 1e-20) (gamma 0.042747) (sigma 4.0314e+41))
(make polarizability
(omega 0.33472) (gamma 0.19438) (sigma 11.363))
(make polarizability
(omega 0.66944) (gamma 0.27826) (sigma 1.1836))
(make polarizability
(omega 2.3947) (gamma 0.7017) (sigma 0.65677))
(make polarizability
(omega 3.4714) (gamma 2.0115) (sigma 2.6455))
(make polarizability
(omega 10.743) (gamma 1.7857) (sigma 2.0148))
)))


(set! geometry-lattice (make lattice (size sx sy0 sz)))
(set! geometry (list
 (make block (center 0 0 0) (size sx sy sz)  (material
background))
 (make sphere (center 0 0 0) (radius rad)
(material gold))
 ))




(set! pml-layers (list
(make pml (thickness dpml) (direction Y))
))

(set! sources (list
   (make source
 (src (make continuous-src (frequency 1.8181)))
 (component Ex)
   (center 0 0.3 0) (size sx 0 sz)
)
)
)


(set! resolution resl)


(define monitor-xy
(volume
(center 0 0 0)(size sx sy 0)
)
)

(define monitor-xz
(volume
(center 0 0 0)(size sx 0 sz)
)
)

 (run-until 200
   (in-volume monitor-xy (at-beginning output-epsilon))
(in-volume monitor-xy (to-appended "ex" (at-every 0.6
output-efield-x)))

)
 
***
Any suggestion would be greatly appreciated.

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



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

Re: [Meep-discuss] numerical instability in vacuum - no materials, no pml

[Filip Dominec]

Hi, whenever you set the phase in either the Y- or Z- symmetry to -1, 
the simulation eventually becomes unstable. I have tested out all four 
combinations for you, and I can tell that only (set! symmetries (list 
(make mirror-sym (direction Y) (phase 1)) (make mirror-sym (direction Z) 
(phase 1 is stable, though perhaps not what you expect.


Maybe the trouble is that the wave source apparently does not share the 
same symmetry as you impose on the simulation volume.


Four years ago I had similar issues which made me abandon the use of 
symmetries in MEEP entirely.


Filip


On 4.3.2016 14:40, Steve Byrnes wrote:

Hi all, I'm getting a numerical instability in meep with just a wave
traveling through a vacuum--no materials, no pml. Has anyone seen that
before? So far all I know is that the effect depends on the cell size
(subwavelength) and on the resolution and symmetries. Here is an example:
The fields start growing exponentially halfway though...
~
(define sim_size_yz .25)
(define sim_size_x 15)
(define freq 1.8)
(define freq_width 1)
(define extra_simulation_time 30)

(set! geometry-lattice (make lattice (size sim_size_x sim_size_yz
sim_size_yz)))

(set! resolution 30)

(set! k-point (vector3 0 0 0)) ; periodic boundary conditions

; wave is moving in x direction, with Ey and Hz nonzero
(set! symmetries (list (make mirror-sym (direction Y) (phase -1)) (make
mirror-sym (direction Z) (phase 1

(set! sources (list (make source (src
  (make gaussian-src
   (fwidth freq_width)
   (frequency freq)))
   (component Ey)
   (amplitude 2)
   (center 5 0 0)
   (size 0 sim_size_yz sim_size_yz


(run-sources+ extra_simulation_time
(at-every 1 (output-png Hz "-vZc dkbluered -M 1 -0z0")))
~
Did I do something wrong? What's the cause? Is there any trick to avoiding
this instability, other than trial and error?

Thanks in advance,
Steve
~~
Steven Byrnes
Physicist, Draper Laboratory, Cambridge, MA, USA
http://sjbyrnes.com/



___
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] Mesh size

[Filip Dominec]

Hi, it is directly in 
http://ab-initio.mit.edu/wiki/index.php/Meep_Reference, search for 
"resolution". The higher, the finer mesh.

Filip


On 11.2.2016 06:07, saket wankhade wrote:

Dear meep users,
   I know meep uses uniform meshing but  want to change size of it.Is it
possible to change meshing size?

   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] doubt regarding subpixel averaging behaviour

[Filip Dominec]

Dear Pablo, the things are complicated - in python-meep I am using,
the "averaging %" message appears even when averaging is explicitly
turned off. And it throws apparently random numbers. I think this is a
bug.

Important is whether the structure behaviour  is sensitive to
sub-pixel changes of geometry.
Filip

2015-09-21 19:49 GMT+02:00, Pablo Díaz Núñez :
> Dear Filip,
>
> well, I'm actually observing it in the output of the simulation. When it
> says: subpixel-averaging is a number percent % done, time remaining. For
> each case with 7 or less processors it works and for 8 processors it
> doesn't appear, so I'm guessing it is not working. I couldn't check if
> it's affecting my results yet.
>
> Pablo.
>
> El 21/09/15 a las 19:36, Filip Dominec escribió:
>> Dear Pablo, how exactly does the bug manifest? Can it be observed on
>> the exported permittivity, e.g. in Paraview? Or does the simulation
>> lose its sub-pixel precision with regards to some structure parameter?
>> Filip
>>
>> 2015-09-21 19:28 GMT+02:00, Pablo Díaz Núñez :
>>> Dear meep users,
>>>
>>> I have encountered a strange behaviour of subpixel averaging when
>>> running meep-mpi. Working at one node with 8 processors, if I do the
>>> simulation with 7 processors or less, subìxel averaging performs as it
>>> should be, but if I choose the 8 processors it won't work even
>>> eps-averaging is set to true.
>>>
>>> Does someone know why this happens?
>>>
>>> Thanks in advance,
>>> Pablo.
>>>
>>> ___
>>> 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] doubt regarding subpixel averaging behaviour

[Filip Dominec]

Dear Pablo, how exactly does the bug manifest? Can it be observed on
the exported permittivity, e.g. in Paraview? Or does the simulation
lose its sub-pixel precision with regards to some structure parameter?
Filip

2015-09-21 19:28 GMT+02:00, Pablo Díaz Núñez :
> Dear meep users,
>
> I have encountered a strange behaviour of subpixel averaging when
> running meep-mpi. Working at one node with 8 processors, if I do the
> simulation with 7 processors or less, subìxel averaging performs as it
> should be, but if I choose the 8 processors it won't work even
> eps-averaging is set to true.
>
> Does someone know why this happens?
>
> Thanks in advance,
> Pablo.
>
> ___
> 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] diffraction limit

[Filip Dominec]

Dear Amin,
I am afraid your question should be better searched/posed e.g. in
http://physics.stackexchange.com/ rather than to the MEEP community.

Your question has multiple answers depending on the point of view.
1) The most straightforward is that Maxwell equations have some
solutions and extremely narrow light confinement along a fiber just
does not belong to them.
2) You may also use the position-momentum uncertainty to deduce that
compressing photons in the position implies they will gain lateral
momentum, i.e., rapidly diffract afterwards.
3) This is analogous to the spectrum of a finite potential well in
elementary quantum mechanics; above some energy level, you have a
continuum of unbound states.
4) Or, yet different formulation of the same principle: using the
familiar Fourier transform, tight spatial confinement involves high
Fourier components that are not guided.
Filip

2015-09-15 17:10 GMT+02:00, amin izadi :
> dear all users
> I am a physics student and studied Fourier optics recently. I know what is
> diffraction limited lens and diffraction limits. But I don’t know why we
> cannot confine light in a region smaller than the light wavelength for
> traditional optical waveguides. Please guide me.
>
> Thanks in advance
> Best regards
>

___
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 source amplitude be changed?

[Filip Dominec]

Dear Steve,
1) before we involve in changing the source amplitude: Analysing the
high-quality cavity ringdown by time-domain method running the whole
time is *extremely* wasteful.  In fact, the "harminv", or "filter
diagonalization method" was designed to solve exactly this problem:
from a short sample of the ringdown, it precisely recovers the
frequencies, amplitudes and decay rates of all the modes. For what you
do, harminv is orders of magnitude more efficient than the classical,
Fourier-transform based approach!

2) Motivated to help you with your particular research, I spent
several working days to implement a ready-to-use simulation which I
published at 
https://github.com/FilipDominec/python-meep-utils/tree/master/example_ringdown_cylindrical_cavity
It has proven to work efficiently, and it is ready for you.

3) I guess you are focused on the EmDrive experiments. While the topic
has several red flags and appears highly suspicious for me, I admit
that I am not knowledgeable enough to guess what makes different
groups around the world report some positive results. Perhaps there is
something completely new beyond my understanding. I am however pretty
much convinced that the mysterious force effects can *not* be observed
in the pure Maxwell-equation solver, such as MEEP. Therefore, MEEP can
only play an auxiliary role for the design of resonant cavities,
waveguides etc.

Filip


2015-09-12 20:49 GMT+02:00, Steve :
> I need to see the decay of the fields in a resonant cavity excited with
> a Gaussian source. (Bandwidth = 0.025 * center frequency) My thought
> was:
>
> (at-time 1 (set! amplitude 0)) which does not work. I tried
> (define amp 1) with
> (amplitude amp) in the sources list, then
> (at-time 1 (set! amp 0)) which didn't work either. And in these cases,
> what I mean by "didn't work" is:
>   ?: 0 [procedure-property # arity]
>
>
> Is there a way to change the source amplitude during the run?
>
> I really don't care about the source amplitude, I only want to view the
> decay of the fields after the source turns off. Perhaps someone knows a
> way to make the Gaussian source turn off so that the decaying fields can
> be viewed. In this case, the quality factor of the resonant cavity is
> very large so waiting for the source to turn off automatically doesn't
> work as it never turns off.
>
>
> ___
> 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] Source code: Nonlinear polarization

[Filip Dominec]

Dear Vladimir, search for the variable 'chi2' in the code, it is used
in multiple files. The actual computation of its physical effect
should be in step_generic.cpp
Filip

2015-07-22 23:05 GMT+02:00, Владимир Борисович Новиков
:
> Dear all,
> Please show code place in https://github.com/stevengj/meep where nonlinear
> polarization (chi2*E*E) is calculated.
>
> Vladimir
>

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

Re: [Meep-discuss] Reconfigurable medium meep computation

[Filip Dominec]

Dear Nicolas, I guess the optical and mechanical processes happen at
completely different time scales (picoseconds to microseconds at
least). Perhaps the simplest way is to re-iterate multiple separate
simulations, with each simulation's structure being defined by the
result of the previous simulation field shape (and, say, stress
tensor).

This approach does not need any dynamic changes of the structure. They
would be needed, however, if the changes were comparably fast as the
field propagation, and therefore one would need to maintain the field
shape created by the previous structure.

Filip

2015-06-18 21:09 GMT+02:00, Nicolas Bachelard :
> Dear Meep team,
>
> I am using Meep for a week now and I am very happy about it.
> You did a very powerful and easy handling software. Thank you.
>
> I look over the different examples that I could find on the internet but
> there is one type of computation that I wish to perform
> and I cannot find appropriated example so far.
>
> I am wondering if I could compute optical forces in a reconfigurable system
> using Meep.
> For instance, let us assume that I put a particle in an optical force
> field.
> This force induces a motion of the particle, which in turn changes the
> permittivity of my medium
> and thus the force...
>
> In fact I guess that my question is the following: Can we change the
> permittivity of the medium
> during the FDTD computation? Can this change of permittivity be triggered
> by internal variables such as the
> electric field?
>
> All the best
>
> --
>
> --
> Nicolas Bachelard, PhD
> NSF Nanoscale Science and Engineering Center (NSEC),
> University of California, Berkeley 3112 Etcheverry Hall,
> UC Berkeley, California 94720, USA
>

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

Re: [Meep-discuss] bragg structure with kerr effect ....

[Filip Dominec]

Hi, Alshikh,
from what I understand, you shall introduce another callback function
like your  eps_bragg(const vec &pt), which will return the value of
the Kerr coefficient. It should be called in a similar manner as e.g.
the susceptibilities are.

I always found it useful to test out the Kerr nonlinearity in a
homogeneous medium first; when I got an obvious anharmonic wave
distortion after a while, I could be sure the nonlinearity is well
defined.

Hope this helps a bit,
Filip

2015-06-15 16:02 GMT+02:00, alsh...@netcourrier.com :
>
> Hello,
>
>
> I have a bragg structure like the one defined in the
> example bragg_transmission.cpp
>
>
>
> double eps_bragg(const vec &pt) {
>
>   double z = pt.z() - zsize * 0.5;
>
>
>
>   if (fabs(z)*2 > Nperiods)
>
> return nlo*nlo;
>
>   else {
>
> double zi;
>
> double zf = modf(z, &zi);
>
> if (zf < 0) zf += 1;
>
> if (zf < wlo)
>
>   return (nlo*nlo);
>
> else
>
>   return (nhi*nhi);
>
>   }
>
> }
>
>
>
> how can I add (kerr) nonlinear property to the material which have high
> refrective index? so I can do s.chi3_set(value)...
>
>
>
> Thank you .
>
>
>
>
>

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

Re: [Meep-discuss] Compiling Meep 1.3 on Debian 8 (testing) - HDF5 library troubles

[Filip Dominec]

Dear all,
in 2015, there have been numerous reports of MEEP not compiling with
HDF5 on Debian Jessie and newer versions of Ubuntu [1,2]. This
happened due to a known change in the system [3].

After a longer trial-and-error, I found the required change in the
LDFLAGS variable so that I can compile MEEP again from scratch using
the updated script available on Github [4].

The trick is that the HDF5 files must be searched in e.g.
/usr/lib/x86_64-linux-gnu/hdf5/openmpi or similar, depending on your
setup. I will be happy to receive your test results on other systems.

Wishing you a nice weekend,
Filip

- References -
[1] 
http://meep-discuss.ab-initio.mit.narkive.com/58VCfNNf/meep-can-t-find-hdf5-libraries-
[2] during-configure
http://permalink.gmane.org/gmane.comp.science.electromagnetism.meep.general/5445
[3] https://github.com/h5py/h5py/issues/536
[4] 
https://github.com/FilipDominec/python-meep-install/blob/master/python-meep-install.sh




 This is
LDFLAGS
2015-04-19 17:05 GMT+02:00, Robin Whittle :
> Thanks Steven and colleagues for Meep!
>
> I was able to compile the single threaded version (not MPI) version of
> the program with two problems on a 64 bit Debian 8 (testing)
> system:
>
> 1 - "make check" failed for near2far.  I will email the   
> log file to m...@ab-initio.mit.edu as requested.
>
> 2 - Meep's configure script did not find the HDF5 libraries.  I fixed
> this by compiling HDF5 from source, with a configure option
> suggested in a recent list message by Pavel Ivanov.
>
> This description is long in the hope that it will help people who are
> stuck somewhere.  There are a lot of decisions to make about compiling
> and/or installing from packages the various things Meep itself relies
> on, and other tools required to use Meep.  I detailed my exact
> experience, including some which turned out to be wrong, in the hope
> that it will help someone.
>
> I recently wrote to the list with an account of working through most of
> the Tutorial.  Due to an attached image file, the message exceeded the
> 40kB limit of this list and so is stuck in moderator limbo.  Hopefully
> it won't get to the list, since I will write an updated version of it
> based on the Meep I compiled today.
>
>   - Robin
>
>
>
> This is fresh install, last week, of Debian 8 (testing) on a dual hex
> core Xeon X5670 machine with 72GB.  Debian 8 (Jessie) has not yet been
> released.  The installation I used here is the "testing" version,
> leading up to that release.
>
> Low-key preliminaries:
>
>The system has X Windows and I am sshing to it from a Windows
>machine and using Xming for the Windows display of X windows
>programs.  To run Synaptic (package manager) like this without
>any fuss, I needed to (from non-root account and then "su -")
>add "PermitRootLogin yes" to /etc/ssh/sshd_config and restart
>the sshd server with: "/etc/init.d/ssh restart".  Then I could
>use PuTTY to log into the machine as root, and the command
>"synaptic" would bring up the GUI package manager.  (PuTTY:
>Connection > SSH > X11 > Enable X11 forwarding.)
>
> Apart from running Synaptic, which I did as root (and some other
> commands as specifically noted), I did all the following, including
> untargzipping the tarballs, as a mortal user, with sudo to run "make
> install" commands as root.  I have not attempted to to compile for MPI -
> so this is a single-threaded Meep.  This is based on the instructions at:
>
>   http://ab-initio.mit.edu/wiki/index.php/Meep_Installation
>
> which was last updated on 2015-02-13.
>
> I used Synaptic to get some packages, including, as instructed, the
> development versions.  (BTW, Synaptic makes Meep 1.2.1-2+b1 available.)
>
> gcc
>
>   Some gcc packages were already installed:
>
>   gcc-4.8-base4.8.4-1
>   gcc-4.9-base4.9.2-10
>
>   However, later when I tried to compile Harminv, the configure script
>   complained that no C compiler was in the path.  I attempted to fix
>   this by installing:
>
>   gcc-4.9 4.9.2-10
>
>   This brought in many other packages, including binutils and
>   libgcc-4.9-dev and involved an upgrade to libc6:
>
> libc6 (version 2.19-17) will be upgraded to version 2.19-18
> binutils (version 2.25-5) will be installed
> libc6-dev (version 2.19-18) will be installed
> libgcc-4.9-dev (version 4.9.2-10) will be installed
>
>   This didn't fix the complaint by Harminv's ./configure:
>
> no acceptable C compiler found in $PATH
>
>   After some Googling I decided to install the build-essential
>   11.7 package with Synaptic, which brought in a bunch of
>   packages.  I could not figure out from this exactly what
>   version or versions of gcc, specifically the C compiler and
>   g++, I would have.
>
>
> build-essential (version 11.7) will be installed
> dpkg-dev (version 1.17.25) will be installed
> fakeroot (version 1.20.2-1) will be installed
> g++ (version 4:4.9.2-2) will be installed

Re: [Meep-discuss] missing _H5P_CLS_DATASET_CREATE_g

[Filip Dominec]

Dear all, I am, too experimenting with this issue at the moment. You
can clone my repository with the installation scripts for the latest
python-meep from: https://github.com/FilipDominec/python-meep-install.

The advantage of using git is in clarity: Every modification of the
installation procedure has the output log attached in the very same
commit. One can easily compare how any change in the input manifested
in the output. It is also easy to transfer the procedure on different
systems, including emulators.

I am going to try the brute-force method described here:
http://comments.gmane.org/gmane.comp.science.electromagnetism.meep.general/4748
If it works, it would mean that it could be easily fixed. If not, the
sources of MEEP would need to be updated.

Filip

2015-06-02 17:34 GMT+02:00, Stephan :
> Hello,
>
> Does someone have a solution for this _H5P_CLS_DATASET_CREATE_g problem
> found? I have the same problem with my Mac. I also used Brew for installing
> the packages. With C++ it works quite well, but i prefer to work with
> Python.
>
> I really hope someone can help me.
> Thanks!!!
>
> Stephan
>
>
>
>
>
> ___
> 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] Precompiled package for meep 1.3

[Filip Dominec]

Dear Vladimir and all interested,
to my knowledge there is no precompiled MEEP of the version 1.3 for
Debian-based systems. Version 1.2.1 has been readily available for
over a year thanks to Thorsten Alteholz.

I prepared a compilation script, and planned to package the very
latest MEEP and Python-meep on my own (and to publish them in my own
PPA repository), but I ran into problems of incompatibility with the
important HDF5 library. I observed this in the latest Debian Jessie
and Ubuntu 14.10, 15.04. The first sign of problems in the compilation
output is on the line with "checking for H5Pcreate in -lhdf5... no",
see the full output of Debian Jessie:
https://github.com/FilipDominec/python-meep-install/blob/master/debian-jessie.log#L210
I think this is related to a new version of libhdf*.

Until I spare enough time to resolve how to compile MEEP that would be
again able to export data in the HDF5 format, I can not proceed with
packaging. Any hints are appreciated from anybody.

Best regards,
Filip



2015-05-31 11:12 GMT+02:00, Владимир Борисович Новиков
:
> I would like install latest version of Meep using precompiled package (by
> means comand apt-get install meep h5utils). But only 1.2 version installs.
> Where I can find precompiled package for latest version 1.3?
>
> Sincerely yours
>

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

Re: [Meep-discuss] FW: Si material parameters for MEEP C++

[Filip Dominec]

Dear Shin-Woong,
I did not compile your code, but I have few thoughts:
1) First, the material should be tested on a half-space, not a slab.
The latter combines "too much physics", i.e. the Lorentz-Drude model
with a pronounced Fabry-Pérot interference (which is moreover
modulated by the dispersion of the medium).
2) Precise modeling of silicon spectra is relatively hard; it has
narrow impurity absorption peaks in mid-IR, and typical band-gap
behaviour in the optical region; see
http://www.fzu.cz/~dominecf/misc/eps/index.html . None of these are
easy to be approximated by a Lorentzian.
3) I can see you composed the source of ca. 500 discrete point
sources. This seems utterly inefficient to me. Is this needed?
4) If you did not get any answer yet, it may be due to your e-mail
falling into spamboxes. At least it happened to me.
Filip


2015-05-07 14:41 GMT+02:00, Shin-Woong, PARK :
> Further to my questions below, I'm attaching my MEEP C++ code to the end of
> this e-mail.
>
>
>
> Regards,
>
>
>
> S. Park
>
>
>
> From: Shin-Woong, PARK [mailto:pkwo...@korea.ac.kr]
> Sent: Thursday, May 07, 2015 8:43 PM
> To: 'meep-discuss@ab-initio.mit.edu'
> Subject: Si material parameters for MEEP C++
>
>
>
> Dear MEEP users,
>
>
>
> I have investigated the reflective spectrum of Si slab with MEEP C++.
> However, the spectrum was not agreed with the analytic result.
>
>
>
> With the same MEEP C++ code, the Ag reflectivity was obtained and it agreed
> perfectly with the analytic calculation.
>
>
>
> I wonder what the material parameters(eps, sigma, omega, gamma) is correct
> in the unit length of 1e-7 (a=100nm).
>
>
>
> The used parameters which are obtained by Lorentz-Drude model for
> polarizability are as follows:
>
>
>
> eps : 3.9 (reletive permittivity)
>
>
>
> sigma:
>
>0   8.000   2.850
> -0.107
>
>
>
> omega:
>
>0   0.293585919782031   0.222609104010551
> 0.139533967368932
>
>
>
> gamma:
>
>0   0   0.005081294765458
> 0.201638681168977
>
>
>
>
>
> I'm looking forward to your comment and great help.
>
>
>
> Best regards
>
>
>
> S. Park
>
>
>
>
>
>
>
> Shin-Woong, Park   Ph.D
>
> Research Professor
>
> Center for Advanced Photovoltaic Materials
>
> Korea University
>
> Tel: +82-2-3290-3975
>
> Mobile: +82-10-2077-1350
>
> Email:   pkwo...@korea.ac.kr,
>  7.shinwoong.p...@gmail.com
>
>
>
>
>
> 
>
>
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
>
>
> using namespace std;
>
> using namespace meep;
>
>
>
> complex i(0,1);
>
> grid_volume v;
>
>
>
> /** unit length a = 100nm (1e-7) **/
>
>
>
> double Si_thickness = 1;
>
>
>
> double eps(const vec &p)
>
> {
>
>   if (abs((v.center().y()) - p.y()) 
> {
>
>   return 3.9;
>
> }
>
>   return 1.0;
>
> }
>
>
>
> class head: public material_function
>
>   {
>
>   bool has_conductivity(component c)
>
>{
>
>   if(c==Dx)
>
>   {
>
>printf("bool\n");
>
>
>return true;
>
>   }
>
>   else
>
>   {return false;}
>
>}
>
>
>double conductivity(component c, const vec &r)
>
>{
>
>  if(c==Dx)
>
>  {
>
>   if (abs((v.center().y()) - r.y()) 
>  {
>
>   //return 2*3.14*0.*0.01/11.9;
>
>   return 1.5/3.9;
>
>  }
>
>
>
>  else
>
> {return 0;}
>
>  }
>
>  else
>
>  {return 0;}
>
>}
>
>   };
>
>
>
> double sigma1(const vec &p)
>
> {
>
>   if (abs((v.center().y()) - p.y()) 
> {
>
>   return 0;
>
> }
>
>
>   return 0;
>
> }
>
>
>
> double sigma2(const vec &p)
>
> {
>
>   if (abs((v.center().y()) - p.y()) 
> {
>
>
>   return 8.0;
>
> }
>
>   return 0;
>
> }
>
>
>
> double sigma3(const vec &p)
>
> {
>
>   if (abs((v.center().y()) - p.y()) 
> {
>
>   return 2.85;
>
> }
>
>   return 0;
>
> }
>
>
>
> double sigma4(const vec &p)
>
> {
>
>   if (abs((v.center().y()) - p.y()) 
> {
>
>   return -1*0.107;
>
> }
>
>   return 0;
>
> }
>
>
>
>
>
> int main(int argc, char **argv) {
>
>   /** Internals **/
>
>   initialize mpi(argc, argv);
>
>   head VCH_head;
>
>   deal_with_ctrl_c();
>
>
>
>   /** Creating structure **/
>
>   const double xGrids = 50;
>
>   const double yGrids = 50;
>
>   const double resolution = 5;
>
>
>
>   v = vol2d(xGrids, yGrids, resolution);
>
>
>
>   /**Describing the geometry and materials*/
>
>   //structure s(v,eps, pml(1, X) + pml(1, Y));
>
>   structure s(v,eps, pml(1, Y));
>
>   s.set_conductivity(Dx,VCH_head);
>
>   s.add_polarizability(sigma1,0.000,0.000);  //
> sigma, omega, and gamma for Si
>
>   s.add_polarizability(sigma2,0.293585919782031,0.000);
>
>   s.add_polarizability(sigma3,0.222609104010551,0.005081294765458);
>
>   s.add_polarizability(sigma4,0

Re: [Meep-discuss] flux spectrum of continuous source

[Filip Dominec]

Hi, the degree of monochromaticity of the source is inversely
proportional to the simulation time. You can suppress spectral ringing
by slow onset of the source, and possibly by applying a smooth window
to the time recorded function. Consequently, there is nothing like a
fully monochromatic source.

If you need an efficient monochromatic computation, you can use the
frequency-domain solver built in meep.

Filip


2015-05-05 12:29 GMT+02:00, Eoin Murray :
> Does anyone have a solution to this, to make a fully monochromatic light
> source, it seems like a fairly typical use case for an electromagnetic FDTD
> library.
>
> I have found that a mono-source can be made if you run the simulation for a
> long time, like 1500 periods, but there must be a more efficient way to do
> this. I will post my solution as soon as I find one.
>
>
>> On 2 May 2015, at 14:30, Eoin Murray  wrote:
>>
>> Hi Filip,
>>
>> Thanks for the swift reply and for recommending the solution. I have tried
>> what was suggested in Gib's post - where a smooth turn on function of
>> around two periods should narrow down the linewidth of the source spectrum
>> (or power spectrum) - however this does not seem to work for me,
>>
>> I have made a sample repo on github to show the issue, I am using a
>> frequency of 1.1 and a continuous-src with a 2 period turn on time (I have
>> tried unto 20 periods turn on and little changes), I would expect the
>> linewidth of this source to be approaching zero. I understand that there
>> would be some numerical broadening, but still the source is far to broad
>> for me at the moment with a width of 0.05, this should be much smaller to
>> simulate a close-to-monochromatic light source like an atomic dipole
>> (which a continuous wave src should do).
>>
>> The field does become more spectrally narrow if I run for a long time
>> (like 1500 periods), but I expect I should be able to achieve same after
>> 20 periods or something, why do the transients take so long to die out.?
>>
>> The attached repo contains a _test.ctl file with my code and graphs in the
>> _test-out/ folder.
>>
>> https://github.com/eoinmurray/meep-test.git
>> <https://github.com/eoinmurray/meep-test.git>
>>
>> Thanks again for the help.
>> Eoin
>>
>>> Begin forwarded message:
>>>
>>> Date: 1 May 2015 20:59:41 BST
>>> Subject: Re: [Meep-discuss] flux spectrum of continuous source
>>> From: Filip Dominec >> <mailto:filip.domi...@gmail.com>>
>>> To: Eoin Murray mailto:em...@cam.ac.uk>>
>>>
>>> Hi, Eoin,
>>> everything suggests you have the same problem (which is actually not a
>>> problem per se) as Gib:
>>> https://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg05374.html
>>> <https://www.mail-archive.com/meep-discuss@ab-initio.mit.edu/msg05374.html>
>>>
>>> Regards,
>>> Filip
>>>
>>> 2015-05-01 14:17 GMT, Eoin Murray >> <mailto:em...@cam.ac.uk>>:
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>> From: Eoin Murray mailto:em...@cam.ac.uk>>
>>>> Subject: flux spectrum of continuous source
>>>> Date: 1 May 2015 15:14:20 BST
>>>> To: meep-discuss@ab-initio.mit.edu
>>>> <mailto:meep-discuss@ab-initio.mit.edu>
>>>>
>>>> I want to create a monochromatic continuous source, in air, and measure
>>>> the
>>>> flux through some plane, so I use the following code:
>>>>
>>>>> (set! sources (list
>>>>>   (make source
>>>>> (src (make continuous-src (wavelength wv) (width 0)))
>>>>> (component Ez)
>>>>> (center 0 0) (size 0 0
>>>>
>>>> I thought that the flux spectrum would look like a dirac delta
>>>> function,
>>>> instead it is quite broad, why is this?
>>>> How can I create a continuous wave monochromatic source in meep?
>>>> Attached are links to the flux spectrum I measured through a plane north
>>>> of
>>>> the source, and also an image of the field.
>>>>
>>>> http://i.imgur.com/xeAZCte.png <http://i.imgur.com/xeAZCte.png>
>>>> <http://i.imgur.com/xeAZCte.png <http://i.imgur.com/xeAZCte.png>>
>>>>
>>>> http://i.imgur.com/Dza8deC.png <http://i.imgur.com/Dza8deC.png>
>>>> <http://i.imgur.com/Dza8deC.png <http://i.imgur.com/Dza8deC.png>>
>>
>> ___
>> 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] Fwd: Plane wave in meep (C++)

[Filip Dominec]

Dear Amrit,
if I am not wrong, the only way how a wave can have only one
particular direction is that it is of infinite width. Any wave limited
by a finite-sized source will more or less diffract.

To simulate an infinite wave in MEEP, one can easily employ
Bloch-periodic boundaries (on the faces that are transverse to the
wave).

Now if you wish to make the infinite wave oblique, you have to modify
1) the source to have nonzero transverse wave-vector component, c.f.
https://github.com/FilipDominec/python-meep-utils/blob/master/meep_utils.py
at lines 375-400,
2) the Bloch-periodic boundaries to account for the phase acquired
across the simulation volume, c.f.
https://github.com/FilipDominec/python-meep-utils/blob/master/scatter.py
lines 26-27.
3) all field monitors, depending how you use them.

The examples referenced are in Python, but the idea should be the same in C++.
Regards,
Filip

2015-05-01 21:39 GMT, amrit poudel :
> Hi Filip,
>
> Could you please give me an example of how to generate monochromatic plane
> wave using your approach in C++ meep?
>
> I am not sure about my approach because the wave seems to be propagated in
> all directions, but I would like to have it propagate in only one particular
> direction (think of an experiment where you sign a laser light on a metallic
> nanoparticle).
>
>
>
> Thanks for your time and help.
>
> Amrit
>
>
>
>> On May 1, 2015, at 3:02 PM, Filip Dominec 
>> wrote:
>>
>> Hi, Amrit,
>> I think you may construct the oblique wave source as you describe, but
>> I still consider the volume source with complex amplitude to be a
>> simpler and more efficient solution.
>>
>> Filip
>>
>> 2015-05-01 16:08 GMT, amrit poudel :
>>> Hi Filip,
>>> Thank you very much for your reply. I am interested in a monochromatic
>>> source, so your suggestion might work. However, there are a few things
>>> that
>>> still remain unclear to me.
>>> Is it not true that a collection of point dipole sources arranged in a
>>> vertical line, as it is done in the following example, generate plane
>>> wave
>>> (not in the immediate vicinity of the source, but at a small distance
>>> away
>>> from the vertical line)? I am not sure about the propagation direction
>>> of
>>> the wave generated in this fashion.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> continuous_src_time src(freq, fwidth);
>>> double sx1, sy1, sy2, dy;sx1 = 5.0; sy1 = 5.0; sy2 = 10.0;
>>> dy
>>> = (sy2-sy1)/2000;
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> volume src_volume(vec(sx1 , sy1 ), vec(sx1 , sy2 ));
>>> f.add_volume_source(Ez, src, src_volume);
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> for (double sy=sy1; sy<=sy2; sy+=dy){f.add_point_source(Ez, src,
>>> vec(sx1, sy));
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>}
>>> I assume this would give me electric field \vec{E}
>>> ~\hat{e_z}*\exp(i*k_x*x)*\exp(-i*\omega*t)
>>> Best,
>>> Amrit
>>>
>>>
>>>> Date: Fri, 1 May 2015 09:43:08 +
>>>> Subject: Re: [Meep-discuss] Plane wave in meep (C++)
>>>> From: filip.domi...@gmail.com
>>>> To: amrit_...@hotmail.com
>>>> CC: meep-discuss@ab-initio.mit.edu
>>>>
>>>> Dear Amrit,
>>>> I deduce you are interested in _oblique_ incidence of the plane wave.
>>>> Perhaps the optimum solution would be to freely rotate the source
>>>> object in space; however to my knowledge this is not possible.
>>>>
>>>> It is however relatively easy to make a source emit with a transverse
>>>> component of the wave vector, say, Ky. The problem is that under
>>>> constant Ky the angle is a function of frequency. While for Ky ~
>>>> omega/c, the source emits along its plane, for Ky << omega/c the angle
>>>> approaches standard perpendicular emission. You therefore can not
>>>> define one angle if the source is broadband, i.e., pulsed.
>>>>
>>>> Examples of the source amplitude callback can be found online.
>>>>
>>>> Hope this helps a bit,
>>>> Filip
>>>>
>>>> 2015-04-30 21:12 GMT, amrit poudel :
>>>>> Dear Meep users,
>>>>> I was wondering if I could get some help implementing incident plane
>>>>> wave in
>>>>> meep (as a C++ library).
>>>>> Is it enough to simply add the following lines of code to generate
>>>>> s-polarized incident plane wave in a 2D geometry with a scatterer
>>>>> located on
>>>>> the XY plane? Also, how does one determine the angle of incident of
>>>>> the
>>>>> plane wave in meep?
>>>>> 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> continuous_src_time src(freq, fwidth);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> f.add_point_source(Ez, src, vec(sx, sy));
>>>>> **Here, f is field defined
>>>>> with
>>>>> appropriate structure and grid_volume.
>>>>>
>>>>> I am not sure if this is correct at all.
>>>>>
>>>>> I will appreciate any help.
>>>>> Thank you.
>>>>> Amrit
>>>
>

___
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 in meep (C++)

[Filip Dominec]

Dear Amrit,
I deduce you are interested in _oblique_ incidence of the plane wave.
Perhaps the optimum solution would be to freely rotate the source
object in space; however to my knowledge this is not possible.

It is however relatively easy to make a source emit with a transverse
component of the wave vector, say, Ky. The problem is that under
constant Ky the angle is a function of frequency. While for Ky ~
omega/c, the source emits along its plane, for Ky << omega/c the angle
approaches standard perpendicular emission. You therefore can not
define one angle if the source is broadband, i.e., pulsed.

Examples of the source amplitude callback can be found online.

Hope this helps a bit,
Filip

2015-04-30 21:12 GMT, amrit poudel :
> Dear Meep users,
> I was wondering if I could get some help implementing incident plane wave in
> meep (as a C++ library).
> Is it enough to simply add the following lines of code to generate
> s-polarized incident plane wave in a 2D geometry with a scatterer located on
> the XY plane? Also, how does one determine the angle of incident of the
> plane wave in meep?
> 
>
>
>
>
>
>
>
>
> continuous_src_time src(freq, fwidth);
>
>
>
>
>
>
>
>
> f.add_point_source(Ez, src, vec(sx, sy));
> **Here, f is field defined with
> appropriate structure and grid_volume.
>
> I am not sure if this is correct at all.
>
> I will appreciate any help.
> Thank you.
> Amrit
>
>
>
>

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

Re: [Meep-discuss] Confusions

[Filip Dominec]

Dear Hamza,
from what I know you need to run a loop of the simulations; this is
probably accomplished the best through a loop in a bash script; the
scheme interface accepts command-line parameters as can be found in
numerous examples. As an example in python-meep, I just uploaded
https://github.com/FilipDominec/python-meep-utils/tree/master/example_metamaterial_s_parameters/sphereTiO2_LossScan
.

Second, you ask about MEEP storing the mode profiles for a source.
Typically, MEEP uses a flat, even shape of the source. (There is a new
feature of computing the mode profile to match a mode exactly to a
dielectric waveguide, but to my knowledge this is supposed to work for
single-frequency sources only.)

Units in MEEP are arbitrary, to the point that there is absolutely no
a priori specification of whether meters, micrometers or e.g. furlongs
are used. From my personal view, the resulting data is the simplest to
interpret if one uses meters as the length unit, but a little downside
is that using MEEP for optical range, you operate with small numbers.

Regards,
Filip

2015-04-24 2:03 GMT+02:00, hamza humayun :
> Hi,sorry to disturb but can you address following confusions of mine?İ was
> wondering if there is a method, similar to parametric sweep in Comsol, in
> MEEP. İ want to see the resonance in microdisk change with wavelength that
> is off and on resonance, or i would have to run a loop? For loop i am
> confused about the wavelength range in meep. When defining the source in
> MEEP. When we define gaussian source and provide central frequency, beam
> width (df) and no. of frequency points (n), does the program calculate the
> modes at each of these frequencies, if so where are results stored ?
> İ have been going through different meep files and i noticed that units are
> not shown when writing the code. Some use the exact values and some seem to
> use arbitrary units. Does everything happen by default in micrometer (um)?
>
> Thanks
> Hamza

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

Re: [Meep-discuss] CAD tool for Meep

[Filip Dominec]

>From my personal point of view, MEEP is mostly used for scientific
research rather than engineering. Most simulations therefore deal with
complicated physical interpretation of rather simple structures. The
highlights of MEEP are the possibility to defive various physical
phenomena and its scripting interface that enables to build complex
pre- and post-processing around the actual FDTD computation.

This is also my case: Being able to easily inspect the structure in
Mayavi or Paraview, I had no issues with definition of the model. In
fact, the time spent "programming" the structure is negligible
compared to that one spent with debugging the simulation, or comparing
the results against other sources and dealing with the physics around.
I will be interested if one writes a CAD for MEEP, but it has to be
competitive to the existing workflow I am used to.

If an interface to some CAD is to be written, the CAD should in optimal case:
1) be fully parametric, to allow scanning through parameters or their
automated optimization,
2) enable to define all other MEEP structures, such as field sources
and monitors, perfectly matched layers, boundary conditions etc.,
3) be also aware of the discretized grid of FDTD, so that the
structure can be defined with single-voxel accuracy.
If these features would be missing in the CAD, my workflow would be
arguably more efficient if I stayed with Python scripts and Paraview.
In fact, I find the programming interface surprisingly friendly.

Regards,
Filip



2015-04-21 16:15 GMT+02:00, John Ball :
> I can't speak to the needs or limitations of the lib-ctl interface
> w/epsilon-input-file; However, having spent a lot of time now perfecting my
> model structure in the C++ meep format I have a few opinions there:
>
> I've been boot-strapping myself a sort of custom c++ based input_epsilon
> function that reads the contents of an hdf5 file and uses the location
> indices of the structure volume to initialize the correct epsilon value (I
> do this because the process of making the epsilon grid itself takes
> forever, so I've found it to be far more useful to separately create it and
> store it for later use). If a FreeCAD module/plugin (sorry, I don't know
> the program) could be used to intelligently create & store such an hdf5
> file (or whatever file format might be the most practical), I can see that
> being useful--especially if the module could take a vrml mesh or something
> similar and convert it into the pixel-based format that is the most easily
> used by an eps() function when using c++ meep.  Extra bonus points if the
> FreeCAD module can compress the structure somehow and you can supply a c++
> function that can accurately decompress the structure for initialization by
> eps(). My eps hdf5 files can get huge, but I don't have the time/motivation
> to figure out any compression myself.
>
> After that, my expertise drops considerably; however, if you could use a
> GUI to design the sources, detectors, etc, even if all it did was build a
> C++ function with the meep libraries that could be then compiled and run
> separately, I imagine that would be useful for many people, especially new
> users.
>
> All of this could probably be done to build lib-ctl scripts instead (or
> hell, even in addition). I prefer the C++ method because it allows me to
> use functions from other libraries as well.
>
> I like your idea, or at least the version of it that I see in my mind. I
> hope you take it somewhere!
>
> On Tue, Apr 21, 2015 at 2:54 AM, Alex  wrote:
>
>> Hi Robert,
>> There is no need to bring in MEEP's code to FreeCAD. MEEP has build-in
>> function "epsilon-input-file". If FreeCAD will have capability to
>> export structure into HDF5 file, MEEP will just import that files.
>> It is accepted to call GPL programs from not-GPL.
>>
>> Best regards, Alex Friman
>> LPI RAS
>>
>> 2015-04-21 9:37 GMT+03:00 Robert Rehammar :
>> > Dear Meep users,
>> >
>> > I have been using Meep in the past and finds the tool nice and
>> > powerful.
>> If
>> > comparing to commercial CEM tools, I would say Meeps front-most
>> > weakness
>> is
>> > the lack of a GUI to interface the tool and create the model in. There
>> is a
>> > FOSS CAD tool with good traction known as FreeCAD (freecadweb.org)
>> which is
>> > very nice and I think Meep would fit excellent as a module to FreeCAD.
>> How
>> > would the Meep community feel about that? FreeCAD is written in C++ and
>> > Python and has support for things like storing material properties in
>> > modelled objects, parametric modelling and large import/export of CAD
>> file
>> > formats.
>> >
>> > Looking at this, I found one obstacle and that is that FreeCAD is LGPL
>> and
>> > Meep is GPL. Seems like the FreeCAD-devs are very reluctant to bringing
>> in
>> > GPL code into FreeCAD. Anyone has any idea on how that could be solved?
>> One
>> > way I guess is to only use FreeCAD to generate ctl-files for Meep to
>> > execute, and not link against Meep. This might

Re: [Meep-discuss] Python-Meep Investigation

[Filip Dominec]

Hi, Cristian et al.,
now I can also confirm that have an issue with HDF5 on Debian Jessie,
though Debian Wheezy was fine. The problematic portion in the log is:
checking for H5Pcreate in -lhdf5... no
checking for H5Pset_mpi... no
checking for H5Pset_fapl_mpio... no

Meep then can not save into HDF files, in which case it ends with the
error message "meep: not compiled with HDF5, required for HDF5 output"

Note that Christian reported a different output of the compilation
procedure; to repeate it for comparison:
>> >> checking for H5Pcreate in -lhdf5... no
>> >> configure: WARNING: Couldn't find the HDF5 library!! Switching to
>> >> --without-hdf5.
>> >> checking for H5Pset_mpi... no
>> >> checking for H5Pset_fapl_mpio... no

I will investigate this issue further. The newest version of the
installation procedure, with its full log output on the current
cleanly installed system, is at:
https://github.com/FilipDominec/python-meep-install

Filip

2015-03-25 4:05 GMT-04:00, Filip Dominec :
> Hi,
> it is as you write, and therefore I would like to make the blue-boxed
> installation failsafe on as many systems as possible. Currently it is
> known to work on Ubuntu, but yesterday I finally made it work on
> Debian, too.
> At the moment, I am installing clean Debian Jenny system to make a
> final test. I will keep you posted what is the result.
> Filip
>
> 2015-03-25 1:10 GMT+01:00, c7...@gmx.net :
>> Hello,
>> I just noticed, that you are the author of the website with the blue
>> boxed
>> script. Have you read my last post or have another idea what might be
>> causing the problem? I am personally out of my depth here, I don't know
>> enough about python-meep to start messing around with the underlying
>> code,
>> but if I can help figure out what is going on, I will. I greatly
>> appreciate
>> your help.
>>
>> Greetings
>> Christian Kropla
>> Diploma Student at IAPP, Dresden
>>
>> Gesendet: Montag, 23. März 2015 um 09:10 Uhr
>> Von: "Filip Dominec" 
>> An: c7...@gmx.net
>> Betreff: Re: [Meep-discuss] Meep can't find HDF5 libraries during
>> ./configure
>> Hi,
>> from what you wrote, I feel motivated to help you. Not only are there
>> many users of python-meep, but even more I am wondering what may be
>> wrong with that blue box script. I would be thankful if you help me
>> find this out.
>>
>> Python-meep should really be a frontend for MEEP; all interfacing with
>> HDF5 files is done through the libmeep.so's built-in functions. If
>> libmeep.so behaves differently, you perhaps use two different versions
>> of the library. Note that the blue script installs into /usr/local/lib
>> instead of the default /usr/lib. This is to allow coexistence with the
>> libraries from the repository. Python-meep then loads the libmeep
>> library from /usr/local/lib, but by default, meeps loads the latter. I
>> guess that's it.
>>
>> To find the actual problem: About a month ago, I made a change in the
>> procedure, changing line #17 to replace 'libhdf5-serial-dev' with
>> 'libhdf5-openmpi-dev'. Although both versions worked on my system
>> (ubuntu 13.10), the second one should be faster. Can you remember
>> which version you used? Can you please recompile meep and python-meep
>> again, testing these two (serial / openmpi) versions?
>>
>> Best,
>> Filip
>>
>>
>>
>>
>> 2015-03-23 2:25 GMT+01:00, c7...@gmx.net :
>>> That script is actually what I based my build on, and from what I can
>>> tell it is working fine for the most part. However, what is not working
>>> are the HDF5 output functions in MPI mode and using python-meep. If you
>>> use OpenMPI, the program will continue to run forever because it can't
>>> write to the files. The processes are blocking each other. OpenMPI
>>> doesn't tell you that, MPICH however does.
>>>
>>> This does not seem to be problem with Meep, but with python-meep. I
>>> wrote a small *.ctl script to test the output functions and they work.
>>> Somehow python-meep is using the wrong hdf5 libraries (the ones that
>>> don't have mpi enabled), if that is even possible. I thought it was
>>> "just" a frontend for meep.
>>>
>>> Installing Meep from the repositories on Debian Jessie was the first
>>> thing I did, then I compiled python-meep against those and got the it
>>> running. Non-MPI worked flawless. MPI-Mode worked, but without the hdf5
>>> functions.
>>>
>>> Then I

Re: [Meep-discuss] Resonant Modes in Microdisks

[Filip Dominec]

Dear Pierre,
I observed similar mode splitting (from intended circular symmetric
structures) when my simulations had too coarse a resolution. How the
results change if you halve or double the resolution?

You could also launch the frequency-domain solver to identify the
detected two modes.

Filip

2015-04-02 12:04 GMT+02:00, Pierre :
> Dear Meep users and developpers
>
> I am learning how to find resonant modes in microdisks with Meep.
>
> I decided to test my script on the microdisk described in the article
> /Analytical Study of the Microdisk's Resonant Modes Coupling With a
> waveguide Based on the Perturbation Theory/ by Morand (Journal of
> Lightwave Technology vol 22 no 3 march 2004).
>
> In 2D, this disk is modelised by a cylinder of effective index 2.2 and
> radius 1 µm.
>
> The article and an analytical method based upon the continuity of
> Bessel's functions find the following TM mode :
>
> lambda = 1.4265 µm, Q = 297, azimuthal number = 7, radial number = 1
>
> The nearest modes found by Meep are the following :
>
> lambda = 1.4055 µm, Q = 3E4, azimuthal number = 25, radial number = 1
>
> lambda = 1.4583 µm, Q = 2E4, azimuthal number = 24, radial number = 1
>
> Which are quite different!
>
>
> I use the following script and then I change fcen to the resonant
> frequency found previously and df to 0.01.
>
>
> (define-param n0 1)
> (define-param n 2.2) ;effective index of waveguide
> (define-param R 1)   ;radius of cylindre (µm)
>
> (define-param pad 2)   ;padding between waveguide and edge of PML
> (define-param dpml 1)  ;thickness of PML
> (define-param cellx (* 2(+ dpml pad R))) ;size of the cell along x axis
> (define-param celly cellx)   ;size of the cell along y axis
>
> (define-param fcen 0.7) ; pulse center frequency
> (define-param df 0.1) ; pulse width (in frequency)
>
> (set! geometry-lattice
>(make lattice (size cellx celly no-size)
> ))
>
> (set! geometry (list
>(make cylinder (center 0 0) ; makes the outter part of the disk
>   (height infinity)
>   (radius R)
>   (material (make dielectric (index n)))
>)
> ))
>
> (set! sources (list
>(make source (src (make gaussian-src (frequency fcen) (fwidth df)))
> (component Ez)
> (center 0 (- R 0.1))
> )))
>
> (set! pml-layers (list
> (make pml (thickness dpml)
> )))
>
> (set! resolution 40)
>
> (use-output-directory)
> (run-sources+ 300
> (at-beginning output-epsilon)
> (after-sources (harminv Ez (vector3 0 (- R 0.1)) fcen df))
> )
>
> (run-until (/ 1 fcen) (at-every (/ 1 fcen 20) output-efield-z))
>
> Could someone tell me what I am doing wrong?
>
> Thanks
>
>
> Regards
> Pierre
>

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

Re: [Meep-discuss] Resonant Modes in Microdisks

[Filip Dominec]

Dear Pierre,
I observed similar mode splitting (from intended circular symmetric
structures) when my simulations had too coarse a resolution. How the
results change if you halve or double the resolution?

You could also launch the frequency-domain solver to identify the
detected two modes.

Filip

2015-04-02 12:04 GMT+02:00, Pierre :
> Dear Meep users and developpers
>
> I am learning how to find resonant modes in microdisks with Meep.
>
> I decided to test my script on the microdisk described in the article
> /Analytical Study of the Microdisk's Resonant Modes Coupling With a
> waveguide Based on the Perturbation Theory/ by Morand (Journal of
> Lightwave Technology vol 22 no 3 march 2004).
>
> In 2D, this disk is modelised by a cylinder of effective index 2.2 and
> radius 1 µm.
>
> The article and an analytical method based upon the continuity of
> Bessel's functions find the following TM mode :
>
> lambda = 1.4265 µm, Q = 297, azimuthal number = 7, radial number = 1
>
> The nearest modes found by Meep are the following :
>
> lambda = 1.4055 µm, Q = 3E4, azimuthal number = 25, radial number = 1
>
> lambda = 1.4583 µm, Q = 2E4, azimuthal number = 24, radial number = 1
>
> Which are quite different!
>
>
> I use the following script and then I change fcen to the resonant
> frequency found previously and df to 0.01.
>
>
> (define-param n0 1)
> (define-param n 2.2) ;effective index of waveguide
> (define-param R 1)   ;radius of cylindre (µm)
>
> (define-param pad 2)   ;padding between waveguide and edge of PML
> (define-param dpml 1)  ;thickness of PML
> (define-param cellx (* 2(+ dpml pad R))) ;size of the cell along x axis
> (define-param celly cellx)   ;size of the cell along y axis
>
> (define-param fcen 0.7) ; pulse center frequency
> (define-param df 0.1) ; pulse width (in frequency)
>
> (set! geometry-lattice
>(make lattice (size cellx celly no-size)
> ))
>
> (set! geometry (list
>(make cylinder (center 0 0) ; makes the outter part of the disk
>   (height infinity)
>   (radius R)
>   (material (make dielectric (index n)))
>)
> ))
>
> (set! sources (list
>(make source (src (make gaussian-src (frequency fcen) (fwidth df)))
> (component Ez)
> (center 0 (- R 0.1))
> )))
>
> (set! pml-layers (list
> (make pml (thickness dpml)
> )))
>
> (set! resolution 40)
>
> (use-output-directory)
> (run-sources+ 300
> (at-beginning output-epsilon)
> (after-sources (harminv Ez (vector3 0 (- R 0.1)) fcen df))
> )
>
> (run-until (/ 1 fcen) (at-every (/ 1 fcen 20) output-efield-z))
>
> Could someone tell me what I am doing wrong?
>
> Thanks
>
>
> Regards
> Pierre
>

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

Re: [Meep-discuss] Low frequency modulation

[Filip Dominec]

Hi, Gib,
in reality, the source is a sine wave multiplied by a "box function"
of the duration of your simulation. The spectrum of the source is
therefore obviously a convolution of a Dirac's δ-function at the
nominal frequency f0, convolved with the sin(fT)/fT envelope,
corresponding to the spectrum of the box function of T-width.
http://www.thefouriertransform.com/pairs/box.php

This is why a short transient when the sinewave source is turned on
can yield multiple resonances.

Smooth startup is exactly what you need to make the envelope narrower
in spectrum.

Filip


2015-03-31 12:07 GMT+02:00, Gib Bogle :
> Hi Filip,
>
> I had not considered the possibility of two resonant modes.  But my source
> is monochromatic, so there is no spectrum width.  I have realised, though,
> that by specifying the 'width' parameter for the continuous-src I can ensure
> a smooth startup.I am about to test that.
>
> I did try to use the frequency domain solver, but it ran for hours and
> failed to converge.  I don't know what that signifies.
>
> Cheers
> Gib
> 
> From: Filip Dominec [filip.domi...@gmail.com]
> Sent: Tuesday, 31 March 2015 8:54 p.m.
> To: Gib Bogle
> Cc: meep-discuss@ab-initio.mit.edu
> Subject: Re: [Meep-discuss] Low frequency modulation
>
> Hi, Gib,
> it appears there are two resonant modes relatively close in frequency
> (separated by 1/4 of their center frequency, as you wrote). You may
> wish to set the 'width' to some reasonable value  so that the spectrum
> of the source is narrower.
> http://ab-initio.mit.edu/wiki/index.php/Meep_Reference
>
> Of course, there is also the possibility to run the simulation for
> longer time, so that the ringing decays, or to use the
> frequency-domain solver. Both could be especially useful if you were
> interested what the resonances stem from.
>
> Filip
>
> 2015-03-31 4:01 GMT+02:00, Gib Bogle :
>> I appreciate that most Meep users, those who post on this mailing list
>> anyway, are working in optics, while my project is in the microwave range
>> (5-6 GHz), but there may be someone who can throw some light (ha!) on my
>> question.
>>
>> I am exciting a slot antenna, which is supposed to be resonant at 5.8 GHz,
>> with a continuous plane wave at that frequency, and logging the electric
>> field Ey in the gap at the end of the waveguide.  After a couple of
>> periods
>> the Ey signal displays the expected sinusoidal shape - almost.  There is a
>> low frequency modulation, about 4x the wavelength, that is gradually
>> decaying but still obvious after 20 periods.  This makes it hard to get a
>> good estimate of the amplitude of the antenna response - my goal.
>>
>> I haven't been able to find out what is creating this persistent low
>> frequency wave.  My best guess is that it is somehow triggered by the
>> sudden
>> onset of the sinusoidal forcing by the plane wave.  Is there a way to ramp
>> up the forcing signal?  Is this likely to be the cause?
>>
>> Thanks
>> Gib
>>
>

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

Re: [Meep-discuss] Low frequency modulation

[Filip Dominec]

Hi, Gib,
it appears there are two resonant modes relatively close in frequency
(separated by 1/4 of their center frequency, as you wrote). You may
wish to set the 'width' to some reasonable value  so that the spectrum
of the source is narrower.
http://ab-initio.mit.edu/wiki/index.php/Meep_Reference

Of course, there is also the possibility to run the simulation for
longer time, so that the ringing decays, or to use the
frequency-domain solver. Both could be especially useful if you were
interested what the resonances stem from.

Filip

2015-03-31 4:01 GMT+02:00, Gib Bogle :
> I appreciate that most Meep users, those who post on this mailing list
> anyway, are working in optics, while my project is in the microwave range
> (5-6 GHz), but there may be someone who can throw some light (ha!) on my
> question.
>
> I am exciting a slot antenna, which is supposed to be resonant at 5.8 GHz,
> with a continuous plane wave at that frequency, and logging the electric
> field Ey in the gap at the end of the waveguide.  After a couple of periods
> the Ey signal displays the expected sinusoidal shape - almost.  There is a
> low frequency modulation, about 4x the wavelength, that is gradually
> decaying but still obvious after 20 periods.  This makes it hard to get a
> good estimate of the amplitude of the antenna response - my goal.
>
> I haven't been able to find out what is creating this persistent low
> frequency wave.  My best guess is that it is somehow triggered by the sudden
> onset of the sinusoidal forcing by the plane wave.  Is there a way to ramp
> up the forcing signal?  Is this likely to be the cause?
>
> Thanks
> Gib
>

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

Re: [Meep-discuss] Numerical dispersion?

[Filip Dominec]

Hi, Glenn,
in my experience, the speed of light and generally the results in MEEP
are quite accurate (compared to theory, other methods or experiment)
until the wavelength becomes comparable to several voxels - in which
case however also the structure ceases to be described correctly. Thus
I believe that a well-defined simulation with reasonable resolution
should not suffer from numerical dispersion. Any additional correction
for this would involve additonal computational steps.
Filip

2015-03-30 0:58 GMT+02:00, glenn :
> Hi,
>
> Does anyone know if Meep does any sort of correction for numerical
> dispersion (see J. B. Schneider, and C. L. Wagner (1999) "FDTD dispersion
> revisited: Faster-than-light propagation
> ", IEEE
> Microwave and Guided Wave Letters 9 (2): 54-56.)?
>
> If a correction is not automatically made in Meep, would it make sense to
> adjust dielectric constants in a calculation to compensate? Is anyone aware
> of subtle inaccuracies that might result from doing this?
>
> Glenn

___
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 is "strides" in Meep sources?

[Filip Dominec]

Hi, I am still quite happy with my explanation that the function
assigns correct amount of bytes (or reals or doubles?) to be skipped
for each direction. Along Z, it is just the next byte; along Y, one
has to skip the number of cells in row, and along X, one has to skip
the number of bytes in row times in column. Makes sense to me. In
fact, I do not consider this approach too "yucky".
The function initializes the array at once, this is why there is a
cycle over the X,Y,Z dimensions.

Filip

2015-03-26 18:18 GMT+01:00, Alex :
> Thanks for answer, Filip.
> It is obviously not distance in bytes. It is something like direction.
>
> Pieces of sources:
>
>   enum direction { X=0,Y,Z,R,P, NO_DIRECTION };
>
>   int num_direction(direction d) const {
> return num[((int) d) % 3];
>   };
>
>   int nr() const { return num_direction(R); }
>   int nx() const { return num_direction(X); }
>   int ny() const { return num_direction(Y); }
>   int nz() const { return num_direction(Z); }
>
> // START READING HERE
>
> void grid_volume::set_strides() {
>   FOR_DIRECTIONS(d) the_stride[d] = 0; // Yuck yuck yuck.
>   LOOP_OVER_DIRECTIONS(dim,d)
> switch(d) {
> case Z: the_stride[d] = 1; break;
> case R: the_stride[d] = nz()+1; break;
> case X: the_stride[d] = (nz()+1)*(ny() + 1); break;
> case Y: the_stride[d] = nz() + 1; break;
> case P: break; // There is no phi stride...
> case NO_DIRECTION: break; // no stride here, either
> }
> }
>
> 2015-03-26 20:07 GMT+03:00 Filip Dominec :
>> As far as I understood the source, the 'stride' represents how much
>> bytes in the computer memory shall be skipped to get to the voxel in
>> the neighboring row.
>> More readable, but perhaps less efficient, implementation would be to
>> address the voxels as a 2-D or 3-D array.
>> Is this correct?
>> Filip
>>
>> 2015-03-26 17:53 GMT+01:00, Alex :
>>> Dear Meep users and developers.
>>> I'm trying to understand Meep sources. So, what means "stride"? Why
>>> project needs additional source file "step_generic_stride1.cpp"
>>> (automatically generated)?
>>>
>>> Sorry if answers of this questions are obvious. English and C++ is not
>>> my native languages.
>>>
>>> Best regards, Alex Friman
>>> LPI RAS
>>>
>>> ___
>>> 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] What is "strides" in Meep sources?

[Filip Dominec]

As far as I understood the source, the 'stride' represents how much
bytes in the computer memory shall be skipped to get to the voxel in
the neighboring row.
More readable, but perhaps less efficient, implementation would be to
address the voxels as a 2-D or 3-D array.
Is this correct?
Filip

2015-03-26 17:53 GMT+01:00, Alex :
> Dear Meep users and developers.
> I'm trying to understand Meep sources. So, what means "stride"? Why
> project needs additional source file "step_generic_stride1.cpp"
> (automatically generated)?
>
> Sorry if answers of this questions are obvious. English and C++ is not
> my native languages.
>
> Best regards, Alex Friman
> LPI RAS
>
> ___
> 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] Calculation of response time of a device in meep

[Filip Dominec]

Dear Nirmala,
the time of propagation is given by the group velocity of the signal
in the structure times the structure size.

Note the group velocity may be significantly (10x-100x) slower that
the speed of light if you compute it near the edge of the pass band.

If there were any resonances, they might take very long to decay
sufficiently, depending on their quality. Assuming there are none, let
us give the simulation time as 5*size, and increase this value if the
signal gets clipped. This is observed as characteristic ringing in the
spectra.

Filip


2015-03-26 10:22 GMT+01:00, nirmala dsouza :
> Sir,
>
> Using meep, I had designed a 2d photonic crystal with dielectric rods in
> air for gate application . It has two inputs and one output. These two
> inputs (sources) are applied at each end of the two waveguides and the
> other end is connected to the output waveguide. It is like a Y shaped PC
> waveguide. Now I want to calculate , how much time the  device will take
> responds to the input signals ?
>
>
> Nirmala
>
> On Thu, Mar 26, 2015 at 12:35 PM, Filip Dominec 
> wrote:
>
>> Hi, Nimala,
>> perhaps it is possible. Could you specify your task in more specific
>> words, please?
>> The custom source can be easily found on the net, e.g.
>>
>> http://comments.gmane.org/gmane.comp.science.electromagnetism.meep.general/3936
>> Filip
>>
>> 2015-03-26 3:57 GMT+01:00, nirmala dsouza :
>> > I want to calculate response time of a photonic crystal optical gate.
>> > Is
>> it
>> > possible to calculate this using meep? If Yes , please help me to find
>> > this. I also want to know code for giving a  square pulse in meep
>> (scheme)
>> >
>> >
>> >
>> > Nirma
>> >
>>
>

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

Re: [Meep-discuss] Calculation of response time of a device in meep

[Filip Dominec]

Hi, Nimala,
perhaps it is possible. Could you specify your task in more specific
words, please?
The custom source can be easily found on the net, e.g.
http://comments.gmane.org/gmane.comp.science.electromagnetism.meep.general/3936
Filip

2015-03-26 3:57 GMT+01:00, nirmala dsouza :
> I want to calculate response time of a photonic crystal optical gate. Is it
> possible to calculate this using meep? If Yes , please help me to find
> this. I also want to know code for giving a  square pulse in meep (scheme)
>
>
>
> Nirma
>

___
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 can't find HDF5 libraries during ./configure

[Filip Dominec]

rialhl_fortran.so.8
> /usr/lib/x86_64-linux-gnu/libhdf5_openmpi_hl.so
> /usr/lib/x86_64-linux-gnu/libhdf5_hl_cpp.so.8
> /usr/lib/x86_64-linux-gnu/libhdf5_serial.so
> /usr/lib/x86_64-linux-gnu/libhdf5_cpp.so.8
> /usr/lib/x86_64-linux-gnu/libhdf5_openmpi_fortran.so
> /usr/lib/x86_64-linux-gnu/libhdf5_openmpi.so.8
> /usr/lib/x86_64-linux-gnu/libhdf5_openmpihl_fortran.so
> /usr/lib/x86_64-linux-gnu/libhdf5_cpp.a
> /usr/lib/x86_64-linux-gnu/libhdf5_openmpihl_fortran.so.8
> /usr/lib/x86_64-linux-gnu/libhdf5_serial_fortran.a
> /usr/lib/jni/libjhdf5.so
>
> I also tried to add the libraries separately with:
> export
> LD_RUN_PATH="/usr/local/lib/:/usr/lib/x86_64-linux-gnu/hdf5/openmpi/"
>
> but no luck.
>
>
> On Mon, 2015-03-23 at 09:10 +0100, Filip Dominec wrote:
>> Hi,
>> from what you wrote, I feel motivated to help you. Not only are there
>> many users of python-meep, but even more I am wondering what may be
>> wrong with that blue box script. I would be thankful if you help me
>> find this out.
>>
>> Python-meep should really be a frontend for MEEP; all interfacing with
>> HDF5 files is done through the libmeep.so's built-in functions. If
>> libmeep.so behaves differently, you perhaps use two different versions
>> of the library. Note that the blue script installs into /usr/local/lib
>> instead of the default /usr/lib. This is to allow coexistence with the
>> libraries from the repository. Python-meep then loads the libmeep
>> library from /usr/local/lib, but by default, meeps loads the latter. I
>> guess that's it.
>>
>> To find the actual problem: About a month ago, I made a change in the
>> procedure, changing line #17 to replace 'libhdf5-serial-dev' with
>> 'libhdf5-openmpi-dev'. Although both versions worked on my system
>> (ubuntu 13.10), the second one should be faster. Can you remember
>> which version you used? Can you please recompile meep and python-meep
>> again, testing these two (serial / openmpi) versions?
>>
>> Best,
>> Filip
>>
>>
>>
>>
>> 2015-03-23 2:25 GMT+01:00, c7...@gmx.net :
>> > That script is actually what I based my build on, and from what I can
>> > tell it is working fine for the most part. However, what is not working
>> > are the HDF5 output functions in MPI mode and using python-meep. If you
>> > use OpenMPI, the program will continue to run forever because it can't
>> > write to the files. The processes are blocking each other. OpenMPI
>> > doesn't tell you that, MPICH however does.
>> >
>> > This does not seem to be problem with Meep, but with python-meep. I
>> > wrote a small *.ctl script to test the output functions and they work.
>> > Somehow python-meep is using the wrong hdf5 libraries (the ones that
>> > don't have mpi enabled), if that is even possible. I thought it was
>> > "just" a frontend for meep.
>> >
>> > Installing Meep from the repositories on Debian Jessie was the first
>> > thing I did, then I compiled python-meep against those and got the it
>> > running. Non-MPI worked flawless. MPI-Mode worked, but without the hdf5
>> > functions.
>> >
>> > Then I tried to compile everything myself, because I could not find any
>> > answers on the matter, and that is when I encountered my original
>> > problem with "./configure" not finding HDF5 libraries either.
>> >
>> >
>> >
>> > On Sun, 2015-03-22 at 22:17 +0100, Filip Dominec wrote:
>> >> Hi, I would traditionally refer you to the blue-boxed compilation
>> >> procedure at http://f.dominec.eu/meep/index.html#install
>> >>
>> >> I tested it on different Ubuntu/Debian machines. Does it work on your
>> >> system?
>> >>
>> >> Filip
>> >>
>> >> 2015-03-22 3:07 GMT+01:00, c7...@gmx.net :
>> >> > Unfortunately that didn't work, but it definitely has something to do
>> >> > with
>> >> > the MPI. I just compiled all packages without it and MEEP finds the
>> >> > libraries.
>> >> > Something is preventing meep from finding the HDF5 packages when it
>> >> > is
>> >> > compiled with mpi-support.
>> >> >
>> >> > Greetings
>> >> > c7420
>> >> >
>> >> > Gesendet: Sonntag, 22. März 2015 um 00:34 Uhr
>> >> > Von: "Pavel Ivanov" 
>> >> > An: c7...@gmx.net
>> >> > B

Re: [Meep-discuss] Frequency-domain solver

[Filip Dominec]

Hi, Gib,
I am pleased your problem was resolved.

The frequency-domain solver should give the same results as the
time-domain solver (with Fourier transform). I wrote an example script
which does exactly such comparison for a metamaterial cell:

https://github.com/FilipDominec/python-meep-utils, look for
'example_frequency_domain_solver'

The examples are written using python-meep, as I need tight
integration with numerical processing which I was not able to do in
scheme.

Filip


2015-03-19 5:25 GMT+01:00, Gib Bogle :
> Hi Filip,
>
> The Meep code has been updated on the cluster, and now the program does not
> crash at that point.  It obviously is a memory hog, though, and I am still
> discovering how much it needs to avoid running out.
>
> On a different but connected topic: I would like to set up a cluster run
> that solves multiple cases, e.g. varying the frequency.  It would be great
> if you could point me to an example .ctl file that executes multiple
> simulations, creating file names appropriately.
>
> Thanks
> Gib
> ________
> From: Filip Dominec [filip.domi...@gmail.com]
> Sent: Thursday, 19 March 2015 12:16 p.m.
> To: Gib Bogle
> Cc: meep-discuss
> Subject: Re: [Meep-discuss] Frequency-domain solver
>
> Exactly, this is the trunk repository with the most fresh code.
> F. D.
>
> 2015-03-19 0:11 GMT+01:00, Gib Bogle :
>> I don't think you were confused, but I'm wondering where I should get the
>> fixed code from.
>> Is this it?  git clone https://github.com/stevengj/meep
>>
>> Gib
>> 
>> From: Filip Dominec [filip.domi...@gmail.com]
>> Sent: Thursday, 19 March 2015 12:05 p.m.
>> To: Gib Bogle
>> Cc: meep-discuss
>> Subject: Re: [Meep-discuss] Frequency-domain solver
>>
>> Hi, Gib, perhaps I was a bit confused. The fact is that MEEP source
>> has been fixed by the commit I mentioned, and it was not before April
>> 2014. Therefore if the release 1.2.1 comes from March, it is probably
>> not fixed (no matter it is currently the latest official release I am
>> aware of).
>>
>> I guess you need to recompile, then. I would be thankful for the
>> procedure that finally works for you, too.
>>
>> Regards,
>> Filip
>>
>> 2015-03-18 23:46 GMT+01:00, Gib Bogle :
>>> Hi Filip,
>>>
>>> I see that the version I have built (with Cygwin on Windows) has source
>>> code
>>> dated 29/3/2014.  I downloaded meep-1.2.1.tar.gz from
>>> http://ab-initio.mit.edu/wiki/index.php/Meep_download in January this
>>> year.
>>> This claims to be the latest release - is this not the case?
>>>
>>> Cheers
>>> Gib
>>> 
>>> From: Filip Dominec [filip.domi...@gmail.com]
>>> Sent: Thursday, 19 March 2015 11:26 a.m.
>>> To: Gib Bogle
>>> Cc: meep-discuss
>>> Subject: Re: [Meep-discuss] Frequency-domain solver
>>>
>>> Hi, Gib, it looks exactly like the bug that has been resolved in git
>>> commit
>>> https://github.com/stevengj/meep/commit/0640e9f6a2ccfa2a40375a89b5692ebb1fb87efb
>>>
>>> Could you check a recent version of MEEP either compiling it from
>>> source (blue box in http://f.dominec.eu/meep/index.html#install), or
>>> installing e.g. from Ubuntu 14.10 repository, where, as far as I know,
>>> it has been updated?
>>>
>>> Filip
>>>
>>> 2015-03-18 22:01 GMT+01:00, Gib Bogle :
>>>> I am trying to use the frequency-domain solver for a 3D problem,
>>>> 25x25x22
>>>> with resolution=10.  The output from
>>>> (meep-fields-solve-cw fields)
>>>> is:
>>>> Meep: using complex fields.
>>>> on time step 1 (time=0.05), 41.9989 s/step
>>>> final residual = 0
>>>> Finished solve_cw after 1 steps and 0 CG iters.
>>>>
>>>> It seems that nothing is done, taking 42 sec.  I think that the way to
>>>> see
>>>> the waveform at a point is:
>>>> (run-until 10
>>>> (to-appended "ex"
>>>> (at-every 0.05
>>>> (in-point sample_point output-efield-x)
>>>> )
>>>> )
>>>> )
>>>>
>>>> and this gives the same result - i.e. the solution starting from 0 - as
>>>> if
>>>> I
>>>> had not previously invoked meep-fields-solve-cw.
>>>>
>>>> I have seen other posts on the mailing list on this subject, but I have
>>>> not
>>>> been able to find any resolution.  It would be very helpful to have an
>>>> explanation of this apparent problem.  Does the frequency-domain solver
>>>> work?
>>>>
>>>> Thanks
>>>> Gib
>>>>
>>>>
>>>>
>>>
>>
>

___
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-domain solver

[Filip Dominec]

Exactly, this is the trunk repository with the most fresh code.
F. D.

2015-03-19 0:11 GMT+01:00, Gib Bogle :
> I don't think you were confused, but I'm wondering where I should get the
> fixed code from.
> Is this it?  git clone https://github.com/stevengj/meep
>
> Gib
> ________
> From: Filip Dominec [filip.domi...@gmail.com]
> Sent: Thursday, 19 March 2015 12:05 p.m.
> To: Gib Bogle
> Cc: meep-discuss
> Subject: Re: [Meep-discuss] Frequency-domain solver
>
> Hi, Gib, perhaps I was a bit confused. The fact is that MEEP source
> has been fixed by the commit I mentioned, and it was not before April
> 2014. Therefore if the release 1.2.1 comes from March, it is probably
> not fixed (no matter it is currently the latest official release I am
> aware of).
>
> I guess you need to recompile, then. I would be thankful for the
> procedure that finally works for you, too.
>
> Regards,
> Filip
>
> 2015-03-18 23:46 GMT+01:00, Gib Bogle :
>> Hi Filip,
>>
>> I see that the version I have built (with Cygwin on Windows) has source
>> code
>> dated 29/3/2014.  I downloaded meep-1.2.1.tar.gz from
>> http://ab-initio.mit.edu/wiki/index.php/Meep_download in January this
>> year.
>> This claims to be the latest release - is this not the case?
>>
>> Cheers
>> Gib
>> 
>> From: Filip Dominec [filip.domi...@gmail.com]
>> Sent: Thursday, 19 March 2015 11:26 a.m.
>> To: Gib Bogle
>> Cc: meep-discuss
>> Subject: Re: [Meep-discuss] Frequency-domain solver
>>
>> Hi, Gib, it looks exactly like the bug that has been resolved in git
>> commit
>> https://github.com/stevengj/meep/commit/0640e9f6a2ccfa2a40375a89b5692ebb1fb87efb
>>
>> Could you check a recent version of MEEP either compiling it from
>> source (blue box in http://f.dominec.eu/meep/index.html#install), or
>> installing e.g. from Ubuntu 14.10 repository, where, as far as I know,
>> it has been updated?
>>
>> Filip
>>
>> 2015-03-18 22:01 GMT+01:00, Gib Bogle :
>>> I am trying to use the frequency-domain solver for a 3D problem, 25x25x22
>>> with resolution=10.  The output from
>>> (meep-fields-solve-cw fields)
>>> is:
>>> Meep: using complex fields.
>>> on time step 1 (time=0.05), 41.9989 s/step
>>> final residual = 0
>>> Finished solve_cw after 1 steps and 0 CG iters.
>>>
>>> It seems that nothing is done, taking 42 sec.  I think that the way to
>>> see
>>> the waveform at a point is:
>>> (run-until 10
>>> (to-appended "ex"
>>> (at-every 0.05
>>> (in-point sample_point output-efield-x)
>>> )
>>> )
>>> )
>>>
>>> and this gives the same result - i.e. the solution starting from 0 - as
>>> if
>>> I
>>> had not previously invoked meep-fields-solve-cw.
>>>
>>> I have seen other posts on the mailing list on this subject, but I have
>>> not
>>> been able to find any resolution.  It would be very helpful to have an
>>> explanation of this apparent problem.  Does the frequency-domain solver
>>> work?
>>>
>>> Thanks
>>> Gib
>>>
>>>
>>>
>>
>

___
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-domain solver

[Filip Dominec]

Hi, Gib, perhaps I was a bit confused. The fact is that MEEP source
has been fixed by the commit I mentioned, and it was not before April
2014. Therefore if the release 1.2.1 comes from March, it is probably
not fixed (no matter it is currently the latest official release I am
aware of).

I guess you need to recompile, then. I would be thankful for the
procedure that finally works for you, too.

Regards,
Filip

2015-03-18 23:46 GMT+01:00, Gib Bogle :
> Hi Filip,
>
> I see that the version I have built (with Cygwin on Windows) has source code
> dated 29/3/2014.  I downloaded meep-1.2.1.tar.gz from
> http://ab-initio.mit.edu/wiki/index.php/Meep_download in January this year.
> This claims to be the latest release - is this not the case?
>
> Cheers
> Gib
> ________
> From: Filip Dominec [filip.domi...@gmail.com]
> Sent: Thursday, 19 March 2015 11:26 a.m.
> To: Gib Bogle
> Cc: meep-discuss
> Subject: Re: [Meep-discuss] Frequency-domain solver
>
> Hi, Gib, it looks exactly like the bug that has been resolved in git
> commit
> https://github.com/stevengj/meep/commit/0640e9f6a2ccfa2a40375a89b5692ebb1fb87efb
>
> Could you check a recent version of MEEP either compiling it from
> source (blue box in http://f.dominec.eu/meep/index.html#install), or
> installing e.g. from Ubuntu 14.10 repository, where, as far as I know,
> it has been updated?
>
> Filip
>
> 2015-03-18 22:01 GMT+01:00, Gib Bogle :
>> I am trying to use the frequency-domain solver for a 3D problem, 25x25x22
>> with resolution=10.  The output from
>> (meep-fields-solve-cw fields)
>> is:
>> Meep: using complex fields.
>> on time step 1 (time=0.05), 41.9989 s/step
>> final residual = 0
>> Finished solve_cw after 1 steps and 0 CG iters.
>>
>> It seems that nothing is done, taking 42 sec.  I think that the way to see
>> the waveform at a point is:
>> (run-until 10
>> (to-appended "ex"
>> (at-every 0.05
>> (in-point sample_point output-efield-x)
>> )
>> )
>> )
>>
>> and this gives the same result - i.e. the solution starting from 0 - as if
>> I
>> had not previously invoked meep-fields-solve-cw.
>>
>> I have seen other posts on the mailing list on this subject, but I have
>> not
>> been able to find any resolution.  It would be very helpful to have an
>> explanation of this apparent problem.  Does the frequency-domain solver
>> work?
>>
>> Thanks
>> Gib
>>
>>
>>
>

___
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-domain solver

[Filip Dominec]

Hi, Gib, it looks exactly like the bug that has been resolved in git
commit 
https://github.com/stevengj/meep/commit/0640e9f6a2ccfa2a40375a89b5692ebb1fb87efb

Could you check a recent version of MEEP either compiling it from
source (blue box in http://f.dominec.eu/meep/index.html#install), or
installing e.g. from Ubuntu 14.10 repository, where, as far as I know,
it has been updated?

Filip

2015-03-18 22:01 GMT+01:00, Gib Bogle :
> I am trying to use the frequency-domain solver for a 3D problem, 25x25x22
> with resolution=10.  The output from
> (meep-fields-solve-cw fields)
> is:
> Meep: using complex fields.
> on time step 1 (time=0.05), 41.9989 s/step
> final residual = 0
> Finished solve_cw after 1 steps and 0 CG iters.
>
> It seems that nothing is done, taking 42 sec.  I think that the way to see
> the waveform at a point is:
> (run-until 10
> (to-appended "ex"
> (at-every 0.05
> (in-point sample_point output-efield-x)
> )
> )
> )
>
> and this gives the same result - i.e. the solution starting from 0 - as if I
> had not previously invoked meep-fields-solve-cw.
>
> I have seen other posts on the mailing list on this subject, but I have not
> been able to find any resolution.  It would be very helpful to have an
> explanation of this apparent problem.  Does the frequency-domain solver
> work?
>
> Thanks
> Gib
>
>
>

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

Re: [Meep-discuss] h5ls: unable to open file. python -meep

[Filip Dominec]

Hi, Julián,
your script works for me. I get the same result from 1- and 2-process
simulation.

I have h5utils in version 1.12.1, and freshly-compiled meep 1.2.1 &
python-meep according to the blue box at
http://f.dominec.eu/meep/index.html#install

Could you somehow examine the sample.h5 file? Its size? For example:

x@dominecf-F9E:/tmp/ju $ h5ls sample.h5
ez.i Dataset {160, 320, 112/Inf}
ez.r Dataset {160, 320, 112/Inf}
x@dominecf-F9E:/tmp/ju $ ll sample.h5
-rw-rw-r-- 1 x x 89621 Mar 13 09:42 sample.h5

Filip

2015-03-13 3:29 GMT+01:00, Julián Pita :
> Hello,
>
>
> I have a problem reading the hdf5 file of the field (sample.h5).  When I try
> h5ls   it gives me: unable to open file.
> (h5ls: Version 1.8.14)
>
> h5ls sample-eps.h5
> eps  Dataset {160, 320}
>
> h5ls sample.h5
> sample.h5: unable to open file
>
> Best regards,
>
> Julián.
>
>
>
> Code:
>
> from meep_mpi import *
> #define the waveguide material as a function of a vector(X,Y) :
> #we create a straight waveguide of widdth 1 over the full length
> class epsilon(Callback):
>   def double_vec(self,vec):
>   if ((vec.y() >= 4) and (vec.y() <= 5)):
>   return 12
>   else:
>   return 1
>
> #create the computational grid of size 16 x 32 with resolution of 10
> vol = voltwo(16,32,10)
>
> #create a structure with PML of thickness = 1, using the class 'epsilon'
> material = epsilon()
> set_EPS_Callback(material.__disown__())
> s = structure(vol, EPS, pml(1))
>
> #define a gaussian line source of length 1 at X=1, Y=4
> #with center frequency 0.15 and pulse width 0.1
> srcGaussian = gaussian_src_time(0.15, 0.1)
> srcGeo = volume(vec(1,4),vec(1,5))
>
> #create the fields
> f = fields(s)
> f.add_volume_source(Ez, srcGaussian, srcGeo)
>
> #export the dielectric
> epsFile = prepareHDF5File("./sample-eps.h5")
> f.output_hdf5(Dielectric, vol.surroundings(), epsFile)
>
> #define the file for output of the field components
> ezFile = prepareHDF5File("./sample.h5")
>
> #define a probing point at the end of the waveguide
> #to check if source has decayed
> probingPoint = vec(14.5,4.5)
>
> #start the simulation, sending HDF5 output to the file 'ezFile'
> runUntilFieldsDecayed(f, vol, Ez, probingPoint, pHDF5OutputFile = ezFile)
> ___
> 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] Seeking advice for measuring transmission spectra

[Filip Dominec]

Dear John,
I can not confirm not deny your approach is correct.

I use another way to get the incident/transmitted/reflected fields
from a structure in free space. Most importantly, it provides also the
phase information, and also allows to get all the reflection and
transmission coefficients in single simulation run.

The results from this approach have been repeatedly confirmed by
experiment and with results from other labs. It also works for oblique
incidence. It is however not suitable for waveguides with mode
profiles different from plane wave.

The code is in 
https://github.com/FilipDominec/python-meep-utils/blob/master/meep_utils.py
and the corresponding function is `get_s_parameters'. I tried to
provide the necessary comments in the body of this function, too.

Filip




2015-02-18 3:42 GMT+01:00, John Ball :
> I've spent a lot of time today continuing to try to figure this out. I've
> realized that my idea of using add_dft_flux with Sx, Sy, and Sz separately
> and computing |S|dVdt isn't valid, because the output of add_dft_flux gives
> a cumulative sum of S over time, instead of the instantaneous power.
>
> Here's what I'm doing now. It's giving me the most reasonable results I've
> obtained so far, but I'm not completely confident:
>
> 1. Using "monitor_point"s to output the real & imag parts of ex, ey, ez,
> hx, hy, hz at each time point.
> 2. In Matlab, load and combine the real & imaginary parts of each field
> component.
> 3. Compute the Fourier transform of each field component to get Ex(omega),
> Hx(omega), etc.
> 4. Use S = E x H* on the Fourier transformed field components to get
> Sx(omega), Sy(omega), Sz(omega).
>
> The result seems to possess the same frequency spectrum as ex, hx, etc.
> individually. I also tried computing S = E x H* on the time-series data and
> Fourier transforming the result (the reverse order of operations from what
> I describe above), but the resulting spectrum is centered around omega=0,
> rather than having a peak near a ~500 nm wavelength, which is the peak of
> my source. Is this computation valid? I think my main confusion lies in
> handling the Poynting vector(s) in the frequency domain rather than in the
> time domain.
>

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

Re: [Meep-discuss] help for calculation of transmission and reflection of photnic crystals slabs

[Filip Dominec]

Hi, Saeid,
your task has been perhaps done by somebody else, please take a look at
https://timsaucer.wordpress.com/2013/04/30/building-l3-photonic-crystal-cavity-in-meep-1-finding-mode/,
http://comments.gmane.org/gmane.comp.science.electromagnetism.meep.general/10,
http://osdir.com/ml/science.electromagnetism.meep.general/2008-03/msg00096.html
etc.

There are various properties of periodic structures, and multiple
approaches to compute them. FDTD is useful for some of these, but you
may be also interested in PWEM (implemented in e.g. MPB).

Filip

2015-02-14 9:05 GMT+01:00, Saeid Gholami :
> Dear prof. JohnsonI try to compute the reflection and transmission spectra
> for Photonic crystals slabs but I could not. please help me and other Meep
> user.I ask you to give us a input file or example of 3D calculation to
> simulate the Photonic crystals slabs. please help us.
> Thanks a lot.
>

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

Re: [Meep-discuss] Error while using perfect-metal

[Filip Dominec]

Dear Jim,
this seems to be a result of instability, resulting in saturated (i.e.
infinite or NaN) values as you suggest.
To verify this, you may shorten the simulation until you get some
image that is not plain black. As a matter of fact, the instability
does not occur instantly, but it takes it several tens  or hundreds of
steps to reach "inifinity". You can then identify where the problem
starts.
I have no experience with perfect-metal in MEEP, though.
Filip

2015-02-11 12:52 GMT+01:00, jim kurian :
> Hello,
>
>
> I am new to Meep and I am facing problems when I use the material type
> perfect-metal. Whenever I try to simulate anything using perfect-metal
> material type or metal (the defined variable) the output .png files are
> just black blocks. It is as if the values are saturated.
>
> Can you please explain why this happens and what can be done to avoid it.
>
> Thank you.
>

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

Re: [Meep-discuss] Gaissian Distribution of Phase

[Filip Dominec]

Hi, currently I do not have the example you mention, but surely you
can make a focused beam from an oblique beam, by introducing a
*quadratic* term into the imaginary part of the exponential that
defines the source amplitude.
If you wish to build a focused *gaussian* beam, you will also wish to
modify the amplitude in the exponent.
Filip


2015-01-07 13:05 GMT+01:00, Yousuf Khan :
> Dear Steven and meep users,
> I already saw some examples of oblique source by introducing a phase shift
> in source function. Is it possible to construct a focused source by Gaussian
> distribution of phase ? If yes, can anybody give an example
> please. Regards,
> Yousuf Khan

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

Re: [Meep-discuss] Puzzling results for reflection spectrum

[Filip Dominec]

Hi, if you properly divide the reflected amplitude by the incident
amplitude, the reflection of a linear system should indeed be the
same, independent of the source duration and spectrum.
If it is not, one possible cause may be that you clip the time record
while the source was still running, or the structure was still
retaining some energy in resonances. What happens if you run the
simulation for 2x and 3x longer time?
Filip

2015-02-10 22:30 GMT+01:00, Gib Bogle :
> I am getting puzzling inconsistencies between results for the reflection
> spectrum of a scatterer when I vary the width of the Gaussian pulse.  Since
> I am a beginner this probably stems from my lack of understanding of
> something.
>
> The scattering antenna is a metal loop with a small gap (i.e. the loop is
> not closed).  The conductor cross-section is rectangular, 0.2 wide and 0.1
> thick (all Meep units).  The inner radius is 0.868, and the gap is 0.2.  The
> antenna lies in the xy plane, centred at the origin.
>
> The region size is 4p x 4p x 6p, where p=6, and the PML thickness is p.  The
> plane wave source is located at the lower edge of the PML, i.e. at z = -2p,
> and the flux plane is at z = -p, halfway between the wave source and the
> antenna.  The frequency I am interested in is 5.5 GHz, i.e. a Meep frequency
> of 0.1833 with a Meep unit distance of 0.01m.  This corresponds to a Meep
> wavelength of 5.456, which explains why I am using p=6.
>
> I am using resolution=20.  The Gaussian pulse that is exciting the
> reflection has a centre frequency of 0.1833, and I have simulated various
> pulse widths, always with nfreq=100.  With df=0.1 the reflection spectrum
> has a well-defined minimum at (0.139, 1.3E-06), and a flat local minimum at
> (0.181, 8.35E-6).  With df=0.2 there is just a very flat minimum at (0.178,
> 1.97E-6), and with df=0.3 a minimum at (0.1, 1.61E-6).  Zooming in with
> df=0.05 shows just the local minimum at (0.183, 8.4E-6), more like a point
> of inflection.
>
> Are these results surprising?  Am I making an obvious mistake?  I would be
> grateful for guidance.
>
> Thanks
> Gib
>

___
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 a invariable complex refractive index?

[Filip Dominec]

Dear Liu,
from the principle of FDTD computation, there is no other way how to
define complex refractive index than to include dispersion. Either you
may introduce a Drude term (conductivity), or some high-frequency
Lorentzian.
More details are here:
http://ab-initio.mit.edu/wiki/index.php/Material_dispersion_in_Meep
Filip

2014-12-06 13:47 GMT, liu :
> Hi, everyone,
>
>
> 1) I want to define a wavelength independent complex refractive index in
>
>
> meep, for example, n= 5+0.05i. Because I just want to simulate the
> absorption
>
>
> of the materials, so we do not need Drude model. But how to define it in
>
>
> meep?
>
>
>
>
> 2) Can meep calculate two-photon absorption? how to define the two-photon
> absorption parameters?
>
>
>
>
> Thank you!
>
>
>
>
>
>

___
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 and python-meep on OS-X

[Filip Dominec]

Thank you, Glenn, great job.
I will be happy to add a link to your post!
Filip

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

Re: [Meep-discuss] Slow calculation with meep parallelisation

[Filip Dominec]

Hi, sorry, I can not tell whether it is a common problem (I did not
encounter this). But I believed it is important to determine whether
it might come from the network issues.
F.

2014-12-02 11:16 GMT+01:00, Gupta, Ratnesh (GE Global Research,
Consultant) :
> Hi Filip,
>
> Yes, I tried multiprocessing on single node too. And the problem persists.
> Is it a common problem with meep multiprocessing?
>
> Thanks and Regards,
> Ratnesh
>
> -Original Message-
> From: Filip Dominec [mailto:filip.domi...@gmail.com]
> Sent: Tuesday, December 02, 2014 3:41 PM
> To: Gupta, Ratnesh (GE Global Research, Consultant)
> Subject: Re: [Meep-discuss] Slow calculation with meep parallelisation
>
> Hi, I believed you might have problems with the inter-node communication in
> the cluster; I wondered whether the problems pertain when the
> multiprocessing is run on single node. Maybe you have tried this?
> F. D.
>
> 2014-12-02 10:02 GMT+01:00, Gupta, Ratnesh (GE Global Research,
> Consultant) :
>> Hi Filip,
>>
>> Thanks for the quick reply. I didn't understand what you mean by
>> running on single node and using different -np option. Or if you meant
>> both separately.
>>
>> I did try running on single node using '-np 1' with 'meep-mpi'. Also I
>> did try with strictly single node using 'meep'. 'meep' and 'meep-mpi with
>> -np 1'
>> took similar time for a smaller model but both ran out of memory for
>> the required geometry size giving the segmentation fault.
>>
>> I hope I could clarify my problem.
>>
>> Thanks and regards,
>> Ratnesh
>>
>> -Original Message-
>> From: Filip Dominec [mailto:filip.domi...@gmail.com]
>> Sent: Tuesday, December 02, 2014 2:24 PM
>> To: Gupta, Ratnesh (GE Global Research, Consultant)
>> Subject: Re: [Meep-discuss] Slow calculation with meep parallelisation
>>
>> Hi, Ratnesh,
>> it indeed seems to be an issue with multiprocessing - did you try to
>> run it on a strictly single node? How does it scale on it when you use
>> different -np option?
>> F.
>>
>> 2014-12-02 9:18 GMT+01:00, Gupta, Ratnesh (GE Global Research,
>> Consultant) :
>>> Hi,
>>>
>>> I've configured a cluster with meep-mpi. I am able to execute the
>>> code. But the code while run with '-np 1' is completely run within
>>> 368 seconds where it took 410 seconds while run with '-np 2'.
>>> Similarly, the time keeps increasing for increasing number of
>>> processors which is not expected.
>>>
>>> Also, I have a huge geometry which I want to simulate and is getting
>>> segmentation fault with single processor. I hoped to run it with
>>> multiple processor so that do decrease the probability of
>>> segmentation fault.
>>>
>>> Please help.
>>>
>>> Thanks and Regards,
>>> Ratnesh
>>>
>>
>

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

Re: [Meep-discuss] Scaling - dielectric-epsilon, metal-copper, lattice/resolution and Symmetry

[Filip Dominec]

. Cylindrical coordinates - maybe an answer will come from the
> discussion group.
>
> Filip - If my current run is successful I want to calculate forces
> around the outside of the modeled resonate cavity. I am hopeful that
> Meep can detect forces caused by evanescent wave momentum and if so, I
> will be a long way ahead of game. I appreciate your continued support.
>
> Steve
>
>
> On Mon, 2014-11-24 at 13:53 +0100, Filip Dominec wrote:
>> Dear Steve,
>> 1) Use the value of 2.3. The static permittivity is invariant to scaling.
>>
>> 2) If you wanted to model realistic copper, with scaling of 1:1e6, you
>> would have to feed MEEP with values normalized to the scaling (1e6)
>> and also by the speed of light (2.998e8). For instance, the physical
>> Lorentz oscillator frequencies would have to be divided by 2.998e14 in
>> your scripts, if you intended to exactly model some dielectric [such
>> as http://fzu.cz/~dominecf/misc/eps/].
>>
>> However you can not do this in your case, as your microwave simulation
>> would go unstable. I observed there is a FDTD critical frequency [see
>> http://fzu.cz/~dominecf/meep/index.html#stability], above which the
>> permittivity of all materials has to be positive. If you keep the
>> Courant factor at the default value (0.5), and wish to model a cavity
>> of 0.3 m length with, say one million voxels, your resolution would be
>> 0.003 m and the critical frequency would be about 60 GHz. A metal
>> model that approximately follows the Drude model with correct losses
>> at low frequencies, and that has positive real part of permittivity at
>> higher frequency than 60 GHz, has to be used.
>>
>> I will try to write about a reasonable method how to efficiently
>> define lossy metals for a stable FDTD simulation, on the above
>> mentioned website in the next days.
>>
>> 3) The 50 um thin wall you wrote about is a related topic. I believe
>> you do not wish to use 50 um resolution for a 300 000 um-sized
>> simulation volume in FDTD. One option is to use FEM or other
>> Maxwell-solving method instead, the second one is to define a thin
>> layer of another "effective metal", whose conductivity is
>> appropriately reduced by the ratio of the pixel size to the 50 um
>> thickness. So if you use a voxel size of 3000 um, and so is the
>> thickness of the wall, you define the conductivity as 60 times lower
>> than that of bulk copper.
>>
>> I got very reasonable results when simulating thin metallic layers in
>> MEEP. Of course, all such simulations should be quantitatively
>> verified.
>>
>> 4) Sorry, I can not help with symmetries, in MEEP they never worked
>> for me as I expected.
>>
>> 5) Nor did I use the cylindrical coordinates.
>>
>> Hope this helps anyway. In few days (weeks) these mails should be also
>> approved to appear in the mailing list.
>> Filip
>>
>>
>>
>>
>> 2014-11-23 19:31 GMT+01:00, Steve :
>> > Dear Steven and Meep users,
>> >
>> > It has been several days since I have been able to post. Issues have
>> > accumulated.
>> >
>> > 1 - In my Meep model I am using a dielectric resonator made of
>> > Polyethylene,
>> > PE. High density PE has a dielectric constant = 2.3. across a broad
>> > range of frequencies. Do I use this value as the value of epsilon, as
>> > in
>> > (material (make dielectric (epsilon 2.3))) ?
>> > Or does it need to be scaled somehow into Meep units? If so, How is it
>> > scaled?
>> >
>> > 2 - I am using Copper, courtesy of  Aaron Webster -
>> > http://fzu.cz/~dominecf/meep/data/meep-metals.pdf. The data
>> > Normalization length=1e-06 in meter. What does that mean to me
>> > specifically with respect to my lattice size and resolution? Also see
>> > 3,
>> > below.
>> >
>> > 3 - I am modeling a closed truncated copper cone resonator with very
>> > thin copper ends. A 2-D model. The general dimensions of the cone are
>> > 0.10 to 0.30 meter, the end thicknesses are 5e-5 meters and the drive
>> > frequency is 2 GHz. For low resolution h5topng does not show the ends
>> > but for high resolution (400) Meep does not execute succesfully for
>> > lattice sizes large enough to contain the device. I would like to use
>> > meep length a=1e-6 but that seems unapproachable. What am I missing in
>> > my understanding of scaling, lattice size and resolution?
>> >
>> > 4 - I have tried to use symmetry to speed the calculations. It does,
>> &g

Re: [Meep-discuss] Scaling - dielectric-epsilon, metal-copper, lattice/resolution and Symmetry

[Filip Dominec]

Dear Steve,
1) Use the value of 2.3. The static permittivity is invariant to scaling.

2) If you wanted to model realistic copper, with scaling of 1:1e6, you
would have to feed MEEP with values normalized to the scaling (1e6)
and also by the speed of light (2.998e8). For instance, the physical
Lorentz oscillator frequencies would have to be divided by 2.998e14 in
your scripts, if you intended to exactly model some dielectric [such
as http://fzu.cz/~dominecf/misc/eps/].

However you can not do this in your case, as your microwave simulation
would go unstable. I observed there is a FDTD critical frequency [see
http://fzu.cz/~dominecf/meep/index.html#stability], above which the
permittivity of all materials has to be positive. If you keep the
Courant factor at the default value (0.5), and wish to model a cavity
of 0.3 m length with, say one million voxels, your resolution would be
0.003 m and the critical frequency would be about 60 GHz. A metal
model that approximately follows the Drude model with correct losses
at low frequencies, and that has positive real part of permittivity at
higher frequency than 60 GHz, has to be used.

I will try to write about a reasonable method how to efficiently
define lossy metals for a stable FDTD simulation, on the above
mentioned website in the next days.

3) The 50 um thin wall you wrote about is a related topic. I believe
you do not wish to use 50 um resolution for a 300 000 um-sized
simulation volume in FDTD. One option is to use FEM or other
Maxwell-solving method instead, the second one is to define a thin
layer of another "effective metal", whose conductivity is
appropriately reduced by the ratio of the pixel size to the 50 um
thickness. So if you use a voxel size of 3000 um, and so is the
thickness of the wall, you define the conductivity as 60 times lower
than that of bulk copper.

I got very reasonable results when simulating thin metallic layers in
MEEP. Of course, all such simulations should be quantitatively
verified.

4) Sorry, I can not help with symmetries, in MEEP they never worked
for me as I expected.

5) Nor did I use the cylindrical coordinates.

Hope this helps anyway. In few days (weeks) these mails should be also
approved to appear in the mailing list.
Filip




2014-11-23 19:31 GMT+01:00, Steve :
> Dear Steven and Meep users,
>
> It has been several days since I have been able to post. Issues have
> accumulated.
>
> 1 - In my Meep model I am using a dielectric resonator made of
> Polyethylene,
> PE. High density PE has a dielectric constant = 2.3. across a broad
> range of frequencies. Do I use this value as the value of epsilon, as
> in
> (material (make dielectric (epsilon 2.3))) ?
> Or does it need to be scaled somehow into Meep units? If so, How is it
> scaled?
>
> 2 - I am using Copper, courtesy of  Aaron Webster -
> http://fzu.cz/~dominecf/meep/data/meep-metals.pdf. The data
> Normalization length=1e-06 in meter. What does that mean to me
> specifically with respect to my lattice size and resolution? Also see 3,
> below.
>
> 3 - I am modeling a closed truncated copper cone resonator with very
> thin copper ends. A 2-D model. The general dimensions of the cone are
> 0.10 to 0.30 meter, the end thicknesses are 5e-5 meters and the drive
> frequency is 2 GHz. For low resolution h5topng does not show the ends
> but for high resolution (400) Meep does not execute succesfully for
> lattice sizes large enough to contain the device. I would like to use
> meep length a=1e-6 but that seems unapproachable. What am I missing in
> my understanding of scaling, lattice size and resolution?
>
> 4 - I have tried to use symmetry to speed the calculations. It does, but
> my cone does not maintain its shape. That is, this code
>
> ;(set! symmetries (list ;
> *Symmetry*
> ;(make rotate4-sym (direction 1) (phase (if xodd? -1 +1)))
> ;   (make rotate2-sym (direction 2))
> ;  (make rotate4-sym (direction 1)   )  ; (phase -1)defaults
> to +1
> ;))
>
> in all cases results in an h5topng image of my cone cut in the y-z plane
> with one end reversed and joined to the same end. Is this a Bug or again
> just my flawed understanding of the workings of symmetry in meep?
>
> 5 - I can run my model using cylindrical coordinates which speeds the
> calculations tremendously but I don't understand how to generate 2-D
> images for presentation. Is it possible? How?
>
> I hope this wish-list doesn't "turn you off." I will continue to search
> for answers and hope for answers to these questions, most likely one/two
> at at time.
>
> Thank you for your consideration and help.
>
> Stephen Russell
>
>
>
> ___
> 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-ini

Re: [Meep-discuss] Dispersive anisotropic media

[Filip Dominec]

Hi, Rajath,
1) I am not able to think up how to get the variable conductivity in
Scheme. The Python interface goes through all the points in space and
asks some function for the value - it is not hard to program some
definition of a, say, inhomogeneously doped semiconductor.
2) I think you question has been answered here:
http://comments.gmane.org/gmane.comp.science.electromagnetism.meep.general/906

Maybe I am wrong and there is some elegant solution to point 1, but
here I can not help.
Filip


2014-11-19 18:47 GMT+01:00, Rajath Shashidhara :
> Hi Filip,
>
> I'm unable to get python-meep working and I'm in a hurry. My best option
> would be to use Scheme for now.
>
> Would you please guide me how to implement the features I've asked for in
> my previous mail using scheme?
>
> Thanks,
> RAJATH S
> Birla Institute of Technology and Science, Pilani
>
> On Wed, Nov 19, 2014 at 9:04 PM, Filip Dominec 
> wrote:
>
>> Dear Rajath,
>> it pretty much looks like missing- or incompatible version of libhdf.
>> Have you tried the compilation procedure from this site?
>> http://fzu.cz/~dominecf/meep/index.html#install
>> I tested it on several different systems to work flawlessly.
>> Filip
>>
>>
>> 2014-11-19 9:09 GMT+01:00, Rajath Shashidhara
>> :
>> > Hi Dominec,
>> > Thanks for the resource. I am not specifically looking to implement it
>> > on
>> > scheme. Infact I'm familiar with python. I'd prefer working with
>> > python.
>> >
>> > I tried to compile python-meep.
>> >
>> > I landed up with this error:
>> > ImportError: /usr/lib64/python2.7/site-packages/_meep.so: undefined
>> symbol:
>> > H5T_C_S1_g
>> >
>> > When I import meep on python.
>> >
>> > Please help me fix this.
>> >
>> > Thank you,
>> > RAJATH S
>> > 2012B5A7589P
>> >
>> > On Wed, Nov 19, 2014 at 4:41 AM, Filip Dominec
>> > 
>> > wrote:
>> >
>> >> Hi, I can do both in Python (some notes here:
>> >> http://fzu.cz/~dominecf/meep/), but perhaps you expect the help to be
>> >> in Scheme.
>> >> F.
>> >>
>> >> 2014-11-18 21:26 GMT+01:00, Rajath Shashidhara <
>> rajaths.raja...@gmail.com
>> >> >:
>> >> > Hello,
>> >> >
>> >> > I am trying to run some FDTD simulations on Meep. I have the
>> >> > following
>> >> > questions:
>> >> >
>> >> > [1] How to model a material using Drude's model whose plasma
>> >> > frequency
>> >> > is
>> >> > dependent on the coordinates ? 'drude-susceptability' option as
>> >> > mentioned
>> >> > in Meep Reference accepts only a number as a parameter to frequency.
>> >> >
>> >> > [2] How to setup bloch's periodic boundary conditions only along
>> >> > y-axis?
>> >> >
>> >> > I could not find an option in k-point variable to configure bloch's
>> >> > conditions according to my need.
>> >> >
>> >> > Please help me in setting up the above things for my simulation.
>> >> >
>> >> > Thank you,
>> >> >
>> >> >
>> >> >
>> >> > Rajath S,
>> >> >
>> >> > M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
>> >> >
>> >> > Birla Institute of Technology and Science - Pilani,
>> >> > Pilani
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Rajath S,
>> > M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
>> > Birla Institute of Technology and Science - Pilani,
>> > Pilani
>> >
>>
>
>
>
> --
> Rajath S,
> M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
> Birla Institute of Technology and Science - Pilani,
> Pilani
>

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

Re: [Meep-discuss] Units in Meep

[Filip Dominec]

I am convinced that it would be more convenient if MEEP allowed one to
use the true SI units. (Thanks to the terahertz time-domain
spectroscopy, I can directly compare data from simulation and from our
laboratory.) The current approach of normalized units is however just
a formal complication and it only requires to be a little careful when
coding.

Citing from my humble "simulation notes" on http://fzu.cz/~dominecf/meep/ :
"In the MEEP's routines, the speed of light is defined as 1.0 (instead
of 2.997e8 m/s), and also the vacuum impedance is 1.0 (instead of 377
Ohm). Therefore, when we feed MEEP with some frequency, we always
divide it by c=2.997e8 and when MEEP returns some frequency value to
us, we in turn multiply it by c. Opposite procedure has to be done
when handling time units etc. As long as linear systems are simulated,
this convention makes no qualitative difference in the results..."

HTH, Filip

2014-11-10 9:44 GMT+01:00, Charalampos Mavidis :
> Dear Steve,
>
> There is a wiki on this mater.
> http://meepunits.wikia.com/wiki/Meep_unit_transformation_Wiki
>
> Charalampos
>
> On Mon, Nov 10, 2014 at 6:17 AM, Stephen Russell 
> wrote:
>
>> Dear Meep Users,
>>
>> Units in Meep - I find many explanations, each more confusing than the
>> last.
>>
>> I am very much a newby. I installed Meep last week and it seems to work
>> as
>> advertised. I am looking at centimeter waves, and have about given up on
>> meep units. What is the problem with using SI units in meep?
>>
>> And if someone would explain meep units, being very clear to
>> differentiate
>> between meep units and SI units, that would be great! Use number examples
>> at each step so I can follow along with my calculator.
>>
>> The confusion starts with the second step of the explanations, the first
>> step, pick a characteristic length-a, I get. The second step- now the
>> speed
>> of light is c/a seems reasonable but next the units are described using
>> c.
>> But what c? SI units or meep units? Numerical examples at each step would
>> make that and all that follows clear to the newby.
>>
>> Thanks for your consideration.
>>
>> Steve
>>
>>
>>
>>
>>
>>
>> ___
>> 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] monochromatic source

[Filip Dominec]

Hi, Farhad,
generally both the continuous and the narrow-band-gaussian sources are
good choices. Note however that for mathematical reasons a source
short in time will always have a broad spectrum. Spectral selectivity
has to be paid with computation time.

Fortunately, the Fourier transform of a gaussian pulse has fast
decaying spectral wings, so a gaussian envelope is somewhat optimal
for your purposes.

Filip


2014-08-21 18:25 GMT+02:00, FARHAD KAZEMI :
> Dear MEEP users,
>
> I am trying to simulate a monochromatic source emitting only with the single
> frequency. Could any body tells me how can I do that?
> which one I have to use, continuous or Gaussian source?
> using these sources, in order to get flux in some where, I am using add-flux
> function. In this case I need to define fcen, df and nfreq which gives an
> spectrum of frequencies instead of one frequency. how can I use this
> function for single frequency?
> Can I use Gaussian source with very narrow df for this purpose?
>
> Thank you so much,
>
> Farhad

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

Re: [Meep-discuss] Part of PML

[Filip Dominec]

Hi, Sophia, as far as I know, it is possible to overlap any material
with PML. The PML condition however applies for the whole boundary, so
it can not be defined in its part only.

Note I had some numerical stability issues when the PML was defined on
one axis only while the other boundaries were periodic. The
nearly-grazing incidence waves could be slightly _amplified_ by PML.
This problem never happened when the PML was at all boundaries, nor it
happened when the structure was defined with sufficient losses.

Filip

2014-08-09 17:15 GMT+02:00, Sophia Fox :
> Hello,
>
> I was wondering is it at all possible to have material on top of the
> PML? The reason I ask is I'd like to only have part of the PML along
> the same axis...
>
> Sophie
>
>
>
> ___
> 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] Complex transmission and reflection coefficients

[Filip Dominec]

Hi, Joshua,
I am not sure if it will be helpful to you, but two years ago I wrote
a similar simulation of complex scattering coefficients
(reflection+transmission) from a SRR or any other metamaterial unit
cell.

The codes are in python-meep and are publicly available at
https://github.com/FilipDominec/meep_metamaterials/

The simulation also automatically computes the effective parameters
[Smith2002]  with correct branch of solution, allows scans over any
structure parameter, can cope with nonperpendicular incidence of wave,
and exports 3D data for Mayavi/Paraview as well as ready-to-publish
plots of various kinds.

The electric/magnetic field averaging is implemented manually using
the get_field() function and the results have been verified many times
to be very realistic. I am not aware that the method you describe
would have any fundamental pitfall from the physical point of view.

Filip


2014-07-03 23:04 GMT+02:00, Joshua Surya :
> Dear Meep Users,
>
> In the past month of trying to learn meep, I have benefited greatly from
> these discussions.  So before my ramble I would like to thank everyone for
> reading this.  I am truly grateful for your help.
>
> I am trying to calculate the effective parameters (namely the permeability
> and permittivity) of the structure I am simulating.  To do so, I must find
> the transmission and reflection coefficients, which to my understanding can
> be found by simply outputting the electric field components twice (with and
> without the structure) and taking a ratio after performing fft on the
> electric field components.
>
> Reflection coefficients = fft(R-R0)/fft(T0)
> Transmission coefficients = fft(T)/fft(T0)
>
> This method has been described previously,
> https://www.mail-archive.com/meep-discuss%40ab-initio.mit.edu/msg04262.html
> https://www.mail-archive.com/meep-discuss%40ab-initio.mit.edu/msg00849.html
>
> The problem I am having is that when I perform a sanity check on the
> coefficients I arrive at, by taking the absolute value squared of the
> reflection and transmission coefficients, I get values that do not make
> sense, and do not match the (power) Reflection and Transmission values that
> I get when I perform the simulation.
>
> To provide additional information about the structure I am simulating, it
> is a column of gold split ring resonators (periodic in the y direction).  I
> included PML in the X direction only.
>
>
> [R]  l  C l
>   l   [S]   C [T]
>   ll  C l
>   ll  C l
>   ll  C l
>   ll  C l
>
> [R]-Reflection line
> [S]-Source line
> [T]-Transmission line
>
> Here is a snippet of my code, I omitted parts that are unimportant.
>
> (set! ensure-periodicity true)
>
> (set! k-point (vector3 0 0 0))
>
> (set! eps-averaging? false)
>
> (set! force-complex-fields? true)
>
> (define-param no-grating? false); if true, then use control
>
> (set! geometry-lattice (make lattice (size sx sy no-size)))
>
> (set! geometry
> (if no-grating?
> (list
> )
> (list
> (make cylinder (center 0 0) (radius outradius) (height infinity)
> (material gold))
> (make cylinder (center 0 0) (radius inradius) (height infinity)
> (material air))
> (make block (center 0.83 0) (size cube cube infinity)
> (material air))
> )))
>
>
> (set! pml-layers (list (make pml (direction X) (thickness 1.0
>
>
> (set! sources
> (list
> (make source
> (src (make gaussian-src (frequency fcen) (fwidth df)))
> (component Hz)
> (center -2.4 0 0)
> (size 0 sy
>
> (run-until
> 560
> (at-beginning output-epsilon)
> (in-volume (volume (center 2.9 0 0) (size 0 sy 0))
> (to-appended "T" (at-every 1 output-efield-y
>
> Thank you all very much for your time.
>
> Joshua Surya
> Electrical and Computer Engineering
> University of Illinois Urbana-Champaign | B.S. Class of 2015
>

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

Re: [Meep-discuss] Multiple wavelengths and light direction

[Filip Dominec]

Hi,
1) spectrum: although the gaussian source with frequency around
(1/1.55) would give an approximate result, you probably want to use
the band_src_time which is described here:
http://fzu.cz/~dominecf/misc/meep/index.html#bandsource
I am going to contribute the code to github today.

2) If you wish the fields to propagate from one wall to the other, it
is trivial. If you wish the fields to emerge in the middle of the
waveguide and to propagate one direction only, it is much more
complicated, as you probably need to optimize two sources close to
each other so that they interfere destructively in one direction.

Filip

2014-06-19 19:03 GMT+02:00, Lynn :
> Hi Meep users!
>
> I am trying to specify a range of wavelengths between 1.5 and 1.6 to put
> into my waveguide and I can not find how to do this! Is it possible? Also I
> only want the light to propagate in the positive y direction, is there a way
> to do that as well? Thanks!!
>
> Lynn Stanwyck

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

Re: [Meep-discuss] real metal material

[Filip Dominec]

Dear John,
I believe your paragraph on setting the epsilon at one given frequency
is correct: The real part can be set directly. The imaginary part of
permittivity is introduced by setting conductivity.
I use the same approach and the frequency-domain computations give
results that can be directly compared to those coming from Fourier
transform of time domain data and to the experimental data from our
laboratory. There is a relatively good match.

HOWEVER, according to to my experience so far, the real part of
permittivity may never be negative even in frequency-domain
computation in MEEP. Whenever I defined the
constant-part-of-permittivity to be  negative, the FDTD/FDFD
simulation always became unstable. You wrote that it "generates NaN
fields if negative real permittivities are invoked", so this could be
the case (except for the detail that NaN data always identified an
instability in my time-domain computations. I never ever observed NaNs
resulting from a frequency-domain computation in MEEP. Are you sure
e.g. MEEP terminated correctly?)

I can see two solutions:
1) use epsilon=1 and some high conductivity; this defines a lossy
conductor. You will correctly simulate electromagnetic resonances up
to infrared frequencies, but no plasmon-related effects.
2) Switch to a FDTD simulation with a long enough gaussian source,
which takes more time thand FDFD, but enables realistic metal model.

BTW if I am correct, there is a little misconception in your last
paragraph: The PEC is characterized by epsilon just going to "complex
infinity", not "minus infinity". If epsilon was huge real positive, it
leads to huge permittivity --> PEC, if it was huge real negative, it
is a lossless metal with tiny electron mass --> PEC, if it had huge
positive imaginary part, it is a inductance-free conductor with tiny
resistivity, again --> PEC. Complex infinity has no sign.

Hope this helps,
Filip Dominec
IOP ASCR, Prague

2014-06-19 14:07 GMT+02:00, Weiner John :
> Dear meep users and experts:
>
> I am really stuck, and I need your help.
>
> I am trying to implement a real metal material such a silver (Ag) or gold
> (Au): these are materials with a negative real relative permittivity and a
> positive imaginary permittivity.  According to "Materials in Meep" it should
> be possible to characterize the leading (frequency independent) term of the
> complex permittivity by specifying the real epsilon (for metals this is a
> negative number) and the D-conductivity.  The D-conductivity is expressed in
> terms of the imaginary part of epsilon (see the first equation on the
> "Materials in Meep" page).  If one knows the real part and the imaginary
> part of the permittivity at a given wavelength of interest, then one knows
> the D-conductivity at that wavelength, and one should be able to use meep to
> simulate the electromagnetic fields in and around an object characterized by
> that material.  So far so good...it works as advertised for positive real
> permittivities, but generates NaN fields if negative real permittivities are
> invoked.
>
> A frequency-dependent Drude or Lorentz expression always has as the leading
> term the same frequency-independent expression as described above.  So if
> the D-conductivity approach at fixed wavelength (or frequency) does not
> work, then there is no reason to expect the Drude-Lorentz expressions to
> work either.
>
> The use of the "metal" material, which is a perfect electrical conductor
> (PEC), does produce meaningful fields in meep.  The PEC is characterized by
> epsilon ->  negative infinity without loss (imaginary permittivity = 0).
> Since "metal" works, one would think that a large negative real epsilon and
> reasonably small loss term would work as well and would show slight field
> penetration into these materials (skin depth), etc.
>
> If someone has a little piece of meep code that they could show me as an
> example of a real metal, I would be most grateful.  I just don't see any way
> forward from here.
>
> Best regards,
>
> John WEINER
> 22 Ave. de la Sibelle
> 75014 Paris
> ___
> 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] (no subject)

[Filip Dominec]

Dear Shampy,
this topic has been discussed many times. Generally you can not force
a complex value of permittivity in FDTD. You can however define a
high-frequency oscillator that introduces losses.

More on this topic is at
http://ab-initio.mit.edu/wiki/index.php/Dielectric_materials_in_Meep
or search the mailing list.

I tried to make a list of some realistic material models at
http://fzu.cz/~dominecf/misc/eps/; the data used can be fed to MEEP.

Finally I would like to ask you to stick to the "netiquette" and write
your name as "Shampy Mansha", not "#SHAMPY MANSHA#". The capitals look
like shouting, and the hashmarks look like something as banging your
fist on the table before and after saying it...

Regards,
Filip Dominec


2014-06-12 18:01 GMT+02:00, #SHAMPY MANSHA# :
> Dear Steven and other Meep users,
>
> I am doing a simulation in which I require to use a complex dielectric
> constant of the form(say for example):
>
> epsilon = 1 + 0.01i
>
> For my simulation the frequency isn't fixed, instead I have to use a
> gaussian source with some finite width.
> And in the whole simulation I wish to use the same epsilon(epsilon =
> 1+0.01i).
>
> Is there a way to do this kind of simulation?
>
> Thanks,
> Shampy Mansha
> NTU,Singapore
>

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

Re: [Meep-discuss] Beam splitters in meep?

[Filip Dominec]

Hi, as a simplest approach, I would suggest to reduce the 'sigma'
parameter of the metal, first. It should allow the transmission to be
adjusted even in the case of a low resolution.
Filip

2014-05-26 7:06 GMT+02:00, jayv :
> I need some beam splitters with varying T/R ratios, and I've had some
> success
> with the meep-metals file by trying different thicknesses of 'myAl', for
> instance.
>
> I don't really need the properties of a particular metal, and I don't want
> to
> use the high resolution needed for thin metal films,  so an abstract beam
> splitter (partially transparent mirror) would be fine.  Is there any way to
>
> obtain such an element in meep?  For instance, would it be possible to
> simply
> set the (Ez,Ey) field values on a line (the mirror) at each step through
> some
> step function?
>
> Thanks in advance.
>
>
> ___
> 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] Permittivity of Silicon

[Filip Dominec]

Dear Thomas and all,
I wrote most of my thoughts on the referred page; while sometimes the
discrete Lorentzian oscillators suffice to precisely describe the
dielectric function in the frequency range of interest, the optical
spectra of semiconductors are usually of the harder cases.

You can manually fit the eps' and eps'' spectrum by summing more
narrower oscillators. This takes human time, and each oscillator also
requires CPU time in each FDTD step, so it is always a tradeoff.

The good point is that if you are interested in photovoltaics, your
simulations may be perhaps restricted to the wavelengths of 1200--400
nm, where silicon seems to behave in a relatively cultivated way.

DominecF


2014-05-19 18:15 GMT+02:00, Thomas LOPEZ :
> Dear Meep users,
>
> I would like to implement in MEEP  this  model  of Silicon permittivity
> (see below, from Deinega, A. & John, S. *Effective optical response of
> silicon to sunlight in the finite-difference time-domain method*.
> /Optics letters/ *37,* 112--114 (2012)):
>
> This expression is from multiple Debye, Drude and Lorentz terms and is
> sufficient to describe the response of bulk silicon to 300nm to 1000nm...
> I found some information about modeling Silicon here
> http://fzu.cz/~dominecf/misc/eps/ and also in Meep tutorial.
> Unfortunately, the imaginary part of epsilon is often far from tabulated
> data.
>
> So do you have any idea how to implement this expression? Are there any
> "tricks" using polarization class?
>
> Many thanks in advance for your assistance.
>
>
> --
> Thomas Lopez
> Doctorant/PhD Student
> Département Electronique Optronique et Signal (DEOS)
> Institut Supérieur de l'Aeronautique et de l'Espace (ISAE)
> 10 Avenue Edouard Belin BP 54032
> 31055 Toulouse CEDEX 4 FRANCE
> www.isae.fr
>
>

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

Re: [Meep-discuss] Read refractive index data from file

[Filip Dominec]

If I correctly understand your question, you wish to define material
properties as an arbitrary function of frequency.
This is generally not possible in FDTD, see e.g.
http://ab-initio.mit.edu/wiki/index.php/Dielectric_materials_in_Meep
Filip

2014-05-13 19:07 GMT+02:00, Charalampos Mavidis :
> Hello everyone!
>
> Is there a way to read refractive index-vs-wavelength data from file and
> use it in meep?
>
> Charalampos
>

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

Re: [Meep-discuss] PML overlapping dispersive material

[Filip Dominec]

Hi, Sophia, from my personal experience, the dispersive material can
overlap with PML in the simulations.
The question of stability under such conditions may be quite hard,
though. You probably have to find out by trying which parameters are
stable - and which not.
Regards,
Filip

2014-05-07 12:07 GMT+02:00, Sophia Antonia Fox :
> Hello,
>
> I am very new to Meep. I plan to 3D model a simple dielectric with a
> silver mirror underneath which will be modelled using Drude-Lorentz. A
> dipole source will be placed at center of dielectric as below;
>
>  PML
>   ---
>  |   Air|
>  |--|
>  |Dielectric|
>   PML|--|PML
>  | Silver   |
>  |--|
>  |   Air|
>  
> PML
>
> In the x-y plane. The dipole with be along x i.e. Ex
>
> Now this is probably a stupid question but can PML overlap the silver
> at all? Its just I have been doing some reading and for some people if
> the PML overlaps a dispersive material, the fields blow up inside the
> PML. I'll try this anyway but any information or guidance would be
> great.
>
> Thanks!
> Sophia
>
>
>
>
> ___
> 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] Drude material in MEEP

[Filip Dominec]

Dear Allen,
surely the best guide for defining the Lorentzian model for materials
in MEEP is
http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial/Material_dispersion
where also a working example is presented.

I must apologize for the statement that you have to use a
low-frequency Lorentzian oscillator; in fact, there is
'drude-susceptibility' in the current scheme interface of Meep. This
function seems to be provided by libctl, which explains why I could
not find it in the C++ sources nor it is present in the Python
interface I use. Sorry that I cannot help with this, as I have no
experience with the 'drude-susceptibility' function.

Filip

2014-04-28 20:06 GMT+02:00, Allen Spencer :
> Dear Filip,
> Thank you very much for your reply!  Suppose I want to use Drude model of
> material:epsilon(omega)=eps_inf-sigma/(omega*(omega+i*gamma))with
> eps_inf=12,sigma=0.3, gamma=1.6So how should I define this material in meep?
>  In MEEP reference I found lorentzian-susceptibility and
> drude-susceptibility but I haven't get how should I define this material
> using these functions. I am looking forward to your reply!
> Regards,Allen
>
>> Date: Mon, 28 Apr 2014 19:12:11 +0200
>> Subject: Re: [Meep-discuss] Drude material in MEEP
>> From: filip.domi...@gmail.com
>> To: falcon_dai...@hotmail.com
>> CC: meep-discuss@ab-initio.mit.edu
>>
>> Dear Allen,
>> If I correctly understand your question, the Drude model can be
>> approximated by the polarisation coming from a Lorentz oscillator with
>> as extremely low resonance frequency. General approach is to select a
>> realistic plasma frequency (for instance, omega_p := 2*pi*3.64e15
>> rad/s for aluminium), then to select some low enough oscillator
>> frequency omega_0 (e.g. 1 rad/s) and finally to adjust the oscillator
>> strength to be omega_p**2/omega_0**2 so that the actual plasma
>> frequency is (almost) independent of the arbitrary value of omega_0.
>> You may set the gamma value to some realistic one, e.g. gamma := 10e12
>> rad/s to introduce losses.
>>
>> At the moment, I am writing a text about how to correctly define
>> conductor models for FDTD that are both realistic and numerically
>> stable, as there are nontrivial points. I am going to share it when it
>> is done. Some preliminary chaotic notes are at
>> http://fzu.cz/~dominecf/misc/meep/index.html#drude.
>>
>> Regards,
>> Filip
>>
>> 2014-04-28 18:12 GMT+02:00, Allen Spencer :
>> > Dear MEEP users,
>> > Dose any one know how to define a Drude material
>> > (epsilon=eps_inf-sigma/omega*(omega+i*gamma)) but without Lorentz
>> > oscillating term using polarizations in MEEP. Thanks in advance for
>> > your
>> > help!
>> > Regards,Allen
>

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

Re: [Meep-discuss] Drude material in MEEP

[Filip Dominec]

Dear Allen,
If I correctly understand your question, the Drude model can be
approximated by the polarisation coming from a Lorentz oscillator with
as extremely low resonance frequency. General approach is to select a
realistic plasma frequency (for instance, omega_p := 2*pi*3.64e15
rad/s for aluminium), then to select some low enough oscillator
frequency omega_0 (e.g. 1 rad/s) and finally to adjust the oscillator
strength to be omega_p**2/omega_0**2 so that the actual plasma
frequency is (almost) independent of the arbitrary value of omega_0.
You may set the gamma value to some realistic one, e.g. gamma := 10e12
rad/s to introduce losses.

At the moment, I am writing a text about how to correctly define
conductor models for FDTD that are both realistic and numerically
stable, as there are nontrivial points. I am going to share it when it
is done. Some preliminary chaotic notes are at
http://fzu.cz/~dominecf/misc/meep/index.html#drude.

Regards,
Filip

2014-04-28 18:12 GMT+02:00, Allen Spencer :
> Dear MEEP users,
> Dose any one know how to define a Drude material
> (epsilon=eps_inf-sigma/omega*(omega+i*gamma)) but without Lorentz
> oscillating term using polarizations in MEEP. Thanks in advance for your
> help!
> Regards,Allen

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

Re: [Meep-discuss] Meaning of Complex fields in hd5 files

[Filip Dominec]

Hi, jayv,
the real and imaginary fields should be the same except for that the
imaginary part if shifted by 1/4 of its period. Thus computing the
modulus of the complex fields you get a smooth, non-oscillating
function, describing the magnitude of the field amplitude.

I think you can disregard the imaginary part if you do not have a
particular reason to take it into account...
F.

2014-04-28 5:26 GMT+02:00, jayv :
> Hi,
>
> I recently started using MEEP, and have run some 2d simulations to generate
>
> h5 Ez files.  For periodic boundary in the Y direction, the results are
> complex -- the h5 files contain both an ez_i and ez_r component.
>
> What are the meanings of these numbers?  When I generated a new h5 file from
>
> sqrt(ez_i^2 + ez_r^2) it did not look like a wave source.  I know that
> propagating Ez sources can be described with an exp(i*w*t) term, but that
> component acts on a _real_ Ez(x,y,z) field.
>
> Can someone please explain what the (r,i) values at particular (x,y,z)
> points
> are supposed to mean when (set! force-complex-fields? true) is used?
>
> Thanks,
>
> jayv
>
>
> ___
> 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] Zero Amplitude source

[Filip Dominec]

Hi,
you can probably set the source cutoff to 0
(http://ab-initio.mit.edu/wiki/index.php/Meep_Reference#source).
(But I must admit that I do not understand the purpose to do this.)
F.


2014-04-23 22:13 GMT+02:00, James Green :
> Dear MEEP users,
>
> Does anyone have any idea about how to make a gaussian source with zero
> amplitude. Or in the other word just make source without any EM field to
> ensure that meep will run.
>
>
> Regards,
> James
>

___
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 the energy spectrum radiated by a point source doesn't match with the spectrum of source itself?

[Filip Dominec]

This appears exactly as the result of the said effect.
The good point is that the gaussian source shape is reasonably
preserved upon differentiation, so you may pre-compensate it by
"fcen=0.40".
Or, if you have tighter requirements on the source, you may use the
newly implemented feature of band-source (), which guarantees flat
spectrum and suppressed spectral leakage. Its advantages are a
tradeoff with a much longer source duration. You would also have to
compile the fresh version of MEEP from github.
Filip


2014-04-22 16:17 GMT+02:00, Ehsan Saei :
> I've just used fcen=0.45 for source but the power has a frequency center at
> 0.5.  Is there any solution for this behavior?
>
>> Date: Tue, 22 Apr 2014 16:08:12 +0200
>> Subject: Re: [Meep-discuss] why the energy spectrum radiated by a point
>> source doesn't match with the spectrum of source itself?
>> From: filip.domi...@gmail.com
>> To: e.s...@hotmail.com; meep-discuss@ab-initio.mit.edu
>>
>> May it be attributed to that the radiated field is a derivative of the
>> current, so that high-frequency components are enhanced compared to
>> the lower frequency ones? Or is it a more complicated deviation?
>> Regards,
>> Filip
>>
>> 2014-04-22 16:01 GMT+02:00, Ehsan Saei :
>> > Dear Steven and MEEP users,
>> >
>> > I simulated a point source which is located in free-space (air ) and
>> > tried
>> > to compute the power radiated by the source and travels through a cubic
>> > that
>> > surrounds the source. After plotting the data I have noticed that the
>> > power
>> > has a frequency center different from that I have used for the source.
>> > Any idea about this behavior?
>> >
>> > Thanks in advance,
>> > Ehsan
>> >
>

___
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 the energy spectrum radiated by a point source doesn't match with the spectrum of source itself?

[Filip Dominec]

May it be attributed to that the radiated field is a derivative of the
current, so that high-frequency components are enhanced compared to
the lower frequency ones? Or is it a more complicated deviation?
Regards,
Filip

2014-04-22 16:01 GMT+02:00, Ehsan Saei :
> Dear Steven and MEEP users,
>
> I simulated a point source which is located in free-space (air ) and tried
> to compute the power radiated by the source and travels through a cubic that
> surrounds the source. After plotting the data I have noticed that the power
> has a frequency center different from that I have used for the source.
> Any idea about this behavior?
>
> Thanks in advance,
> Ehsan
>

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

Re: [Meep-discuss] Doubt about concept of flux spectrum in MEEP

[Filip Dominec]

As far as I know, there remains the problem of the mode shape
generally being different for different frequencies. In some specific
cases, such as hollow metallic waveguide, the mode cross-section
remains the same, so it is easy to excite/detect the first mode
selectively at broad frequency range.

Implementing this for e.g. optical fiber would require much more
complicated spatio-temporal evolution of the port. However the
difference between the mode shapes is smooth, so such a case could be
composed by stacking about ten ports, each operating at different
frequency range.
F.


2014-04-15 2:08 GMT+02:00, Steven G. Johnson :
> A more general solution would be to use code similar to the eigenmode-source
> feature: call MPB to compute the modes for a given cross-section (and for
> each desired frequency), and use those to perform the relevant overlap
> integrals with the Fourier-transformed fields in the same cross-section.
> This is certainly do-able to implement (at least for dispersionless
> materials).
>
> On Apr 14, 2014, at 5:21 PM, Filip Dominec wrote:
>
>> This is true - I mostly simulate the behaviour of an infinite periodic
>> array of scatterers, so I am interested in perpendicular (or oblique)
>> plane waves only.
>>
>> The simple flat recording plane can probably be generalized to all
>> waveguides that can be approximated by LP modes. Other geometries
>> perhaps need to introduce the concept of a "port" such as that is in
>> CST Studio etc.
>>
>> 2014-04-14 22:57 GMT+02:00, Steven G. Johnson :
>>> Only if you are looking at planewaves or similar solutions where you
>>> know
>>> the forward/backward eigenmodes.
>
>
> ___
> 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] Doubt about concept of flux spectrum in MEEP

[Filip Dominec]

Another option would be to define an amplitude-recording-plane: for
instance, knowing the Ex-field and Hy-field, one can easily separate
the amplitudes of both forward- and backward-propagating waves along
the z-axis. The usual scattering problems with properly absorbing
boundaries then require only single simulation, because the
inward-propagating wave is the same as if there was no scatterer
(verified numerically!).

Currently, I use such a feature in my metamaterial-simulation scripts
https://github.com/FilipDominec/meep_metamaterials, but it often
accounts for over 10 % of CPU load as it is implemented in high-level
language that calls the get_field() procedure for multiple points each
step.

I believe it has to be fairly easy to implement in C, but last time I
got lost in the MEEP code. I will appreciate an outline how to start
and what to do - then I am going to try it again and make a patch.

Filip

> This is why we tend to recommend using a separate simulation (with no
> scatterer) for normalization purposes, to get the incident flux, as in the
> Meep tutorial.

___
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 doesn't print anything in terminal

[Filip Dominec]

Dear Ehsan,
on Linux, you can use the 'tee' command:

mpirun -np 8 meep-mpi test.ctl| tee   test.out

Did it help?
Filip

2014-04-10 8:39 GMT+02:00, Ehsan Saei :
> Dear all,
>
> I try to run a ctl file using meep-mpi  on a ubuntu machine with the
> following command line:
>
> mpirun -np 8 meep-mpi test.ctl > test.out
>
> but It doesn't print anything in terminal. What other option is required for
> printing the progress in terminal?
>
> thanks in advance,
> Ehsan
>

___
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 frequency snapshots and near to far field transform

[Filip Dominec]

Dear Arthur,
thank you for sharing your code! I cloned your source, downloaded the
meep 1.2.1 sources and copied your files over the original directory.
Then I used my old compilation procedure on Ubuntu [1] to compile meep
and rebuilt the python-meep interface.

The new functions  of snapshot() and nf2ff() appear in the meep-mpi
module. This looks promising. I will try out your functions using my
Python scripts.

There is a lot of functions that would make MEEP easier to use in some
cases (so far I had to write them on my own). I have some code to
contribute, would you be interested to extend the functions in your
repository? (Of course the best practice would be to incorporate it in
the trunk source!)
Regards,
Filip

[1]: http://fzu.cz/~dominecf/misc/meep/#install


2014-03-27 17:10 GMT+01:00, Arthur Thijssen :
> Dear Meep users,
>
> During the course of the my PhD I have added some functionality to Meep.
> This includes:
> - output of fields / field components in the frequency domain.
> Meep includes discrete Fourier transforms used mostly for flux plane
> calculations. I've written a wrapper class that uses this build in DFT to
> output fields to hdf5 files in the frequency domain.
>
> - Near to far field transform. Using the algorithm described in
> "Computational Electrodynamics: The Finite-Difference Time-Domain Method"
> by Taflove, the addition to Meep can perform near to far field transforms
> and output them to hdf5 files. The output is given in a spherical
> coordinate system, see the Matlab post processing script for more
> information.
>
> - Mode volumes in the frequency domain. Meep is able to calculate mode
> volumes, however it can only do this for one mode at a time. The addition
> to Meep is able to perform mode volume calculations for several modes at
> once in the frequency domain if the modes are excited.
>
> I have included a scheme interface with this functionality. See the control
> file example for details.
>
> The code is fully MPI compatible.
>
> In order to use my additions for Meep, you can download the modified source
> files from here:
> https://github.com/Arthur-Thijssen/MEEP-actt
> Simply replace those files with the original Meep code and compile
> normally.
>
> A few notes:
>
> - The near to far field transform has not been implemented using a FFT
> algorithm. This might be added in the future.
> - I prefer to use single precision floating point numbers when using Meep.
> This is the default setting for the code given here.
> - I have not gotten to optimizing hdf5 output yet and is thus not as fast
> as it could be.
>
> Let me know what you think and if you have any questions.
>
> Thanks,
>
> Arthur Thijssen
>

___
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 harminv problem

[Filip Dominec]

Hi, it appears to me that harminv may not use the MPI synchronisation
at its end. If this is the case, it could result in  a race condition,
when one instance of harminv ends the multithreaded program, while the
second one is still running.

I suggest to add some field-manipulating function at the very end of
your program, so that all threads have to wait for each other and
finish simultaneously. My python-meep scripts have meep.all_wait() at
their last line, and probably a similar function exists in scheme.

Does it help?

Regards,
Filip

2014-03-12 20:32 GMT+01:00, Oosten, D. van (Dries) :
> Sorry guys, but just to clarify, mpirun often says things like
>
> --
> mpirun has exited due to process rank 5 with PID 8389 on
> node workstation exiting without calling "finalize". This may
> have caused other processes in the application to be
> terminated by signals sent by mpirun (as reported here).
> --
>
> does that clarify things for anyone?
>
>
> 
> From: Oosten, D. van (Dries)
> Sent: Wednesday, March 12, 2014 8:20 PM
> To: meep-discuss@ab-initio.mit.edu
> Subject: meep mpi harminv problem
>
> Hi guys,
>
> I have been struggling with the following issue. When I use harminv to find
> eigenmodes in meep, it is often unreliable when I use it through mpirun.
> This is especially the case when the workstation we run meep on is under
> heavy load. It seems to me that the process get killed by mpirun before they
> can give their results. Could this be the case and if so, what tests can I
> run to track this problem down?
>
> Thanks in advance!
>
> best,
> Dries
>
> ___
> 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] silica dispersion model

[Filip Dominec]

Dear Pablo,
I plot the Lorentz model for silica at http://fzu.cz/~dominecf/misc/eps/#SiO2
The page also contains the numerical data for the Lorentzian
oscillators, along with additional information about the sources and
application of the data.

Hope this helps,
Fillip

2014-02-26 13:14 GMT+01:00, Pablo Díaz Núñez :
> Dear meep users.
>
> I need to use the dispersion model for fused silica in my simulations.
> Since these physics are quite new to me, I'm not sure how I should
> calculate the parameters for the lorentzian model. Could someone point
> me in the right direction or tell me about any literature I could check?
>
> Thanks in advance.
> Pablo.
>
> ___
> 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] wave guide coupling

[Filip Dominec]

Dear Isaac,
I seem not to fully understand what you are planning to do. But if I
can guess what the question was, the answer is that I personally did
not encounter any example of a waveguide coupler.

If the wave shall be coupled between two planar PhC slab waveguides,
then it seems as a rather simple task.
If there is coupling of freely propagating wave to any waveguide, the
task becomes a bit more complicated and a sketch of your geometry
would be needed.

Best regards,
Filip Dominec

2014-02-13 16:44 GMT+01:00, ISAAC MATERE :
> Hi meep users
> am trying to come up with a script for a wave coupler, but the close i can
> get for it is a wave guide at 90 degrees, kindly assist with any relevant
> information
>
> isaac
>

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

Re: [Meep-discuss] Gaussian pulses in Meep

[Filip Dominec]

Dear Simon,
I think your conjectures are all correct. The pseudo-gaussian spectral
profile (I guess the spectrum is more precisely ~ f*exp[-(f-fcen)**2 /
fwidth**2] or something like that) requires a gaussian time evolution
of the source. The cutoff defines sharp edges in time when the source
starts and ends so a simple rectangular time window is thus used.
Thanks to the fast convergence of the gaussian function, the default
10/fwidth timespan is usually sufficient to suppress the spectral
leakage into high frequencies.

At http://fzu.cz/~dominecf/misc/meep/#bandsource I present a patch to
meep (sources.cpp) that uses a band-source with lower spectral leakage
and well-defined spectrum of frequencies. It however requires the
source to be turned on for a longer time.

Hope this helps.
Filip

2014-02-06 21:41 GMT+01:00, Simon Bernard :
> Hi, I have a question about the way Meep treats Gaussian pulses.
>
> Suppose you specify the parameter fwidth to be df. Then, the bounds of the
> pulse in frequency space will be -df/2 and +df/2. In the time domain, the
> width of the pulse is characterized by 1/fwidth. And this width is not the
> actual FWHM of the pulse in time, but is proportional to it.
>
> The thing that confuses me is the parameter cutoff. As described in Meep
> Reference, cutoff determines the time t0 at which peak of the pulse occurs:
> t0 = tstart + cutoff * width.
> Therefore, increasing cutoff increases the duration of the pulse in time.
> Shouldn't this affect fwidth? Why is fwidth independent of cutoff?
>
> My attempt at answering this:
>
> Cutoff only controls how sharply the pulse in time is turned on/off at its
> tails, and does not affect its width.
> The smaller the cutoff, the sharper the pulse's edges are in time. And I am
> guessing that describing these sharp edges in frequency space requires
> higher frequency Fourier components.
> Meep Reference states that increasing cutoff decreases the amount of high
> frequencies introduced by the start/stop of the source. "Introduced" is
> still unclear to me as to how it concretely affects a simulation. Maybe
> these high frequency components are responsible for the wiggles you would
> usually see in a power spectrum near the edges of the bandwidth (the df)?
>
> Thank you,
> -Simon
>

___
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)

[Filip Dominec]

Dear Farhad,
from what I recall from tinkering the sources, you will probably want
to edit the polarizability.cpp. First of all, there already _is_ a
model that includes some random fluctuations; it might suit your
needs. If not, modifying the code that implements constitutive
relations is the best access point to add new physics, anyway.

Beware the MEEP code is optimized for speed, i. e. it is a bit hard to
read and many lines are found when one searches for 'yucky'...

I believe all other physics can be incorporated into the
aforementioned custom routine for polarisation update. Maybe the MEEP
authors can give more detailed info...
Filip


2014/1/6, FARHAD KAZEMI :
> Dear Fillip,
>
> thank you so much for your answer. Actually, briefly , fluctuational
> electrodynamics indicates that, the electromagnetic wave generated by a
> surface with finite T>0 of temperature is because of the fluctuation of
> charges or dipoles inside the material. It studied this phenomenon
> statistically. this kind of fluctuations caus two types of thermal radiation
> namely far-field and near-field radiation. far-field radiation is well-known
> case which can be predicted easily by some simple radiative heat transfer
> equations. However, for the case of near-field we need to apply such concept
> ( fluctuational electrodynamics) in our calculations in order to reveal the
> near-field radiative heat transfer enhancement occurred between two plates
> separated by a nano-distance gap. This phenomenon can be explained due to
> the existence of surface polaritons on the interface between surfaces of the
> plates. There is a paper describing the application of FDTD for such problem
> and
>  I am trying to recalculate the same thing using MEEP and of course
> manipulate some parameters later.
> Specifically, can we manipulate the existence code of the MEEP to solve some
> other equations (in this case  fluctuational electrodynamics) parallely with
> Maxwell ewuations?
> Additionally, do you have any idea about how can I include the effects of
> temperature on the emission of the EM wave from a surface with a finite
> temperature?
>
> Thank you again. sorry if my message is long.
>
> Farhad
>
>
>
> On Monday, January 6, 2014 5:50 PM, Filip Dominec 
> wrote:
>
> Dear Farhad,
> I am not an expert nor I have thoroughly read the referred
>  article,
> but I believe the non-radiative fields should be exactly modelled by
> MEEP as long as they are a solution of the (source-free) Maxwell
> equations. You may, for example, define a metallic
>  capacitor and a
> metallic inductor, connect them and you should obtain the realistic
> oscillation frequency of this LC circuit.
>
> You might, however, find out it would be necessary to newly implement
> thermal emission and absorption. Maybe even some quantum phenomena
> would involve - but, for instance, the Casimir forces have been
> implemented in MEEP successfully so even this can be done.
>
> The article touches a quite interesting topic, by the way.
>
> Best wishes,
> Filip Dominec
>
>
> 2014/1/6, FARHAD KAZEMI :
>>
>  Dear all,
>>
>> I would
>  like to model the radiation transfer between two plates
>> separated by nano-gap in which we have to bring near-field radiation
>> effects into account using fluctuational electrodynamics.
>> Does MEEP is capable of solve such problems? or we need to
>> manipulate the source C++ codes to introduce near-field equations?
>> In fact, I am trying to reproduce the results of the following paper.
>>
>> Mathieu Francoeur, M. Pinar Menguc, Role of fluctuational electrodynamics
>> in
>> near-field radiative heat transfer, Journal of Quantitative Spectroscopy &
>> Radiative Transfer 109 (2008) 280–293
>>
>> Thanks®ards Farha

___
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)

[Filip Dominec]

Dear Farhad,
I am not an expert nor I have thoroughly read the referred article,
but I believe the non-radiative fields should be exactly modelled by
MEEP as long as they are a solution of the (source-free) Maxwell
equations. You may, for example, define a metallic capacitor and a
metallic inductor, connect them and you should obtain the realistic
oscillation frequency of this LC circuit.

You might, however, find out it would be necessary to newly implement
thermal emission and absorption. Maybe even some quantum phenomena
would involve - but, for instance, the Casimir forces have been
implemented in MEEP successfully so even this can be done.

The article touches a quite interesting topic, by the way.

Best wishes,
Filip Dominec

2014/1/6, FARHAD KAZEMI :
> Dear all,
>
> I would like to model the radiation transfer between two plates
> separated by nano-gap in which we have to bring near-field radiation
> effects into account using fluctuational electrodynamics.
> Does MEEP is capable of solve such problems? or we need to
> manipulate the source C++ codes to introduce near-field equations?
> In fact, I am trying to reproduce the results of the following paper.
>
> Mathieu Francoeur, M. Pinar Menguc, Role of fluctuational electrodynamics in
> near-field radiative heat transfer, Journal of Quantitative Spectroscopy &
> Radiative Transfer 109 (2008) 280–293
>
> Thanks®ards Farha

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

Re: [Meep-discuss] Designing inclined geometry

[Filip Dominec]

Dear Prem,
as far as I know, this task would require either
1) to build the desired structure by overlapping a big (potentially
infinite) number of overlapping blocks,
or
2) load the structure pixel-by-pixel either from a data file, or from
a mathematical expression.
I spent several days implementing the 2nd way in Python and now I can
define virtually any inclined/bent/distorted object. Some info is at
http://fzu.cz/~dominecf/misc/meep/ and I can send the fresh sources to
you. But it uses python-meep.
F.

2013/12/3, prem prakash singh :
> Dear Meep users,
> I want to design two inclined fiber for coupling. In Cartesian system, I
> didn't get any angle parameter for design.  So whenever I am selecting
> block or cylinder, it comes parallel to X-Y axis not inclined. Could any
> one please  educate me to design such inclined geometry.
> Required structures is appended below.
>
> [image: Inline image 1]
>
> With Best Regards .
>
> Prem Prakash Singh
> IISc
>

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

Re: [Meep-discuss] Near-field radiation between two parallel plates in MEEP

[Filip Dominec]

Dear Farhad,
I must admit that maybe I do not fully understand your question, but anything 
is predicted by Maxwell equations should be possible in MEEP. In many cases my 
computations required MEEP to take into account the non-radiative electric or 
magnetic fields (such as when building a split-ring resonator in metamaterial, 
sharp tips, surface plasmons, surface optical phonons etc.) and the results 
were compatible with experimental or previously published values.
So you may build as narrow cavities/gaps as the FDTD grid allows you and 
everything should be realistic. With proper subgridding, you may even define 
slits much narrower than is the grid unit.
F. D.


> On Wed, 27 Nov 2013 01:57:33 -0800 (PST)
> FARHAD KAZEMI  wrote:
> 
> > Dear all,
> > 
> > I would like to model the radiation transfer between two plates 
> > separated by nano-gap in which we have to bring near-field radiation 
> > effects into account. 
> > Does MEEP inherently support the near-field effects? or we need to 
> > manipulate the source C++ codes to introduce near-field equations?
> > 
> > Thanks®ards
> > 
> > Farhad

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

Re: [Meep-discuss] refractive index of silicon

[Filip Dominec]

Dear Rui,
I tried to fit the dielectric function of silicon by the Lorentz oscillator 
model  at: http://fzu.cz/~dominecf/misc/eps/

The exact constants of the Lorentz oscillators can be found in 
http://fzu.cz/~dominecf/misc/meep/scripts/meep_materials.py
which is a file I directly import in my Python-MEEP scripts. You may have to 
modify it to match your length and time scale. For simplicity, I always use the 
SI units in my scripts. Try to reduce the number of Lorentz-Drude oscillators 
as possible within your needed accuracy in the required spectral domain - each 
additional oscillator consumes CPU time!

Some remarks on the materials in MEEP and FDTD stability is also here:
http://fzu.cz/~dominecf/misc/meep/#mat_mod

Regards, 
Filip Dominec

On Fri, 20 Sep 2013 15:55:50 -0700
Rui La  wrote:

> Dear meep users,
> 
> I want to study the short wavelength light(300-700nm) propagation in Si but
> found that the real and imaginary part of refractive index of silicon from
> has a huge difference at short wavelength. For example, the real part of
> refractive index will have maximum of 6.8 at 370nm corresponding to 46.24
> as dielectric constant. But the refractive index will drop to around 3.5
> after 900nm corresponding to 12. The extinction coefficient is also
> changing dramatically under 400nm. So how could I define the materials at
> short wavelength. Thank you.
> 
> Best,
> 
> Rui

___
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 set frequency and fwidth

[Filip Dominec]

Hi, Rui,
I also always need to compute it from the basics.

25 nm corresponds to 0.25 units, therefore one unit corresponds to 1e-7 m,

400 nm is roughly 700 THz in reality, therefore you would rescale the
frequency to 700e12 * 1e-7 = 7e7,
but MEEP defines speed of light as 1 instead of 3e8 m/s, so you need
fcen = 7e7/3e8 = 2.5e-1.

Fwidth should obviously be something similar to fcen in your case.

Hope this is correct,
Filip

2013/9/20, Rui La :
> Dear meep users,
>
> I want to get the result from 200nm to 700nm. My structure is a 2D cylinder
> with radius equal to 0.25 in meep and 25nm in reality. How do I set my
> frequency and fwidth? Thank you.
>
> Best,
>
> Rui
>

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

Re: [Meep-discuss] Fw: question about meep

[Filip Dominec]

Dear Lin,
for better illustration of what actually happens, could you generate
the images again with the source shifted downwards, e. g. to 1/4 of
the picture height?
Thanks,
Filip

2013/7/9, nw...@mail.sim.ac.cn :
>
>
>
>
>
>
>
> Dear meep users
>
> I'm a student of CAS(Chinese Academy of Sciences).Recently, I try to do
> some calculations with meep, but I have a problem on Periodic boundary.The
> system i calculated is two dimensional,and the boundary conditions i want to
> set are periodic conditions in y direction,open condition in X direction.
> Unfortunately, the field shows that the PML in x direction doesn't work. The
> Hz field in different times(5 15 100)  are shown below and the accessory is
> the ctl file. I'm very confused and I will be appreciated that you can help
> me.I also find that another meep user talked about the same proble several
> yeas ago,but i haven't any reply for his (her)question
> http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/1472/match=period
>
> Best
>
> Lin Wang
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

Re: [Meep-discuss] add-field, save-field, load-field, etc.

[Filip Dominec]

Hi, John,
other people have asked a similar question and I am afraid it is not
implemented yet.

It is one of the features I proposed to implement in the mail few weeks ago:
http://permalink.gmane.org/gmane.comp.science.electromagnetism.meep.general/4959
However, I did not get any reply so far, therefore I am waiting before
I submerge into the rather nontrivial C++ code to decide the right way
how to implement the function. It seems the best way would be to clone
add_dft_flux_plane() etc.

If I understand it well, do you need just to save the amplitude
spectrum of one field component?

F.

2013/6/21, John Weiner :
> Dear Meep users:
>
> The Meep Reference describes the add-flux, save-flux, load-flux,
> load-minus-flux statements and the tutorial shows how to use these to
> calculate transmission and reflection from the fluxes through specified
> flux-region objects.
>
> My question is: Do analogous statements exist for the individual
> components of the E- and H-fields themselves?
>
> ___
> 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] New feature: band-pass source

[Filip Dominec]

Just for comparison,
these are some spectra recorded using the old Gaussian source:
http://fzu.cz/~dominecf/misc/meep/img/ampli_debug_gaussian.png
The structure couples to the low frequencies and induces ugly
artifacts by spectral leakage.

And here are those obtained using the band source with width 0.1.
http://fzu.cz/~dominecf/misc/meep/img/ampli_debug_band.png
Obviously in the region of interest, the signal is clean of any artifact.

Feel free to write me if interested.
Filip

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

[Meep-discuss] New feature: band-pass source

[Filip Dominec]

Dear MEEP users,
let me share a little code snippet with you. Sometimes it happens that
one wants to run a FDTD simulation with a broadband source, which
however avoids some frequencies. A single gaussian source is not
useful in such case, as its spectrum has always broad wings. Composing
the source from many narrow-band gaussians is not practical.

For such a case I prepared a band_src_time() class, which is used
similarly as the gaussian source except for that it transmits only in
a spectral window given by parameters f, fwidth.

Technically the source is a sinc(t) function multiplied by
Blackman-Nutall window. Such a waveform has proven to provide a nice
rectangle with highly suppressed side lobes and therefore spectral
leakage under -25 dB with default settings of a short source duration
(much better values available with longer source time).

To apply, put the following snippet in the sources.cpp in MEEP 1.2 sources:
--

/// Band source
band_src_time::band_src_time(double f, double fwidth, double s)
{
  freq = f;
  width = 1.0 / fwidth;
  peak_time = width * s;
  cutoff = width * s * 2;

  master_printf("Initializing band source for time_domain (f fwidth s)");
  // this is to make last_source_time as small as possible
  while (exp(-cutoff*cutoff / (2*width*width)) < 1e-100)
cutoff *= 0.9;
  cutoff = float(cutoff); // don't make cutoff sensitive to roundoff error
}


complex band_src_time::dipole(double time) const
{
  // e_i2pif = exp(-1j*2*pi*freq*tt)
  // wnd_Hann= cos(-(tt/(cutoff*2)*pi))**2
  // wnd_Hamming= (0.53836+0.46164*cos(tt/(cutoff*2)*pi*2))
  // wnd_Blackman= (0.42659 + 0.49656*cos(tt/(cutoff*2)*pi*2) +
0.076849*cos(tt/(cutoff*2)*pi*4))
  // wnd_Gauss   = exp(-((tt)/(cutoff*2)*3)**2)   // Gaussian
window, char. width = 1/3
  // wnd_ContRect =rect(tt, 0, (trunc((cutoff*2)/8/width))*8*width)
  double tt = time - peak_time;

  double sinc= sin(tt*2*pi / width/2)/(tt*2*pi * width);
  double wnd_BlackmanN= (0.3635819 + 0.4891775*cos(tt/(cutoff*2)*pi*2) +
  0.1365995*cos(tt/(cutoff*2)*pi*4)+ 
0.0106411*cos(tt/(cutoff*2)*pi*6));
  //if (float(fabs(tt)) > cutoff)
//return 0.0;

  // correction factor so that current amplitude (= d(dipole)/dt) is
  // ~ 1 near the peak of the band.
  complex amp = 1.0 / complex(0,-2*pi*freq);

  return sinc * wnd_BlackmanN * polar(1.0, -2*pi*freq*tt) * amp;
  //if (abs(tt)>1e-9)
  //return exp(-tt*tt / (2*width*width)) * sin(tt)/tt * polar(1.0,
-2*pi*freq*tt) * amp;
  //else
  //return 1;

}

bool band_src_time::is_equal(const src_time &t) const
{
 const band_src_time *tp = dynamic_cast(&t);
 if (tp)
  return(tp->freq == freq && tp->width == width &&
 tp->peak_time == peak_time && tp->cutoff == cutoff);
 else
  return 0;
}

--

And add the following into meep.hpp:

--
// band source with given minimum and maximum frequency and duration
class band_src_time : public src_time {
 public:
  band_src_time(double f, double fwidth, double s = 5.0);
  virtual ~band_src_time() {}

  virtual complex dipole(double time) const;
  virtual double last_time() const { return float(peak_time + cutoff); };
  virtual src_time *clone() const { return new band_src_time(*this); }
  virtual bool is_equal(const src_time &t) const;
  virtual complex frequency() const { return freq; }
  virtual void set_frequency(complex f) { freq = real(f); }

 private:
  double freq, width, peak_time, cutoff;
};
--

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

[Meep-discuss] FDTD packages convergence

[Filip Dominec]

Dear all,
this is an additional thought following my previous e-mail. Many
interesting functions have been already implemented in different free
FDTD codes. Just few examples of "special capabilities":
* MEEP implements interesting physics and frequency-domain solver,
* EMTL uses sub-pixel smoothing even for dispersive media and allows
to define materials with  precise modified Lorentzian model,
* OpenEMS may define variable density grid, is supplied with a
graphical interface and calculates the far field,
* B-CALM runs the time-stepping routine on the graphical card,
* etc.
Other features seem to be missing everywhere, such as gyrotropic
(Faraday) media or efficient subgridding.

Generally their aim is the same - to provide the scientists/engineers
around the world with a well usable and flexible FDTD simulation
package. However at this moment, a lot of effort is duplicated in each
of the packages, the novices often hesitate which one to start using
and, what is the worst, each of these programs provides just a part of
the advanced features and not the others.

Is there any plan of cooperation with other projects? What do you
think would be the most efficient way to start?
Filip

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

[Meep-discuss] Amplitude monitor plane for MEEP 1.3

[Filip Dominec]

Dear MEEP developers and users,
in our team, we employ MEEP to solve various problems and it is very
useful. However, now and then we encounter some important functions to
be missing. Most of them may be somehow written in Python code, but
they would be the most efficient if hard-coded in the C++ source.

One such function is the AmplitudeMonitorPlane(volume, component),
which averages the field over a defined volume() and records the
spatial average for each timestep. It is essential e. g. for
s-parameter calculation.

I am planning to write this important function in the MEEP source,
however I would like first to be assured that my effort will not be
duplicated and that it would be incorporated to the trunk also for the
benefit of other users. (There are many other features to be written,
too.)

I am looking forward for your opinion,
Filip

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

Re: [Meep-discuss] organic material in meep

[Filip Dominec]

Dear Gholamhosain,
the permittivity has to be established from experimental (or
quantum-mechanical) sources, see for instance
http://xplqa30.ieee.org/ielx5/5503869/6055237/6004802/html/img/6004802-fig-2-large.gif

This graph may be easily converted to numerical data using Engauge or
similar program.

Then I fit the curve manually by one (or few more) Lorentzian
oscillators for the spectral region of interest. I put some
interesting spectra on the page http://fzu.cz/~dominecf/misc/eps/,
where also the data for the materials may be downloaded. But it will
be surely easy to build a Lorentzian model for the photovoltaic
materials.

F.

2013/6/4, Gholamhosain Haidari :
> *Hi all*
> I am interested in meep for organic solar cell.
> My problem is that I do not know the Drude-Lorentz parameter for regular
> organic materilas (PEDOT:PSS and PCBM:P3HT, ITO)
> Is there any program or code for finding Drude-Lorentz parameters from
> experimental data (for example e1 and e2( e=e1 + ie2)).
> All the best
> *Thank you very much in advance*
> moh
>

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

Re: [Meep-discuss] Get (n, k) for a frequency from a dispersive material.

[Filip Dominec]

And I forgot to add that

n = real(sqrt(eps))
k = imag(sqrt(eps))

F. D.

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

Re: [Meep-discuss] Get (n, k) for a frequency from a dispersive material.

[Filip Dominec]

Hi, Oscar, this is rather straightforward. The dielectric function
used by MEEP is given by the well-known Lorentz formula. (I have
verified it numerically, but this is a bit longer to explain.)

In Python, I use the following function for the material. As an
example I will give the SiO2 definition for broad spectral range. I
hope it will be readable even for non-Python users:

class material_SiO2():#{{{
""" Amorphous SiO2
Optical resonances fitted manually to experimental spectra
Note: Discrete Lorentzian oscillators used predict higher losses
in the mid-IR region
Note2: crystalline SiO2 should be similar, but is slightly birefringent

From Gunde, M. K.: "Vibrational modes in amorphous silicon dioxide"
Physica B: Physics of Condensed Matter, Volume 292, Issue 3-4,
p. 286-295.
"""
def __init__(self, where=None, sigmafactor=1):
self.eps = 1
percm = 3e8/1e-2
self.pol = [
{'omega': 447*percm, 'gamma': 49*percm, 'sigma':.923},
{'omega': 811*percm, 'gamma': 69*percm, 'sigma':.082},
{'omega':1064*percm, 'gamma': 75*percm, 'sigma':.663},
{'omega':1165*percm, 'gamma': 80*percm, 'sigma':.058},
{'omega':1228*percm, 'gamma': 65*percm, 'sigma':.017},
{'omega': 2.6e15, 'gamma': .5e15, 'sigma': .5},
{'omega': 2.8e15, 'gamma': .2e15, 'sigma': .55},
]
self.name = "Amorphous silica glass (SiO2) for IR range"
self.shortname = "SiO2 (IR)"
self.where = where
#}}}

def analytic_eps(mat, freq):
complex_eps = mat.eps
for polariz in mat.pol:
complex_eps += polariz['sigma'] * polariz['omega']**2 /
(polariz['omega']**2 - freq**2 - 1j*freq*polariz['gamma'])
return complex_eps

See also http://fzu.cz/~dominecf/misc/eps/

Regards,
Filip

2013/5/24, Oscar Garcia :
> Dear  MEEP users,
>
>
>
> I´m wondering if it is possible to get the value (n,k) from a dispersive
> defined material for a particular frequency. For example, if you have the
> following material:
>
>
>
> (define-param silicon (make dielectric (epsilon 1.5) (E-susceptibilities
>
>
> (make lorentzian-susceptibility (frequency 3.64) (gamma 0) (sigma 8))
>
>
> (make lorentzian-susceptibility (frequency 2.76) (gamma (* 0.063 2)) (sigma
> 2.85))
>
>
> (make lorentzian-susceptibility (frequency 1.73) (gamma (* 2.5 2)) (sigma
> -0.107))
>
>
> )))
>
> Is it possible to do something like this:
>
>
>
> get_n_real(frequency=1, material=silicon)
>
> get_n_img (frequency=1, material=silicon)
>
>
>
> Someone knows an easy way to implement this function in MEEP?
>
>
>
> Thank you very much and best regards,
>
>
>
> Oscar García
>
> FideNa
>
> 8   www.fidena.es | ' +34 948166177 | 6 +34
> 948166211
>
> Tanto el presente mensaje como cualquier material adjunto a él han sido
> enviados por FideNa, y son propiedad de FideNa o han sido utilizados por
> FideNa con permiso de sus propietarios. Es por tanto material
> potencialmente
> confidencial que no se difundirá ni utilizará en manera alguna sin el
> consentimiento escrito previo de FideNa.
>
>
>
>
>
>

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

Re: [Meep-discuss] Porting MEEP to the Web

[Filip Dominec]

Hi, thanks for explanation. Do you think this approach would be
compatible with MEEP dumping some GBs of HDF5 files containing
volumetric data? Or even better, with MEEP being launched only as a
non-interactive computational node communicating over MPI with some
server in the local network?
Filip

2013/5/23, Fernando Carvalho :
> You got it!
> That was the point I was looking for someone to get.
> When you compile something to NaCl, in the end it will be a binary code
> with some "dangerous instruction" not being allowed, such as those need for
> Forking and executing code that was not verified by the validator. So in
> average, Google says that code near 95% it's original performance.
> A typical scenario for NaCl would be a Web page, with a prompt that passes
> messages to the Native Client module to be executed and the output is print
> to some HTML element on that page.
> So you could add a button that would "upload" a MEEP script to the module
> to be executed.
> Of course, this "upload" process is only a way to call a script that will
> be executed in the local browser, through the Native Client process.
> You can understand a Native Client module as an element in a Webpage that
> is listening to commands and it can callback your webpage when it deems
> it's necessary.
> So an way to port MEEP, would be to add an Handler function that will
> receive an Scheme command that was written in an input box on the webpage
> and then updating MEEP internal state within the module.
> When MEEP wants to send a message to the user, it will call a post method
> to report what is needed and a Javascript function will put this message,
> somewhere on the Webpage.
> So if you think that if a user open a webpage with a MEEP script embedded,
> it could start running immediately and then report the results to your
> server, without much user interaction.
>
> If you need more information, please, be free to ask me.
> I have already made a small project with Physical simulations using NaCl,
> but I'm no expert in this technology.
> We can discuss issues with Google developers which are very supportive, if
> you got interested in the project.
> I can't port MEEP to this technology by myself, but with some help, I think
> it will very straightforward.
>
>
>
>
> On Thu, May 23, 2013 at 12:17 PM, Filip Dominec
> wrote:
>
>> Hi, the suggested project is appealing to me because it seems it could
>> greatly simplify installation procedure of MEEP at Windows. I can
>> imagine convincing many colleagues at the institute to run FDTD
>> simulations when their computer is idle...
>> However, not knowing anything about NaCl, I am still concerned about
>> the performance; usually one wants to compile MEEP from sources to get
>> the optimized code for their particular architecture. On the other
>> hands, if whole MEEP is compiled before being run, quite a lot of
>> external dependencies will have to be packed.
>> So far, it is possible to run a simulation of sodium chloride in MEEP,
>> but not vice versa. How should a typical scenario of MEEP under NaCl
>> look like?
>> F.
>>
>> 2013/5/22, Fernando Carvalho :
>> > There will be no major performance impacts to the user, because it will
>> run
>> > a machine code, directly compiled from a C++ source by a GCC compiler
>> > variant for Native Client.
>> > To the user, the main benefit is that the same binary blob can be
>> executed
>> > in any operating system that Chrome or Chromium is fully ported
>> (currently
>> > with the exception of iOS and Android).
>> > For developers, it will be a way to create a huge distributed
>> > processing
>> > community for MEEP, that will unleash possibilities of discovering many
>> new
>> > structures, with a cheap processing cost.
>> > If want to know more, you can ask me directly or read a little in this
>> > brief explanation:
>> > https://developers.google.com/native-client/overview
>> >
>> >
>> >
>> > On Wed, May 22, 2013 at 3:43 AM, Filip Dominec
>> > wrote:
>> >
>> >> Hi, I did not know this project before. What would be the greatest
>> >> benefits for the user? Would it not impact the performance too much?
>> >> Filip
>> >>
>> >> 2013/5/21, Fernando Carvalho :
>> >> > Hi everyone,
>> >> >
>> >> > Recently, Google Developers, at Google IO 2013, had announced PNaCl
>> >> (Native
>> >> > Client <https://developers.google.com/native-client/>), an Open
>> So