Possible Charged Particle Field

Page 3 of 7 Previous  1, 2, 3, 4, 5, 6, 7  Next

Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Jul 20, 2018 7:22 pm

.
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.
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Jul 20, 2018 7:37 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Jul 21, 2018 8:49 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Jul 21, 2018 9:07 pm

.
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.
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Jul 22, 2018 9:15 am

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Jul 22, 2018 10:57 am

.
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).




.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Jul 22, 2018 5:02 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Jul 22, 2018 8:41 pm

.
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.


.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Jul 23, 2018 8:16 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Jul 23, 2018 9:48 pm

.
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?
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Jul 23, 2018 11:00 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Jul 23, 2018 11:37 pm

.
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?
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 24, 2018 12:48 am

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 24, 2018 5:57 am

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 24, 2018 6:07 am

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 24, 2018 7:34 am

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 24, 2018 7:36 am

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
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Jul 24, 2018 3:15 pm

.
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
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Jul 24, 2018 6:25 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Jul 25, 2018 12:07 am

.
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.  
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Jul 25, 2018 12:16 am

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Jul 26, 2018 9:34 pm

.
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?
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Jul 26, 2018 10:40 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Jul 26, 2018 10:58 pm

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.
avatar
Nevyn
Admin

Posts : 1134
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Jul 27, 2018 10:58 pm

.
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.
.

LongtimeAirman
Admin

Posts : 872
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 3 of 7 Previous  1, 2, 3, 4, 5, 6, 7  Next

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum