Possible Charged Particle Field

Page 14 of 29 Previous  1 ... 8 ... 13, 14, 15 ... 21 ... 29  Next

Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sat Sep 22, 2018 5:17 pm

While the gravity math is in there, it has been disabled by default because it still needs work. You can now enable it in the scenarios just by including this line in the scenario function:

Code:

engine.applyGravity = true;

Or to turn it on for everything you can enable it in the ChargePointMotionEngine class constructor.

It still needs to be balanced with charge emission. I believe that charge emission should be the stronger force at the quantum level, but I'm not sure of the ratio.

Your new collision scenario had me all confused for a bit. I couldn't figure out why I couldn't see any of the particles until I rotated the camera and saw that they are a spiral coming in from the background. Looks pretty cool.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Sep 23, 2018 3:00 pm

Your new collision scenario had me all confused for a bit. I couldn't figure out why I couldn't see any of the particles until I rotated the camera and saw that they are a spiral coming in from the background. Looks pretty cool.
A little confusion is good, turning things about is fair play. I was more concerned with someone losing patience and missing the action - the particles auguring in.

I suppose the main source of confusion is the ‘size’ of the particles. You were absolutely correct in ‘suggesting’ that I go back and link the separation of particle positions to a particle’s charge/emission/gravity radius. Our charge particles have a radius of 1 unit. The particle separation in the collision test configurations is now 22, each particle must be isolated by a volume of space over twenty cubed larger than the particle’s volume. The particles are thus further away and more difficult to see when they are surrounded by all that additional space. When the entire collision grid is visible, the particles appear very small. If the default Particle mesh is turned on, it’s especially difficult to observe neutrons from a pole position. For best viewing, one would turn on Charge axes and a higher Precision.
 
Do you have any particular directions with respect to changing the viewer’s Graphics and Precision settings, i.e. should we? Here, we may reduce user confusion by allowing the user to clearly see the neutrons coming. Of course one should allow the user to change it back.

Sorry the collision group struck you as ugly. Granted, my velocities were above that imposed by the frame rate; higher than one might expect during normal situations. I also seem to recall that not all collision bugs occurred at the higher speeds.

The collision test group now includes, (it still needs work): a lowest velocity – startVel, and highest velocity, stopVel. In Test 01, the range is broken into 10 incremental velocities. Eventually, a user would select the lowest and highest speeds using a control panel extension for this configuration.

You may not have noticed a single moving column colliding with a single stationary column in collision test 01. I believe there’s more difficulty in comparing final particle positions in the linear group when compared to the circular configuration.  

I would also like to portray the perfect collision’s final stationary position - two units away from the initial stationary particle’s position in the direction of the approaching particle - perhaps as a target strike zone box with gradation marks to allow measurements, deviations from the ideal.

Will we see electrons? I realize the frame rate for electrons is not the same as our charged particles.

Give some thought to whether a new configuration might be used to compare gravity and charge. Can we not compare those accelerations directly. Can we compare them with enabling/disabling alone?  

Please feel free to redirect or task me if I get too single minded.

Posting in a rush, the next wave is here.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 23, 2018 7:31 pm

LongtimeAirman wrote:A little confusion is good, turning things about is fair play.

Touche!

LongtimeAirman wrote:Do you have any particular directions with respect to changing the viewer’s Graphics and Precision settings, i.e. should we? Here, we may reduce user confusion by allowing the user to clearly see the neutrons coming. Of course one should allow the user to change it back.

Right now there are a lot of options, because I want to test them all and see the differences. I also want you, and anyone else, to find those differences and figure out why they are different. I actually spent some time yesterday thinking about a new way to show the charge points. Since I have been working with THREE.BufferedGeometry objects and per-vertex colors lately, I saw that I might be able to create a new particle sphere that contained the charge point locations directly on that sphere, rather than using lines that are external to it. So most of the particle would be the primary color of it (red for protons, green for neutrons) but where there is a charge point, it would be another color, maybe black since it goes with any other color.

What I soon realised is that it won't work for any arbitrary locations of charge points. I had to combine the precision of the sphere with the precision of the charge points in such a way that there were more sphere vertices than charge point locations, otherwise the charge point color would cover the sphere. They also had to be an integer multiple of each other. That is, if the precision of the charge points was 8, then the sphere would need N*8 vertices. This made it difficult to implement and I didn't get it correct, so I rolled it all back.

The main problem I had was that I would need to remove all of the different charge point precision options except for the Hosohedron ones. I could create the vertex colors I wanted with a Hosohedron because of the way it has been implemented with math, where-as a lot of the others use set vertices according to some pattern. I wasn't quite ready to remove them all. I am tempted though. The Hosohedron algorithm can be used to create the original NSEWFB positions and it increases in precision in a nice, even manner. I think that is the charge point location algorithm to use.

I think we can remove all of the precision options and just leave Cardinal, Low, Medium and High options.  If you are happy with that, then I will look further into it. Simplifying these options will provide more room for other features to be implemented, such as the per-vertex colors to show charge points.

LongtimeAirman wrote:Sorry the collision group struck you as ugly. Granted, my velocities were above that imposed by the frame rate; higher than one might expect during normal situations. I also seem to recall that not all collision bugs occurred at the higher speeds.

It wasn't the collision group that was ugly, just the collision errors.

LongtimeAirman wrote:You may not have noticed a single moving column colliding with a single stationary column in collision test 01. I believe there’s more difficulty in comparing final particle positions in the linear group when compared to the circular configuration.  

I would also like to portray the perfect collision’s final stationary position - two units away from the initial stationary particle’s position in the direction of the approaching particle - perhaps as a target strike zone box with gradation marks to allow measurements, deviations from the ideal.

Yeah, I've noticed those ending positions being out of place. Not sure why yet, but it only seems to happen with very fast velocities, so I guess some sort of math error. Maybe the initial collision is producing NaN numbers, which then get zero'd out to avoid everything collapsing, but then it works on the next frame. This allows it to proceed with its initial velocity for a bit farther than it should.

LongtimeAirman wrote:Will we see electrons? I realize the frame rate for electrons is not the same as our charged particles.

Electrons bring in a few problems. Yes, the frame rate is a problem but so is size (which are actually the same problem, really). The code is not quite setup to handle them at the moment. I have been slowly moving towards it, but haven't quite reached the point that it needs to be at to handle different radius and mass values.

LongtimeAirman wrote:Give some thought to whether a new configuration might be used to compare gravity and charge. Can we not compare those accelerations directly. Can we compare them with enabling/disabling alone?

Yes, that would be good, and necessary. We need to find the balance point, which should be done through theory, and we need a scenario to make sure that it works as we think that it should. Some of the existing scenarios should do the trick. The Two Body scenarios in particular should be able to show the repulsion of a proton being balanced by the attraction of gravity. Still, if you can think of something else, then just post it and we can work out the details, or just give it a go and see what you come up with.

Being able to enable/disable some forces is just a convenience. Some scenarios may not want to use all forces because they want to show some special behavior of one force. Like the collision tests. We just want to look at the problems with collisions, not be distracted by gravity or the ambient field.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Sep 24, 2018 6:42 pm

.
I think we can remove all of the precision options and just leave Cardinal, Low, Medium and High options.  If you are happy with that, then I will look further into it. Simplifying these options will provide more room for other features to be implemented, such as the per-vertex colors to show charge points.
The current nine Precision options, with no clear differences or rationale for selecting one over another except more or less pink Charge lines are too many. Limiting them to Cardinal, Low, Medium and High would be better.

Oh, I failed to mention earlier, I definitely prefer the lat/long particle mesh, they look neater. The previous triangles mesh was slick enough, but they drew more attention to themselves and were probably a larger graphic load.

Today, I  looked at one of the Lattice configurations, 01. ‘Unbroken’? Sort of, it's now a slow motion breakdown. The configuration consists entirely of neutrons with particle separations greater than the particle interaction zones (2.2*PIM .EMISSION_RADIUS). An extra neutron is added to the grid’s center, within the interaction zones of the central-most, closest eight neutrons. (I noticed the p = null; statement for the first time). The result is some surprising motions, I’ll call it cube dancing. After a minute or two, the central neutron is cast out, and the 8 other neutrons go a bit slower in the opposite direction. The action appeared a little smoother on my machine, with more motions before the eventual ejection of the central neutron and the breakdown of the entire lattice.

Possible Charged Particle Field  - Page 14 5fused10
LatticeBody 01 variations can cause reliable Overlap bug collision errors.

The results described in the previous paragraph apply to a lattice with grid dimensions: edgeX, edgeY, and edgeZ, of 6x4x6. The same applies to 2,2,2 or 4,4,4 or any even#,even#,even#. If the grid dimensions are changed, and the central neutron is placed within four closest neighbors - mid face - Overlap bug collision errors occur. For example, changing the grid from 6,4,6 to  7,4,6, or 6,5,6, or 6,4,7; the center of the grid would then be positioned between four closest at the center of the lattice; all 5 neutrons become ‘fused’ in in an overlap error - in the example’s x,y and z planes respectively. The overlapped particles usually burst apart after some time – up to several minutes – all the while getting closer and closer to each other –overlapping more and more. Likewise, placing the lone center neutron between two closest neutrons - an odd#,odd#,even# grid configuration will result in three overlapped neutrons at the grid’s center.  

It appears that the initial 9 central neutrons for say, a 2,2,2 grid and new neutron center seem to be frozen for a moment in their own overlap error before the action begins.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 24, 2018 11:48 pm

I don't think I mentioned the change to the particle mesh. Those spirals bothered me a bit, so I created a line geometry to represent them instead. Previously, it was just using the geometry for a sphere and rendering it as wireframe, hence you saw the triangles. Now it is its own geometry and uses a THREE.LineSegments object to render them. That Hosohedron algorithm just keeps giving and giving!

I've seen overlapping problems in Lattice 02 (which I like to use every now and again to gauge performance with a lot of particles). Sometimes a couple of neutrons would attach to each other and spin around that bond point. The ambient field, and gravity if enabled, cause all particles to group together, which causes a lot of collisions at the same time. Some of the Three Body scenarios do the same, but with less force and less particles.

There are a few problems at work here.

Looking at the Three Body problem as it is simpler. We have 3 particles in a line and the top and bottom particles are pushed towards the central one by the ambient field. Gravity would do the same thing as the central particle is pulled towards the other 2, but they are equal and opposite forces, so they offset each other and it doesn't move. Once they all collide, both the top and bottom particles hit the central one at the same time and with the same, but opposite, force. This causes the central particle to take the velocity from one and then the other, which cancels out and we end up with no motion.

That makes sense.

However, the influence of gravity and/or the ambient field (or even the attraction from the protons if that is being used) do not disappear. They keep wanting to push all of those particles together. Since the particles have no velocity, even though they are colliding, they do not change each others velocities. So the ambient field or gravity push them together and they start to overlap.

I have actually caused this by reversing a change I made a while ago. In the main processing code of the MotionEngine implementation, it decides which forces to apply to the particle that it is looking at. Now, in theory, there is no reason to stop a charge interaction just because there is a collision at the same time. However, in practice (or virtual practice), there is. I recently reversed that code so that it allowed charge (and possibly ambient field) interactions even if there is a collision in the same frame. I wanted to see if it would work with that after some other changes. It didn't. It can be changed back to avoid some of these issues, but I don't like it. It should be able to process both forces on the same frame, but I'm not sure how to at the moment.

I have been toying with an idea for a few weeks that might help, but again, I don't really like it. It feels wrong. Anyway, my need for purity aside (that sounds a bit racist Embarassed , but is not meant to, pure principles Twisted Evil , not pure genes or race Evil or Very Mad ), we need a way to reverse these overlaps. I can't find a nice way to do it, so may have to revert to something ugly.

One idea was to have a way for the collision code to be able to apply a once-only velocity. Since velocity stays with a particle, there is no way to say 'move back a bit, you've gone too far', but that is what we need. This may mean that we have to process collisions separately from all other forces. Before all other forces so that these little adjustments can be applied before the other forces calculate their numbers. A little bit of a performance hit, but shouldn't be too bad and I choose precision over performance for this type of code.

That won't fix problems that are caused by multiple particles colliding simultaneously though. That is a hard one to fix. I may need to rethink the way forces are calculated to deal with that one. For example, it currently calculates the changes in velocity for all particles, and then it applies all of those changes. We may need to make the changes as we go so that when multiple particles collide at the same time, the forces can transfer across the particles.

Take the Three Body problem above, if we make the changes as we calculate the collisions, then either the top or the bottom particle will be considered to collide with the central particle first. The velocity changes will be calculated and applied. Then the other particle will collide and it will now see the new velocity for the central particle and calculate accordingly.

This would cause the second particle to collide to bounce off first, then on the next frame, the other particle would bounce off. It doesn't feel right, but it may be necessary.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Sep 25, 2018 7:23 pm

.
Thanks for explaining the collision status in detail.

Granted, collisions, gravity, charge emission and charge reception should all be occurring at the same time. It surprised me when you first said it, but sure, I believe it. It’s only natural to expect that the best solution should involve the single motion engine spherical index interaction zone Very Happy.

For review, unless I’m mistaken, collisions are detected when the emission and target particles overlap.
charge-point-engine.js, line 720.
Code:
If( info.distance <= module.DIAMETER ) {
engine.collisionForce.interactWith( info.particle );
}
You've explained our main constraint - we may not change a particle’s position. The collision response to the overlapped particle is to calculate a change in velocity or spin in the target particle. Simple-collision-force.js, line 118,
Code:
velocity.add( vel );
Unfortunately, we do not know whether the new velocity or spin will clear the collision or not.

Gravity or charge can compound the problem by working against separating the particles. I suppose that’s part of what you meant by the practical reason to disregard all additional interactions during a collision.
 
How about a collision counter? If a collision extends over some dt or small number of iterations a particle should be able to recover the penetration distance by some anti-overlap re-position response – like an additional drift velocity or deformation away from the emission particle. If motion is prevented by another particle – then a 3body situation may be necessary. But that would be ‘reverting to something ugly’.

Sorry, I keep thinking about it, but I’m not much help here.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 25, 2018 9:50 pm

