Possible Charged Particle Field

.
Jared, I don't know about you, but I'm not script smart. I'd be more than happy to work with you to learn this app to the extent that you might need it. Helping you would help me learn it. I can't say I can teach it since there's a great deal about it I haven't begun to figure out and it's not finished yet. As Nevyn says, programming is a tool. It's more important to understand how to work with it.

I’ve got a tack for you Nevyn, but fair’s fair, you deserve credit. By expansion theory, we know charge particles are expanding. We also know, given an interval of time, a charged particles’ emissions will expand outward from the particle, as on an expanding spherical layer. Have you told us something we don’t know? I don’t think so. On the other hand, I believe this development of yours improves our understanding of relativity. Now we can say – of course! We can clearly see the both the expanding charge particle and its expanding emission field, easily adjusting for micro or macro.

I'm surprised you feel implementing the R function is a problem. I believe we already know the radius function R. All objects in the universe are expanding – accelerating - at the same rate. For Earth, the radius doubles every 19 minutes or so. Why there’s a post or two on the subject here at this site. As requested, just poking.
 
All radii and distances are time dependent variables – the relativistic perspective. We know that the particle radius should be time dependent, equal to a distance, r0 at some position p0 at time t0, r(t)= p(0) + r(0)*expansion(t). Normally one can overlook such details, but if you’re trying to model the universe, relativity must be included. Previously I could always claim I didn't understand relativity, but that excuse is worn pretty thin now, although you or Miles have always surprised me with things I hadn’t considered.

So the CPIM app already includes spin and a latitude function – great, it may go all the way. With all due respect, when I said you should use spin to tie all your formulas together, app aside, the physics comes first. If you’ve already built CPIM with these ideas in mind, not just a charge field but a relativistic charge field I’d say you’re doing a fine job.

Otherwise, as we're all aware, it's not quite done. It needs gravity - or this great new expansion alternative you're putting together.
.

No, I haven't shown anything we didn't already know, but I have used it in a more logical, consistent, and precise manner.

I don't know where that doubling every 19 minutes comes from, so I don't know if I can trust it. Doubling is also a relative term, so it doesn't really tell us anything about the actual radius. You also have to know what that 19 minutes applies to. You see, from a non-expanding perspective, both distance and time expand, since time is based on distance. If the meter expands, then so does the second. This keeps the ratio the same in spite of the expansion, from an expanding perspective. I am trying to find math that fills the gap between what we see from an expanding perspective and what really happens from a non-expanding perspective. I am not exactly in either camp, but somewhere between them. I need to step through it with great care to keep everything in its proper place.

Finding this change in radius will actually allow me to implement gravity at the same time. Since that change in radius is gravity. I just need to account for time discrepancies. I'm looking over Miles Third Wave papers for equations I can use and have found a few, but I'm still trying to figure out exactly how he calculated an initial radius for the proton. Miles states that you can't just use the equations of motions to find an older radius, or you can but you can only use it as a proportionality. I found another equation this morning, but haven't had any time to play with it.

I found the pin!

While the above analysis is still applicable, I have started from the wrong position. It is not volume that I should be analyzing, but surface area. My method is still the same, but we start from SA = 4Pi * r^2.

Radius	Area	A(r) / A(1)	A(1) / A(r)
1	12.5663706144	1	1
2	50.2654824574	4	0.25
3	113.0973355292	9	0.11111111
4	201.0619298297	16	0.0625
5	314.159265359	25	0.04
6	452.3893421169	36	0.0277777778
7	615.7521601036	49	0.0204081633
8	804.247719319	64	0.015625
9	1017.8760197631	81	0.012345679
10	1256.6370614359	100	0.01

Which gives us a 1/r^2 relationship.

Therefore, to find the charge at a given distance, we use: D(d) = C(1)/d^2

The relativistic version is: D(d) = C( R( -d/c ) )/d^2

Miles then went on to include gravity, which he said brings in another 1/r^2 relationship, so we end up with 1/r^4. However, I stand by my analysis and in the case of charge density, gravity must be included in the initial determination of charge density at the boundary of the emitter.

To be clear, charge density is a function of the volume of the emitter at the time of emission. It is the emission of a volume, over a surface. However, the drop-off of that emission is only dependent on surface area. We are taking the emission of 1 dt, and watching it as it moves out into space. We don't care about the space between that emission and its source, which using volume would include, so we use the surface area equation.

That makes perfect sense to me, Nevyn. The math even makes sense, which is a good thing since I'm not great with these kinds of maths and would have never seen these relationships the way you do.

I apologize to just be a sort of cheerleader here, but it's still interesting and I'm trying to follow along as best I can. Wish I could actually help on this one though.

.
That makes sense to me. You may have noticed I've been thinking of your finding strictly in terms of surface area. In my last post I interpreted your 'emission volume' as an expanding dt surface - "We also know, given an interval of time, a charged particles’ emissions will expand outward from the particle, as on an expanding spherical layer". The entire emission volume would involve all subsequent time differentials which we don't need.
.

Yeah, I was thinking the same way, only really seeing it as the top layer of the volume, but still didn't put it together that I should be using the surface area instead. Miles had to remind me as I looked over one of his papers. But my method is sound and it was only the initial equation that needed to be fixed, so the general outcome is the same.

It is good to know that you can understand what I have written. That I am making sense. So you are doing a bit more than just cheer-leading. I want to show how I find these things, and why the math is the way it is, so others can see what being mechanical means. So they can run with it themselves and maybe find things that everyone else has missed.

Let's have a look at the Radius function.

