Dear Steve, thanks for your long e-mail. Ad 2. Now I can see that your simulation will not be overwhelmingly big; if you set size to 320,000 microns and resolution to 0.01, the pixels would be 100 microns and you would get 3200x3200 pixels simulation, which may be acceptable if you have a powerful computer. It could give sound results. Still it is inefficient in the sense that you are using relatively high resolution for a very simple and smooth structure. I wonder whether the 99 % of empty simulation volume could not be replaced by some analytical model...
But, if it is so, why not get along completely without the "1e6 scaling" and use the SI units instead? I suggest to define the size to 0.32 meter, so setting the resolution to 0.01*1e6 = 10,000) should give you the same result, but in better readable units. This also touches the problem of simulation time: if you use "1 meter" as size unit, and define MEEP to run for 9 internal time units, it is quite clear the physical run time would be 9/c = 3.002-08 seconds = 30.02 nanoseconds. If the prescaling of 1e6 is applied, then it goes more complicated and I tend to make errors in estimations in such cases. Ad 3. If a sheet of 50 micrometers is to be simulated, the resolution has either to be increased at least 60 times, or some informed approximation has to be applied. As I wrote, thin metallic sheets can sometimes be well approximated by a thicker resistive metal slab, but I do not have any clue as to what extent this can be applied to Casimir force simulations. Ad 4. I can recall I got big problems with symmetries that also applied to my sources; as a result, I could never excite a plane wave in such cases. But maybe it is only related to Python meep or maybe I just did something wrong. I had to try everything from scratch as I found no example of symmetries in Python-meep anywhere. Filip 2014-11-24 20:57 GMT+01:00, Steve <russell7...@roadrunner.com>: > Dear Filip, > > Thank you for your response. > > Item 1. I am using 2.3 because I didn't have anything else to use. I am > happy to know that it is the right value to use. I am working a highly > visible problem so my mistakes will be scrutinized. Of course I only > expect to "break the ice" to encourage someone to use available funding > and skills to work the problem in detail, but I also want my answers to > be good enough to do that. > > Another aspect is that I know of an experimental effort to build and > test this device with variations but as I wrote in an earlier message, > there is no working theory which explains previous experimental results > so all efforts to date have been "cut and try" type methods. (Of course > there are rudiments of theory which are being used, 5 different ones > publicly known, at last count.) > > Item 2. I will need to read your read on your web site to understand > this. This is what I have done. > > I set lattice size to 320000 x 320000 and scaling 1:1e6 and used copper > normalized to 1e-6 as my material. Then I set resolution to 1e-2. My > idea was that my wavelength is about 0.15 meters (frequency ~2 GHz) so I > need a minimum of 10 samples per cycle to characterize the driving > frequency. Anyway, 320,000 x 1e-6 gives 0.32 meters which is a little > larger than my geometry. Then with my resolution of 0.01, I am sampling > the lattice at only 3200 points. That should be more than enough, maybe > 100 times more than enough, but it runs. Slowly but it runs and for very > short runs h5topng produces usable PNG files. I expect that to maintain > for longer runs. I started a run last night which should finish about > noon tomorrow. Simulating 9 seconds real time so run time is 9/1e-6 = > 9,000,000. That is confusing and I don't know why Meep was made to use > Meep time as run time, but I guess that using simulated time would also > be confusing as well as hiding Meep's operation under another layer of > conversion. > > Item 3. Well, 50 um is the dimension of the material used and that I > have coded into my geometry. If I can avoid approximations I want to do > so for reasons I wrote about in Item 1. above. I will need to look into > this in more detail but if the simulation currently running produces a > viable resonate field image then that will be a consideration. > > Item 4. I really could benefit from symmetry. The ability cut a 36 hour > run time by 3/4 or even 1/2 is significant, and even more so when doing > what amounts to test runs. I wonder if it is simply a coding error that > mismatches the coordinates between the lattice and the geometry. After > my run completes tomorrow I will change the axis on my geometry to see > if symmetry can be maintained that way. It is pretty easy to see the > mismatch of the field phases. I may need to play with that, too. > > Item 5. 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 <russell7...@roadrunner.com>: >> > 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-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
