Possible Charged Particle Field

.
Polar aligned particles cycling their separation distance due to gravitational attraction and charge repulsion – of course! What a wonderful unexpected surprise. I shouted when the odd proton in particleArray = initThreeBody05() caused all three particles to tumble apart. Unless I’m mistaken, I don’t believe these particles are spinning yet. Dang Nevyn, your smile muscles must be hurting. Don’t worry about great charged particle discoveries like bouncing balls, I still love my marbles.





These two diagrams are better. I hope you approve, I need to get with the program.
.

They are spinning, but most of those configurations don't show it because they are aligned too well for direct collisions or have even force on both sides that cancel out. Have a look at initThreeBody05, and compare it to initThreeBody04 which is the same configuration but 04 has a Neutron in the middle and 05 has a Proton. You will see that the Neutron does not receive any spin, it just shoots off to the side (because it is offset on that side from the vertical alignment of the 2 Protons above and below). However, when there is a Proton in the middle (and offset), the charge fields interact and cause spin.

There is no gravity in this model either. The attraction I added was to represent the external ambient field pushing in from the outside, but not between the particles. This may not be needed once we implement gravity but I am also trying to represent the hole through the center of the Proton that will not resist any charge entering that area. This will need to be formalized into code too at some point.

Those images look better. I believe the charge vectors are pointing the right way. I'll give them a better look a bit later on.

That last image is showing what I want, but not really in the right way to be the most expressive. It is correct, but I think a change in the direction of the force will help to contrast the charge vectors with the cardinal point axes.

You have the receiver on the left and the emitter on the right and it will work better swapped around. Basically, I want the emitter to be negative, in all 3 dimensions, relative to the receiver. It will also help to make each dimension the same, so if the X axis has a difference of 5, then so should the Y and Z. This will cause the charge vectors to be around a 45° angle at each cardinal point, which helps to show how to break them up into linear and tangential components.

If the receiver is at (0, 0, 0), then put the emitter at (-5, -5, -5) and see how it looks. What I'm looking for is the charge vectors to be in the positive dimensions, as that is where the axis markers are pointing. Therefore, it is easier to see how those two things relate to each other.

.
Sure Nevyn, I'll be happy to redo the drawings as you've requested. If you'd like, please provide a desired set of charge density magnitudes/directions or I'll just make them up again.

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

Reviewing cdm-notes.txt. I wasn't able to give a proper review of the Charge Density Model last month. Now that I’ve given the subject some thought, in our discussion and the images I’ve made, here's my review.

During the charge density received calculation, the center of the receiving particle is the center of the world coordinate system - (0, 0, 0). The x, y, and z components - the linear and spin components of the charge density vector - at each cardinal position are required. All accelerations are received from some point in space, from that direction and at some magnitude. Although I may be mistaken, my thinking matches my images.

QUOTE
      Calculate sum of charge densities from other particles at the cardinal positions on this particle (N,S,E,W,F,B).
      For each position:
           Split charge vector into 3 components:
           A linear velocity component that points to the center of the particle; //points to the center of the - emitting? - particle.
UNQUOTE
Recommend changing the last sentence to –
         “A linear velocity component that may point either toward or away from the receiver center. //originating from the center of the emitter, the charge density vector may thought of as entering the cp’s on one side of the receiver and then exiting the receiver at the opposite cp".
 
Comment. Recently you’ve mentioned the idea of allowing through charge. When, say, the north or south charge density vector is well aligned with both the N/S axis direction and location, we might expect the N/S linear charge acceleration to be greatly reduced, but in those cases I would also expect some sort of trade off – like increased pair stability. It’s on the to-do list, too early for now.

Each orthogonal projection (3 at each cp) involves sines and cosines and a distance or two. How much charge received would we expect to actually penetrate to the relative opposite side of the receive particle? None really, but the cp idea is a great simplification for charge field approximations. I suppose there may be a way to simplify the charge density calculation down to just the three charge density vectors entering the receiver.

QUOTE
 “Two spin components that point in the other 2 dimensions. //point in the other 2 –orthogonal? – dimensions”.
UNQUOTE
Recommend changing that sentence to -
“Two components, both orthogonal to the linear velocity and tangential to the cardinal position. These two component directions cause particle spin".
 
QUOTE
     The actual dimensions used are different for each position:
       North: V=-Y, S=X,Z
       South: V=+Y, S=X,Z
       East:  V=-X, S=Y,Z
       West:  V=+X, S=Y,Z
       Front: V=+Z, S=X,Y
       Back:  V=-Z, S=X,Y
UNQUOTE
Comment. The table is incomplete. We know the north cp is located at (0,1,0). The charge density vector intercepting the north cp may come from any direction, with linear component not limited to -Y as you’ve indicated. Recommend changing table to.
       North: V=+/-Y, S=+/-X, +/-Z
       South: V=+/-Y, S=+/-X, +/-Z
       East:  V=+/-X, S=+/-Y, +/-Z
       West:  V=+/-X, S=+/-Y, +/-Z
       Front: V=+/-Z, S=+/-X, +/-Y
       Back:  V=+/-Z, S=+/-X, +/-Y

QUOTE
      “Where a vector with the same sign as the linear velocity dimension means a repulsion and the opposite means attraction (or do we ignore attraction and just let the other side apply repulsion?)”.
UNQUOTE
Comment. I would remove or change the sentence. As above, we will see the linear velocity components pointing both in and out of the receiver particle. I don’t believe the linear components of the charge density vector will ever indicate any attractions – only repulsions. The repulsion is felt in the directions of the linear components - in the same general direction as the six individual charge density vectors.

QUOTE
For linear velocity:

Code:

   We now have 6 vectors positioned at 6 positions.
   We reduce that to 1 vector by summing them all to find the resultant velocity.
   May need to ignore vectors that point away from the center of the particle (attraction).
   Add to the particles current velocity.
UNQUOTE
Comment. Strike out May need to ignore vectors that point away from the center of the particle (attraction). I don’t know how the algorithm is actually being performed. At present, half the linear components will point into the receiver and the other half will point out.

The spin stuff looks ok to me.

Let me know if you disagree with the above, or I'll proceed to clean it up a bit more, then change, commit and push those changes to you.
.

Nah, don't touch those notes. They were only meant to be a rough guide to remind myself of various thoughts. I will flesh them out a bit more to reflect the implementation and some realisations I have had since doing so.

Airman wrote:A linear velocity component that points to the center of the particle; //points to the center of the - emitting? - particle.

No, to the center of the receiver which is the owner of the charge (cardinal) point. You start at the charge point and look towards the center of the particle and that is the linear velocity direction for that charge point. The plane orthogonal to that direction is the spin.

Airman wrote:Each orthogonal projection (3 at each cp) involves sines and cosines and a distance or two. How much charge received would we expect to actually penetrate to the relative opposite side of the receive particle? None really, but the cp idea is a great simplification for charge field approximations. I suppose there may be a way to simplify the charge density calculation down to just the three charge density vectors entering the receiver.

Yes, I have been thinking about that. I haven't found a nice way to determine which charge points should be measured for a given emitter. It is not limited to 3 at a time though. There could be up to 5 for an emitter lined up with one of the cardinal points.

Airman wrote:The table is incomplete. We know the north cp is located at (0,1,0). The charge density vector intercepting the north cp may come from any direction, with linear component not limited to -Y as you’ve indicated

You are misunderstanding what the negative sign means. It does not mean that we ignore negative velocities. It just means that a velocity that matches the sign is considered a positive velocity. i.e. a repulsion. If the velocity (or the component of the velocity that we are interested in) is the opposite sign, then it is an attraction. It is really representing a transformation into the charge points local coordinate system.

.
We're talking a bit past one another, for example, the first quote you attribute to me in your preceding post is actually yours. I don't see a problem, we both understand the charge density vector and its cardinal position components better than your original notes. As per your instructions, I'll leave them alone, you'll clean them up at your leisure.

The following two drawings are as requested, with receiver at (0, 0, 0) and emitter at (-5, -5, -5).




.

It was really your comment after the statement that I was addressing.

The images now put the charge vectors in the right octet, but they are covering the axis markers. Maybe take away those added border lines on them. Can you make the axis markers longer, without making them thicker? About half the length of those charge vectors would be good. We need to be able to see the angles between the charge vector and axis marker.

Have you had a look over the algorithm in cdm.js? I know the code will be a bit confusing because I am using some things that aren't normally required, but if you find the 2 main functions then you can just focus on them as they provide the algorithm. The rest is just transferring data around.

.
I've looked at everything in the GIT folder at least once, of course I'm far from understanding any of it. I can't make any additions or changes till I do. I may as well concentrate on cdm.js next.


.

I have an idea about how to determine if a charge point should be measured or not. The premise is that a charge point on the far side of a receiver, from the emitter, should not receive any charge. To determine this, we look at each opposite charge point pair (the ones that are the same color in the images above).

Find the lines from each charge point to the center of the emitter.
Create a triangle by adding a third line between the 2 charge points (length will be 2 * radius).
Calculate the angle created at each charge point.
If angles are equal, then use both charge points, otherwise, use charge point with the larger angle.

The angles are calculated using the Law of Cosines which allows us to determine the angles when we only have the length of each side. If the charge points are labelled CP1 and CP2, and the center of the emitter is labelled E, the line from CP1 to E is labelled L1, from CP2 to E is L2 and from CP1 to CP2 is D (for diameter), then the angles at each charge point are given by:

cos(CP1 angle) = (L1.length * L1.length + D.length * D.length - L2.length * L2.length) / (2 * L1.length * D.length)
cos(CP2 angle) = (L2.length * L2.length + D.length * D.length - L1.length * L1.length) / (2 * L2.length * D.length)

That is an expensive operation but it is required. I can make it a little bit better by calculating both angles at the same time, and therefore saving some multiplications since we use the square of the lengths in each calculation. I can also avoid the arccos function (the cos moves to the other side of the equation and becomes an arccos), which is rudely expensive, because I don't care about the actual values, just that one angle is larger than the other. Therefore, if the right side of those equations are compared to each other, then the smaller value equates to the larger angle (arccos will invert that relationship).

I also tried to combine them into one equation by putting them into a ratio (dividing one by the other) and if the answer to that is above or below one, then we know the relationship between angles. But the resulting equation seemed to be even more complicated and expensive.

I'll give this a try tonight and see how it goes.

.
Good stuff Nevyn. I’m agog, almost overwhelmed by this wonderful learning opportunity. Thanks.

Sounds like you want diagrams with the opposite cardinal positions joined together. Will do.
 
I made a few additions to the particleArray list you provided, but I haven’t committed or pushed any of them yet. The most interesting result I found was when I started with particleArray = initThreeBody05(), then changed the top and bottom protons to neutrons.

Code:

function initThreeBody06()
 {
 var particleArray = new ChargeInteractionModel.ParticleArray( 3 );
 particleArray.items[0].object3D.position.set( 0, 5, 0 );
 particleArray.items[0].type = ChargeInteractionModel.NEUTRON;
 particleArray.items[0].recreateNode();
 particleArray.items[1].object3D.position.set( 1, 0, 0 );
 particleArray.items[2].object3D.position.set( 0, -5, 0 );
 particleArray.items[2].type = ChargeInteractionModel.NEUTRON;
 particleArray.items[2].recreateNode();
 return particleArray;
 }

From the browser, it’s plain to see the neutrons - initially stationary - begin to spin and bob. An odd spin reversal occurs at about 20sec in. Here’s a small gif - looking up at the neutron, proton and neutron, rotated to a smaller aspect, showing the apparent anomaly.

The site wont let me post the 1 Meg gif, turned it into a poor jpg image. Here's a slightly better image.


Turns out, I like Quaternions. I accept the fact that the protons are spinning. I had gotten the impression from the fact that I never saw the proton wireframes rotate.

Might there be an easy way to slow down action?
.

That is a nice little test to perform. I didn't think about that one. I was mostly focused on Protons rather than the Neutrons. I will check it out tonight.

I have noticed some strange spins that seem to suddenly kick it the opposite way. I assumed it was complex charge interactions going on because I had Protons in there. Neutrons remove that possibility, so you may have found evidence of a bug or it may be perfectly explainable. Of course, once I make the changes mentioned in my last post, things will act differently. Hopefully, it will fix it at the same time and save me the effort of tracking it down. Of course, tracking down bugs like that is how you truly understand an algorithm. You have to get right inside of it and make sure that every step is doing what you want it to do. I often find new ways to do things as I look at it closely like that.


There are a few ways to slow it down.

1. You can reduce the force applied from the charge field. This can be found in cdm.js file, find the calculateChargeDensity function and above that you will see a constant called something like MAX_CHARGE_STRENGTH = 0.2;, you can change that to a smaller value to reduce the force.

2. You can introduce a frame count in between calculations. That is, you can tell it to not calculate on every frame, which it is doing now, and it will ignore N frames before calculating again. This will need to wrap both the calculations and the updating of particles (which applies the calculated velocity and spin), otherwise it will just use the previously calculated velocity and spin during those ignored frames.

To do this you need to find the render function in test.html (near the bottom of the file) and do a little magic do stop it calculating when you don't want it to. It is a little more difficult to do than option 1, and even harder to explain. I will add that in so it will be easy to change the number of frames to ignore just by changing a single variable.

3. Run it on an old computer! OK, that is not as feasible as the other 2, but it would work.


I have created a new test function that creates a random number of particles, giving them a random position, orientation, velocity and spin, with a 25% chance of being a Neutron. You can easily change the max number of particles, the max bounds to be positioned and the chance of being a Neutron. This allows you to just refresh the page and get a new scenario. Not so good for testing the algorithm, but good for seeing how it handles lots of different interactions.

Actually, it's just cool to watch!

I have found that I can get about 200 - 300 particles and still reach 60 frames per second running on an RX580 graphics card and Intel i5 processor at around 3.5GHz (I think). The card doesn't really have much to do with it, since a pure JS implementation is doing it all in the CPU, not the GPU. Still, I am pretty happy with the performance so far. A shader implementation should be able to handle 1000 particles easily on a decent graphics card.

I haven't committed that yet, but I will tonight.

.

I have an idea about how to determine if a charge point should be measured or not. The premise is that a charge point on the far side of a receiver, from the emitter, should not receive any charge. To determine this, we look at each opposite charge point pair (the ones that are the same color in the images above).
…
I'll give this a try tonight and see how it goes.

Good luck, I guess.

I think your idea of sampling the charge received at each cardinal point is perfectly valid. Without such a simplification computations may become untenable. Sorry I made mention of charge entering or exiting, into or out of the receiver, can we make due with just three cardinal points? I didn’t intend those comments to detract from your cardinal points idea.

All the necessary computations to determine whether the receiver’s cardinal point is on the front or back side the receiver sound like a huge load. We know that the distance to the center of the receiver is the halfway point. All these lengths, any chance we can convert distances into distances^2?

I haven’t figured out how you’ve done it yet, but given the discussion, I can't wait. With respect to a possible reduced set of cardinal points, i.e. 2 equatorial cp’s and a N or S pole. Have you considered that direct charge density received at a pole will result in a gyroscopic spin axis precession?
.

You didn't detract from the idea of charge points, only showed that it is currently receiving forces that it should not. You are perfectly correct and I was already aware of it, but hadn't mentioned it. It's great that you saw it. Shows that you are understanding the algorithm.

Yes, determining which charge points to measure can get expensive. Initially, I was looking for a cheap way to do it with the most obvious being (which I mentioned in my notes) to ignore any force that has a linear velocity component (with respect to that charge point) that has a sign opposite to that charge points linear velocity component (the +'s and -'s in my table of cardinal points). I actually did implement that the other day, but I quickly realised that it would remove the attractions that I had put into the charge vectors.

In the end, we may not need those attractions, but I have a little feeling that they might still be needed. Maybe reduced from what they are now (which is equal and opposite to the equatorial charge strength at every angle from equator to pole, that is, 10° from the equator is the same, but opposite value, as 10° from the pole).

However, I am not performing this math for performance reasons. I am doing it for physical reasons, and that means that it is not negotiable. The functionality is required, but we may be able to find a cheaper way to determine the same thing. If we can remove those attractions, then I can do it very cheaply (basically just a less than or greater than comparison).

In the end, no matter how slow it is, you have to make sure that the code matches the expected outcomes. There is no point having lightning fast code if it doesn't give you the correct answer.

While nearly all scenarios will only involve 3 charge points, there is still the possibility of 5 being used at once. Put the receiver at (0, 0, 0) and the emitter at (5, 0, 0) and the receiver will get a direct hit on the East charge point. The West should not receive any charge. However, all of the others are in the same, relative, position as each other, so either they all receive charge or none of them do. This is a tricky scenario because all charge points, except E and W, are receiving charge that points away from the receiver, but still hits at a tangent. Currently, each of those points (N, S, F, B) will receive an attraction along the line from the charge point to the center of the receiver, which is just plain wrong. Maybe in this case, they should only use the East charge point. If I went with the idea of not accepting charge vectors that point away from the receiver, as these would, then it would mean that only the East point is used in this scenario. You may be right. I'll have a play with it tonight.

We need to implement gravity too. I went looking through Miles' papers the other day to find whatever I could on the strength of gravity at this level, but didn't find what I was looking for.

I also want to implement the effect that the receiver has on the charge that it receives. Is the charge reduced because it had to pass through the receivers emission? Is it ignored because it goes through the poles and straight through the central hole in the receiver?

I just had a new idea that could replace all of this! We can forget about charge points if we look at where the actual BPhoton of the receiver is in its spin cycle. This becomes the one and only charge point and we take the line back to the center of the receiver to determine which are the linear and spin components. This would involve using sines and cosines to figure out those components, but since we are only looking at a single charge point, it becomes feasible to do it that way. Of course, I would need to perform the math to determine where that BPhoton is, which is quite complicated.

That idea needs a lot of fleshing out, but is probably more accurate in the long run. Probably more complicated too. Calculating where the BPhoton is is not too bad since I already have that code in one form or another. The charge calculations might be better or they might be worse, I'm not sure at this stage.

Do you see how one thing leads to another? If I hadn't gone through this algorithm using various charge points, I might not have seen how to use it for the real BPhoton.

I have implemented the above algorithm to exclude charge points based on the angle between them and the emitter. I think it works better now. More smooth. Most configurations remain the same, but some have changed. I was shocked to see that initThreeBody04 stopped pushing the Neutron but figured out why and created a new version of that configuration called initThreeBody04_02. See if you can figure out why they behave the way they do. Very interesting configuration, the second version shows acceleration of the Neutron quite nicely.

Then I ran your configuration and my jaw hit the ground! The Neutrons were being corralled into the poles of the Proton between them. They moved about, but remained within the pole area. They gained all sorts of spins too. Amazing to watch. Loved it!

These changes have been pushed to GIT. Have a look, especially at initThreeBody04 and 04_02 but also your own configuration. Let me know if it is acting differently to how it did before these changes.

I think I just figured out what that sudden spin reversal is. It occurs when the particle is moving from within the equatorial charge zone of an emitter and into the polar charge zone or back the other way. It is the attraction I added that is causing it. The attraction should only operate on the linear velocity component and not the spin, but it is applied to both. I'm not sure how to fix it yet, either.

I fixed that, but it wasn't the problem. It was a problem, though, so it is fixed now.

I then thought that it was the quaternions overloading. When a binary number gets too large, it suddenly goes negative. If you keep adding 1 to an integer, you will eventually get back to the value that you started with. So I normalized the spin quaternions, since a quaternion can store a rotation of 370° just as well as 10°, but visually, they are the same thing. But that wasn't the problem either.

I really don't know what it is now.

I have put up a version on my website. It uses Airmans configuration with 2 Neutrons, positioned above and below a Proton. Just watch them dance around. It is quite mesmerizing.

https://www.nevyns-lab.com/mathis/app/cpim/test.html

.

Have a look, especially at initThreeBody04 and 04_02 but also your own configuration. Let me know if it is acting differently to how it did before these changes.

Gosh Nevyn, it's good to see you rolling.

Great, a pop quiz. I’m afraid I knew the answer before I read your question. I’d already reviewed your GIT changes in Sourcetree.

The main change appears to be the 3X reduction in the proton emission field density, from 3000 to 1000.

Code:

//effect.maxParticles = 3000;
effect.emissionRate = 1000;

That slowed emission reactions down 3X, which means I won't have to move back to my old computer in the spare bedroom in order to slow things down further. In “my NPN” configuration, I see the reverse spin anomaly now takes three times as long before it occurs. The reduced proton emission field strength makes the neutron positions above and below the proton appear more stable – more bobs and cycling neutron spins occur before the neutrons leave the proton.