The radius function, R, must return the radius of a particle given a time differential, t, where t is in unit-time, for example, the number of seconds. When t=0, the current radius is returned. When t>0, a future radius is returned. When t<0, a past radius is returned.

We use the equation of motion s = (at^2)/2 to find the displacement of the radius given the time it occurs over, and the acceleration of the radius. We already know the time, d/c, but we need to know the value of gravity. I have found differing values for the gravity of the proton and need to decipher which one is applicable and why. For now, we will let it stand as the variable a.

Let:

r = current radius of emitter
a = gravity of emitter
t = amount of time the motion occurs over

Then:

If t < 0
R(t) = r - at^2 / 2
Else
R(t) = r + at^2 / 2

Unfortunately, passing in a negative time does not work as well in the math as I wanted it to. The time is squared which means the negative sign is lost so it needs to be extracted from the time or used in a different way to avoid this. I am going to redefine the R function so that it doesn't need to handle that part.

Let R be a function that returns the change in radius given an amount of time, t, where t>=0.

That leaves the subtraction from the current radius out of the R function and we can deal with the minus sign because we know that we are moving backwards in time in this equation.

So R becomes:

R(t) = (at^2)/2

Putting that into D gives us:

D(d) = C( r - R( d/c ) )/d^2
    = C( r - (a/2)(d/c)^2 )/d^2

Now we can see a bit more clearly why the relativistic equation reduces to the quantum version. I said earlier that as d becomes very small, the ratio of d:c approaches 0. In the above equation, that causes the change in radius to be so small that it can be thought of as just being the radius. i.e. r - (a/2)0^2 = r.

The values for r and a are treated as constants here, but they really represent the emitter. It might be a proton or it might be a star. For a given problem they may be constants but in others they will need to be specified. So I would rewrite the equation like this:

D( r, a, d ) = C( r - (a/2)(d/c)^2 )/d^2

to reflect that r, a, and d are all parameters. I'm not sure if that is how mathematicians specify such things but I know programmers will understand.

.

So I would rewrite the equation like this:

D( r, a, d ) = C( r - (a/2)(d/c)^2 )/d^2

to reflect that r, a, and d are all parameters. I'm not sure if that is how mathematicians specify such things but I know programmers will understand.

I’m sure mathematicians and programmers would agree, D( r, a, d ) appears radical. The charge density received from a charged particle depends on the particle’s radius, gravity and distance. Standard math doesn’t list all the parameters used on the right side of an identity equation as an index, or whatever that is, on the left. I would say a - the gravity of the emitter - is the only emitter “constant”. It’s difficult to tell the difference between distances and an acceleration without accompanying units - meters, seconds or sec^2.

After rereading a couple of Miles’ third wave and part of his long Mercury precession papers earlier today, I’d say you’re using the motion equation s = (at^2)/2, to find the displacement of the radius exactly as Miles has done.

Critically speaking, that’s all I’ve got.

You’re making charge field history. What next?  
.

Yeah, I thought it would be non-conformant, but I wanted to express that they may be variables in some circumstances while they may be constants in others. This is especially true when dealing with stars, planets and moons. Every entity will have its own radius and gravity value, where-as if we are looking at protons, then they all share the same values for those. But electrons and neutrons will be different, so it isn't just a micro vs macro type of thing. Even for our purposes in this app, we will need to handle different values once we bring electrons into the mix. We could probably use the same values for protons and neutrons though.

What's next?

Brain, in every episode of Pinkie and the Brain, wrote:The same thing we do every night, Pinkie, plan to take over the world!

Seriously though, I am working on the Charge Density function, C, to figure out if charge density can be calculated in the way that I want it to be. I want an expression that gives us the charge density, but only for a unit-area of the emitter, that can then be expressed on the receiver.

Question: What do you get if you take the volume of a sphere and divide it by the surface area of that sphere?

Conceptually, you should get the volume per unit-area.

A Dimensional Analysis tells you that the value is a meter (assuming you are using meters as your length units). It is 1 dimensional, not 3, so how does it represent a volume? Because it is a radius!

If you take the equation for the volume of a sphere (4/3 * PI * r^3) and divide it by the equation for the surface area of a sphere (4 * PI * r^2), you get r/3. Therefore, if my interpretation is correct, the volume per unit-area is equal to the volume of a sphere with a radius that is 1/3 of the original sphere's radius.

Does that sound reasonable?

Also, gravity. With the equation s = at^2/2, we can find the change in radius given an amount of time (which will be the time between frames but also include any time discrepancy as a result of distance separation) to find the amount of space that the other particles have taken up as a result of their expansion. We convert that into a vector that pulls our particle in that direction, by that amount. We do that for every other particle and sum them all together to get a resultant gravity vector. I'm not sure this is correct, since the other particles will expand regardless of what our current particle is doing. But in this math, 2 particles on either side of our particle will result in no motion. It doesn't feel quite right, but I can't see another way to do it, yet.

Brain, in every episode of Pinkie and the Brain, wrote:
The same thing we do every night, Pinkie, plan to take over the world!

Lol!!!

.
Pinky and the Brain are about to implement gravity.


Curious about the outcome? See: animaniacs pinky and the brain
https://gifer.com/en/oaf

////\\\\////\\\\////\\\\////\\\\////

I thought we were going to implement gravity by redrawing expanding particles. The screen dimensions would need to be recalculated along with the acceleration of the expanding particles.
.

.
Sorry Nevyn, I don't understand your resultant gravity vector idea. If particles are outside each other's charge range will gravity still be calculated? Real expanding particles seems easier.  

