Possible Charged Particle Field

Page 24 of 24 Previous  1 ... 13 ... 22, 23, 24

Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Dec 05, 2018 10:49 pm

.
I have implemented re-configuration. Is that even a word? It is now!

I am not convinced that everything is being disposed of correctly, but I think I have most, if not all, of it. If you notice crashes after re-configuring many times, let me know as it most likely means something is not being released.

My site has been updated with the latest code: https://www.nevyns-lab.com/mathis/app/cpim/test.html


MotionEngine.prototype.destroy. "This method is called to destroy an engine and is only used once per engine" - sounds seriously cool.

Reconfiguration it is; its working perfectly.

I've been trying the Reconfigure button for a few scenarios at your Lab and at home, back and forth and back and forth between changing a value on the User Interface parameter page and viewing the changing output with my browser console open - no errors observed. Your change appears to work for all UIs so far. Why did you make a change - adding the 'gravityForm' label to the gravity scenario only? You indicated that the label is optional, so why would one want the label? In any case I'll be happy to make that change across all the scenarios if you'd like, repetition is the only way I seem to learn anything.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Dec 06, 2018 5:00 am

Oh, I forgot to tell you about that. You can now set an ID on a form. It is optional and a default will be applied. At first I used that to store the form in the UIManager because I couldn't get a nice expression to determine if the form was already created using JQuery. So I store the form in an object, which is a property of the UIManager class (called forms). When I realised that you didn't really need to specify the ID, I just left it in but made it optional.

You can use it to create multiple forms. You define all of the forms you want in the scenario init function, but you only call show() on the first one. In the success function of that, you show the second form and in its success function you show the next, etc, etc.

It would look something like this:

Code:

var form1 = ui.createForm( 'form1' );
var form2 = ui.createForm().id( 'form2' );
form1.title( 'Form One' ).blah blah blah
form2.title( 'Form Two' ).blah blah blah
var suc1 = function( values )
{
   // use values
  ...
  // show next form
  form2.show();
};
form1.success( suc1 ).show();

I haven't actually tried it yet, but it should work (famous last words).
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Dec 06, 2018 5:04 am

And, it turns out, the destroy method is actually being used multiple times per engine (every time you press reconfigure). It is considered the end of life for the engine, but the init method can be called again to start a new life, so to speak. This allows some things to be reused and others to be released and recreated.
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Dec 06, 2018 1:50 pm

.

We have a set of Reconfiguration errors after using Reconfigure 3 times to vary Offset Pair UI's moving particle's offset distance. At first I thought I needed to repair the collision scenario; until I saw that each new Reconfiguration added a new set of post collision lines.

In the Collision group scenarios the user has the option to turn on/off lines and target boxes. If no lines or target boxes are selected, all well and good. When one does select lines, additional Reconfigures will not remove those lines.

I especially like the fact that Reconfigure defaults to a Reload when there is no user interface for that scenario. I use the left arrow to Reset the scenario, is there a single key for Reconfigure so one can do so without opening the control panel?

Adding to my short term to-do list: updating the Help pages. It's missing several things like the vectors or the Reset, Reconfigure and Reload buttons.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Dec 06, 2018 5:04 pm

