Possible Charged Particle Field
Page 28 of 29
Page 28 of 29 • 1 ... 15 ... 27, 28, 29
Re: Possible Charged Particle Field
.
I'll share my meager progress.
Jump right into overdrive. EQS406. With r=1 particles, the minimum spherical radius  without particle contact, is just under 14. At that distance, the r=1 particles are 8.35 angular degrees. Contact occurs between the 3 and the nine particle ring latitudes. Using equatorial offsets, we can add an equator and a new latitude ring. The original 8 equatorial latitude rings, (with 30,30,36,36,36,36,30,30 particles) separated by about 10 degrees have been replaced with 11 latitude rings (of 30 particles each) separated by 7.1916 degrees. N increased from 406 to 472. Not shown. That number could be increased further by addressing the pole latitudes, but I don’t see the point pushing past overdrive – that’s supposed to be our limit. It makes sense to start with a smaller EQS solution, with two less latitude rows compared with 406, then optimize that solution to replace the existing EQS406.
With that in mind I’ll begin with EQS372 northern hemisphere latitudes (up from the equator at zero) and particle ring counts.
[ 11.25, 12 ], // 30 particles
[ 22.5, 12 ], // 30 "
[ 33.75, 12 ], // 30 "
[ 45, 17.1429 ], // 21 "
[ 56.25, 20 ], // 18 "
[ 67.5, 24 ], // 15 "
[ 78.75, 40 ], // 9 "
[ 88.5, 120 ] // 3 "
Working the Overdrive EQS optimization.
Using equatorial offsets, of 360/30/2 degrees, I added a new 30 particle equatorial ring which bumped the EQS372 up to a modEQS402. With r=1 particles, the minimum spherical particle configuration radius  without particle contact, for the 372 (and 402) is just under 12, two smaller than the 406 radius, so the particles appear larger in the modEQS402 image.
I see the 402 is a good improvement in particle uniformity over the EQS406. I'll work the pole ends next, beginning with rotating the 3 particle pole rings by 20 degrees about the poletopole axis. I'll move and may even might add a new polar latitude as well. All changes are straightforward. The particle count should increase a little bit more.
I'll be busy offline for the next two days.
.
I'll share my meager progress.
Jump right into overdrive. EQS406. With r=1 particles, the minimum spherical radius  without particle contact, is just under 14. At that distance, the r=1 particles are 8.35 angular degrees. Contact occurs between the 3 and the nine particle ring latitudes. Using equatorial offsets, we can add an equator and a new latitude ring. The original 8 equatorial latitude rings, (with 30,30,36,36,36,36,30,30 particles) separated by about 10 degrees have been replaced with 11 latitude rings (of 30 particles each) separated by 7.1916 degrees. N increased from 406 to 472. Not shown. That number could be increased further by addressing the pole latitudes, but I don’t see the point pushing past overdrive – that’s supposed to be our limit. It makes sense to start with a smaller EQS solution, with two less latitude rows compared with 406, then optimize that solution to replace the existing EQS406.
With that in mind I’ll begin with EQS372 northern hemisphere latitudes (up from the equator at zero) and particle ring counts.
[ 11.25, 12 ], // 30 particles
[ 22.5, 12 ], // 30 "
[ 33.75, 12 ], // 30 "
[ 45, 17.1429 ], // 21 "
[ 56.25, 20 ], // 18 "
[ 67.5, 24 ], // 15 "
[ 78.75, 40 ], // 9 "
[ 88.5, 120 ] // 3 "
Working the Overdrive EQS optimization.
Using equatorial offsets, of 360/30/2 degrees, I added a new 30 particle equatorial ring which bumped the EQS372 up to a modEQS402. With r=1 particles, the minimum spherical particle configuration radius  without particle contact, for the 372 (and 402) is just under 12, two smaller than the 406 radius, so the particles appear larger in the modEQS402 image.
I see the 402 is a good improvement in particle uniformity over the EQS406. I'll work the pole ends next, beginning with rotating the 3 particle pole rings by 20 degrees about the poletopole axis. I'll move and may even might add a new polar latitude as well. All changes are straightforward. The particle count should increase a little bit more.
I'll be busy offline for the next two days.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
EQS406 versus modEQS372.
Our simulated charge field particles react to the ambient charge field according to the ‘charge’ received at their charge sampling points. Those points are currently calculated by an equiisolatitudinal area algorithm called EQS. We currently use three EQS solutions  46, 130 and 406.
Any algorithm has its purpose and limitations. We may improve the behavior of our charge field particles by increasing the uniformity of the sample point distribution sets over our current EQS precision ‘standards’ by careful modifications. We can conveniently display those sampling point distribution sets by placing neutral particles in the ‘same’ spherical configurations for easy review. These mods may indicate simple improvements to the algorithm itself.
EQS406 compared to EQS 342 modified into modEQS372.
Please reference the above image. In my last post I showed the ‘Overdrive’ spherical configuration  EQS406 and possible alternative configuration, modEQS402 still needing some pole optimization. That pole mod led me to begin at a different EQS solution, modifying EQS342 into a modEQS372, currently my recommended replacement for EQS406.
As in my previous post, with r=1 particles, the minimum spherical particle configuration radius without particle contact, for the EQS342 (and modEQS372) is just under 12. The ‘minimum’ EQS406 radius without particle contact is 14. The EQS406 has 9 northern hemisphere latitude particle rings separated by about 10 degrees: (3, 9, 15, 20, 24, 30, 30, 36, 36). That same set is repeated in the southern hemisphere.
Starting with EQS342  (3, 9, 15, 18, 21, 30, 30, 30, 30, 30, 30, 21, 18, 15, 9, 3). Sixteen latitude rings, totaling 342 points. Make the following modifications:
1. Adding single particles over the poles. EQS doesn’t provide single pole particles. [ 90, 360 ] results in a particle that ‘leans’ on the ptop axis.
2. Offsetting adjacent pole latitude rings. EQS partitions the spherical surface in both latitude and longitudinal alignments. Instead of the current six minimum gaps; point the hex between 2 of the 12 particles in the next particle ring instead of directly at six of them by rotating the 6 particle ring latitude 360/12/2 or 15 degrees. If the pole was three point, it would need the same rotation with respect to its neighboring latitude. Pole latitudes numbers that aren't evenly divisible may not benifit from offset rotations. Note, the modEQS372 in the image still needs its hex rotation. EQS342’s polar latitude group: 3, 9, 15, 18, 21 was changed to modEQS372’s 1, 6, 12, 18, 21, 24.
3. Offsetting adjacent equatorial latitude rings. Given rows of equal number (30) particle rings, we can increase the distance between adjacent (elevation) particles by alternating the starting positions of the each particle ring 360/30/2, 6 degrees. Offsetting adjacent latitudes allows us to change reduce the elevation angle of adjacent latitudes results the resulting distinctive hexagonal alignments.
4. Adding a new 30 particle ring over the equator. Note, all EQS algorithm solutions lack equatorial rings. Offsetting the equatorial latitudes has allowed us to replace the previous 6 latitudes with 10 degree separation to 7 latitudes, each separated by 8.7 degrees, with resulting distinctive hexagonal alignments.
The result is modEQS372  (1, 6, 12, 18, 21, 24, 30, 30, 30, 30, 30, 30, 30, 24, 21, 18, 12, 6, 1). 19 latitudes with 372 points. The modifications above result in increased numbers of particles at EQS342’s radius of 12, without allowing r=1 particles to overlap; EQS406’s minimum radius without r=1 particle overlap is 14.
The new modified distribution is densest between adjacent (azimuthal) particles within the two +/30 particle ring latitudes at the shoulders. The ‘density’ of points reduces toward both the equator and poles.
The main limitation of this method is maximizing the number of equal particle ring latitudes. I believe there are just a small set of two modifiable EQS solutions at this ‘scale’, involving only those solutions with 4 or 6 equal particle length equatorial latitudes. ModEQS372 handles the 6 case, six equatorial latitudes become the modified seven. The EQS130 competition will handle the other, by changing an EQS solution with 4 adjacent (elevation) equal particle equatorial latitudes into the modified five.
EQS130 contenders next.
.
EQS406 versus modEQS372.
Our simulated charge field particles react to the ambient charge field according to the ‘charge’ received at their charge sampling points. Those points are currently calculated by an equiisolatitudinal area algorithm called EQS. We currently use three EQS solutions  46, 130 and 406.
Any algorithm has its purpose and limitations. We may improve the behavior of our charge field particles by increasing the uniformity of the sample point distribution sets over our current EQS precision ‘standards’ by careful modifications. We can conveniently display those sampling point distribution sets by placing neutral particles in the ‘same’ spherical configurations for easy review. These mods may indicate simple improvements to the algorithm itself.
EQS406 compared to EQS 342 modified into modEQS372.
Please reference the above image. In my last post I showed the ‘Overdrive’ spherical configuration  EQS406 and possible alternative configuration, modEQS402 still needing some pole optimization. That pole mod led me to begin at a different EQS solution, modifying EQS342 into a modEQS372, currently my recommended replacement for EQS406.
As in my previous post, with r=1 particles, the minimum spherical particle configuration radius without particle contact, for the EQS342 (and modEQS372) is just under 12. The ‘minimum’ EQS406 radius without particle contact is 14. The EQS406 has 9 northern hemisphere latitude particle rings separated by about 10 degrees: (3, 9, 15, 20, 24, 30, 30, 36, 36). That same set is repeated in the southern hemisphere.
Starting with EQS342  (3, 9, 15, 18, 21, 30, 30, 30, 30, 30, 30, 21, 18, 15, 9, 3). Sixteen latitude rings, totaling 342 points. Make the following modifications:
1. Adding single particles over the poles. EQS doesn’t provide single pole particles. [ 90, 360 ] results in a particle that ‘leans’ on the ptop axis.
2. Offsetting adjacent pole latitude rings. EQS partitions the spherical surface in both latitude and longitudinal alignments. Instead of the current six minimum gaps; point the hex between 2 of the 12 particles in the next particle ring instead of directly at six of them by rotating the 6 particle ring latitude 360/12/2 or 15 degrees. If the pole was three point, it would need the same rotation with respect to its neighboring latitude. Pole latitudes numbers that aren't evenly divisible may not benifit from offset rotations. Note, the modEQS372 in the image still needs its hex rotation. EQS342’s polar latitude group: 3, 9, 15, 18, 21 was changed to modEQS372’s 1, 6, 12, 18, 21, 24.
3. Offsetting adjacent equatorial latitude rings. Given rows of equal number (30) particle rings, we can increase the distance between adjacent (elevation) particles by alternating the starting positions of the each particle ring 360/30/2, 6 degrees. Offsetting adjacent latitudes allows us to change reduce the elevation angle of adjacent latitudes results the resulting distinctive hexagonal alignments.
4. Adding a new 30 particle ring over the equator. Note, all EQS algorithm solutions lack equatorial rings. Offsetting the equatorial latitudes has allowed us to replace the previous 6 latitudes with 10 degree separation to 7 latitudes, each separated by 8.7 degrees, with resulting distinctive hexagonal alignments.
The result is modEQS372  (1, 6, 12, 18, 21, 24, 30, 30, 30, 30, 30, 30, 30, 24, 21, 18, 12, 6, 1). 19 latitudes with 372 points. The modifications above result in increased numbers of particles at EQS342’s radius of 12, without allowing r=1 particles to overlap; EQS406’s minimum radius without r=1 particle overlap is 14.
The new modified distribution is densest between adjacent (azimuthal) particles within the two +/30 particle ring latitudes at the shoulders. The ‘density’ of points reduces toward both the equator and poles.
The main limitation of this method is maximizing the number of equal particle ring latitudes. I believe there are just a small set of two modifiable EQS solutions at this ‘scale’, involving only those solutions with 4 or 6 equal particle length equatorial latitudes. ModEQS372 handles the 6 case, six equatorial latitudes become the modified seven. The EQS130 competition will handle the other, by changing an EQS solution with 4 adjacent (elevation) equal particle equatorial latitudes into the modified five.
EQS130 contenders next.
.
Last edited by LongtimeAirman on Thu Feb 21, 2019 7:00 pm; edited 1 time in total (Reason for editing : Typos!)
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
EQS130, along with two alternatives, modEQS128 and modEQS144 are shown. A few small changes to the existing EQS algorithm (ex. EQS 130) result in the two modified and, I believe, improved (equidistant) point distributions  as shown.
You have my sympathies, post after post of particles in spherical configurations. This is a working project and the devil’s in the details. As you no doubt already know (too well), the present goal is to improve the uniformity of distribution (equidistance wise) of our calculated particle’s charge field sampling points. That should have the side benefit of improved overall performance of our possible charged particle field simulation engine.
Note that the engine is being used as a tool to model the sampling points of a single particle as particle configurations. Aside from my autocad modifications, our particle engine allows one to make these models. I consider them as real and valid in some sense, although to be perfectly honest, I cannot explain nor justify the validity of spherical particle configurations with respect to the charge field. Nevertheless, I’ll work toward developing a spherical group UI that will allow a casual user to create many of them herself. Then that single spherical UI scenario could allow me to discard several redundant and tool scenarios currently in the Spherical group.
The user just selects from these precision levels: Low, Med, High and Overdrive. The default is low. I discussed Overdrive in my last post. EQS130 is our simulation’s high Precision standard, made up of (3, 9, 15, 18, 20, 20, 18, 15, 9, 3), 10 particle ring latitudes totaling 130 particles, and is shown in the top row of the image. This configuration begins to overlap the r=1 particles at about R=7.1. R=7.5 in the EQS130 first row of images.
ModEQS128. – (1, 6, 12, 18, 18, 18, 18, 18, 12, 6, 1), 11 rings, 128 particles. The first alternative to ECP130 begins with EQS108 – (6, 12, 18, 18, 18, 18, 12, 6), 10 particle ring latitudes totaling 108 particles. The configuration begins to overlap the r=1 surface particles near R=6.6. R=7 in the EQS108, as well as the modEQS128– second row images. The modifications are as follows:
1. Add single pole particles.
2. Rotate the 6 particle ring pole, 360/12/2 = 15 degrees. This allows slightly more room between the 6 and 12 particle ring latitudes – say for a slightly larger 6, or smaller 12 particle rings.
3. Convert the four equatorial 18 particle rings into five by adding a new 18 particle ring and
4. Offsetting, or alternating the starting point of each adjacent 18 particle latitude ring by 360/18/2 = 10 degrees (az) so that the 5 rows will form a hexagonal pattern.
ModEQS144 – (3, 9, 15, 18, 18, 18, 18, 18, 15, 9, 3), 11 rings, 144 particles. It is also shown (third row) at the configuration radius R=7. It began as EQS126 (3, 9, 15, 18, 18, 18, 18, 15, 9, 3). Here are the 144 modifications:
1. Rotate the pole triangles 360/9/2 = 20 degrees (az).
2. Offset equal particle (18) equatorial latitudes 360/18/2 = 10 degrees, thereby making room to;
3. Add a new 18 particle latitude ring, increasing the number equatorial latitudes from 4 to 5 in the same area.
I believe both the ModEQS128 and ModEQS144 alternatives provide more uniform point distributions then EQS130.
I’ll look at EQS46, the Medium Precision, next.
.
EQS130, along with two alternatives, modEQS128 and modEQS144 are shown. A few small changes to the existing EQS algorithm (ex. EQS 130) result in the two modified and, I believe, improved (equidistant) point distributions  as shown.
You have my sympathies, post after post of particles in spherical configurations. This is a working project and the devil’s in the details. As you no doubt already know (too well), the present goal is to improve the uniformity of distribution (equidistance wise) of our calculated particle’s charge field sampling points. That should have the side benefit of improved overall performance of our possible charged particle field simulation engine.
Note that the engine is being used as a tool to model the sampling points of a single particle as particle configurations. Aside from my autocad modifications, our particle engine allows one to make these models. I consider them as real and valid in some sense, although to be perfectly honest, I cannot explain nor justify the validity of spherical particle configurations with respect to the charge field. Nevertheless, I’ll work toward developing a spherical group UI that will allow a casual user to create many of them herself. Then that single spherical UI scenario could allow me to discard several redundant and tool scenarios currently in the Spherical group.
The user just selects from these precision levels: Low, Med, High and Overdrive. The default is low. I discussed Overdrive in my last post. EQS130 is our simulation’s high Precision standard, made up of (3, 9, 15, 18, 20, 20, 18, 15, 9, 3), 10 particle ring latitudes totaling 130 particles, and is shown in the top row of the image. This configuration begins to overlap the r=1 particles at about R=7.1. R=7.5 in the EQS130 first row of images.
ModEQS128. – (1, 6, 12, 18, 18, 18, 18, 18, 12, 6, 1), 11 rings, 128 particles. The first alternative to ECP130 begins with EQS108 – (6, 12, 18, 18, 18, 18, 12, 6), 10 particle ring latitudes totaling 108 particles. The configuration begins to overlap the r=1 surface particles near R=6.6. R=7 in the EQS108, as well as the modEQS128– second row images. The modifications are as follows:
1. Add single pole particles.
2. Rotate the 6 particle ring pole, 360/12/2 = 15 degrees. This allows slightly more room between the 6 and 12 particle ring latitudes – say for a slightly larger 6, or smaller 12 particle rings.
3. Convert the four equatorial 18 particle rings into five by adding a new 18 particle ring and
4. Offsetting, or alternating the starting point of each adjacent 18 particle latitude ring by 360/18/2 = 10 degrees (az) so that the 5 rows will form a hexagonal pattern.
ModEQS144 – (3, 9, 15, 18, 18, 18, 18, 18, 15, 9, 3), 11 rings, 144 particles. It is also shown (third row) at the configuration radius R=7. It began as EQS126 (3, 9, 15, 18, 18, 18, 18, 15, 9, 3). Here are the 144 modifications:
1. Rotate the pole triangles 360/9/2 = 20 degrees (az).
2. Offset equal particle (18) equatorial latitudes 360/18/2 = 10 degrees, thereby making room to;
3. Add a new 18 particle latitude ring, increasing the number equatorial latitudes from 4 to 5 in the same area.
I believe both the ModEQS128 and ModEQS144 alternatives provide more uniform point distributions then EQS130.
I’ll look at EQS46, the Medium Precision, next.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
I don’t see how the methodology I’ve been using can “optimize” the EQS46. I suppose I could come up with an objective quantitative measure of equispaced points in order to evaluate the EQS46, and then compare it to an alternative, there are many standard polyhedral forms to choose from. I also wanted to give an additional look at the geodesics. Also I’m sure the ‘fullerene’ icosabased carbon configuration, C60 would be better choice than the EQS46.
Here’s another idea I’ve picked up in my readings, that I need to pass by you. Particle placements based on repulsion; our possible charged particle field should be able to handle that. Using the EQP algorithm, an arbitrary number of Protons can be positioned at the spherical configuration’s radius with their south poles oriented toward the spherical configuration’s center. I imagine the protons’ emission fields may then push each proton into optimal positions which we may then use as an ideal Precision solution set for that number of points.
In order to do that, we must constrain the protons’ motions to the spherical radius. Specifically, is it possible  relatively easily – to: 1. Immobilize, fix, or make Unmoveable  both the proton’s spin axis to always point to the configuration center; as well as 2. Fix the protons distance from that center?
Optimistic, eh? I had to ask.
.
I don’t see how the methodology I’ve been using can “optimize” the EQS46. I suppose I could come up with an objective quantitative measure of equispaced points in order to evaluate the EQS46, and then compare it to an alternative, there are many standard polyhedral forms to choose from. I also wanted to give an additional look at the geodesics. Also I’m sure the ‘fullerene’ icosabased carbon configuration, C60 would be better choice than the EQS46.
Here’s another idea I’ve picked up in my readings, that I need to pass by you. Particle placements based on repulsion; our possible charged particle field should be able to handle that. Using the EQP algorithm, an arbitrary number of Protons can be positioned at the spherical configuration’s radius with their south poles oriented toward the spherical configuration’s center. I imagine the protons’ emission fields may then push each proton into optimal positions which we may then use as an ideal Precision solution set for that number of points.
In order to do that, we must constrain the protons’ motions to the spherical radius. Specifically, is it possible  relatively easily – to: 1. Immobilize, fix, or make Unmoveable  both the proton’s spin axis to always point to the configuration center; as well as 2. Fix the protons distance from that center?
Optimistic, eh? I had to ask.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
Yes, those things are possible, but it isn't pretty and breaks the model we are trying to create. It would require a custom model. I don't think it is worth the effort. It also won't work because the emission gives the particles a velocity which doesn't stop when it reaches some optimal position. They will just keep going (you could step through it, frame by frame to fix this). Plus, how are you going to place them at the start? Wouldn't that placement choose the final positions, with slight variations given that the protons emission is not spherical? That emission profile is a problem too. We don't want it to be a factor is choosing charge reception, only emission.
In order to test the charge point configurations, we can use a bit of math. There is probably some better way to do it, but when I'm in unknown territory and can't see a nice solution, I tend to brute force it and then look for optimizations later.
We take each generated charge point and we calculate the distance to all other particles. We then find the minimum value from that set. So we end up with a minimum value per charge point. Then we compare all of the minimum values to each other. There are many ways to do that but just putting them into a graph would be a good start. If you end up with a straight horizontal line, then you have found an optimal solution. The most optimal solution is that which is closest to Y=0 on the graph.
In order to test the charge point configurations, we can use a bit of math. There is probably some better way to do it, but when I'm in unknown territory and can't see a nice solution, I tend to brute force it and then look for optimizations later.
We take each generated charge point and we calculate the distance to all other particles. We then find the minimum value from that set. So we end up with a minimum value per charge point. Then we compare all of the minimum values to each other. There are many ways to do that but just putting them into a graph would be a good start. If you end up with a straight horizontal line, then you have found an optimal solution. The most optimal solution is that which is closest to Y=0 on the graph.
Re: Possible Charged Particle Field
.
With respect to points on a sphere, I believe repulsion is actually an iterative process. Based on increasing the distance between the closest points in the set of N points on a sphere at a given iteration. It’s another possible alternative to our current EQS and EQP algorithms I hadn’t gotten into  there are many. Equidistant points on a sphere aren't true beyond the platonic solids, and are only approximated. I thought if we had ‘real proton repulsion’  given an EQP starting set – it might work; but you’re correct, I ‘overlooked’ the constant motion of the nonzero velocities as the protons keep repelling each other.
I should point out my obvious thinking. Fixing orientations and distances in the way I suggested mimics the coherence orientation. I suppose any coherence in our possible charged particle field would also require a custom model.
With that in mind, and not for the first time, I googled something like “equispacing points on a sphere”, and found an algorithm based on scurves on the sphere. It’s undergraduate, easy to read for anyone interested in the subject. Nice looking results and it also includes an efficiency function that sounds like what you had in mind.
A New Computationally Efficient Method for Spacing n Points on a Sphere Jonathan Kogan https://scholar.rosehulman.edu/rhumj/vol18/iss2/5/
Pages 54 – 71.
Also, the results look good. The Mathematica code is included, here's the Python code.
Airman. Ok, nix the repulsion idea.Nevyn wrote: Yes, those things are possible, but it isn't pretty and breaks the model we are trying to create. … .
With respect to points on a sphere, I believe repulsion is actually an iterative process. Based on increasing the distance between the closest points in the set of N points on a sphere at a given iteration. It’s another possible alternative to our current EQS and EQP algorithms I hadn’t gotten into  there are many. Equidistant points on a sphere aren't true beyond the platonic solids, and are only approximated. I thought if we had ‘real proton repulsion’  given an EQP starting set – it might work; but you’re correct, I ‘overlooked’ the constant motion of the nonzero velocities as the protons keep repelling each other.
I should point out my obvious thinking. Fixing orientations and distances in the way I suggested mimics the coherence orientation. I suppose any coherence in our possible charged particle field would also require a custom model.
I take it you would like to see some quantitative measure in support of selecting alternative precision candidates, suggesting “brute force” for a start. That’s a change, up to now, I’ve been relying on images to compare the precision candidates, I’ll shoot for numbers too.Nevyn wrote: In order to test the charge point configurations. ...
We take each generated charge point and we calculate the distance to all other particles. …
With that in mind, and not for the first time, I googled something like “equispacing points on a sphere”, and found an algorithm based on scurves on the sphere. It’s undergraduate, easy to read for anyone interested in the subject. Nice looking results and it also includes an efficiency function that sounds like what you had in mind.
A New Computationally Efficient Method for Spacing n Points on a Sphere Jonathan Kogan https://scholar.rosehulman.edu/rhumj/vol18/iss2/5/
Pages 54 – 71.
Pg 62. … we ﬁrst created three new functions to analyze how well the points were spaced on a sphere: SmallestDistance, TheoreticalSmallestDistance, and NormalizedSmallestDistance.
SmallestDistance(pts) takes a list of points and identiﬁes the smallest Euclidean distance between any two points on the sphere. In other words, it identiﬁes the two points that are closest together and outputs the distance between the two.
The TheoreticalSmallestDistance(n) function returns the upper bound for the distance of n equally spaced points on a sphere. It is well known that the optimal spacing of points on the plane is the hexagonal grid. To ﬁnd the upper bound for the distance of n points on a sphere, we imagine there is a planar hexagonal grid that covers the entire area of the sphere. Using this grid, we ﬁnd this upper bound for all n values based on the size and the number of equilateral triangles.
Lastly, we deﬁned the NormalizedSmallestDistance(pts) function as the SmallestDistance(pts)/TheoreticalSmallestDistance(Length(pts)); the function provides a relative accuracy for the points that are around the sphere.
Also, the results look good. The Mathematica code is included, here's the Python code.
Pg 70. The research discussed in this paper has also led to the creation of the Mathematica function SpherePoints[n], which was added in the Mathematica 11.1 update [10]. This Mathematica function enables anybody who wants points spaced equally on a sphere to generate them quickly and easily [8].
 Code:
Pg 72. A.2 Python Code
import math
def spherical coordinate (x , y ):
return [math. cos (x) ∗ math. cos (y) ,
math. sin (x) ∗ math. cos (y) , math. sin (y )]
def NX(n, x ):
pts =[]
start = (−1. + 1. / (n − 1.))
increment = (2. − 2. / (n − 1.)) / (n − 1.)
for j in xrange(0 , n):
s = start + j ∗ increment
pts . append(
spherical coordinate (
s ∗ x , math. pi / 2. ∗
math. copysign (1 , s ) ∗
(1. − math. sqrt (1. − abs( s )))
))
return pts
def generate points (n):
return NX(n, 0.1 + 1.2 ∗ n)
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
Status update. Unfortunately, Jonathan Kogan’s paper didn’t provide all the details. The program is more complicated than it first appeared, and I haven’t decided how I should go about reorganizing the code I previously posted. The important thing is supposed to be the “efficiency measure”. Requoting TheoreticalSmallestDistance(n), “we imagine there is a planar hexagonal grid that covers the entire area of the sphere”, that’s all the information provided on that subject.
I decided to go through the exercise of figuring out the efficiency measure while adding a simpler type of spiral algorithm, based on the Golden ratio. From, Evenly distributed points on sphere,
https://web.archive.org/web/20060728050730/http://cgafaq.info/wiki/Evenly_Distributed_Points_On_Sphere. Also Points on a sphere, October 4th, 2006 by Patrick Boucher. //http://www.softimageblog.com/archives/115
In the meantime, I found Jonathan Kogan’s youtube video of his paper, A New Computationally Efficient Method for Spacing n Points on a Sphere
.
The Efficiency measure, including the TheoreticalSmallestDistance(n) equation I was searching for appears to be part of a small set (3 or 4(?)) of slides – not included in the paper  that served for brief glimpses in the two videos, good enough for a screen capture.
Outputs for the new Golden ratio spherical algorithm with Efficiency measure are shown. Above, the spherical configuration GS50 is on the left and GS406 (from the inside) is on the right. We are looking down along the main N/S y axis for both. While the overall spacing is nice, the poles are either clumped or open.
The Efficiency Measure for GS406 is shown below. Assuming I implemented it correctly the normalized efficiency measure is a poor 0.674. According to Kogan’s paper the best efficiences are about 0.85. Radius 16 is cutting it close, the two closest r=1 neutrons are separated by just 0.040 – almost touching. If one were interested in the just the efficiency numbers, it’s easy to switch between the Parameters and Output control tabs. Curious to see the results, beginning with 10, and incrementing by five up to 65, then 130, then 406, the best efficiency I found was 0.7115 for 10 neutrons, with a fairly straight line dropping to the the GS406’s 0.674. The Golden ratio I implemented is not a good source for equidistant spaced points necessary for our desired charge detection Precision candidates.
.
Status update. Unfortunately, Jonathan Kogan’s paper didn’t provide all the details. The program is more complicated than it first appeared, and I haven’t decided how I should go about reorganizing the code I previously posted. The important thing is supposed to be the “efficiency measure”. Requoting TheoreticalSmallestDistance(n), “we imagine there is a planar hexagonal grid that covers the entire area of the sphere”, that’s all the information provided on that subject.
I decided to go through the exercise of figuring out the efficiency measure while adding a simpler type of spiral algorithm, based on the Golden ratio. From, Evenly distributed points on sphere,
https://web.archive.org/web/20060728050730/http://cgafaq.info/wiki/Evenly_Distributed_Points_On_Sphere. Also Points on a sphere, October 4th, 2006 by Patrick Boucher. //http://www.softimageblog.com/archives/115
 Code:
inc := pi*(3sqrt(5))
off := 1/(2*N)  1
for k := 0 .. N1
z := k/N + off
r := sqrt(1z*z)
phi := k*inc
pt[k] := (cos(phi)*r, sin(phi)*r, z)
In the meantime, I found Jonathan Kogan’s youtube video of his paper, A New Computationally Efficient Method for Spacing n Points on a Sphere
.
The Efficiency measure, including the TheoreticalSmallestDistance(n) equation I was searching for appears to be part of a small set (3 or 4(?)) of slides – not included in the paper  that served for brief glimpses in the two videos, good enough for a screen capture.
 Code:
smallestDistance[pts_] := min[table[N[euclideanDistance[pts[[i]], pts[[j]]]],{i,1.0, length[pts]}, {j, i + 1.0, length[pts]}]]
theorecticalSmallestDistance[pts_] := Math.sqrt(8*Math.PI/(n*Math.sqrt(3)))
normalizedSmallestDistance[pts_]:= smallestDistance[pts]/theorecticalsmallestDistance[length[pts_]]
Outputs for the new Golden ratio spherical algorithm with Efficiency measure are shown. Above, the spherical configuration GS50 is on the left and GS406 (from the inside) is on the right. We are looking down along the main N/S y axis for both. While the overall spacing is nice, the poles are either clumped or open.
The Efficiency Measure for GS406 is shown below. Assuming I implemented it correctly the normalized efficiency measure is a poor 0.674. According to Kogan’s paper the best efficiences are about 0.85. Radius 16 is cutting it close, the two closest r=1 neutrons are separated by just 0.040 – almost touching. If one were interested in the just the efficiency numbers, it’s easy to switch between the Parameters and Output control tabs. Curious to see the results, beginning with 10, and incrementing by five up to 65, then 130, then 406, the best efficiency I found was 0.7115 for 10 neutrons, with a fairly straight line dropping to the the GS406’s 0.674. The Golden ratio I implemented is not a good source for equidistant spaced points necessary for our desired charge detection Precision candidates.
.
Last edited by LongtimeAirman on Fri Mar 15, 2019 7:05 pm; edited 1 time in total (Reason for editing : Added efficiency code)
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
Kogan spiral algorithm, 201 r=1 Neutrons, the configuration radius is 25.
The Kogan spiral algorithm and efficiency measure has been added to the spherical scenarios. Now that we have pictures as well as numbers we can make actual qualitative comparisons. Here’s an abbreviated efficiency calculation  Smallest/Theoretical  for the current three EQS precision standards versus EQP, Golden and Kogan algorithm results.
EQP with 404 particles at 0.797 is higher  better point distribution efficiency  than EQS 406 at 0.788 and Kogan 406 at 0.789.
Next, if I continue as planned, I should look at modifying EQS results by adding an equatorial row of particles and rotating alternate latitudes which could improve the current EQS standard. Also, as I mentioned previously, I should be getting better Golden results. I need to look into that too.
.
Kogan spiral algorithm, 201 r=1 Neutrons, the configuration radius is 25.
The Kogan spiral algorithm and efficiency measure has been added to the spherical scenarios. Now that we have pictures as well as numbers we can make actual qualitative comparisons. Here’s an abbreviated efficiency calculation  Smallest/Theoretical  for the current three EQS precision standards versus EQP, Golden and Kogan algorithm results.
EQP with 404 particles at 0.797 is higher  better point distribution efficiency  than EQS 406 at 0.788 and Kogan 406 at 0.789.
Next, if I continue as planned, I should look at modifying EQS results by adding an equatorial row of particles and rotating alternate latitudes which could improve the current EQS standard. Also, as I mentioned previously, I should be getting better Golden results. I need to look into that too.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
Well Sir, great pain and joy, another fine possible charge particle engine programming tasking is tentatively complete, an efficiency measure is now included with most all our point configurations. Assuming it’s correct, the expanded efficiency table above shows the results.
The polyhedral vertex set – octahedron, cube, icosahedron and pentagonal dodecahedron surprised me. I had assumed the platonic solids were the only ideal solutions. The equidistant spacing of the vertices of the octahedron are the most ideal on the board  0.908  closest to one. What does the icosa’s greater than one value, 1.119 mean? Mediocre cube and dodeca values. I can see why the hoso’s are extinct.
The EQS precision set: 46, 130 and 406 are bold and highlighted. EQS2380.846, and EQS312 – 0.849, would make better standards than EQS 130 and 406. I apologize for giving you grief over the rectangular plot algorithm which you converted to centroids. Given it’s overall values, I have a greater respect for the EQS algorithm and your implementation of it.
I claimed I could improve the efficiencies of some EQS solutions by adding an equatorial particle ring, or pole particles, rotating alternate equatorial or polar latitude rings, so I created a new spherical group scenario “EQS Mods” that shows such mods to EQS336: The result is a very respectable Mod EQS374 with efficiency value of 0.838. I didn’t quite follow the ‘dw centroids logic’ so I adjusted the latitudes by eye, trial and error. I need to work this with autocad and see if I can improve that number further.
Once again, the Golden algorithm has a poor and very linear efficiency result – it must be wrong. On the other hand, the new Kogan algorithm is as good as Golden. K201 or K326 would make fine standards.
The primary benefit of this table is that it provides sufficient justification in selecting a more efficient short list of precision alternatives.
Any thoughts? Feedback? Additional taskings?
.
Well Sir, great pain and joy, another fine possible charge particle engine programming tasking is tentatively complete, an efficiency measure is now included with most all our point configurations. Assuming it’s correct, the expanded efficiency table above shows the results.
The polyhedral vertex set – octahedron, cube, icosahedron and pentagonal dodecahedron surprised me. I had assumed the platonic solids were the only ideal solutions. The equidistant spacing of the vertices of the octahedron are the most ideal on the board  0.908  closest to one. What does the icosa’s greater than one value, 1.119 mean? Mediocre cube and dodeca values. I can see why the hoso’s are extinct.
The EQS precision set: 46, 130 and 406 are bold and highlighted. EQS2380.846, and EQS312 – 0.849, would make better standards than EQS 130 and 406. I apologize for giving you grief over the rectangular plot algorithm which you converted to centroids. Given it’s overall values, I have a greater respect for the EQS algorithm and your implementation of it.
I claimed I could improve the efficiencies of some EQS solutions by adding an equatorial particle ring, or pole particles, rotating alternate equatorial or polar latitude rings, so I created a new spherical group scenario “EQS Mods” that shows such mods to EQS336: The result is a very respectable Mod EQS374 with efficiency value of 0.838. I didn’t quite follow the ‘dw centroids logic’ so I adjusted the latitudes by eye, trial and error. I need to work this with autocad and see if I can improve that number further.
Once again, the Golden algorithm has a poor and very linear efficiency result – it must be wrong. On the other hand, the new Kogan algorithm is as good as Golden. K201 or K326 would make fine standards.
The primary benefit of this table is that it provides sufficient justification in selecting a more efficient short list of precision alternatives.
Any thoughts? Feedback? Additional taskings?
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
I'm not sure how you are calculating those numbers. What equation are you using?
I spent a bit of time implementing a way to test the algorithms. I've pushed some new changes to do so, but there is no code that uses it yet. Here is what I have implemented:
We have some algorithms that generate points on the surface of a sphere, and we want to find the most even representation of that surface. We want each point to be of equal distance to its neighbours. In order to evaluate these algrithms, we must gather statistics about the data they generate.
In the first instance, our data is a series of points. We want to know how far each point is from all other points. For each point in the data set, we calculate the min, max, average and range of the distance to all other points. That gives us an array of min values, one for each point, and an array of max values, etc, etc.
That brings us to the second instance where we have a new data set containing statistics for each location generated by an algorithm. Statistics are addictive, you can't have just one, so let's gather some more statistics from the statistics that we already have.
Now we are analyzing each data set in isolation to the others. We are calculating the min, max, average and range of all mins, then all max values, then all averages and finally, all of the ranges. In the end, we reduce it all down to 16 numbers. Most of which are useless, but we'll get to that in a minute. This is what our final data set looks like:
Now we need to figure out which values mean something to this problem and help us to determine which is the better algorithm. Let's look at each data set and see what it is telling us.
Minimums:
The min data set can tell us how much deviation there is from true equality between points. This is a critical data set for this problem, as it represents the data we are trying to minimize between algorithms. Of particular interest is the range, which we want to approach zero. An algorithm that reached zero would have true equal distance between all points.
The min.min value represents the closest of all point pairs. This value ultimately comes from only 2 points in the original data set.
The min.max value represents the largest minimum of all point pairs. Same as with the min, only 2 points are used to calculate that value. This is the worst that the algorithm gets. Minimizing this value is important. We want min.min and min.max to approach each other.
The min.avg value represents the average minimum distance between points and gives us a general representation of an algorithm. This is probably a good value to initially look at to gauge algorithms. If you have to represent an algorithm with a single value, this is the one to use. While not exactly as important as others, it gives the best general idea of how an algorithm will perform.
Note that the min.avg value, and indeed all values really, heavily relies on the radius used. You must choose one radius and use it for all algorithms in order to be able to compare the numbers. A unit radius is generally the best.
The min.range value represents the difference between the smallest minimum and the largest minimum, therefore, it is a very important value. The closer this is to zero the better.
Maximums:
The max data set can tell us how balanced the points are on the sphere. In a truely balanced set of points, every point has an equal and opposite point from it. The line between those 2 points goes through the center of the sphere. The maximum value for any given point represents the point that is farthest from it. If that value equals the diameter of the sphere, then balance is achieved. If max.range also equals zero, then every point has an opposite.
This is not of important interest, and would not be used to differentiate algoithms in the first instance. If you have a few algorithms that appear equal, then this kind of balance may be used to differentiate them and choose a winner.
The max.min value represents the smallest maximum value.
The max.max value represents the largest maximum value.
The max.avg value represents the average maximum value.
The max.range value represents the difference between the largest maximum value and the smallest maximum value.
If max.avg equals the diameter and max.range equals zero then true balance is achieved.
Average:
The avg data set is of little use, but can be used like the max data set to determine balance. Since it is more dangerous to use as such, it can be ignored for this problem.
The avg.min value represents the smallest average value.
The avg.max value represents the largest average value.
The avg.avg value represents the average average value. Does that even mean something? I think we've gone too meta.
The avg.range value represents the difference between the largest average value and the smallest average value. It can be used to determine increasing uniformity as it approaches zero.
Range:
The range data set is not very important.
The range.min value represents the smallest range value.
The range.max value represents the largest range value.
The range.avg value represents the average range value. A good indicator of uniformity. The closer to zero the better.
The range.range value represents the difference between the largest range value and the smallest range value.
To analyze a set of algorithms, we calculate these values for each algorithm, using the same radius, and then put the important values into a table. Look at those values and see which algorithms look the best.
I have implemented a few new methods in the LocationCreator class to generate these statistics. I've even created a little helper method to just return the important ones, which are only 6 values out of 16. You need to implement each of the algorithms as a LocationCreator, just like you have with EQP. I suggest you copy the eqp.js file to a new file for each new algorithm, renaming each like algorithmname.js, just like eqp.js and eqs.js, etc.
I'll look into creating a new modal dialog that will calculate the stats and present the results for all known algorithms in a table.
I spent a bit of time implementing a way to test the algorithms. I've pushed some new changes to do so, but there is no code that uses it yet. Here is what I have implemented:
Statistics of Points representing the Surface of a Sphere
We have some algorithms that generate points on the surface of a sphere, and we want to find the most even representation of that surface. We want each point to be of equal distance to its neighbours. In order to evaluate these algrithms, we must gather statistics about the data they generate.
In the first instance, our data is a series of points. We want to know how far each point is from all other points. For each point in the data set, we calculate the min, max, average and range of the distance to all other points. That gives us an array of min values, one for each point, and an array of max values, etc, etc.
That brings us to the second instance where we have a new data set containing statistics for each location generated by an algorithm. Statistics are addictive, you can't have just one, so let's gather some more statistics from the statistics that we already have.
Now we are analyzing each data set in isolation to the others. We are calculating the min, max, average and range of all mins, then all max values, then all averages and finally, all of the ranges. In the end, we reduce it all down to 16 numbers. Most of which are useless, but we'll get to that in a minute. This is what our final data set looks like:
 Code:
{
min: {
min: <number>,
max: <number>,
avg: <number>,
range: <number>
},
max: {
min: <number>,
max: <number>,
avg: <number>,
range: <number>
},
avg: {
min: <number>,
max: <number>,
avg: <number>,
range: <number>
},
range: {
min: <number>,
max: <number>,
avg: <number>,
range: <number>
}
}
Now we need to figure out which values mean something to this problem and help us to determine which is the better algorithm. Let's look at each data set and see what it is telling us.
Minimums:
The min data set can tell us how much deviation there is from true equality between points. This is a critical data set for this problem, as it represents the data we are trying to minimize between algorithms. Of particular interest is the range, which we want to approach zero. An algorithm that reached zero would have true equal distance between all points.
The min.min value represents the closest of all point pairs. This value ultimately comes from only 2 points in the original data set.
The min.max value represents the largest minimum of all point pairs. Same as with the min, only 2 points are used to calculate that value. This is the worst that the algorithm gets. Minimizing this value is important. We want min.min and min.max to approach each other.
The min.avg value represents the average minimum distance between points and gives us a general representation of an algorithm. This is probably a good value to initially look at to gauge algorithms. If you have to represent an algorithm with a single value, this is the one to use. While not exactly as important as others, it gives the best general idea of how an algorithm will perform.
Note that the min.avg value, and indeed all values really, heavily relies on the radius used. You must choose one radius and use it for all algorithms in order to be able to compare the numbers. A unit radius is generally the best.
The min.range value represents the difference between the smallest minimum and the largest minimum, therefore, it is a very important value. The closer this is to zero the better.
Maximums:
The max data set can tell us how balanced the points are on the sphere. In a truely balanced set of points, every point has an equal and opposite point from it. The line between those 2 points goes through the center of the sphere. The maximum value for any given point represents the point that is farthest from it. If that value equals the diameter of the sphere, then balance is achieved. If max.range also equals zero, then every point has an opposite.
This is not of important interest, and would not be used to differentiate algoithms in the first instance. If you have a few algorithms that appear equal, then this kind of balance may be used to differentiate them and choose a winner.
The max.min value represents the smallest maximum value.
The max.max value represents the largest maximum value.
The max.avg value represents the average maximum value.
The max.range value represents the difference between the largest maximum value and the smallest maximum value.
If max.avg equals the diameter and max.range equals zero then true balance is achieved.
Average:
The avg data set is of little use, but can be used like the max data set to determine balance. Since it is more dangerous to use as such, it can be ignored for this problem.
The avg.min value represents the smallest average value.
The avg.max value represents the largest average value.
The avg.avg value represents the average average value. Does that even mean something? I think we've gone too meta.
The avg.range value represents the difference between the largest average value and the smallest average value. It can be used to determine increasing uniformity as it approaches zero.
Range:
The range data set is not very important.
The range.min value represents the smallest range value.
The range.max value represents the largest range value.
The range.avg value represents the average range value. A good indicator of uniformity. The closer to zero the better.
The range.range value represents the difference between the largest range value and the smallest range value.
To analyze a set of algorithms, we calculate these values for each algorithm, using the same radius, and then put the important values into a table. Look at those values and see which algorithms look the best.
I have implemented a few new methods in the LocationCreator class to generate these statistics. I've even created a little helper method to just return the important ones, which are only 6 values out of 16. You need to implement each of the algorithms as a LocationCreator, just like you have with EQP. I suggest you copy the eqp.js file to a new file for each new algorithm, renaming each like algorithmname.js, just like eqp.js and eqs.js, etc.
I'll look into creating a new modal dialog that will calculate the stats and present the results for all known algorithms in a table.
Re: Possible Charged Particle Field
I have the statistics dialog up and running. It is comparing EQS, EQP and Hosohedron algorithms at the moment. The balance and uniformity both approach zero, so the lower the number, the better. The min, max and average can not be compared between algorithms, unless each algorithm has approximately the same number of points. So you can compare EQS 46 with EQP 46, or EQS 130 with EQP 130, etc. The range value is comparable across all and shows the variance of the algorithm. Closer to zero is better.
It shows your EQP improvements are very close to the standard EQS algorithm. I'm not sure what they look like, but the numbers look good. I created 3 versions to match the EQS variants. I'm not sure if they are good values or not. Have a look at the bottom of eqs.js to see what I did there. Play around with the numbers to try different options.
It shows your EQP improvements are very close to the standard EQS algorithm. I'm not sure what they look like, but the numbers look good. I created 3 versions to match the EQS variants. I'm not sure if they are good values or not. Have a look at the bottom of eqs.js to see what I did there. Play around with the numbers to try different options.
Re: Possible Charged Particle Field
.
Nevyn wrote. I'm not sure how you are calculating those numbers. What equation are you using?
Airman. The efficiency measure numbers I’ve shown in my tables are the normalizedSmallestDistance[pts_].
normalizedSmallestDistance[pts_]:= smallestDistance[pts]/theoreticalsmallestDistance[length[pts_]]
var smallestDistance = minimum;
The only measured value is the smallestDistance, what you referred to as minmin.
var theoreticalSmallestDistance = radius * Math.sqrt((8*Math.PI)/((n)*(Math.sqrt(3))));
The theoreticalSmallestDistance provides an ideal value for any radius and number of particles. Please consider including it in your statistical set. It allows a way to measure across configuration sets – at a given radius and number of particles – as Kogan mentions in his paper.
Nevyn wrote. It shows your EQP improvements are very close to the standard EQS algorithm. I'm not sure what they look like, but the numbers look good. I created 3 versions to match the EQS variants. I'm not sure if they are good values or not. Have a look at the bottom of eqs.js to see what I did there. Play around with the numbers to try different options.
Airman. We have a disconnect. I’ve made no EQP improvements. I added the EQP set to the particle engine’s precision set two months ago. I added the above efficiency measure to the spherical group scenario EQP Points last month. I should point out, when one selects the ‘approximate number’ of EQP particles of 406 in the parameter tab, here’s the calculated output table:
Since that time, I’ve included the same efficiency measure in all the spherical configurations on their Output control tabs. My latest effort over the last day or two has been in trying to understand EQS var cellAngles well enough to modify it by adding new latitudes. To be honest, I want to throw out the angle and lastAngle averaging and list the desired particle latitudes directly, but that would be changing your centroid calculation.
In case of confusion; I had to give a quick reply lest you be working under a false assumption. I appreciate the stat breakdown and enthusiasm. I'd be happy to include any additional info on the user side of the firewall, on the output control tab’s output table if at all possible.
P.S. Added two same "and number of particles" as in; The theoreticalSmallestDistance provides an ideal value for any radius and number of particles.
.
Nevyn wrote. I'm not sure how you are calculating those numbers. What equation are you using?
Airman. The efficiency measure numbers I’ve shown in my tables are the normalizedSmallestDistance[pts_].
normalizedSmallestDistance[pts_]:= smallestDistance[pts]/theoreticalsmallestDistance[length[pts_]]
var smallestDistance = minimum;
The only measured value is the smallestDistance, what you referred to as minmin.
var theoreticalSmallestDistance = radius * Math.sqrt((8*Math.PI)/((n)*(Math.sqrt(3))));
The theoreticalSmallestDistance provides an ideal value for any radius and number of particles. Please consider including it in your statistical set. It allows a way to measure across configuration sets – at a given radius and number of particles – as Kogan mentions in his paper.
Nevyn wrote. It shows your EQP improvements are very close to the standard EQS algorithm. I'm not sure what they look like, but the numbers look good. I created 3 versions to match the EQS variants. I'm not sure if they are good values or not. Have a look at the bottom of eqs.js to see what I did there. Play around with the numbers to try different options.
Airman. We have a disconnect. I’ve made no EQP improvements. I added the EQP set to the particle engine’s precision set two months ago. I added the above efficiency measure to the spherical group scenario EQP Points last month. I should point out, when one selects the ‘approximate number’ of EQP particles of 406 in the parameter tab, here’s the calculated output table:
Only 404 particles.404 Neutrons. The configuration radius is 17.1. The smallest distance  between the centers of the two closest particles  is 2.581, between neutrons 1 and 2. The theoretical distance is 3.241. Smallest/Theoretical is 0.797.
Since that time, I’ve included the same efficiency measure in all the spherical configurations on their Output control tabs. My latest effort over the last day or two has been in trying to understand EQS var cellAngles well enough to modify it by adding new latitudes. To be honest, I want to throw out the angle and lastAngle averaging and list the desired particle latitudes directly, but that would be changing your centroid calculation.
In case of confusion; I had to give a quick reply lest you be working under a false assumption. I appreciate the stat breakdown and enthusiasm. I'd be happy to include any additional info on the user side of the firewall, on the output control tab’s output table if at all possible.
P.S. Added two same "and number of particles" as in; The theoreticalSmallestDistance provides an ideal value for any radius and number of particles.
.
Last edited by LongtimeAirman on Sat Apr 20, 2019 2:29 pm; edited 2 times in total (Reason for editing : Added P.S.)
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
I had another play with it and have the following table at the moment:
I combined the Balance and Uniformity fields together (and also changed the value being used for the uniformity), because I was out of space. Added in the sample size to show the actual number of points used. The Ideal column shows the theoretical smallest distance, using your equation. I haven't read up on it, so I don't know if it applies to all situations or just whatever Kogan was working on in that paper. The EQS algorithm beats it, though, so it seems to be limited.
I put the Ideal value right next to the Min and Max values, because that is what we want to compare it against. The last column, Factor, is Min/Ideal. I used the Min at first, but it didn't really work. I tried the Average and the results looked better to me. That is the average of the minimum values, so it represents all minimums rather than just the best minimum.
Here is the table using Average/Ideal:
We want to find an algorithm that has a low Range and Balance, and a Factor close to 1. The EQS algorithm is still looking the best to me. You're right about EQP, it isn't complete, but it does have some different cell angles being used. EQSMods is a new one where I extracted the cell angles from your spherical.js scenario, but then realised that the algorithm is different too, so it uses the angles, but not the new algorithm, just the standard EQS one.
I combined the Balance and Uniformity fields together (and also changed the value being used for the uniformity), because I was out of space. Added in the sample size to show the actual number of points used. The Ideal column shows the theoretical smallest distance, using your equation. I haven't read up on it, so I don't know if it applies to all situations or just whatever Kogan was working on in that paper. The EQS algorithm beats it, though, so it seems to be limited.
I put the Ideal value right next to the Min and Max values, because that is what we want to compare it against. The last column, Factor, is Min/Ideal. I used the Min at first, but it didn't really work. I tried the Average and the results looked better to me. That is the average of the minimum values, so it represents all minimums rather than just the best minimum.
Here is the table using Average/Ideal:
We want to find an algorithm that has a low Range and Balance, and a Factor close to 1. The EQS algorithm is still looking the best to me. You're right about EQP, it isn't complete, but it does have some different cell angles being used. EQSMods is a new one where I extracted the cell angles from your spherical.js scenario, but then realised that the algorithm is different too, so it uses the angles, but not the new algorithm, just the standard EQS one.
Re: Possible Charged Particle Field
Please compare your ideal values against the two tables I posted, it's not there. As per the paper, I used the normalized value, smallest/theoretical. Give the paper a review, you'll see that a good normalized value is around 0.85.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
This is the ideal value: Math.sqrt( ( 8 * Math.PI ) / ( numPoints * Math.sqrt( 3 ) ) )
I'm using a radius of 1, so it falls out. That is what you are referring to as the theoretical value. The Factor column contains first the smallest/theoretical, then the average smallest/theoretical in the second pic.
I'm using a radius of 1, so it falls out. That is what you are referring to as the theoretical value. The Factor column contains first the smallest/theoretical, then the average smallest/theoretical in the second pic.
Re: Possible Charged Particle Field
.
With respect to precision alternatives, do we want to compare precision alternatives or do we want to provide a range of precision values? I favor the latter. Doing a quick review, I see the following current precision alternatives:
1. Low; 8 cardinal points octahedron;
2. Medium (K46);
3. High (K130);
4. Overdrive (K406);
5. EQP Medium (EQP46);
6. EQP High (EQP130); and
7. EQP Overdrive (EQP406).
In order to improve the range of our precision set consider:
EQP: We have EQP48 vice EQS46, EQP128 vice EQP130, and EQP404 vice EQP406 – none of the three EQP numbers agree with the EQS numbers to do a direct comparison, still, EQP128 may be slightly better than EQS13. More importantly, there doesn’t seem to be any good spherical alternatives between EQP46 and K201. So keep EQP128;
EQS: Keep EQS46, but drop EQS130. Add EQS 238 and/or EQS312. EQS406 has a low performance. The only alternative with a better performance near that number of particles would be my ModEQS374.
Kogan: Keep K46, but drop K130 and K406. Add K201 and K326.
That would make my proposed precision list:
1. Low; 8 cardinal points octahedron;
2. EQS46;
3. EQP128;
4. K201;
5. EQS238;
6. EQS312;
7. K326; and
8. ModEQS376;
.
Agreed. I think the Kogan spiral algorithm is prettier and provides numbers close to the equilatitudinal/longitudinal area solutions of the EQS or EQP algorithms.Not sure if it is better or not, but it looks cool.
With respect to precision alternatives, do we want to compare precision alternatives or do we want to provide a range of precision values? I favor the latter. Doing a quick review, I see the following current precision alternatives:
1. Low; 8 cardinal points octahedron;
2. Medium (K46);
3. High (K130);
4. Overdrive (K406);
5. EQP Medium (EQP46);
6. EQP High (EQP130); and
7. EQP Overdrive (EQP406).
In order to improve the range of our precision set consider:
EQP: We have EQP48 vice EQS46, EQP128 vice EQP130, and EQP404 vice EQP406 – none of the three EQP numbers agree with the EQS numbers to do a direct comparison, still, EQP128 may be slightly better than EQS13. More importantly, there doesn’t seem to be any good spherical alternatives between EQP46 and K201. So keep EQP128;
EQS: Keep EQS46, but drop EQS130. Add EQS 238 and/or EQS312. EQS406 has a low performance. The only alternative with a better performance near that number of particles would be my ModEQS374.
Kogan: Keep K46, but drop K130 and K406. Add K201 and K326.
That would make my proposed precision list:
1. Low; 8 cardinal points octahedron;
2. EQS46;
3. EQP128;
4. K201;
5. EQS238;
6. EQS312;
7. K326; and
8. ModEQS376;
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
The Kogan algorithm can use any number of points. I chose those ones to match the EQS algorithm and get a feel for how they worked at the same size. If we choose to use that algorithm, we can see what number of points works best. I don't want to mixandmatch algorithms, with the exception of the first precision. I just want one that works well across a few precision points. We might find that the Kogan algorithm works well at 200, 400 and 600, or 100, 200, 400, for example.
There are still some issues at the poles. Not quite as bad as EQS and no where near as bad as most algorithms, but it is still there.
There are still some issues at the poles. Not quite as bad as EQS and no where near as bad as most algorithms, but it is still there.
Re: Possible Charged Particle Field
.
You're the boss, I try to be selfmotivating, but at the moment, I need directions.
If you agree, I'll load all the additional stats you've included with the new Statistics button in all the spherical scenarios Output control tab's Output table. That will enable us to collect the same data for every n of every spherical algorithm for direct comparison.
Feel free to direct or task me otherwise.
.
You're the boss, I try to be selfmotivating, but at the moment, I need directions.
If you agree, I'll load all the additional stats you've included with the new Statistics button in all the spherical scenarios Output control tab's Output table. That will enable us to collect the same data for every n of every spherical algorithm for direct comparison.
Feel free to direct or task me otherwise.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
You can add it to those scenarios if you want, but it will be easier to create another button that targets a specific algorithm and generates the stats for a range of sizes. We can't do that with EQS, but we can with Kogan. I'll look into that over the next few days.
Re: Possible Charged Particle Field
.
The Charge Point Statistics button includes 9 items: Algorithm, Size, Ideal, Min, Max, Mean, Range, Balance, and Factor. In order to match the Statistics button output, the spherical scenarios efficiency calculations would need to rename four variables and add four new output variables: Max, Mean, Range, and Balance. So, thanks for clarification, other than changing names, I won’t be adding new values at present.
Still, I made good progress  for me. Working with point sets are fun. Each algorithm had its own set of efficiency calculations. I replaced those instances with function calls to a single instance; function calcStats( num, radius, xPts, yPts, zPts ). I changed most all the verbiage to agree with the Statistics button. Now, if you give the word, I can work on adding or changing all the spherical scenario Output tables in one place. I’ll push the change in a few hours.
Next, each algorithm has two instances of point set creations, for both statistics and particle placement. I suppose I should reduce that to just one functional point creation instance and two function calls (for each algorithm). It adds up.
.
Thanks for calling me off, but a few changes are necessary. Such as conforming my prior efficiency verbiage to agree with the new statistics data.You can add it to those scenarios if you want, but it will be easier to create another button ... .
The Charge Point Statistics button includes 9 items: Algorithm, Size, Ideal, Min, Max, Mean, Range, Balance, and Factor. In order to match the Statistics button output, the spherical scenarios efficiency calculations would need to rename four variables and add four new output variables: Max, Mean, Range, and Balance. So, thanks for clarification, other than changing names, I won’t be adding new values at present.
Still, I made good progress  for me. Working with point sets are fun. Each algorithm had its own set of efficiency calculations. I replaced those instances with function calls to a single instance; function calcStats( num, radius, xPts, yPts, zPts ). I changed most all the verbiage to agree with the Statistics button. Now, if you give the word, I can work on adding or changing all the spherical scenario Output tables in one place. I’ll push the change in a few hours.
Next, each algorithm has two instances of point set creations, for both statistics and particle placement. I suppose I should reduce that to just one functional point creation instance and two function calls (for each algorithm). It adds up.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
Maybe we can plot the Kogan values off of the list you’re generating with the Statistics2 button?
Good progress today, I'll push the changes in a couple of hours. As hoped, I successfully converted the two instances of code creating point sets within each algorithm – for particle placement or distribution calculations – into two function calls, and one instance of function coding. I also corrected a problem with Poly points and calcStats that I pushed yesterday.
All the spherical configuration scenarios are now better organized. For example, it occurs to me I should create a single scenario where I can output any spherical set, just provide the desired: typeAlgorithm, number of surface particles, and configuration radius. Or I can put two or more configurations on the screen at once.
.
Maybe we can plot the Kogan values off of the list you’re generating with the Statistics2 button?
Good progress today, I'll push the changes in a couple of hours. As hoped, I successfully converted the two instances of code creating point sets within each algorithm – for particle placement or distribution calculations – into two function calls, and one instance of function coding. I also corrected a problem with Poly points and calcStats that I pushed yesterday.
All the spherical configuration scenarios are now better organized. For example, it occurs to me I should create a single scenario where I can output any spherical set, just provide the desired: typeAlgorithm, number of surface particles, and configuration radius. Or I can put two or more configurations on the screen at once.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
.
Currently, all the spherical configuration scenario’s surface particles share the same orientation  they are all aligned with the world coordinates. Turn on the Boundary and Particle axes graphics to see that all particle axes: n/s (yaxis, green), e/w (xaxis, red) and f/b (zaxis, blue), are parallel. I want to reorient/rotate all the surface particles such that their n/s axis is pointed to the configuration center – the (0,0,0) position. The particles would then be aligned to the spherical configuration instead of the world. By adding a checkbox, the user can choose to align the particles one way or the other.
Each particle has a different, but not correct, orientation.
Of course, reorienting each particle properly is easier said than done. Adding insult to injury, quaternions are built into three.js, but I haven’t figured out how to make them work for this problem yet. The image above shows EQP46 particles improperly reoriented by this codeline –
var q = new THREE.Quaternion().setFromAxisAngle( new THREE.Vector3( points[i].x, points[i].y, points[i].z ), angle*i ); // angle = 2PIRad/number of particles.
I believe I need to do three cross products between each position and each axis. Then follow that up with three dot products to determine the angles. I’ve suffered this problem long enough to seek help. Here are two recent finds I must share:
Rotation Quaternions, and How to Use Them, by D. Rose  May, 2015. Short and straightforward, this paper includes a three step quaternion rotation process. Step 1: Convert the point to be rotated into a quaternion by assigning the point's coordinates as the quaternion's imaginary components, … . Step 2: Perform the rotation. … . Step 3: Extract the rotated coordinates from p'. ... .
3d Math Primer for Graphics and Game Development, Fletcher Dunn and Ian Parberry – 2nd edition, 2011. A wonderful ‘basics’ math book that I’ve always wanted. All you need  including physics  to create your own particle engine. As I understand it, this is a free ebook, in pdf, or you may choose to purchase a printed copy. Check it out.
.
Currently, all the spherical configuration scenario’s surface particles share the same orientation  they are all aligned with the world coordinates. Turn on the Boundary and Particle axes graphics to see that all particle axes: n/s (yaxis, green), e/w (xaxis, red) and f/b (zaxis, blue), are parallel. I want to reorient/rotate all the surface particles such that their n/s axis is pointed to the configuration center – the (0,0,0) position. The particles would then be aligned to the spherical configuration instead of the world. By adding a checkbox, the user can choose to align the particles one way or the other.
Each particle has a different, but not correct, orientation.
Of course, reorienting each particle properly is easier said than done. Adding insult to injury, quaternions are built into three.js, but I haven’t figured out how to make them work for this problem yet. The image above shows EQP46 particles improperly reoriented by this codeline –
var q = new THREE.Quaternion().setFromAxisAngle( new THREE.Vector3( points[i].x, points[i].y, points[i].z ), angle*i ); // angle = 2PIRad/number of particles.
I believe I need to do three cross products between each position and each axis. Then follow that up with three dot products to determine the angles. I’ve suffered this problem long enough to seek help. Here are two recent finds I must share:
Rotation Quaternions, and How to Use Them, by D. Rose  May, 2015. Short and straightforward, this paper includes a three step quaternion rotation process. Step 1: Convert the point to be rotated into a quaternion by assigning the point's coordinates as the quaternion's imaginary components, … . Step 2: Perform the rotation. … . Step 3: Extract the rotated coordinates from p'. ... .
3d Math Primer for Graphics and Game Development, Fletcher Dunn and Ian Parberry – 2nd edition, 2011. A wonderful ‘basics’ math book that I’ve always wanted. All you need  including physics  to create your own particle engine. As I understand it, this is a free ebook, in pdf, or you may choose to purchase a printed copy. Check it out.
.
LongtimeAirman Admin
 Posts : 1570
Join date : 20140810
Re: Possible Charged Particle Field
To rotate an object to point towards a specific point:
Let:
p1 = center point of object
p2 = point to look towards
Let:
p1 = center point of object
p2 = point to look towards
 Code:
// create a vector to represent the line from p1 to the point on the object that needs to be oriented towards p2
// I think this will be the Y axis for you
var align = new THREE.Vector3( 0, 1, 0 );
// calculate the vector between the location of the object and the target point
// this is where align will end up at the end of this algorithm
var v = new THREE.Vector3().subVectors( p1, p2 );
// calculate the angle between those 2 vectors
var angle = align.angleTo( v );
// calculate axis to rotate around
// this is the vector that is orthogonal to both align and v
var axis = new THREE.Vector3().crossVectors( align, v ).normalize();
// create quaternion to represent the rotation
var quat = new THREE.Quaternion().setFromAxisAngle( axis, angle );
// apply quaternion to object
...
Page 28 of 29 • 1 ... 15 ... 27, 28, 29
Page 28 of 29
Permissions in this forum:
You cannot reply to topics in this forum

