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

#### deltaMass

• Full Member
• Posts: 955
• A Brit in California
• Liked: 671
• Likes Given: 275
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4380 on: 07/15/2015 09:26 PM »
A comment about conservation. That might come as a surprise to some here, since I almost never talk about that.

Let's think about the battery, and its associated parameters Ein and Pin.
Let's imagine some propellantless drive under battery power, undergoing two scenarios:

1. Drive clamped to the lab frame and so constrained from moving while battery gives rise to a thrust.
2. Drive accelerates for some time (severely subrelativistically at all times), and then the battery power is switched off, leaving it coasting. We apply an external force to decelerate the "dead" drive to a full stop.

In both cases we aim to consume the same fraction f of the total battery power.
We can make a measurement for both scenarios in the lab frame.
Does that imply that this is the same thing as switching both drives on for the same amount of time?
What does it mean to measure the energy of a moving battery in the lab frame?

To guide your thinking on these questions, here's something you might not know about energy transformation between two inertial frames. It is not as simple as you might imagine. It goes like this, per Newton, and describes how kinetic energy changes transform:

dE1 = dE0 + m dv deltaV

where
m is the mass of the object possessing kinetic energy
deltaV is the change in velocity of the object in the rest frame (frame 0)
dv is the component of the relative velocity of the frames along the direction of kinetic motion

You can prove this quite simply using a small amount of algebra. I will if you want me to.

« Last Edit: 07/16/2015 01:09 AM by deltaMass »

#### deltaMass

• Full Member
• Posts: 955
• A Brit in California
• Liked: 671
• Likes Given: 275
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4381 on: 07/15/2015 09:32 PM »
[snip..] the talk about conservation of energy got entangled in relativity, and the reason confuses me. Could we agree to discuss scenarios where v<<c so gamma is close to 1? This way we can use classical mechanics and  not get needlessly bogged down on einstenian paradoxes while imultaneously recognizing that al inertial reference frames should be equivalent. Not that you need relativity for that, since equivalence under Galilean transformations has been part of classical mechanics for a very long time.
You can thank @WarpTech for that. He continually obfuscates what is clearly a problem in strictly classical mechanics with his gammas, gravity references, black holes, rest energies and metric tensor components. I for one am sick of it.
« Last Edit: 07/15/2015 09:35 PM by deltaMass »

#### LasJayhawk

##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4382 on: 07/15/2015 10:43 PM »
The transmitter at Arecibo is 1 megawatt at 2.3 GHz CW.
It was built by Continential Electronics out of Texas, I'm sure if you have the money, they will make whatever you want.

#### deltaMass

• Full Member
• Posts: 955
• A Brit in California
• Liked: 671
• Likes Given: 275
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4383 on: 07/15/2015 11:12 PM »
The transmitter at Arecibo is 1 megawatt at 2.3 GHz CW.
It was built by Continential Electronics out of Texas, I'm sure if you have the money, they will make whatever you want.
Wikipedia says
Quote
The Arecibo Radio Telescope has three radar transmitters, with effective isotropic radiated powers of 20 TW at 2380 MHz, 2.5 TW (pulse peak) at 430 MHz, and 300 MW at 47 MHz.
Conflict?

#### rfmwguy

• EmDrive Builder (retired)
• Senior Member
• Posts: 2166
• Liked: 2684
• Likes Given: 1124
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4384 on: 07/15/2015 11:27 PM »
[snip..] the talk about conservation of energy got entangled in relativity, and the reason confuses me. Could we agree to discuss scenarios where v<<c so gamma is close to 1? This way we can use classical mechanics and  not get needlessly bogged down on einstenian paradoxes while imultaneously recognizing that al inertial reference frames should be equivalent. Not that you need relativity for that, since equivalence under Galilean transformations has been part of classical mechanics for a very long time.
You can thank @WarpTech for that. He continually obfuscates what is clearly a problem in strictly classical mechanics with his gammas, gravity references, black holes, rest energies and metric tensor components. I for one am sick of it.
There is an imbalance in the cosmos which classical physics has failed to resolve. Gravity and its antithesis; a counterbalance to the only known force without a repulsive state. While I surmise em radiation has a counterbalance for CoE and may not directly produce thrust, gravity has zero, zip, nada CoE. This leaves us an opening to explore. Definition of this force is still in the "duh" phase. While I think no new physics are needed to resolve it, it remains unresolved because an old master failed to grasp it. So try this one for size; gravity is weak and extends to a cosmic scale. For every instance of gravity, a weak cosmic force equal to it is created. Failure to accept this theory leads to the opposite of what the universe is doing right now. So DM, time to define this force...perhaps its the only real explanation for what people are reporting. c'mon dm, you can do it!

