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

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
My theoretical understanding of how an EMDrive works is fine
That's the problem, right there.  8)

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
Yes, there is no doubt that 32 time periods is relatively nothing.  I estimated it will take 100 to 1,000 longer time to get to steady state standing waves. 
I just started a 320 period run and I'm outputting a two period Ez file at the end with 1/50 sampling to get a better look at the wave activity - should take about 8 hours (on one four core VM).

Today I'll work on "switching off" the input source in some manner.  I do think I need to put in a "restart" capability - it isn't there by default - odd!

Offline TheTraveller

My theoretical understanding of how an EMDrive works is fine
That's the problem, right there.  8)

You still believe:

1) Momentum in a waveguide travels at Phase Velocity?

2) Cullen, Shawyer and Yang are wrong to use Guide Wavelength / Group Velocity to calculate end plate bounce Force?

3) Group Velocity / Guide Wavelength are the same at each end of the cavity?

4) Bounce Force generated at each end end plate is the same?

5) There is no Idle mode nor Motor mode nor Generator mode?

6) The EMDrive is an Over Unity device, despite seeing the rotary Power curve showing that is not so?
It Is Time For The EmDrive To Come Out Of The Shadows

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
I don't feel comfortable with cylindrical coordinates, but if someone wants to take a crack at converting the Cartesian coordinate model to a cylindrical coordinate model, here is what the documentation has to say.

http://ab-initio.mit.edu/wiki/index.php/Cylindrical_coordinates_in_Meep

There is likely more information posted on the internet if it can be found.

If you'd like to try it but don't have access to meep, here is a solution prepared for us by Quixote who's day job is software engineer and systems administrator for a rather large (very large) corporation in Silicon Valey, CA. First step, read the instructions, then follow them.

https://drive.google.com/folderview?id=0B91RvuTQIsPkfkFvdGlVelRRX2xwTXVlTHB4LWU2b1FEUlVPUDQtVEJxcHJlNC1LYzB3bU0&usp=drive_web

I logged on my Ubuntu OS and logged back on to my Windows 7 OS, followed the instructions and now have Meep running in a virtual machine on Windows. It doesn't run quite as fast as my meep code running on bare metal under Ubuntu OS, but it is significantly faster than the downloaded pre-compiled debian meep package. And it is completely up to date running Meep 1.3. something 1.3.0.11 I think, it includes the integrated MPB capability, MPB stand-alone, HDFview and the rest, all current, freshly compiled from source this month (july, 2015).

There will be some questions, but they should be few, and the same area, so ask, I probably have already asked them, but if not will be able to find answers.

I am posting this so that all of you theorists can easily run meep to look into your own area of interest without becoming S/W engineers, so go for it. I'm sure the meepers here will help you with running it after you have it available.
« Last Edit: 07/21/2015 06:19 pm by aero »
Retired, working interesting problems

Offline flux_capacitor

  • Full Member
  • ****
  • Posts: 708
  • France
  • Liked: 860
  • Likes Given: 1076
I plan to work on a GPU port of Meep to get it running 10x faster and have a cluster of machines on which I can / will run experiments as requested or available to help with the parameter studies and fundamentals.

Just curious, will you use CUDA or OpenCL ? CUDA only works with NVIDIA GPUs (proprietary), while OpenCL works with NVIDIA, AMD or Intel GPUs.

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
I don't feel comfortable with cylindrical coordinates, but if someone wants to take a crack at converting the Cartesian coordinate model to a cylindrical coordinate model, here is what the documentation has to say.

Hey "aero" - meep's cyl coordinates are for 2D calculations using rotational symmetry.  Since we have 3D spatial variation, that wouldn't work for us here...

In order to fix meep's reduction to first order accuracy at boundaries due to the use of "stair step" geometry, we'd need to implement a new kernel based on the maxwell equations transformed into generalized curvilinear coordinates - or perhaps into an analytical spherical coordinate transformation if we're only going to model sections of a sphere... But then we'd have to have the input source conform to the analytic spherical coordinates.  I'd prefer the generalized transform.  This is not easy to do - though there's precedent for it and similarities to CFD methods, etc to draw upon.

In the meantime - the meep formulation has some advantages - it's quick and simple, but as Rodal points out - we have to watch out for being misled on the quantitative accuracy of the simulations.  A convergence study, where we'd validate that we are accurate - should show that we need to increase the density linearly to get more accurate results - a bummer in that better conformal methods have 2nd order (faster) grid convergence.

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
Just curious, will you use CUDA or OpenCL ? CUDA only works with NVIDIA GPUs (proprietary), while OpenCL works with NVIDIA, AMD or Intel GPUs.
Ideally I'd work with OpenACC in the gnu compiler - or potentially just generate code using llvm and nvvm, which allows for interoperability among systems.

In this case - the most expedient way to go is with Cuda on Nvidia - I have a K20 and some Titan-X cards lying around and can use that quickly.  The memory used by this case and resolution appears to be about 4GB, so would fit in GDDR.

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
I plan to work on a GPU port of Meep to get it running 10x faster and have a cluster of machines on which I can / will run experiments as requested or available to help with the parameter studies and fundamentals.

Just curious, will you use CUDA or OpenCL ? CUDA only works with NVIDIA GPUs (proprietary), while OpenCL works with NVIDIA, AMD or Intel GPUs.
What about openblas?
Retired, working interesting problems

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
I don't feel comfortable with cylindrical coordinates, but if someone wants to take a crack at converting the Cartesian coordinate model to a cylindrical coordinate model, here is what the documentation has to say.

Hey "aero" - meep's cyl coordinates are for 2D calculations using rotational symmetry.  Since we have 3D spatial variation, that wouldn't work for us here...

In order to fix meep's reduction to first order accuracy at boundaries due to the use of "stair step" geometry, we'd need to implement a new kernel based on the maxwell equations transformed into generalized curvilinear coordinates - or perhaps into an analytical spherical coordinate transformation if we're only going to model sections of a sphere... But then we'd have to have the input source conform to the analytic spherical coordinates.  I'd prefer the generalized transform.  This is not easy to do - though there's precedent for it and similarities to CFD methods, etc to draw upon.

In the meantime - the meep formulation has some advantages - it's quick and simple, but as Rodal points out - we have to watch out for being misled on the quantitative accuracy of the simulations.  A convergence study, where we'd validate that we are accurate - should show that we need to increase the density linearly to get more accurate results - a bummer in that better conformal methods have 2nd order (faster) grid convergence.

Well, yes but when the antenna is on the axis of rotation and either a point source or axial in length, the frustum is rotationally symmetric. Meep also allows specification of mirror symmetry which reduces run time significantly but does not address the granularity issue. But while on this topic, note that the granularity issue is not as severe as the images would have us believe. Within the computational lattice there are ~200 pixels between the ends of the cavity. The images make it appear as though there are about 20 stair-steps, when in reality there are about 200. Probably still a large discontinuity for bouncing EM waves but really only about (Big radius - Small radius)/200 per discontinuity.

That comes out to be ( (11.01 in inches /2) - (6.25 inches /2)  ) / 200 discontinuities = 0.0119   inch/discontinuity or 0.00030226 meters/discontinuity. Pretty rough surface though it is further smoothed by eps averaging use in meep.

« Last Edit: 07/21/2015 06:48 pm by aero »
Retired, working interesting problems

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
What about openblas?
BLAS isn't used here - the curl evaluations are hand coded.  The main issue is yo avoid copying in and out of GPU memory, so in concept it's simple: copy all field data into GPU and run loops there.

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
If it's about accelerating simulations, couldn't we theoretically try and make something like the SETI client and distribute prepared packages to those willing to donate CPU time to simulate a ton of EM drive configurations - even over longer periods of time and operation?
We could make a MEEP Docker package that gets the data either from the Google drive or the Git repo. Anybody with  a Windows, Mac, or Linux box can run it.

Docker is still Linux, so you'd still have Linux VM overhead on Windows and OS X.  It's not an OS-independent lightweight VM like the JVM or Parrot.  It's just a bit smaller than VirtualBox, and mostly meant for prototyping web apps on developers' laptops, not CPU-intensive scientific computing like meep.
http://docs.docker.com/installation/windows/

http://docs.docker.com/installation/mac/

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
If it's about accelerating simulations, couldn't we theoretically try and make something like the SETI client and distribute prepared packages to those willing to donate CPU time to simulate a ton of EM drive configurations - even over longer periods of time and operation?
We could make a MEEP Docker package that gets the data either from the Google drive or the Git repo. Anybody with  a Windows, Mac, or Linux box can run it.

Docker is still Linux, so you'd still have Linux VM overhead on Windows and OS X.  It's not an OS-independent lightweight VM like the JVM or Parrot.  It's just a bit smaller than VirtualBox, and mostly meant for prototyping web apps on developers' laptops, not CPU-intensive scientific computing like meep.
http://docs.docker.com/installation/windows/

http://docs.docker.com/installation/mac/

Virtual Box overhead is not nearly as severe as the overhead of a downloaded pre-compiled package. My timing runs show it to have only 3% to 10% overhead compared to a fresh compile on my target machine.

The downloaded Debian package has about 28% overhead compared to the same fresh compile on my target machine. That is, the timing run used to take 2400 seconds using the pre-compiled download, but after compiling from source, it takes 1875 seconds wall clock.

Retired, working interesting problems

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
I wrote my own program to side-step these issues with Meep:

1) I compute the standing wave steady state solution with  RF feed OFF

2)  Computing time: under 1 minute

3) Boundary Conditions: satisfied exactly on the conical boundary (no staircase effect).  Lack of vertical wall is due to the fact that there is no field outside the brim of the hat.  The jagged vertical wall in the Meep output is a numerical artifact of the Finite Difference solution.

4) I confirm that for Yang/Shell, the mode shape calculated by Meep/Post-Processed by Wolfram Mathematica is TM113.  I calculate a natural frequency for this mode shape of 2.4941 GHz

5) I confirm that the "Mexican Hat" shape for the stress calculated by Meep at the Small Base is correct

6) At the Big Base, with the RF Feed off there is another Mexican Hat shape at the Big Base, but this Mexican Hat is squashed: it is a "Pancake" due to the much smaller magnitude

7) I confirm Meep/Post-Processed by Wolfram Mathematica result that the stress on the big base is smaller than the stress in the small base

8) I confirm that the central bulge in the stress at the big end calculated by Meep/Post-Processed by Wolfram Mathematica is due to the antenna in close proximity with the big base.  This central bulge disappears upon turning the RF feed off.

9) Pay no attention to the vertical numerical values for the stresses I just calculated, I still have to work on computing the power scaling.

I show below first the steady state stresses

and below, the previously computed stresses at 0.013 microseconds by Meep/Post-Processed by Wolfram Mathematica
« Last Edit: 07/21/2015 07:45 pm by Rodal »

Offline X_RaY

  • Full Member
  • ****
  • Posts: 852
  • Germany
  • Liked: 1146
  • Likes Given: 2479
Another thougth.

upon reflection light undergoes a 180 degree phase change on metal surfaces

BTW http://forum.nasaspaceflight.com/index.php?topic=37642.msg1403569#msg1403569  :D
« Last Edit: 07/21/2015 07:45 pm by X_RaY »

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
I show below first the steady state stresses and below, the previously computed stresses at 0.013 microseconds by Meep/Post-Processed by Wolfram Mathematica
Qualitatively these look very similar which is/was encouraging! Also - the stairstep boundary conditions on meep actually seem to be OK - note the shape of the stress function as it approaches the wall seems smooth and similar to the analytical standing wave solution.

What I want to see is some of the qualitative behavior surmised by some (Traveler I think?) where the wave dissipates into the big end, aliasing into the wall as dissipation (ultimately) into thermal energy, creating a kind of momentum sink.  If I understand correctly - we would need to model the dissipative wall effects in meep explicitly in the boundary condition, as this isn't a "multi-physics" package as was pointed out.  We'd have whatever surface currents exist in the walls creating a dissipation into heat based on material characteristics, certainly do-able.

Do I have this right? Is it important in the presumed phenomenology?

Offline Ricvil

  • Full Member
  • *
  • Posts: 171
  • Liked: 110
  • Likes Given: 71
Another thougth.

upon reflection light undergoes a 180 degree phase change on metal surfaces

Yes, and this situation is modeled by a traveling wave with reverse propagation and exactly 180 degrees of phase difference producing a destructive interference exactly at the mirror position.
With two mirrors one has to satisfy the destructive interference at two points simultaneously, and this condition defines the possibles modes on "cavity".
This is a example of superposition  principle to model boundary conditions.
« Last Edit: 07/21/2015 08:19 pm by Ricvil »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
I show below first the steady state stresses and below, the previously computed stresses at 0.013 microseconds by Meep/Post-Processed by Wolfram Mathematica
Qualitatively these look very similar which is/was encouraging! Also - the stairstep boundary conditions on meep actually seem to be OK - note the shape of the stress function as it approaches the wall seems smooth and similar to the analytical standing wave solution.

What I want to see is some of the qualitative behavior surmised by some (Traveler I think?) where the wave dissipates into the big end, aliasing into the wall as dissipation (ultimately) into thermal energy, creating a kind of momentum sink.  If I understand correctly - we would need to model the dissipative wall effects in meep explicitly in the boundary condition, as this isn't a "multi-physics" package as was pointed out.  We'd have whatever surface currents exist in the walls creating a dissipation into heat based on material characteristics, certainly do-able.

Do I have this right? Is it important in the presumed phenomenology?

What you are saying is correct, including modeling the dissipative effects.  I understand that Aero has modeled the wall as a Perfect Meep metal and also using a Drude model in Meep with numbers suggested by deltaMass but that the Drude model made no difference.

I don't understand why you refer to TheTraveller concerning the dissipative effect at the wall :)

My understanding, IMHO TheTraveller follows Shawyer, nothing extra is needed:

are you referring to the "motor" and "generator" effect described by Shawyer?

or are you referring to TheTraveller instead of Todd Desiato "WarpTech" who suggested dissipation as important to the problem?
« Last Edit: 07/21/2015 10:44 pm by Rodal »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
1) I have confirmed that the fact that the stress is much higher at the small base than the big base for Yang Shell has nothing to do with the RF feed being on.  It is due to the standing waves

2) I don't understand at the moment how these forces are going to be balanced in the conical lateral walls.  That's one of the reasons that I wrote my own code to examine this.  I am going to examine what is happening with the stress at the conical walls.

3) It seems to me that to balance the greater force at the small end, the stress at the conical walls has to be a suction instead of a pressure (in order to give an axial component to balance the forces) or else there has to be a huge shear force to balance the greater force at the small end

4) I understand that Coulomb forces due to the Magnetic Field producing eddy currents can result in a suction force.

5) Regardless of the nature of the suction/and/or/shear stress necessary to balance the forces at the ends. I propose that it may be very easy to disrupt these forces.  It seems to me that it may be much easier to maintain pressure than suction, and to maintain pressure than shear. 

WARNING: not a well-formed idea follows:

6) Perhaps the "ratcheting" effect of the EM Drive is all due to the momentary disruption of these boundary conditions.  In other words: set-up an electromagnetic field whereby there is greater force at the small end than the force at the big end. If the pressure at the small end is much greater, this has to be counterbalanced by a suction and/or shear on the conical lateral walls.  While it may be possible to have suction and/or/shear due to the Magnetic field and eddy -currents,  it may be easy to disrupt them, hence the ratcheting effect.  It would be like disrupting boundary conditions in a submarine propeller with cavitation or disrupting the no-slip boundary condition in a fluid-elastic viscous flow (in this last case, resulting in stick-slip at the boundary oscillating between plug flow and viscous flow).
« Last Edit: 07/21/2015 08:35 pm by Rodal »

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
@Rodal
Yah - It's Todd's theory I'm referring to - sorry to be responding by phone leading to mis-attribution :-)

OK - I will look up Aero's prior oosts on wall...

Offline VAXHeadroom

  • Full Member
  • **
  • Posts: 209
  • Whereever you go, there you are. -- BB
  • Baltimore MD
  • Liked: 287
  • Likes Given: 173
The Space Show will have Dr. Jim Woodward on tonight.

 Tuesday, July 21, 2015; 7-8:30 PM PDT (10-11:30 PM EDT; 9-10:30 PM-1 PM CDT): We welcome DR. JJIM WOODWARD back to the show to update us on his work with a Mach effect drive impulse engine- and gravitational physics.

http://www.thespaceshow.com/
Emory Stagmer
  Executive Producer, Public Speaker UnTied Music - www.untiedmusic.com

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
0