-
#1480 by kitsuac on 08 Jan, 2016 18:00
-
Here's a thought for all you meepers --
Though meep isn't able to run a simulation faster and faster the more hardware resources you throw at it, it's a relatively simple thing to run many simulations at the same time which WILL scale proportionally to the hardware resources you throw at it. So meep users, think about it - is there value you could gain by seeing many meep simulations which differ only by certain parameter changes? If you are able to provide a configuration file along with which parameter(s) to vary over different simulations (how much to vary them, at what increments), it's something the tech wizards among us would be able to automate with scripts and cloud servers. It'd just be a matter of starting N servers each given a different automatically generated config file variation, and then aggregating the simulation output files for download and comparison. -
#1481 by Rodal on 08 Jan, 2016 18:20
-
Here's a thought for all you meepers --
Though meep isn't able to run a simulation faster and faster the more hardware resources you throw at it, it's a relatively simple thing to run many simulations at the same time which WILL scale proportionally to the hardware resources you throw at it. So meep users, think about it - is there value you could gain by seeing many meep simulations which differ only by certain parameter changes? If you are able to provide a configuration file along with which parameter(s) to vary over different simulations (how much to vary them, at what increments), it's something the tech wizards among us would be able to automate with scripts and cloud servers. It'd just be a matter of starting N servers each given a different automatically generated config file variation, and then aggregating the simulation output files for download and comparison.
There is a parallel version of Meep: http://ab-initio.mit.edu/wiki/index.php/Parallel_Meep that may be interesting to run.
Yes, there are several limitations to performing parallel computing in a public cloud, an intensive application like Meep will, like other parallel scientific computing applications, have to map out pieces of itself in parallel and report back to the source several times before synthesizing.
When it comes to cloud, long distances mean unacceptably high latencies. Researchers from the University of Bonn in Germany examined those latency issues(for computational fluid mechanics (CFD) modeling) in the cloud by utilizing a common CFD and its utilization in parallelized computing including both CPU and GPU cores of Amazon EC2.
For CPUs in Amazon’s EC2 cluster, they found that the application running on 8 CPU cores had an efficiency of 70 percent relative to a non-virtualized cluster. “Beyond that limit, they run into network interconnect bandwidth problems . After an explicit request for more CPU compute instances, they have seen even for up to 256 CPU cores / 32 instances an acceptable parallel efficiency of more than 50 percent.
According 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/) -
#1482 by Tellmeagain on 08 Jan, 2016 18:23
-
Just VMS for me. Came to it in about 1987. Every other operating system I've worked on seems like a step backwards (including VxWorks which I use for satellite control systems). I in fact have a MicroVAX 3100-90 on my desk (currently powered off
I've always wondered about the VAX in your moniker. Dare I ask if you know RT-8, RT-11, TSX, RSX-11, RSTS? I suspect VMS is on the list too?
)
[/quote]
I have a vax3900. -
#1483 by zen-in on 08 Jan, 2016 18:25
-
Rfmwguy, what is that dandy hand tool he's using to cut those templates out?
I guess I'm old school. My first choice for cutting soft metals like Copper is a set of hand shears. This is what's called a well built American hand tool. Sadly, they are no longer made. This one is very good for straight cuts. There are shears specially made for curves. The trick is to place the work against the anvil blade so the waste gets bent by the cut and not the piece you are cutting out.
-
#1484 by kitsuac on 08 Jan, 2016 18:27
-
There is a parallel version of Meep: http://ab-initio.mit.edu/wiki/index.php/Parallel_Meep
Although there are several limitations to performing parallel computing in a public cloud, an intensive application like Meep will, like other parallel scientific computing applications, have to map out pieces of itself in parallel and report back to the source several times before synthesizing.
When it comes to cloud, long distances mean unacceptably high latencies. Researchers from the University of Bonn in Germany examined those latency issues(for computational fluid mechanics (CFD) modeling) in the cloud by utilizing a common CFD and its utilization in parallelized computing including both CPU and GPU cores of Amazon EC2.
For CPUs in Amazon’s EC2 cluster, they found that the application running on 8 CPU cores had an efficiency of 70 percent relative to a non-virtualized cluster. “Beyond that limit, they run into network interconnect bandwidth problems . After an explicit request for more CPU compute instances, they have seen even for up to 256 CPU cores / 32 instances an acceptable parallel efficiency of more than 50 percent.
According 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.”
I'm well versed with cloud servers, MPI, and specifically meep running in parallel. If you search my post history, you'll see that I made a pretty thorough effort to test the extent of meep's scalability within the context of the sort of simulations being done by users on this forum. Unfortunately, it's not so great. Even within the same machine with multiple cores, scalability rapidly drops off and becomes a detriment. That's because, like you've said, the simulation needs to be divided into separate work items and there is complex synchronization which needs to occur as a result.
What I'm talking about now is an alternative in lieu of that ideal sort of scalability. Running multiple distinct simulations doesn't suffer from the problems of dividing up a single simulation and synchronizing all of the stitch points. Instead, each simulation permutation can run at the optimal number of cores on a single machine, spend hours or days doing it's work, and then send the results back to a central location. -
#1485 by Rodal on 08 Jan, 2016 18:52
-
That you can't solve this set of equations in the under cut off volume doesn't mean there can't be thrust at all.I agree with 1) but what is the evidence that leads to 2)?
Why does Shawyer suggest to keep the small end above cutoff?
It is stated in Roger's thrust equation:
Thrust = (2 * Qu * Df * Power) / c
Where Df is as attached and is where the small end cutoff comes into the equation. With the small end in cutoff, there is no thrust.
Please refer to the 2nd and 3rd attachments as well
(If there was ever thrust like discussed and not other effects like Lorentz force or whatever)
As far as I know Shawyer's Df and thrust equations are not proven till now.
All discussed thrust equations for conical cavities leads to larger thrust the closer the narrow end of the cavity is in relation to it's apex (mathematically singularities at null distance).
Some threads ago we had a huge discussion especially of the effects of evanescent waves.
Question: Was this been tested by Shawyer and his company or is it his intuitive opinion that it would not work with an undersized end of the cone, just below cutoff diameter?
Very well put.
At the moment I have not seen either:
1) a theoretical justification why (what is simultaneously claimed to be a completely closed cavity (the EM Drive)) can be modeled as an open waveguide, including the cut-off condition for open waveguides, for anomalous thrust purposes.
2) reports of experiments showing what happens to the anomalous force when the EM Drive has a small diameter that is below the cut-off condition. On the contrary, all the NASA tests are for an EM Drive that has a small diameter that is below the cut-off condition (as pointed out by TT), and on top of that they use a dielectric insert which lowers the natural frequency even further. Yet, NASA reports an anomalous thrust. Now, somebody could answer "well that's why NASA reports thrust orders of magnitude lower than Shawyer and Yang", but there are problems with that explanation:
a) NASA reported no thrust without a dielectric, at a higher frequency which is not as far apart from the cut-off condition as when using a dielectric.
b) NASA reports anomalous thrust even in vacuum while Shawyer and Yang have never reported test result under vacuum conditions.
c) if the explanation is that NASA reported a lower thrust because their use of dielectric and diameter below the cut-off condition, then the explanation would be "smaller thrust" rather than "no thrust".
So, in the end, it would be much more convincing for Shawyer to report anomalous force data for geometries with different small end diameter, above, at and below the cut off limit.
It should not be too time demanding or expensive to produce such data.
And producing such data would only enhance the credibility (it would serve to support his embattled theory of modeling the closed cavity as an open waveguide) without incurring loss of intellectual property, because it has already been disclosed in the open literature that according to him there is a cut-off condition for thrust.
Shawyer's "cut-off" condition for thrust is already public knowledge. Therefore he cannot claim the cut-off condition to be a trade-secret (https://en.wikipedia.org/wiki/Trade_secret) (*) or something patentable by itself since it already has become public knowledge.
I hope that perhaps Shell can investigate this experimentally, given time. Apparently if Shell investigates this she would be the first one in the world to report such experimental data.
_________
(*) a trade secret is information that:
* Is not generally known to the public;
* Confers some sort of economic benefit on its holder (where this benefit must derive specifically from its not being publicly known, not just from the value of the information itself);
* Is the subject of reasonable efforts to maintain its secrecy. -
#1486 by mwvp on 08 Jan, 2016 18:52
-
WarpTech and I went over Zeng and Fan's equations in excruciating detail. These discussions took place in prior threads. WarpTech had a mathematical theory for the EM Drive related to this.
To make the long story short:
1) Zeng and Fan's paper is for an open waveguide having open end. By contrast, the EM Drive as conceived by Shawyer is a completely closed cavity with closed ends. Cut-off conditions apply to open waveguides, and not to closed cavities.
2) I found an important mathematical mistake in Zeng and Fan's paper that affects their results.
3) I calculated Zeng and Fan's expressions for the actual EM Drive experiments with and without the correction needed to address their mathematical mistake.
4) The calculations based on Zeng and Fan's paper don't support the "anomalous" thrust claimed in EM Drive experiments.
One of several papers that appeared very interesting at first, but that upon working out the numbers, unfortunately could not numerically explain the claimed "anomalous" thrust.
Thanks a lot for that reply and info. But anyways, wouldn't even a closed waveguide display similar propagation coefficient (alpha and beta), and at cut off have a knee? That steep phase slope, beta, makes the skirts on filters roll off so fast, and tunning precarious and sensitive.
I believe Meep can plot those parameters for custom cases, and with dissipation, even if you can't find analytic solutions. I think the Eigensolver MPD (Meep's older brother) does also, much faster....
PS: Concerning <<Thrust is generated by the large radiation pressure in the frustrum becoming unbalanced at each end>>, the radiation pressure in the EM Drive can be shown to be perfectly balanced (hence no net force) if you take into account the radiation pressure on the lateral conical walls, and include all terms, including the time rate of the Poynting vector, in addition to the gradient of the stress, when relying on classical physics.
...
Since the EM Drive is a closed surface, supposedly not interacting with external fields, and without anything going in or out of it (according to Shawyer), the divergence theorem can be applied to the above balance equation.
According to classical physics, since the EM Drive is a closed surface, it should not self-accelerate as a result of any electromagnetic action going on inside it. To self-accelerate you need any of the following:
1) Not being really "closed" and hence interacting with external fields in a way that its claimed performance (greater than a photon rocket) and conservation of energy issues can be justified
I'm positing Shawyer's wrong, the frustrum is an open, not closed system. The flux inside is dissipated due to waveguide skin losses, especially at the base. The dispersion-filtered lower sideband of the acceleration induced doppler-spread energy is mostly radiated at the base, leaving a net unbalanced radiation pressure, enhancing (or retarding according to orientation) the initiating acceleration. An extraordinary negative inertial resistance or inertial ratcheting will be a consequence, along with exhaust heat flux. -
#1487 by Rodal on 08 Jan, 2016 18:56
-
WarpTech and I went over Zeng and Fan's equations in excruciating detail. These discussions took place in prior threads. WarpTech had a mathematical theory for the EM Drive related to this.
To make the long story short:
1) Zeng and Fan's paper is for an open waveguide having open end. By contrast, the EM Drive as conceived by Shawyer is a completely closed cavity with closed ends. Cut-off conditions apply to open waveguides, and not to closed cavities.
2) I found an important mathematical mistake in Zeng and Fan's paper that affects their results.
3) I calculated Zeng and Fan's expressions for the actual EM Drive experiments with and without the correction needed to address their mathematical mistake.
4) The calculations based on Zeng and Fan's paper don't support the "anomalous" thrust claimed in EM Drive experiments.
One of several papers that appeared very interesting at first, but that upon working out the numbers, unfortunately could not numerically explain the claimed "anomalous" thrust.
Thanks a lot for that reply and info. But anyways, wouldn't even a closed waveguide display similar propagation coefficient (alpha and beta), and at cut off have a knee? That steep phase slope, beta, makes the skirts on filters roll off so fast, and tunning precarious and sensitive.
I believe Meep can plot those parameters for custom cases, and with dissipation, even if you can't find analytic solutions. I think the Eigensolver MPD (Meep's older brother) does also, much faster....
PS: Concerning <<Thrust is generated by the large radiation pressure in the frustrum becoming unbalanced at each end>>, the radiation pressure in the EM Drive can be shown to be perfectly balanced (hence no net force) if you take into account the radiation pressure on the lateral conical walls, and include all terms, including the time rate of the Poynting vector, in addition to the gradient of the stress, when relying on classical physics.
...
Since the EM Drive is a closed surface, supposedly not interacting with external fields, and without anything going in or out of it (according to Shawyer), the divergence theorem can be applied to the above balance equation.
According to classical physics, since the EM Drive is a closed surface, it should not self-accelerate as a result of any electromagnetic action going on inside it. To self-accelerate you need any of the following:
1) Not being really "closed" and hence interacting with external fields in a way that its claimed performance (greater than a photon rocket) and conservation of energy issues can be justified
I'm positing Shawyer's wrong, the frustrum is an open, not closed system. The flux inside is dissipated due to waveguide skin losses, especially at the base. The dispersion-filtered lower sideband of the acceleration induced doppler-spread energy is mostly radiated at the base, leaving a net unbalanced radiation pressure, enhancing (or retarding according to orientation) the initiating acceleration. An extraordinary negative inertial resistance or inertial ratcheting will be a consequence, along with exhaust heat flux.
Thank you for explicitly stating that you are << positing Shawyer's wrong, the frustrum is an open, not closed system>>.
Now I understand your post much better. Thanks -
#1488 by Rodal on 08 Jan, 2016 19:25
-
Maybe related:
http://arxiv.org/abs/1504.00333QuoteHow Current Loops and Solenoids Curve Space-time
Andre Fuzfa
Namur Center for Complex systems (naXys),
University of Namur, Belgium
(Dated: December 15, 2015)
The problem is that the paper requiresQuotearbitrarily large steady electric currents
Quotesince the large electric currents that can be achieved with current superconducting cables, roughly of order 10^4 A, will generate extremely weak space-time curvature, it will be necessary to amplify the signal by forcing light to perform numerous round trips in the artifi cially generated gravitational fi eld.
while the electric fields in the EM Drive, instead of being steady currents in a cable are radio-frequency waves alternating in time (at around 2 GHz frequencies) and moreovoer, the electric field magnitude in EM Drive experiments instead of being "arbitrarily large" has been small, relatively speaking. Actually, if the test performed in air exceed just 10^6 V/m, air will experience dielectric breakdown and become conductive (like lightning).
That's the problem of the EM Drive claimed anomalous force experiments:
1) RF cavity resonance, including resonance of conical and truncated cone cavities have been experimentally and theoretically addressed for a long time
2) The electromagnetic field intensity in EM Drives is not of a magnitude for which interesting General Relativity or Nonlinear Quantum Mechanics effects are present to justify the claimed forces.
3) Something that experienced DIY people are experimenting with (under suitable safety precautions since microwave fields can blind and damage people and 1 KW can kill) as a DIY experiment instead of something requiring a CERN type experimental facility and budget.
It could be that if there is something interesting here (and not just experimental artifacts), it may not be at all what Shawyer and others expect (*)
___
(*) when Penzias and Wilson discovered the Cosmic Background Radiation at 4 GHz they were initially bothered by the "noise" and worried long and hard how to eliminate this irksome noise. They even cleaned the frustum-of-a-pyramid (horn-shaped)
microwave receiver from bird poop :-)
thinking that it was perhaps the source of the noise. After cleaning it from pigeon droppings, the noise was still there. They did not initially perform the experiment looking for the Background Radiation, yet they became famous Nobel Prize winners for its discovery, that's how science works, many times :-) (Both of course deserve enormous credit for their great experiment and their persistence in identifying the source of the noise, and both of them were great Physicists). (Their supersensitive instrument included a MASER)
https://en.wikipedia.org/wiki/Discovery_of_cosmic_microwave_background_radiation
Pigeon trap used by Penzias and Wilson to get rid of pigeons:
http://www.smithsonianmag.com/smithsonian-institution/how-scientists-confirmed-big-bang-theory-owe-it-all-to-a-pigeon-trap-180949741/?no-ist
-
#1489 by VAXHeadroom on 08 Jan, 2016 20:31
-
In college I worked on a Data General Eclipse S-330 which had 64K RAM. One of the devices we had to make it run much faster was a fixed-head swap disk - one platter and one head over every track. I think it had 128KB of memory
Just VMS for me. Came to it in about 1987. Every other operating system I've worked on seems like a step backwards (including VxWorks which I use for satellite control systems). I in fact have a MicroVAX 3100-90 on my desk (currently powered off )
You missed the golden days when we moved from 64kb RAM to more, but you got to play with the first 1 MIPS mini.
So, thoughts on a crowdsourced emulator and development framework?
OK, enough of that...
Initial thoughts...
1) open source, freely available development environment - I'm using Eclipse and MinGW currently.
2) standardized language (C++)
3) Cross-compilable across a short list of OS's - Windows & *nix variants
4) Open Source with configuration management (git)
5) Control definition files using standard mathematics notations - unlike meep which uses a Lisp variant. I realize this would make it incompatible with meep, but cheese and crackers is that language a mess
A good example of what I would like to see would be POV-Ray's language... (www.povray.org)
6) built-in stock examples on which to run simulations to simplify debugging of new algorithms and provide built-in-test for data sets with known results. This might be provided as part of a distribution package, but having simple cylindrical and/or box cavities built in would provide quicker and less error-prone checks of new compilations (new operating systems etc).
7) a pre-compiler which would compile the control files to binary for faster run-time.
User interface with standardized elements - too many people roll their own and make a mess of it...
-
#1490 by tchernik on 08 Jan, 2016 21:09
-
... Something that experienced DIY people are experimenting with (under suitable safety precautions since microwave fields can blind and damage people and 1 KW can kill) as a DIY experiment instead of something requiring a CERN type experimental facility and budget.
It could be that if there is something interesting here (and not just experimental artifacts), it may not be at all what Shawyer and others expect (*)
My concern of late is that, as long as there aren't more well funded, institutional, conclusive tests in a hard vacuum showing the presence of force (or its lack thereof) after rigorous attempts to expunge all sources of noise, all DIY experiments will continue to be tainted by the suspicion of systematic experimental error. Because they are made on air, and that always implies the presence of thermal-convection forces. And even more if the forces measured are comparable with those known to arise from thermal/convection phenomena on air.
Well, we have actually 2 institutional efforts for testing this on a vacuum so far. NASA EagleWorks' and Martin Tajmar's at Dresden.
NASA's one is why many of us are still excited and paying attention to the Emdrive. Dresden's are way more inconclusive, and IMO they look like a negative.
Therefore the ball still is at NASA EW, from who we are expecting for a peer-reviewed and replicated confirmation (or refutation), and maybe with Tajmar's team, in case they try to get better thrust from their Emdrive setup (or a new one).
I'm not dissing DIY efforts, though. But let's be honest: only after a lab performs a clear replication in a vacuum, this phenomenon would be taken more seriously in academia.
That or a mythical demonstration of an Emdrive moving all by itself or shooting through the roof (which I notice, TT said has plans to do. I'm really looking forward for that. The self propelled Emdrive, not the one flying through the roof). -
#1491 by zen-in on 08 Jan, 2016 21:20
-
...
In college I worked on a Data General Eclipse S-330 which had 64K RAM. One of the devices we had to make it run much faster was a fixed-head swap disk - one platter and one head over every track. I think it had 128KB of memory
OK, enough of that...
Initial thoughts...
1) open source, freely available development environment - I'm using Eclipse and MinGW currently.
2) standardized language (C++)
3) Cross-compilable across a short list of OS's - Windows & *nix variants
4) Open Source with configuration management (git)
5) Control definition files using standard mathematics notations - unlike meep which uses a Lisp variant. I realize this would make it incompatible with meep, but cheese and crackers is that language a mess A good example of what I would like to see would be POV-Ray's language... (www.povray.org)
6) built-in stock examples on which to run simulations to simplify debugging of new algorithms and provide built-in-test for data sets with known results. This might be provided as part of a distribution package, but having simple cylindrical and/or box cavities built in would provide quicker and less error-prone checks of new compilations (new operating systems etc).
7) a pre-compiler which would compile the control files to binary for faster run-time. User interface with standardized elements - too many people roll their own and make a mess of it...
At Digilab, a Cambride MA FTIR spectrometer manufacturer we used DG Eclipse S/130 minis. They had a 10 Gig Winchester drive; so named because of the removeable media. When it was calculating an FFT the hard drive made a characteristic rhythmic noise that would go on for as long as an hour sometimes, since the data was cached on the disk. We also used DG Novas for testing our interface boards. They used core memory so the paper tape loader stayed intact after a power cycle. The Eclipse had boot proms, very pricey in 1978 and used solid state memory. To make a hard-copy of the spectra, we used an ink-jet printer; a rarity back then. -
#1492 by MazonDel on 08 Jan, 2016 23:27
-
A question for the various DIYers out there.
I've got some CAD skills (Solidworks) and I have been thinking lately about how that might possibly aid these endeavors going on. One thing I realized is that one of my professional 3D printer sources (ShapeWays) can do metal printing of various sorts, including polishing of external surfaces. If it would be helpful for me to CAD up some frustums based on your desired dimensions, I can do various things like integrate cooling devices (fluid channels, peltier mounts, etc), and other things. Chances are decent though that unless an unpolished surface is acceptable the inside of the frustum, that the big end will need to be detachable, which I can do as well. I don't have the software with me at the moment, but to some degree I believe I have some of the modeling tools, such as thermal and whatnot available to try out on the models. I somewhat doubt I have any radio packages, though I will look at that just in case.
All that said, it seems at least ShapeWays is limited in their size to (27.918 x / 25.908 y / 27.928 z, cm), which does not seem sufficient for most of the attempts I am aware of, such as rfmwguy's. However, if someone were desiring a much smaller frustum (from what I've gathered, this seems to mean higher frequency?), this could be helpful.
Let me know what you all think about this.
-Mazon -
#1493 by Tetrakis on 09 Jan, 2016 00:01
-
...
I hope that perhaps Shell can investigate this experimentally, given time. Apparently if Shell investigates this she would be the first one in the world to report such experimental data.
I have to admit, its this kind of thinking that got me excited about becoming a scientist many years ago. If you do good science, you can actually expand to the cumulative knowledge of mankind and, for a moment, know more about something than anyone else ever has. Shell seems to be committed to doing good science and has the right motivations. -
#1494 by glennfish on 09 Jan, 2016 00:08
-
In college I worked on a Data General Eclipse S-330 which had 64K RAM. One of the devices we had to make it run much faster was a fixed-head swap disk - one platter and one head over every track. I think it had 128KB of memory
Just VMS for me. Came to it in about 1987. Every other operating system I've worked on seems like a step backwards (including VxWorks which I use for satellite control systems). I in fact have a MicroVAX 3100-90 on my desk (currently powered off )
You missed the golden days when we moved from 64kb RAM to more, but you got to play with the first 1 MIPS mini.
So, thoughts on a crowdsourced emulator and development framework?
OK, enough of that...
Initial thoughts...
1) open source, freely available development environment - I'm using Eclipse and MinGW currently.
2) standardized language (C++)
3) Cross-compilable across a short list of OS's - Windows & *nix variants
4) Open Source with configuration management (git)
5) Control definition files using standard mathematics notations - unlike meep which uses a Lisp variant. I realize this would make it incompatible with meep, but cheese and crackers is that language a mess A good example of what I would like to see would be POV-Ray's language... (www.povray.org)
6) built-in stock examples on which to run simulations to simplify debugging of new algorithms and provide built-in-test for data sets with known results. This might be provided as part of a distribution package, but having simple cylindrical and/or box cavities built in would provide quicker and less error-prone checks of new compilations (new operating systems etc).
7) a pre-compiler which would compile the control files to binary for faster run-time. User interface with standardized elements - too many people roll their own and make a mess of it...
I'm game, but here's some things to think about.
This community is neither data savvy or machine heavy.
I think that perhaps one approach would be to build a front end interface, HTML/PHP/JAVA that lets a model parameters be created, with tons of up front (are you sure?) messages etc. etc. etc, then the backend is on par with what you're describing. I can't picture See or RFMW or many of the others having a freaking clue what you & I are discussing here.
So what I want to ponder is a multi-tiered approach
1. User interface structure
2. User output structure
3. backend majic, which is where your response started.
The backend side should be cloud of sorts, but unless we have a constant payment structured to some VM cluster in Amazon land, we're severely restricted from a cost point of view to PHP PEARL or java. I'd love to do any variant of C, but I'm not sure we could find an affordable hosting environment that would both support the UI structures as well as the processing back-end that you correctly are thinking of. Perhaps a bifurcated front end that feeds a paid option to amazon (fast), or an unpaid option to some slow-boat interpreter? (Pearl, PHP, slow). Or are you thinking of physically hosting a cluster?
Perhaps it could be based on available UI libraries, just to drag you away from optimal solutions.
I get nervous thinking about a DIY folk who's instructions are first, "Install the LINUX distro of choice then add this package". -
#1495 by ThinkerX on 09 Jan, 2016 00:24
-
Conservation of Energy Question:
As I understand it, the objection here is that constant thrust at the levels claimed for the EM Drive lead directly to a violation of Conservation of Energy. However, suppose the thrust is NOT constant, but instead 'crashes' before reaching that point?
I am thinking here of a 'longer cycle.' Something on the order of 30-40 seconds of high 'thrust,' followed by an unavoidable 'crash' of at least several minutes with no thrust, yet still drawing power, then another 30-40 seconds of 'thrust,' followed by another 'crash.' A 'charge / discharge' cycle. To maintain 'constant acceleration,' you'd need several (10? 20?) EM Drives working in a timed sequence, and a corresponding increase in required power.
Does this represent a valid workaround for Conservation of Energy? -
#1496 by glennfish on 09 Jan, 2016 00:26
-
A question for the various DIYers out there.
I've got some CAD skills (Solidworks) and I have been thinking lately about how that might possibly aid these endeavors going on. One thing I realized is that one of my professional 3D printer sources (ShapeWays) can do metal printing of various sorts, including polishing of external surfaces. If it would be helpful for me to CAD up some frustums based on your desired dimensions, I can do various things like integrate cooling devices (fluid channels, peltier mounts, etc), and other things. Chances are decent though that unless an unpolished surface is acceptable the inside of the frustum, that the big end will need to be detachable, which I can do as well. I don't have the software with me at the moment, but to some degree I believe I have some of the modeling tools, such as thermal and whatnot available to try out on the models. I somewhat doubt I have any radio packages, though I will look at that just in case.
All that said, it seems at least ShapeWays is limited in their size to (27.918 x / 25.908 y / 27.928 z, cm), which does not seem sufficient for most of the attempts I am aware of, such as rfmwguy's. However, if someone were desiring a much smaller frustum (from what I've gathered, this seems to mean higher frequency?), this could be helpful.
Let me know what you all think about this.
-Mazon
There was somewhere in this forum, or perhaps reddit, someone who wanted to do this using a laser as I recall. That would be more a fiber optic approach, but if RF works in any frequency, shorter frequencies would work. NXP has some tech in the 77 GHz range that would be match your dimensions, but I'm unaware of a builder actively working in shorter wavelengths. The upside is the transmitters look like solid state devices which would make things easier in one sense, but lower power which would make things worse in another. Perhaps someone could source some surplus police radars in the Ka-band and try a build with your capabilities? -
#1497 by oliverio on 09 Jan, 2016 00:58
-
A question for the various DIYers out there.
I've got some CAD skills (Solidworks) and I have been thinking lately about how that might possibly aid these endeavors going on. One thing I realized is that one of my professional 3D printer sources (ShapeWays) can do metal printing of various sorts, including polishing of external surfaces. If it would be helpful for me to CAD up some frustums based on your desired dimensions, I can do various things like integrate cooling devices (fluid channels, peltier mounts, etc), and other things. Chances are decent though that unless an unpolished surface is acceptable the inside of the frustum, that the big end will need to be detachable, which I can do as well. I don't have the software with me at the moment, but to some degree I believe I have some of the modeling tools, such as thermal and whatnot available to try out on the models. I somewhat doubt I have any radio packages, though I will look at that just in case.
All that said, it seems at least ShapeWays is limited in their size to (27.918 x / 25.908 y / 27.928 z, cm), which does not seem sufficient for most of the attempts I am aware of, such as rfmwguy's. However, if someone were desiring a much smaller frustum (from what I've gathered, this seems to mean higher frequency?), this could be helpful.
Let me know what you all think about this.
-Mazon
There was somewhere in this forum, or perhaps reddit, someone who wanted to do this using a laser as I recall. That would be more a fiber optic approach, but if RF works in any frequency, shorter frequencies would work. NXP has some tech in the 77 GHz range that would be match your dimensions, but I'm unaware of a builder actively working in shorter wavelengths. The upside is the transmitters look like solid state devices which would make things easier in one sense, but lower power which would make things worse in another. Perhaps someone could source some surplus police radars in the Ka-band and try a build with your capabilities?
But the radiation force scales directly with wavelength. I believe that the highest thrust you could ever get from a photon would be something like a gamma ray LASER. (Lethal of course.) By this logic I assume a very small emdrive with a very high frequency source, according to proponents of the theory, should have thrust comparable to a larger drive with a lower frequency. Considering that a smaller drive should weigh less too, this may be a viable way to detect forces. -
#1498 by SeeShells on 09 Jan, 2016 01:22
-
Thanks....
I hope that perhaps Shell can investigate this experimentally, given time. Apparently if Shell investigates this she would be the first one in the world to report such experimental data.
I have to admit, its this kind of thinking that got me excited about becoming a scientist many years ago. If you do good science, you can actually expand to the cumulative knowledge of mankind and, for a moment, know more about something than anyone else ever has. Shell seems to be committed to doing good science and has the right motivations.
One of the reasons I had designed the top tuning chamber was to run the top small tuning plate below and through the peak resonance and into the cutoff area and record the data. I'm sure I'll not be the first experimenter to do this in the worlds of tuning chambers but maybe the first looking for unusual data that may show up.
Just getting caught up on reading comments here. Some very good thoughts and ideas and even videos!
I would like to address one, that's the thermal comments of mwvp. VAXheadroom (what a great name, reminds me of a old video in the 80's) did a great post processing of the CSV data from mt CE frustum from a meep run by aero and found the exact opposite in thermal energy that mwvp suggested.
http://forum.nasaspaceflight.com/index.php?topic=39004.msg1472111#msg1472111
The large base showed very little thermal energy would be induced in the bottom and a 10 fold increase in the top small plate and even higher in the top Se center mode.
When I laid out the frustum for a mode TE012 it was for the high Q generating mode and one that was sought by EagleWorks, but then I visualized I could do several things with utilizing the dual opposing waveguides in the bottom large plate.
Everyone knows the frustum modes are created not only by the spacing of the two endplates but also by the width and angle of the cavity itself. It's what one would expect within the physical walls of the copper frustum. But there is one other thing that effects the mode development and hasen't been taken into account very often and that is the RF energy being inserted into the cavity. This was obvious to me from the dozens of meep simulations we ran with different antennas and placements, up, down, side, dipoles, snubs loops, I think we covered just about everything (well close).
I allowed the dual waveguides to radiate into the cavity creating a harmonic mode between themselves, this served as a launcher into the small end of the RF energy and one other thin happened, the bottom plate spread and deformed the mode spreading it out and allowing another non-deformed mode to use it to bounce off of it devoloping in the small end part of the frustum a TE01 or hybrid mode in the cavity. This is why Dr, Rodal said it doesn't look like any modes he has seen.
I guess the easiest way I can say this is the bottom energy (1800) out of phase from the small top mode is a kind of EM mirror focusing the energy into the top mode generation.
-
#1499 by VAXHeadroom on 09 Jan, 2016 01:49
-
...
In college I worked on a Data General Eclipse S-330 which had 64K RAM. One of the devices we had to make it run much faster was a fixed-head swap disk - one platter and one head over every track. I think it had 128KB of memory
OK, enough of that...
Initial thoughts...
1) open source, freely available development environment - I'm using Eclipse and MinGW currently.
2) standardized language (C++)
3) Cross-compilable across a short list of OS's - Windows & *nix variants
4) Open Source with configuration management (git)
5) Control definition files using standard mathematics notations - unlike meep which uses a Lisp variant. I realize this would make it incompatible with meep, but cheese and crackers is that language a mess A good example of what I would like to see would be POV-Ray's language... (www.povray.org)
6) built-in stock examples on which to run simulations to simplify debugging of new algorithms and provide built-in-test for data sets with known results. This might be provided as part of a distribution package, but having simple cylindrical and/or box cavities built in would provide quicker and less error-prone checks of new compilations (new operating systems etc).
7) a pre-compiler which would compile the control files to binary for faster run-time. User interface with standardized elements - too many people roll their own and make a mess of it...
At Digilab, a Cambride MA FTIR spectrometer manufacturer we used DG Eclipse S/130 minis. They had a 10 Gig Winchester drive; so named because of the removeable media. When it was calculating an FFT the hard drive made a characteristic rhythmic noise that would go on for as long as an hour sometimes, since the data was cached on the disk. We also used DG Novas for testing our interface boards. They used core memory so the paper tape loader stayed intact after a power cycle. The Eclipse had boot proms, very pricey in 1978 and used solid state memory. To make a hard-copy of the spectra, we used an ink-jet printer; a rarity back then.
That was almost certainly a 10MB Winchester drive, not 10gig! The first 1GB drive I ever saw was in 1988 - about 6"x12"x24" and was $25,000 (for a VAX 8340 - quad processors @~8Mhz each!). We had 8 of these HD's - 4GB with a shadow pair. $200K in hard drives!! That would be about 3,300 TB today
)
A good example of what I would like to see would be POV-Ray's language... (
User interface with standardized elements - too many people roll their own and make a mess of it...