Quote from: Notsosureofit on 02/17/2015 11:36 amQuote from: Rodal on 02/17/2015 01:40 amQuote from: Notsosureofit on 02/17/2015 12:01 am@ RODALArrgh, Mondays !Looked over my bleary weekend, noticed I was using diameters AGAIN !Mode Frequency (MHz) Quality Factor, Q Input Power (W) Mean Thrust (μN) Calculated w/o dielectricTE012 1880.4 22000 2.6 55.4 10.8TM212 1932.6 7320 16.9 91.2 38.5TM212 1936.7 18100 16.7 50.1 93.5TM212 1937.115 6726 50 66 104.0Anyway, shows it pays to rewrite everything in the same place !....Great !In order to understand the above, (please correct me if I am wrong), you used in your formula the actual frequency and mode shapes that took place in the EM Drive experiment with the dielectric so in that sense you did calculate with the dielectric in a very restricted sense.FYICleanup and de-typo of the take on applying the Equivalence Principle.The proposition that dispersion caused by an accelerating frame of reference implied an accelerating frame of reference caused by a dispersive cavity resonator. (to 1st order using massless, perfectly conducting cavity, no dielectric)Starting with the expressions for the frequency of a cylindrical RF cavity:f = (c/(2*Pi))*((X/R)^2+((p*Pi)/L)^2)^.5For TM modes, X = X[sub m,n] = the n-th zero of the m-th Bessel function.[1,1]=3.83, [0,1]=2.40, [0,2]=5.52 [1,2]=7.02, [2,1]=5.14, [2,2]=8.42, [1,3]=10.17, etc.and for TE modes, X = X'[sub m,n] = the n-th zero of the derivative of the m-th Bessel function.[0,1]=3.83, [1,1]=1.84, [2,1]=3.05, [0,2]=7.02, [1,2]=5.33, [1,3]=8.54, [0,3]=10.17, [2,2]=6.71, etc.Rotate the dispersion relation of the cavity into Doppler frame to get the Doppler shifts, that is to say, look at the dispersion curve intersections of constant wave number instead of constant frequency.df = (1/(2*f))*(c/(2*Pi))^2*X^2*((1/Rs^2)-(1/Rb^2))and from there the expression for the acceleration g from:g = (c^2/L)*(df/f) such that:g = (c^2/(2*L*f^2))*(c/(2*Pi))^2*X^2*((1/Rs^2)-(1/Rb^2))Using the "weight" of the photon in the accelerated frame from:"W" = (h*f/c^2)*g => "W" = T = (h/L)*dfgives thrust per photon:T = (h/(2*L*f))*(c/(2*pi))^2*X^2*((1/Rs^2)-(1/Rb^2))If the number of photons is (P/hf)*(Q/2*pi) then:NT = P*Q*(1/(4*pi*L*f^3))*(c/(2*pi))^2*X^2*((1/Rs^2)-(1/Rb^2))This does fit (as far as I've gotten) the concept of a self-accelerating Dirac wavepacket (which does conserve momentum).Slow goin', thanks for your patience.Excellent! Thank you for posting the complete equations.One suggestion: In the expression NT = P*Q*(1/(4*pi*L*f^3))*(c/(2*pi))^2*X^2*((1/Rs^2)-(1/Rb^2))the speed of light in vacuum "c" appears in the numerator without being divided by the SquareRoot of the relative electric permittivity and relative magnetic permeability.Since the relative electric permittivity of the dielectric is 2.3, this would decrease the values in the table by a factor of Sqrt[2.3]=1.52 if the whole cavity would be occupied by the dielectric. Granted that only a portion of the truncated cone contains the dielectric, which will decrease the dividing factor, but any amount will reduce the effective value of c in the medium, giving lower thrust and hence values closer to the experimental measurements. For example, very roughly, assuming that 1/3 of the longitudinal length is occupied by the dielectric, and using the average as a medium with those average properties, Sqrt[(2.3*1/3)+1*(2/3)]=1.20, the thrust values would be reduced by a factor of 1.20, so for the most important test (the one in recently performed in vacuum, -the other experimental values may have been affected by thermal convection effects in the air and are therefore less reliable-), instead of 104 μN you would get 87 μN, which better compares with the experimental value of 66 μN.
Quote from: Rodal on 02/17/2015 01:40 amQuote from: Notsosureofit on 02/17/2015 12:01 am@ RODALArrgh, Mondays !Looked over my bleary weekend, noticed I was using diameters AGAIN !Mode Frequency (MHz) Quality Factor, Q Input Power (W) Mean Thrust (μN) Calculated w/o dielectricTE012 1880.4 22000 2.6 55.4 10.8TM212 1932.6 7320 16.9 91.2 38.5TM212 1936.7 18100 16.7 50.1 93.5TM212 1937.115 6726 50 66 104.0Anyway, shows it pays to rewrite everything in the same place !....Great !In order to understand the above, (please correct me if I am wrong), you used in your formula the actual frequency and mode shapes that took place in the EM Drive experiment with the dielectric so in that sense you did calculate with the dielectric in a very restricted sense.FYICleanup and de-typo of the take on applying the Equivalence Principle.The proposition that dispersion caused by an accelerating frame of reference implied an accelerating frame of reference caused by a dispersive cavity resonator. (to 1st order using massless, perfectly conducting cavity, no dielectric)Starting with the expressions for the frequency of a cylindrical RF cavity:f = (c/(2*Pi))*((X/R)^2+((p*Pi)/L)^2)^.5For TM modes, X = X[sub m,n] = the n-th zero of the m-th Bessel function.[1,1]=3.83, [0,1]=2.40, [0,2]=5.52 [1,2]=7.02, [2,1]=5.14, [2,2]=8.42, [1,3]=10.17, etc.and for TE modes, X = X'[sub m,n] = the n-th zero of the derivative of the m-th Bessel function.[0,1]=3.83, [1,1]=1.84, [2,1]=3.05, [0,2]=7.02, [1,2]=5.33, [1,3]=8.54, [0,3]=10.17, [2,2]=6.71, etc.Rotate the dispersion relation of the cavity into Doppler frame to get the Doppler shifts, that is to say, look at the dispersion curve intersections of constant wave number instead of constant frequency.df = (1/(2*f))*(c/(2*Pi))^2*X^2*((1/Rs^2)-(1/Rb^2))and from there the expression for the acceleration g from:g = (c^2/L)*(df/f) such that:g = (c^2/(2*L*f^2))*(c/(2*Pi))^2*X^2*((1/Rs^2)-(1/Rb^2))Using the "weight" of the photon in the accelerated frame from:"W" = (h*f/c^2)*g => "W" = T = (h/L)*dfgives thrust per photon:T = (h/(2*L*f))*(c/(2*pi))^2*X^2*((1/Rs^2)-(1/Rb^2))If the number of photons is (P/hf)*(Q/2*pi) then:NT = P*Q*(1/(4*pi*L*f^3))*(c/(2*pi))^2*X^2*((1/Rs^2)-(1/Rb^2))This does fit (as far as I've gotten) the concept of a self-accelerating Dirac wavepacket (which does conserve momentum).Slow goin', thanks for your patience.
Quote from: Notsosureofit on 02/17/2015 12:01 am@ RODALArrgh, Mondays !Looked over my bleary weekend, noticed I was using diameters AGAIN !Mode Frequency (MHz) Quality Factor, Q Input Power (W) Mean Thrust (μN) Calculated w/o dielectricTE012 1880.4 22000 2.6 55.4 10.8TM212 1932.6 7320 16.9 91.2 38.5TM212 1936.7 18100 16.7 50.1 93.5TM212 1937.115 6726 50 66 104.0Anyway, shows it pays to rewrite everything in the same place !....Great !In order to understand the above, (please correct me if I am wrong), you used in your formula the actual frequency and mode shapes that took place in the EM Drive experiment with the dielectric so in that sense you did calculate with the dielectric in a very restricted sense.
@ RODALArrgh, Mondays !Looked over my bleary weekend, noticed I was using diameters AGAIN !Mode Frequency (MHz) Quality Factor, Q Input Power (W) Mean Thrust (μN) Calculated w/o dielectricTE012 1880.4 22000 2.6 55.4 10.8TM212 1932.6 7320 16.9 91.2 38.5TM212 1936.7 18100 16.7 50.1 93.5TM212 1937.115 6726 50 66 104.0Anyway, shows it pays to rewrite everything in the same place !....
@ RODALPS: Got plenty of big vacuum chambers here, (couple 6' x 8' cylinders, etc.) no torsion balances left though (not put together anyway .. might have parts) and a big lack of time !
Quote from: Notsosureofit on 02/17/2015 02:06 pm@ RODALPS: Got plenty of big vacuum chambers here, (couple 6' x 8' cylinders, etc.) no torsion balances left though (not put together anyway .. might have parts) and a big lack of time !That makes for such an attractive setup, that anyone would gladly trudge through 7 ft of snow !
Quote from: aero on 02/16/2015 02:00 pm...As for whether or not meep integrates the equations, I think it is a matter of terminology...Numerical Integration involves approximating definite integrals by summing discretized areas. This is not what the Finite Difference method does. Sorry about being perhaps overly rigorous in the use of the word "integrate". I point this (finite? pun-intended ) difference because it is important to understand the convergence problems with Finite Difference methods (as opposed to integration methods like the Boundary Element method, for example, or methods based on variational principles like the Finite Element Method).What the Finite Difference method does is instead to approximate solutions to differential equations using finite differences to approximate derivatives. The idea of a finite difference method is the transformation of a continuity domain to a discrete set of points, the mesh. In every grid point the given differential operator is approximated by a difference-operator. The issue is that numerically, numerical differentiation is always a much trickier problem than numerical integration (from a convergence viewpoint).The Finite Difference method is a very old method (references going back to the 19th century) but great progress was made using it during and after World War II, due to the development of the digital computer, due to Von Neuman and Friederichs, mainly due to the Manhattan Project.At MIT's ASRL very complex Finite Difference codes were developed, for example the PETROS code:http://bit.ly/1AJ5Vgt in addition to Finite Element and other types of numerical analyses.
...As for whether or not meep integrates the equations, I think it is a matter of terminology...
....To-wit: Finite Element methods give you both an approximation to the exact solution and a measure of how good that approximation is, even if the exact solution is not easily obtained. Finite Difference schemes provide no such information regarding the correctness of the results they provide.
Has anyone looked at rangling some cloud vm time to run these processes. You can find the amazon compute vm prices here http://aws.amazon.com/ec2/pricing/and the azure compute vm prices herehttp://azure.microsoft.com/en-us/pricing/details/virtual-machines/not sure what the runtime looks like but I would hazard a guess that you could figure out a cheap enough solution that allows you to get results in the least amount of time.
Quote from: birchoff on 02/17/2015 03:50 pmHas anyone looked at rangling some cloud vm time to run these processes. You can find the amazon compute vm prices here http://aws.amazon.com/ec2/pricing/and the azure compute vm prices herehttp://azure.microsoft.com/en-us/pricing/details/virtual-machines/not sure what the runtime looks like but I would hazard a guess that you could figure out a cheap enough solution that allows you to get results in the least amount of time.I've looked at it but I'm not going to take the responsibility of paying for and trying to figure out how to use their systems, and to install and use meep on those systems.I do have an opinion. The most understandable documentation of the available capabilities is from Google.https://cloud.google.com/compute/pricingBut at only 100 GB memory for a high memory compute configuration, I'd be concerned about size of the model. For a 3D model, Meep memory requirements go up by a factor of 8 for each doubling of the resolution and compute requirements by a factor of 16 for the same doubling. If someone wanted to do this, it would be necessary to establish the model at low resolution on a convenient machine, then calculate the resources needed by the problem running at the resolution required for viable results.Meep was designed to run massive problems at high resolution on supercomputers. Sixteen processors each with 6.5 GB ram is not really a very impressive supercomputer. And I wonder, can these cloud based compute engines guarantee model execution synchronization for the duration of a run that may consume hours of CPU? If it can't be synchronized then AIUI all the CPU's wait for the slowest partition to keep up. That could get costly in a hurry.I have designed and priced a custom computer that could provide a very good basis for estimating the resources needed to run high fidelity problems. It was priced at $2038.96 (USD), a firm quote, tax included. It is about 1/3 the machine referred to above. (Six cores with 32 GB DDR4 memory) I'm not going to take the responsibility for paying for that machine, either, though I would love to have it.
The EmDrive's resonant cavity has the characteristics as of cutoff waveguide. By reference to the phenomena of electromagnetic wave anomalous propagation in the cutoff waveguide, the fact that the electromagnetic wave can be reflected without metal surface in the cutoff waveguide is presented in the paper.At the same time, another fact that the electromagnetic wave distribution in the EmDrive's resonant cavity showing a characteristic of evanescent wave is presented also. It is a kind of electromagnetic wave anomalous propagation. This anomalous propagation can be described by the photon tunneling effect, consistent with quantum field theory.At last,the opinion that EmDrive revealing some properties of background vacuum is put forward in the paper,and the introduction of the virtual photon process may be a new method to analyze the momentum conservation of EmDrive.
https://iafastro.directory/iac/archive/browse/IAC-13/C4/P/16863/...
Nice to know someone has looked at it. Was just wondering if these computation limitations could be simply solved by the application of a little sprinkle of the cloud. As for paying for access to the resources, I guess the question is how badly do we want accurate results.
Quote from: aero on 02/17/2015 05:31 pmQuote from: birchoff on 02/17/2015 03:50 pmHas anyone looked at rangling some cloud vm time to run these processes. You can find the amazon compute vm prices here http://aws.amazon.com/ec2/pricing/and the azure compute vm prices herehttp://azure.microsoft.com/en-us/pricing/details/virtual-machines/not sure what the runtime looks like but I would hazard a guess that you could figure out a cheap enough solution that allows you to get results in the least amount of time.I've looked at it but I'm not going to take the responsibility of paying for and trying to figure out how to use their systems, and to install and use meep on those systems.I do have an opinion. The most understandable documentation of the available capabilities is from Google.https://cloud.google.com/compute/pricingBut at only 100 GB memory for a high memory compute configuration, I'd be concerned about size of the model. For a 3D model, Meep memory requirements go up by a factor of 8 for each doubling of the resolution and compute requirements by a factor of 16 for the same doubling. If someone wanted to do this, it would be necessary to establish the model at low resolution on a convenient machine, then calculate the resources needed by the problem running at the resolution required for viable results.Meep was designed to run massive problems at high resolution on supercomputers. Sixteen processors each with 6.5 GB ram is not really a very impressive supercomputer. And I wonder, can these cloud based compute engines guarantee model execution synchronization for the duration of a run that may consume hours of CPU? If it can't be synchronized then AIUI all the CPU's wait for the slowest partition to keep up. That could get costly in a hurry.I have designed and priced a custom computer that could provide a very good basis for estimating the resources needed to run high fidelity problems. It was priced at $2038.96 (USD), a firm quote, tax included. It is about 1/3 the machine referred to above. (Six cores with 32 GB DDR4 memory) I'm not going to take the responsibility for paying for that machine, either, though I would love to have it.Nice to know someone has looked at it. Was just wondering if these computation limitations could be simply solved by the application of a little sprinkle of the cloud. As for paying for access to the resources, I guess the question is how badly do we want accurate results.
Quote from: birchoff on 02/17/2015 06:58 pmQuote from: aero on 02/17/2015 05:31 pmQuote from: birchoff on 02/17/2015 03:50 pmHas anyone looked at rangling some cloud vm time to run these processes. You can find the amazon compute vm prices here http://aws.amazon.com/ec2/pricing/and the azure compute vm prices herehttp://azure.microsoft.com/en-us/pricing/details/virtual-machines/not sure what the runtime looks like but I would hazard a guess that you could figure out a cheap enough solution that allows you to get results in the least amount of time.I've looked at it but I'm not going to take the responsibility of paying for and trying to figure out how to use their systems, and to install and use meep on those systems.I do have an opinion. The most understandable documentation of the available capabilities is from Google.https://cloud.google.com/compute/pricingBut at only 100 GB memory for a high memory compute configuration, I'd be concerned about size of the model. For a 3D model, Meep memory requirements go up by a factor of 8 for each doubling of the resolution and compute requirements by a factor of 16 for the same doubling. If someone wanted to do this, it would be necessary to establish the model at low resolution on a convenient machine, then calculate the resources needed by the problem running at the resolution required for viable results.Meep was designed to run massive problems at high resolution on supercomputers. Sixteen processors each with 6.5 GB ram is not really a very impressive supercomputer. And I wonder, can these cloud based compute engines guarantee model execution synchronization for the duration of a run that may consume hours of CPU? If it can't be synchronized then AIUI all the CPU's wait for the slowest partition to keep up. That could get costly in a hurry.I have designed and priced a custom computer that could provide a very good basis for estimating the resources needed to run high fidelity problems. It was priced at $2038.96 (USD), a firm quote, tax included. It is about 1/3 the machine referred to above. (Six cores with 32 GB DDR4 memory) I'm not going to take the responsibility for paying for that machine, either, though I would love to have it.Nice to know someone has looked at it. Was just wondering if these computation limitations could be simply solved by the application of a little sprinkle of the cloud. As for paying for access to the resources, I guess the question is how badly do we want accurate results.Not so much accurate results. The results I have presented are accurate to second order, for the problem evaluated. More like more representative problems, higher fidelity models (3D, and resolving smaller gaps, for example), that could be achieved with more computing power.I have calculated error bounds, the magnitude of step size squared for my current run, which I hope to post in about 6 hours.delta s ~= 0.023 mm = 0.000023 meters, (delta s)^2 =5.29E-010delta t ~= 0.0001071422 sec, (delta t)^2 = 1.1479455161248E-008 s^2Those error bounds seem acceptable to me for the problems I am evaluating. The errors inherent in the problem formulated to represent characteristics of the actual EM thurster/vacuum chamber are far, far larger than the computational errors of the simulation.I kind of wish people would stop posting their concern about numerical computational deficiencies here. If they have a valid concern then they really should take it up with MIT, where the codes were written, or perhaps ONR, DARPA who spent the money to pay for the development. Maybe ONR/DARPA should ask for their money back?Or PM me, I can point them to several online sites giving results that scrutinise meep accuracy.
...Actually the basis of the exact solution (for the truncated cone microwave cavity) goes back to the great US engineer Schelnukoff in 1938 . ...
He crossed Siberia into Manchuria and then Japan before settling into Seattle in 1921. There he received bachelor's and master's degrees in mathematics from the State College of Washington, now the University of Washington, and in 1928 received his Ph.D. from Columbia University for his dissertation On Certain Properties of the Metrical and Generalized Metrical Groups in Linear Spaces of n Dimension....., Schelkunoff joined Western Electric's research wing, which became Bell Laboratories. In 1933 he and Sally P. Mead began analysis of waveguide propagation discovered analytically by their colleague George C. Southworth. Their analysis uncovered the transverse modes. Schelkunoff appears to have been the first to notice the important practical consequences of the fact that attenuation in the TE01 mode decays inversely with the 3/2 power of the frequency. In 1935 he and his colleagues reported that coaxial cable, then new, could transmit television pictures or up to 200 telephone conversations.
...I have calculated error bounds, the magnitude of step size squared for my current run, which I hope to post in about 6 hours.delta s ~= 0.023 mm = 0.000023 meters, (delta s)^2 =5.29E-010delta t ~= 0.0001071422 sec, (delta t)^2 = 1.1479455161248E-008 s^2Those error bounds seem acceptable to me for the problems I am evaluating. The errors inherent in the problem formulated to represent characteristics of the actual EM thurster/vacuum chamber are far, far larger than the computational errors of the simulation.I kind of wish people would stop posting their concern about numerical computational deficiencies here. If they have a valid concern then they really should take it up with MIT, where the codes were written, or perhaps ONR, DARPA who spent the money to pay for the development. Maybe ONR/DARPA should ask for their money back?...
We are discussing the NASA experiments, and the proposed theoretical explanations, asking and examining all kinds of questions. Numerical solutions (related to EM Drive Developments - space flight applications) deserve equal examination, not less, than the examination of experiments and the examination of theoretical explanations.
...So what do you propose as a resolution to your critique?
.. it is critical, to assess results of a numerical solution, to compare the results of a numerical solution (for example Finite Difference method) to an exact solution. In this case, an exact solution to a cylindrical cavity exists (http://en.wikipedia.org/wiki/Microwave_cavity#Cylindrical_cavity), and it would be worthwhile to compare how far is the MEEP solution for a resonant cylindrical cavity, say of a diameter=Sqrt[BigDiameterOfTruncatedCone * SmallDiameterOfTruncatedCone]=0.21060 m and same axial length, with the same material inputs and mesh as used for the Finite Difference solution of the Truncated Cone. ....
The accuracy issues we are discussing are not related to any bugs or issues concerning the people at MIT that wrote the program, they are issues inherent to the Finite Difference method. All numerical methods have numerical issues of different kinds. The purpose to discuss these issues here in an open forum is to examine the numerical solutions concerning EM Drive for space flight applications, just like we examine the experiments and the theoretical explanations. We are discussing the NASA experiments, and the proposed theoretical explanations, asking and examining all kinds of questions. Numerical solutions (related to EM Drive Developments - space flight applications) deserve equal examination, not less, than the examination of experiments and the examination of theoretical explanations.