Miles Mathis' Charge Field
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Possible Charged Particle Field

4 posters

Page 13 of 15 Previous  1 ... 8 ... 12, 13, 14, 15  Next

Go down

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

Post by Nevyn Fri Jan 18, 2019 11:17 pm

Got text working. Mostly like what I wrote above, but slightly different. There were some complications but I got around them in the end. The worst was the fact that the fonts have to be loaded, and that happens concurrently with the page itself being loaded. Therefore, you can't know that a font will actually be available when you try to use it. I postponed the initialization function calls until the fonts are loaded, so we can use them in the scenario initializers. This does create a delay before the page shows to the user.

You use the factory object to create a 3D text object. It works just like a Particle, but we have a few more methods we can use and we also lost a few methods that apply to particles but not text.

Code:

var text = factory.createText( 'Some text' ).get();
scene.add( text );

The default font is Helvetiker. You can also use Optimer and Gentilis. All of them come in plain and bold. To set these properties, we use ParticleFactory.font method:

Code:

factory.font( 'optimer', 'bold' );
var text = factory.createText( 'Some text' ).get();
scene.add( text );

You can also use some constants: PIM.HELVETIKER, PIM.OPTIMER and PIM.GENTILIS. Similarly, for the style, we have: PIM.PLAIN and PIM.BOLD.

The generated text will be 10 units in size. You can change any of the parameters used to generate the text geometry, but the size has its own method that you use like this:

Code:

factory.fontSize( 25 );
var text = factory.createText( 'Some text' ).get();
scene.add( text );

Other properties, and even size, can be set using the fontProp method:

Code:

factory.fontProp( 'size', 25 );
var text = factory.createText( 'Some text' ).get();
scene.add( text );

For more information on what properties you can use, see the THREE.TextGeometry class. Remember we are using r88, so look at the documentation for that version.

The default color is white, but you can change it by changing the THREE.Material used. This is done by calling the ParticleFactory.newTextMaterial method. This method takes an object parameter that will be given to the Material created. Generally, you will only want to set the color, which can be done like this:

Code:

factory.newTextMaterial( { color: 0xff0000 } );
var text = factory.createText( 'Some red text' ).get();
scene.add( text );

There is a default material and all text created will use the same material object until you call newTextMaterial. Then all subsequent text will use that material. This means that they will all change if that material object is changed. This can be used to your advantage but it can also cause problems.

Like particles, we can set the position and rotation using the place and orient methods:

Code:

var text = factory.createText( 'Some text' ).place( 0, 10, 0 ).orient( 0, 1, 0, Math.PI/2 ).get();
scene.add( text );

However, we can't use the velocity or spin methods because text is static.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sat Jan 19, 2019 5:14 pm

.
Possible Charged Particle Field  - Page 14 Curren11
Fonts in space. Current output.

Thanks for the addition, I hope it works. The output letter dimensions are aprox 10x10x4, much larger than the r=1 neutron surrounded with edge lengths (5,6,7,8,9 - I believe). One needs to change the view direction slightly to order to see the very large letters from this close - about 150. How do I limit the x and y values to four decimal places?

But that's not my main complaint. Before entering any numbers, just clicking the parameters tab, it might take a minute before seeing the tab change. Entering numbers must be slow and careful, expect long delays. Pretty ugly first impression. I wasn't able to play with scaling the diagram size to match the font size because my browser slowed to near zero. I bombed Firefox Developer a couple of times, needing the Task Manager to stop Firefox. Did I do something wrong?

Here's all the changes I made, so you could see what I did, but I did NOT push it to Bitbucket.


// The verticies - previous
/*
for ( i = 0; i < numEdges; ++i)
{
    var j = i + 1;
    if ( j === numEdges ) { j = 0 };
    console.log( 'P'+ j + ': x = ' + xCoords[i] + ', y = ' + yCoords[i]);
};
*/

// The verticies - current
for ( i = 0; i < numEdges; ++i)
{
    var j = i + 1;
    if ( j === numEdges ) { j = 0 };
    var text = factory.createText( 'P'+ j + ' : x = ' + xCoords[i] + ', y = ' + yCoords[i] )
    .place( 20, -20*j, 0 )
    .get();
    scene.add( text );
};

P.S. Must clarify, I actually used 'var text = ... , and not 'text = ... , . No change in molasses.


Last edited by LongtimeAirman on Sat Jan 19, 2019 6:11 pm; edited 1 time in total (Reason for editing : Added P.S.)

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sat Jan 19, 2019 6:25 pm

You can limit the number of decimal places by using the Number.toFixed method. You must have a number object, which if you are using THREE.Vector3 then you do, otherwise use myVar = Number( myVar ); to make sure that it is. Then you just call toFixed like this:

Code:

var text = myVar.toFixed( 4 );

where 4 is the number of decimal places that you want. The text value will be a string, not a number (I think).

It seems the text generates along the Z axis, and we are looking down the Z axis by default. Give the text a rotation to fix that:

Code:

var text = factory.createText( 'My Text' ).orient( 0, 1, 0, Math.PI/2 ).get();

Text is quite complex geometry, so if you have too much of it, it will slow things down. It doesn't seem like that is what you are experiencing though. I'm not sure why it would slow down before you even start the scenario. I don't experience that in my dev environment.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sun Jan 20, 2019 12:21 pm

.
Possible Charged Particle Field  - Page 14 Cyclic12
This time I'm using Chrome, the scenario is still slow but it's much faster than Firefox. The console output messages are shown. I Pushed the changes to Bitbucket. I still need to shorten the numbers, etc.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sun Jan 20, 2019 7:56 pm

That's a weird violation warning to get since we haven't changed that file, and it isn't even ours. It may be that Chrome has been updated to now show that warning, but you are also seeing performance issues, so it seems that something has changed. Did you use a copy of OrbitControls.js from a different ThreeJS version?
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sun Jan 20, 2019 9:28 pm

.
Negative. By the way, even though it's slow Firefox doesn't show any console warnings. I see the problem with either my testing folder's public_html test.html or my separate GIT files. I would have no idea how to replace OrbitControls.js without the Git application seeing the change.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sun Jan 20, 2019 10:49 pm

When I added support for text, I had to change the initialization mechanism so that it would not initialize until the fonts had loaded (which happens on a separate thread). To do that, I added this code:

Code:

(function() {
 var doInit = function() {
 init();
 initGUI();
 animate();
 };
 var wait = function() {
 if( PIM.isLoaded() )
 {
 doInit();
 }
 else
 {
 setTimeout( wait, 50 );
 }
 };
 window.onload = wait;
}());

Which creates 2 temporary functions, doInit and wait. It then sets wait as the window onLoad event handler, so that it gets executed when the web page has loaded (all scripts parsed and the HTML is built into elements). When that happens, it will check to see if the fonts have loaded by calling PIM.isLoaded(). If that returns false, then it just call wait again after 50ms have transpired. If PIM.isLoaded returns true, then it calls doInit which will initialize the system like it did before, but we know the fonts are available.