I'll even get you started

g = GM/r2

Write its equivalent opposite equation. Forget that 5th force thing

https://en.m.wikipedia.org/wiki/Fifth_force

(Crickets)

x = r2/GM

« Last Edit: 07/16/2015 12:29 AM by rfmwguy »

#### ElizabethGreene

• Member
• Posts: 69
• Nashville, Tennessee
• Liked: 138
• Likes Given: 3
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4385 on: 07/15/2015 11:30 PM »
The largest microwave sources I found were Gyrotrons. ...
Along gyrotrons, the most powerful manmade source of microwaves are klystrons. SLAC uses 150 megawatts (pulsed) S-band (3GHz) klystrons and 1.25 MW CW klystrons!
I was very wrong, thank you for the correction.  Klystrons appear to beat Gyrotrons by a wide margin at cm frequencies.  Gyrotrons only come into their own in the mm range.  Learned.

But we don't wand to ignite the plasma of a tokamak or power a particle accelerator, and we're not quite yet feeding lift engines of a mothership.
Particle accelerator?  Sounds like an excellent plan.  I could use one* when we get the emDrive mothership in orbit.

* In my idea book I have a sketch of a unique nuclear reactor.  It uses an accelerator to fire high energy electrons into a Tungsten target that fires high energy protons into Thorium and Beryllium fuel rods.  Be + 1.5 MeV photon = 1 neutron + 2 4He... 4Be + n = 2 4 2He + 2n ... 4Be + 4 2He =  12 6C + n ... Thorium + n = U233.  U233 Fission = Power for the mothership.

This is the only nuclear reactor I know of that a.) can be bought/built by Greene on the street and b.) you can turn on, i.e. make hot, once you are in orbit and safely out of the purview of NEST, the IAEA, etc.  Until you set it off the components are safe**.

** Ok, you aren't going to put Beryllium in your kids crayons, but it's still "safe" compared to your average nuclear reactor fuel rod.

*** I don't know if this works from a neutron economy POV,  It's just another idea in the book until I do that research.  The EmDrive comes first.

#### Eer

• Full Member
• Posts: 284
• Liked: 144
• Likes Given: 138
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4386 on: 07/15/2015 11:38 PM »
How to help scientists gather data and study the EMDrive, even if you are an absolute novice.

If you are excited about the EMDrive and wants to contribute to its research, but don't know how, this is a step-by-step guide that if performed correctly by anyone out there interested in helping would provide valuable information for the scientists to study and better understand the EMDrive behavior.

1. Install MEEP http://ab-initio.mit.edu/wiki/index.php/Meep (preferably from your package manager)
3. meep NSF-1701.ctl
4. Eventually, MEEP will output nine .h5 files. It may take a long time depending on your computer. Patience is a virtue.
5. h5totxt -t 13 -0 -y -0  ex.h5 > zCopper-exy.csv
6. Open your zCopper-exy.csv on a spread sheet and aero's zCopper-exy.csv on another. Open a third spread sheet that is one spread sheet minus the other, entry by entry. Check that highest entry (in absolute value). If it's negligible you are good to go. If it's a value too big, greater than 10^-6, your MEEP installation isn't in sync with ours, so it's no use.
7. Now you are good to go. Make a new directory to start the tests. Copy NSF-1701.ctl there.
8. Open NSF-1701.ctl in a text editor and change a single value. For example, (set! high 10.2) means the model is 10.2 inches high. Change the 10.2 to another value and save NSF-1701.ctl with this single change. This is called sensitivity analysis. One value at a time. (set! high 10.2) was just an example, change any value of interest
9. meep NSF-1701.ctl
10. h5totxt -t 13 -0 -y -0  ex.h5 > zCopper-exy.csv
11. Compare your new zCopper-exy.csv with your old one. See if there was any relevant change (do the spreadsheet comparison again). If there was no considerable change in values, it means the modification made doesn't impact the behavior of the EMDrive. This is an important information for scientists, so let us know. Otherwise, if there was a significant change, let us know if it was positive or negative and its intensity. If you don't know how, just upload the .h5 files somewhere and we will analyze it.