Concerning the reasonableness of the notion of a volume of a sphere divided by the sphere’s surface area. You’ve shown how they – the surface area and volume - are related. A “volume of particle emission” becomes an expanding spherical layer, a surface area with a differential time thickness dt. The further an object is, the smaller the amount of the expanding surface area the receiver will intercept. Sounds perfectly reasonable to me.  
.

.

Therefore, if my interpretation is correct, the volume per unit-area is equal to the volume of a sphere with a radius that is 1/3 of the original sphere's radius.

I don't see a problem. Check your thinking against this site.
Area and Volume of a Circle and Sphere Using Simple Geometry
http://physicsinsights.org/sphere-volume-1.html

(14) Volume(sphere) = (1/3)*r*A
where A now represents the surface area of the sphere. ...
(15)The Surface(sphere) = 4Pi*r^2

.

LongtimeAirman wrote:
I thought we were going to implement gravity by redrawing expanding particles. The screen dimensions would need to be recalculated along with the acceleration of the expanding particles.

No, we can't do that for at least 2 reasons. The first one mathematical and the second physical.

1) The numbers explode!

We are working within a certain precision which is set by the computer that the application is running on and the language used to implement it. In our case, we have 64bit floating point numbers in Javascript, but on a GPU, such as in a shader, we may only have 32bit floating point values. On a phone, we might only have 16bit numbers. No matter how large that is, it is still finite. We could be working with 1024bit numbers and it still would not be enough. If you just keep increasing the radii, then you will eventually, actually rather quickly, reach the upper limit of what your numbers can store.

There are ways around this limit. You can work with arbitrarily sized numbers that do not have an upper limit, except for the amount of memory in your system. However, they introduce a speed limit. The larger your numbers are, the slower they are to use in any calculation. Eventually, again rather quickly, the app grinds to a halt just trying to add 2 numbers together.

2) It doesn't represent the actual physics.

A 3D system is a Newtonian system, rather than a Relativistic one. The 3D engine will render all geometry as it is now, no matter how far it is from the camera. It does take distance into account to make things smaller the further they are from the camera, but it does not take the time discrepancy that that distance represents into account. We can make it do that, but only with considerable effort, and it is not as easy as it first looks.

You see, it isn't just the size that we see in the past, it is also the position (and velocity, spin, etc). When we look at the Sun from the Earth, we are seeing it at a size that it was 8 minutes ago, but we are also seeing it in the position that it was in 8 minutes ago. This is also a problem for charge calculations. My equation above takes care of the time discrepancy by using a smaller radius to calculate the initial emission, but it does not take the position difference into account. In its current state, it can't do that. In fact, it might not be feasible to do that because while that charge was travelling from the source to the receiver, the emitter could have had a collision and changed trajectory. We have no way of knowing that.

So we are left to find another way. It isn't going to be perfect, but we may be able to get pretty close and hopefully minimize the differences.

My idea is to treat everything as if it is always at the same size, but use adjusted values from all other particles that the current particle is interacting with. You always need a reference point, which is the current particle for us, so that you can determine how things look from that point. They may look completely different from a different point, but that is irrelevant to our current particle, for it is not over there, it is here.

LongtimeAirman wrote:Sorry Nevyn, I don't understand your resultant gravity vector idea. If particles are outside each other's charge range will gravity still be calculated? Real expanding particles seems easier.

I'm not sure about that. There is some distance where the change becomes so small as to be irrelevant. We can choose to find that distance and ignore everything outside of it just like we are with charge. Or we might just add it in anyway. It will probably be just as much computational effort to determine if it is too far away as it is to just calculate and add it in, which is not the case with charge as that is expensive to calculate.

LongtimeAirman wrote:Concerning the reasonableness of the notion of a volume of a sphere divided by the sphere’s surface area. You’ve shown how they – the surface area and volume - are related. A “volume of particle emission” becomes an expanding spherical layer, a surface area with a differential time thickness dt. The further an object is, the smaller the amount of the expanding surface area the receiver will intercept. Sounds perfectly reasonable to me.  

Not quite correct. Or it is in some ways, but maybe a bit misleading. The further an emitter is from the receiver, the larger the surface area is at the location of the receiver. That is, if we calculate a unit-area on the emitter at the time of emission, then that unit-area expands as that emission travels away from the emitter. That is what the outer 1/d^2 is doing in my equation. It is finding the amount of emission over the same unit-area on the receiver and the d^2 reduces the charge density to reflect the same unit-area at the receiver. The unit-area stays the same and we let the charge density change but we could just as easily find the new area that the emission covers at the receiver.

In fact, I think we should do that. We should let the emission travel out uninhibited until it reaches the receiver. We then calculate the size of the original unit-area at that distance. Then we divide that, let's call it the received-area, by the area that it interacts with on the receiver. This creates an equation that calculates the interaction of one area, on the emitter, and another area, on the receiver. Therefore, it can handle the difference in area that the receiver has with respect to the emitter. I might investigate that at some point. It may just lead to the same 1/d^2 relationship, but it is worth finding out.

LongtimeAirman wrote:I don't see a problem. Check your thinking against this site.
Area and Volume of a Circle and Sphere Using Simple Geometry
http://physicsinsights.org/sphere-volume-1.html

I knew the math was correct, not because I searched for it, but because I plugged some values into it and saw the relationship directly. What I am unsure of is my interpretation of it being the radius of a sphere to represent a volume. That site does not explicitly state it, but I was using the same concepts as they are (as in a pyramid-like shape from the surface to the center).

What I am trying to get at with that analysis, is that it is the whole volume that is emitting, not just the surface, even though it only emits at the surface. How can that be? Easy, because not all of that emission was created (for want of a better term) at the same time, but it is all emitted from the surface at the same time.

This is easier to see with stars and planets, than protons or small particles. I am actually wondering if there is a different equation for particles as compared to composite entities like stars. Anyway, with a star or planet, we have a body made up of smaller particles and it is each of those particles that is actually emitting. The sum of that emission becomes the emission of the body. However, the emission that came from the very center of that body is older than the emission that came from the surface particles. But age doesn't really matter. It is the sum of emission at the surface that we care about because that is the amount of emission that will travel away from the emitter and eventually collide with a receiver.

That gets us the total charge emission from the volume (with an assumption that the whole sphere is emitting, which we know is incorrect) at the surface. I then divided that by the surface area to get to a unit-volume or the amount of volume that is behind a unit-area. That should represent the amount of emission that is moving towards the receiver, with some margin of error. What we really should do, is determine the surface area of reception, translate that into an area of emission and use that to calculate the amount of emission. I may investigate that as well.

I had an idea a few months ago that might be able to help us here. In my posts above, I mentioned that there is a problem with reaching back into the past because you can only use the current data to do so. This ignores any interactions between the time of emission and reception that might have occurred to the emitter because there is no way to determine that. The best we could do is assume a reversal of the current velocity, spin, etc, which is not really good enough. It might work okay with stars and planets, but not at all with particles. Although, particles have an advantage in that they are so close to each other that we aren't looking very far into the past, but they also collide a lot more often and the results of those collisions are more drastic if compared to a planet.

The idea I had was to look at everything as an event. Each event has a time that it occurred, the position and orientation it was in, the resultant velocity and spin, etc. Essentially, it is the state of the entity at that event, or just after that event really. From there, we can determine its current position and orientation by using the time since that event and apply it to the velocity and spin. So we never change the position of an entity, for example, we just calculate its current one. Only a collision, which is the event, can cause those values to change.

Now, we can extend that a bit to keep a certain amount of history. We store the last 10 events, for example, so we can actually determine the complete story of that entity at least that far back into the past. We have a path, not just a line. Jared will be familiar with this because it is the basis of keyframes that he works with. However, he is using it to drive the complete animation, where-as I just want a window of it to represent the past.

.
You're covering new ground, I may not be the only one with a confusion or two. Must have pictures. Feel free to mark or make corrections or suggestions.



The emitter is on the left, and the receiver is on the right. You’ve recently developed a relativistic charge field, based on expansion theory, where charge emitted - C(), the particle radius - R() and the amount of charge received - D() allow us to model charged particles of almost any size, quantum or stellar.

Currently, the charge density received calculation is done at the receiver’s N/S,E/W,F/B points. I believe that this method doesn’t seem capable of differentiating between a relativistic case or not, so you are coming up with a better method.

I'm not sure I understand your r/3 spherical volume. I would say that the volume of the sphere that is the source for all emission felt by the receiver is the small conic section of the emitter, the base of the conic section is pointed toward the receiver. We can see the expansion of the surface area intercepted by the receiver. 
.

Nevyn wrote:Jared will be familiar with this because it is the basis of keyframes that he works with. However, he is using it to drive the complete animation, where-as I just want a window of it to represent the past.

Indeed, and ideally my simulations would (and will) borrow as much from yours as possible. I just don't know how to get it into Maya yet really! Obviously keyframes and editing are useful for a video-style presentation, but the simulation itself needs to be on or approach this level for me at some point. I'm following along pretty well, though you still work some serious magic to me. And really appreciate what you guys are doing here.

Sorry for the confusion, I'm just playing with ideas. Seeing what's possible. Some of those ideas are not for this app, but are in the same area. There isn't one magic equation for everything. There are little subtleties that can change the equations you want to use in a given problem or you might want a different kind of information so you go about it in a different way. I am not being clear about that at all. I'm just dumping my thoughts at this stage and seeing if they can stand up by themselves. Not very fair to anyone trying to understand me!

The use of charge points (N,S,E,W,F,B, for example) is still viable and the way I want to go. I'm quite proud of that little algorithm! It has no relation to being relativistic because the charge points are about applying the charge to the receiver, where-as being relativistic is about supplying charge by the emitter. It is the emission that happened in the past maybe because it is a long way away. The reception of that charge is a local event. It happens now, so no need for Relativity on that side of the interaction. If you want to know if something is, or needs to be, relativistic, just look for time discrepancies. They can be masked as distances.

Yes, it is the conic section that I was trying to get at. We want to know how much volume is in that section as that is the amount of charge that the receiver has to deal with. If we imagine that where that conic section touches the surface is a unit-area, then that whole conic section is a unit-volume. If my interpretation is correct, then that section has a volume that is equal to the volume of a sphere with 1/3rd of the radius of this sphere. So imagine that we take the sphere, create another sphere that has 1/3rd the radius, and then squash that smaller sphere into the shape of the conic section. It should match. That's all I'm trying to say about that. It seems logical to me, but am open to criticism as well.

Another way your picture works for me is that we can work backwards. We look at the emission radius at the receiver and project that back onto the emitter to find the actual area required by this interaction. This method does not work with my charge points because we are trying to find the charge density across the entire receiver, not at particular points on it. You could use that for a star pushing out on a planet when you just want the amount of repulsion and don't care about spins.

.
Maybe the charge point (N,S,E,W,F,B) method can be used for the relative case. You mentioned tracking state changes. Why not track the last 10 (or however many) state changes - and when they occurred - for each particle’s N,S,E,W,F,B cardinal locations. The past position of the emitter may then be compared to the present in order to arrive at a gravity component to the velocity or spin changes based on the change in charge received from that particle in the past.
.

That is actually a reason why we can't use that method. There are too many charge interactions so it would require too much history. At 60 frames per second we would have to record 60 state changes only to have 1s worth of history because charge interactions tend to happen over many frames.

Even if we could use it though, we wouldn't need to store history for each charge point since they are just used to find the resultant velocity and spin, which is what we would store. The charge points are just a way to break up the surface that is being bombarded with charge so that we can find small differences and apply them individually. They still collectively represent the surface of the receiver and they are always put back into a single vector for velocity and a single quaternion for spin.

Maybe we could tackle it slightly differently and still use the history. Instead of recording every collision, we just sample every entity at regularly intervals and record its state. The recorded state becomes the current state minus the previous state. This makes it easier to determine how much history you will store too. Because we set the time between samples, we know the sample rate. Multiply that by the number of samples and you have the time that those samples cover.

So if we sampled every second and kept 60 state changes, then we would have 1 minute of approximate history.

However, I don't think that is to be used in this app. We are dealing with protons not planets and stars, so we don't really have a history problem.

Okay, this is really fun and only slightly off-topic.

But if you load up the "Proton -> Stack 3" sim and stare at it for a bit, then look away somewhere else, your vision keep warping for a moment! Reality appears to ripple, the optics are fun. Just thought it was cool!

.
Good longitude to you.

Jarred, when I stare at things like that I see auras - of course I 'm sure that's due to strictly visual persistence. On the other hand I do like thinking of auras. At first I thought it was New Age nonsense. Now, I merely find it hard to believe anyone could actually perceive our real charge field auras.

Nevyn, I must ask, using your examples, I know how to set a particle's: type; position; velocity; and orientation. I believe the only thing missing - I've made several attempts - how should I set an initial spin?
.

Each Particle object has a spin property that is a Quaternion. So set it just like you do the orientation. The spin is to the orientation as the velocity is to the position.

Jared Magneson wrote:Okay, this is really fun and only slightly off-topic.

But if you load up the "Proton -> Stack 3" sim and stare at it for a bit, then look away somewhere else, your vision keep warping for a moment! Reality appears to ripple, the optics are fun. Just thought it was cool!

I used to get the same feeling when playing Guitar Hero. The motion of the game is down the screen, and your brain starts to take that as normal, so when you look away, everything moves.

.
Thanks Nevyn, I’m still trying to figure out your clue. By accident (serendipity?) I left w = zero and particleArray.items[i].spin.set(x,y,z,w) worked.

Spin bugs. I added four new initTwoBody scenario choices by including modest initial spins. Particle spins have the unfortunate side effect of making spin bugs stick out like sore thumbs. Here are three spin bugs you may have observed:
 
1. Rotating emission field. I’m sure we’ve all noticed the first spin bug in the initRandomBody scenarios. We know photon emissions must travel directly outward from protons. When Charged Particle Interaction Model (CPIM) protons spin, we see that all the emission particles making up the proton emission field are rotating outward along with the spinning protons. This rotating emission field bug has been unmentioned since fixing it would probably require giving every emission photon position and velocity. Can the particle rotate without rotating the charge effect? Sure, I suppose, for more program complexity. View initTwoBody02 versus initTwoBody02_s1 or _s2 from directly ‘above’ (+Y) in order to see the bug most clearly.

2. Spin reversals. We’ve mentioned spin reversals before, they haven’t gone anywhere. initTwoBody03_s1 usually starts with a quick two or three.

3. Spin shimmy and shakes. Higher speed spin reversals? initTwoBody04 starts with a few.
.

I think the w value should be 1, not 0.

1. Not going to fix that. Not feasible. It would require every charge photon to be an entity in the world, rather than just a cheap shader effect. Also, the charge does need to rotate with the particle because it represents the equatorial emission of that particle, so it must remain on the equator.

.
Well I thought that w should be a one. I don't know why, but that didn't work.

1. Sorry, I don't wish to argue, but I guess I didn’t properly describe the rotating emission bug. Its understood that the charge effect is a cheap shader effect, we certainly don't need to be making every photon its own entity. However, if the particle is spinning with, say, a horizontally oriented Y spin, the horizontally oriented charge effect will stay above the equator - we don't need to give the particle emission field a Y spin too. In order to stay above the particle's equator, the charge effect would only need to be rotated when the particle spin is not aligned with the particle's spin axis.
.

I get what you are saying, but I don't think it is worth the effort. I tried to implement independent charge in AV and it didn't work out. There are going to be limitations of the model like this and we just need to be aware of them. The interactions are not limited like that and they are what we care about because they drive the model. Users may get confused by it, and that is unfortunate, but we just need to make sure that we tell them about such limitations and hope they understand.

I might see a way around it one day, but that day is not today.

Sorry if my previous post seemed a bit short or sharp, I am just limited on time, not any problem with you or what you are showing.

Nevyn, what might it take to calculate such a thing, out of curiosity? Nvidia just dropped some crazy new hardware with the RTX 2000 series. Would a GPU 4x as powerful handle that number-crunching? 10x?

Is that a limitation of the code or of the hardware? I'm interested in your take because it's just about the same calculation overhead I'm running into in Nparticles as well. But they're CPU-dependent, not GPU, and I'm hoping there's a light at the end of the tunnel on these things somewhere.

If that is distracting or too off-topic, please ignore it.

Firstly you need to separate the charge from the particle. Every single charge photon now requires its own position and velocity, and that's only if you are rendering it as a point. Otherwise you will need orientation and spin as well. That's just memory, but it is the maintenance of it that is expensive.

