# Possible Charged Particle Field

Page 27 of 29   1 ... 15 ... 26, 27, 28, 29

## Re: Possible Charged Particle Field

.
I’ve forgotten the source of the EQS algorithm. I’ve cited it here somewhere at the site but I’ve been unable to find it. Anyway,

It occurred to me that the particle ring algorithm could serve perfectly well to generate latitude particle positions (as well as longitudinal) better than the EQS latitude particle ring currently does, because it isn't constrained to r=1 surface particles only. I believe our new pRing algorithm can easily replace the EQS algorithm. What a strange coincidence.

And not just precision charge detector locations, maybe the Precision points could be modeled as charge emission points.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

While the EQS algorithm does generate points at r=1, it is not limited to that. The algorithm could easily be changed to use any radius. Actually, I just checked the code and it already does take in a radius to generate the points at.

The EQS algorithm was chosen because it generates points that are very close to being equidistant from each other. This algorithm does not have that property. The charge points require that because they represent the locations that external charge is felt from. We want that to evenly cover the surface of the sphere or we are going to get very strange results.

It is good to see you thinking in this way though. You're seeing how to use things to your advantage. Seeing a bigger picture and how you can use smaller pieces to accomplish what you want to.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
I had no idea the EQS algorithm worked with equi-areas, do you recall the citation? I would think the radius you entered into EQS would apply to all the surface particles. As you yourself mentioned, the new particle ring algorithm could actually include different radii at the same time.

I put this diagram together to help clarify things. The blue lines are the latitude rings that the particles are centered on, except for the pole particles which appear to be centered on an edge of the vertical latitude extent.

I do enjoy working with this stuff.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

.
Ok, here's the source, below. I recall reading the short paper, it's just a few years old, based on distributing equi-area rectangles on the surface of a sphere. Of course, we are distributing spherical particles, or circular areas and not rectangles and so I treat the equi-area claim with much skepticism. It appears that the second source is an application based on the same partitioning ideas as the paper, although the application is ten years older than the paper. The application is chock full of code and was beyond me when I first looked at it. The page claims only two downloads in the last 13 years or so; did you download one of them?  I'll try studying it a bit.

A new method to subdivide a spherical surface into equal-area cells by Zinovy Malkin. https://arxiv.org/ftp/arxiv/papers/1612/1612.03467.pdf
Abstract. A new method is proposed to divide a spherical surface into equal-area cells. The method is based on dividing a sphere into several latitudinal bands of near-constant span with further division of each band into equal-area cells. It is simple in construction and provides more uniform latitude step between latitudinal bands than other methods of isolatitudinal equal-area tessellation of a spherical surface.

https://www.mathworks.com/matlabcentral/fileexchange/13356-eqsp-recursive-zonal-sphere-partitioning-toolbox
EQSP: Recursive Zonal Sphere Partitioning Toolbox. A suite of Matlab functions intended for use in exploring equal area sphere partitioning.

///////////////////////////////////////////////

PS. If we were truly interested in covering the sphere with equi-areas for charge density/distribution purposes - say to provide at least 3 or 4 precision alternatives - I 'know' I can improve the output performance of the EQS algorithm by replacing the current equi-area rectangles with hexagons. For example, look at the EQS equators which present columns of particles - I rationalized it by saying they shared axial charge channels. We can increase the number of particle spheres by offsetting alternate latitude rows, positioning the particle spheres hexagonally, more like alternate bricks in a wall, instead of the current particle columns.

I'll work on a proper example.
.

Last edited by LongtimeAirman on Wed Feb 06, 2019 1:48 pm; edited 2 times in total (Reason for editing : Added PS.)

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

.
The EQS group consists of 46, 130 and 406 spherical equi-iso-latitudinal areas, which you've replaced with  “points”, used for calculating charge received by our charge field particles. I believe the equi-area claim is great for Cartesian maps; however, the equi area claim with respect to points is false. How do I prove it?

EQS Packing r=1 particles , making up an r=10 sphere. How many particles can we fit without overlap?

I’ve made a game of packing r=1 neutral particles onto a r=10 spherical surface without overlap. I submit that the maximal contender using the EQS algorithm is EQS238. I posted an image of it on Monday, on the bottom of the last page of this thread, here it is again above. EQS238 is on the right side, a little too large to see here.

I recreated the EQS238 in autocad, without foreshortening. Note that that EQS238 has six latitude particle rings of 24 particles about the equator. The particles are arranged in longitudinal lines. By offsetting alternate rows, changing from from 15 to 11 degree latitude steps while maintaining a 15 degree spacing between particles in that equatorial band, I was able to add a seventh row of 24 particles directly over the equator to result in the modified EQS262. Having increased the particle count by 24 you might agree that the equi-area particle distribution of 262 is somewhat improved over EQS232.

I admit, its a bit hit or miss. But i definitely want to improve the distribution of our charge detection points. If you like, I'll go through this exercise again with EQS406.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

Airman wrote:As you yourself mentioned, the new particle ring algorithm could actually include different radii at the same time.

I didn't mean it would use different radii at the same time. Currently, it uses the same radius for all points generated in a single call of the function. It could be changed to generate different radii, but that is not what it needs to do for its current use, and I wouldn't change it that way anyway. It is best left as it is and you change the points in another function. One function generates points (or handles direction) while the other moves them in and/or out in whatever way you want (handling distance). That way, you can exchange either algorithm for another without affecting the other one. Keeping your code small and concise and modular allows it to be re-usable. If your code is intimately tied into what you want it to do in this one case, then it is difficult to pull it out for a different need. It takes a while, but you get a feel for these kinds of things.

Here's another paper that is more specific to our need to generate charge points.

https://www.cmu.edu/biolphys/deserno/pdf/sphere_equi.pdf

We'd want the regular placement version. Simple algorithm. Probably a better result than the EQS algorithm when using it for points. If you want to implement it, find the current eqs.js file and create another one in the same directory. Copy this code into it and implement the createLocations function.

Code:
`var EquidistantSphericalPoints = (function( THREE, SPHERE ){   var module = Object.create( {}, {      Version: { value: '0.1', writable: false }   } );      /**    * A ChargePointLocator is used to create a collection of ChargePoints     * that can work together for a sphere    */   module.LocationCreator = function()   {      SPHERE.LocationCreator.call( this );            // TODO add properties that control the algorithm here      // e.g. this.area = 1;   };      module.LocationCreator.prototype = Object.create( SPHERE.LocationCreator.prototype, {      constructor: { value: module.LocationCreator, writable: false }   } );   module.LocationCreator.prototype.createLocations = function( radius, dst )   {      // TODO generate points at radius and push into dst   };      return module;}( THREE, SPHERE ));`

Look at EQS to get a general idea of what you need to do, but the algorithm itself is quite different.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

What I am looking for with this algorithm is uniformity. I'm not too concerned with covering the entire surface with charge points. I just want whatever charge points are in use to be uniformly distributed over that surface. Your EQS262 covers the equatorial region beautifully, but it has problems at the poles. You can clearly see where it changes from equator to pole at about half way up the surface. The standard EQS has problems at the poles too, so does this algorithm, so do all of them.

I wonder if you could alter 262, or something close to that, to just offset every second row. Don't add any more rows in, just offset every even row or something like that. Try to get more of the surface to be in that diamond pattern rather than columns. You might be able to get a bit closer to what we need.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
Affirmative, we want a uniform distribution of surface points. Given my example converting EQS238 to the Modified-EQS262, I thought I might be able to alter or optimize a given EQS set, making the same custom changes I made with autocad, including particle ring rotations of a few degrees. And so I'd work on EQS46, 130, and 406 with that goal in mind.

As far as EQS goes, it seems that as the number of areas is increased, the more accurate the algorithm becomes. I noticed the three polar points, a sure sign that the algorithm isn’t based on a regular polyhedron. Unfortunately, the lower number EQS algorithm solutions seem to place the greatest concentration of points about the poles. Still, I noticed there are pole area rings which would also benefit from particle ring offset rotations. Note that the separation between the three particle and 9 particle ring sets is currently at minimum, and can be increased with a 45deg rotation. Of course, i'll need to find out if I can alter the EQS code or not.

Actually, I had a better solution in mind. I was going geodesic on our charge particle.
Geodesic polyhedron https://en.wikipedia.org/wiki/Geodesic_polyhedron
I have the vertices, edges and edge arcs for the basic icosa and octahedron plotted. I’d started the second frequency subdivisions when I read your link.
https://www.cmu.edu/biolphys/deserno/pdf/sphere_equi.pdf

At first it seemed too simple to believe. A single page, illustrated, including notes, a refresher on spherical coordinates, formulas, algorithms and references. A half dozen or more reads later and despite the fact that there are three points at the poles, I can’t wait to try this new code and test it at r=10 with the rest.