FYI, I've begun down this path.  Gave up trying to get RPM packages with all the right versions to work together, and installed Debian 8.  Am running on a dual quad-core Xeon in VMware, allocated 2 processors x 2 cores each, but I see it's only really using 1 cpu (which is maxed out, purely user space cpu time as expected).  6GB memory allocated, but it's only using a shade more than 3GB for the meep process.  Have not investigated the MPI alternatives, as I think those are more intended for clusters than symmetric multiprocessors.

It's presently up to step 1339 of its first run through NSF-1701.ctl.  Has about 57 min of cputime so far.  3 *.h5 files produced so far.

I'll work my way through your steps above and report results when I have them.
« Last Edit: 07/15/2015 11:39 PM by Eer »

#### rfmwguy

• EmDrive Builder (retired)
• Senior Member
• Posts: 2166
• Liked: 2684
• Likes Given: 1124
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4387 on: 07/16/2015 12:35 AM »
Congrats New Horizons team, very impressed...the best media question I heard was "when are we going back?" The answer was interesting, there are designs being worked on.

IMHO, the key for planetary science and space exploration success is becoming clear. It is not more sensitive  instrumentation, it is not lower cost hardware...it is faster propulsion. This is your challenge scientific community...to shrink the fabric of space and time with modern propulsion research.

To the propulsion industry...think outside the box. Your equations have shown us that propellants will never get us to where we want to go...faster and farther. Perhaps in this forum, one of us may help show you the way.

In case you are wondering, Space is big. Here is a "to scale" map of the solar system with the moon diameter as the scale length of one pixel. http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html No wonder it takes so much time to get anywhere.
Yep, which it never ceases to amaze me that we are trying to illuminate the solar system with a match. Goddard and Von Braun had their day, time to take the next step. Sounds crazy, but if I were a billionaire that really wanted to leave a scientific legacy, here's what I would do:

Offer a \$250M prize to a winner of a race. The race would be:

From LEO to 2AU...shortest time to get there wins.

Let them use gravity assist, chemical propellants, ion engines, floobie dust (hat-tip deltamass), its a simple time and speed calculation. Limit total mass to lets say a few hundred kg just to make it interesting.

Once qualified, Mr Billionaire pays for standardized ride to LEO and a standardized telemetry pack to be built in. Time begins at release. Releases can be sequential. Window of release: 2 years.

Now, there's something outside the box for all those X prize types out there. Call it the Galactic 500 (only because I'm from Indy).

Hey...no fair...this guy needs to credit me

http://www.huffingtonpost.com/benjamin-t-solomon/a-propellantless-propulsi_b_7718408.html

#### TheTraveller

##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4388 on: 07/16/2015 12:52 AM »
Sorry for interrupting, but there are a couple things that puzzle me. I don't think I'll post much or at all after this, since the thread is so active and I don't have the energy to keep up with it continuously.

First, I don't quite understand the discussion about how wave behave in a waveguide, when we're not dealing with waveguides; the frustrum is a not (just) that but a resonant chamber.  This means the radiation inside should form standing waves, with their nodes where the field is always zero, and whatnot, am I correct?

I've been looking at several sources, but they confirm that, if we have a standing wave the phase velocity is zero and group velocity is infinite. I can't tell who's right, but either the resonant chamber should not move at all, or resonant chambers should all explode the instant you put some energy in them, depending on who's right.

Second, the talk about conservation of energy got entangled in relativity, and the reason confuses me. Could we agree to discuss scenarios where v<<c so gamma is close to 1? This way we can use classical mechanics and  not get needlessly bogged down on einstenian paradoxes while imultaneously recognizing that al inertial reference frames should be equivalent. Not that you need relativity for that, since equivalence under Galilean transformations has been part of classical mechanics for a very long time.

A frustum is 1st a tapered microwave waveguide that is closed at each end. The EM waves inside behave as per known microwave waveguide physics.

