Author Topic: EM Drive Developments - related to space flight applications - Thread 3  (Read 1875425 times)

Offline SeeShells

  • Senior Member
  • *****
  • Posts: 2335
  • Every action there's a reaction we try to grasp.
  • United States
  • Liked: 2982
  • Likes Given: 2601




Warp-shell
Length         9.4488
Large Diameter 7.9134
Small Diameter 5.874
All in inches
2.45 GHz magnetron

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?

No, not at all! I'm jazzed!

Offline aero

  • Senior Member
  • *****
  • Posts: 2785
  • 92129
  • Liked: 724
  • Likes Given: 249
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.
Retired, working interesting problems

Offline VAXHeadroom

  • Full Member
  • *
  • Posts: 196
  • Whereever you go, there you are. -- BB
  • Baltimore MD
  • Liked: 259
  • Likes Given: 151
.....
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...
« Last Edit: 07/03/2015 04:53 PM by VAXHeadroom »
Emory Stagmer
  Executive Producer, Public Speaker UnTied Music - www.untiedmusic.com

Offline SeeShells

  • Senior Member
  • *****
  • Posts: 2335
  • Every action there's a reaction we try to grasp.
  • United States
  • Liked: 2982
  • Likes Given: 2601
...
A quick calculator for size and care must be taken in the wire size as it's quite important.
http://jcoppens.com/ant/qfh/calc.en.php

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

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

***I wait for Aero and you to meep the poynting vectors.


Offline thebigcat

  • Member
  • Posts: 2
  • Liked: 3
  • Likes Given: 0
.....
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 :D

Offline kitsuac

  • Member
  • Posts: 10
  • NW Ohio
  • Liked: 9
  • Likes Given: 4
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 h5utils
sudo apt-get install meep-mpich2


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

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


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

sudo apt-get build-dep meep
sudo apt-get source meep
cd meep-1.1.1
./configure CFLAGS=-pg CXXFLAGS=-pg
make && sudo make install
meep file.ctl
gprof meep > profile.txt


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

Profiler output after running aero's Bradycone3D.ctl (http://forum.nasaspaceflight.com/index.php?topic=37642.msg1399328#msg1399328):

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name   
  8.38      7.33     7.33 557328093     0.00     0.00  meep::ivec::operator-(meep::ivec const&) const
  8.36     14.64     7.31 1622701977     0.00     0.00  meep::grid_volume::num_direction(meep::direction) const
  7.70     21.38     6.74        3     2.25    12.42  meep::fields::connect_the_chunks()
  5.34     26.05     4.67 325024307     0.00     0.00  meep::ivec::operator*(int) const
  4.73     30.19     4.14 325042084     0.00     0.00  meep::ivec::operator+(meep::ivec const&) const
  4.41     34.05     3.86 521866872     0.00     0.00  meep::grid_volume::owns(meep::ivec const&) const
  4.38     37.88     3.83        3     1.28    10.03  meep::fields::find_metals()
  4.19     41.55     3.67 110494080     0.00     0.00  meep::fields::on_metal_boundary(meep::ivec const&)
  3.04     44.21     2.66 1304761006     0.00     0.00  meep::ivec::in_direction(meep::direction) const
  2.98     46.82     2.61 1509572196     0.00     0.00  meep::stop_at_direction(meep::ndim)
  2.33     48.85     2.04 1509572196     0.00     0.00  meep::start_at_direction(meep::ndim)


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.
« Last Edit: 07/03/2015 06:42 PM by kitsuac »

Offline deuteragenie

  • Member
  • Posts: 71
  • Germany
  • Liked: 22
  • Likes Given: 0
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 h5utils
sudo apt-get install meep-mpich2


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

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


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

sudo apt-get build-dep meep
sudo apt-get source meep
cd meep-1.1.1
./configure CFLAGS=-pg CXXFLAGS=-pg
make && sudo make install
meep file.ctl
gprof meep > profile.txt


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

Profiler output after running aero's Bradycone3D.ctl (http://forum.nasaspaceflight.com/index.php?topic=37642.msg1399328#msg1399328):

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name   
  8.38      7.33     7.33 557328093     0.00     0.00  meep::ivec::operator-(meep::ivec const&) const
  8.36     14.64     7.31 1622701977     0.00     0.00  meep::grid_volume::num_direction(meep::direction) const
  7.70     21.38     6.74        3     2.25    12.42  meep::fields::connect_the_chunks()
  5.34     26.05     4.67 325024307     0.00     0.00  meep::ivec::operator*(int) const
  4.73     30.19     4.14 325042084     0.00     0.00  meep::ivec::operator+(meep::ivec const&) const
  4.41     34.05     3.86 521866872     0.00     0.00  meep::grid_volume::owns(meep::ivec const&) const
  4.38     37.88     3.83        3     1.28    10.03  meep::fields::find_metals()
  4.19     41.55     3.67 110494080     0.00     0.00  meep::fields::on_metal_boundary(meep::ivec const&)
  3.04     44.21     2.66 1304761006     0.00     0.00  meep::ivec::in_direction(meep::direction) const
  2.98     46.82     2.61 1509572196     0.00     0.00  meep::stop_at_direction(meep::ndim)
  2.33     48.85     2.04 1509572196     0.00     0.00  meep::start_at_direction(meep::ndim)


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.

inline direction stop_at_direction(ndim dim) {
  return (direction) (dim + 1 + 2 * (dim == D1));
}

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

See http://stackoverflow.com/questions/1697358/fast-modulo-3-or-division-algorithm?lq=1

idiv cycles: approx. 43
shift/add approach cycles: approx 30, so at first glance there is something to be won to optimize %3
 