I see the slight increase in offset positions from 1 to 1.05 as a way to compensate for the reduced emission field strength, to reduce the resulting waiting time necessary to “eject” the offset particles to the sides. The 3X reduction and 1 to 1.05 offset changes together result in what appears to be no change at all.

I thought I saw a radius increase that could suggest you’re using test.html as a geometry/sandbox while working on the alternative cardinal position methods - but that’s a stretch.

I am studying, and will continue to study cdm.js for some time to come. I see your latest changes to the charge density received calculation, reducing the number of cardinal position used. I'm not at all certain I see any "smoothing", less calculations has got to be good.

What am I missing? I have several staged/uncommitted file changes you made to cdm-notes.txt and cdm.js txt. I thought they would update at the last pull, I don’t know how to incorporate or reconcile them at present. Everything else is just wonderful.
.

LongtimeAirman wrote:The main change appears to be the 3X reduction in the proton emission field density, from 3000 to 1000.

Code:

//effect.maxParticles = 3000;
effect.emissionRate = 1000;

Nope, that's not it. That only effects the charge shader I imported from AV. It is only a visual representation of the charge emission and does not play any part in the calculations. But I don't blame you for thinking that caused the slowdown.

The slowness is caused by what I mentioned yesterday. I reduced the value of MAX_CHARGE_STRENGTH from 0.2 to 0.1.

LongtimeAirman wrote:I see the slight increase in offset positions from 1 to 1.05 as a way to compensate for the reduced emission field strength, to reduce the resulting waiting time necessary to “eject” the offset particles to the sides. The 3X reduction and 1 to 1.05 offset changes together result in what appears to be no change at all.

Not quite. The initThreeBody04 function puts the Neutron at X=1 while the Protons above and below it are at X=0 (they have a different Y value, obviously). The radius of a Proton or Neutron is 1, so the Protons were emitting straight up and down at the West charge point on the Neutron. The North and South charge points also received charge. This means that all charge received by that Neutron is balanced. The West charge point only receives spin since it receives purely tangential vectors. The North and South charge points receive both tangential and linear velocity, but again, it is equal and opposite so no net force. The Neutron does not move.

In initThreeBody04_02, I moved the Neutron over to X=1.05 so that the West charge point would receive a little bit of linear velocity. Because I used such a small increase, you can see how the Protons give it a little bit of force the first time they move towards the Neutron but less as they move back up. The second time they come down they give it another push and the Neutron shoots away at a quicker velocity.

LongtimeAirman wrote:I thought I saw a radius increase that could suggest you’re using test.html as a geometry/sandbox while working on the alternative cardinal position methods - but that’s a stretch.

Not sure what you saw. Maybe the line that looks like var D = RADIUS * 2;, but that is not actually changing the radius, only calculating the diameter to create the third side of the triangle for the charge point exclusion code.

LongtimeAirman wrote:What am I missing? I have several staged/uncommitted file changes you made to cdm-notes.txt and cdm.js txt. I thought they would update at the last pull, I don’t know how to incorporate or reconcile them at present. Everything else is just wonderful.

If you are prepared to lose all of your own changes, then you can do a hard reset to the top commit of mine. You do this by right-clicking on the commit you want to reset to and click on the 'Reset to this commit' menu item. It will display a dialog box with some options and one of them is a dropdown menu with options like Soft, Medium and Hard. A hard reset will discard all of your own changes and the source will reflect the GIT structure and content.

Alternatively, in the File Status tab or Log/History tab, click on the 'Unsaved changes' line at the top of the commit tree and the box at the bottom will show all of the changed files. You can right-click on each one and select 'Discard' to get rid of your changes to that file. You can probably select multiple files and discard them all at once.

If you want to keep your changes but they aren't merging, then it gets more complicated. Let me know if this is the path you need to take.

.
I was so sure I had the answer; but no, wrong again. I’ll get you yet Red Barron!  

But then, it may take a lot longer than expected, as of a few hours ago, it appears you’ve made at least eight commits today. Good gosh Nevyn. I’ll try to give them a proper review tomorrow.  
.

Well, I was separating various little changes into individual commits just in case we wanted to take some out later. Each commit is an 'All or Nothing' type of thing. It also helps you to see the related changes for a given update. If you read the comment against each commit, you should be able to tell which ones relate to which problem/solution.

.
It’s difficult making my slow progress in this project interesting to the average reader – even charge field devotees. Don’t feel sorry for me, I think its fun using this fancy new platform.

Thanks for including initRandomBody01 - making initial configurations of large numbers of random particles - Nevyn. Like everything else you do, it’s got more puzzling details than I can currently count, it’s also given me a few new ideas.

Today I added a basic lattice configuration. The lattice is 4 particle layers thick. The top and bottom layers are protons, and the two middle layers are neutrons. I posted two versions: 1. initLatticeBody01. Proton separations (15) greater than the emission radius (10) let this lattice just sit there – like a brick.



And 2. initLatticeBody02. Proton separations are slightly less than the emission radius – the brick blows apart.



Each proton is emitting charge. The breaking lattice makes a larger computational load, see the slower 29 FPS (frames per second) here, vice 55 FPS for “the brick”. Note that the two larger neutrons below and to the right of the image center are overlapping – passing through one another. Collisions seem so far away right now.

I’ve got plenty of little questions: like how did the proton appear in the center of the brick? I tried incorporating little random changes to the neutron’s y positions with no luck. Several comments indicate notional tasks, not yet operational, and not worthy of being called bugs.
 
Still, baby steps. My immediate goal – nothing is certain in this life – is to launch a modified initOneBody01_02 at the wall. That should be fun.

Nevyn, you’ve mentioned needing to implement gravity a time or two, any chance you might be able to incorporate expansion gravity?
.

I haven't seen the code yet, so I don't know why that proton sits in the middle. You may be creating more particles than you need. Remember that array indices are 0-based, so the last item in the array is Array.length - 1. If you created a ParticleArray with 3 particles, then you reference them as 0, 1 and 2. Not 1, 2, 3. Check the line that looks like:

Code:


var particleArray = new ChargeInteractionModel.ParticleArray( <number of items> );


and the following code that will be setting the positions of those particles. Make sure that the highest item index that you use is 1 less than the above. My guess is that you are not changing one of the items, so it remains in the center. It could also be the first item that you are missing, which should be addressed as 0. You can also make sure that you are addressing all items in the array, and have not missed one. That is, all of the array indices that you use are sequential.

There is no particle collision code yet. I have a method in there to handle it, and the algorithm checks for it and calls that method, but it does nothing (apart from setting the return vector to 0, 0, 0, which it must do). Maybe you would like to implement that method? Just a standard inelastic collision. Use a mass of 1 (which means it can probably be ignored in the equation, but don't, as we will set mass and radius soon enough). Find the RADIUS declaration and add in another one for MASS. That makes it easier to change it, but eventually I want that as passed in data. Then we can deal with electrons as well. Remember that the collision method is called for 1 particle only. Not both particles in the collision. The other particle will call the method again for itself. It is inefficient, but I'm not too concerned about that at the moment.

However, the way the collision method is called will mean that it will not work for neutrons. I will need to change the driver algorithm to handle neutrons better. It was written with charged particles in mind and I added in neutrons later and haven't revisited that section.

It is quite amazing how much action we get with just the charge field alone. Kind of shows how it is more important than gravity at this scale.

I'm not sure how to implement gravity yet. I need to read through a few of Miles' papers again to get a feel for how to add it in along side of the charge field code, rather than it including that charge field stuff itself, as the mainstream math does. If I can do it via expansion, without anything actually expanding, then I will do it that way. That is, I don't want the radii of the particles to change at all, but I may be able to calculate how they would change and then use that to determine the gravity vector.

What I need to know is how to balance the charge field with gravity. What is their relative strengths at this scale? As long as we stick to that ratio, then we can make the values whatever we want.

I think a more serious change is required to implement the collision method. We need to know the current velocity to calculate the collision and we don't have that available at the moment. You can still start implementing it and any data that you need, but don't have, then just add a new method parameter for it and I will make sure that it is available and passed in.

.
I was innocent. My picture showed a new initial configuration with a breakdown resulting in converging and overlapping neutrons; a point worth mentioning. I don’t believe anyone expected any collisions yet, although there’s no denying you could have easily done so. At least the neutrons didn’t merge like the particles in Proto-planet.

I repeat, I’m happy for this opportunity to work with you – helping build a charge field collision model. You're the boss. I have plenty of appreciation for your charge field knowledge and math, software and engineering skills. Believe me, I’m anxious to contribute, I'm devoting time to it every day.

For maximum efficiency, I would assume collision detection should be the first task performed in the “charge density received” calculation since a collision can override the calculation. It also makes sense to calculate the accelerations due to gravity alongside charge in the same “charge density received” calculation – 1/r^2 for gravity and r^4 for charge. If you feel we must establish some scale of radius/tangential velocity, then the proton scale is fine. Macro sizes take longer, but I don't believe our model can do the difference justice. We certainly don’t need a gravity calculation for every cardinal position, just a single calculation, from this.particle’s position to the other particle’s position (center to center).

I agree, from what I understand, "a more serious change is required to implement the collision method". Your current collision constraints seem unworkable. Any collision requires being able to reset both particles’ motion set: position, orientation, velocity and spin.

For us, a “simple” collision might mean that we can allow this.particle’s position to remain the same; however, this.particle’s orientation should be reset. I will argue that the “other particle” colliding with this.particle must at least be pushed back to the position at which contact would occur, with a new rebound velocity – based on it’s previous velocity. Even better, we should include the appropriate rebound distance.
.

I think I misunderstood you question about that proton in the center of the lattice. I thought you meant it wasn't supposed to be there and went into debug mode. Now I think you are asking why, as a matter of Physics, does it stay in the center. Which is actually easier to answer.

There is nothing to move it. No protons are close enough to impose any attraction or repulsion. Neutrons don't attract or repulse, so they won't move it either. You may also be asking why it doesn't move those neutrons that are close to it, and that is because they are at a 45° angle to the proton and are in a zero influence zone. That is, the proton neither attracts nor repulses anything in that area.

The lattice arrangements are interesting. Didn't expect them to move quite the way they did.

I have made those changes to get the collision code in there and working. You only need to implement the actual math in the calculateCollision method of ParticleArray. It already contains the data, read in from the appropriate buffers, and the writing to the appropriate output variables. I have included the spin values as well as the linear velocity, but you don't have to use them. I'm not sure if they should be used or not, but they could be used to impart spin between the particles. Don't worry about them at first, just get a standard collision working and then it can be altered to include spin later.

I have split the original ParticleArray.calculate method into 2 methods now. The charge calculations now have their own method so that they could be separated from the collision code. This allows neutrons to be included in collisions while excluded from charge calculations which it didn't do before.

I wouldn't reset the orientation, I would determine the change in spin based on the current spin of both particles and apply that change. Collisions will not always stop the spin because they may have spins that match and therefore do not change the spin of either particle. If they are equal and opposite then they would cancel each others spins, just like Miles talks about with magnetism.

We don't need to move either particle because they have penetrated each other. Normally I would agree with you, but in this case it doesn't apply because we don't have solid particles. We have little spinning BPhotons acting like particles and they allow overlapping.

The collision calculations must be performed for one particle only. All of these calculations are for one particle only. Everything is setup for such math. They all work out the same things, so it all calculates correctly, it is just a bit less efficient than it could be. But if we made it efficient in that way, it would be less efficient in other ways that matter a lot more.

I'll give you an example to illustrate it. Suppose we have 10 particles and we are calculating through them and come to the 4th particle and determine that it collides with the 6th particle. If we decide to move the 6th particle during that calculation, then all particles before the 4th will have worked with a differently positioned 6th particle. While there are ways to deal with this stuff, we don't need it here because the physics allows us to ignore it.

.
CPIM Bug report. No changes. Running particleArray = initLatticeBody02() in order to observe plenty of close particles.
The screen appears to freeze at the moment when two neutrons make contact.

The following error outputs.

//499cdm.js:731 Uncaught ReferenceError: q1 is not defined
//    at module.ParticleArray.calculateCollision (cdm.js:731)
//    at module.ParticleArray.calculate (cdm.js:483)
//    at render (test.html:562)
//    at animate (test.html:555)

.

Sorry about that, looks like I called them s1 and s2 but copied the code from elsewhere where they were called q1 and q2.

This is the code block:

Code:


 (function() // calculate direct collision between particles
 {
 var v = new THREE.Vector3();
 var q = new THREE.Vector3();
 var v1 = new THREE.Vector3();
 var s1 = new THREE.Quaternion();
 var v2 = new THREE.Vector3();
 var s2 = new THREE.Quaternion();
 
 module.ParticleArray.prototype.calculateCollision = function( index1, point1, orient1, index2, point2, orient2, vel, spin )
 {
 var vi = index1 * 3;
 var qi = index1 * 4;
 // read in current velocities and spins for each particle
 v1.x = this.velocities[vi];
 v1.y = this.velocities[vi+1];
 v1.z = this.velocities[vi+2];
 q1.x = this.spins[qi];
 q1.y = this.spins[qi+1];
 q1.z = this.spins[qi+2];
 vi = index2 * 3;
 qi = index2 * 4;
 v2.x = this.velocities[vi];
 v2.y = this.velocities[vi+1];
 v2.z = this.velocities[vi+2];
 q2.x = this.spins[qi];
 q2.y = this.spins[qi+1];
 q2.z = this.spins[qi+2];
 
 // TODO calculate change in velocity for point1 caused by point2
 // place change in velocity into v
 v.set( 0, 0, 0 );
 // place change in spin into q
 q.set( 0, 0, 0, 1 );
 
 // add change to velocity and spin
 vel.add( v );
 spin.multiply( q );
 };
 }());


Change

Code:

var s1 = new THREE.Quaternion();

to

Code:

var q1 = new THREE.Quaternion();

and do the same for s2 to q2.

I have just found another bug in that code. It is not reading the full quaternions because it is missing the w value.

Directly after

Code:

q1.z = this.spins[qi+2];

add

Code:

q1.w = this.spins[qi+3];

and do the same for q2.

.
Ok, progress. I’ve made the four changes as directed. I suppose I should feel guilty for not finding and correcting them myself – almost.

CPIM Bug 2. Particles disappearing.

Now, we have a slightly new problem. When particles touch, they blink out of existence. Are their buffer contents overwritten with zeros -  v.set( 0, 0, 0 )? I would have hoped the particles passed thru each, like before, unless the collision code was provided.

I understand I’m supposed plug in the appropriate change in velocity of this.particle or v1, due to the other.particle, v2, and to not make any changes to the other particle, v2. Given the current problem it looks like I must set both v1 and v2.

Hep me please. Your continued guidance and patience is appreciated.
.

You just need to replace this code:

Code:


 // TODO calculate change in velocity for point1 caused by point2
 // place change in velocity into v
 v.set( 0, 0, 0 );
 // place change in spin into q
 q.set( 0, 0, 0, 1 );


with the implementation. Place the change in velocity in the v variable (a vector) and the change in spin in the q variable (a quaternion). The rest of the code takes care of adding it to where it needs to go.

Not sure why they would disappear though. There is nothing in that code to do that. Do they ever re-appear? If not, then they are being given a bad velocity and have shot away off screen. I had some particles do that when I was getting the major charge algorithm operational. I also found that sometimes the math would calculate invalid values. That is, the numbers are in a state that is 'Not a Number' (yes, that is a possible state of a floating point value). You can check for this by using the isNaN function like this:

Code:


if( isNaN( v.x ) )
{
   // take action for a non-valid number
}


You could zero out the vector (and spin) if you detect invalid numbers. The charge calculations are already doing that. However, spend a bit of time making sure that the math is correct before that. Bad math may give you bad results and should always be the first thing to check. If the math is fine, then it just may be that the numbers are getting too large to store in the 53 bits a JS floating point number has to work with (it is 64 bits but the other bits are used for something else).

To be clear and completely honest, I did not test that collision code, even without the implementation. I ran through a few tests to make sure that the page still worked, but did not look for a test configuration that actually made particles collide. I should have done that. There may be problems higher up in the call stack. Just make sure that your math is correct and if it still has problems, then I will have a look at it. I might have a little bit of time later today to have a look, but can't promise anything.

.
The particles blink out and do not return.  

"Just make sure that your math is correct and if it still has problems".

I made no changes beyond as you directed me earlier. I have not generated any change vectors, my math is not at issue. I believe it "still has problems".
.

Ok. Show me the changes that you did make. Post the whole code block as I did above.

I had a quick look at the calling code and it looks fine, but that is the problem with little bugs, they look fine until you look really closely. I am not at home, so I can't test anything. I'm just looking at the code on BitBucket.

.
If you're not at home don't worry about this now.

I pushed the small changes to BitBucket.  

Code:


 module.ParticleArray.prototype.calculateCollision = function( index1, point1, orient1, index2, point2, orient2, vel, spin )
 {
 var vi = index1 * 3;
 var qi = index1 * 4;
 // read in current velocities and spins for each particle
 v1.x = this.velocities[vi];
 v1.y = this.velocities[vi+1];
 v1.z = this.velocities[vi+2];
 q1.x = this.spins[qi];
 q1.y = this.spins[qi+1];
 q1.z = this.spins[qi+2];
 q1.w = this.spins[qi+3];
 vi = index2 * 3;
 qi = index2 * 4;
 v2.x = this.velocities[vi];
 v2.y = this.velocities[vi+1];
 v2.z = this.velocities[vi+2];
 q2.x = this.spins[qi];
 q2.y = this.spins[qi+1];
 q2.z = this.spins[qi+2];
 q2.w = this.spins[qi+3];
 
 // TODO calculate change in velocity for point1 caused by point2
 // place change in velocity into v
 v.set( 0, 0, 0 );
 // place change in spin into q
 q.set( 0, 0, 0, 1 );
 
 // add change to velocity and spin
 vel.add( v );
 spin.multiply( q );
 };

I'll continue playing with it on a separate copy.
.

Yeah, that looks fine.

That should not change anything. Both v and q are set to an identity value (ie, they do nothing) so it may be vel and/or spin that are the problem. They were being used in a different way before my recent changes, so it may that they are being used somewhere that I don't want them to be anymore. I thought I caught them all, but may have missed one. Or it is something else entirely. I'll have a look when I can.

Fixed it. The spin component of the collision was causing invalid numbers. I have commented it out. I thought I was multiplying by an identity quaternion, so it should do nothing, but I'm not so sure that I was, now.

I have had a look over the Gravity at the Quantum Level paper and found these values that I think should be able to help us implement gravity and make sure that the gravity and charge fields are in the correct proportions.

Gravity of the Proton = Gp = 6.29 x 10^-20 m/s^2
Electrical field of the Proton = Ep = 1.48 x 10^18 m/s^2

Let's look at their ratios:

Ep/Gp = 1480000000000000000 / 0.0000000000000000000629
= 2.35e+37
Gp/Ep = 4.25e-38

This means that the gravitational field is extremely small compared to the charge field. We are currently using a charge field strength of 0.1, so the gravity strength would be 4.25e-39 to keep it proportional. It doesn't look like it will make much difference.

Everyone, please chime in if you have any info about gravity at this level. Any links to papers that might be relevant. Anything, really. I remember reading about gravity being 22 orders of magnitude larger than we thought at the quantum level, but haven't found it in my searches yet. I'm probably skimming over it. Those numbers might already contain it but I'm not sure. I think they must, but would prefer it was spelled out for me.

From "The Third Wave Pt. 5":

Mathis wrote:As the basic motion in the universe, it intersects the E/M field and all other known and unknown fields. Only in this way can it be unified with other interactions. I have already shown in this series of papers that at the quantum level it combines with the E/M field to create the orbit. In subsequent papers I have shown that the strong force can be replaced by gravity at the quantum level, and that the acceleration of gravity at the quantum level can be calculated from known numbers, giving us a field that is actually 1022 more powerful than now thought.

In fact, let us now calculate the force due to acceleration of mass, and see if it is of a proper size to fit the strong force. Here is the value I calculated for the proton:

a = 6.06 x 10-13m/s2
F = ma = 1 x 10-39v4

http://milesmathis.com/third5.html

That's really all I could find myself, after scanning about half a dozen papers. I feel like we know it better as a concept but since most of Miles' work is charge equations, there's not much to work with on gravity equations. Hope it helps though.

.
I implemented a simple collision, a transfer of linear energy alone.

The algorithm I used can be found at the end of the Gamasutra reference  Pool Hall Lessons: Fast, Accurate Collision Detection Between Circles or Spheres, page 3. http://www.gamasutra.com/view/feature/131424/pool_hall_lessons_fast_accurate_.php?page=3

Code:


 module.ParticleArray.prototype.calculateCollision = function( index1, point1, orient1, index2, point2, orient2, vel, spin )
 {
 var vi = index1 * 3;
 var qi = index1 * 4;
 // read in current velocities and spins for each particle
 v1.x = this.velocities[vi];
 v1.y = this.velocities[vi+1];
 v1.z = this.velocities[vi+2];
 q1.x = this.spins[qi];
 q1.y = this.spins[qi+1];
 q1.z = this.spins[qi+2];
 q1.w = this.spins[qi+3];
 vi = index2 * 3;
 qi = index2 * 4;
 v2.x = this.velocities[vi];
 v2.y = this.velocities[vi+1];
 v2.z = this.velocities[vi+2];
 q2.x = this.spins[qi];
 q2.y = this.spins[qi+1];
 q2.z = this.spins[qi+2];
 q2.w = this.spins[qi+3];
 
 // Determine collision reaction.
 // Calculate the velocity and spin changes
 // felt by the receiving charged particle only.
 // The linear momentum velocity exchange is implemented              
 // below. See Gamasutra's Pool Hall Lessons

 // Find the normalized vector between the centers of the
 // overlapping receiver and emitter particles.
 var vectorCPA = new THREE.Vector3();// CPA, collision point axis.
 vectorCPA.copy(point1);
 vectorCPA.sub(point2);
 vectorCPA.normalize();// In the ref, vectorCPA is called n.
 
 // Find the length of each particle's motion along the linear
 // component CPA.
 var a1 = v1.dot(vectorCPA);
 var a2 = v2.dot(vectorCPA);
 
 // Using the optimized version,
 // optimizedPA =  2(a1 - a2)
 //               -----------
 //                 m1 + m2
 // float optimizedPA = (2.0 * (a1 - a2)) / (circle1.mass +
 // circle2.mass);
 var m1 = 1.0;// receiver's mass or this.mass.
 var m2 = 1.0;// emitter's mass or this.mass.
 var optimizedPA = (2.0 * (a1 - a2))/(m1 + m2);
 
 // Calculate v1', the new movement vector of the receiver
 // v1' = v1 - optimizedPA * m2 * n
 var vectorV1Bounce = new THREE.Vector3();
 vectorV1Bounce.copy(vectorCPA);
 vectorV1Bounce.multiplyScalar(optimizedPA*m2);
 var v1Prime = new THREE.Vector3();
 v1Prime.copy(v1);
 v1Prime.sub(vectorV1Bounce);

 // TODO calculate change in velocity for point1 caused by point2
 // place change in velocity into v
 v.set( 0, 0, 0 );

 // place change in spin into q
 q.set( 0, 0, 0, 1 );
 
 // add change to velocity and spin
 vel.copy( v1Prime );// Transfer of linear momentum only.
 //spin.multiply( q );
 };


The coding is direct and straight forward. The resulting collision velocities seem a bit too energetic, I've reviewed it several times. Please give it a look.

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

I can't think of anything to add on the subject of gravity at the proton scale.

Thanks for that reference Jared. In our discussions we always seem to assume the nucleus is held together by charge channeling, but I personally believe gravity does hold the nucleus together. Gravity may not bring nuclei together, although it may help hold it together. Planetary scale charged particles might be more fun.
.

Replace m1 and m2 with MASS. This is a constant created at the top of the file and is set to the value 1.
Remove v1Prime and use v for that purpose instead.
Remove the v.set(0, 0, 0); line (since you are doing that in the above code when setting v1Prime).
Change vel.copy( v1Prime ); back to vel.add( v );.

By using copy instead of add, you are overriding all collisions other than the last one (for this particle). We need to sum all collisions, not just use one of them.

We may find that the value of MASS needs to be reduced in order to balance it with the charge strength and gravity, once that is in. Feel free to reduce it until the collisions look right to you.

.
Thanks Nevyn, I made the changes you identified, with a little more cleanup and pushed them to bitbucket.

A couple of notes.
1. I tried varying MASS from MASS=0.0001 to MASS=10000 with no change in collision outcomes.
2. When line 788 spin.multiply( q ) is uncommented, particles disappear.

Code:


 // float optimizedPA = (2.0 * (a1 - a2)) / (m1 + m2);
 //
 var optimizedPA = (2.0 * (a1 - a2))/(MASS + MASS);

 // Calculate v, our desired receiver velocity change
 // v = v1 - optimizedPA * m2 * n
 var vectorV1Bounce = new THREE.Vector3();
 vectorV1Bounce.copy(vectorCPA);
 vectorV1Bounce.multiplyScalar(optimizedPA*MASS);
 v.copy(v1);
 v.sub(vectorV1Bounce);
 
 // TODO calculate change in velocity for point1 caused by point2
 // place change in velocity into v
 //v.set( 0, 0, 0 );
 
 // place change in spin into q
 q.set( 0, 0, 0, 1 );
 
 // add change to velocity and spin
 vel.add( v );
 //spin.multiply( q );
 };


.

Yeah, I tested that mass change myself and it didn't work. The collision math is the wrong algorithm to be using. I think it is an elastic collision, but we want an inelastic collision. There is definitely too much bounce going on.

.
I pushed a "correction" to the bounce’s energy efficiency by changing the multiplier from 2.0 to 4.0 in the momentum transfer equation for optimizedPA. I can't explain why but it seems to work fine.

//var optimizedPA = (2.0 * (a1 - a2))/(MASS + MASS);
var optimizedPA = (4.0*(a1 - a2))/(MASS + MASS);

You can see the difference between the two values most clearly when running particleArray = initThreeBody04(). With the 2.0 multiplier  the results are inexplicably radical, but with 4.0 the result looks perfectly natural, including the slight sideways motion imparted to the protons.

I believe changing the MASS value had no effect because both particles were equivalent masses no matter what MASS value was actually selected.
.

.


Here's a gif of particleArray = initThreeBody04_03(), a slight numerical change not pushed, made just for discussion. I believe it shows a perfectly valid collision. The –y value for the bottom proton has been changed from -5 to -4.9 so that both protons don’t impact the neutron at the same time as in initThreeBody04(). The change has resulted in a single collision, between the bottom proton and the neutron. What appears to be a second collision is not, it is due to charge repulsion primarily between the top proton and the neutron. Note, I minimized the emission field for clarity.
.

