-
#1520 by flux_capacitor on 08 Jan, 2017 13:04
-
Neat little interactive tool that visually demonstrates the point. This one is for sound and strings but the same superposition principle applies. Just make the amplitudes unequal.
http://www.physicsclassroom.com/Physics-Interactives/Waves-and-Sound/Standing-Wave-Patterns/Standing-Wave-Patterns-Interactive
Another visual:
http://www.mysearch.org.uk/website3/html/3%20Plane%20Standing%20Waves.htm
I don't have any reason to suspect this isn't happening in the cavity. Are the guys running computer simulations able to capture it?
This could become a plasma accelerator, as a microwave thruster for a spaceship, with a magnetic nozzle opened to space.
Let's imagine the same happens inside the EmDrive. How do you exactly envision such energy flow can transfer momentum whereas it stays contained inside a closed cavity? Aren't we in the same situation as the driver sat in his car at rest, pushing on the steering wheel to make it move?
Or do you think like WarpTech there is sort of a continuous shifting of the center of mass of the EM wave backwards, its energy being then dispersed through the metal and finally to the outside, making the EmDrive an open system?
Is such a thing as the "center of inertial mass" of an EM wave a scientifically established fact? Photons have no rest mass but possess inertial mass, however does the center of mass of a group of photons, an electromagnetic wave, exist, can it be weighed and its physical displacement measured? Due to Heisenberg's uncertainty principle, an elementary particle cannot be localized in both space and time, but a macroscopic group of fermions forming an object with a rest mass can, so its center of mass can be measured. Does a macroscopic group of photons forming a travelling EM wave have a measurable center of mass ? Especially if photons can be treated as massive particles in a waveguide. -
#1521 by mwvp on 08 Jan, 2017 15:53
-
Here is a set of near and far fields viewed from the x side. It looks a little suspicious to me, but what do I know?
It looks like the field is being radiated into the cavity until the amplitude of the energy, and its phase shifts so it is being then reflected back. Energy sloshing around between modes? That's the problem with such a high-Q cavity, it takes too long to stabilize or even observe the process. Perhaps drastically reduce the Q?
A small loop, as an H-mode transducer/feed/probe should only be creating a magnetic field. Ideal the current would be uniform through. It's not like a loop antenna. -
#1522 by aero on 08 Jan, 2017 16:01
-
Here is a set of near and far fields viewed from the x side. It looks a little suspicious to me, but what do I know?
Maybe one of the 3 dipoles is 180o out of phase?
Thanks. I'll look into that possibility tomorrow.
Steve
I'm Sorry, but I mislead you regarding the x-view of the fields. The x view you were looking at wasn't time slices, rather they were spacial slices of a static field at the end of the run, stepping across the computational lattice in the x direction. The other gifs were time slices, but I didn't see anything in any of the time slice side views. so I made a spacial slice side view. I've attached the time slice gifs x-view of the central axis here. But as was remarked, there is very little field energy on the central axis. Maybe that apparent energy "lump" at the center of that static field is just the direction of dipole radiation. It was taken at the end of the run which was 64 cycles. I blithely assumed it would be at the end of the 64-th cycle and the same as the start of the 65-th cycle which never started, but I don't know exactly how meep does it as it propagates in integer time steps that are 2/resolution (2/240 and 2/50 near and far views) with meep time being (1/c) in these cases. Inverse speed of light.
Anyway, regarding the sign on the dipole radiation, unless meep does it wrong internally or unless physics requires that I add a phase angle to one or the other ex, ey when used together, the dipole phases are right. That is, they all start at time 0 with zero phase with ex radiating in the x direction and ey radiating in the y direction.
-
#1523 by mwvp on 08 Jan, 2017 16:09
-
...
How do you exactly envision such energy flow can transfer momentum whereas it stays contained inside a closed cavity? Aren't we in the same situation as the driver sat in his car at rest, pushing on the steering wheel to make it move?
No, in practice this is an open system, not a closed system. Shawyer doesn't discuss the role of dissipation, consequently critics use the closed-system strawman arguement. Power applied, and dissipation/heat makes the system open...
Or do you think like WarpTech there is sort of a continuous shifting of the center of mass of the EM wave backwards, its energy being then dispersed through the metal and finally to the outside, making the EmDrive an open system?
I believe there is a continuous shifting of the center of radiation pressure via a marching wave of momentum. I don't see the need like WarpTech to invoke gravity, as I understand gravity is the curvature of spacetime caused by mass, and mass being Energy. And since there is considerable megawatts of radiation pressure against the immense mass-energy of the frustrum, what I would call gravitational effects would be insignificantly infinitesimal. Unless there's new physics.
But we seem to be unable to consider the physics of a frustrum for over a few dozen microseconds, when many milliseconds are called for.
-
#1524 by aero on 08 Jan, 2017 16:28
-
Here is a set of near and far fields viewed from the x side. It looks a little suspicious to me, but what do I know?
It looks like the field is being radiated into the cavity until the amplitude of the energy, and its phase shifts so it is being then reflected back. Energy sloshing around between modes? That's the problem with such a high-Q cavity, it takes too long to stabilize or even observe the process. Perhaps drastically reduce the Q?
A small loop, as an H-mode transducer/feed/probe should only be creating a magnetic field. Ideal the current would be uniform through. It's not like a loop antenna.
These graphics only show the fields, there isn't any cavity in the lattice, just vacuum and a one wavelength pml around the edges to absorb the field energy and suppress/eliminate reflections from the lattice walls.
But by only magnetic, are you saying that only hz should be used to excite the dipoles? That is, I should remove the ex and ey excitations?
Edit-Add: And this is a continuous sin wave excitation for clarity. No noise bandwidth and no Q. That is, Q=1.
And I've concluded that meep for one, will never be able to propagate more than a few microseconds per day. I'm running the fastest consumer grade processor currently available (4.7 GHz clock) with physical 8 cores but the overhead required to share a meep job between cores becomes greater than the run time saved when more than 4 cores are interfaces. Maybe the latest Intel I7 processors with 24 MHz cache would run the job but the clock is slower on that processor and since run time is directly related to clock rate I don't know that even running the whole job in cache would make up for the slower clock rate of the Intel processors. So to get speed, a coarse lattice is required, but working in the near field as we are, and desiring some level of precision, limits how coarse the lattice can be.
That leaves it up to the theoreticians to see any details, and experimentalists to lead the way. -
#1525 by mwvp on 08 Jan, 2017 16:42
-
These graphics only show the fields, there isn't any cavity in the lattice, just vacuum and a one wavelength pml around the edges to absorb the field energy and suppress/eliminate reflections from the lattice walls.
But by only magnetic, are you saying that only hz should be used to excite the dipoles? That is, I should remove the ex and ey excitations?
Uhm, I probably wasn't following the threads closely enough. I just got the impression that because the fields faded, and a diametric phase shift seemed to appear, a probe was placed near a wall. I need to reacquaint myself with Meep. Sorry. -
#1526 by sanman on 08 Jan, 2017 17:12
-
And I've concluded that meep for one, will never be able to propagate more than a few microseconds per day. I'm running the fastest consumer grade processor currently available (4.7 GHz clock) with physical 8 cores but the overhead required to share a meep job between cores becomes greater than the run time saved when more than 4 cores are interfaces. Maybe the latest Intel I7 processors with 24 MHz cache would run the job but the clock is slower on that processor and since run time is directly related to clock rate I don't know that even running the whole job in cache would make up for the slower clock rate of the Intel processors. So to get speed, a coarse lattice is required, but working in the near field as we are, and desiring some level of precision, limits how coarse the lattice can be.
That leaves it up to the theoreticians to see any details, and experimentalists to lead the way.
Hey man, why don't you try to get an account on Amazon Web Services or some other Cloud platform, and the rest of us can chip in to give you a few bucks to run it on there, so that you'll have as many processors as you like.
Who maintains this Wiki, btw?
http://emdrive.wiki/MEEP#Cloud_computing:_Amazon_EC2_AMI
Maybe give that guy @dumbo a tweet to get his help. -
#1527 by rfmwguy on 08 Jan, 2017 17:26
-
Did someone say closed system strawman argument?
-
#1528 by aero on 08 Jan, 2017 17:45
-
And I've concluded that meep for one, will never be able to propagate more than a few microseconds per day. I'm running the fastest consumer grade processor currently available (4.7 GHz clock) with physical 8 cores but the overhead required to share a meep job between cores becomes greater than the run time saved when more than 4 cores are interfaces. Maybe the latest Intel I7 processors with 24 MHz cache would run the job but the clock is slower on that processor and since run time is directly related to clock rate I don't know that even running the whole job in cache would make up for the slower clock rate of the Intel processors. So to get speed, a coarse lattice is required, but working in the near field as we are, and desiring some level of precision, limits how coarse the lattice can be.
That leaves it up to the theoreticians to see any details, and experimentalists to lead the way.
Hey man, why don't you try to get an account on Amazon Web Services or some other Cloud platform, and the rest of us can chip in to give you a few bucks to run it on there, so that you'll have as many processors as you like.
Who maintains this Wiki, btw?
http://emdrive.wiki/MEEP#Cloud_computing:_Amazon_EC2_AMI
Maybe give that guy @dumbo a tweet to get his help.
I have ran meep on a server, the speed does not depend on number of processors, the time to complete a meep job increases with number of processors interfaced beyond 3 or 4 processors. The run time by number of processors is an upward opening parabola, the minimum run time depends only on the processor clock rate. A more efficiently or custom interface code, customized to meep might increase the number of processors that could be effectively be brought to bear, but that is a job of work to do so. And I expect that most if not all numeric models face a similar limitation at whatever level of computational lattice they operate.
Of course a server does have the advantage of a batch job so one could walk away and let it run for a few weeks...But then one needs to define a job where the long, long run time would actually provide needed information. -
#1529 by sanman on 08 Jan, 2017 17:54
-
I have ran meep on a server, the speed does not depend on number of processors, the time to complete a meep job increases with number of processors interfaced beyond 3 or 4 processors. The run time by number of processors is an upward opening parabola, the minimum run time depends only on the processor clock rate. A more efficiently or custom interface code, customized to meep might increase the number of processors that could be effectively be brought to bear, but that is a job of work to do so. And I expect that most if not all numeric models face a similar limitation at whatever level of computational lattice they operate.
Of course a server does have the advantage of a batch job so one could walk away and let it run for a few weeks...But then one needs to define a job where the long, long run time would actually provide needed information.
In a previous post Rodal mentions:QuoteAccording to the researchers, they "believe that Amazon’s HPC (https://aws.amazon.com/hpc/) cloud is well prepared for moderately sized parallel CFD problems on up to 64 CPU cores or 8 GPUs.”
NASA's JPL is one of the featured customers of Amazon’s HPC (https://aws.amazon.com/hpc/) -
#1530 by Rodal on 08 Jan, 2017 18:03
-
The problem with solution time is inherent to the choice of the central difference time operator (which is only conditionally stable) to run the computations.I have ran meep on a server, the speed does not depend on number of processors, the time to complete a meep job increases with number of processors interfaced beyond 3 or 4 processors. The run time by number of processors is an upward opening parabola, the minimum run time depends only on the processor clock rate. A more efficiently or custom interface code, customized to meep might increase the number of processors that could be effectively be brought to bear, but that is a job of work to do so. And I expect that most if not all numeric models face a similar limitation at whatever level of computational lattice they operate.
Of course a server does have the advantage of a batch job so one could walk away and let it run for a few weeks...But then one needs to define a job where the long, long run time would actually provide needed information.
In a previous post Rodal mentions:QuoteAccording to the researchers, they "believe that Amazon’s HPC (https://aws.amazon.com/hpc/) cloud is well prepared for moderately sized parallel CFD problems on up to 64 CPU cores or 8 GPUs.”
NASA's JPL is one of the featured customers of Amazon’s HPC (https://aws.amazon.com/hpc/)
To choose MEEP as the running platform to perform calculations one has to have an overwhelming rationale to select MEEP over other possible alternatives (ANSYS, COMSOL, FEKO, EmPro, etc., etc.).
The advantage of a FDTD methodology, particularly using a conditionally stable finite difference method like the central difference method, in my view, is primarily to solve highly nonlinear problems .
For linear problems, there are much more efficient algorithms, like spectral methods, for example.
MEEP's main purpose of existence has been, to solve nonlinear optics problems, that were difficult to solve.
One great advantage of MEEP is that the code is open, so that students can get to change the code as needed. In particular, one can change the code to solve highly nonlinear equations, using nonlinear constitutive equations, or if necessary, nonlinear equations of motion.
I could see people wanting to run MEEP in the cloud, or using highly parallel algorithms, if one would be solving highly nonlinear equations. I don't see the rationale, as done up to now, where MEEP has been used to solve linear Maxwell equations.
For a highly nonlinear problem, it would be practically out of the question to run the Boundary Element Method used in FEKO, for example, due to the highly populated matrices that BEM involves, and therefore how inefficient would be to calculate the inverse matrix at every time step. MEEP then would have a clear advantage over FEKO BEM.
What would that nonlinear solution driving the need for MEEP be for an EM Drive? Minotti's solution is nonlinear, but he has solved the problem analytically, which is always preferable to a numerical solution.
Are there other nonlinear equations out there needing a numerical solution? WarpTech says that his formulation involves several nonlinear terms, and he does not have analytical solutions. Perhaps WarpTech would be interested...
-
#1531 by WarpTech on 08 Jan, 2017 18:37
-
Here is a set of near and far fields viewed from the x side. It looks a little suspicious to me, but what do I know?
Maybe one of the 3 dipoles is 180o out of phase?
Thanks. I'll look into that possibility tomorrow.
Steve
I'm Sorry, but I mislead you regarding the x-view of the fields. The x view you were looking at wasn't time slices, rather they were spacial slices of a static field at the end of the run, stepping across the computational lattice in the x direction. The other gifs were time slices, but I didn't see anything in any of the time slice side views. so I made a spacial slice side view. I've attached the time slice gifs x-view of the central axis here. But as was remarked, there is very little field energy on the central axis. Maybe that apparent energy "lump" at the center of that static field is just the direction of dipole radiation. It was taken at the end of the run which was 64 cycles. I blithely assumed it would be at the end of the 64-th cycle and the same as the start of the 65-th cycle which never started, but I don't know exactly how meep does it as it propagates in integer time steps that are 2/resolution (2/240 and 2/50 near and far views) with meep time being (1/c) in these cases. Inverse speed of light.
Anyway, regarding the sign on the dipole radiation, unless meep does it wrong internally or unless physics requires that I add a phase angle to one or the other ex, ey when used together, the dipole phases are right. That is, they all start at time 0 with zero phase with ex radiating in the x direction and ey radiating in the y direction.
Okay, but a loop should look like a "magnetic dipole" not an electric dipole. That's what appears to be wrong to me. It should oscillate red circle to blue circle, not both at the same time. -
#1532 by mwvp on 08 Jan, 2017 19:00
-
...
And I've concluded that meep for one, will never be able to propagate more than a few microseconds per day. I'm running the fastest consumer grade processor currently available (4.7 GHz clock) with physical 8 cores but the overhead required to share a meep job between cores becomes greater than the run time saved when more than 4 cores are interfaces. Maybe the latest Intel I7 processors with 24 MHz cache would run the job but the clock is slower on that processor and since run time is directly related to clock rate I don't know that even running the whole job in cache would make up for the slower clock rate of the Intel processors. So to get speed, a coarse lattice is required, but working in the near field as we are, and desiring some level of precision, limits how coarse the lattice can be.
That leaves it up to the theoreticians to see any details, and experimentalists to lead the way.
A concept that is presently nagging me is using a frequency domain solver to derive propagation constants for cross-sections, for several related frequencies. Then using that data, solve a wave equation. I could modify that to handle Doppler shift.
The most important data to me is to obtain the marching wave's radiation pressure; a dynamic force. Vs. cavity dimensions, dispersion, acceleration, et. Finding modes, losses, feedpoints, probes and coupling is vital, but can (is) be done quickly in the frequency domain with Feko,et.
Thanks a lot for all your efforts, Aero. You put in, and still contribute a lot of work. I hate to agree that Meep, or probably any non-custom, rigorous code isn't going to solve a dozen operations on a million points over a trillion time steps. -
#1533 by aero on 08 Jan, 2017 19:01
-
I have ran meep on a server, the speed does not depend on number of processors, the time to complete a meep job increases with number of processors interfaced beyond 3 or 4 processors. The run time by number of processors is an upward opening parabola, the minimum run time depends only on the processor clock rate. A more efficiently or custom interface code, customized to meep might increase the number of processors that could be effectively be brought to bear, but that is a job of work to do so. And I expect that most if not all numeric models face a similar limitation at whatever level of computational lattice they operate.
Of course a server does have the advantage of a batch job so one could walk away and let it run for a few weeks...But then one needs to define a job where the long, long run time would actually provide needed information.
In a previous post Rodal mentions:QuoteAccording to the researchers, they "believe that Amazon’s HPC (https://aws.amazon.com/hpc/) cloud is well prepared for moderately sized parallel CFD problems on up to 64 CPU cores or 8 GPUs.”
NASA's JPL is one of the featured customers of Amazon’s HPC (https://aws.amazon.com/hpc/)
Dr. Rodal makes a good point above. The only real advantage of meep for our problem is that it gives time evolution of the fields without evoking averages over the cycle, and most importantly allows customization of the software. It could conceptually be modified to calculate the effect of the energies on the air particles within the cavity. That would be nice if the cavity were, for example, filled with ammonia and ran at 24 GHz. Then it's ability to handle nonlinear problems might shine. But that would I'm sure introduce other problems with required resolution and slow the run time even more.
But let's look at what we have and what could be gained. I recently ran meep to calculate quality factor and other parameters, a job which ran for 1500 cycles of the ~2.45 GHz drive and took ~444. minutes. That is 3.336E-9 seconds (SI units) per cycle of the drive and 26640 seconds run time. 1500 cycles times 3.336E-9 gives ~5 micro-seconds simulated real time. I calculate 0.187 nano-seconds simulated/second real time. So how long a time needs to be simulated? My machine ran this job at a rate of about 16 microseconds per day using 4 processors. Sixty-four processors running at the same speed without interface limitations would take 1.5 hours. Except that server processors run at a lower clock rate than 4.7GHz, more likely 3 GHz. But 100 micro-seconds might be enough for the cavity to reach steady state at somewhat low Q. An off the top guess is that the amazon server may complete 100 microsecond simulated run in less than one day which would be helpful if the data were sufficiently desirable to expend the funds and effort. -
#1534 by RERT on 08 Jan, 2017 19:06
-
PotomacNeuron -
Yes, Rossi is a convicted Felon, some time ago on a different technology. My own main reason for believing him a crook is that by far the most compelling explanation for some of his Ecat results is simply that he tampered with experiments. So agreed, just my opinion in that case.
Thanks for editing your post. The edit trail has a hint of 'agreed not to ask when you stopped beating your wife' (still mentions Ecat) but it seems like the way these things work...
In any case, there is much more room for opinions on Shawyer. What do you have against Cannae? -
#1535 by aero on 08 Jan, 2017 19:09
-
Here is a set of near and far fields viewed from the x side. It looks a little suspicious to me, but what do I know?
Maybe one of the 3 dipoles is 180o out of phase?
Thanks. I'll look into that possibility tomorrow.
Steve
I'm Sorry, but I mislead you regarding the x-view of the fields. The x view you were looking at wasn't time slices, rather they were spacial slices of a static field at the end of the run, stepping across the computational lattice in the x direction. The other gifs were time slices, but I didn't see anything in any of the time slice side views. so I made a spacial slice side view. I've attached the time slice gifs x-view of the central axis here. But as was remarked, there is very little field energy on the central axis. Maybe that apparent energy "lump" at the center of that static field is just the direction of dipole radiation. It was taken at the end of the run which was 64 cycles. I blithely assumed it would be at the end of the 64-th cycle and the same as the start of the 65-th cycle which never started, but I don't know exactly how meep does it as it propagates in integer time steps that are 2/resolution (2/240 and 2/50 near and far views) with meep time being (1/c) in these cases. Inverse speed of light.
Anyway, regarding the sign on the dipole radiation, unless meep does it wrong internally or unless physics requires that I add a phase angle to one or the other ex, ey when used together, the dipole phases are right. That is, they all start at time 0 with zero phase with ex radiating in the x direction and ey radiating in the y direction.
Okay, but a loop should look like a "magnetic dipole" not an electric dipole. That's what appears to be wrong to me. It should oscillate red circle to blue circle, not both at the same time.
Ok - I'll put up the same gifs with only hz excitation of the dipole, and we can look at that. It will be later before I get to it as I'm sitting my boy today. -
#1536 by Peter Lauwer on 08 Jan, 2017 19:31
-
8 W Wifi Repeater EDUP EP-AB003
I have also bought an RF amplifier such as which TheTraveller uses and measured the amplification today. As RF source I used the Windfreak SynthNV signal generator.
At 2.45 GHz I measured a (maximum) power output of the SynthNV of 16.5 dBm. This signal was fed into the Wifi repeater and a) measured with a spectrum analyzer (Agilent E4404B), b) with the network analyzer feature of the SynthNV.
a) a power output of 30.3 dBm was measured => 13.8 dB amplification (an external attenuator of 20 dB was used), so lower than the given 17 dB,
b) the Windfreak network analyzer gives ~13 dB amplification (sorry, I was lazy and took a picture of the screen with my phone).
I have ordered some preamps (the 5MHz-6GHz Broadband Low Noise Amplifier RF LNA Amp Module which was recommended on this forum) to reach the 20 dBm input for the Wifi repeater.
The bandwidth of the amplifier seems to be much broader than the given specs (2.4-2.5 GHz), especially on the low freq side.
-
#1537 by Stormbringer on 08 Jan, 2017 19:48
-
...
How do you exactly envision such energy flow can transfer momentum whereas it stays contained inside a closed cavity? Aren't we in the same situation as the driver sat in his car at rest, pushing on the steering wheel to make it move?
No, in practice this is an open system, not a closed system. Shawyer doesn't discuss the role of dissipation, consequently critics use the closed-system strawman arguement. Power applied, and dissipation/heat makes the system open...
Or do you think like WarpTech there is sort of a continuous shifting of the center of mass of the EM wave backwards, its energy being then dispersed through the metal and finally to the outside, making the EmDrive an open system?
I believe there is a continuous shifting of the center of radiation pressure via a marching wave of momentum. I don't see the need like WarpTech to invoke gravity, as I understand gravity is the curvature of spacetime caused by mass, and mass being Energy. And since there is considerable megawatts of radiation pressure against the immense mass-energy of the frustrum, what I would call gravitational effects would be insignificantly infinitesimal. Unless there's new physics.
But we seem to be unable to consider the physics of a frustrum for over a few dozen microseconds, when many milliseconds are called for.
don't rule out new physics unless old physics will entirely do. Granted -old physics generally wins out but it does not have to be that way every time.
https://www.sciencedaily.com/releases/2016/01/160108083918.htm?trendmd-shared=0
https://arxiv.org/abs/1504.00333
scientists suggest/consider new physics too often for it to be an illegitimate mode of inquiry. Furthermore if there is smoke there could be fire. In the realms of physics, astronomy and cosmology there is a lot of smoke lately. -
#1538 by mwvp on 08 Jan, 2017 19:52
-
...But 100 micro-seconds might be enough for the cavity to reach steady state at somewhat low Q.
You could increase the cavity resistance to cut the Q back to around 30 - 100. But that would affect the steepness of the dispersion slope. That matters if you're going to consider doppler shift or novel modulation. If you just want a steady-state, perhaps you can save the low-Q run E & H values and load them into a run at high-Q, to reach equilibrium faster. -
#1539 by mwvp on 08 Jan, 2017 20:08
-
don't rule out new physics unless old physics will entirely do. Granted -old physics generally wins out but it does not have to be that way every time.
https://www.sciencedaily.com/releases/2016/01/160108083918.htm?trendmd-shared=0
https://arxiv.org/abs/1504.00333
scientists suggest/consider new physics too often for it to be an illegitimate mode of inquiry. Furthermore if there is smoke there could be fire. In the realms of physics, astronomy and cosmology there is a lot of smoke lately.
Ok. In the current climate of moral and political degeneration, I really have to wonder if things like the lucrative hunt for dark matter, the justification of the lucrative CERN Higgs, the LIGO find, et. aren't the result of a congressman suggesting to a lab directory he'd better get results. I mean, the orthodoxy scares/troubles me far more than the fringe. I have hopes that the fringe will give us the break-throughs, certainly not the orthodoxy. But I'll admit, the batteries and LED flashlights have been getting better. And the chips.
Anyways, I'm aghast that the conventional radiation pressure and EM momentum resulting from marching or traveling standing waves, due to cavity dissipation and Doppler shift hasn't been considered by now. Just sayin. I'm not a math-whiz, I'm more hardware. Its taken me a while, and I'm preoccupied.
I'll give the article a read. After reading the news article, I'm filled with evil thoughts a parking outside LIGO with my Tesla Coil and sending them gravitational Morse code that I'm an alien prince, and would they please e-mail me some bit-coins over wifi
