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

Online Eer

  • Full Member
  • ****
  • Posts: 624
  • Liked: 466
  • Likes Given: 913
I'll try to write a step-by-step guide soon so others can do what I am doing in order to provide more data to the scientists.

@leomillert (and @aero, @dumbo, et al.) - I started this page: http://emdrive.wiki/MEEP - please document your setup steps there, so folks can set up a new environment, compile MEEP, execute the .ctl file, and postprocess the CSVs as needed.  And it would be great to put your .ctl file up on, say, Github and link to it as well.

Perhaps @dumbo could also share his Amazon AMI with MEEP set up? 

I suspect there are a lot of lurkers out there who would like to lend a hand in these areas.

I'm interested, too.  I know there was a message a ways back up list detailing things, but a README or Setup Dependencies section on that Wiki page would be a better place to record:

What version of MEEP?
Windows or just Linux versions?  Separate pointers to each setup section, as they're different.
What versions of which RPM/tar.gz/whatever packages for each dependency
Installation sequence
Recommended configure options to tailor facilities.

Then - how much process memory / system memory required?
Is it thread safe and if so, how many threads can be allocated usefully (may be result of trial and error)

And of course, a section on parallel / cluster installs - what API sets, and whether the scripts are already setup for distributed partition of the various sets (unlikely) or not - that's likely to be an area of some "fooling around" in any event.

Thanks
From "The Rhetoric of Interstellar Flight", by Paul Gilster, March 10, 2011: We’ll build a future in space one dogged step at a time, and when asked how long humanity will struggle before reaching the stars, we’ll respond, “As long as it takes.”

Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
Quote
What version of MEEP?
I am using MEEP 1.3 with libctl 3.2.2, Guile 2.0.11, Harminv 1.4 and OpenBLAS 0.2.12
HDF5 is version 1.9.224 and h5utils is 1.12.1

Quote
Windows or just Linux versions?  Separate pointers to each setup section, as they're different.
I am using Linux

Quote
What versions of which RPM/tar.gz/whatever packages for each dependency
I installed everything except OpenBLAS from source, compiled myself. It was really tricky, so I strongly recommend people to see first if their distribution has MEEP pre-packaged.

Quote
Installation sequence
http://ab-initio.mit.edu/wiki/index.php/Meep_Installation

Quote
Then - how much process memory / system memory required?
I didn't benchmark, but on my old laptop, it took around 5 hours for MEEP to finish the simulation and output the .h5 files.

Quote
Is it thread safe and if so, how many threads can be allocated usefully (may be result of trial and error)
No idea.

Quote
And of course, a section on parallel / cluster installs
I think MPI covers all this.
http://ab-initio.mit.edu/wiki/index.php/Meep_Installation#MPI_.28parallel_machines.29

-------------------------------------------------------------------------------------------------------------------------------------------

In the end, I believe hunting down each program to the same exact version and same exact configuration is too hard to justify it.
My suggestion is to just install MEEP from your package manager, run NSF-1701.ctl and compare the output (converted to .csv) with either mine or aero's. If the difference is negligible, you are good to go. If it's non-negligible, then it's a good time to hunt down what's causing the difference.

-------------------------------------------------------------------------------------------------------------------------------------------

@saucyjack
I think you have the right idea in mind. By documenting everything, anyone can install MEEP, change a single value on the NSF-1701 model and provide useful results for the scientists to further analyze.

« Last Edit: 07/14/2015 11:20 pm by leomillert »

Offline WarpTech

  • Full Member
  • ****
  • Posts: 1407
  • Do it!
  • Statesville, NC
  • Liked: 1453
  • Likes Given: 1925
Building and thinking...of the 4 known fundamental forces, only gravity is assymetrical, meaning it is only attractive and cannot be repulsive. We have a problem here...CoE. with no cosmic balance, no conservation, the universe collapses...rapidly...yet it expands. This is a known fact.

If, after the time of inflation, everything shrinks faster and faster inclusive all forces, but condensed matter(higher energy density, shrinks faster) and free space(lower energy density, shrinks slower) with different velocities, for any internal observer it seems to be a faster and faster expansion. Would be explain redshift for example ;) Everything is relative...  ;D

Yup! The Hubble expansion can be explained by considering, "What if a meter were shrinking by 6.8 nanometers per century, relative to the distant past?" As we look out into space and billions of years back into time, it would appear that light is red-shifted because our ruler is shrinking, as the "anti-gravity" energy that is inflating it is running down. Matter is collapsing but from our perspective, it looks like the universe is expanding. As matter collapses faster, it will look like the expansion is accelerating. To my knowledge, there is no known observation that can quantify it or distinguish the difference.
Todd

Offline WarpTech

  • Full Member
  • ****
  • Posts: 1407
  • Do it!
  • Statesville, NC
  • Liked: 1453
  • Likes Given: 1925
@Warptech
A couple more notes:

1. You say that you will address the incorrect assumption that the input energy term Pin*t is much smaller than the rest energy term m0*c2. Problem is that you never mention it again!!
Furthermore, you apparently ignore the post I made showing that for eminently reasonable physical values, the input energy term is about 14 orders down on the rest energy term!! Why have you conveniently blocked this out? You are quite capable of calculating it yourself.  Are you therefore prepared to admit that the input energy term can be neglected in comparison with the rest energy term?
That being the case, all your equations collapse into tautology.
...
@Warptech.
At least do us the favour of replying to the first point here.  You have done a lot of replying, but have studiously skirted this core point, it seems to me.
The fact that your equations produce nonsense when you make this approximation is really your problem, not anyone else's. They are, after all, yours.


Re. your query "How is 'k' measured?"
At these severely sub-relativistic speeds (even the smallest experimental k-value predicts breakeven at less than 1%c) we don't need SR or GR. Pin is measured with a power meter onboard. Acceleration may be measured onboard with an accelerometer, or by an external inertial observer who logs deltaV over deltaT. There is no black magic to be squeezed from this. It is thoroughly mundane. Force F is directly calculable from acceleration (F = m a) because m is invariant to first order (and with 14 orders down on your SR twiddle, arguably to even higher order). Thus we can calculate 'k'.

I'm with @wallofwolfstreet here: plug in some numbers and amaze us with your theory.

That's what I've been doing, messing with MathCAD on my (lunch?) break. :) Here you go. I will admit, @wallofwolfstreet was correct in that I need to include the kinetic energy in my Eout term, and what I have is not Eout but E-total. So progress is being made here...

See attached PDF file with equations and plots from v=0 to c.
Todd


Offline WarpTech

  • Full Member
  • ****
  • Posts: 1407
  • Do it!
  • Statesville, NC
  • Liked: 1453
  • Likes Given: 1925
..
You have confused me. Did you transpose the matrix? My csv files have 245 rows and JA columns = 261 columns.
I will trust that you intended "rows" instead of "columns," because the x dimension corresponding to length is smaller than the y,z dimension corresponding to diameter of the cavity.
All the numbers I gave you were correct.  You are right, the words "row" and "column" in my post were transposed because I keep thinking of the EM Drive as being longer than its mean diameter, and I keep forgetting that your Finite Difference grid has more nodes in the diameter direction than in the longitudinal direction.  If given the choice I would have put more grid points in the longitudinal direction, in the direction where the fields have the most variation. I am correcting the initial post to transpose rows with columns.  Thank you.

Also I keep thinking of the x axis as the horizontal axis, but your matrix is set-up so that x is in the vertical direction of the matrix (x indicates the number of rows) . 

My intuition is to have the z axis as the longitudinal axis of a cone, but you have the x axis as the longitudinal axis, so I have to keep reminding me of all this stuff (particularly when I type fast :)  ).  Too late to change it (these directions are arbitrary as long as we remember them).  I would not be surprised if unwillingly I make the same mistake again (thinking of the x axis in the horizontal direction)
Ditto on the x vs z direction. It confuses me too.
Todd

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
@Warptech
A couple more notes:

1. You say that you will address the incorrect assumption that the input energy term Pin*t is much smaller than the rest energy term m0*c2. Problem is that you never mention it again!!
Furthermore, you apparently ignore the post I made showing that for eminently reasonable physical values, the input energy term is about 14 orders down on the rest energy term!! Why have you conveniently blocked this out? You are quite capable of calculating it yourself.  Are you therefore prepared to admit that the input energy term can be neglected in comparison with the rest energy term?
That being the case, all your equations collapse into tautology.
...
@Warptech.
At least do us the favour of replying to the first point here.  You have done a lot of replying, but have studiously skirted this core point, it seems to me.
The fact that your equations produce nonsense when you make this approximation is really your problem, not anyone else's. They are, after all, yours.


Re. your query "How is 'k' measured?"
At these severely sub-relativistic speeds (even the smallest experimental k-value predicts breakeven at less than 1%c) we don't need SR or GR. Pin is measured with a power meter onboard. Acceleration may be measured onboard with an accelerometer, or by an external inertial observer who logs deltaV over deltaT. There is no black magic to be squeezed from this. It is thoroughly mundane. Force F is directly calculable from acceleration (F = m a) because m is invariant to first order (and with 14 orders down on your SR twiddle, arguably to even higher order). Thus we can calculate 'k'.

I'm with @wallofwolfstreet here: plug in some numbers and amaze us with your theory.

That's what I've been doing, messing with MathCAD on my (lunch?) break. :) Here you go. I will admit, @wallofwolfstreet was correct in that I need to include the kinetic energy in my Eout term, and what I have is not Eout but E-total. So progress is being made here...

See attached PDF file with equations and plots from v=0 to c.
Todd
OK, will review shortly. And I said the same thing as @wall to you about the KE. Now for the third time, I think, that direct question to you, as yet unanswered


You apparently ignore the post I made showing that for eminently reasonable physical values, the input energy term is about 14 orders down on the rest energy term!! Why have you conveniently blocked this out? You are quite capable of calculating it yourself.  Are you therefore prepared to admit that the input energy term can be neglected in comparison with the rest energy term?



Offline SeeShells

  • Senior Member
  • *****
  • Posts: 2442
  • Every action there's a reaction we try to grasp.
  • United States
  • Liked: 3186
  • Likes Given: 2708
Would anyone be interested that would model a perforated copper sheet for me in meep?

I post the specs of the sheets and angles to run at.

Shell

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
@WarpTech - I looked at your pdf.
Einstein's ghost will bite you in the neck while you sleep.
Force cannot depend on velocity.
« Last Edit: 07/14/2015 11:59 pm by deltaMass »

Offline A_M_Swallow

  • Elite Veteran
  • Senior Member
  • *****
  • Posts: 8906
  • South coast of England
  • Liked: 500
  • Likes Given: 223
Are the heat effects within the -10° to 150° C range of a normal thermal camera? (Cost about £700)

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
Would anyone be interested that would model a perforated copper sheet for me in meep?

I post the specs of the sheets and angles to run at.

Shell

Excellent point.  There is no fundamental problem whatsoever in modelling this in Meep.  This is what FD and FE programs are for.

It is a pre-processing problem.  It requires for somebody to write a pre-processing mesh routine to locate copper and holes in a grid with holes in them.   The number of nodes required to do this will be much, much larger than the present number of nodes used, and therefore the amount of computer memory and computer time will be much larger.

Another way to handle this (not requiring a different mesh than presently used) would be to use an equivalent constitutive model for the copper with holes (letting wavelengths small enough pass through holes and large wavelengths not pass through, and distributing this wavelength dependence at every node in an average sense).  For example, one may start by modeling a problem with a known exact solution, either a rectangular or cylindrical cross-section cavity of smaller dimensions, modeled with and without the perforated holes to see what difference it makes if any, and if it makes a difference, work out a model for the copper with holes using an equivalent model with copper with no holes for the truncated cone.  Theoretical and/or experimental papers on the effect of perforation on microwaves waveguides would be very helpful for this.  The simplest thing is to refer to papers and ascertain whether the effect of the small wavelength is negligible and henceforth deduce that the effect of the holes is negligible.

The practical problem of holes is lack of stiffness, and this compliance leading to distortion that may affect the Q. 

If these effects are of interest, I would start by modeling the hexagonal cross-section and see what difference that makes.  (The hexagonal model will take much less computer resources than modeling the holes).
« Last Edit: 07/15/2015 12:47 am by Rodal »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
Are the heat effects within the -10° to 150° C range of a normal thermal camera? (Cost about £700)

Yes, and this would serve many purposes.  Not only would this document the thermal history (temperature profile in space vs. time), but when focusing on the bases of the truncated cone it would reveal the actual mode shape being excited.

Neither Shawyer nor Yang ever offered any experimental verification of the mode shapes that were excited in their tests. The only experimental verification was made by Paul March at NASA that verified the excitation of mode shape TM212 for NASA tests.
« Last Edit: 07/15/2015 01:07 am by Rodal »

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
Go New Horizons! At 3*10-19 Watts received power and 1500 b/s @8.44 GHz, both transmitters phoned home with perfect status. One heck of a radio!!  ;D ;D ;D

Not a bad spacecraft either ;D
« Last Edit: 07/15/2015 01:10 am by deltaMass »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
We continue the program started with posts

http://forum.nasaspaceflight.com/index.php?topic=37642.msg1403629#msg1403629

http://forum.nasaspaceflight.com/index.php?topic=37642.msg1404000#msg1404000
http://forum.nasaspaceflight.com/index.php?topic=37642.msg1404004#msg1404004
http://forum.nasaspaceflight.com/index.php?topic=37642.msg1404005#msg1404005
http://forum.nasaspaceflight.com/index.php?topic=37642.msg1404006#msg1404006

showing for the first time (this has not been previously shown anywhere else) what the stress (force/unitArea) on the Big Base looks like.

The stress tensor is obtained using Wolfram Mathematica ( http://www.wolfram.com/mathematica/ )  , post-processed from the transient Finite Difference (using Meep) solution for RF feed ON for an EM Drive.

Looking at the surface of the Big Base from a point located inside the cavity, the normal stress at the Big Base is pointed in the direction from the small base towards the big base, applying pressure on it, as required for a recoil motion to take place and accelerate the EM Drive in the opposite direction, towards the small base. The stress is not uniformly distributed through the big base (at least for the mode shape TM11 excited in this example) but instead it is distributed mainly in the circumferential outer periphery of the Big Base.

The stress at the Big Base is similar to the one shown at section x=38 near the Big Base, previously shown in this post http://forum.nasaspaceflight.com/index.php?topic=37642.msg1404000#msg1404000, except that the stress is significantly higher and much concentrated at the copper and much less at the center of the Big Base.

We naturally expect that the stress tensor on the copper itself should sum up to zero in order to satisfy the momentum equilibrium equation implied by Maxwell's equation.   We have yet to plot the stress at the Small Base (and the lateral surfaces) to make this comparison.
______________________________






(*)  (where we denote by sigmaxxxx= T11 the contravariant component of the tensor acting along the longitudinal direction "x" of the EM Drive, normal to the the plane yz having normal x, where direction "1" is "x")

(**) For the copper diamagnetism is assumed such that the magnetization M is assumed proportional to the applied magnetic field such that for free space it is assumed that M is zero in free space in the relationship 
« Last Edit: 07/16/2015 11:55 am by Rodal »

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
@Rodal:
Is it possible with this data to confirm or deny the correctness of 2*P/c versus 2*P/vg?

Offline aero

  • Senior Member
  • *****
  • Posts: 3629
  • 92129
  • Liked: 1145
  • Likes Given: 360
Dr. Rodal
A new folder, end-cuts-July14-2015 is on Google Drive.
https://drive.google.com/file/d/0B1XizxEfB23tbVExQjlsRDFyMkk/view?usp=sharing
Do you need new side view csv files. These seem to me to be from the same run that we have been using, that is the NSF-1701 control file that I uploaded several days ago. Anyhow, the matrix dimensions are right. Let me know.
Retired, working interesting problems

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
And here we show the fluctuation of the stress with time, for the component σxx acting along the longitudinal direction "x" of the EM Drive, normal to the the circular cross-section plane yz having normal x, calculated at the center of the Big Base.
« Last Edit: 07/15/2015 02:01 am by Rodal »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
Dr. Notsosureofit added this important remark to the Wiki section on his hypothesis

http://emdrive.wiki/@notsosureofit_Hypothesis

Quote
Notice that this is the static thrust per photon in a rest (un-accelerated) frame traveling with the cavity.  That is to say, thrust is dependent on the acceleration that the physical cavity experiences and goes to zero at the acceleration g.  This is an example of a negative feedback system where the steady state acceleration in the cavity frame of a free cavity will always be less than that calculated from the static force. It has no dependence on the linear velocity.  (The case of circular motion is different in that the centrifugal "force" is dependent on angular velocity and will further negatively affect the thrust.) 

This remark pertains to a lot of the discussions that have been taking place concerning the implications of thrust in the EM Drive vis-a-vis conservation of energy and the issue of measurement of such a thrust.
« Last Edit: 07/15/2015 03:00 am by Rodal »

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
Quote
the number of cycles for the photons in the cavity to reach velocity c
Is it just me, or is getting hot in here?

Offline leomillert

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

I think you're fine - looks like you have a good meep install.

Yes, all of the numbers in your csv file were different than the numbers in my csv file, the not by much. I loaded both csv files into a spread sheep program then subtracted one from the other, entry by entry. Then I looked for the largest positive difference and the absolute value of the largest negative difference. I came up with 4.16333634234434E-017 and 2.7972416050126E-017. That is the difference in numerical precision of our two machines, nothing more.

You're good to go, and for all you theorists out there, leomillert is now set to generate meep data for you.

and leomillert, here are some links to manuals that you may wish to bookmark if you haven't already.

http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-user.pdf
http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref.pdf
https://www.mail-archive.com/[email protected]/ - You may need to join.
http://ab-initio.mit.edu/wiki/index.php/Meep_Tutorial
http://ab-initio.mit.edu/wiki/index.php/Meep_Reference
http://ab-initio.mit.edu/h5utils/h5topng-man.html
http://ab-initio.mit.edu/h5utils/h5totxt-man.html
http://www.hdfgroup.org/products/java/hdfview/UsersGuide/index.html

and don't forget, Google is your friend.

aero

aero, I tried to replicate your method but using the UNIX shell instead of spreadsheet programs, since that is more portable and efficient. And it would also help novices, since it would eliminate the need for them to deal with spreadsheets and all that.
However, my sh abilities are a bit rusty and I ended up getting a different (probably wrong) result. The difference between our models according to my script is much greater than the one you calculated.

Can you spot the error?
Here's the script. I added comments so you could better understand it.
Run as "sh compare.sh", should take around a 1 minute to finish executing and outputting its result.

#!/bin/sh

# considering 2 models
# zCopper-exy-leo.csv
# zCopper-exy-aero.csv

# change all commas for newlines
tr ',' '\n' < zCopper-exy-leo.csv > tmp1
tr ',' '\n' < zCopper-exy-aero.csv > tmp2

# define variables a and b as how many lines each file has
a=$(wc -l < tmp1)
b=$(wc -l < tmp2)
# calculate how many extra lines one file has
d=$(echo $a-$b | bc)

# get absolute value of amount of extra lines
if [ $d -lt 0 ]
then
d=$(echo $d*-1 | bc)
fi

# check which file had extra lines (leo or aero) and remove those extra lines
if [ $a -lt $b ]
then
head -n -$d tmp2 > tmp3
# join the two .csv files, line by line
paste tmp1 tmp3 > pst
fi
if [ $b -lt $a ]
then
head -n -$d tmp1 > tmp3
# join the two .csv files, line by line
paste tmp1 tmp3 > pst
fi

rm tmp1
rm tmp2
rm tmp3

# remove extra tab between values and add a minus in its place
# also fix scientific notation so bc understands it later on
sed -e 's/      / - /g' -e 's/e/*10^/g' pst > tab
rm pst

# subtract each entry, line by line
IFS=$'\n'
set -f
for i in $(cat ./tab); do
    echo "scale=50; "$i"" | bc >> res
done
rm tab

# sort values from lowest to highest
sort -nk1,1 res > srt
rm res

# create file with the lowest value and the highest value
(head -n1 && tail -n1) < srt > end

# print result to screen
cat end

Offline dumbo

  • Member
  • Posts: 15
  • I believe eleph^H^H^H^H^HEMDrives can FLY
  • Tianjin, China
  • Liked: 9
  • Likes Given: 77
Hi everyone,

I see there has been frantic activity in the forum since I last checked in. I have received some great PMs from users with offers of donating server time, etc. Unfortunately, it looks like I am going to be very busy with my day job all week, and so from my side it will take some longer time before I can begin.

But if any other intrepid soul wants to have a go in the meantime, feel free to use the EC2 AMI that I have created and now made public:
The AMI name is ubuntu-trusty-meep-emdrive with AMI id ami-3f54560f. The AMI is based on the stock Ubuntu AMI provided by Amazon with the following modifications:
1) I have installed packages meep and meep-mpi-default
2) I have placed aero's config file in the root folder of user ubuntu
3) The configuration file has been slighly altered to make sure it can run on the version of meep I installed. The only change is that all instances of the type:
(define variable)
(set! variable some-value)
have been changed to
(define variable some-value)
This change was necessary as the simulation otherwise refused to start.
4) The main run statement has been wrapped in a (synchronized-magnetic ...) statement which will increase runtime and memory usage, but also increase accuracy as per the meep wiki.

Happy Pluto day everybody! I am in awe of the incredible men and women who have taken us so far already into space. Heute die welt, morgen das sonnensystem!

Best regards,
dumbo

Tags:
 

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