Just last night I got a hexagonal frustum modeled to my satisfaction. I have plugged in these numbers, plus .125" for the wall thickness and attached a .ctl file as a .txt file. The frequency, material, and scale are completely arbitrary at the moment, just something to test the geometry. It also lacks end caps, which should be relatively easy to add on. I added some comments and removed some dead code just now (I was planning on posting tomorrow, but carpe diem), and since I didn't test it, be prepared to have at least one syntax error (with my luck).

No perforations are modeled, in theory they should not affect the analysis, correct?

.....I also wrote the computer program to display the Poynting vector field......1) It changes its direction around the antenna, this impacts the whole field

2) It changes its time average, which is not zero anymore.

I'm not clear on the high-level math, but given an example or an algorithm I can code anything. If you could share the algorithm with me, I can code it in POVRay and generate 3D animated movies to include the E,H, and Poynting vector fields. Being able to see all 3 at once and in motion should be very instructive...

I don't think it's too long at just under 2 inches or 48.4 mm 2450 MHz as it will be pointing down the length long axis between the plates.

Edit: added a little clarity.

Hi Shell,

You are amazing. How did you get those images?

***No you are! You sent them to me and i saved them for ref.

They are Poynting vector field images I calculated based on a program I wrote using Mathematica, an exact solution using Associated Legendre functions and Spherical Bessel Functions. They are not calculated using COMSOL FEA.

I also wrote the computer program to display the Poynting vector field.

Since they are based on an exact solution for standing waves inside the frustum, the Poynting vector averages zero over an integer number of periods. (It fluctuates like a sine, pointing in one direction over 1/2 a period, and pointing in the opposite direction over the next 1/2 period).

*** That's not what we want is it.

I can already tell you that the Poynting vector field using the exact solution based on standing waves does NOT agree with Meep, because Meep takes into account the RF feed antenna, which the exact solution does NOT. The antenna disturbs the Poynting vector field:

1) It changes its direction around the antenna, this impacts the whole field

.....I also wrote the computer program to display the Poynting vector field......1) It changes its direction around the antenna, this impacts the whole field

2) It changes its time average, which is not zero anymore.

I'm not clear on the high-level math, but given an example or an algorithm I can code anything. If you could share the algorithm with me, I can code it in POVRay and generate 3D animated movies to include the E,H, and Poynting vector fields. Being able to see all 3 at once and in motion should be very instructive...

To add to this, I do OpenCL and CUDA optimization as well as more generic multi-threading. If you guys have any routines you think can benefit from a GPU let me know

Since others have expressed interest in optimizing meep - just a quick note on profiling to find bottlenecks via Ubuntu, or if you're just interested in quickly getting meep running (sorry, these instructions aren't for the cutting-edge latest meep source, since the dependencies may not be so trivial in that case).

sudo apt-get install meep h5utilssudo apt-get install meep-mpich2

Now you can run meep either in single-threaded mode or multi-threaded using MPI:

meep file.ctlmpirun -np 4 meep-mpich2 file.ctl

If you'd like to get profiling working, build from source with some modifications:

This will give you the human-readable profiler output. Since the .ctl may take a very long time to run (especially without using the MPI binary), I've modified libctl/meep.cpp to install a sigint handler which exits properly in response to ctrl+c so the profiler data will still be generated if you terminate early (see http://www.linuxquestions.org/questions/linux-software-2/gprof-profile-an-application-782385/, You can just place the signal handler setup into ctl_start_hook, for example).

Nothing too surprising, basic vector math eats up most of the CPU cycles. I think the -pg compiler switch disables function inlining, so the real story is probably a bit different than the results a profiler will give. But it's a starting point, anyway.

Since others have expressed interest in optimizing meep - just a quick note on profiling to find bottlenecks via Ubuntu, or if you're just interested in quickly getting meep running (sorry, these instructions aren't for the cutting-edge latest meep source, since the dependencies may not be so trivial in that case).

sudo apt-get install meep h5utilssudo apt-get install meep-mpich2

Now you can run meep either in single-threaded mode or multi-threaded using MPI:

meep file.ctlmpirun -np 4 meep-mpich2 file.ctl

If you'd like to get profiling working, build from source with some modifications:

This will give you the human-readable profiler output. Since the .ctl may take a very long time to run (especially without using the MPI binary), I've modified libctl/meep.cpp to install a sigint handler which exits properly in response to ctrl+c so the profiler data will still be generated if you terminate early (see http://www.linuxquestions.org/questions/linux-software-2/gprof-profile-an-application-782385/, You can just place the signal handler setup into ctl_start_hook, for example).