Maybe that is causing some issues. However, I develop in Chrome and test in Firefox once I upload to my site (which I don't often do for this project). I have not seen those warnings, but will have a closer look when I can. Maybe I missed them, but I doubt it because the console is always there to see.

Even if that is not causing issues, it will cause slowdown during the initialization process, because it is waiting for those fonts.

The fonts were another issue. Browsers don't let you just pull in code from anywhere. They limit you to the same domain that the page was loaded from or you get a Cross-site Scripting error. The fonts would not load unless you served the page from a web server. If you just double-clicked the HTML file to open it, they would not load. So I uploaded them to my site and linked directly to that. Therefore, it has to download them from my site when you load the page, which is a lot slower than if they were local files. This would create a Cross-site Scripting error, but I made a change to my web server to mark these resources as Cross-site allowed, so the browser is happy to load them.

None of that would cause the violation message, but it will be causing some slow down during init.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Tue Jan 22, 2019 7:57 pm

.
My previous posts included images of fonts in space displaying impossible to distinguish characters.  
Nevyn wrote. It seems the text generates along the Z axis, and we are looking down the Z axis by default. Give the text a rotation to fix that:
Yes, we need to look perpendicularly at the text output. When text is viewed obliquely the letters/numbers become indistinguishable.

I tried as you suggested, and added an orientation angle to go with the off-center text, but there’s no ideal angle. There’s always both x and y distortions. Ideally, the text should be placed on the inside surface of a sphere centered on the viewer at 0,0,0.

I did a side by side comparison of the plain and bold, optimer, helvetiker and gentilis, 3d fonts. Gentilis has the narrowest characters, and is easiest to read. It’s clear the oblique problem is due to the fact that the font letters have a perpendicular thickness of about half their height. Does that 3d font source have flatter 3d fonts?

Possible Charged Particle Field  - Page 14 Cycpol10
Cyclic polygon output. The text is 200 units behind the circle and polygon, at the best viewing angle. 
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Tue Jan 22, 2019 9:15 pm

I did warn you that this isn't the right way to show that sort of info.

You can reduce the depth of the text, which may help a bit, add this before you create the text:

Code:

factory.fontProp( 'bevelEnabled', false );

That stops the edges of the text from being smoothed, which also reduces the depth because beveling adds a bit to accommodate the rounding of the edges.

But you will never get away from the 3D nature of it.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Wed Jan 23, 2019 12:30 pm

.
Possible Charged Particle Field  - Page 14 Cycpol11
The problem: for a given set of edge lengths, provide the user with a cyclic polygon radius and output coordinates. You’ve explained that the console is not intended for normal users. The only other option I’m aware of is 3d space fonts, which you’ve provided, thank you very much. I’ve got the cleanest font selected (gentilis plain), and you’ve identified the way to turn the font beveling off - the font thickness went from 4 to two. The above shows the comparison. The top left image has font beveling, when viewed at even a slight off center angle, the font’s characters soon became indistinguishable. The bottom image shows the oblique viewing problem is gone, the scenario even seems to run a bit faster without beveling. Yes, 3d fonts are a pain, but I consider the improved output above as perfectly acceptable.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Wed Jan 23, 2019 6:33 pm

I don't see what it is you're trying to do, or at least, it doesn't fit in this app. What I see is intermediate information needed by a developer as they solve a larger problem. I don't see what the user gets out of it or why they would come to a particle simulator to see cyclic polygon coordinates. Don't get me wrong, it is indeed an interesting problem, but the app needs to focus on what the user wants, not what we want. If you are solving this problem in order to place particles around something, then that is what it should do. Not show the edges and circles. That is why I see it as intermediate information. It is what you need to know in order to know that the algorithm is working, but once you do, you need to move on to the next stage and do something with it. It is easy to lose sight of the end goal when you hit an interesting problem.

I certainly don't want to tread on your enthusiasm or down play your accomplishments. It is great that you have solved this complicated problem, but you soon learn that in software development, most of the great things you do go unnoticed by the users. We all want to show off what we have done when we are proud of it, but only a select few will understand. Users are only impressed by what you do for them. Make their life easier or show them something interesting and they will love it. How you did it, or what problems you solved to do it, they really don't care about. And that is not the users fault, or the developers, it just is what it is. Most users just don't understand what goes into the apps they use, and really, they shouldn't. The developers job is to make the complicated easier. We take the stress away by dealing with it ourselves so that the user doesn't have to.

So, in essence, I am trying to say that we need to think about what the app is, what it does and what the user gets out of it. That is the lesson I have learnt over the last few years working with you guys. I realised that I was building apps that allowed me to play with ideas and try things out, but they weren't very good for the user. Great for me, but not very good for anyone else. So I have been trying to focus more on the user experience and less on what I want to play with. I still get to do that as I develop the apps, but sometimes I have to let things go or let them fade into the background because they either don't work in the app or they are not the focus of the app. But you know what? The users love it. They don't want a million options they don't understand, they want clean and concise. They want the app to show them something that they find interesting without the need to mess with heaps of controls.

I am certainly not saying that this scenario is not useful. I think it just needs to focus on placing particles rather than where they are being placed. Maybe re-word it as particle placement where you specify the straight-line distances between particles arranged in a circle. You could even have a similar scenario that lets the user specify the angles rather than the edge lengths. The end goal is setting up a scenario for the user to watch. The particle interactions are the main focus of the app, so the scenarios should reflect that.

It may not sound like it, but I am impressed with what you have done. In fact, I am going to look over it and see if I can fit it into MBL for the rings. I looked into it at the time, but didn't want to get side-tracked on the placement issue when I was making progress on larger problems. Now I can go back with a working example and it will be much easier.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Thu Jan 24, 2019 12:22 am

.
Nevyn wrote. I don't see what it is you're trying to do, or at least, it doesn't fit in this app.
Airman. Agreed. There is absolutely no purpose to a cyclic polygon finder when all particles are the same size. Further, I’ll agree to most all your following comments. As far as confusion goes, I submit your post from earlier in this thread, https://milesmathis.forumotion.com/t476p575-possible-charged-particle-field#4797 by Nevyn Fri Dec 14, 2018 5:06 pm

Airman wrote: What's the practical limit - the maximum number of neutral particles in a spherical array - without overlap - at a given radius?
Nevyn wrote: You actually sent me the link to the answer to that in the MBL thread: https://milesmathis.forumotion.com/t464p25-molecular-bonding-language#3694.

Use the diameter of the neutron/proton as the edge length. If you want a bit of space between the particles, add it to that diameter.

If you get stuck, I'll go through the MBL code and see how to adapt it to this problem.
Airman. The next day, I replied. by LongtimeAirman Saturday, 15 December 2018 at 6:34 pm

MBL is Great Guns Nevyn. The cyclic polygon algorithm is necessary to cope with varying ring molecule component lengths. For example, say there’s a ring created by 2,3,4, and 5 alpha long sets of stacks – the cyclic polygon algorithm allows one to calculate the various stack positions on the ring(within a given tolerance).

In CPIM, protons and neutrons have the same diameter. The cyclic polygon problem reduces to simply dividing the circumference (at the desired radius) by an integer number of angular particle widths ( n plus gap) in the ring - the N-gon. So I can imagine producing an N-gon ring (a spherical array will come later) according to the radius and minimum particle gaps selected by the user. With that understanding, I suppose I can start with the cyclic polygon algorithm. Is that close to what you thought I was thinking? Any chance of providing larger random sized (say 1<=r<=5) particles?
Airman. I admit, my last words are definitely confusing. Even with particles of varying radii, spheres aren't edge lengths, the cyclic polygon wouldn't work. But by referring back to the cyclic polygon algorithm from the MBL thread, https://milesmathis.forumotion.com/t464p25-molecular-bonding-language#3694, that I had found for you specifically for use in the MBL, I gathered that you hadn't gotten it to work, and you didn’t want to say as much; well then, I had to try too.

Nevyn wrote: It may not sound like it, but I am impressed with what you have done. In fact, I am going to look over it and see if I can fit it into MBL for the rings. I looked into it at the time, but didn't want to get side-tracked on the placement issue when I was making progress on larger problems. Now I can go back with a working example and it will be much easier.
Airman. I like to think I got lucky getting the algorithm to work because of your help, read back over the thread for proof of that. Cyclic polygon was always intended for MBL and I’m glad to hear you’ll get around to using it as the practical tool it was intended to be. At minimum, consider removing the cyclic polygon from CPIM, and, if you’d be so kind, it may fit among your calculators. I’ll even clean it up to meet your calculator spec, if I may, as you wish.  
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Thu Jan 24, 2019 6:42 pm

I don't think the particle size makes the algorithm useless. It isn't the size of the particles that are being used but the distances between them. Differing particle sizes would make it more complicated, but only slightly. That would be different in MBL, where the size of the atoms is what we are using to find the positions and angles.

I might have helped a bit with programming constructs, but I don't remember discussing the actual algorithm itself. That is all on you. You did that. You implemented a complex mathematical problem and put it into the app. That's a great achievement, even if it doesn't stay in this particular app. Although I see no reason to get rid of it just yet, maybe not at all. That is a decision for the last stages of development, just before we go live.

I have no problem saying that this algorithm scared me away when I looked at it. I knew that I could solve it if I put the effort in, but didn't really want to at the time. I thought it would take too much time to do, so left it for another day. I really am impressed that you got this working, and you should be too.

I hadn't thought about adding a calculator for cyclic polygon placement. I'm not sure if it fits in there, because it will need to show something, not just give back the results and those results are a series, rather than a single value. Maybe it is a new breed of calculator, requiring a new page style. There are probably a few other algorithms that we have used in this app that could be made into a calculator too. The hosahedron algorithm and all of the others that I tried to use on the charge point locations.

The reason it won't fit into the current calculators is that the pages for the calculators are generated. All calculators are specified in a database and then used to fill in the page dynamically, when you request the page from the server. Therefore, all calculators must be the same. Not in the equation they are using, but in the way they are specified and the way the page will use that data to generate the HTML and JS. So this type of algorithm needs a new way to define it and a generator to create the pages.

It is something to think about. I might forget about it before I can get to it though, so feel free to remind me later if we haven't mentioned it in a while. I'm occupied with creating a Periodic Table of AML at the moment, which will be the start of the second level of apps built on top of my language series. Those languages make things so much easier. I want to capitalize on that and see where it goes. I've had the idea of a periodic table app since the early days of AV, and it feels so close now.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Fri Jan 25, 2019 7:44 pm

.
Thanks for the praise; and thanks for the opportunities.

Ok, distances and edge lengths being equal, the cyclic polygon scenario stands. Earlier today I added angles to the output table. I imagine I’ll complete this scenario as you’ve suggested, by placing particles at the user requested cyc-poly points as the initial particle distribution in order to observe the particles’ charge/gravity interactions. Distances must be greater than two. The lines and circle will be removed. I understand the current calculator format limitations; until there’s an actual cyc-poly calculator - I think it’s fair to allow the user to have the non-default option of displaying the table output at some discrete location (say behind the initial view). Of course, if you think that’s crass, I’ll wait for the calculator version before including a table output.
 
The Periodic Table of AML sounds fine. Perhaps some elemental structure will become apparent in the forms of the AML codes themselves.  
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sat Jan 26, 2019 6:37 pm

Would you be happy with a modal dialog that pops up to show the information you want after the scenario has initialized, but before rendering starts? Then the user can click it away and it is not part of the scene. I might even be able to get it to show it in the dialog that the scenario controls are on. I could allow you to attach a function to a button and that function can make the calculations and show them in the current dialog.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sat Jan 26, 2019 10:15 pm

.
Possible Charged Particle Field  - Page 14 Pringc10
Thanks for the option, but I don’t think its necessary – reserving the right to reconsider the offer later. I think I’ve initially completed the new scenario, Particle Ring – Cyclic Polygon. I stand corrected, this scenario works much better than I expected. Not just cyclic polygons, any series of numbers translates to unique particle ring positions, inside or out of the emission field of an optional central proton. The example shown, 6 neutrons in hex formation about the central proton results from entering 6 tens as shown. As you may notice, the table output (complete with circle, lines and central neutron) is a non default user selected option, located well behind the viewer and interacting particles.

This scenario gives the user a lot of flexibility, especially good for viewing a wide variety of mainly 2D action, so I’ll place it at the top of the Spherical scenarios. I’ll Push it either later today or tomorrow before I change anything else.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by LongtimeAirman Mon Jan 28, 2019 8:00 pm

.
Possible Charged Particle Field  - Page 14 Bofsix10
The same hex group as my previous post, this time from ‘behind’ (about z=-30) the particle ring (z=0) to the initial observation point (z=60). The requested output text is located discreetly ‘behind’ the initial viewpoint (z=300) with central neutron (z=305). When I said crass, I meant crass.

Would you be happy with a modal dialog that pops up to show the information you want after the scenario has initialized, but before rendering starts? Then the user can click it away and it is not part of the scene. I might even be able to get it to show it in the dialog that the scenario controls are on. I could allow you to attach a function to a button and that function can make the calculations and show them in the current dialog.

When I last posted, I was anxious to share the ‘new’ Particle Ring – Cyclic Polygon scenario – joy joy joy - so I didn’t try understanding, let alone replying to your offer. It occurred to me that the discreet output table may be an acceptable standard.

Does the output table violate charged particle space to the point of objection? How does the modal dialog compare? To be perfectly honest, I’d be happy to try both for an honest comparison but don’t want you to waste your time. On the other hand, if the modal box works, we could ditch the existing 3d text. I'd say it was your decision.

I'm still amazed that various number sequences result in such various outcomes.  
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Mon Jan 28, 2019 10:49 pm

I think 3D text is not meant for this purpose. It is meant for 'in-world' viewing. That is, it is part of the scene that the user is interacting with. It is meant to represent actual text in the world, such as a McDonalds sign. Using it to show this kind of information just brings more problems than it solves. It is difficult to see as soon as you move the camera. Just look at the image in your last post, all of that text is unreadable. Well, you actually can read it, but it is not easy to read.

I would prefer that this kind of information, if shown at all, is shown in the scenario settings dialog. A button executes a developer supplied function that will do whatever it needs to and then updates a control in the dialog. The developer must not require that function to be executed. It is just for the user to see, not for the code to use to retrieve data to set up the scenario. That is, the button and its function are optional, so you can't rely on it being executed.

The developer will be able to create the button, supplying the function to be executed by it, like any other control.

Code:

ui.control().button( showCoordsFunction, 'text on button' ).message( 'text before button' ).add();

You also setup a control to show the results.

Code:

ui.control().id( 'coordinates' ).textarea().message( 'Generated Coordinates' ).add();

Then you just need to implement the showCoordsFunction wherever is convenient.

Code:

var showCoordsFunction = function()
{
  var results = $( '#coordinates' ); // use JQuery to find the coordinates textarea
  // also get the controls that have the data to be processed
  // then use it to populate the results textarea
}

We can get into more detail after I develop the base framework. It should work something like that though.

The results control is going to be a bit of a problem. There are so many options that one might want to use. I am leaning towards just providing a text area, which you can then populate with text as you want. This is simple, but not very pretty for some things. In your case, it really needs some sort of table, but tables in HTML are not a control like a text area or drop-down box, etc. I'll see if I can come up with anything that might work.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by Nevyn Thu Jan 31, 2019 3:53 am

I have added support for textareas and buttons, allowing many new things to be accomplished. A textarea is a multi row box for large amounts of text. I am typing this post into one at the moment. You can specify how many rows and/or columns the textarea will have by using some UI functions. In the current usage, a dialog box, the column value is ignored. Rows do work though.

Code:

ui.control().id( 'textarea' ).message( 'A text area' ).textarea().rows( 2 ).columns( 10 ).value( 'Some text...' ).add()

You can also pass the rows and columns into the textarea function:

Code:

ui.control().id( 'textarea' ).message( 'A text area' ).textarea( 2, 10 ).value( 'Some text...' ).add()

You can omit either or both values for rows and columns, any missing value will be determined at run-time according to the available space for the component. There are 2 other variants of the columns function that do the exact same thing, but are made available for their brevity. You can replace columns with cols or colms. I used both variants because cols is the HTML way of specifying it, but I am used to using colms when I use it in code. This way, I can get it wrong and it still works.

The text will be available in the success function, just like any other control.

Code:

var success = function( values ) {
  var text = values.textarea;
}

Buttons are an interesting little addition that actually provides quite a bit of power to this framework. I did not intend it to reach this sort of functionality but we have found ourselves here anyway. My intentions be damned. They have some limitations as far as presentation goes, at the moment, but being able to attach functions that the user can execute allows you to change the other controls. For example, a defaults button could be created that returns all controls to their original values, or various preset values could be applied. If we want more functionality out of these buttons, I will look into a way to group them together into a toolbar.

Here's how you create a button:

Code:

ui.control().message( 'A button' ).button().title( 'Calculate' ).add()

but that won't actually do anything. It will look like a button and the user can press it, but nothing will happen. We need to attach a function to the button that will be executed when the user presses it. Every time they press it.


Code:

var calcText = function( event ) {
  // get the current time
  var d = new Date();
  // create a message
  var s = 'You pressed the button at ' + d.getHours() + ':' + d.getMinutes() + ':' + d.getSeconds();
  // find the textarea control and set its contents
  $( '#textarea' ).html( s );
};
ui.control().message( 'A button' ).button( calcText ).title( 'Calculate' ).add()

Notice how the calcText function is passed in to the button function. It does not have ( and ) so it is not being invoked, just referenced. It will not be executed here, but it will be attached to the button so that when it is clicked, that function will be executed.

For your purposes, I would suggest using a new tab to contain the button and textarea, and any other controls you may want on there. In the button click event function, calculate the coordinates from the edge lengths and display it in the textarea. A textarea is a basic control though. It doesn't allow any formatting of the text such as bold fonts or structure like a table. You can only format through tabs, spaces and new lines. To use these characters in a Javascript string, you use \t and \n for tab and new line respectively. You can also use \r\n for a new line, it shouldn't matter. The former is the Unix way and the latter is the Windows way. Browsers have to cater to both.

Code:

var text = 'Some\ttab\tseparated\ttext.\nSome normal text.';
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Thu Jan 31, 2019 5:49 pm

.
Notice how the calcText function is passed in to the button function. It does not have ( and ) so it is not being invoked, just referenced. It will not be executed here, but it will be attached to the button so that when it is clicked, that function will be executed.
And ( and ) may be necessary. I don’t see how this option provides a solution. At present, the user enters a set of distances – we don’t even ask the user to identify how many; How do I “calculate” the number of rows, particles, and their coordinates? The code must be executed in order to build the output table.

Please correct me if I'm wrong. I’m thinking a fancy (n rows by four variables and text) alert message will do. When the user presses the UI OK button, the program is executed, but before the action is displayed, the fancy alert message appears.
if (outputTable == true){display fancy alert message output table}
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Thu Jan 31, 2019 7:48 pm

Ok, I forgot about the array processing that will split the text value (the edge lengths) into an array of numbers for you (before the success function is called). In this situation, you would have to do that yourself. I will explain how to do that shortly.

Airman wrote:How do I “calculate” the number of rows, particles, and their coordinates?

You are already doing that in your success function. I would start by copying the ktCyclicPolygon function and removing all code that creates the 3D stuff and just create the text from the coordinates. That function will be what you pass in to the button method when creating the UI. Or you might have a small wrapper function that gets the values from the controls and then calls that function, passing the values in as parameters.

To split the edge length text into an array of tokens, you can use the default tokenizers supplied by the Utils package like this:

Code:

var text = $( '#edgeLengths' ).val(); // replace edgeLengths with the id of your edge lengths control, make sure you leave the # in there
var tokens = Utils.TOKENIZER.WHITESPACE( text ); // use whatever tokenizer you have specified on the edge lengths control
var fmt = Utils.FORMATTER.Number;
var numbers = [];
for( var i=0; i<tokens.length; i++ )
{
  numbers.push( fmt( tokens[i] ) );
}
// now you can use the numbers array to calculate the coordinates
// numbers is equivalent to values.array in your success function

You find the controls that you need values from using JQuery in conjunction with the ID of the control. The $ value is JQuery and it is a function which you can give a CSS Selector. If the selector starts with a #, then it will look for an element with the ID that matches the rest of the selector (assuming a simple selector, they can get much more complex).

Code:

var myControl = $( '#myId' );

That will find a HTML element with an ID myId and return it as a JQuery object. JQuery supplies lots of functions to invoke on the object which are browser independent. That is, if different browsers do something in different ways, JQuery will take care of that for you. So to get the value from most controls, we can use the val function like this:

Code:

var myControl = $( '#myId' );
var myValue = myControl.val();

That works for things like text and numbers, but doesn't work for check boxes. They are a bit trickier, we have to check for a property called checked (which is a strange little beast as its value is irrelevant, only its presence matters).

Code:

var myControl = $( '#myId' );
var myValue = myControl.prop('checked');

That should return a boolean value that you can use where true means that it is checked and false means that it is not.

I don't think using an alert type of thing is a good idea because the user is already in a dialog box. Using multiple dialog boxes at the same time is frowned upon these days, because it can confuse the user but it can also get messy with the underlying UI. A modal dialog box, like what we are using here, stops the rest of the application from being interactive until it is dismissed. Having another modal dialog popup on top of that can cause issues with some frameworks.

Look at the gravity.js file for an example of a button and a textarea being used together.

Oh, and trust me, the ( and ) are definitely not needed in the context I was explaining. We don't want to execute the function at that point, we only want to pass it into the button method as a reference. It will only get executed if the user presses the button.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sat Feb 02, 2019 12:34 am

.
Possible Charged Particle Field  - Page 14 Sceneo10
Interim status report, half way there. Both the new output table and soon to be eliminated 3D particle field text are shown. The new output table needs some formatting changes, but all the values are present.  
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by LongtimeAirman Sun Feb 03, 2019 12:24 am

.
Possible Charged Particle Field  - Page 14 Prcp310
Here’s the latest Particle ring – Cyclic polygon, “Output control” tab.

I do like this scenario. Your instructions worked perfectly. All the 3D text is gone, my chrome console is happy and I can go back to firefox again.

With just four rows the table isn't as clear as the previous, I didn't see how to determine the number of particles and then output a new line for each position. For example, since I'm asking the user to decide whether to calculate the the output table, I see no problem asking that the user enter the number of particles, "for a better output table please input the number of distances/particles", then I believe I would be able to output a row for each particle instead of the current output table's total of four rows. Is there a way for me to use numbers.length to modify the Output control tab's textarea - perhaps with iterated calculate actions?  

I tried cleaning up the code – including deleting some original instructions. I'll create a single cyclic polygon function to replace the current separate cyclic polygon codes: one for the particle placement and the other for this new output table.

On a separate subject, you may have noticed I started a new scenario - Particle sphere UI - intended to replace the set of spherical scenarios. I didn't get very far.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sun Feb 03, 2019 5:31 am

No need to worry about the number of rows in the text area. It will add scroll bars if it needs to. When the function to calculate the coordinates is executed, the text area is already displayed and while it is possible to resize it, I'd prefer not to. Set it to a reasonable number to start with and let the user scroll for the rest. I'd say about 5 rows would be fine.

I don't think it is a good idea to make one function out of the two variants you have. They serve different purposes and any attempt to bring them together is going to be messy and difficult to maintain. You could look for common code in both versions and try to find a way to extract that out so it can be used by each of them, but it really isn't necessary.
Nevyn
Nevyn
Admin

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Mon Feb 04, 2019 9:34 pm

.
You indicated the possibility of a poly calculator of some sort. I also mentioned I'm trying to come up with a Particle sphere scenario to replace all the current Spherical group's polyhedra choices. While I haven't exactly made any new progress, I've reviewed the EQS algorithm for generating particles on the surface of a sphere. That algorithm is an important part of our particle engine which you recently described as a complicated function in a function, or something like that. I'll try to describe it more simply, omitting a few unknown calculation details like measuring from area edges versus center of areas.

Possible Charged Particle Field  - Page 14 Partsp12
EQS 132, 192, and 238. The EQS numbers indicate the number of radius = 1 neutral particles making up the surface of a sphere of radius 10.

There are 130 particles on the surface of the 130EQS sphere. They are generated by the five pairs of numbers in the code below. The 1st number of each pair refers to the latitude of a hemisphere; the equator is at lat. zero, and the north pole is at 90 degrees latitude. Here we see 90deg divided by 5 lat sets, 18 deg apart.

The 2nd number of each pair indicates the degrees between particles (c-c) at that latitude. Since each latitude has a different circumference, the total number of particles to fill each particle ring will vary. Comments have been added to show how each particle ring count is determined.

The same pattern is repeated to create the southern hemisphere. The total particle ring set is - 3,9,15,18,20,20,18,15,9,3.

Code:

     var angles130 = [
          [ 18, 18 ], // Lat 18. A particle every 18 degrees, 360/18 = 20 particles.
          [ 36, 20 ], // Lat 36. Every 20 degrees, 360/20 = 18 particles at that lat.
          [ 54, 24 ], // Lat 54. Every 24 degrees, 360/24 = 15.
          [ 72, 40 ], // Lat 72. 360/40 = 9.
          [ 90, 120 ] // Lat 90. 360/120 = 3 particles at the pole.
     ];
     var locator130 = new EQS.LocationCreator( angles130 );

     var angles238 = [
          [ 12.85, 15 ], // 24 particles
          [ 25.71, 15 ], // 24      "
          [ 38.57, 15 ], // 24      "
          [ 51.13, 18 ], // 20      "
          [ 64.29, 24 ], // 15     "
          [ 77.14, 40 ], // 9      "
          [ 89, 120 ] // 3       "     . Hemisphere total = 119. Full sphere = 238
     ];
     var locator238 = new EQS.LocationCreator( angles238 );
I recall asking how many spheres of a given size might fit on the surface of a larger sphere. EQS130 seemed like a good standard at the time. Understanding the algorithm better, I was able to get to 238 without any particle overlaps. Mainly by adding 4 extra latitude rings (2 per hemisphere) - that is, if you wanted to add a new precision almost doubling Overdrive.

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

PS. Must correct spelling (oarticle) error.


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

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by LongtimeAirman Mon Feb 04, 2019 10:41 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Tue Feb 05, 2019 8:30 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Tue Feb 05, 2019 9:05 pm

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

Possible Charged Particle Field  - Page 14 Howeqs10
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
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by LongtimeAirman Wed Feb 06, 2019 12:43 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by LongtimeAirman Thu Feb 07, 2019 12:58 am

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

Possible Charged Particle Field  - Page 14 Partsp13
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.   
 
Possible Charged Particle Field  - Page 14 238and10
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
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Fri Feb 08, 2019 2:06 am

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by Nevyn Fri Feb 08, 2019 4:31 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Fri Feb 08, 2019 9:29 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Fri Feb 08, 2019 10:05 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sun Feb 10, 2019 7:26 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Mon Feb 11, 2019 5:52 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Wed Feb 13, 2019 12:20 am

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

Possible Charged Particle Field  - Page 14 Eqs40610
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
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Wed Feb 13, 2019 12:55 am

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by Nevyn Wed Feb 13, 2019 12:58 am

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Wed Feb 13, 2019 1:17 am

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

Thanks for the additional guidance.
.

LongtimeAirman
Admin

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by LongtimeAirman Wed Feb 13, 2019 1:35 am

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Wed Feb 13, 2019 5:42 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Thu Feb 14, 2019 8:27 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Thu Feb 14, 2019 11:37 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sat Feb 16, 2019 5:13 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sat Feb 16, 2019 6:01 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sat Feb 16, 2019 9:14 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sat Feb 16, 2019 10:29 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by LongtimeAirman Sun Feb 17, 2019 2:43 pm

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

Posts : 2015
Join date : 2014-08-10

Back to top Go down

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

Post by Nevyn Sun Feb 17, 2019 5:41 pm

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

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

http://www.nevyns-lab.com

Back to top Go down

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

Post by Sponsored content


Sponsored content


Back to top Go down

Page 13 of 15 Previous  1 ... 8 ... 12, 13, 14, 15  Next

Back to top

- Similar topics

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