Continuously variable Guide Wavelength/Group Velocity EM waves are bouncing from end to end. EM waves don't stand still. They can't.
« Last Edit: 07/16/2015 01:14 AM by TheTraveller »
It Is Time For The EmDrive To Come Out Of The Shadows

#### TheTraveller

##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4389 on: 07/16/2015 01:00 AM »
Length of Dipole Antenna modeled: 0.058 m
We can calculate the free-space wavelength as:  λ = c / frequency
Taking the frequency to be 2.45 GHz (as per @rfmwguy's model) then λ = c / frequency = 0.122364 m
Therefore the ratio of the dipole antenna length L to the wavelength λ is:

L / λ = 0.058 m/0.122364 m
= 0.4740

The internal Guide Waveguide, inside the cavity, is what you need to based your antenna length on. Not the external wavelength. Then as the waveguide is tapered, you need to calc the Guide Wavelength at the point of side wall insertion diameter. BTW you only need a 1/4 wave antenna (at the selected Guide Wavelength) with the outer shield connected to the side wall.
« Last Edit: 07/16/2015 01:14 AM by TheTraveller »
It Is Time For The EmDrive To Come Out Of The Shadows

#### deltaMass

• Full Member
• Posts: 955
• A Brit in California
• Liked: 671
• Likes Given: 275
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4390 on: 07/16/2015 01:20 AM »
So forget about Phase Velocity when dealing with EM waves inside a waveguide.

I've yet to find any use for the Phase Velocity.  I had a brief thought that obscene >> c values might cause some issues due to charges or magnetic fields being unable to rearrange fast enough in the material, but I intuit that should cause localized heating, not thrust.

Phase Velocity, inside a waveguide, is above c and is imaginary.

http://www.microwaves101.com/encyclopedias/waveguide-mathematics#velocity

Any reference or belief that anything inside a waveguide travels at Phase Velocity (greater than c) is just plain wrong and a failure to understand basic microwave waveguide engineering and physics.
vgroup + vphase = 2*c

was the physics you posted here a couple of days ago.
Now here you are laying down the law like a distinguished and irascible professor.

#### apoc2021

• Member
• Posts: 18
• Liked: 37
• Likes Given: 27
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4391 on: 07/16/2015 01:38 AM »
However, after yesterdays misunderstanding, revelation and embarrassment. I am still trying to put all the pieces back together in a comprehendible way.

Embarrassment - are you kidding? You are one of the most courageous people I know, and one of few here. You are hurling decades of learning and practical experience at a difficult, ambiguous problem, in full view of the public and without a shroud of anonymity, despite knowing the possibility of being wrong and despite knowing that [at times impolite] reviewers are waiting for a misstep. You know going into it that you might err, and whenever you do you publicly take ownership of the mistake and detail how and why you were wrong. And then you go right back to working on it again!

Please - and you don't need to hear this from me, but - just keep going. If everyone who was capable simply did what you do routinely, our society might be much closer to cracking this right now.

So let me just take the opportunity to say thanks. And kids, if you're reading, know that this man Todd is a man of courage!

#### WarpTech

• Full Member
• Posts: 1374
• Do it!
• Vista, CA
• Liked: 1426
• Likes Given: 1894
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4392 on: 07/16/2015 01:49 AM »
...
There is an imbalance in the cosmos which classical physics has failed to resolve. Gravity and its antithesis; a counterbalance to the only known force without a repulsive state. While I surmise em radiation has a counterbalance for CoE and may not directly produce thrust, gravity has zero, zip, nada CoE. This leaves us an opening to explore. Definition of this force is still in the "duh" phase. While I think no new physics are needed to resolve it, it remains unresolved because an old master failed to grasp it. So try this one for size; gravity is weak and extends to a cosmic scale. For every instance of gravity, a weak cosmic force equal to it is created. Failure to accept this theory leads to the opposite of what the universe is doing right now. So DM, time to define this force...perhaps its the only real explanation for what people are reporting. c'mon dm, you can do it!

I'll even get you started

g = GM/r2

Write its equivalent opposite equation. Forget that 5th force thing

https://en.m.wikipedia.org/wiki/Fifth_force

(Crickets)

x = r2/GM

The "balance" or symmetry of gravity is that for any quantum harmonic oscillator in it's ground state, the power radiated by the oscillator TO the ZPF is equal to the power absorbed by the oscillator FROM the ZPF.

Gravity depends on gradient in the available power of the ZPF. Particles "contract" as they fall toward the CM and into a gravity well. They also "inflate" or expand when they move away from the CM. So gravity is a lack of available power in the ZPF, and its opposite would be an increase in available power of the ZPF. Like inflating a balloon with ZPF energy. This is "exotic matter", the opposite of gravity.
Todd

#### aero

• Senior Member
• Posts: 2930
• 92129
• Liked: 784
• Likes Given: 273
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4393 on: 07/16/2015 01:53 AM »
How to help scientists gather data and study the EMDrive, even if you are an absolute novice.

If you are excited about the EMDrive and wants to contribute to its research, but don't know how, this is a step-by-step guide that if performed correctly by anyone out there interested in helping would provide valuable information for the scientists to study and better understand the EMDrive behavior.

1. Install MEEP http://ab-initio.mit.edu/wiki/index.php/Meep (preferably from your package manager)
3. meep NSF-1701.ctl
4. Eventually, MEEP will output nine .h5 files. It may take a long time depending on your computer. Patience is a virtue.
5. h5totxt -t 13 -0 -y -0  ex.h5 > zCopper-exy.csv
6. Open your zCopper-exy.csv on a spread sheet and aero's zCopper-exy.csv on another. Open a third spread sheet that is one spread sheet minus the other, entry by entry. Check that highest entry (in absolute value). If it's negligible you are good to go. If it's a value too big, greater than 10^-6, your MEEP installation isn't in sync with ours, so it's no use.
7. Now you are good to go. Make a new directory to start the tests. Copy NSF-1701.ctl there.
8. Open NSF-1701.ctl in a text editor and change a single value. For example, (set! high 10.2) means the model is 10.2 inches high. Change the 10.2 to another value and save NSF-1701.ctl with this single change. This is called sensitivity analysis. One value at a time. (set! high 10.2) was just an example, change any value of interest
9. meep NSF-1701.ctl
10. h5totxt -t 13 -0 -y -0  ex.h5 > zCopper-exy.csv
11. Compare your new zCopper-exy.csv with your old one. See if there was any relevant change (do the spreadsheet comparison again). If there was no considerable change in values, it means the modification made doesn't impact the behavior of the EMDrive. This is an important information for scientists, so let us know. Otherwise, if there was a significant change, let us know if it was positive or negative and its intensity. If you don't know how, just upload the .h5 files somewhere and we will analyze it.

FYI, I've begun down this path.  Gave up trying to get RPM packages with all the right versions to work together, and installed Debian 8.  Am running on a dual quad-core Xeon in VMware, allocated 2 processors x 2 cores each, but I see it's only really using 1 cpu (which is maxed out, purely user space cpu time as expected).  6GB memory allocated, but it's only using a shade more than 3GB for the meep process.  Have not investigated the MPI alternatives, as I think those are more intended for clusters than symmetric multiprocessors.

It's presently up to step 1339 of its first run through NSF-1701.ctl.  Has about 57 min of cputime so far.  3 *.h5 files produced so far.

I'll work my way through your steps above and report results when I have them.

You need MPI in order to make use of more than one core. You seem to be running serially on one cpu and it is taking a long time. Allocating 2 processors is quite adequate for the NSF-1701 problem, it is not so large as to benefit from more than 2 processors, (a little benefit, but very little). But without MPI, meep can't work with the second processor. I run that problem, all 6527 timesteps, in 1 hr. 33.9 minutes (5635.3 seconds) on my AMD Phenom quad core. (2.9 GHz).

Xeon in VMware - Your Xeon is very likely a better processor than mine, and as I understand it, the virtual box imposes surprisingly little overhead for this problem. I urge you to take the step of installing Open MPI or MPICH, MIT's version of MPI. You will be rewarded by significantly better run time. It won't cut the run time in half, but it will reduce it a lot.
Retired, working interesting problems

#### cuddihy

• Full Member
• Posts: 831
• Liked: 152
• Likes Given: 165
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4394 on: 07/16/2015 01:55 AM »

* In my idea book I have a sketch of a unique nuclear reactor.  It uses an accelerator to fire high energy electrons into a Tungsten target that fires high energy protons into Thorium and Beryllium fuel rods.  Be + 1.5 MeV photon = 1 neutron + 2 4He... 4Be + n = 2 4 2He + 2n ... 4Be + 4 2He =  12 6C + n ... Thorium + n = U233.  U233 Fission = Power for the mothership.

This is the only nuclear reactor I know of that a.) can be bought/built by Greene on the street and b.) you can turn on, i.e. make hot, once you are in orbit and safely out of the purview of NEST, the IAEA, etc.  Until you set it off the components are safe**.

** Ok, you aren't going to put Beryllium in your kids crayons, but it's still "safe" compared to your average nuclear reactor fuel rod.

*** I don't know if this works from a neutron economy POV,  It's just another idea in the book until I do that research. The EmDrive comes first.
I  could see how it would work from a neutron economy, you could probably get the geometry needed...once. As soon as neutrons start producing lots of hot Helium and irradiated Carbon though, the matrix will expand rapidly and the He will cause leaks.
That's what my nuclear gut says ;-)
« Last Edit: 07/16/2015 01:56 AM by cuddihy »

#### Eer

• Full Member
• Posts: 284
• Liked: 144
• Likes Given: 138
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4395 on: 07/16/2015 02:01 AM »
How to help scientists gather data and study the EMDrive, even if you are an absolute novice.

If you are excited about the EMDrive and wants to contribute to its research, but don't know how, this is a step-by-step guide that if performed correctly by anyone out there interested in helping would provide valuable information for the scientists to study and better understand the EMDrive behavior.

1. Install MEEP http://ab-initio.mit.edu/wiki/index.php/Meep (preferably from your package manager)
3. meep NSF-1701.ctl
4. Eventually, MEEP will output nine .h5 files. It may take a long time depending on your computer. Patience is a virtue.
5. h5totxt -t 13 -0 -y -0  ex.h5 > zCopper-exy.csv
6. Open your zCopper-exy.csv on a spread sheet and aero's zCopper-exy.csv on another. Open a third spread sheet that is one spread sheet minus the other, entry by entry. Check that highest entry (in absolute value). If it's negligible you are good to go. If it's a value too big, greater than 10^-6, your MEEP installation isn't in sync with ours, so it's no use.
...

FYI, I've begun down this path.  Gave up trying to get RPM packages with all the right versions to work together, and installed Debian 8.  Am running on a dual quad-core Xeon in VMware, allocated 2 processors x 2 cores each, but I see it's only really using 1 cpu (which is maxed out, purely user space cpu time as expected).  6GB memory allocated, but it's only using a shade more than 3GB for the meep process.  Have not investigated the MPI alternatives, as I think those are more intended for clusters than symmetric multiprocessors.

It's presently up to step 1339 of its first run through NSF-1701.ctl.  Has about 57 min of cputime so far.  3 *.h5 files produced so far.

I'll work my way through your steps above and report results when I have them.

You need MPI in order to make use of more than one core. You seem to be running serially on one cpu and it is taking a long time. Allocating 2 processors is quite adequate for the NSF-1701 problem, it is not so large as to benefit from more than 2 processors, (a little benefit, but very little). But without MPI, meep can't work with the second processor. I run that problem, all 6527 timesteps, in 1 hr. 33.9 minutes (5635.3 seconds) on my AMD Phenom quad core. (2.9 GHz).

Xeon in VMware - Your Xeon is very likely a better processor than mine, and as I understand it, the virtual box imposes surprisingly little overhead for this problem. I urge you to take the step of installing Open MPI or MPICH, MIT's version of MPI. You will be rewarded by significantly better run time. It won't cut the run time in half, but it will reduce it a lot.

Indeed - I'll do so.  Run just completed and it took quite a while serialized to one CPU, as you said.

And, having run the comparison, we're out of sync.  I used the apt-get install meep approach, and evidently that's in adequate.

I'll next turn my attention to reviewing the recompilation of everything (hmph) and will try to reproduce the reference csv with small error across all cells before moving on to trying to get an MPI version that also matches closely.

Thanks,
Ed
« Last Edit: 07/16/2015 02:30 AM by Eer »

#### rfmwguy

• EmDrive Builder (retired)
• Senior Member
• Posts: 2166
• Liked: 2684
• Likes Given: 1124
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4396 on: 07/16/2015 02:15 AM »
...
There is an imbalance in the cosmos which classical physics has failed to resolve. Gravity and its antithesis; a counterbalance to the only known force without a repulsive state. While I surmise em radiation has a counterbalance for CoE and may not directly produce thrust, gravity has zero, zip, nada CoE. This leaves us an opening to explore. Definition of this force is still in the "duh" phase. While I think no new physics are needed to resolve it, it remains unresolved because an old master failed to grasp it. So try this one for size; gravity is weak and extends to a cosmic scale. For every instance of gravity, a weak cosmic force equal to it is created. Failure to accept this theory leads to the opposite of what the universe is doing right now. So DM, time to define this force...perhaps its the only real explanation for what people are reporting. c'mon dm, you can do it!

I'll even get you started

g = GM/r2

Write its equivalent opposite equation. Forget that 5th force thing

https://en.m.wikipedia.org/wiki/Fifth_force

(Crickets)

x = r2/GM

The "balance" or symmetry of gravity is that for any quantum harmonic oscillator in it's ground state, the power radiated by the oscillator TO the ZPF is equal to the power absorbed by the oscillator FROM the ZPF.

Gravity depends on gradient in the available power of the ZPF. Particles "contract" as they fall toward the CM and into a gravity well. They also "inflate" or expand when they move away from the CM. So gravity is a lack of available power in the ZPF, and its opposite would be an increase in available power of the ZPF. Like inflating a balloon with ZPF energy. This is "exotic matter", the opposite of gravity.
Todd
So we have someone willing to address this classical question. Well done warptech. Let's explore how we can invoke an imbalance between g and x. You may do this far quicker than my synapses fire. Here's why I say this, its what I expect to have left over after eliminating other possibilities. Its the missing link of GUT...giving away some working theories of mine, if thrust appears, I predict it will differ towards and away from a gravitational source. Interested? Hope so...its a hot potato subject you know.
« Last Edit: 07/16/2015 02:17 AM by rfmwguy »

#### Notsosureofit

• Full Member
• Posts: 659
• Liked: 707
• Likes Given: 1394
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4397 on: 07/16/2015 02:26 AM »
Its the missing link of GUT...giving away some working theories of mine, if thrust appears, I predict it will differ towards and away from a gravitational source. Interested? Hope so...its a hot potato subject you know.

I would have to agree, the gravitational dispersion would add or subtract with the direction of the cavity.

#### WarpTech

• Full Member
• Posts: 1374
• Do it!
• Vista, CA
• Liked: 1426
• Likes Given: 1894
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4398 on: 07/16/2015 02:33 AM »
So forget about Phase Velocity when dealing with EM waves inside a waveguide.

I've yet to find any use for the Phase Velocity.  I had a brief thought that obscene >> c values might cause some issues due to charges or magnetic fields being unable to rearrange fast enough in the material, but I intuit that should cause localized heating, not thrust.

Phase Velocity, inside a waveguide, is above c and is imaginary.

http://www.microwaves101.com/encyclopedias/waveguide-mathematics#velocity

Any reference or belief that anything inside a waveguide travels at Phase Velocity (greater than c) is just plain wrong and a failure to understand basic microwave waveguide engineering and physics.

TT, I think you resolved my confusion anyway. From Cullen, you posted,

F = (2*P/c)*(λog),

You also posted,

λg = λo/sqrt(1 - (λoc)2),

and

vg = c*sqrt(1 - (λoc)2),

Substituting these into the force equation gives,

F = 2*P*vg/c2,

which gives 2*P/vp,  or F*vp = 2*P,

In other words, it is the rocket equation, "the same" as it is for matter, not different as I was thinking it was. What is different is that dw/dk =/= dE/dp but rather E/p, and that still perplexes me.
Todd

#### deltaMass

• Full Member
• Posts: 955
• A Brit in California
• Liked: 671
• Likes Given: 275
##### Re: EM Drive Developments - related to space flight applications - Thread 3
« Reply #4399 on: 07/16/2015 02:46 AM »

Tags: