My theoretical understanding of how an EMDrive works is fine
Yes, there is no doubt that 32 time periods is relatively nothing. I estimated it will take 100 to 1,000 longer time to get to steady state standing waves.
Quote from: TheTraveller on 07/21/2015 02:50 pmMy theoretical understanding of how an EMDrive works is fineThat's the problem, right there.
I plan to work on a GPU port of Meep to get it running 10x faster and have a cluster of machines on which I can / will run experiments as requested or available to help with the parameter studies and fundamentals.
I don't feel comfortable with cylindrical coordinates, but if someone wants to take a crack at converting the Cartesian coordinate model to a cylindrical coordinate model, here is what the documentation has to say.
Just curious, will you use CUDA or OpenCL ? CUDA only works with NVIDIA GPUs (proprietary), while OpenCL works with NVIDIA, AMD or Intel GPUs.
Quote from: notarget on 07/20/2015 08:34 pmI plan to work on a GPU port of Meep to get it running 10x faster and have a cluster of machines on which I can / will run experiments as requested or available to help with the parameter studies and fundamentals.Just curious, will you use CUDA or OpenCL ? CUDA only works with NVIDIA GPUs (proprietary), while OpenCL works with NVIDIA, AMD or Intel GPUs.
Quote from: aero on 07/21/2015 05:56 pmI don't feel comfortable with cylindrical coordinates, but if someone wants to take a crack at converting the Cartesian coordinate model to a cylindrical coordinate model, here is what the documentation has to say.Hey "aero" - meep's cyl coordinates are for 2D calculations using rotational symmetry. Since we have 3D spatial variation, that wouldn't work for us here...In order to fix meep's reduction to first order accuracy at boundaries due to the use of "stair step" geometry, we'd need to implement a new kernel based on the maxwell equations transformed into generalized curvilinear coordinates - or perhaps into an analytical spherical coordinate transformation if we're only going to model sections of a sphere... But then we'd have to have the input source conform to the analytic spherical coordinates. I'd prefer the generalized transform. This is not easy to do - though there's precedent for it and similarities to CFD methods, etc to draw upon.In the meantime - the meep formulation has some advantages - it's quick and simple, but as Rodal points out - we have to watch out for being misled on the quantitative accuracy of the simulations. A convergence study, where we'd validate that we are accurate - should show that we need to increase the density linearly to get more accurate results - a bummer in that better conformal methods have 2nd order (faster) grid convergence.
Quote from: flux_capacitor on 07/21/2015 06:08 pmWhat about openblas?BLAS isn't used here - the curl evaluations are hand coded. The main issue is yo avoid copying in and out of GPU memory, so in concept it's simple: copy all field data into GPU and run loops there.
What about openblas?
Quote from: CW on 07/21/2015 05:30 amIf it's about accelerating simulations, couldn't we theoretically try and make something like the SETI client and distribute prepared packages to those willing to donate CPU time to simulate a ton of EM drive configurations - even over longer periods of time and operation?We could make a MEEP Docker package that gets the data either from the Google drive or the Git repo. Anybody with a Windows, Mac, or Linux box can run it.
If it's about accelerating simulations, couldn't we theoretically try and make something like the SETI client and distribute prepared packages to those willing to donate CPU time to simulate a ton of EM drive configurations - even over longer periods of time and operation?
Quote from: bprager on 07/21/2015 03:38 pmQuote from: CW on 07/21/2015 05:30 amIf it's about accelerating simulations, couldn't we theoretically try and make something like the SETI client and distribute prepared packages to those willing to donate CPU time to simulate a ton of EM drive configurations - even over longer periods of time and operation?We could make a MEEP Docker package that gets the data either from the Google drive or the Git repo. Anybody with a Windows, Mac, or Linux box can run it.Docker is still Linux, so you'd still have Linux VM overhead on Windows and OS X. It's not an OS-independent lightweight VM like the JVM or Parrot. It's just a bit smaller than VirtualBox, and mostly meant for prototyping web apps on developers' laptops, not CPU-intensive scientific computing like meep. http://docs.docker.com/installation/windows/http://docs.docker.com/installation/mac/
Another thougth.
I show below first the steady state stresses and below, the previously computed stresses at 0.013 microseconds by Meep/Post-Processed by Wolfram Mathematica
Quote from: Ricvil on 07/21/2015 02:16 pmAnother thougth.upon reflection light undergoes a 180 degree phase change on metal surfaces
Quote from: Rodal on 07/21/2015 07:15 pmI show below first the steady state stresses and below, the previously computed stresses at 0.013 microseconds by Meep/Post-Processed by Wolfram MathematicaQualitatively these look very similar which is/was encouraging! Also - the stairstep boundary conditions on meep actually seem to be OK - note the shape of the stress function as it approaches the wall seems smooth and similar to the analytical standing wave solution.What I want to see is some of the qualitative behavior surmised by some (Traveler I think?) where the wave dissipates into the big end, aliasing into the wall as dissipation (ultimately) into thermal energy, creating a kind of momentum sink. If I understand correctly - we would need to model the dissipative wall effects in meep explicitly in the boundary condition, as this isn't a "multi-physics" package as was pointed out. We'd have whatever surface currents exist in the walls creating a dissipation into heat based on material characteristics, certainly do-able.Do I have this right? Is it important in the presumed phenomenology?