Well, we are going to have to change their positions, during processing of a single frame. I can't see any other way around it. I just need make sure that it doesn't effect the other calculations. It does raise more problems though. How do you know where to move them to? In a single collision between 2 particles it is easy, but what if there are multiple particles? What if we move a particle inside of another? It all gets complicated, very quickly.

I was thinking of adding a third parameter to the collision force that would allow it to specify a once-off position adjustment. It won't be remembered on the next frame the way a velocity would. That will fix the 2 particle collisions, but not the multiple, or at least, not all of the time. It may work sometimes, maybe even a lot of the time, but not always. Maybe it will fix itself over the next few frames though. We won't really know until we try it.

Maybe I can come up with another spatial index, or add to the existing one, so that we can find all of the collisions on a given particle and make adjustments accordingly. Rather than treating every particle in isolation, we know in advance that we have multiple and can use them all to find the right motions to add.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 26, 2018 12:51 am

Airman wrote:Gravity or charge can compound the problem by working against separating the particles. I suppose that’s part of what you meant by the practical reason to disregard all additional interactions during a collision.

Yes, exactly. Directly after the distance to diameter check you posted above it did have an else, but I commented that out recently and it needs to be put back in to avoid some of these overlapping issues. Long term, we need to fix it in a better way, but that is the short term solution.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Sep 26, 2018 3:31 pm

.
For the record. A few days ago I saw Lattice 01, a previous version by now, creating far more overlap errors. I didn’t mention it at the time as I was trying to figure out how best to show it. As it turned out, I haven’t seen anything like it since. Anyway, many more overlapped pairs were created. So many that overlapped pairs occurred in sets in the grid’s remote particles on opposite sides of the blasted grid; the simultaneous overlapped pairs could burst free at the same time, then, somehow, two of the four speeding neutrons - from opposite bursts - collided on an axis of symmetry. The dual mirror, fourfold symmetry was well neigh perfect. A Matrix moment. I haven’t noticed that particular extreme since then.

Lattice 02 (which I like to use every now and again to gauge performance with a lot of particles).
Lattice 02 starts with a fine crush of particles. I especially enjoyed the slightly overlapped spinning neutron pairs, the closest we have to resembling end-over-end spins. I increased the other lattices’ separation distances, but left 02’s alone. Opps, I should still change the separation distance from 10 to Er, with no change in the action.

Directly after the distance to diameter check you posted above it did have an else, but I commented that out recently and it needs to be put back in to avoid some of these overlapping issues. Long term, we need to fix it in a better way, but that is the short term solution.
I like to note significant interactions. That's part of the reason we create scenarios - to highlight details, not to request or imply they be immediately changed or corrected. Those behaviors good and bad, are a part of developing the program. My mentioning that varying Lattice 01’s grid dimensions can create long term overlapped collision errors with 5 or 3 neutrons is a notable distinction, and not meant as critique.
 
Ok, I un-commented out - or restored the else statement on line 729. In my working system, not GIT.

Furthermore, I’ve subsequently run many iterations of both Lattice 01 and 02; with both the ‘else’ version running beside the ‘commented out else’ version. When else is included, I see no – wait, there’s still an occasional overlap error; although far fewer. The trade-off, or downside to less overlapped particles is a slower system. Including 'else' slows the system down – I might guess by half. If that's true, I’d prefer faster with more obvious errors myself. I wouldn't necessarily want to reduce errors by taking such a big a big performance hit.  

I trust your judgement. There are plenty of problems need solving. If you don’t mind my saying, you’ve made great progress. I’m happy to help.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 26, 2018 8:26 pm

I don't understand why the 'else' version would be slower. If anything, it should be faster, because it is not doing charge (and I think ambient) interactions on a collision. But that shouldn't even be enough to see a difference. Maybe try opening them up in the reverse order. Maybe one of them is getting more of the graphics card than the other. I have noticed that happen when I leave my dev version open and test my website version after an update and the website version runs slower. If I close down the dev browser (I check them in different browsers) then it is fine. Doesn't happen every time though, but often enough that I try to shut down my dev browser before testing. It is usually just the start of the app that seems to slow down to maybe 30 fps for a while. It can clear itself even with both browsers running.

We need to discuss where this app is going. What do we want out of it? What do we want it to do? How will a general user make use of it? Everyone else can chime in here too. I'm not sure if they are listening anymore, we have gotten fairly low-level and it would be difficult for anyone else to understand.

I don't really have good answers for those questions. In one way, I see it as a Particle Interaction Engine. Just an API that can then be used to build other apps with a more focused angle on some problem or solution. I don't mean to make that sound like it is something small and inconsequential, because it is not. In fact, it is a great thing to have in your toolbox. I just don't see what our end-goal is at the moment. Not that that is a problem right now, there is plenty still left to do, but having an end-point can be beneficial too.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Sep 27, 2018 7:21 pm

.
Bad News. I intend to keep quiet for a while, and let someone else have a say, but fate would have it otherwise. My GIT isn’t working today. I tried Fetching three times - morning, noon and a little while ago. The timer keeps going round and round and I re-entered my Atlassian password at least twice for each attempt; no joy, so I canceled those Fetches. I’ve made changes today (adding post collision target grids in collision tests 01 and 02) that I’ve saved as a Commit.

I will not Push the Commit until I successfully Fetch and Pull (if necessary) first. If I have the same problem tomorrow, I may mention it again.
 
/////\\\\\/////\\\\\/////\\\\\

Good news. Meanwhile, does anyone out there have any comments, questions or suggestions concerning the Charged Particle Interaction Model?
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Thu Sep 27, 2018 8:12 pm

I haven't made any changes this week (i've been reading a few Jack Reacher novels and loving it) so there shouldn't be any changes to pull. I've received emails saying that you have pushed changes, so your local repository should be up-to-date.

Have you restarted SourceTree? I have had issues in the past where I leave it open and my machine goes to sleep, but when it wakes up, SourceTree won't work properly and the timer just keeps going round and round but nothing ever happens. A restart of the app usually fixes it. Although, I haven't had that problem in a few months, so maybe they fixed it in an update.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Oct 01, 2018 12:15 am

.
We need to discuss where this app is going. What do we want out of it? What do we want it to do? How will a general user make use of it? Everyone else can chime in here too. I'm not sure if they are listening anymore, we have gotten fairly low-level and it would be difficult for anyone else to understand.
Particle engines are wonderful things. I believe I may have a few thoughts about where we might go.
 
First, I haven’t seen the lattice 04 and 05 spin jitter bugs lately, how did you fix them? Was it a spatial index charge point sign error?

Without a doubt, our single biggest collision error is overlapped particles. It seems worst when particles drift together.

Have I overlooked any specific changes you requested or suggested to any of the scenarios?

I need to look at spin collisions.

We don’t have neutron charge channeling yet. Or slightly differing particle radii, let alone a separate size class like electrons.

Have you ever tried whitespace instead of black? Can we create streams of particles? Or a particle shooter?

Given the charge sampler/profiler and how it allowed you to find a good equatorial emission solution, can you, or we, re-look the possibility of maximum proton emissions at +/-30 degree latitudes?

The Matrix moment still exists. As Lattice 01 breaks down, one might see four simultaneous overlapping pairs bursting apart at the same time with new collisions among the outcomes. How can that degree of symmetry exist between the distant corners of the expanding/disintegrating lattice?

Neutrons alone are comparable to photons. Is it possible to bring in a staked spin object and see if we can corral ‘photons’ with it?

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

Thanks for the continued GIT/ Sourcetree advice and support. I usually turn Sourcetree on in order to copy from my working version to the Git folder before commiting a change, Fetch and/or Pull or Push, then I turn it off. I never 'leave it on' unless I'm reviewing the commit changes. I don't know what resolved my latest BitBucket problem, it just started working again. It may have been due to the fact that I don't always have internet access. Or not all Fetches, Pulls and Pushes work.  
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Mon Oct 01, 2018 6:48 pm

LongtimeAirman wrote:First, I haven’t seen the lattice 04 and 05 spin jitter bugs lately, how did you fix them? Was it a spatial index charge point sign error?

Not sure. I did play around with that sort of stuff last week, but can't remember anything specific that I changed. I still see them in the Unmovable scenarios. It seems like the particle bounces (spin-wise) between 2 points.

LongtimeAirman wrote:Without a doubt, our single biggest collision error is overlapped particles. It seems worst when particles drift together.

Yep, that needs a serious change to fix and I'm still trying to figure out a nice way to do it. It seems like I will need to take all collisions into account, on a given frame. Somehow keep the particles outside of each others boundaries while satisfying all of their velocity changes.

LongtimeAirman wrote:Have I overlooked any specific changes you requested or suggested to any of the scenarios?

I can't think of any at the moment.

LongtimeAirman wrote:I need to look at spin collisions.

Yes, I had a quick attempt at it, without looking into any current theory on the issue and it worked some times but not all the time. I think I need to take relative position into account. Not just look at the spin of the particle, but transform it so that we get the spin from the perspective of the line between the colliding particles.

LongtimeAirman wrote:We don’t have neutron charge channeling yet. Or slightly differing particle radii, let alone a separate size class like electrons.

I am hesitant to add in electrons just yet. We need to deal with the collision issues before we introduce a smaller particle.

Not sure how to handle charge channeling at the moment. My first attempt, for the proton, was to use an attraction, but that is incorrect. It is not an attraction but an absence of repulsion or even a reduction of the received emission. I am starting to think of it as a charge point issue. Effectively, we need a way for each ChargePoint object to know if it is at the poles and to reduce the received charge accordingly. Basically it will act like a reversed charge point.

LongtimeAirman wrote:Have you ever tried whitespace instead of black?

Not in this app, but I tried it in AtomicViewer and it sucks. Too bright and everything looks washed-out.

Are you thinking of a printer friendly version?

LongtimeAirman wrote:Can we create streams of particles? Or a particle shooter?

Not in this app. That is a different type of engine.

LongtimeAirman wrote:Given the charge sampler/profiler and how it allowed you to find a good equatorial emission solution, can you, or we, re-look the possibility of maximum proton emissions at +/-30 degree latitudes?

A few weeks ago I changed the creation of the CHARGE_DENSITY array so that it could be generated from an equation. I really like that and settled on an algorithm that uses the sine function. So we need a way to use that, but the maximum is not at the equator but just before it. I think we should be able to do that by providing an offset to the angles used in the sine function. Right now the equator is represented by sin( 90° ) and the poles are represented by sin( 0° ) (actually, it is a bit more complicated than that, but close enough). so if we give it an offset of 15°, say, then the equator will be represented by sin( 105° ), which is a smaller value than at 90°. 15° away from the equator will be 100% strength. 30° seems too large, but it will be easy to change the offset to see how it turns out.

LongtimeAirman wrote:The Matrix moment still exists. As Lattice 01 breaks down, one might see four simultaneous overlapping pairs bursting apart at the same time with new collisions among the outcomes. How can that degree of symmetry exist between the distant corners of the expanding/disintegrating lattice?

Because they are all the same distances from the other particles. You have created a scenario based on symmetry, so it is going to have symmetry.

LongtimeAirman wrote:Neutrons alone are comparable to photons. Is it possible to bring in a staked spin object and see if we can corral ‘photons’ with it?

I don't think this is the app for that. That requires a more formal representation of charge. This app is about particles, and uses charge for that, but it doesn't represent charge itself.

LongtimeAirman wrote:Thanks for the continued GIT/ Sourcetree advice and support. I usually turn Sourcetree on in order to copy from my working version to the Git folder before commiting a change, Fetch and/or Pull or Push, then I turn it off. I never 'leave it on' unless I'm reviewing the commit changes. I don't know what resolved my latest BitBucket problem, it just started working again. It may have been due to the fact that I don't always have internet access. Or not all Fetches, Pulls and Pushes work.

Probably just the BitBucket servers then. It happens.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Oct 01, 2018 11:03 pm

.
Here's a quick followup.
///////////////////

Possible Charged Particle Field  - Page 14 Tgridd10
Airman. A collision test 01 view. The moving particle - approaching from the right - will push or overlap the stationary particle slightly forward (toward the left), before it ends up in a slightly further than the 'ideal' position, not quite visible in frame 51. Sorry, the gifs are almost always too large to post.  
///////////////////

Nevyn. I am hesitant to add in electrons just yet. We need to deal with the collision issues before we introduce a smaller particle.
Airman. Actually, I was thinking of bigger particles. Our particles of radius one define the top velocity; call it 60, or what if we call it lightspeed(?). Our radius equals 1 particles are the simulation’s smallest particles ; charge interactions are calculated. We could just as easily call the particles nectrons and electrons. The proton would then have a radius of about 10. Our sim should allow us some range of particle dimensions. Including large, slow moving bodies needn’t complicate the present collision situation.
///////////////////
(Whitespace).
Nevyn. Are you thinking of a printer friendly version?
Airman. I hadn’t taken that into consideration.
///////////////////

Airman wrote. Can we create streams of particles? Or a particle shooter?
Nevyn. Not in this app. That is a different type of engine.
Airman. Can we create any other object? Nothing else exists in this simulation? Sure, I like to draw lattice line grids to mark positions, but the lines cannot interact with the particles in any way. We need something besides just the lines or particles. How about a particle chamber? Start with a huge hollow particle that could fit a dozen or so of our particles inside. Any collisions with the large and smaller particles would bounce the small particles back inside the larger particle’s boundary again. Or boundary walls could be treated as the surfaces of very large particles. Or is that wishful thinking?
///////////////////

Nevyn. A few weeks ago I changed the creation of the CHARGE_DENSITY array so that it could be generated from an equation. I really like that …
… but it will be easy to change the offset to see how it turns out.
Airman. That sounds easy enough, the sine maps directly to a particle’s latitudes. Please consider, one may modify the sine argument. In my D function diagram I multiply the angle by 2, so that 2 sine peaks (magnitude) occur, one for each hemisphere (different polarities) at +/- 45, for starters(?). I was thinking about the possible source for a charged particle's dual polarity magnetic field.
///////////////////

(Matrix moment).
Nevyn. Because they are all the same distances from the other particles. You have created a scenario based on symmetry, so it is going to have symmetry.
Airman. I’ll be more than happy to put a little randomizer at every new location velocity or spin. That has the added advantage of making things a little more interesting for the viewer. Probably help slow things down though.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Tue Oct 02, 2018 12:28 am

LongtimeAirman wrote:Actually, I was thinking of bigger particles. Our particles of radius one define the top velocity; call it 60, or what if we call it lightspeed(?). Our radius equals 1 particles are the simulation’s smallest particles ; charge interactions are calculated. We could just as easily call the particles nectrons and electrons. The proton would then have a radius of about 10. Our sim should allow us some range of particle dimensions. Including large, slow moving bodies needn’t complicate the present collision situation.

OK, I hadn't thought about that, but it still falls to the same problem. The model needs to keep velocities below what the smallest particle can handle, so the larger particles will be a lot slower than they currently are. How slow depends on the difference between the smallest and the largest.

LongtimeAirman wrote:Can we create any other object? Nothing else exists in this simulation? Sure, I like to draw lattice line grids to mark positions, but the lines cannot interact with the particles in any way. We need something besides just the lines or particles. How about a particle chamber? Start with a huge hollow particle that could fit a dozen or so of our particles inside. Any collisions with the large and smaller particles would bounce the small particles back inside the larger particle’s boundary again. Or boundary walls could be treated as the surfaces of very large particles. Or is that wishful thinking?

Some sort of virtual boundary would be a good thing to add. I'll see if I can come up with an interface for it and plug it in to the MotionEngine class. I want to be able to use different geometry for the boundary. We could then use a rectangular boundary in some scenarios or a spherical boundary in others. Can't really see any need for other shapes, but you never know what the future holds.

LongtimeAirman wrote:I’ll be more than happy to put a little randomizer at every new location velocity or spin. That has the added advantage of making things a little more interesting for the viewer. Probably help slow things down though.

It will only slow down the initialization. Not the runtime execution of the model. That is, it will take slightly longer to load the page, but it should run the same. And it won't even slow it down noticeably.

See if you can made the randomization configurable. Pass in the max amount of randomness (for the position) and then work out the actual randomness for each particle (actually, each dimension for each particle). Don't forget that you want positive and negative values.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Oct 03, 2018 11:30 am

See if you can made the randomization configurable. Pass in the max amount of randomness (for the position) and then work out the actual randomness for each particle (actually, each dimension for each particle). Don't forget that you want positive and negative values.
I included the following code in Lattice 01. It works fine, but I’m not real clear on how to make the “randomization configurable”. I believe the boolean variable ‘randomPosition’ may be a PIM variable; it may be selectable from the GUI. When true, the code adds small randomDX, randomDY, and randomDZ values to the particles’ lattice positions that Lattice 01 calculates. I don’t see how to make a new function call to create new random positions, am I missing something?
Code:

particles.push( new PIM.Neutron() );
 for( var i=0; i < vol  ; i++ )
 {
 ...
 if(randomPosition === true){
 var MaxRandomDX = 0.2;
 var MaxRandomDY = 0.2;
 var MaxRandomDZ = 0.2;
 var randomDX =  MaxRandomDX * 2 * ( Math.random() - 0.5 );
 var randomDY =  MaxRandomDY * 2 * ( Math.random() - 0.5 );
 var randomDZ =  MaxRandomDZ * 2 * ( Math.random() - 0.5 );
 p.object3D.position.set( countX * dX - offsetX + randomDX, countY * dY - offsetY + randomDY, countZ * dZ - offsetZ + randomDZ );
 }
 else {
 p.object3D.position.set( countX * dX - offsetX, countY * dY - offsetY, countZ * dZ - offsetZ );
 }
 particles.push( p );
 }
 var particleArray = new PIM.ParticleArray( particles );
 return particleArray;

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Oct 03, 2018 2:43 pm

.
Possible Charged Particle Field  - Page 14 Dodeca10

Dodeca Motion Error. I noticed a problem that needs reporting. Easily seen in Colliding Test 03. Moving neutrons approach a stationary grid of protons. In the image above, I changed the camera position to look in the positive x direction, the same direction as the approaching neutrons.

Observing the scenario in each of the Precision levels – except Dodecahedron – we see the neutrons will collide with the either the proton emission field; or the proton and the proton’s emission field. In all cases the neutron will end up going back in the direction it came from, with a negative x velocity. Likewise, protons that are actually hit will be given a positive x velocity, which they may pass to the next proton.  

The image shows Dodecahedron Precision. I removed the proton emissions for clarity. The bottom row of 4 neutrons is still advancing (+X); the three rebounded rows of neutrons have a component of negative Z. The second row of neutrons received the most neg Z.  We can also see the resulting proton motions have a lot of resulting +/-Z component as well.

You indicated your thinking about reducing the Precision list, but it’d be nice to know what the error is.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Oct 03, 2018 7:06 pm

LongtimeAirman wrote:I included the following code in Lattice 01. It works fine, but I’m not real clear on how to make the “randomization configurable”. I believe the boolean variable ‘randomPosition’ may be a PIM variable; it may be selectable from the GUI. When true, the code adds small randomDX, randomDY, and randomDZ values to the particles’ lattice positions that Lattice 01 calculates. I don’t see how to make a new function call to create new random positions,  am I missing something?

All you need to do is pass in a parameter for the max values (which you have called MaxRandomDX, etc). I don't think you need 3 of them, 1 will do for all of them. So it might look like this:

Code:

function initLattice01( ... /* your current parameters */, maxRandomPos )
{
 var randomDX =  maxRandomPos * 2 * ( Math.random() - 0.5 );
 var randomDY =  maxRandomPos * 2 * ( Math.random() - 0.5 );
 var randomDZ =  maxRandomPos * 2 * ( Math.random() - 0.5 );
 ...
}

If you want to get a bit smarter, then we can make that parameter optional like this:

Code:

function initLattice01( ... /* your current parameters */, maxRandomPos )
{
 if( typeof maxRandomPos !== 'number' )
 {
  maxRandomPos = 0; // no randomness if not specified
 }
 ...
 for ...
 {
  var randomDX =  maxRandomPos * 2 * ( Math.random() - 0.5 );
  var randomDY =  maxRandomPos * 2 * ( Math.random() - 0.5 );
  var randomDZ =  maxRandomPos * 2 * ( Math.random() - 0.5 );
  ...
 }
 ...
}

That allows you to not pass in a value for maxRandomPos, or even an invalid value, and it will still work.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Oct 03, 2018 7:09 pm

With respect to dodecahedrons, I suspect that the problem is that they do not have a ChargePoint at the poles and/or that they are not exactly symmetrical.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Oct 03, 2018 7:21 pm

By the way, the general consensus is to use a lower case letter to start a variable name or function/method name. Start with an upper case letter for class names. Use all upper case for constants. It makes it easy to see what a particular name refers to.

Variable and function names use what is called Camel-case. It starts with a lower case letter and every word after the first starts with an upper case letter: myVariableName.

Different people have different styles, but that is very common.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Oct 03, 2018 11:13 pm

.
Sorry, Nevyn, I'm trying to follow instructions and I'm stuck. The code is easy enough, my problem is, I do not know how to use a function call here. In calling the function (randomizingPosition), I will pass maxRandomPos (or not, if, as you say, one includes code for substituting zeros when a numerical value is not included). The function then generates values for randomDX, randomDY or randomDZ, but how do I get those random numbers back to lattice 01 in order to add them to the particle positions? The calling function doesn't recognize them. I've also tried initializing the variables in Lattice01, and overwriting them with the function call with no luck. Please excuse my frustration, your patience is appreciated.  
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Wed Oct 03, 2018 11:20 pm

Nah, my bad. You can't use parameters to the scenario init functions. You could copy the current initLatticeBody01 into a new local and private function that does take parameters, and then call it from initLatticeBody01, but it is not worth the effort unless you wanted to create multiple scenarios with differing randomness.
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Oct 03, 2018 11:50 pm

.
Thanks, that's a relief. I'll stick with your corrections to my previous code, then add randomized positions to a few more scenarios, using the boolean variable randomPosition.
.

LongtimeAirman
Admin

Posts : 1306
Join date : 2014-08-10

View user profile

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Nevyn on Sat Oct 06, 2018 1:52 am

I have removed all of the precision options, leaving only 4: Low, Medium, High and Overdrive. All of these are based on the Hosohedron algorithm, so I will be able to take advantage of that for visualization of the charge points.

I created a new ChargeProfile implementation that will randomize another one. It uses the other profile to calculate the standard value, then it alters the length of that vector by calculating a random number between 0 and 1, if the number is below the threshold then it is clamped at that threshold, otherwise it is used as is. This creates a variation in the force strength between the threshold and 100%.

To visualize that, I have added some code to recreate the charge profile geometry every 60 frames. That should make it update every second. I randomize the initial update count for each particle so that they do not all update on the same frame as that causes stuttering. Note that the profile that you see does not represent the values that are being used in force calculations. It is just a sample taken every second or so.

Possible Charged Particle Field  - Page 14 Random10

This represents a randomness in the ambient charge field feeding the proton emitting the charge and/or the randomness of collisions with charge photons. It provides a variation in the model that leads to unique situations as the model runs.

I have added a new menu that allows you to specify how much randomness you want in the charge profiles of charged particles.

I updated my site with all of the latest changes.

https://www.nevyns-lab.com/mathis/app/cpim/test.html?cp=1&rnd=100&scenario=Unmoveable.Arrange%20about%20Z&graphics=y,n,y,n,n,n
Nevyn
Nevyn
Admin

Posts : 1684
Join date : 2014-09-11

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

Back to top Go down

Possible Charged Particle Field  - Page 14 Empty Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 14 of 29 Previous  1 ... 8 ... 13, 14, 15 ... 21 ... 29  Next

Back to top


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