I’m overwhelmed - delighted - at the possibilities. In any case, I'll give it a go.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

Those geodesics do look promising. Worth a try at some point. I like the triangulation approach. I've done that before to generate spheres from dodecahedrons (or maybe icosahedrons) and it does work well. Whether it gives us the required conformity, I don't know, but it looks like it might. It is always interesting to try different algorithms and see their differences.

Airman wrote:Of course, i'll need to find out if I can alter the EQS code or not.

Negative. Don't alter that code, create a new implementation so that we can swap them with ease. A couple of posts above I have written the boilerplate code for a new charge point location generator. Find the existing eqs.js file, create a new JS file in that directory for your new implementation and copy the code above into it. Then change the name on the top line, EquidistantSphericalPoints in the above code, to something that reflects the algorithm. Then just implement the module.LocationCreator.prototype.createLocations function. That function is given the radius to create points at and an array that you add THREE.Vector3 objects to. The rest of the application already knows how to use it and just needs to be told to use a particular implementation.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
Per your directions, thank you very much, I copied eqs.js to a new file sphericalpoints.js, and replaced the contents with your above - var EquidistantSphericalPoints. Is the name difference a problem?

I have 2 or 3 goals. First is to figure out how to create and use the new equidistant points on a sphere algorithm.

Second, I assume I may corrupt the EQS function, or should I could create another duplicate EQS file for "EQS-optimization"?

Third, the geodesic contender may emerge. I had high hopes at first, but they are fading as I realize that a low frequency geodesic solution for uniform distribution of points is unlikely. Yesterday and today I've played with the 1st and 2nd frequency sets for both the icosahedon and octahedrons and saw a huge flaw in my expectations. The reason the EQS algorithm is not a good solution is that it divides a sphere surface into equi-iso-latitudinal areas and Not points; Geodesics is 'probably' not a good solution as it divides spheres into chords, and Not points. I haven’t figured out how best to convert geodesic areas/lines into points or whether the exercise is completely pointless.

Unless directed otherwise, I’ll use a Spherical scenario to call the new appropriate algorithm in order to position N neutral, unmoveable particles and so compare the various alternates.

Again, I appreciate the directions.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

The name difference is mandatory. We need to be able to identify different implementations and that name at the top of the file is how we do it. The name should reflect the algorithm being implemented. You can shorten it, like I have with EQS, as long as it is unique in the project.

To use the new code, you need to include it in the project by adding it to the HTML file. At the top, in the HEAD section, you will find the existing EQS import:

Code:
`<script src="js/engine/eqs.js"></script>`

Copy and paste that directly below the existing one and then change eqs.js to the name of your JS file.

You create an instance and call its createLocations method like this:

Code:
`var radius = 10;var points = [];var locator = new EquidistantSphericalPoints.LocationCreator();locator.createLocations( radius, points );`

The radius may be specified somewhere else and passed in, you wouldn't generally declare it like that and use it straight away (unless you had more uses for the value).

After that code has executed, the points array will contain THREE.Vector3 objects. You can use them in any way you want to. You can change them. Use the Vector3.multiplyScalar function to change the length without changing the direction.

No, you definitely can not change eqs.js (unless fixing a bug in it). It is being used, so if you change it, it will change that too and I don't want that. We can add new implementations all we want, but we can't change what is being used unless it needs to happen.

With respect to the geodesics, don't worry about them talking about areas and triangles. All of these algorithms generate points, but those points are then used to build areas on the surface. Most times you can just use the points as generated, but sometimes, like in EQS, you do need to think about how to convert the area into a single point. When I looked at those geodesics, I was only looking at the points and their distribution on the sphere. Ignore the triangles, except in how they help you to see the distances between points. You may be right, they may turn out useless, but they might find some other use too.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
I was able to get the new Equi-distant Spherical Points algorithm to work in its own scenario initEQPSphereUI. EQP as opposed to the existing EQS. It's a simple matter to choose any number of particles and the spherical configuration's radius. Next I'll transfer the known good "working" EQP to sphericalpoints.js as previously directed.

Here's a direct comparison between the EQS406 and EQP406 algorithms; 406 r=1 particles in a r=20 sphere. The results are very similar, suggesting that it may take some effort to improve the uniformity of our particle engine's charge detection points.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

I would rename sphericalpoints.js to eqp.js and similar with the module name, just use EQP. Then it is a simple matter to swap between EQS and EQP.

It is a bit difficult to see the difference in those images. The particles in the back blur out the ones in the front. What you want to do is change the charge point algorithm to use this, instead of EQS. This is the reason I suggested you create a class for it. Both EQS and now EQP both implement the same interface, so we can use them interchangeably.

In /js/engine/charge-point-engine.js at line 450, you will find the createChargePointLocator function. This is responsible for creating the object that will generate charge point locations. It also hooks in to the menu through the module.ChargePointConfiguration property.

Code:
`module.createChargePointLocator = function(){   var locator = null;   switch( module.ChargePointConfiguration )   {      case module.CHARGE_POINT_LOW:         locator = new Hosohedron.LocationCreator( 4, 2 );         break;      case module.CHARGE_POINT_MEDIUM:         //locator = new Hosohedron.LocationCreator( 8, 4 );         locator = new EQS.LocationCreator( EQS.ANGLES_46 );         break;      case module.CHARGE_POINT_HIGH:         //locator = new Hosohedron.LocationCreator( 16, 8 );         locator = new EQS.LocationCreator( EQS.ANGLES_130 );         break;      case module.CHARGE_POINT_OVERDRIVE:         //locator = new Hosohedron.LocationCreator( 32, 16 );         locator = new EQS.LocationCreator( EQS.ANGLES_406 );         break;      default:         locator = new Hosohedron.LocationCreator( 4, 2 );         //locator = new EQS.LocationCreator( EQS.ANGLES_46 );   }   return locator;};`

You can just change EQS to EQP and the app will use your algorithm to generate charge points. That will be a lot easier to see the differences in pics. If you want to, you can even add EQP as more choices in that switch statement so that you can swap between EQS and EQP without changing the source code. You will need to add them as options to the menu as well, which is in the HTML file at line 461.

Code:
`folder1 = gui.addFolder( 'Precision' );addCPCfg( PIM.CHARGE_POINT_LOW, 'Low', folder1 );addCPCfg( PIM.CHARGE_POINT_MEDIUM, 'Medium', folder1 );addCPCfg( PIM.CHARGE_POINT_HIGH, 'High', folder1 );addCPCfg( PIM.CHARGE_POINT_OVERDRIVE, 'Overdrive', folder1 );`

You don't need to add the constants, like PIM_CHARGE_POINT_LOW. You can just use literal values here and in the switch statement above like this:

Code:
`addCPCfg( 100, 'EQP Overdrive', folder1 );`

and

Code:
`   switch( module.ChargePointConfiguration )   {      case 100:         // TODO create EQP locator         break;   ...`

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

I added a comment to one of you recent commits, did you see that? Did you get an email about it? I wasn't sure what the site was going to do, so let me know.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
I just looked at sourcetree and didn't see your commit comment - nothing too serious I hope. I've never received any e-mail notices from bitbucket.

.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

.
I logged into bitbucket and saw your comment. Copy the initial letter name change. I see I did receive an e-mail from bitbucket eight hours ago. I usually just check my mail first thing every morning; I would have seen the bitbucket message tomorrow.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

Comments will only show on the BitBucket site, not through SourceTree or any other GIT client (that I am aware of).

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
Ok, status update.

EQP closely follows the EQS naming convention. We have eqp.js (like eqs.js) and new module var EQP (like var EQS). The names of the html and module must be different, I thought that the case change between eqs.js and var EQS somehow violated that rule; it's much cleaner now.

I believe I've followed 'all' your directions except: 1. Creating an instance and 2. Adding a "switch".

I assume the instances must be in eqp.js, so I'll add the new EQP alternatives CHARGE_POINT_46, CHARGE_POINT_130 and CHARGE_POINT_406 there. Just between you and me, I'm having a heck of a time trying to understand the LocationCreator.prototype.createLocations function.

PS. Corrected to "must be in eqp.js,". I'm making too many typos; the fidgets, sorry for that.

Heck as in difficult. First location then radius. I see that SPHERE.LocationCreator is the main module, used by both hosohedron.js and eqs.js. Both have instance examples.
.

Last edited by LongtimeAirman on Thu Feb 14, 2019 10:04 pm; edited 1 time in total (Reason for editing : Added PS.)

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

LongtimeAirman wrote:
The names of the html and module must be different, I thought that the case change between eqs.js and var EQS somehow violated that rule; it's much cleaner now.

I not exactly sure what you mean by 'html' there, but I assume you mean the name of the JS file, eqp.js in this case, which is included in the HTML file. That file name and the module name are totally unconnected, from a code perspective. In this case, and generally most cases, they will be related because the filename should reflect what it contains and the module should also reflect what it contains, so they will be fairly close. But there is no requirement that they be related as they are totally different things.

LongtimeAirman wrote:
I believe I've followed 'all' your directions except: 1. Creating an instance and 2. Adding a "switch".

I assume the instances must be in ecp.js., so I'll add the new EQP alternatives CHARGE_POINT_46, CHARGE_POINT_130 and CHARGE_POINT_406 there. Just between you and me, I'm having a heck of a time trying to understand the LocationCreator.prototype.createLocations function.

I don't want you to add a switch, I want you to add a case to the existing switch statement. You can see the other cases in the code snapshot I posted above, and you just need to add another case and break, creating your EQP object between them, just like all of the others. It looks like you will add 3 case statements, one for each size: 46, 130 and 406.

A switch statement works by evaluating an expression into some value. That value is then compared to all of the cases until a match is found. If a match is found, then the code inside that case is executed until a break statement is found (or the end of the switch statement). If it encounters a break statement, then it exits the switch and continues execution after it. Note that it is totally possible to let one case fall into another case by not having a break statement in the first. This is often useful, but if you didn't mean to do that, it can cause some funny bugs.

Suppose we had a value that is a string, let's say 'myString'. If we passed it to this switch statement:

Code:
`var value = 'myString';switch( value ){  case 'not the right case':    console.log( 'not this one' );    break;  case 'not this one either':    console.log( 'nope, wrong again' );    break;  case 'myString':    console.log( 'found it!' );    break;  case 'try again':    console.log( 'nada' );    break;}`

then we would see 'found it!' printed to the console and none of the other messages would be.

What would happen if the value did not match any of the cases? In the above switch, it would do nothing. If it doesn't match, then it doesn't have anything to execute, so it will just continue processing the code after the switch. However, you can add a default case that will get executed if no specific match is found:

Code:
`var value = 'won't match anything';switch( value ){  case 'not the right case':    console.log( 'not this one' );    break;  case 'not this one either':    console.log( 'nope, wrong again' );    break;  case 'myString':    console.log( 'found it!' );    break;  case 'try again':    console.log( 'nada' );    break;  default:    console.log( 'did not find any matching case' );}`

You can add a break after the default code, but you don't have to if it is the last case in the switch.

What if we had 2 cases that actually contain the same code? Then we omit the break statement from one and let it fall into the next:

Code:
`var value = 'won't match anything';switch( value ){  case 'not the right case':    console.log( 'not this one' );    break;  case 'not this one either':    console.log( 'nope, wrong again' );    break;  case 'myString':  case 'myOtherString':    console.log( 'found it!' );    break;  case 'try again':    console.log( 'nada' );    break;  default:    console.log( 'did not find any matching case' );}`

So if value is either 'myString' or 'myOtherString', it will show 'found it!' in the console. It is also possible to execute some code for 'myString' and still let it fall into 'myOtherString', if you have a need to do something extra for one and not the other.

Code:
`var value = 'won't match anything';switch( value ){  case 'not the right case':    console.log( 'not this one' );    break;  case 'not this one either':    console.log( 'nope, wrong again' );    break;  case 'myString':    console.log( 'it is myString' );  case 'myOtherString':    console.log( 'found it!' );    break;  case 'try again':    console.log( 'nada' );    break;  default:    console.log( 'did not find any matching case' );}`

So in this version, if value='myString', then it will print 'it is myString' and 'found it!' to the console, but only 'found it!' if value='myOtherString'.

The createLocations method just needs to create THREE.Vector3 objects and add them to the dst parameter, which is an array.

Code:
`module.LocationCreator.prototype.createLocations = function( radius, dst ){  for( var i=0; i<10; i++ )  {    dst.push( new THREE.Vector3( i, i, i ) );  }};`

That is a trivial example, but it shows the intent of the method. I'll break it down to show what each part is doing.

module is the module object that will become EQP in your case, but it hasn't been set to the EQP variable yet, so we refer to it as module (which is a local variable, where-as EQP is global).

LocationCreator is a class, which is actually defined above this method declaration, but it looks like any other function. It is actually just a function, but when we call it with the new keyword in front of it, it is treated as a class constructor. Which basically means that a new object is created and passed in to the function as this.

prototype is a special object that allows classes to be created and executed. JS doesn't really have classes, like other languages, it has prototypes that provide similar functionality. The prototype object is the same for all instances (objects) of the class, therefore it can be used to share data. In this case, we are using it to share functions. This means that there is only 1 instance of each function, but it is shared by all instances of the class. When you invoke the function (actually called a method now), the specific instance of the class is set as this which allows you to refer to it inside of the function.

createLocations is the name of the function/method that we are creating and it will be stored in the prototype object of the LocationCreator class which is, in turn, stored in the module object.

The function takes in 2 parameters: radius and dst. The radius parameter will be a number and is used to set the size of the sphere that is being created. You will need to make sure that the length of each THREE.Vector3 object is equal to radius. The dst parameter is used to store the points themselves so that they can be used by the calling code.

Everything else is specific to your implementation. You just need to copy the code from your scenario and make it work with the radius and dst parameters.

Now, it seems like you have some variations, since you are based off of EQS which has 3 different sets of angles to generate points from. Have a look at EQS to see how this is handled in that class. Basically, I pass the angles in to the constructor, which stores them as a member variable (this.whatever) so that they can be used in the createLocations function.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
No Joy. Everything works, except EQP.

Thanks for the switch and LocationCreator.prototype.createLocations function explanations.

I believe I've added the three new EQP cases to the createChargePointLocator function() switch properly. When I select an EQP setting on the control panel Precision settings, the output is always the default (Hosohedron.LocationCreator( 4, 2 )).

Over the past two days I tried two things. The first was modifying module var EQP to closely agree with var EQS. Substituting ‘numPoints’ for ‘angles’ and treating the radius variable exactly the same. Creating the value of ‘points’ from the call titles. The objects are a bit different, 'angles' is an array, while the value of numPoints is either 46, 130, or 406. I believe I set the radius to 1 properly, ... .

Next, I commented out most of my first effort, then modified EQP to closely agree with var Hosohedron. That made much more sense. Where Hosohedron receives ( divWidth, divHeight ) from the charge-point-engine precision switch, now EQP.LocationCreator receives the pair of numbers ( radius, points ). While the hoso example is easy to follow; still, no joy seeing an EQP graphic Precision setting yet. I'm afraid that radius may the problem.

I posted all my changes and have run out of guesses. I'll keep looking, but must ask, please give it the once over, find the error and win the prize of your choice.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

Ok, got that working.

There were a few problems. Firstly, the constants used in the switch statement were not defined, so it couldn't match on your case statements and would fall through to the default. That had to happen in the cdm.js file as the module object in charge-point-engine.js is actually the cdm.js module since charge-point-engine is not a module itself, but a module extension (tricky, I know).

