Possible Charged Particle Field

Page 11 of 22 Previous  1 ... 7 ... 10, 11, 12 ... 16 ... 22  Next

Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Sep 07, 2018 5:37 pm

This is why it is a good idea to do a Fetch before you commit. That will show you what is on the GIT server but won't actually Pull them down. Then you can decide if you want to pull them down or not (but you usually should, I can't think of any reason not too, but there might be one).
avatar
Nevyn
Admin

Posts : 1356
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 Sep 07, 2018 5:49 pm

.
No Joy.
Requesting a pull from your line, with the 'Rebase instead of merge' checkbox checked, I received the following error.

The graph is unchanged.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Sep 07, 2018 8:28 pm

You may need to Abort the Rebase before you do anything else. Go to the Action menu and near the bottom there is an item to Abort rebase, if that is enabled (not grayed out) then select it and let it do its thing. This should put you back to where you were before that pull and rebase.

The error has occurred because you still have changes that are not committed. Either commit them (but don't push) or stash them (this removes them from the files but you can add them back when you want to). Then try to pull and rebase again.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 07, 2018 8:43 pm

.
'Abort the Rebase' is greyed out, and not a option.

I haven't made any additional changes that I'm aware of. The uncommitted changes at the top seem to refer to your octahedron changes, not mine.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Sep 07, 2018 8:58 pm

Nah, it definitely refers to your changes. Click on the Unsaved changes item in the graph to see if there are any. If so, then stash them (or deal with them however you want) and try the Pull and rebase again.

If all else fails, you can always clone from GIT again.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 07, 2018 10:01 pm

.
Thanks again Nevyn, I re-cloned, committed and pushed my changes. I must learn to do a better job with Git, I'll try a few tutorials.  

Jared, Sorry to step on your post and cause a ruckus.  
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Sep 07, 2018 10:10 pm

Cool. That is often the easiest way to get out of a bind.

I just wanted to mention that I don't want you to feel obligated to work on this app. You can take a break any time you want. Sometimes I just don't feel like working on my apps, so I don't. If I feel like watching a movie, but know that I should be fixing some bug, then I'll just watch a movie and maybe get to that bug afterwords, or maybe not at all. I might not get back to it for a week or more, sometimes months. We don't have any deadlines or any pressure that we don't put on ourselves. I certainly don't want to put any pressure on anyone. If you have the desire to work on it, then go ahead, but if you don't, then don't force it. We'll get it done eventually. No rush.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 07, 2018 10:48 pm

.
Aside from a few small embarrassments like today, everything's great, thank you very much. Knowing one can re-clone is a real relief, but it's also a pretty crude tool to rely on.

This project is perfect, something I've always wanted. I intend to devote a great deal of time to it in the future - but you're the boss. I'm extremely happy to be working with you, but at present I'm a bit of a burden, a cross between Sancho Panza and the Sorcerer's apprentice (Mickey Mouse). Eventually I'll get out of the learning mode and make some real contributions.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Sep 08, 2018 9:30 pm

Found a bug in the charge force calculations that caused some serious issues. Nothing has been working very well since the start and I was dismissing it as equatorial interactions when an attracted particle got close. Turns out it was just crappy math.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 08, 2018 10:15 pm

.
Correcting bad math is good progress. Can't wait to see it.

I received a new Windows 10 update last night and nothing is working well. I was ready to commit my own changes (I'm still on the icosa but I'd like to cover all the configurations before playing with gravity), checked BitBucket and found you had changed -1 back to 1. I committed my changes without a push. I tried Fetching and Pulling for minutes on end with no outcome. Ok, something new, I'm receiving an atlassian log-in request every minute I'm in Scourcetree, I may need to go back to them for another bug fix.

Now I'm taking a break.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Sep 09, 2018 4:27 am

I have added the ability to stop a Particle from moving and/or spinning. This allows you to remove one of them to focus on the other. You can set it on a per particle basis. There are some new scenarios that make use of it by stopping the neutrons from moving so that we can see the spin effects from the charge emission of a proton.

It sounds like you need to reset your credentials in SourceTree. Goto the Tool menu, select Options and then click on the Authentication tab. From there you can edit your account or remove some saved passwords. If you edit the account don't change anything except for the password. The rest has been working so it should not need to be changed.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 09, 2018 11:27 pm

.
The Good/Bad Status Update.

Good Status. Thanks. My SourceTree (Bitbucket) is working again. I checked the SourceTree Authentication tab - it was empty. There were no Bitbucket credentials in my Windows Credential Manager either (a previous problem). I cleared the desktop of everything except SourceTree, did a Fetch, caught and replied to the first Atlassian log-in request. I think I’m back to normal.

Bad Status. We have a conflict. My next step would be to pull your changes – carefully unselecting the ‘commit merged changes immediately’ option, followed by a Push. I haven’t tried it yet, because I don’t think it would be pretty. I noticed your latest change is adding the new Scenario group Unmoveable, beginning at line 356 in Test.html. In my commit I’ve added the function drawIcosaSurface at the same location. If I Pull your changes now, then I will need to resolve the conflict. Unless I'm mistaken, I believe that involves a Source Tree resolution tool, something new. Or I can re-clone again, and Commit my changes to Test.html when Unmoveable is already in Test, with no conflict.  

Thanks for your continued attention and patience. I’ll await your direction.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 10, 2018 12:25 am

A merge conflict can be difficult to fix. It can be very easy too, and it should be in this case, but it will be made difficult because I can't see anything.

What you need is an application that shows you the differences between 2 files and allows you to select what you want to merge. The one I use at work is a professional product and so it costs money. There are free ones available though. I have asked around the office and you can try to use one called KDiff3 (http://kdiff3.sourceforge.net/). You have to tell SourceTree to use it. Open the Action menu, select Options and go to the Diff tab. On there you will see the lower section called 'External Diff / Merge'. On that part, there is an option to select an 'External Diff Tool'. Drop that down and select KDiff3. I'm not sure what else you will need to do. Maybe tell it where the executable is or it might be able to figure that out on its own.




Once that is done, you can right-click on files that have a merge conflict and hover over 'Resolve Conflicts' and then select 'Launch External Merge Tool'. This will open up KDiff3 with the 2 files.

KDiff3 will present you with 3 panes. The right and left panes will contain the 2 files (which one is which I don't know, you should be able to figure that out by looking at the content of them as one will contain my changes and one will contain yours). The center pane is where you merge things together. You can select the sections that are different in the 2 files and move them into the center version. In this case, you want both of our changes. Once you have the center file looking correct, save it and close KDiff3. Then SourceTree will pick up the changes and you should be able to continue with the merge (Action menu). If not, you might need to select the file, right-click, hover over 'Resolve Conflict' and then select 'Mark Resolved'. Then continue with the merge.

Alternatively, you could create a new branch and commit your stuff to that and then create a Pull Request so that I can merge them together. I think you can only create a Pull Request from the BitBucket website. If you can't see where to do that, then just let me know and I will merge them without it. A Pull Request is just a formal way of asking someone to merge your work. Since it is just the 2 of us, we can forego the formality.
avatar
Nevyn
Admin

Posts : 1356
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 Mon Sep 10, 2018 7:21 am

I think I have misunderstood. I thought you had pulled my changes, but on a re-read of your post above, it doesn't seem like you have. In that case, this isn't really a problem. You should be able to Pull with the rebase option checked (if your changes have been committed but not pushed). Don't worry about line numbers. The apps work all that out by comparing content, not lines. It should be able to figure out how to put those 2 together because we have not changed the same section of that file. In fact, we have added new content rather than change existing code. Things get difficult when we both change the same thing. Then you, or I, have to decide which one to keep or which parts of each to keep.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 10, 2018 5:46 pm

.
Alternatively, you could create a new branch and commit your stuff to that and then create a Pull Request so that I can merge them together…
What can I say? if there’s a way to screw something up, I will. Starting with the fact that I missed your most recent excellent direction, 'pull with a rebase'.

Insead, I put myself on the commit and made it into a branch, origin/featureIcosaSurface. I went to Bitbucket and made a pull request for the branch - I hope it went to you. I went back to sourcetree and tried to reposition myself at origin/master at the top and found I was merging my new "branch" and your subsequent work. Luckily, just this morning I had downloaded and viewed a couple of kdiff3 tutorials. You'll be happy to hear I was able to resolve the conflicts, as you said, our work was separate content. Unfortunately, no joy; Pulls and Pushes resulted in errors. Now I’m a push and 6 pulls behind, realizing that the feature is now the master. My head is lost somewhere.


The status looks grim. I think I need a detailed map with instructions on how to get out.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Sep 10, 2018 6:13 pm

.

If it's any help, here are the staged files. I understand that I would delete the orig file.
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Sep 10, 2018 6:24 pm

I can't see why you have 1 push. The branch starts from the 'Corrected phi calculation' commit, which I pulled a few days ago. All commits on the blue branch (master) are mine and make up the 6 pulls. I can't see anything for you to push. I am a bit concerned about the top red commit, which has a tag for master on it. I guess that is the 1 push, but that should be on a new branch (which the other 2 tags show). I got 2 emails this morning: one for a commit and another for a pull request. I'll have a look tonight and see if I can merge them together.

By the way, you forgot to add a / to the branch name in between 'feature' and 'icosahedraSurface' so it became one word. No big deal. I will try to merge these branches such that that branch will disappear (unlike how I merged my previous branch which kept it as part of the history). It doesn't matter either way, but this is more of an accidental branch rather than a separate piece of work.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 11, 2018 1:58 am

I have fixed up that merge conflict and put your changes on to master. Everything seems to be working, but check your stuff in case I missed something.

KDiff3 was a bit different to what I am used to. I might try another one if I need a merge tool again.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 11, 2018 9:03 pm

.
Current status. Hallelujah. Thank you Nevyn. Given my previous standing of one Push, 6 Pulls, and two uncommitted files (the products of my kdiff3 conflict resolution) – I re-cloned. One small problem (?), it appears the origin/featureIcosahedraSurface is the current main branch.


Should I try to delete the branch - featureIcosahedraSurface branch; or leave it alone?

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

There was mention of a charge interaction math correction. I delayed posting until I had something better to discuss, happy to review the scenarios.

There are significant changes visible in LatticeBodies 02, 04, and 05. I described the 3 vertical neutron proton pairs on the left edge of lattice 04 recently. The neutrons above those protons are given initial spins but not an initial velocity. Now, as before, the neutrons begin to approach the protons’ north poles in a downward z direction. There’s no change in the neutron’s x, y, and z spin reversal errors: single changes, or bouncing between spin angles while the neutrons descend. Something new, the protons’ emissions do not stop the neutrons from colliding into the protons. Half the lattice’s particles exit, stage down. Lattice 05 also blows out the bottom. Lattice 02 now makes a more vertical blast pattern.
 
Unmoveables. You create particle arrays so neatly, in three lines given initSpinTest - more to study. I see that you didn’t add the Unmoveables to the default list //initFct = Scenarios, was that intentional?

Unmoveable 01. A proton at (0,0,0) and unmoveable neutron at (5,0,0). I saw no neutron motion.


Unmoveable 02. After having looked at the three unmoveable scenarios: arrange about Y, Z, and X; this scenario makes better sense, it's shown above. Three neutrons in near equatorial positions, spinning in response to the uneven charge they receive due to their latitude positions – very difficult to achieve. The emission strength is off course highest at the equator. The emission field strength felt by the neutrons at lattitudes above or below the equator will fall off at some rate. That difference in field strength received should cause the unmoveable neutrons to spin. Unfortunately, we will note that using a fixed number of charge point samples involves a mathematical certainty, sampling can cause undesirable side effects and/or artifacts. As I understand it, the higher precision particles were created specifically to minimize such artifacts.

Unmoveable, arrange about Y. A proton at (0, 0, 0) is surrounded in the Y plane by a ring of 16 unmoveable neutrons 5 units away. The neutrons are within the proton’s emission field; the neutrons start rocking, then tumbling. The tumbling looks quite natural.

With CP precision selected, every other neutron in the ring: front, back, left, right and the four positions directly between them remain stationary - they do not react to the emission field. With CP precision selected, the stationary neutrons are receiving ‘balanced’ charge. The other neutrons are spinning in reaction to the spin imbalance caused by the particle’s precision selected. Since none of the unmoveable neutrons can be pushed out of their positions, I would expect all the neutrons would remain stationary until small differences begin to accrue to new stable positions at varied spin angles, or slow random spins. After a while, more than a minute or two, the neutrons begins experiencing spin reversals - bouncing between spin positions. The reversals last for a while, then stop as the neutrons resume their natural looking tumbling. Infrequent, intermittent spin reversal errors.

With Icosa precision selected, only the four particles in the F,B, L, R positions remain stationary. After some time, the tumbling icosa particles also display intermittent spin reversal errors. With the other higher precision selected, the particles’ spin motions appear lifelike. The same intermittent spin reversal errors are present, although they are harder to see.

Unmoveable, arrange about Z. 16 neutrons in a z-plane ring (16 at the top) around the proton at ( 0, 0, 0 ). With CP selected– Above (16 ), right (4), below(Cool, and left (12), positions remain stationary. The 4 particles directly between them (2, 6, 10, 14) move very slowly, even stopping in new positions for long periods of time – just what I would expect.

On the other hand, why would particles 2,6,10,14 move very slowly or not at all? Also, positions: 1, 3, 5, … , 13, 15 all spin at the pretty much the same rate, that doesn’t seem to make sense, so I check the charge density values.
CHARGE_DENSITY = [100, 90, 75, 50, 30, 10, 5, 2, -5, -15, -30];
I believe the charge density shown is a vertical (latitude) profile. The pole emission value of -30 is a third the magnitude of the equator’s 100. The greatest differential (-30)-(-15) = -15 occurs near the pole, so that complicates things like a faster spin near the pole. I would expect to see particles 1,7,9,15 (near the pole) spin at one rate while particles 3,5,11,13 (near the equator) will spin at a higher rate, but I’m not certain. Or that particles 2,6,10,14 would move more vigorously, not less. That logic makes me believe the neutrons are not properly representing the vertical profile you’ve created.

Unmoveable, arrange about X. Same as Z. 1,3,5,7,9,11,13,15 appear to me to be spinning at the same basic rate (I’ll experiment with those values later); 2,6,10,14 are spinning more slowly, or stationary at new spin positions; 4,8,12,and 16 are perfectly stationary. The higher precision particles are the most responsive.

Those negative charge field values could use some discussion. If I understand things, the particle's emission profile needs tweeking. Aside from the infrequent intermittent spin reversals, the motions look good. Any agreement? Or am I seeing things?

P.S. I received notification of the completed Pull request yesterday, but didn't notice it till just an hour ago.
.


Last edited by LongtimeAirman on Tue Sep 11, 2018 11:19 pm; edited 1 time in total (Reason for editing : Added P.S and corrected 2 typos.)

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Sep 11, 2018 11:21 pm

SourceTree looks correct to me. The tags are just saying that the featureIcosahedraSurface branch is at the same position as master, which is just what we should expect from a merge of those two branches. Yes, you can delete that branch. It is not needed anymore. I'm not sure if I deleted it from GIT (which would be under the REMOTES section of the left hand panel, the BRANCHES section represents only the branches that you have checked out). If you don't want it anymore, then it can be deleted from both. Everything is on master now, so there is no danger in deleting them.

Airman wrote:You create particle arrays so neatly, in three lines given initSpinTest - more to study.

Definitely look over initSpinTest, which is the guts of setting up these scenarios. It takes advantage of the ThreeJS classes that we are working with to place all of the particles. Essentially, it creates a Vector3 to represent the first position (this can be anywhere on the circle that it creates, but it is easiest to put it on 1 dimension only) and then creates a Quaternion that is a rotation about the axis we want the circle to be around. Then, for each Particle to be created, it sets the position using the current value in the Vector3 and then rotates that vector to the next position. Simple and effective.

What that function doesn't do, by design, is change the orientation of those Particles so that they point towards the center. I didn't want that for these tests, but it would be good to create another version that does. It isn't quite as simple as rotating a vector, but pretty close. Give it a try if you want to.

Airman wrote:Something new, the protons’ emissions do not stop the neutrons from colliding into the protons.

Yes, that was the problem that I fixed and had previously thought was the protons equatorial emission pushing the particle away once it got close. Now the attraction holds right up to the collision. It has broken a few scenarios, or at least, they don't behave the same way they did before. Broken is probably not the right word, but it is what I thought when I ran over all of the scenarios for testing and saw that a lot of them don't work the way we are used to. Sometimes, we have to change our expectations and not fall into the trap that it must look the way it did when we created the scenarios. It can be a difficult thing to do sometimes.

Airman wrote:I see that you didn’t add the Unmoveables to the default list //initFct = Scenarios, was that intentional?

A bit of both, really. I did see all of those commented out functions to set the initial one to be used, and wondered if I would bother adding the new ones to it and was leaning towards not doing so. In the end, I just forgot about it. Now that we have the menu, those lines are not really needed anymore.

Airman wrote:Unmoveable 01. A proton at (0,0,0) and unmoveable neutron at (5,0,0). I saw no neutron motion.

That is the intended outcome. Since the neutron is right on the equator of the proton, it should receive equal amounts of charge on both sides which cancel each other out.

The rest of the scenarios currently show problems. Not in the scenarios themselves, but in the way the neutrons react to the protons charge field. I think you have covered it quite well. I placed neutrons just above the equator line expecting them to keep gaining spin, but they don't. There are still problems in the spin algorithms and these tests were designed to help see what that might be. I haven't spent anymore time with it though.

For a bit of fun, temporarily change those neutrons into protons and watch how they all push on the center proton.

Yes, the charge density values can certainly be discussed. I played with them a bit after creating these new scenarios and ended up with the reduced attraction that you have shown above. I even tried removing the attraction as I think that is part of the problems that we are trying to fix.

It has pushed me towards the idea of creating a new Force to represent the ambient charge field. I am thinking that it will create some virtual boundary that represents the volume of space around a particle that ambient charge can come from. For all other particles that are within that boundary, it will calculate how much of that boundary they block and create a vector to represent that. The vector will be the opposite of what the ambient field would do, that is, it will point outwards, not inwards, because the ambient field represents a constant force from all directions. Other particles block that, so it is the same as an attraction towards those particles that is equal and opposite to the force of the ambient field.

It also shows the need for gravity. I will be very happy to remove those attractions from the charge density array once we can do so.
avatar
Nevyn
Admin

Posts : 1356
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 Wed Sep 12, 2018 12:02 am

CHARGE_DENSITY = [100, 90, 75, 50, 30, 10, 5, 2, -5, -15, -30];

Something else I did was to reduce the number of items that represent an attraction. This pushes the change-over point from equatorial emission to polar attraction further towards the poles.

There are 11 items in the array and only 3 of them represent an attraction, therefore, the polar attractions only represent 11/3 of the 90° angle between equator and pole.

I also removed the 0 sections. There used to be a small section between equator and pole that had no repulsion or attraction. I was trying to get the repulsion back when the attracted particles gets close, but it was a lost cause.
avatar
Nevyn
Admin

Posts : 1356
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 Wed Sep 12, 2018 8:33 pm

Before we get too far into a discussion about that charge density array, I probably should mention that I am trying to get rid of it. I want an equation that does the same job and I think I have found some good leads for finding one. However, a discussion would still be good, because I need to find the right equation and it might help me to see what it needs to do a bit better.

How would we find the correct equation for that? Ideally, we would pull it out of some sort of experiment, something like a scattering experiment. It might be worth looking over Miles papers on scattering and any others we might be able to find from the mainstream to get a feel for what the charge profile might look like and what equations are being used to describe them.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 12, 2018 9:04 pm

...about that charge density array ...
Nevyn, I just saw your comment. Here's my quick reply.
The maximum emissions in our charge profile currently occur at the equator, that's a mistake.

These pictures show that maximum missions occur at +/30. That's the profile we should match.
When there are two profile peaks instead of one, there is a stable region between the two peaks - like the rings of Saturn. That's something I had to immediately throw out there.

Ambient space will be comprised of particles and antiparticles. Does our space include antiparticles?
.

LongtimeAirman
Admin

Posts : 1037
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Sep 12, 2018 11:02 pm

I did model that +-30° at first, but soon dropped it because we are dealing with particles, not composite bodies. When moving through a planet, charge has time to create the profile you see above. It is caused by lots and lots of collisions. But a particle doesn't have any of that. It has 1 collision to redirect an incoming charge photon, so there is no time and no reason for it to create the +-30° peaks. Those charge profiles are created by streams of particles, not single photons like we have.

However, I have an abstract class called ChargeProfile, with one sub-class called SimpleChargeProfile (that I want to change the name of to reflect that it is a charged particle profile). So we can create multiple ChargeProfile implementations to reflect different scenarios. I don't want +-30° peaks for a particle, but I do for a planet, so we create a version for planets and moons and stars, etc (composite bodies).

No, we don't have anti-particles because we don't have any spin on the charge photons. The code can support spin from charge, but it isn't being used right now.
avatar
Nevyn
Admin

Posts : 1356
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 Sep 13, 2018 12:53 am

.
I apologize for many typos.

I would hope this sim could demonstrate orbital behavior, aka the relationship between charge and gravity. I know that gravity operates over vast distances, that is, with respect to the size of the particle. Maybe the sim can provide better understanding. In my opinion, equatorial emissions wreck orbits. Your explanation "1 collision to redirect an incoming charge photon" doesn't necessarily suggest that the resulting  emissions are primarily equatorial. It seems to me that single collision, redirected matter, is more likely redirected from somewhere between the pole and the equator, when arriving from above or below, similar to the +/- 30 deg lats. You may say particulate matter doesn't orbit or that gravity is useless at the Particulate matter level. What a killjoy.

Thanks for the +/- charge profile alternative - for the sake of a general class.

I looked at the the rest of the scenarios. Not to inventory them, I was mainly looking for changes and to re-familiarize myself with them. I'll be starting on the dodecahedron configuration next. 

Two body 02, two protons with an initial vertical separation of 10. This is included as the gold standard. The 2 protons can bounce every ten seconds for several minutes without errors.

Two body 02-s1 and Two body 02-s2 are not stable. After a single collision, the two vertical (and y-spinning) protons cannot maintain their common spin axes. The top neutron goes through series of constant spin reversal errors which make these two scenarios difficult to watch.

Two body 03. Two protons with an initial vertical separation of 10, the bottom proton is rotated 90 degrees about the x-axis. I don’t recall the bottom proton also picking up an x-spin before.

Two body 03-s1. Same as 03, but the the bottom proton has a y-spin. This scenario seems to run the same as previously. As in 02-s1 and 02-s2 the top neutron goes through series of constant spin reversal errors.

Three body 01, and Three body 02, three protons in a column, with slightly different yet similar symmetrical spacing are both broken as with Proton Stack 03 below.  

Three body 03, protons above and below, with a neutron in the middle – closer to the top proton. The neutron gently collides with the top neutron, and then follows the proton off the top

Three body 04, and Three body 04-02 Two protons, above and below an offset neutron. The neutron begins by moving more in line with the proton poles. Interesting collision variations, including vertigo - It doesn’t last long,

Three body 05, top and bottom protons, a middle neutron is given a horizontal offset, and Three body 06, top and bottom neutrons, a middle proton is given a horizontal offset. Both scenarios are changed, but don’t seem broken.

Four Body 01-04 are all interesting.

Proton Stack 03 - three protons in a vertical column, is definitely ‘broken. Involving the overlap collision error. The column of three cannot maintain separation, followed by a three-way collision, where they seem to come to rest for a while. Up close you can see how the particles are overlapped and getting closer to each other – more and more, until the collision ‘ends’, usually sending one proton up or down at a good speed, and the other two – which may still be locked together in collision, go the other way.

Proton Stack 04 is better behaved than 03, but it too suffers from the overlap collision error. The vertical column of 4 protons go through series of bounces – maintaining their average separations for about a minute or two before a collision overlap (or two) error occurs, a short build-up time, then break apart from overlap error collision with enough energy for the particles to usually exit the screen up and down.

Proton Stack 05. This scenario suffers from the same problem as 03. All 5 of the initial protons collapse together and sit there – overlapping more and more - till the collision error ends, with higher velocity separations.  

Proton Stack 06. This configuration can also last for a minute or two – a fine executive’s toy – before it needs a reload or restart.

All in all, the 3 and 5 proton stacks (and three body 01 and 02) appeared the most 'broken'. The top or bottom ends quickly blow off. The larger stack splits with greater energy. These two scenarios can last longer if they are slightly modified - by moving the middle proton away from the exact center and unsynchronizing the collisions.  
.

LongtimeAirman
Admin

Posts : 1037
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 11 of 22 Previous  1 ... 7 ... 10, 11, 12 ... 16 ... 22  Next

Back to top


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