It still doesn't look quite right to me, and I'm not comfortable with 'it looks close enough'. Yes, we can do that temporarily, but we need to know that the math is correct if we want to extract any useful information from this app. I'd suggest removing the charge field interactions for testing, as you can't tell what is causing the forces when there are multiple being expressed. Use some neutrons with initial velocities that make them collide.

Also, create a scenario with 3 neutrons in a line and the outside 2 have equal but opposite velocities that will collide with the center one at the same time. Make sure that the center neutron doesn't move, but the outside ones receive the forces. That will test the summing of all forces received through collision.

.
As requested.

Collision testing. Changing the optimizedPA coefficient value.

In the simple linear collision implemented, the transfer of linear momentum is described by optimizedPA = (2.0 * (a1 - a2)) / (m1 + m2). a1 and a2 are each particle motion’s dot projections onto the collision axis between the two particles - the two linear components of the collision; m1 and m2 = MASS, a given; the value of 2.0 in the expression is appropriate for a perfectly elastic collision. We’re free to change it, doing so results in a variety of responses.  

Code:


 // Using the optimized version,
 // optimizedPA =  2(a1 - a2)
 //               -----------
 //                 m1 + m2
 // float optimizedPA = (2.0 * (a1 - a2)) / (m1 + m2);
 //
 // optimizedPA value testing.
 //var optimizedPA = (2.0 * (a1 - a2))/(MASS + MASS);
 //var optimizedPA = (3.0 * (a1 - a2))/(MASS + MASS);
 //var optimizedPA = (3.5 * (a1 - a2))/(MASS + MASS);
 //var optimizedPA = (3.9 * (a1 - a2))/(MASS + MASS);
 //var optimizedPA = (4.0 * (a1 - a2))/(MASS + MASS);
 //var optimizedPA = (4.1 * (a1 - a2))/(MASS + MASS);
 var optimizedPA = (5.0 * (a1 - a2))/(MASS + MASS);