Nothing too surprising, basic vector math eats up most of the CPU cycles. I think the -pg compiler switch disables function inlining, so the real story is probably a bit different than the results a profiler will give. But it's a starting point, anyway.

I could bet dim never equals to D1 in practice; if that is the case the whole expression can be simplified and moved upstream. But we should discuss this in a Meep forum, not here.

int num_direction(direction d) const { return num[((int) d) % 3]; };

Maybe a candidate for optimization: is it using ivec ? Can the direction be made of a special form which guarantee that the modulo is always 0 or 1 ? or that mod can be optimized because of the special form of d (ie d is a Mersenne prime etc.)

from the prior csv Meep data files. (This is the equation, that's it really, this is the Abraham definition of the Poynting vector.)

There is a strong, definite Poynting vector from the small base towards the big base, which means that the energy flux is from the small base towards the big base. This would mean, that in order to satisfy Conservation of Momentum, the copper cone needs to move in the direction towards the small base to balance the energy flow in the opposite direction. Alternatively, the Poynting vector field may all get dissipated into heat at the big base. But please note that Meep takes into account losses in detail in the copper model.

The Poynting vector seems to be strongly associated with the RF feed from the antenna.

The Big base is at the left and the Small Base is at the right for the xz and the xy plane views.

NEW INFORMATION: We show here that those (Greg Egan, etc.) that pontificate that the electromagnetic fields inside the EM Drive produce a Poynting vector that sums up to zero over integer periods of time are plain wrong. The reason is that the Poynting vector sums up to zero over integer periods of time only when the electromagnetic fields are standing waves (waves that do not travel in the longitudinal direction). The RF feed antenna disturbs what would otherwise be a standing wave frozen in space and results in waves that travel in the longitudinal direction back and forth and a time variation of the amplitude electromagnetic field that is not a simple sinuosoid, as long as the RF feed is on. This results in a non-zero Poynting vector with a net pointing from the small base to the big base over integer periods of time (probably due to geometric attenuation of the travelling waves due to the conical taper). During EM Drive experiments, the RF feed is on: it is only with the RF feed on that forces have been measured. Notice that the period of this non-sinusoidal variation of the Poynting vector is half the period of the electromagnetic field (as expected from theoretical considerations).

x = longitudinal axis along the length of the truncated coney,z = (transverse) Cartesian axes perpendicular to the longitudinal axis

In contrast, on the circular cross section planar section at a base, the field appears to be self -cancelling over integer periods of time, alternating between a sink and source (this is consistent with the fact that it is the geometric attenuation due to the conical taper of the electromagnetic field, and the RF antenna feed that are responsible for the flux being pointed from the small base towards the big base): yz plane (Circular cross section at Base)

Due to the planar nature of the dipole antenna effect, the Poynting vector field in the xy plane has significantly smaller amplitude than the one in the xz plane. However, it in increasing with time, the amplitude at Time Step 13 clearly being much larger than at TS03 and TS08 (which are similarly located in the time cycle).

You know guys... I'm sitting down here procrastinating about this and that.

I must say i have very much enjoyed seeing so much progress especially by the wonderful Aero and Shell. It is genuinely lovely to see such sharp minds at work, and on a forum to boot. Gives one hope for "Da net" instead of reams of rubbish.

Anyhow. Back on track. All this talk of code reminded me of something. The natural laws of the Universe that we know of such as COE are pretty much ironclad. But here I am typing away on a machine that contains several "Virtual machines" that at full tilt runs off a 750w PSU. All I did was take away the hardware resources by using VMware. Which was created by a lot of clever people to make an "unnatural system" work even better. (or even more unnaturally depending on how you look at it) Anyway - this enables such things to happen.

I once heard that we would have to line several stars up in order to distort SpaceTime enough to make a ERB. I don't believe that anymore. The rules are there... But the method? I very much believe that sometimes we can "trick" the Universe into not paying much attention to us. It just has to be done properly.

BTW. Bit extreme with the ERB. Just hoping to give people here a breather and a pat on the back. Well done!

Dr. Rodal- Time slices 3 thru 7 have been added to the csv folder on Google Drive. Same place as the other ones, I just changed the name to reflect 3 thru 13.

@aero:

two important questions to investigate this further:

1) How do you impose boundary conditions? What are your boundary conditions and how do you actually implement them in Meep (I read that boundary conditions can be imposed such that the problem becomes nonlinear, which would also partly explain the results)

2) TS013 : does this mean that you only marched the FD solution through 13 time steps total? If so, this is way insufficient to make sure that this is not just a transient, if so we would need to investigate marching forwards many more time steps to investigate the time evolution

Considering that Dr. Rodal's analysis shows only 3 slices of the frustum, what are the odds that there are some vectors in the field that are not show actually point the other way? Is there some way to sum the entire Poynting field, including those not shown in the cross sectional views? I notice that in Meep there is the option to output the Poynting vectors here:

output-Xfield-x, output-Xfield-y, output-Xfield-z, output-Xfield-r, output-Xfield-p Output the x, y, z, r, or φ component respectively, of the field X, where X is either h, b, e, d, or s for the magnetic, electric, displacement, or Poynting field, respectively. If the field is complex, outputs two datasets, e.g. ex.r and ex.i, within the same HDF5 file for the real and imaginary parts, respectively. Note that for outputting the Poynting field, you might want to wrap the step function in synchronized-magnetic to compute it more accurately; see Synchronizing the magnetic and electric fields.

I wonder if there is a HDF5 reduction tool that can sum up fields in the file and reduce the entire field to one vector, or how complicated it would be to write such a tool. Seems to me to be just adding up a bunch of numbers... which computers are rumored to be good at.

Considering that Dr. Rodal's analysis shows only 3 slices of the frustum, what are the odds that there are some vectors in the field that are not show actually point the other way? Is there some way to sum the entire Poynting field, including those not shown in the cross sectional views? I notice that in Meep there is the option to output the Poynting vectors here:

output-Xfield-x, output-Xfield-y, output-Xfield-z, output-Xfield-r, output-Xfield-p Output the x, y, z, r, or φ component respectively, of the field X, where X is either h, b, e, d, or s for the magnetic, electric, displacement, or Poynting field, respectively. If the field is complex, outputs two datasets, e.g. ex.r and ex.i, within the same HDF5 file for the real and imaginary parts, respectively. Note that for outputting the Poynting field, you might want to wrap the step function in synchronized-magnetic to compute it more accurately; see Synchronizing the magnetic and electric fields.

I wonder if there is a HDF5 reduction tool that can sum up fields in the file and reduce the entire field to one vector, or how complicated it would be to write such a tool. Seems to me to be just adding up a bunch of numbers... which computers are rumored to be good at.

Nothing left to chance here. In Cartesian coordinates three views should suffice, plus common knowledge of transverse electromagnetic variation with the azimuthal angle. There are only two planes shown at azimuthal angles of 0 and 90 degrees, but the variation with azimuthal angle is shown in the base view and it is a conventional harmonic m=1, n=1 variation.

It is for higher modes, m>1 that what you are discussing would apply, not for m=1, n=1.

We know what the antenna looks like: it is a dipole antenna, the plane views are consistent with it.

To double check this all that is needed is to provide other circular cross-sections: I would favor one at the antenna location, another one close to it, within the same longitudinal wave-pattern, and another one in the next longitudinal wave pattern away from it towards the big base.

Concerning <<seems to me to be just adding up a bunch of numbers... which computers are rumored to be good at.>>, the csv files are available to the public, so anybody can perform their own postprocessing calculations based on the csv, all you have to do is to calculate this can be done by anybody without using HDF5

from the prior csv Meep data files. (This is the equation, that's it really, this is the Abraham definition of the Poynting vector.)

There is a strong, definite Poynting vector from the small base towards the big base, which means that the energy flux is from the small base towards the big base. This would mean, that in order to satisfy Conservation of Momentum, the copper cone needs to move in the direction towards the small base to balance the energy flow in the opposite direction. Alternatively, the Poynting vector field may all get dissipated into heat at the big base.

The Poynting vector seems to be strongly associated with the RF feed from the antenna.

The Big base is at the left and the Small Base is at the right for the xz and the xy plane views.

NEW INFORMATION: We show here that those (Greg Egan, etc.) that pontificate that the electromagnetic fields inside the EM Drive produce a Poynting vector that sums up to zero over integer periods of time are plain wrong. The reason is that the Poynting vector sums up to zero over integer periods of time only when the electromagnetic fields are standing waves (waves that do not travel in the longitudinal direction). The RF feed antenna disturbs what would otherwise be a standing wave frozen in space and results in waves that travel in the longitudinal direction back and forth and a time variation of the amplitude electromagnetic field that is not a simple sinuosoid, as long as the RF feed is on. This results in a non-zero Poynting vector with a net pointing from the small base to the big base over integer periods of time (probably due to geometric attenuation of the travelling waves due to the conical taper). During EM Drive experiments, the RF feed is on: it is only with the RF feed on that forces have been measured. Notice that the period of this non-sinusoidal variation of the Poynting vector is half the period of the electromagnetic field (as expected from theoretical considerations).

x = longitudinal axis along the length of the truncated coney,z = (transverse) Cartesian axes perpendicular to the longitudinal axis

Considering that Dr. Rodal's analysis shows only 3 slices of the frustum, what are the odds that there are some vectors in the field that are not show actually point the other way? Is there some way to sum the entire Poynting field, including those not shown in the cross sectional views? I notice that in Meep there is the option to output the Poynting vectors here:

output-Xfield-x, output-Xfield-y, output-Xfield-z, output-Xfield-r, output-Xfield-p Output the x, y, z, r, or φ component respectively, of the field X, where X is either h, b, e, d, or s for the magnetic, electric, displacement, or Poynting field, respectively. If the field is complex, outputs two datasets, e.g. ex.r and ex.i, within the same HDF5 file for the real and imaginary parts, respectively. Note that for outputting the Poynting field, you might want to wrap the step function in synchronized-magnetic to compute it more accurately; see Synchronizing the magnetic and electric fields.

I wonder if there is a HDF5 reduction tool that can sum up fields in the file and reduce the entire field to one vector, or how complicated it would be to write such a tool. Seems to me to be just adding up a bunch of numbers... which computers are rumored to be good at.

Dr. Rodal- Time slices 3 thru 7 have been added to the csv folder on Google Drive. Same place as the other ones, I just changed the name to reflect 3 thru 13.

@aero:

two important questions to investigate this further:

1) How do you impose boundary conditions? What are your boundary conditions and how do you actually implement them in Meep (I read that boundary conditions can be imposed such that the problem becomes nonlinear, which would also partly explain the results)