Secondly, the EQP class itself had some issues. It was taking the radius in to the constructor, but it shouldn't because the createLocations function of that class already has it passed in as a parameter. That wouldn't stop it from working though, it would just make it ignore the given radius (which it shouldn't do).

The main problem in EQP is that you changed the parameter list for the createLocations function, but then ignored them. You can't change the function declaration on this type of function because it is implementing an interface. An interface is a class that does not provide functionality, but it does provide the functions that will be available in a class that does. It defines the contract for the class. The way it is used. Therefore, we can swap different implementations without changing the code that uses them.

Have a look at the changes in SourceTree and try to see how they fixed it.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
It sure is nice to see it working. I've reviewed each of your corrections and am well able to appreciate them. Especially the fact that the LocationCreator parameter list, ( radius and dst ) is fixed by the class. Where exactly in the charge-point-engine is radius given a value of 1? Module.radius? Whatever that is?

I'll clean up var ECP and the other files of my extraneous commented out code.

Any ideas on how we might compare the performance of EQS versus EQP? Once we have a plan or set of performance measures (optimistic, aren't I), given our previous discussion, I believe I'll need to go through this effort again, making another duplicate of var EQS, call it for var EQS2, for optimizing specific EQS solutions.

Don't forget to claim your prize.
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

LongtimeAirman wrote:Where exactly in the charge-point-engine is radius given a value of 1? Module.radius? Whatever that is?

In charge-point-engine.js at line 490, it calls the createLocations method with a value for radius of module.RADIUS. That is a constant defined in the current module, so the obvious question is, what is the current module. The charge-point-engine.js file is different because it does not define its own module, but receives one as a parameter and extends it by adding more classes and functions to it. If you look at the top of charge-point-engine.js, after the comment, you will see this:

Code:
`(function( module, THREE, SPHERE, EQS, EQP, Hosohedron )`

You can see that module is being passed in as a parameter along with other modules like THREE and our own EQS and EQP modules. So we need to look at what is calling this function, which is actually at the very bottom of the file:

Code:
`}( PIM, THREE, SPHERE, EQS, EQP, Hosohedron ));`

The first parameter is PIM, so the module is defined in cdm.js.

LongtimeAirman wrote:Any ideas on how we might compare the performance of EQS versus EQP? Once we have a plan or set of performance measures (optimistic, aren't I), given our previous discussion, I believe I'll need to go through this effort again, making another duplicate of var EQS, call it for var EQS2, for optimizing specific EQS solutions.

I think the best, and easiest, way to compare them is with our eyes. Take pics of both EQS and EQP with the equivalent number of points and from the same camera position. Right now there is no performance difference because EQP is just an offset version of EQS. I think the initial idea was to have every 2nd row be offset, so that it would form a diamond pattern rather than a square like EQS. When that is done, we need to think about how to use the idea of offset rows but incorporate it into the EQS algorithm. Can we create rows between the defined ones and we make them offset, for example. I would actually prefer that we keep the existing EQS rows and leave them alone, but add in more rows to fill in the gaps.

LongtimeAirman wrote:
Don't forget to claim your prize.

Peace and Prosperity for All

or the big teddy bear, which ever is easiest to get off the shelf.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia

## Re: Possible Charged Particle Field

.
I think the best, and easiest, way to compare them is with our eyes. Take pics of both EQS and EQP with the equivalent number of points and from the same camera position.
I agree, that suits me. But I don't believe we're ready to compare EQS and EQP yet.
Right now there is no performance difference because EQP is just an offset version of EQS.
I disagree or don’t understand. EQP is an alternative algorithm, not just an offset version of EQS.
I think the initial idea was to have every 2nd row be offset, so that it would form a diamond pattern rather than a square like EQS. When that is done, we need to think about how to use the idea of offset rows but incorporate it into the EQS algorithm. Can we create rows between the defined ones and we make them offset, for example. I would actually prefer that we keep the existing EQS rows and leave them alone, but add in more rows to fill in the gaps.
Here's my summary and plan.

Our goal is to place N charge sampling points on a sphere of radius 1 as uniformly as possible.

There are currently 4 values for N: 6, 46, 130, 406. The 6 value corresponds to the cardinal directions - up/down, left/right, in/out. The rest were originally Hosohedron solutions ( 4,2; 8,4; 16,8; 32,16 ). The Hosohedron algorithm partitions the sphere’s surface into latitudinal bands similar to the fact that charge emission is a function of the particle’s latitude. It became clear that the hosohedrons were wrong. The point distribution isn’t uniform, it is highest near the poles. This fact was made apparent by our scenarios.

Aside from ( 4,2 ) the other three Hosohedron solutions were replaced with equi-latitude area EQS algorithm solutions. I‘ve shown that I can improve EQS solutions with offsetting alternate latitude rows.

My next step is to identify a methodology to improve the EQS particle distribution uniformity. For example, beginning with EQS46, using a spherical scenario, I’ll find an approximate smallest spherical configuration radius that 46 r=1 particles can fit without any particle contact. Then I’ll try my alternate row offset adjustments to see if I can fit in any additional particles without any resulting particle contact. I'll attempt the same with EQS high and overdrive. We can decide how best to make those modifications after I use autocad to identify them.

Next, we'd compare the optimized EQS solutions to EQP. Like you, I believe EQP provides a more uniform set of points than EQS does, but we haven’t really determined that yet, including what is the smallest radius spherical configurations with the same total number of r=1 particles.

I'm keeping the same (or approximate ) N values - they might be changed slightly to maximize any advantage offered by the EQS or EQP solutions.

S'alright?
.

LongtimeAirman

Posts : 1461
Join date : 2014-08-10

## Re: Possible Charged Particle Field

I switched between EQS and EQP and it just looks like EQP is slightly rotated around the equator compared to EQS. I might be wrong and am happy to see any evidence of it.

Nevyn

Posts : 1796
Join date : 2014-09-11
Location : Australia