On every frame, every particle has to 'create' new charge, so it needs to 'retire' old charge to make room for the new (it just uses the same objects in memory and re-purposes them). It needs to copy its current position into the new charge photons position and set its velocity (direction, basically). I would probably also store the current time as the birth-time of the photon. This would be used to determine suitability for retirement and also be used to apply the velocity to the position to render the point at the correct location over its lifetime.

The problem is that all of this creation code can not be performed in a shader. It must be on the CPU which is slow for such a sequential and repetitive task. You can render it through a shader, but you must set the position, velocity and birth time in the application code.

To give you an idea of how many charge photons you need, the current implementation in this app is using 1000 photons per particle. These are randomly distributed around the XZ plane and between +-30° along the Y axis (or something close) of that particle. The same shader in Atomic Viewer uses 5000 photons per proton, and that is only the equatorial emission of each proton, not the intake or through-charge shaders, and can be adjusted up to 10,000 with good performance on a decent GPU.

I think you would find that 1000 charge photons per particle is not enough if the charge is detached from the particle because you will see so much space around the particle. It will not look like a charge field, although this does depend on the speed of the charge where slower charge might work a bit better.

To render as a point, which means I could implement some of it in a shader, could be feasible. It is a lot more than my current charge shaders in terms of both memory and processing time, but maybe not unreasonable. Rendering as a sphere would be untenable. Every single charge photon is now a sphere, no shaders for efficiency. You do get to see all spin on the charge photons, which is worthwhile for some applications but you wouldn't have so many particles like we want here.

So more GPU power is not going to help, unfortunately. Well, it could if I was working in a language that gave me access to the GPU for computations, but browsers do not (even though there is a specification for it). I could do it in C/C++ or Java, for example, but not Javascript, although it isn't really a fault of the language, but rather the environment that it runs in (the browser).

There are other problems that arise from detaching the charge from the particle. The renderer can sometimes think that it doesn't need to render the charge because it is located off-screen, even though the charge in it may be on-screen. This is because 1 object represents all charge and that object is located at (0, 0, 0). You really have to keep calculating how large the bounds of that object is, which means calculating the current position of every charge photon in it and finding the maximum value in each dimension, which would have to be done on the CPU where it is slow (and in spite of the fact that the shader could do that easily, it just can't tell us the result).

I don't know what the RTX2000 offers, but a lot of the time it is specialised hardware to provide fast implementations of common tasks. For example, the Vega cards offered hardware occlusion (figuring out what geometry to render) which is far superior to doing it in the software. But that is useless for anything else. I can't use that to calculate charge emission or particle collisions.

What I can use is what they call Cuda Cores (NVidia) or Stream Processors (ATI). You can think of them like a core in your CPU. They can't do anywhere near as much as a CPU core, but there are so, so many of them (1000's) that you can do some things much faster because you can process it in parallel. Instead of iterating through an image one pixel at a time, you just work on every pixel at the same time. It can be difficult to wrap your head around parallelism and even more so trying to use it. Once you do though, these GPU's become so attractive. That's why I miss having them when I work in a browser.

Thank you for the detailed explanation of these limitations, Nevyn. I find myself excited that it made perfect sense. I was curious how much of this could be passed off to the GPU and still would love to delve further on that, though this might not be the space for that and that's fine by me. Maybe we should start a dedicated tech thread for that topic?

But just so you know, the new RTX 2000 cards
GeForce RTX 2080 Ti (FE) GeForce RTX 2080 (FE) GeForce RTX 2070 (FE)
Price $999 ($1,199) $699 ($799) $499 ($599)
Launch September 20th, 2018 September 20th, 2018 TBD
CUDA Cores 4352 2944 2304
Memory 11 GB GDDR6 8 GB GDDR6 8 GB GDDR6

