0 Members and 1 Guest are viewing this topic.
<HTML><HEAD> <TITLE>Theory Simulation</TITLE> <script type="text/javascript">// window.setInterval("run()",10) function run() { } function setup() { } xi0=0; xi1=0; // Initial side-to-side locations of the dots function movei0() { xi0=xi0+1; i0.style.left=xi0; xi0loc.innerHTML=xi0} function movei1() { xi1=xi1+1; i1.style.left=xi1; xi1loc.innerHTML=xi1} </script></HEAD><BODY onload="setup()" style="background-color:black;color:white;font-family:arial,helvetica,sans-serif;font-size:18pt"><blockquote> <center><H1>Theory Simulation</H1><br><br><tt><b id="i0" style="position:relative;left:0;top:0;font-size:60;color:yellow">.</b><b id="i1" style="position:relative;left:0;top:0;font-size:60;color:#0020ff">.</b></tt></center><p><a id="xi0loc"></a> <a id="xi1loc"></a><p><input type="button" value="Move Yellow" onclick="movei0()"/> <input type="button" value="Move Blue" onclick="movei1()"/><p>If you want any text here to provide instructions for the user, you can replace this with your own text. It's always worth doing this because you might forget how your own program works if you come back to it after a long break.</BODY></HTML>
I copied the java text
...and saved the file as simulation.htm, but when I opened it, it is the text that showed up, not the simulation, so I looked for a JavaScript tool on my browser, and I found one, so I copied the text in it, and when I tried to execute it, it showed this error:/*Exception: SyntaxError: expected expression, got '<'@Scratchpad/3:10*/
The first particle to be accelerated would resist to move because it would produce blueshift right away on the information coming from the second particle, and that second particle would only move after a while because it would take time for the information from the acceleration to reach it.
Resistance to acceleration is mass, so accelerating the first particle and stopping the acceleration before that information hits the second particle should give us the mass of the whole system, which is weird since the second particle has not been affected by the acceleration yet. Stopping the acceleration of the first particle means that it should decelerate to rest after a while until it doesn't produce anymore blueshift, and I figure that it should decelerate by the time the second particle would be accelerating, which means that the information from that second acceleration should hit the first particle at the moment it would be at rest, which means that that first particle should start accelerating again, and that it would do so while the second particle would be decelerating.
A particle would then be accelerating while the other would be decelerating and vice-versa later on. Of course, we could accelerate the first particle for a longer time, but I need to know what will happen if we stop the acceleration at the moment the information from the acceleration hits the second particle.
That time shifted motion is hard to illustrate with static diagrams, and I think it would also be hard to put into equations, but I hope it can be simulated. What needs to be simulated is doppler effect from a particular motion that becomes a cause for another motion, so I think we would need that the particles are sources of waves, but I'm afraid that computers cannot produce them fast and precise enough, so I guess that we will have to rely on timing beeps, which computers cannot provide with absolute accuracy either, so the system will probably drift after a while, but I hope it won't drift too much, and that we can use a way to correct the drift if necessary.
We want to see what will happen, so we need the particles to be as far as possible from one another on the screen...
To accelerate the first particle, we could move the left large bar a small distance, and double that distance each new beep.
Normally, to be more precise, we should account for what would happen inside the particle during its acceleration, thus for the motion of its components, represented by the left side and the right side of the vibrating large bar, but to simplify the problem, we might as well just use the constant timing between the left and the right side of the bar, and move the second side after the first one would have moved, thus reducing the distance between the small bars by doppler effect, but not the size of the particles, thus not the distance between the two sides of the large bars.
Quote from: Le Repteux on 07/08/2017 21:51:23The first particle to be accelerated would resist to move because it would produce blueshift right away on the information coming from the second particle, and that second particle would only move after a while because it would take time for the information from the acceleration to reach it.The first problem I see with this (ignoring the lack of any mechanism by which the first particle is accelerated) is how much it's going to move before it stops? How quickly will it accelerate and how quickly is that acceleration slowed as the perceived frequency of the signal from the second particle changes? As soon as particle A starts moving, the perceived frequency goes up, so does it stop instantly? This question then impacts on how the frequency of the signal from A to B will affect B, because if A stops straight away, it won't move any distance and B will detect no change.
QuoteResistance to acceleration is mass, so accelerating the first particle and stopping the acceleration before that information hits the second particle should give us the mass of the whole system, which is weird since the second particle has not been affected by the acceleration yet. Stopping the acceleration of the first particle means that it should decelerate to rest after a while until it doesn't produce anymore blueshift, and I figure that it should decelerate by the time the second particle would be accelerating, which means that the information from that second acceleration should hit the first particle at the moment it would be at rest, which means that that first particle should start accelerating again, and that it would do so while the second particle would be decelerating.I can't see how the acceleration and deceleration of A is going to measure the mass. I'm not convinced that you're doing anything involving mass after the initial acceleration of A, and that part of the process may happen in an instant right at the start. What happens after that appears to have more to do with how that energy is then shared with another particle bonded with the first. Anyway, if you double the amount of energy you're putting in, particle A is going to move further before it stops, and if you halve the energy you're putting in, it will stop sooner, so it looks as if you'll need to be able to vary how quickly particle A accelerates and decelerates under these different mechanisms (direct energy absorption with the initial move that kicks things off vs. acceleration control by perceived frequencies of each particle upon the other) depending on how much energy has been put into moving it. If it accelerates more quickly, it will perceive a stronger frequency change, so that may help decelerate it more quickly as the frequency goes higher, though as it decelerates it may then be slowed progressively more slowly until the frequency is back to the original value.
I don't know if we'll ever get to a working simulation, but, in the course of attempting to build one, this should force us to work out where maths is required and exactly what it has to do. I can already see that we need to establish details about the initial acceleration of particle A to spell out how instantaneous its change in speed is, and then we need rules about how it gets slowed down by its perceived frequency of B's signal, with that same rule controlling B's acceleration when it perceives a change in the frequency of the signal from A. We could program this in such a way that we can change the behaviour of these accelerations later just by changing values in control variables. That would be the safest way to do things if you aren't sure how quickly these accelerations should be handled.
QuoteA particle would then be accelerating while the other would be decelerating and vice-versa later on. Of course, we could accelerate the first particle for a longer time, but I need to know what will happen if we stop the acceleration at the moment the information from the acceleration hits the second particle.That seems to be an arbitrary timing because A won't know when the wobble in his signal reaches B
QuoteThat time shifted motion is hard to illustrate with static diagrams, and I think it would also be hard to put into equations, but I hope it can be simulated. What needs to be simulated is doppler effect from a particular motion that becomes a cause for another motion, so I think we would need that the particles are sources of waves, but I'm afraid that computers cannot produce them fast and precise enough, so I guess that we will have to rely on timing beeps, which computers cannot provide with absolute accuracy either, so the system will probably drift after a while, but I hope it won't drift too much, and that we can use a way to correct the drift if necessary.It should be possible to calculate exact timings for things even if we're moving the action on in jumps for the visual display, but it may involve more complex maths to get those exact values. I can't supply the right maths for that, but I'm sure we can get reasonable results just by working with jumps of varying granularity with a fixed frequency value for each jump, and we can change that granularity to see how it affects the results - they should be inaccurate with large jumps and get better with smaller jumps until there's no point in going smaller. (What I mean by this is that when the change in a perceived frequency can be shown by a curve on a graph, we can carry out a round of calculations at regular time intervals and use whichever frequency the graph gives us at that time point, applying it uniformly for that whole slice of time). The visual display won't need to change for each round if we're doing more fine-grained calculations, so it can be updated every now and then at a fixed frequency while we vary the rate of the underlying calculations.
QuoteTo accelerate the first particle, we could move the left large bar a small distance, and double that distance each new beep.I don't understand why you'd have repeated doublings.
QuoteNormally, to be more precise, we should account for what would happen inside the particle during its acceleration, thus for the motion of its components, represented by the left side and the right side of the vibrating large bar, but to simplify the problem, we might as well just use the constant timing between the left and the right side of the bar, and move the second side after the first one would have moved, thus reducing the distance between the small bars by doppler effect, but not the size of the particles, thus not the distance between the two sides of the large bars.I'm confused now as to what's what. If A and B are both large bars representing two particles, are we now to have each of these particles made of two parts as well? If so, each one could be represented by two large bars, and we'd then need clear rules to control how those two bars move relative to each other.
I think we should use realistic numbers, so the speed of light will be the one used for the signals. We don't have to work in seconds though - we're dealing with very small things very close together and moving tiny distances which we will show greatly enlarged and slowed on the screen. So, how far apart are the particles going to be? Perhaps 200 picometres (a fifth of a nanometre) would be a reasonable starting point if these particles are bonded atoms.
What kind of speed are we going to accelerate the first particle to? (The display can track the particles so that they always stay on the screen, so that shouldn't limit your choice.)
What frequency is the light that you're using for the signals? The "beeps" should represent the crests or troughs of waves in the light signal, so 1x10^15Hz might be a reasonable value, which is 1 per attosecond. (Milli, micro, nano, pico, femto, atto, zepto.) In the program we might use the variable t for time with t representing one zeptosecond, and d for distance with d representing one femtometre. (Light moves about a third of a picometre in one zeptosecond.)Do these sound like reasonable units and sizes? Check them to make sure by doing your own research if you aren't sure - I may have made big errors as this kind of stuff goes way outside my experience.
<?phpecho "Print this comment";?>
How about 1nm/s to begin with?
They sound good too, but I didn't go that far in my analysis yet, so I guess we will both have to get used to them.
While reading about JavaScript, I realize that it is commonly used with HTML, a language that I had already used about 20 years ago to build my own web pages, so it should help.
t=0; // time in zeptoseconds (milli, micro, nano, pico, femto, atto, zepto)d=200; // distance in picometresf=1000; // initial bonding-light frequency per zeptosecond
Just so you all know, I implemented a "code" bbc button above the posting box so you can insert lines of code into the forum and it will format correctly.
Quote from: Le Repteux on 10/08/2017 23:24:41How about 1nm/s to begin with?That sounds a bit low - the gas molecules around us bounce off each other at over a thousand miles an hour, and if we're working with zeptoseconds, it might take millions of years for the simulation to move a particle across the screen. A speed in m/s is the same value in nm/ns, so 500nm/ns ought to be a realistic speed to use.
I think we can make the initial acceleration of A instant, so the first bit of maths programming we need to write is going to be to handle the deceleration as A interacts with the signal from B, and that code needs to be adjustable so that we can change the deceleration rate just by changing a value in a single control variable. I'm going to think about that tomorrow. You might like to think about it too, and then we can compare notes and try to turn it into functional code.
I am having trouble understanding you original premise. Sure a program could be writen for anything but if the basic brick is faulty so will everything that follows be faulty.
How about simulating two cars exchanging sound waves then? We could build the software using that order of magnitude and add buttons to change the speed of the wave or the length of the steps later. What I want to study first is the way doppler effect from motion can become a cause for the same motion, and that principle should not depend on the kind of waves.
If the software works for sound, then we could try to simulate real particles with it. In my example with sound, I usually put the cars one sound second away from one another, but to have the time to examine the motion, I think five seconds would be better. I never gave a frequency to sound, so how about 1 kilohertz to begin with? 5,000 wavelengths between the two cars, that should be precise enough. We could use the speeds cars usually have, or even try to exceed the speed of sound with them to see how the software would react. I think that, as your simulation of MMx shows, the cars would take more and more time to accelerate whatever the rate of acceleration we choose, which is similar to mass increase in the case of particles.