The boundary is the copper structure of the cavity itself. The antenna is inside the structure and the energy (mostly) bounces around inside the cavity. Boundary conditions depend on the copper model.

Quote

2) TS013 : does this mean that you only marched the FD solution through 13 time steps total? If so, this is way insufficient to make sure that this is not just a transient, if so we would need to investigate marching forwards many more time steps to investigate the time evolution

I marched from the start to 30.7 complete cycles. At time = 30.7 periods of the drive frequency I turned on the data collection. That gave me 14 slices (0 thru 13) until the end of the run. I could just as easily named them 307 thru 320 except I always get confused with counting starting at zero, and I didn't think to do it anyway. But they are in fact time slices 307 to 320 of the run, give or take 1.

Due to the planar nature of the dipole antenna effect, the Poynting vector field in the xy plane has significantly smaller amplitude than the one in the xz plane. However, it in increasing with time, the amplitude at Time Step 13 clearly being much larger than at TS03 and TS08 (which are similarly located in the time cycle).

Dr. Rodal- Time slices 3 thru 7 have been added to the csv folder on Google Drive. Same place as the other ones, I just changed the name to reflect 3 thru 13.

@aero:

two important questions to investigate this further:

1) How do you impose boundary conditions? What are your boundary conditions and how do you actually implement them in Meep (I read that boundary conditions can be imposed such that the problem becomes nonlinear, which would also partly explain the results)

The boundary is the copper structure of the cavity itself. The antenna is inside the structure and the energy (mostly) bounces around inside the cavity. Boundary conditions depend on the copper model.

Quote

2) TS013 : does this mean that you only marched the FD solution through 13 time steps total? If so, this is way insufficient to make sure that this is not just a transient, if so we would need to investigate marching forwards many more time steps to investigate the time evolution

I marched from the start to 30.7 complete cycles. At time = 30.7 periods of the drive frequency I turned on the data collection. That gave me 14 slices (0 thru 13) until the end of the run. I could just as easily named them 307 thru 320 except I always get confused with counting starting at zero, and I didn't think to do it anyway. But they are in fact time slices 307 to 320 of the run, give or take 1.

Thank you for the information on the time steps, I understand now that you have 320 (three hundred and twenty) time steps (the time steps were 307 to 320). Thank you.

I need more details on what boundary conditions you are imposing and exactly how are you imposing them at the nodes to understand the model. I am NOT discussing the copper modeling. I am interested in the boundary conditions you implement such that the transverse electric fields Ez, Ez, Ey are zero at a boundary and that the normal magnetizing field Hx, Hy and Hz is zero at a boundary as appropriate to each boundary. In particular for the side conical walls.

Could you give us an example of the actual code showing the imposition of boundary conditions at a finite difference gridpoint on the conical wall?

From the manual:

"An even simpler boundary condition is a metallic wall, where the fields are simply forced to be zero on the boundaries, as if the cell were surrounded by a perfect metal (zero absorption, zero skin depth). More generally, you can place perfect metal materials anywhere you want in the computational cell, e.g. to simulate metallic cavities of an arbitrary shape. "

In my understanding, wall thickness does not matter with perfect metal. With copper, wall thickness and a PML box encompassing the drive would be needed.