c, the speed of light, and the BPhoton

Sorry, I forgot about the -Y giving a slightly different path. This is the difference between a neutron and a proton or an electron and a nectron. Notice the larger hole through the center of the -Y spin which I take as being a proton/electron since they have more through-charge than a neutron/nectron.

Here are 3 images showing how the rotation offset affects the path.

The X spin level offset by 90°:



The Y spin level offset by 90°:



The Z spin offset by 90°:

Note that all of those last 3 images have full spin set of A, X, Y and Z and I am changing the rotation offset of each spin level individually.

Jared Magneson wrote:That sure makes things easier, Nevyn!

But wouldn't that only be true along one spin-set... Uhm, direction? What if we have a -x spin instead of a positive in there, or combinations of these? It seems like there are four possible next-spin-stack motions, as there's no reason a z-spin couldn't come before an x-spin (that I can think of).

There may be a reason why it always moves in alphabetical order, although this would depend on the very first spin levels added. That is, starting with a BPhoton with an axial spin, we could add the next spin level about either X, Y or Z. It really depends on what axis the axial spin is rotating around. Once we have a full spin set though, the same order will remain for all added spin sets. This is because of the energy provided by each spin level.

When looking at a full spin set, X, Y and Z, the X level is providing less energy than the Y or Z. Therefore, it is easier to add a new X spin level on top than it is Y because the X spin if offering the least resistance to the new spin level.

So we could have the following starting setups:

A, X, Y, Z
A, X, Z, Y
A, Y, Z, X
A, Y, X, Z
A, Z, X, Y
A, Z, Y, X

But once we have that first spin set, then the same order will be used for all subsequent spin sets.

I have implemented my Pivoter equation in OpenCL, attached a 3D graphics engine to it so I can see the results and am happy to report that it works perfectly. I can generate a single spin transform for each photon that represent all of its spin levels. The spin transform is then applied directly to the BPhoton node and it is placed into the correct position with the right orientation.

I then went on to add linear velocity to the photons. I calculate this as a position vector but I also merge it into the spin transforms to get a single final transform for each photon that includes its spin and velocity all in one. Unfortunately, that final transform is not working as it should so I still have some issues to track down.

Until I get that working I am just using the position vector directly and keep the linear transform and spin transforms separate in the 3D scene graph. This works but it seems to be doing something weird with photons that have a top level X spin. They disappear. If I look around the scene I can see them way off in the distance but can never catch them. This only happens if I give it a velocity though. Turn that off and they all show up correctly. Really strange issue and I am struggling to see where it is happening.

The performance is pretty good with 1000 photons. It still works with 100,000 photons but is sluggish. If I try it with 1,000,000 photons it never seems to load. It allocates my memory buffers pretty quickly but then seems to go no where but is using 100% of the CPU. At this stage my guess is that the 3D graphics engine is struggling with 1,000,000 spheres (actually it is 2,000,000 because I use 2 spheres per BPhoton, 1 is wireframe so I can see the rotations). I'll have to work out how much memory that is using on the graphics card too, it might be too much for it (but I have 3Gb of mem on my card so it should be fine, but the 3D engine also wants to use some of that).

All-in-all I am making good progress. I'll spend a bit more time on these bugs and then get into the collisions.

Fixed up the velocity problem which turned out to be how I was addressing memory in the GPU. I thought I was mapping the memory correctly, but evidently, I wasn't. So now I can calculate the complete transform for a photon given its position, velocity and spin data.

I also made some improvements to the 3D side of things to see if it would help it work with more photons. I managed to reduce the memory consumption a lot (I was giving it 10GB and it still ran out on 1,000,000 photons) but it still runs slow with 100,000 photons. The calculations take about 50ms with 100,000 photons each with 20 possible spin levels which is about 20 frames/s. The 3D engine takes more time though so it looks really slow. The calculations are disconnected from the 3D rendering so it will keep calculating away even if the scene is not being updated. It would be fine for generating a video, which I have the code for but haven't tried it on this project yet.

On to the collisions!

I've derailed this thread enough so I won't keep posting about this app.

Sorry, one more post with the sad news that my equation doesn't quite work. It looked good until I started to record the path and then I could see that the spin level relationships were not correct. I was trying to avoid using Miles angular velocity equation (because it contains a couple of expensive square roots) but in the end I could not. Once I switched out the velocity part of my equation and replaced it with Miles angular velocity equation, everything worked as I expected.

My equation was: 2Pi * vt / 8r.

This is Miles angular velocity equation: w = sqrt( 2 * r * sqrt( v^2 + r^2 ) - 2 * r^2 ).
That gives you the tangential velocity as traveled on the circumference. I replaced the v in my equation with the w of this one and everything worked fine. That is how it has been implemented in SpinSim minus the 2Pi on the front. I'm not sure if I need that 2Pi or not but it doesn't change the relationship between levels, only the values themselves.

Final equation: Angle = 2Pi * sqrt( 2 * r * sqrt( v^2 + r^2 ) - 2 * r^2 ) * time / 8r

That's impressive, Nevyn, looking forward to see the results!

.
Sorry for the delay, I've been occupied by plenty of real world interruptions here.

Nevyn, De-railing is a feature, not a bug. I went to http://www.nevyns-lab.com/mathis/app/SpinSimulator/ - hoping to see your latest work. No luck, but I still enjoy reviewing it. Please consider a “show  coordinates” function with the b-photon’s “current location”, or allow the user to choose a marker in order to review its specific coordinates, or allow the user to set the b-photon coordinates directly (assuming the location is on the manifold surface).  

Nevyn wrote. “Here is a photon with A, X, Y and Z spins. We want to rotate that around the Y axis to add an axial spin level.”

Airman. You included a superimposed arrow representing the presumed new spherical axis. Imo spinning around the Y axis makes a poor choice. What do you get if you spin an X,Y,Z,X rotated at 45deg from your previous choice, perpendicular to the spin image’s long axis (as viewed down the z axis)? In other words, turn your superimposed axis neg 45deg (CCW about the z-axis). What will the final axial spins look like then? Does that change affect the final energy?
.

LongtimeAirman wrote:.Nevyn, De-railing is a feature, not a bug.

Well that's good, because derailing is my specialty!

LongtimeAirman wrote:I went to http://www.nevyns-lab.com/mathis/app/SpinSimulator/ - hoping to see your latest work.

All of the work I have been discussing in the last few days is not a part of SpinSim. I am doing it in OpenCL in order to use the graphics card processors and I couldn't do that in the browser without using a third party plugin. Right now it produces the same results (spins) as SpinSim so there is no difference, yet.

LongtimeAirman wrote:No luck, but I still enjoy reviewing it. Please consider a “show  coordinates” function with the b-photon’s “current location”, or allow the user to choose a marker in order to review its specific coordinates, or allow the user to set the b-photon coordinates directly (assuming the location is on the manifold surface).

I'm not sure how useful those coordinate are. comparing marker coords could be useful but I think it is the relationships between them that matters more than the specific coordinates. Setting the coord would be too cumbersome. How would the user know what coords to use?

LongtimeAirman wrote:
Nevyn wrote. “Here is a photon with A, X, Y and Z spins. We want to rotate that around the Y axis to add an axial spin level.”

Airman. You included a superimposed arrow representing the presumed new spherical axis. Imo spinning around the Y axis makes a poor choice. What do you get if you spin an X,Y,Z,X rotated at 45deg from your previous choice, perpendicular to the spin image’s long axis (as viewed down the z axis)? In other words, turn your superimposed axis neg 45deg (CCW about the z-axis). What will the final axial spins look like then? Does that change affect the final energy?
.

You can't do that because the spin axis must be orthogonal to the previous spin axis. So once you set X, Y and Z, all spin axes must be on one of those dimensions.

.
Nevyn wrote. I'm not sure how useful those coordinate are. comparing marker coords could be useful but I think it is the relationships between them that matters more than the specific coordinates. Setting the coord would be too cumbersome. How would the user know what coords to use?

Airman. What I was looking for was some way to “dial-in” a b-photon location using the current spin set, to identify the 45deg maximum extent position I mentioned earlier and to “take its picture” for discussion.

Nevyn wrote. You can't do that because the spin axis must be orthogonal to the previous spin axis. So once you set X, Y and Z, all spin axes must be on one of those dimensions.

Airman. While it's true that any new end-over-end spin must be orthogonal to the previous end-over-end x-spin; I don't believe that constraint is true for a new spherical axis. Using the horizontally oriented X,Y,Z,X, spin set, a vertical collision can cause a spherical rotation orthogonal to the top level horizontal spin set at any xy angle - not limited to the y-axis alone.  
.

What type of collision could create an axial spin instead of an end-over-end spin? What makes the axial spin wait for 3 inner levels before adding another one? The higher axial spin becomes a special case, not a natural phenomenon. It just makes everything ugly and is unnecessary. I prefer to clean the theory rather than dirty the details.

It could be that axial spin and direction are related:
A photon that goes through X starts rotating around X, and when it reaches c it starts spinning about X; the same happens for Y, first an axial rotation and then the new Y spin; and so on.
There is no problem at having a rotation at each spin and not at a full level only, at least until we see the new paths.