You are going to have to deal with that in the scenario init function. Any objects you add to the scene, apart from the Particles themselves (which strictly speaking, you don't add to the scene graph), you will need to keep a reference to them in the scenario and check to see if they exist prior to creating and adding them.

Code:

(function( ScenarioJS, PIM, THREE )
{
   var ZERO = new THREE.Vector3( 0, 0, 0 );
   var AXIS_X = new THREE.Vector3( 1, 0, 0 );
   var AXIS_Y = new THREE.Vector3( 0, 1, 0 );
   var AXIS_Z = new THREE.Vector3( 0, 0, 1 );
   
   var myLines = null;
   
   var initRandom = function( factory, ui )
   {
      // only create lines if they do not already exist
      // this code could be in the success function
      if( myLines != null )
      {
         myLines = ...
         scene.add( ... );
      }
      
      // we can use only the success callback because we have specified a default value on the control
      var success = function( values ) {
         ...
      };
      // create a form for user input
      ...
      return null;
   };

   var group = 'My Scenario';
   
   ScenarioJS.addScenario( group, 'Random', initRandom );
   
}( ScenarioJS, PIM, THREE ));
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Dec 06, 2018 5:18 pm

You also may need to remove them from the scene if you determine that they already exist, rather than just leave them there. It depends on what you are using the objects for. If they depend on values supplied by the user, then remove and recreate them, otherwise they can just be added once and forgotten about.

Code:

(function( ScenarioJS, PIM, THREE )
{
   var ZERO = new THREE.Vector3( 0, 0, 0 );
   var AXIS_X = new THREE.Vector3( 1, 0, 0 );
   var AXIS_Y = new THREE.Vector3( 0, 1, 0 );
   var AXIS_Z = new THREE.Vector3( 0, 0, 1 );
   
   var myLines = null;
   
   var initRandom = function( factory, ui )
   {
      // only create lines if they do not already exist
      // this code could be in the success function
      if( myLines != null )
      {
         for( var i=0; i<myLines.length; i++ )
         {
            scene.remove( myLines[i] );
         }
      }
      myLines = [];
      myLines[0] = new ...
      for( var i=0; i<myLines.length; i++ )
      {
         scene.add( myLines[i] );
      }
      
      // we can use only the success callback because we have specified a default value on the control
      var success = function( values ) {
         ...
      };
      // create a form for user input
      ...
      return null;
   };

   var group = 'My Scenario';
   
   ScenarioJS.addScenario( group, 'Random', initRandom );
   
}( ScenarioJS, PIM, THREE ));
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Dec 06, 2018 5:21 pm

Technically, reconfigure does not default to reload, it just equates to almost the same thing.

No key binding at the moment, hadn't thought about it. Not sure what key to put it on yet, maybe the Home key.

Yeah, that's the problem with documentation, you have to keep it up-to-date.
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Thu Dec 06, 2018 6:28 pm

.
I'll study your directions and see what happens next.
 

In the meantime, I tried to make an unmoveable UI scenario using the hosohedron configuration but it was too easy for unmoveable neutrons to be placed in overlapped positions near the top and bottom positions - sometimes freezing the screen. Ok, no Unmoveable UI yet, I simply added a new non interactive Unmoveable scenario - Hosohedron.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Dec 06, 2018 7:10 pm

That is a problem with the hosohedron algorithm. The top and bottom get very crowded because they contain the same number of particles as any other latitude. That is why I stopped using it for the charge points and found an algorithm that attempts to make equal areas between points, rather than equal numbers of points.

The collision code should separate them, but it can take quite a few iterations before they are all separated. It is all of those collisions that cause it to slow down.
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Fri Dec 07, 2018 12:20 am

.
You "found an algorithm that attempts to make equal areas between points, rather than equal numbers of points" eh? Excuse me for asking - which algorithm is that? The .js file and line numbers would be perfect. Actually I was thinking a 60 vertex icosa based configuration might work best for the Unmoveable UI, all 60 may fit inside the proton's emission radius.  

With respect to lines, grids, targetboxs, trajectories and whether they exist or not, I haven't tried any coding yet. I'm trying to wrap my mind around null. I see where your instructions involving these new or existing lines is an expansion of the Gravity scenario: var initRandom = function ( factory, ui ).  Thanks, that's probably all I should need. I'll be able to play with it a bit before crying uncle.

In case you might otherwise miss it for a few days, I sent you an unrelated PM.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Fri Dec 07, 2018 2:12 am

Ah, null. Such a simple, yet strange concept. I take it for granted these days and don't even think about how others might not understand.

Null was invented to solve a very simple problem. It is the answer to a very simple question: Do I have a value?

We usually think of variables based on what they store and what we use it for. An integer is going to store a number and we can do things with it like increment and decrement, add and subtract, etc. Sometimes, we need to think about a variable in a more abstract way. We need to know if the value stored in that variable is actually a valid value.

We use null to say: No, there is no value here, do not use it.

In Javascript, you can always use null. JS actually takes it a step further and defines another type of null, called undefined. I'm not sure why, but there is a difference. A default, unassigned, variable will be undefined. You have to set it to null explicitly. You can't do this:

Code:

var unassigned;
if( unassigned == null )
{
  // will not go into here
}

But you can accomplish the same thing with the typeof operator. This instruction will return a string that tells you the type of a variable.

Code:

var unassigned;
if( typeof unassigned === 'undefined' )
{
   // will go into here
}

However, this is easier:

Code:

var assigned = null;
if( assigned == null )
{
  // will go into here
}

This is even easier and will actually work with either null or undefined:

Code:

var assigned = null;
if( !assigned )
{
  // will go into here
}
var unassigned;
if( !unassigned )
{
   // will go into here
}

Sometimes you need it to work a specific way, and other times it really doesn't matter. You might come across all of them though, so it was worth showing the different ways this might be done.
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Dec 08, 2018 2:36 am

.

A view looking down at the latest Unmoveable.

First things first, I had to replace that awful unmoveable hosohedron I made yesterday with a 60 vertex truncated icosahedron. This configuration lets more neutrons get closer to the central proton without overlapping positions like the hosohedron did. It's still not a user interface, but I believe the 'association football'/buckyball is much better.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Dec 08, 2018 3:23 pm

.

We have an Unmoveable UI.

Beginning with the truncated icosa configuration, the user selects a few proton parameters: position ( inside the neutrons or not ), y-axis spin velocity, and spin axis orientation. If there’s an overlap, Reconfigure makes repositioning the proton easy. For the accompanying image, I turned on the spin vectors to show which neutrons were being effected – the spin vectors do act strangely at times.

Anyone, Please feel free to comment, suggest or criticize. Additional scenario suggestions are welcome.

Unless I think of something else real soon, I’ll look at my collision line null assignments next.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sat Dec 08, 2018 6:14 pm

LongtimeAirman wrote:.
You "found an algorithm that attempts to make equal areas between points, rather than equal numbers of points" eh? Excuse me for asking - which algorithm is that? The .js file and line numbers would be perfect.

In the js/engine/eqs.js file, there are 3 versions of the algorithm that you can use, each having more points than the last. Here's how you use it:

Code:

var locator = new EQS.LocationCreator( EQS.ANGLES_46 );
var points = [];
var radius = 100;
locator.createLocations( radius, points );
// at this stage, points contains THREE.Vector3 objects where each one refers to a point on the sphere at the given radius.

You can use EQS.ANGLES_130 or EQS.ANGLES_406 in place of EQS.ANGLES_46 if you want more points. Unfortunately, you can't choose an arbitrary number of points.
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Dec 09, 2018 1:47 am

.
Here's a simple temporary spherical scenario init46PointSphere01, I put it together with your instructions included in order to see the output for the algorithm you mentioned.
Code:

var init46PointSphere01 = function( factory ) {
       camera.position.set( 10, 10, 10 );
       var locator = new EQS.LocationCreator( EQS.ANGLES_46 );
       var points = [];
       var radius = 10;
       locator.createLocations( radius, points );
       // at this stage, points contains THREE.Vector3 objects where
        //each one refers to a point on the sphere at the given radius.
       var particles = [];
       var p;
       p = factory.createProton().place( 0, 0, 0  )
       .spin( 0, 1, 0, Math.random()*Math.PI/2 )
       .get();
       particles.push( p );
       for( var i = 0; i < 46; i = i++ ) {
             p = factory.createNeutron().place( points(i)).get();
             particles.push( p );
       };
 var particleArray = new PIM.ParticleArray( particles );
 return particleArray;
 };

No joy. I believe something is wrong with .place( points(i)). It's causing the browser as well as my system to freeze up. Same when I replace .place( points(i)) with .place( points[i]). The function is properly registered at the bottom of the 'Spherical' scenarios list so that's not the problem.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Dec 09, 2018 1:50 pm

.
No change. I’ve made several more efforts. EQS apparently requires a pointer/function call. I noticed its absence, and tried placing EQS in the spherical.js function argument list - here it is in the fourth position.

Code:
(function( ScenarioJS, PIM, THREE, EQS )

I tried that yesterday too, but this morning I was more organized/systematic. There are errors for each position: the spherical group goes missing from the scenario listing; EQS.LocationCreator is not a function; EQS is not a constructor; points is not a function. EQS is undefined when I remove it.  I tried it in the init46PointSphere01 function call too with no better results – I had to try.

Code:
var init46PointSphere01 = function( factory, EQS )

I’m good with a constant degree of difficulty in working toward a positive outcome, it comes with the territory. You cause me great pain and joy Sir.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Dec 09, 2018 4:57 pm

Sorry, I forgot about the EQS reference and just assumed it would be available.

You did the right thing by putting the EQS reference in the top function declaration:

Code:
(function( ScenarioJS, PIM, THREE, EQS )

but you also need to put it into the invocation of that function, which is at the very bottom of the file:

Code:
}( ScenarioJS, PIM, THREE, EQS ));

You will need to remove it from the init function declaration:

Code:
var init46PointSphere01 = function( factory, EQS )

should be

Code:
var init46PointSphere01 = function( factory, ui )

You must use the points as an array:

Code:
.place( points[i] )

Don't iterate over a literal number, use the length property of the points array so that it will work regardless of how many points are in there:

Code:
for( var i = 0; i < 46; i = i++ )

should be

Code:
for( var i = 0; i < points.length; i++ )

notice I also remove the i = i++ part, as that would not work as you expect and i would not increment. That is because there are 2 versions of ++. There is the post-increment, where the ++ comes after the variable, and there is the pre-increment, where the ++ goes before the variable.

Code:

var i = 10;
var post = i++;
var pre = ++i;

After that code has executed, you might expect post to equal 11 and pre to equal 12, but they won't. post will equal 10 and pre will equal 12.

That is because var post = i++; will execute the = operator before the ++ operator, hence why it is called post-increment.
However, using the pre-increment will do it the other way around.

Actually, I was wrong, your original code would have worked, but only inadvertently. The reason it would work is because you are using i in both places, so it would execute like this:

i = 0
execute loop
evaluate i = i++ --> set i to current value of i (which is 0), then increment i, which makes it equal to 1.

So inefficient, but it wold work.
avatar
Nevyn
Admin

Posts : 1399
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Dec 09, 2018 6:32 pm

.

There's nothing amiss here - a brief moment in time.

Joy.

The Unmoveable UI uses unmoveable neutrons; here, in the sphericals, the particles are free to accelerate together. The 130 particles were initially placed an emission radius ( r=10 ) from a proton at (0,0,0) where they were well placed and close together. The started accelerating together - the image shows them a little bit overlapped - that's part of a collision simulation - just before they begin to burst apart. Needless to say, your directions worked perfectly; I spat ( a small mess) when the mass burst apart.

The 130 spherical works much better than the C60. I'll go back and to finish the Unmoveable UI again. This has been a long term discussion - the number and distribution of charge points on a sphere - that I can follow. I do seem to recall seeing that algorithm in a search for this project a few months ago, in any case it's nice to see you've implemented them. Maybe C60 should be placed with the EQS group.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman Today at 1:27 pm

.
Update. initOffCollisionPairUI2. The line problem. How do we remove prior scene lines after Reconfigure changes the scene?

I haven’t gotten your directions to work yet.

Before I could even begin I needed to add the array myLines. Now all lines are added to myLines before they are added to the scene. That alone is progress. I see that adding an array to contain all the lines is a code improvement, adding an array of lines to a scene is more efficient and better practice than adding each individual line as they are made to the scene. That works and I pushed it. Since then, myLines is now declared in the initOffCollisionPairUI2, success function, and the lines are still calculated and added to myLines in the initOffsetPairUI2 function. I haven't pushed that myLines change yet.  

The problem is a bit different than I first thought. After any Reconfiguration – restart the scene by removing all the previous scene lines. Note that the total number of lines in this case is just 1 or 2, the post collision trajectories of the initially moving and stationary particles. Later, I could avoid removing lines by checking whether the offset value changes, along with the state of the show post collision trajectories checkbox; but for the time being keep it simple – restart the scene by removing all the previous scene lines first.

That’s where I’m at, crawling, creeping along quite slowly. The if( myLines != null ) doesn’t work yet. Maybe because I shouldn’t make that test until after a Reconfigure has occurred. I'll try that next.  
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman Today at 3:03 pm

.
Not trying to change the subject, just making an observation.


130 Neutrons UI. The array ( radius 8 ) as seen from the array center to one of the array 'poles'.

What's the practical limit - the maximum number of neutral particles in a spherical array - without overlap - at a given radius? I believe spherical arrays are not idle mathematical questions but are real particle configurations that our engine might someday show to be possible. There is also the related question what is the best distribution of charge points about a spherical surface. I believe we share that interest. The minimum spherical array radius limits in the two new Unmoveable UIs was determined by the need to avoid the three each pole particles from coming into contact. I'm not suggesting that that's any problem whatsoever.

When I suggested that C60 be added to the EQS group I realize that the C60 is a different type, C60 is x,y,z listed in terms of phi, while ( I assume ) the EQS group is tabulated in polar coordinates. A x,y,z/polar converter should be an easy matter - for you. Or how about axis angling spherical arrays?

Ok, I'll get back to work.
.

LongtimeAirman
Admin

Posts : 1080
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Sponsored content


Sponsored content


Back to top Go down

Page 24 of 24 Previous  1 ... 13 ... 22, 23, 24

Back to top


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