That's the three new models, and yes they skipped from the 1080 to the 2080 in the nameology. But if you ever wanted more cores, now they're piling up nicely at least at the top end. The 1000 series (yesteryear's) are still beyond competent, and I'm only running a 750Ti myself on my best rig, at 640 CUDA cores. These things are probably 500% faster, if not 1000% due to architecture and memory upgrades.

(The "FE" in the nameology is "Founders Edition", or Nvidia's direct reference cards)

They look pretty good. I've recently put 2 RX580's into my system, but I don't run them together in SLI/Crossfire. I mainly use the 2nd card for computations. Each card has 2304 stream processors and 8Gb of mem, so plenty of room to have some fun, but the 2nd card has been a bit dormant lately. I should have a look over my OpenGL code from a while ago and see how it runs on the new cards.

Using the GPU can be a bit tricky. It can take a while before you see how to use it effectively on a given problem. It really is nothing like normal software development. Which is why I love it. If they would just give me access to the GPU from the browser, I could work some magic. It opens up a whole new world of possibilities and I feel very restricted without it. It's quite frustrating when you can see the solution in your mind, but you can't implement it in the given environment. You have to work with what you have, though, and we're making some good progress in spite of the limitations.

I hear you there. I was looking for a GPU-accelerated successor to Maya's Nucleus particle system, which is calced on the CPU and rendered on the GPU, but I found nothing. Not one solution offered, though there were a few white papers on the topic.

Makes me wish I could somehow implement your code entirely in Python or something, and start from scratch! But with more control, obviously.

This is good stuff regardless, so I hope you two keep pushing on this setup! Promising stuff.

.
Slow progress, learning how to play with the program.

Studying spin behavior. I’m nowhere near understanding where it uses quaternions. That and the spin bugs drove me to review the math again, including NJ Wildberger’s rational geometry form http://milesmathis.the-talk.net/t42-quaternions#349. For example, a quaternion form is given by (a, bi, cj, dk), where a, b, c, and d are rational, and the i, j and k indicate complex components for which: i^2=j^2=k^2=ijk=-1.
In CPIM, I’m initiating spin velocities with x, y, z and 0 values, (x, y, z, 0), that doesn’t agree with the (a, bi, cj, dk) form. I’ll keep looking.

Good news item. I saw NO spin bugs when all particles present were neutrons. It appears spin reversals and the shimmy and shake spin glitches have to do with charge interactions with protons.



Here we see an image of a 4x3x4 particle lattice which displays a wide range of x, y and z spin velocities. Neutron radii = 1, and the closest distance between particle centers is 5. The camera position is z=16 from the lattice center. All particles are spinning at incrementally increasing x, y and z spin velocities. Making it easy to see how simultaneous x, y, and z spin velocities add. The single particle without spin is at the back, left, and bottom. The browser is operating at the desired 60 frames per second.



Here we see a larger, 10x10x10 neutron lattice with various spins. The camera position is z=30 from the lattice center. The fps is 9, way overloaded, good for just a nice image.
.

Glad your still working your way through it. I'm in a bit of a pickle at the moment. I have made so many changes to the code that I can't get your updates without losing it all or trying to weave them back together. My changes didn't help anyway, so I am tempted to just discard them.

My guess for the spin reversal is that the axis direction is being changed. If you have a rotation of 90° about the Y axis, it will rotate a certain way. If you want to rotate the other way, you can make the angle negative, or you can make the axis negative. I think the charge interactions are happening on one axis and then changing to the opposite axis, so the direction of rotation changes with it. This may indicate that the code is not applying rotation direction correctly. That is, it should be setting the angle as positive or negative based on something (not sure what at the moment, probably the angle of incidence).

.
Oops, I Pushed a grid addition to a collision lattice before reading about your pickle. I suppose Committing often is better than saving up and forgetting changes. I hate to think you’d just discard changes. Wasting your time or trying your patience would be awful. I'm striving for success as well as your approval and cooperation.
 
I added many additional lines to initTwoBody02_s2 (a change I haven’t Pushed) in order to study the spin glitches. Your spin reversal thoughts look and sound about right.
.

Nah, don't worry about conflicts with my changes. I was debating with myself whether I wanted to keep them or not (it was an attempt to look for collisions before they happen, rather than after). It didn't work, so nothing lost except my time and sanity, but there wasn't much of that to lose anyway.

.
Studying spins and playing with configurations. Here are all the spin bugs in one 4x2x3 group, initLatticeBody04. The site is converting my 1.5Mbyte gif into a jpg of the final frame after 10 seconds. (I turned down the proton emissions to try to reduce gif size). Only the back left two neutrons went down and came back up, in their 'correct' locations, still on their vertical grid lines. I may change this configuration a bit and Push it tomorrow.



Initially - not shown - we would see twelve different vertical pairs (neutrons above and protons below) where:
Bottom plane, left edge, x = 0, protons are oriented N/S but they have no spin.
Bottom plane, x=1, N/S oriented protons are given y-spin.
Bottom plane, x=2, N/S oriented protons are given x-spin.
Bottom plane, right edge, x=3, N/S oriented protons are given Z-spin.
Top plane, back edge, z = 0, N/S oriented neutrons are given y-spin.
Top plane, z=1, N/S oriented neutrons are given z-spin.
Top plane, front edge z=2, N/S oriented protons are given x-spin.

The two back left neutron/proton pairs usually last the longest before finally - just a few minutes - only the next to the back left, the x=1 pair remains.

The two front left neutrons show a large number of spin reversals. They don't quite fit your description Nevyn, I'm hoping this configuration may provide additional insight.
.

.
I can't keep avoiding it, gravity needs to be included. Here are my initial thoughts:

cdm.js line 477 // determine type of interaction: collision, charge or none.
Recommend changing line 477 to: cdm.js line 477 // determine type of interaction: collision, gravity and, charge or no charge.

cdm.js line 378. (function() // calculate linear and spin velocities
Recommend changing line 378 to: (function() // calculate linear and spin velocity changes due to charge and gravity.

cdm.js line 480 – 495 follow.

Code:


if( len < DIAMETER )
{
// collision
 this.calculateCollision( i, pos, orient, j, p1, q1, vel, spin );
}
else
{
     this.calculateGravity( i, j, p1, vel);
     if( t1 !== module.NEUTRON )
     {
           if( len < INTERACTION_RADIUS )
           {
                  this.calculateChargeInteraction( i, pos, orient, j, p1, q1 );
            }
      }
}


We should avoid a gravity calculation only when the particles are colliding; therefore, I would like to introduce the velocity due to gravity after the - else {, and before the - if( t1, neutron check, cdm.js line 488 as shown above.

The velocity change due to gravity can be found from, F=ma= G* m1*m2/d^2 = G * MASS * MASS / len^2. G, the gravitational constant, needs to be defined as as a function of the emission particle's density or radius.  

I don’t believe I can simply create a new function to calculate the velocity due to gravity between the source and the emitter without screwing up the variables for cdm.js line 492 calculateChargeInteraction function.

Does that sound about right to you?
.

I don't want to introduce another force when we still have problems with the ones we have. It will just make it even harder to see what is happening. If you want to play with it, then create a Branch and work in that. You will see that I have created a new Branch for my pre-calculation refactor. Notice that it has a folder called 'feature'. Do the same. Call the Branch 'feature/gravity'. This keeps various Branches separate from each other but still grouped. We could have some in the future like 'bugfix/collisions'.

I don't see why a collision would stop gravity. We shouldn't even stop it from calculating the charge interactions. All of these things are independent of each other, so they all should happen regardless of what the others are doing.

I had a look at your new test case, but I haven't looked through the code to figure it out. I wan't too concerned with the neutrons spinning back and forth. That is just caused by the charge points on each side moving towards and away from the source of emission, so they push and pull against each other and the neutron rocks back and forth.

I could see how you adjusted the initial spin from left to right: none, Y spin, X spin, Z spin, but I haven't figured out what you are trying to do from front to back. I thought the front row worked within the limitations of the algorithms.

There should be no difference between no spin and a Y spin when the neutron is directly above the proton. Both operated similarly.

There is a slight difference between an X spin and a Z spin, but not much, only the dimensions that motion will occur in. Both operated similarly.

.
Thanks for the guidance Nevyn, I do appreciate it.

initLatticeBody04 – back to front – top row - is just varying neutron spins. This configuration is a collection of all the neutron/proton pair configurations in one place. Sorry, I didn’t mean to imply that every neutron/proton pair shown has a problem, they don’t. For example, it’s interesting to see a z-spinning neutron above a z spinning proton is fairly stable for a while. The overall configuration started as a 4x2x4, where the z=0 row was neutrons without spins, but I noticed that N/S oriented neutrons with no spins acted the same as a N/S oriented neutron with y-spins, so I dropped the case of non spinning neutrons above protons with x or z-spins. I still don't see how the two pair at the back left keep cycling; I know you mentioned why - vertically oriented ambient charge I believe, but I haven't seen it in the code yet. I should mention I think the spin bugs on the front left are especially visible.

Ok, while I may start a ‘feature/gravity’ branch, we should correct the spin bug /charge interaction errors first. I was tempted to leave that particular problem to you, but now I’ll put effort into it.

P.S. initLatticeBody04. I think it's notable to mention that the x=0, z=1 position neutron/proton pair with an z-spin neutron above a N/S oriented, no-spin proton shows NO spin bugs. The spin bugs ARE present in the x-spin neutron above a no-spin proton. That seems like a big clue.
.

No reason we can't both look at any problems. And your examples have been great to show them. I sometimes work through things in my head and miss the little details or excuse them away before a thorough examination. Experience can work against you.

I'm not convinced on these spin issues though. The 2 neutrons on the front-left seem OK to me, but it needs study.

It might be a good idea to show the charge points on the particles. Maybe add in 3 lines, along the X, Y and Z dimensions, that stick out the sides of the particle a little bit. This will help to see how far they are from the emitter and how they relate to the other charge points.

.

"Spinning" Neutrons above Non-spinning Protons. This gif shows a close up of two, N/S oriented, neutron/proton pairs; the proton closest to the viewer is below the image's bottom edge. All 4 radii = 1. All particles are given NSEWFB lines for reference. The two initial vertical neutron (center) to proton (center ) separations = 10.5. The horizontal distance between the centers of the side-by-side pairs is 12. The observation position is (-13, 3, 2). Neither N/S oriented proton has been given any spin. The neutron closest to the viewer has been given an x-spin, but rather than spinning, that neutron is displaying many spin reversals. The N/S oriented neutron in the back has been given an z-spin, it does not display any spin reversals.

Given my poor - 50/50 - record for posting gifs here I'm especially grateful this one (472KB) was allowed.  

Nevyn, does this convince you that the spin reversals are a legitimate bug issue? I'm convinced, but apparently I'm easy. Or would you like to see any additional changes?
.

You will see that I have created a new Branch for my pre-calculation refactor.

Maybe I should have asked first, I went and merged with your remote-tracking branch 'origin/feature/precalculate'. I‘ve since checked a few configurations and found that collisions and spins are behaving badly. For example, collisiontest01 and 02 have way more energy than ever, and the first collision in collisiontest03 freezes the action - fps drops to one. Random occasionally freezes, I suppose due to collisions. Spins I've set in initLatticeBody03 no longer work. I feel like I've made a terrible mistake.

Any suggestions?
.

I need to know what you mean by 'merge', as that has a definite meaning in GIT. If you just mean that you committed your code changes to that branch, then you didn't merge them. Merging would be taking the branch and adding all of those changes (commits) to the master branch, then you say 'this branch has been merged with master', because they become one branch (master is a branch too). I hope you didn't actually merge as that could be really difficult to deal with.

If you just committed your changes to that branch, then we can possibly handle it. The quickest and easiest way is to just revert those commits, but then you lose those changes. If you know what your changes are (selecting the relevant commits will show you) then copy those out somewhere, revert the commits, move to the right branch, and then copy them back in and commit to that branch.

That pre-calculate branch is not meant for development. I created that so that I didn't lose all of those changes just in case I wanted to try that again. I'm not sure if it was working code or not. I didn't see any differences (visually) when using that code, so I abandoned it to see your recent commits.

The reason that your spins don't work is that it adds another level of velocity and spin (called deltaVelocity and deltaSpin). It is these new versions that get calculated into, but not applied until the next frame. That is the pre-calculation part. This allows it to use those up-coming velocities to determine where the particles are going to be and if they are going to collide and deal with it before hand.

.


I tried to discard my last commit but it failed. It looks like it's waiting for me to make two pushes. All my changes involved the init configurations. They are all in a separate non-Git working file so I can easily recreate them.  
.

DO NOT PUSH!

I'm not sure which way we need to solve this. There are 2 possibilities: be on master and revert to the commit with the tag origin/master; or be on the feature/precalculate branch and revert to the commit with the tag origin/feature/precalculate.

Try the first one on master. The merge occurs onto master, so I think that is the way to go. It should revert both branches to their previous state.

Alternatively, you can definitively fix it by deleting your source tree and pulling it from GIT again.