Does it beat -O3 ?

Also, what is the value of direction for one run? Does it change or is it set once the .ctl file is loaded? If it is constant troughout a run, this can be simplified a lot of course.
« Last Edit: 07/03/2015 08:10 PM by deuteragenie »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5895
  • USA
  • Liked: 6045
  • Likes Given: 5325
Again, I calculated the Poynting Vector Fields

 

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 cone
y,z = (transverse) Cartesian axes perpendicular to the longitudinal axis

xz plane (Trapezium flat section)
TS03 = peak flux (pointing from small base towards big base)
TS04 = flux (pointing from small base towards big base)
TS05 = flux (pointing from small base towards big base)
TS06 =  significantly less flux (pointing from small base towards big base)
TS07 = minimum flux (pointing from small base towards big base)
TS08 = peak flux (pointing from small base towards big base)
TS09 = flux (pointing from small base towards big base)
TS10 = flux (pointing from small base towards big base)
TS11 = significantly less flux (pointing from small base towards big base)
TS12 = minimum flux (pointing from small base towards big base)
TS13 = peak flux (pointing from small base towards big base)
« Last Edit: 07/03/2015 08:06 PM by Rodal »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5895
  • USA
  • Liked: 6045
  • Likes Given: 5325
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)

TS03 = peak sink
TS04 = sink
TS05 = self cancelling
TS06 =  source
TS07 = source
TS08 = peak sink
TS09 = sink
TS10 = self cancelling
TS11 = source
TS12 = source
TS13 = peak sink
« Last Edit: 07/03/2015 07:36 PM by Rodal »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5895
  • USA
  • Liked: 6045
  • Likes Given: 5325
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).
« Last Edit: 07/03/2015 07:41 PM by Rodal »

Online tchernik

  • Full Member
  • **
  • Posts: 251
  • Liked: 298
  • Likes Given: 583
Wow. These are fantastic results.

And I imagine that similar modeling can be now done to many other geometries, antenna positions, frequencies, etc, etc, by other people using their own meep installs.

Generating with that a very detailed model of parameters affecting the Poynting vector and probably, thrust.

This basically means experimentalists will no longer be in the dark when trying to understand what happens inside the cavities. Truly remarkable.

PS: open source science rules!
« Last Edit: 07/03/2015 07:45 PM by tchernik »

Offline Possibles

  • Member
  • Posts: 10
  • germany
  • Liked: 6
  • Likes Given: 0
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!

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5895
  • USA
  • Liked: 6045
  • Likes Given: 5325
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
« Last Edit: 07/03/2015 07:59 PM by Rodal »

Offline lmbfan

  • Member
  • Posts: 55
  • Phoenix
  • Liked: 42
  • Likes Given: 42
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:

 http://ab-initio.mit.edu/wiki/index.php/Meep_Reference#Output_functions

Notably this section:

Quote
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.

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5895
  • USA
  • Liked: 6045
  • Likes Given: 5325
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:

 http://ab-initio.mit.edu/wiki/index.php/Meep_Reference#Output_functions

Notably this section:

Quote
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

« Last Edit: 07/03/2015 08:24 PM by Rodal »

Offline SeeShells

  • Senior Member
  • *****
  • Posts: 2335
  • Every action there's a reaction we try to grasp.
  • United States
  • Liked: 2982
  • Likes Given: 2601
Again, I calculated the Poynting Vector Fields

 

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 cone
y,z = (transverse) Cartesian axes perpendicular to the longitudinal axis

xz plane (Trapezium flat section)
TS03 = peak flux (pointing from small base towards big base)
TS04 = flux (pointing from small base towards big base)
TS05 = flux (pointing from small base towards big base)
TS06 =  significantly less flux (pointing from small base towards big base)
TS07 = minimum flux (pointing from small base towards big base)
TS08 = peak flux (pointing from small base towards big base)
TS09 = flux (pointing from small base towards big base)
TS10 = flux (pointing from small base towards big base)
TS11 = significantly less flux (pointing from small base towards big base)
TS12 = minimum flux (pointing from small base towards big base)
TS13 = peak flux (pointing from small base towards big base)

Over the top! Beautiful! Dr. Jose Rodal you rock and Aero my hat is off, I'd give you both a hug, but it will have to be a FTL hug. Feel it? Thanks guys.

As to the rest of you what can I say but wow you made this effect become attainable you steely eyed meep meepers.

Let's digest this just a little as I do not want to jump any guns here but right now I'm going to look at where I'm going to place my helix antenna and start to model it into my design.

Wow again. Very nice.

Shell

Offline deuteragenie

  • Member
  • Posts: 71
  • Germany
  • Liked: 22
  • Likes Given: 0
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:

 http://ab-initio.mit.edu/wiki/index.php/Meep_Reference#Output_functions

Notably this section:

Quote
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.

Like this?

(run-until 200 (synchronized-magnetic output-poynting output-tot-pwr))

Offline aero

  • Senior Member
  • *****
  • Posts: 2785
  • 92129
  • Liked: 724
  • Likes Given: 249
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.
Retired, working interesting problems

Offline VAXHeadroom

  • Full Member
  • *
  • Posts: 196
  • Whereever you go, there you are. -- BB
  • Baltimore MD
  • Liked: 259
  • Likes Given: 151
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).
3D animation rendering, please stand by :)
Emory Stagmer
  Executive Producer, Public Speaker UnTied Music - www.untiedmusic.com

Offline deuteragenie

  • Member
  • Posts: 71
  • Germany
  • Liked: 22
  • Likes Given: 0
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.

Tags: