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

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
Some time back I sent EW a paper on maintaining active tune resonance using a microwave PLL. I don't imagine anyone here has the resources for that, though. Which is why using very high Q is going to be problematic.

Which is why I will be using active frequency control based on monitoring the real time VSWR from my Rf amp and constantly adjusting frequency (in +-1kHz steps) for lowest VSWR, which will keep my frequency right in the middle of the cavity sweet spot, even if it heats up and moves around a bit.
Excellent. Using a PID?

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Hi all - been watching for 6 mos - I'm a former Aero CFD developer / researcher with a background in MechE / Aero Astro and Big Data / Data Science.

+1 for putting the Meep ctls and results on Git with open read access and moderated commits.

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.

To help people like me contribute, perhaps this list can develop a set of parameter study requests that you can post on the wiki and people can register that they are running some parts of it and post results into the Git repo?

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
I'm in the process of setting up git with gitolite3 (user management tools) and cgit (a web interface) on my server.  This means that anyone who wants commit access should send me their SSH public key(s) via PM.  You will then be able to access the repository with passwordless SSH transport, with the initial command being "git clone [email protected]:emdrive" to get a local copy.  Having multiple keys for different machines is totally fine.

@Rodal
If Mathematica can't handle shelling out to non-interactive git commands but can handle http, cgit will expose everything over passwordless http, so you don't have to worry about manually typing passwords in either case.  I'm also configuring cgit so it should use nice URL paths instead of a million & clauses.  When it's ready, it will be accessible at http://git.emdrive.science/.  You can even script automatic uploads via "git add", "git commit", and "git push".

@leomillert
Feel free to do periodic clones of the repository on emdrive.wiki, or wherever else you like.  Everything will be open to the public via the web.  By software licensing convention, adding a comment to the head of each control file explicitly stating that the file is public domain is enough to make it so.  I've also added a redirect from http://emdrive.science/wiki to http://emdrive.wiki for ease of discoverability.

@notarget
GPU Meep sounds excellent in the general case, but I'm not sure how much our particular use case of meep can be parallelized.  It's already hitting the limits of Amdahl's Law - going from eight CPU threads to twelve CPU threads only saves about ten minutes on my machine (50% more threads = 22% less time).  This is somewhat expected since it's modeling the behavior of a system over time - every step depends on the output of the step before it.
« Last Edit: 07/20/2015 08:46 pm by tidux »

Offline rfmwguy

  • EmDrive Builder (retired)
  • Senior Member
  • *****
  • Posts: 2205
  • Liked: 2713
  • Likes Given: 1134
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Hi all - been watching for 6 mos - I'm a former Aero CFD developer / researcher with a background in MechE / Aero Astro and Big Data / Data Science.

+1 for putting the Meep ctls and results on Git with open read access and moderated commits.

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.

To help people like me contribute, perhaps this list can develop a set of parameter study requests that you can post on the wiki and people can register that they are running some parts of it and post results into the Git repo?
For the record, all the dimensions and configuration of my NSF-1701 project is open-source for non-commercial use and gladly offered to interested parties.

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
@notarget
GPU Meep sounds excellent in the general case, but I'm not sure how much our particular use case of meep can be parallelized.  It's already hitting the limits of Amdahl's Law - going from eight CPU threads to twelve CPU threads only saves about ten minutes on my machine.  This is somewhat expected since it's modeling the behavior of a system over time - every step depends on the output of the step before it.

@tidux
We'll see - not to consume this thread's BW on it too much, the short answer is that a GPU port is straightforward fine grained parallelism.  The case we're running fits in GDDR on a K20/K40 card easily, and so we can run thousands of threads on it in a manner for which GPUs are designed, not dissimilar from using a Cray's 256-deep vector units.  There is ample evidence for speedups in the 10x range IMO, enough that I'll go after it.  I've also done a *lot* of work with MPI on large (1000+ node) machines, and understand Amdahl's law quantitatively in that regard - latencies of a couple of (us) are enough to kill things.

OTOH - I think both getting Rodal some qualitative visualizations and some parameter studies WRT antenna placement and / or geometries could be useful to flesh the EM drive out.  We're all missing something WRT understanding the behavior IMO - ISTM that Traveller's theories of dissipative behavior [sic] can be studied using numerical experiments...

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
...We're all missing something WRT understanding the behavior IMO - ISTM that Traveller's theories of dissipative behavior [sic] can be studied using numerical experiments...
Welcome to the thread ! :)

It's great to have somebody that is familiar with CFD analysis in the thread. 

Traveller closely follows Shawyer, and Shawyer says that all that is required is Classical Physics (Maxwell's equations and Special Relativity) and no external fields are required to explain the EM Drive's behavior.  Maxwell's equations and Special Relativity can be completely modeled with numerical experiments.

White and McCulloch invoke the Quantum Vacuum.  That can also be studied using numerical experiments, but it requires writing a routine invoking the external QV field and possibly other constitutive equations.  That can also be modeled numerically (White is studying it numerically).  Meep is an open source code, most Meep users that write papers using Meep write their own routines rather than using it as a black box. 

In my calculations I'm using Meep's electromagnetic fields as an input, I perform all the stress calculations externally, using Wolfram Mathematica.

At this point, I think that the transient problem can be much better handled with an unconditionally stable FD time-domain operator rather than the conditionally-stable central difference FD time-domain operator used by Meep that constraints the solution to extremely small time steps and hence huge running times.  If I get the time I may write a code to do that.  I'll wait to see what happens with rfmwguy and SeeShell's experiments to dedicate the time to do that. 

At this point it is not even clear whether the EM Drive is an experimental artifact or whether it is something that can be used for space propulsion.  It is not just the conservation of momentum problem, but Frobnicat and deltaMass have argued strongly that there are some powerful constraints related to conservation of energy that severely restrict what is being claimed.
« Last Edit: 07/20/2015 09:48 pm by Rodal »

Offline ElizabethGreene

  • Member
  • Posts: 69
  • Nashville, Tennessee
  • Liked: 138
  • Likes Given: 3
I wonder if a space launch platform lifted by EmDrives could be powered by microwaves emitted from the ground. Instead of converting the microwaves to electric power onboard through lossy rectennas, the microwaves would be directed into the cavities. No electric conversion!

Possible, yes.  Depending on the width of the beam it can also make a lovely beacon off into space for ET to home in on.

The applications for EmDrive technology is stunning.  Here's one I sketched in my idea book last week...

The (current) fatal flaw with a Space Elevator is that we lack materials strong enough to construct it.  There is a huge compression load during construction followed by tension load when the counterweight goes up.  If it works out that superconducting emdrives are capable of high static thrust but really bad at acceleration (i.e. what Mr. Shawyer described in his old superconducting cavity paper) then we can use ground-powered emdrives to construct a space elevator.  During construction the drives hold the cable up and are powered by microwaves pointed up from the ground.  When Centripetal acceleration starts to pull the cable then we reverse the drives (flip them from pointed up to pointed down) to keep the tension on the cable within engineering limits.

Once the elevator construction is complete we put an orbital power station on top of it and power it from the top down through superconducting cables piped down from the top.  (I don't want to fire the energy downward from orbit because people might take poorly to being irradiated with megawatts of microwaves from space.)

The flaw in the last bit is that in geostationary orbit it'll be dark half the time.  That means it will provide base generation capacity during the day and base load at night. 

In my perfect-not-bounded-by-laws-of-physics-or-economics world we also attach vertical piping to the cable from the earth to the orbital platform.  A relatively tiny earthborne compressor can send up hydrogen and oxygen to the orbital platform.  Converting them to LOX and LH2 in orbit gives you dirt-cheap reaction mass right where you want it, in high orbit next to the orbital starship construction facility.

... back of the envelope numbers for a 35Gm orbit
2" Cabling: 400,000 Tons of steel
Cost of cabling alone: $118B

For scale, the entire shuttle program clicked out at $209B.

On the other hand, what is the value of being able to place thousands of tons in orbit every day?  Not everything has to run all the way out to geo if you have leo golf-carts to delta-v payloads up to speed from a cable mounted launch platform.

"Emdrive technology has the the same potential to change human civilization as radically as the invention of the printing press, the steam engine, and the transistor." -me

Offline ElizabethGreene

  • Member
  • Posts: 69
  • Nashville, Tennessee
  • Liked: 138
  • Likes Given: 3

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.


GPU support is abstracted off into the Linear algebra libraries (BLAS).  If you install the GPU versions of those then ./configure should find them and off you go.

Cluster support is via the MPI framework and is also baked in.

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9

At this point, I think that the transient problem can be much better handled with an unconditionally stable FD time-domain operator rather than the conditionally-stable central difference FD time-domain operator used by Meep that constraints the solution to extremely small time steps and hence huge running times.  If I get the time I may write a code to do that.  I'll wait to see what happens with rfmwguy and SeeShell's experiments to dedicate the time to do that. 

I looked briefly at the recent history of CEM FDTD stuff post-Taflove and see that people have done some work with implicit formulations, but I'm not sure how effective they are at really increasing CFL.  As you know with CFD, the implicit methods don't improve things much for transient analysis when linearized and the fuller matrix solvers are too expensive for the benefit.

For this case are we suffering from not enough time for evolution of the behavior?  How much time do we need to get a meaningful qualitative view?

One thing I'd like to do is just walk through the E/B fields with Fieldview or another decent viz tool (wish I still had access to AVS or Ames' FAST) and get a feeling for the cycles and interactions and also a quality assessment of the simulation.  Any suggestion for a good OSS 4D capable visualization tool?

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
http://home.penglab.com/proj/vaa3d/home/index.html

Supposedly this can do 4D and 5D visualizations of data.  Is this what you were looking for, notarget?

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564

At this point, I think that the transient problem can be much better handled with an unconditionally stable FD time-domain operator rather than the conditionally-stable central difference FD time-domain operator used by Meep that constraints the solution to extremely small time steps and hence huge running times.  If I get the time I may write a code to do that.  I'll wait to see what happens with rfmwguy and SeeShell's experiments to dedicate the time to do that. 

I looked briefly at the recent history of CEM FDTD stuff post-Taflove and see that people have done some work with implicit formulations, but I'm not sure how effective they are at really increasing CFL.  As you know with CFD, the implicit methods don't improve things much for transient analysis when linearized and the fuller matrix solvers are too expensive for the benefit.

For this case are we suffering from not enough time for evolution of the behavior?  How much time do we need to get a meaningful qualitative view?

One thing I'd like to do is just walk through the E/B fields with Fieldview or another decent viz tool (wish I still had access to AVS or Ames' FAST) and get a feeling for the cycles and interactions and also a quality assessment of the simulation.  Any suggestion for a good OSS 4D capable visualization tool?

The equations being solved (Maxwell's equations) are much simpler than the (nonlinear) Navier Stokes equations.  Maxwell's equations are linear.  The behavior is much,  much simpler than in fluid dynamics.  A cursory review of the literature shows that the algorithms being used in electromagnetism have not been at the forefront of numerical analysis  (they are much behind those used in nonlinear solid mechanics and fluid dynamics).    While for nonlinear systems of partial differential equations in the transient regime, it is true that there are limits on how much of a larger time step an unconditionally stable operator can provide, I don't see as much of a case for linear Maxwell problems like this one. 

Any way, at present aero has run about 6500 time steps to about 0.013 microseconds.  It expect that it will take 1 to 10 microseconds to reach steady state.

Also what is most needed is:

1) People to write an RF Source routine for Meep to model a magnetron, and much simpler than that just to turn -off the source: something that Todd Desiato (WarpTech) asked some time ago, but remains to be done

2) People to write a pre-processing routine to model perforated end-plates with different patterns of perforation, and/or the whole fustrum perforated as presently being tested by rfmwguy and SeeShells.
« Last Edit: 07/21/2015 12:21 am by Rodal »

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9
http://home.penglab.com/proj/vaa3d/home/index.html

Supposedly this can do 4D and 5D visualizations of data.  Is this what you were looking for, notarget?

More like this: https://wci.llnl.gov/simulation/computer-codes/visit/gallery

Generalized field visualization tools - AVS5 was the best of them IMO as you could program what was missing simply.  It turns out that it's still in use at various SC centers, but has fallen into disrepair (sigh).

Again - I'm concerned that the tools discussion shouldn't take too much site BW away from the actual work at hand.  I'll find some good tools / results and post soon.

Offline notarget

  • Member
  • Posts: 18
  • San Carlos, CA
  • Liked: 17
  • Likes Given: 9

The equations being solved (Maxwell's equations) are much simpler than the (nonlinear) Navier Stokes equations.  Maxwell's equations are linear.  The behavior is much,  much simpler than in fluid dynamics. 


Right - I thought so - couldn't think of a nonlinear EM situation apart from modeling a soliton - remembering Taflove's work...


Any way, at present aero has run about 6500 time steps to about 0.013 microseconds.  It expect that it will take 1 to 10 microseconds to reach steady state.


IC - that's a big jump - we're doing 0.013us in about 45 mins, so to get 10us is 580 hours. Ouch.

If I get 10x using GPU (looked into it, possible as code is modular and the explicit time evolution is nicely contained) we're still looking at 58 hours, which exceeds my 12 hour threshold for "worth it" simulations.  Even a cluster doing parameter studies is marginal unless we get below 12 hours per run IMO.

Also what is most needed is:

1) People to write an RF Source routine for Meep to model a magnetron, and much simpler than that just to turn -off the source: something that Todd Desiato (WarpTech) asked some time ago, but remains to be done

2) People to write a pre-processing routine to model perforated end-plates with different patterns of perforation, and/or the whole fustrum perforated as presently being tested by rfmwguy and SeeShells.

I could possibly tackle (1) WRT turning off the source - I don't know what a magnetron does exactly, though I could find out.

(2) sounds like it modifies the boundary conditions in an interesting manner - my lack of experience with CEM would be stretched here...

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Completely agree - repo should be publicly browseable, with accounts only needed for people committing.  And ignore my "Men In Black" bad joke...

If you want me to set this up on the wiki server, let me know; would just take a few minutes.

tidux will do most heavy computing,  so I think it would be better to have it set up on his emdrive.science. (but let's wait to see his opinion).
Maybe we could use the wiki to detail the structure of the repository (its folders and files), how someone can commit, etc. What do you think?

I concur on git, and suggest a clone on two sites is a good idea.  Time I learned git.

I'd still like to see a file/directory/test-run naming convention.  The hierarchy proposed is a good start down that direction, but a uniform naming convention makes sense when there are multiple providers as well as multiple consumers.

One question I have - who is expecting whom to hack on control files?  How will the modifications be validated / verified against test objectives?  I don't feel qualified, at either the lisp, the scheme, the meep script, nor scientific or engineering basis to make ANY sort of valid judgments as to how things should be coded.

@All meepers -

Two things on my mind today.

1) Interface management between Data Requesters and Meepers.

2) Reduce file output volume from meep without sacrificing usable data.

1) Interface management I have prepared a file - form that would work for me. If I received this file from wherever we choose to locate it, I believe I could make the run and produce the requested data without difficulty. It will likely need some additions including meep run time and some other details that Dr. Rodal asks for. And it needs to be changed to indicate the location we choose to use to communicate the resulting files to the requester. And it should be made pretty. I don't see any good reason to require the compete control file in this form. It is the meeper's task to translate requests for data into control files, not the requester's.

Note the request for csv file row numbers. These can be obtained from an ez.000000003.h5 file (or similar) made during a very short initial run. Such runs are necessary anyway, just to verify the antenna location if for no other reason.

2) Reduce file output volume On my computer the 6 .h5 files total 11.4 GB for 14 time slices on the NSF-1701 model run. A longer run with for example, 14 time slices every 100 cycles could quickly consume my 250 GB of available disk although I doubt I could run long enough in one day to do so. The 396 csv files only total 591.6 MB and the 252 png files only 71.9 MB so outputting them directly from meep would reduce the storage load (and file write time) by a factor of about 94%. There is the further difficulty of stopping and restarting the output which meep doesn't seem to provide by default.

I propose that someone who understands the Scheme language write two different step output functions for our use. One each for .png files and .csv files, and with internal control that can be set to output time slice data at meeper controlled intervals during a sequence of meep time windows and while keeping the time slice data files uniquely identified and saved. The only difficulty in doing this is meep and the Scheme language. It would be easy in most languages though the file naming could be a little tricky.

See this section of the Meep Reference manual.
       http://ab-initio.mit.edu/wiki/index.php/Meep_Reference#Writing_your_own_step_functions
Meep already supports direct output of the .png files without the need to save the .h5 files or post process with h5topng. (But not including the switch off/on feature.) I did not find a similar step function output using h5tocsv, but conceptually it should be straight forward to create one.

Retired, working interesting problems

Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
Here is a visualization tool, its large though.

http://www.paraview.org/Wiki/images/5/5d/ParaViewTutorial41.pdf

I have tried to use for a few hours but gave up when it got to tough. Of course software to look into a data set and extract patterns won't be simple although I was able to find the frustum embedded within a 3-D data set of EM fields. Freehand rotation of the view seemed nice and numeric and graphic field strength data and curves was interesting.
Retired, working interesting problems

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
This should also help a bit.
http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial#Output_tips_and_tricks

I also remember: when in doubt, ask the MEEP mailing list. http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss

Have you gotten a reply from the meep mailing list yet? I have received a few replies, maybe I ask dumb questions.
Retired, working interesting problems

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
...

Also what is most needed is:

1) People to write an RF Source routine for Meep to model a magnetron, and much simpler than that just to turn -off the source: something that Todd Desiato (WarpTech) asked some time ago, but remains to be done

2) People to write a pre-processing routine to model perforated end-plates with different patterns of perforation, and/or the whole fustrum perforated as presently being tested by rfmwguy and SeeShells.

I could possibly tackle (1) WRT turning off the source - I don't know what a magnetron does exactly, though I could find out.

(2) sounds like it modifies the boundary conditions in an interesting manner - my lack of experience with CEM would be stretched here...

Right now, turning off the source after 0.013 microseconds would be much more informative than running Meep up to 1 microseconds and beyond.

This is something that Todd asked many days ago: just turning off the source and seeing what happens.
« Last Edit: 07/21/2015 01:15 am by Rodal »

Offline aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
This should also help a bit.
http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial#Output_tips_and_tricks

I also remember: when in doubt, ask the MEEP mailing list. http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss

And how does that help? Tell us why it helps with the problem we have?
Retired, working interesting problems

Offline Ricvil

  • Full Member
  • *
  • Posts: 171
  • Liked: 110
  • Likes Given: 71
Beyound a source of microwave, could the magnetron coupled to cavity be acting as a amplifier too?

Tags:
 

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