Consecutive columns. This gif shows a configuration created for collision testing. Consisting of 7 columns and 5 rows for a total of 35 Neutrons. The distance between columns is 25. The distance between rows is 10. Each neutron is given three, (x,y,z) random orientations. The leftmost column is given an initial velocity of 7.5. There are four consecutive sequences shown, corresponding to the linear collision’s optimizedPA values:

a. optimizedPA = 2.0. The leftmost column collides with the second column, then those two columns quickly bug out the right side of the screen without any additional collisions.

b. optimizedPA = 3.0. After each column collides and transfers momentum to the next, each column still has a forward velocity, faster for each consecutive column to the right.

c. optimizedPA = 4.0. Each column transfers all momentum as shown by the post collision stationary neutron columns. If all energy is transferred, how would the collisions increase in energy?
 
d. optimizedPA = 5.0. After each column transfers momentum they begin traveling in reverse, repeated collisions bug the columns off both the right and left sides of the image.

In all cases, the total particle system’s energy increases with each collision.

I also checked optimizedPA values of 3.9 and 4.1. At 3.9, after collisions, the particles continued with a slight forward velocity. At 4.1 after collisions, the particles continued with a slight reverse velocity. The optimized value of 4,0 resulted in the best transfer of momentum.



Three in a row. Here the configuration is changed to 3 columns and 5 rows for a total of 15 Neutrons. The separation distances are the same as before. The leftmost column is given an initial velocity of 7.5 and the rightmost column a velocity of -7.5.

All optimizedPA values below 5.0 resulted in the three neutrons in each row clumped together, with the most overlapped and clumped trios occurring for optimizedPA = 2.0. This gif shows optimizedPA = 5.0, with two outcomes. Somewhat less than half the time the particles would clump together, more often, the neutrons would rebound apart somewhat slower then they converged together in the first place. I don’t know what would cause such a change. I believe the three in a row test is a bust. I don’t see how a simultaneous three way collision is a fair test.

The biggest problem I’ve observed is increasing energy with consecutive collisions. I believe the results I’ve described above support an optimizedPA with a coefficient of 4.0. However, I do not see how any value would result in increasing the total energy of the particle system. The collision calculation alone may not be causing the total system energy increase.  
.

.
Status update. You’ll recall I implemented the collision algorithm while the particles were overlapped, that may be the reason for the total particle system energy increase.

The ‘charge density received’ calculation adds together (N/S,E/W,F/B) all the charge p1 receives from nearby particles. The received charge causes a change velocity – an acceleration - that will be added to p1’s current velocity.  In the middle of the calculation, while checking for p2’s possible contribution to p1’s change accelerations, the distance between p1 and p2 is found to be less than the sum r1 and r2. The particles are overlapped - go to the collision calculation!

As with the ‘charge density received’ calculation, the collision calculation is only intended to return a change velocity (and change spin) for particle 1. I knew I implemented the collision algorithm while the particles were overlapped, that may account for the total particle system energy increase. The change velocity calculated for overlapping particles is a greater magnitude than the change velocity that is calculated for particles at first contact.

It’s true, we’re constrained in that we cannot change the actual position of any particle, but that doesn’t prevent us from moving both particles to where they might have first touched for the purposes of calculation only. Other than obtaining the required velocity change, any position changes made for the collision calculation does not affect the particle at all.

I implemented repositioning the two particles in the collision calculation with positive results.




The top gif shows the increasing energy problem I reported last post. The bottom gif shows the results of repositioning the colliding particle centers. Watch them long enough and you'll see when they begin at the same time, making the energy change obvious. Using the gif maker and paint I made images of individual gif frames (approximations), showing:

Total time between collisions between column pairs 1/2 and 5/6:
Overlapping particles (top gif) - approx. 1.05 seconds.
Touching particles (bottom gif) - approx. 2.244 seconds.

Positive results. I reduced the amount of energy being added with each collision, clearly there's more being added somewhere. A problem or few remain.

Feel free to chime in.
.

Airman wrote:The change velocity calculated for overlapping particles is a greater magnitude than the change velocity that is calculated for particles at first contact.

It can't do that because neither the center points of the particles, nor the vector pointing from one center to the other are actually used in the equation. The vector from one to the other is used to find the component of the existing velocity that is along that line, but that is it. The length of that vector is never used, so it can't effect the result. In fact, that vector is normalized, so its length will always be 1.

What I think is happening is that when the particles are overlapped, the resultant velocity does not change their positions enough to put them outside of each others boundaries, so when the next frame is calculated, they are still overlapping and go through the collision code again. This keeps happening until they are no longer overlapping or touching. This is why the original code you got this from would move the particles so that they were not overlapping. That avoids this problem.

Not sure how to handle it at the moment.

.

It can't do that because neither the center points of the particles, nor the vector pointing from one center to the other are actually used in the equation. The vector from one to the other is used to find the component of the existing velocity that is along that line, but that is it.

I respectfully disagree, the dot projections, a1 and a2 use the normalized center to center collision axis; a1 and a2 are longer when the normalized axis is overlapped.

Code:


812           ///vectorCPA.copy(point1);
813           vectorCPA.copy(collisionPoint1);
814           ///vectorCPA.sub(point2);
815           vectorCPA.sub(collisionPoint2);

Make the changes between point1 and collisionPoint1 and see for yourself.

Can you console those points to clear up any ambiguity?

The site insists on adding http before the slash slash even in the code block. You understand.
.

I agree that the length of those 2 vectors will be different. With the overlapping vector being shorter than the touching vector. However, it is irrelevant, because the very next line normalizes the vector which ensures that it keeps the same direction and that its length is equal to 1. So any difference is lost after that function call.

816 vectorCPA.normalize();// In the ref, vectorCPA is called n.

The reason a1 and a2 are larger when overlapping is because they already contain some velocity from the last collision, which is really the same collision, and are amplifying that velocity. At least, that is my theory at the moment. See if you can determine if the collision is occurring multiple times. Use console.log( 'my message' ) to write debug messages to the console to see what is happening. Use the debugger to step through the algorithm and watch the variables as you do.