Thursday, April 29, 2010

Faster than 20 crossings per second (but not much)

Re: the doorway conversation where we agreed that 20 shell crossings per second seemed awfully few, I made the following plot. It demonstrates that there are more like 150 or so for 101 particles (which was the number I used for the timing studies). I ran this on Jupiter and was careful that nobody else was using memory or CPU at the time. For 301 particles, there are around 50 crossings per second, which to me still seems slow.

Wednesday, April 28, 2010

x(m,t) attempt 1

Ultimately, it would be nice to have the position of a sheet be a function of the mass and the time. Potentially, this might mean we could use constant time-stepping rather than timestepping determined by the next sheet crossing (which slows the simulation down alot).

My first idea was to solve for the mass between 0 and position x at time t. Then I could potentially invert the relation to get x(m,t). Then we can take a time derivative to get the velocity as a function v(m,t). Here was my initial calculation:





This calculation can be seen in more detail by clicking on it, and zooming in with the browser.


This approach is failing because the sheet positions and ranks are still required, I had hoped they would drop out. In a sense at each position X all you need to know is the number of sheets interior to X, not their positions... but in order to know this at all X, you ultimately need the positions of all the sheets.

One question for Scott: in the x(m,t) picture you envisioned, were you thinking of hanging on to the discreteness of the particles, or were you thinking of a mass continuum?

Friday, April 23, 2010

resolution and time evolution study

I have discovered that the algorithm (for 301 particles) is not as instantaneous as I thought. The reason is that the time between successive collisions shrinks considerably as the simulation progresses. Thus as the system evolves, the rate of time slows down.

To figure out what a faster algorithm would have to accomplish, I've studied the time evolution in the mass sheet code, and also how the timing depends on the resolution (number of mass sheets).

In the two plots below, I have fixed the number of mass sheets to 101, and have evolved the system for a certain number of shell crossings (nc=[1,2,10,50,100,200,500,1000,2000,2200,2600,3000,5000,8000]). Real world computation time is simply proportional to the number of shell crossings. First, the phase space diagrams of these runs here:In the next plot I show the simulation time as a function of real world time:


At some times all the particles are scrunched around x=0 and there are lots and lots of shell crossings in a very short time. At other times the system is more spread out in the x direction, and there is therefore more elapsed time between shell crossings, thus the simulation evolves much faster. The number of windings that occur (and their phases) are highly relevant to the real world time that is taken up reaching a fixed time threshold in the simulation.

Since simulations with fewer particles evolve faster than those with more particles (more shell crossings are required to get to a particular end time as N is increased), the results of resolution studies sort of resemble the time evolution seen above. Below is a plot the simulation is evolved until it crosses some fixed time threshold. Each run has a different number of particles (N=[11,31,51,71,91,95,99,101,111,113,115,121,141,171,221,261]).
Below are three plots that show, as a function of N, the real world time it takes to reach a certain threshold in simulation evolution, the number of shell crossings (proportional to computational time), and the time after the final shell crossing.



Here we see the same sort of behavior. For the very unresolved runs the threshold time is reached after just one shell crossing. As the number of particles is increased the time of the first crossing is below the threshold, and (as discussed before) it takes a very long (real world) time to reach the threshold time because each shell crossing is happening sooner and sooner, so the time advance in the simulation slows down (until the pileup at x=0 is passed, at which point the evolution speeds up again).

In my implementation the scaling is somewhat worse than N*N, because of these jumps associated with the x=0 pileup.

It's clear that most of the time in the sim is spent when the majority of particles are crowded around zero. One possibility for speeding up the algorithm might be to come up with an effective "advance" to get the particles past this hangup point into the next winding. I worried however, because probably most of the energy transfer in the violent relaxation happens in this regime.