Possible Charged Particle Field

Page 21 of 23 Previous  1 ... 12 ... 20, 21, 22, 23  Next

Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Nov 05, 2018 9:52 pm

LongtimeAirman wrote:Can we detect and display a magnitude corresponding to the spin rate, and slow it down so it agrees with the particle spin rate?

We could, but what is the point? Then it would just spin with the particle and we would not need the spin node at all.

LongtimeAirman wrote:Can we introduce additional variations within Lattice 03? Changing a particle's orientation seems to mis-align it's spin node.

Do you have a pic of that? Can you see any kind of relationship going on? For example, if you change the orientation by 90° about the X axis, does that change the spin node by a corresponding amount, and on what axis.

The orientation should not change the position of the spin node. Only changing the spin should change the spin node.

LongtimeAirman wrote:I found a few more additional spin node distortions. They can occur for both protons and neutrons. A new collision bug, where their spin node remains elliptically elongated. One can find a few in Lattice 02.

Try to get some pics of the distortions. I thought that I saw the spin nodes shrinking within the particle sometimes, but I could not find any code that should be doing that. I'm not even convinced that that is what I saw, but it certainly looked like it. Sometimes angles can make things look different than they actually are.

LongtimeAirman wrote:
Are you talking about stacked spins?
I'm talking about the spin node's ability to track the particles' different spin motions. Two Body 04 is a perfect example - the bottom particle is rotating end-over-end as shown by the CW rotation of the spin node. The spin node just shows a simple x or z rotation - with no indication of the protons primary y axis spin. Shouldn't we be able to show the real time orientation of the particle's y spin? We could watch it tumble with additional spins.
.

Each particle only has 1 spin motion. Not sure what you mean by particles' different spin motions.

The bottom particle in Two Body 04 does not have a Y spin. It has an X spin. An X spin rotates around the X axis. It also isn't an end-over-end spin, it is just an axial spin. That's why I thought you were talking about stacked spins, because they do have end-over-end spins.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Mon Nov 05, 2018 11:25 pm

.

Here's a picture of spin node distortion. That's funny, I thought I was seeing elongation expansion, but the spin node around the proton below ‘close controls’ has elongated by selective shrinking. I'll take another pic if I see anything different. It's harder to see the spin nodes penetrating the green colored neutrons.

Airman wrote. Can we detect and display a magnitude corresponding to the spin rate, and slow it down so it agrees with the particle spin rate?
Nevyn. We could, but what is the point? Then it would just spin with the particle and we would not need the spin node at all.
Airman. I see spin nodes as a component of the particle armillary, the spin node duplicates the particle and provides all relevant spin details which can be turned on or off by the user. We might still incorporate collisions into the armillary as well.

Nevyn. Each particle has 1 spin motion.
Airman. One spin motion? The particle at the bottom of Two Body 04 has a y spin, the source for the proton emissions, as well as an x spin; the spin node shows a single x spin without regard for the yspin emission field. A particle orbiting a body has the two orthogonal velocities of curved motion or spin, but what if the particle is also orbiting something else, like galactic central? Isn’t cubic motion (orthogonal x, y and z velocities) a logical extension of pi=4?

One spin? It mostly bothers me that the  spin nodes don't seem to be portraying the particle's apparent motions very well. The nodes need improvement, I do hope we end up keeping them. I don't know if you are arguing for or against them. Please let me know if you think I’m mistaken – i.e. they may not work out.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Nov 06, 2018 12:26 am

I'm not arguing against them. I just want to make sure they are working correctly and that the underlying spins are working correctly.

Airman wrote:Airman. One spin motion? The particle at the bottom of Two Body 04 has a y spin, the source for the proton emissions, as well as an x spin; the spin node shows a single x spin without regard for the yspin emission field. A particle orbiting a body has the two orthogonal velocities of curved motion or spin, but what if the particle is also orbiting something else, like galactic central? Isn’t cubic motion (orthogonal x, y and z velocities) a logical extension of pi=4?

The purpose of the spin node (and velocity node) is to show what the app is doing to these particles. It is not there to show underlying stacked spins. It isn't really there for the user at all, it is there for us as developers. They allow us to see what is going on underneath our code and make sure that it reflects our intentions.

It doesn't matter how many orbits you put the particles in, they still only have 1 linear velocity and 1 spin velocity. The orbit is created by external forces upon the particle (or apparent forces) that change those velocities over time.

No, cubic motion is not an outcome of PI=4. PI=4 is an outcome of circular motion. It is the result of looking at the actual forces, rather than just the position of things and ignoring how they got there.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Nov 06, 2018 10:52 am

.

Thanks Nevyn, you're right. I've mistakenly interpreted the proton emission field as proof that our particles could display more than a single spin motion at a time. I'll try not to do it again.

I was going to add random locations to the Four Body group, but decided against it for the time being. I see that a Four Body 01 collision is a reliable source for distorted spin nodes.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Nov 06, 2018 12:29 pm

.

Here's a better picture from Four Body 01 showing both protons and the closest neutron all with spin node distortions.

Separate subject. Nagging me for several days. It takes two program reloads to select Boundary (one reload), and then the boundary radius (the second program reload). Could they be combined into one program reload?

I've been puzzled by the mysterious function code you added In cdm.js right above - var PI_RATIO = 4/Math.PI;. I haven't gone into solve or search mode, but I've been awful curious - I have a couple of ideas. Just letting you know it's caused me some speculation.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Nov 06, 2018 7:49 pm

LongtimeAirman wrote:Separate subject. Nagging me for several days. It takes two program reloads to select Boundary (one reload), and then the boundary radius (the second program reload). Could they be combined into one program reload?

Yeah, I'm aware of it, but haven't put any time into trying to solve it. It is just a result of the way the menu was initially implemented. Since then I have introduced Bootstrap which I could use to show a dialog box to get all relevant parameters before reloading.

LongtimeAirman wrote:I've been puzzled by the mysterious function code you added In cdm.js right above - var PI_RATIO = 4/Math.PI;. I haven't gone into solve or search mode, but I've been awful curious - I have a couple of ideas. Just letting you know it's caused me some speculation.

It's called a Closure. I've used them quite a bit in this app. They are a bit difficult to understand without knowledge of how Javascript is interpreted and executed. It relies on the fact that functions in JS are just an object like any other, and also the way variables are searched for if they are not defined locally. You can think of it as a way to declare a scope and that is exactly what I am using it for.

Since a function is just an object, it has a lifespan. Some functions are created, used and then destroyed quite quickly, others exist for the entire time that the application is running. Some functions look like they will only exist temporarily, but actually they will stay around for some time. The way I am implementing Closures fits into the 'looks temporary, is actually not' category.

Without getting too complex, I am using it to create variables that will exist longer than the function execution that uses them. In this case, I am declaring PI_RATIO which is then used in the following function. If I declared it as a local variable in the function, then it would be calculated every time that function was called. The way I have done it, it will be calculated once and then used as a value from then on, whenever that function is invoked.

In other cases, I use it to create objects once and use them repeatedly (usually Vector3 and Quaternion objects). This saves the time it takes to create them. I do this when I know that the function will be called every frame so that I don't need to create 60 objects a second, multiplied by however many objects that are used per frame (a lot). It all adds up and slows down the rendering process. Note that I can only get away with this because JS is single-threaded. If it supported multi-threaded programming then I would need to handle it differently.

So, in essence, I am creating a scope that will exist for the life of the app, so that the objects declared in that scope can be used without creating them or calculating them over and over.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Nov 06, 2018 9:32 pm

.
Thanks for the explanation. I understand the need for a single source for ready answers to expensive calculations, the commented out code /*  */ above var PI_RATIO had my interest, it looks like your angular speed calcs.

Bootstrap worked great for the Help section, I didn't realize it could allow the user to set program parameters too. I'm on the Bootstrap site, https://getbootstrap.com/. I also wondered about cloudflare, now I see where it came from.

I'd like to make a change to our UI, but I haven't done so yet. Let the user select the number of particles and the min/max speeds for the collision scenarios. It's good to know we have a choice in implementing such a change - our control panel or Bootstrap - I suppose it means more complicated maintenance. How do I go about making changes to the Bootstrap code? Should I download it or it's documentation? If you have special plans or wish to pre-coordinate any Bootstrap preferences, let's do so.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Tue Nov 06, 2018 10:38 pm

That commented out section above PI_RATIO is me transforming the velocity-to-angle equation into an angle-to-velocity equation. I left it in there in case I got something wrong and needed to refer to how I worked it out. So, yes, it is my angular velocity equation being transformed into a different form.

Bootstrap isn't doing anything for us specifically, it is just a library that provides useful user-interface related things. Generally, all it does is change the way they look, but sometimes it also changes the way they operate. We could do it all without Bootstrap, but it wouldn't look anywhere near as good or polished.

So Bootstrap won't be setting any program parameters, we will use Bootstrap to show a dialog box that lets the user enter those parameters, and then when they press the OK button, it will reload the page.

Similarly, if you want to let the user make some choices when the page loads, you would show a Bootstrap dialog from the scenario init function and then use the values entered to initialize that scenario.

There is a problem with that second approach. Generally, when you use a Bootstrap dialog box, you define it in the HTML. However, I would prefer that we don't do that, as it will tie the scenario to the HTML and I don't want that. Instead, we should build the dialog box in code (which Bootstrap usually supports). That way, the scenario is completely defined with its own JS file and does not link to any other files. I want them to be self-contained.

In saying that, it is generally easier to define the dialog box in HTML and then get your code working. Once it is, we can look into moving it to the code. Don't get held back by trying to do everything at once.

What I have been thinking about, is creating a new class that will take care of these types of things for us. It will have methods to get a value from the user given a message, or present a form containing multiple values, etc. Basically, this class will hide how that happens from the rest of the code. Then, if we later decide that we want it to work differently, we can change it in that class, and everywhere else is ready to go.

If you can work out what parameters you want and list them, then I can define the class and methods to get them from the user for you. Once we have that working, it will be so easy to add to other scenarios that we will probably redefine the whole user interface with it.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Tue Nov 06, 2018 11:55 pm

.
Does this sound ok? It applies to the Colliding group Direct 01 and Direct 02.

Three requested values. (The program variables). (The number constraints).
1. Minimum velocity. ( var startVel; ). ( 0 <= Minimum velocity <= Maximum velocity <= 60 ).
2. Maximum velocity. ( var stopVel; ). ( 0 <= Minimum velocity <= Maximum velocity <= 60 ).
3. Number of collision sets. ( var edgeZ; ). ( 1 =< collision sets <= 18).  

If there is just a single collision set selected, the moving particle(s) will travel at the Maximum velocity selected.

If there are two collision sets selected: one particle set would travel at the minimum velocity; and the other particle would travel at the maximum velocity.

The velocities of the collision sets greater than two and less than 18 ( the maximum) will be interpolated linearly between those two limits.

Negative values will be converted to positive(?).
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Nov 07, 2018 11:16 am

.

Ok, I see you've created a new user interface (UI) for Gravity - Random 06. It starts with the above image.

The code:
Code:

 ui.createForm().title( 'Gravity Scenario' ).message( 'Various scenarios based on gravity.' )
 .control().message( 'Radius' ).value( 100 ).min( 10 ).max( 1000 ).step( 10 ).add()
 .control().message( 'Count' ).value( 300 ).min( 2 ).max( 500 ).step( 1 ).add()
 .success( success ).cancel( cancel )
 .show();
 return null;

Its a Good draft. Simple, straightforward, easy to use. I'm surprised I don't see the radius and count message labels.

It appears the same for Chrome or Firefox Developer.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Nov 07, 2018 5:17 pm

I'm not sure why the labels aren't showing. They are put in there, and should show above the input control for it. I had a more important problem to fix though. The way the scenarios returned the ParticleArray object was a problem because to use a UI like this, you have to let the program continue on before it will show the dialog box. You use the values by implementing a function and attaching it by calling the success method (and a similar one for cancel that uses default values). so I had to change the way test.html was using the ParticleArray so that some scenarios could return a null value and the system would still operate without errors.

Ok, I just had a look and I can see why the labels aren't showing. The value of the message is not being set on the label. Doh! I'm at work, so I can't fix it until later today, but if you want to, just add this line at js/utils.js line 232:

Code:

d.html( params.msg );

I am thinking about changing the way the success and cancel functions work. They currently must find the values themselves, but I think I can extract those values, put them into an array or map, and then pass that to the success or cancel function. This will remove the need for 2 functions and you can just register 1. The UIManager will then call it with the appropriate values.

I will add support for drop-down lists and checkboxes soon. It currently supports text and numbers, which will be fine for most cases.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Nov 07, 2018 6:19 pm

.
I quickly added js/utils.js line 232 because I'm right in the middle of it. Pardon me, I also changed msg to message because I also spent time looking for the label problem. Probably needs changing back. I never would have come up with your new line 232.

Good - get rid of the success/cancel alternatives; I'm having a devil of a time trying to re-define the new Colliding group scenario, Direct UI into success and cancel functions. I'd probably need two duplicate functions with either the: 1. selected values; or 2. preset values.

I'm thinking the first scenario of the group, should be designated Group UI to convey the fact that the user will receive additional information of the scenario group or allow user selectable variables. The rest of the group's scenarios, 01-07 provide our existing preset variables.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Nov 07, 2018 7:24 pm

To implement the success/cancel callback functions, put the general code to setup the scenario into another function, much like we have in various scenarios. Then you call that function from the success/cancel functions with the appropriate parameters. We should be able to remove a lot of the scenario menu options by using dialogs.

Code:

(function( ScenarioJS, PIM, THREE )
{
   var initMyScenario = function ( p1, p2, ... )
   {
      ...
      return new PIM.ParticleArray( ... );
   };

   var init = function( factory, ui )
   {
      var success = function()
      {
         // TODO get values from ui
         // call init function
         var pArray = initMyScenario( p1, p2, ... );
         // set particles
         ui.setParticles( pArray );
      };
      // setup and show dialog
      ui.createForm().title( 'My Scenario' )
         .control().message( 'p1' ).value( 100 ).add()
         .control().message( 'p2' ).value( 300 ).add()
         .success( success )
         .show();
      return null;
   };

   var group = 'Gravity';

   ScenarioJS.addScenario( group, 'My Scenario', init );
}( ScenarioJS, PIM, THREE ));

Retrieving the values is currently up to you, and it sort-of requires knowledge of what the UIManager is doing, although there is a way to specify it yourself.

Essentially, the input controls have an ID attribute that can then be used to find that control. You can specify one yourself by using the id method in between a call to control() and add(). Like this:

Code:

      ui.createForm().title( 'My Scenario' )
         .control().id( 'p1' ).message( 'My Param 1' ).value( 100 ).add()
         .control().id( 'p2' ).message( 'My Param 2' ).value( 300 ).add()
         .success( success )
         .show();

Then you use JQuery to find that element like this:

Code:

      var success = function()
      {
         // get values from ui
         var p1 = $( '#p1' ).val();
         var p2 = $( '#p2' ).val();
         // call init function
         var pArray = initMyScenario( p1, p2, ... );
         // set particles
         ui.setParticles( pArray );
      };

If you don't specify an id, then it will use a generated id with the prefix value and the order number of the control as added to the form, starting at 1.

Code:

      var success = function()
      {
         // get values from ui
         var p1 = $( '#value1' ).val();
         var p2 = $( '#value2' ).val();
         // call init function
         var pArray = initMyScenario( p1, p2, ... );
         // set particles
         ui.setParticles( pArray );
      };

JQuery is a nice library to use and can simplify a lot of web development by homogenizing things that different browsers do differently. Here we are using it to select an element based on its ID, but you can do many other things with it. You don't need to use JQuery for this, but it is available because Bootstrap requires it and I generally use it if I am doing a lot of HTML manipulation.

To do it without JQuery, you would do this:

Code:

var element = document.getElementById( 'value1' );
var p1 = element.value; // this can be different depending on that actual element type which the JQuery val() method takes care of for us

But I want to change all of that anyway. I can do that in the UIManager and just pass in the values so these functions will become more streamlined. So I wouldn't go too far changing scenarios to use this just yet. By all means, have a play with it in one scenario, knowing that you will need to change it before too long.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Wed Nov 07, 2018 9:10 pm

.
It sounds like a plan.

It would be ideal if each of the Group’s scenario alternatives could be selected or selectable from the Group’s UI page. For example, until yesterday, the Gravity group had five scenarios whose only differences were general random settings. It makes good sense to replace them with a single UI. I can finally dial up my preferred number of Gravity particles – four. Of course the Group’s UI page should also include its own pared down scenario list to choose from.

I can almost follow the code. After my previous post I looked more closely at UI changes and was over my head. HTML 5? Suggesting I play around with it before you change it again is a bit more than I’m capable of – almost. Your use of normal developmental jargon throws me. Mention of JQuery lost me completely. Ok, JQuery is a nice library - of what? You don't have to explain everything; It just takes time. Form creation is a long way from charge fields but I’m grateful and happy for the opportunity to learn it in service to you and the charge field.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Wed Nov 07, 2018 10:49 pm

I use the jargon because it will allow you to search on it and get more information if I haven't written enough. If I water it down too much, it will make it very difficult to do any research, if needed.

I try to include code examples to show what needs to be done. It can be difficult to judge how much to explain sometimes.

A lib like JQuery is a huge thing. I just wanted to show what we would be using it for rather than get into what it could be used for. Same for Bootstrap, but at least with that I can just say it is a UI type of thing. JQuery covers UI stuff, element selection, style sheets, events, and a heap more that I can't remember or don't even know. Right now you can just think of it as a nice way to find things. It should be hidden from you soon enough.

At this stage, it is enough to be able to look at the examples, or the code itself, and see that a particular line is retrieving a value, say, even if you don't understand how it is doing that. A lot of development gets done that way. We all just copy/paste, get it working, then try to figure out why it works. Eventually you start to understand more and more and can decide when to use certain tools/techniques over others. But we all started without knowing much about anything and we all just toyed with it until we did.

The commits I pushed last night were fairly low level. It is dynamically generating a modal dialog box, and the controls it contains, based on information we supply. You don't really need to know much about that as long as you can use it effectively. I wanted to create the UIManager class just for that reason. It is there to hide the complexity of UI interaction and provide a common place for it, so that we don't need to implement all of that in every scenario. As a bonus, it allows us to make changes to the UI in one place and all scenarios will be updated without needing to be touched.
avatar
Nevyn
Admin

Posts : 1360
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 Nov 08, 2018 1:51 am

I fixed up the UIManager so that it passes the values into the success callback function. If the user cancels the dialog box, it will gather up the default values for each control and pass those into the callback function. You can still specify a different cancel callback, but if you don't, then it will use the success callback instead. This allows you to only use one callback function if you want to, and that is what is most useful to us for this app.

There are some requirements though. Each control must have a default value. You specify that by calling the value method when creating the control.

Code:

var initRandom = function( factory, ui )
{
   // we can use only the success callback because we have specified a default value on the control
   var success = function( values ) {
      // we can reference the values by their id specified on their control
      var radius = Number( values.radius );
      var count = Number( values.count );
      var particles = initRandomTest( radius, count, factory );
      var particleArray = new PIM.ParticleArray( particles );
      ui.setParticles( particleArray );
   };
   // create a form for user input
   ui.createForm().title( 'Gravity Scenario' ).message( 'Please enter some parameters for the model.' )
      // add a control to specify the radius to position the particles in
      .control().id( 'radius' ).message( 'Radius to place particles' )
         .value( 100 ).min( 10 ).max( 1000 ).step( 10 )
         .add()
      // add a control to specify the number of particles
      .control().id( 'count' ).message( 'Number of particles' )
         .value( 200 ).min( 2 ).max( 500 ).step( 1 )
         .add()
      // add the callback function
      .success( success )
      // show the dialog
      .show();
   return null;
};

Also note that you can specify an id for each control and then use that to reference the value in the parameter passed to the success function. If you don't set the id, it will be valueN where N is a positive integer > 0 and is the index of the control on the form.
avatar
Nevyn
Admin

Posts : 1360
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 Nov 08, 2018 2:11 am

What you might be finding difficult with this new stuff is the idea of a callback function. It takes a little while to get used to the concept.

Javascript is a single-threaded environment. There is mutli-threaded execution going on, but the developer can not control it and knows that their own code will be executed as if it is single-threaded. You can do some things as a result of that and I have made use of them in this app for performance improvements. However, a consequence of that is that the UI can not be updated unless your own code stops execution. There is no way to wait for the user to enter data or perform actions, etc.

So the concept of the callback function was used to allow you to hook into other code. In JS a function is just an object, so we can pass them around and store them and invoke them whenever we want to. Our current case is actually a good example, so we will go with that.

A dialog box is used to present the user with some controls to enter data, perform actions, etc. Ignoring the controls for now, think about just the dialog box. It really has 2 events: success and cancel. The user can press the Ok button or they can press the Cancel button (or escape or various other actions). The dialog box needs to provide a way to let its caller know that the user wants to proceed or cancel.

So the caller registers functions with the dialog box that it wants executed in those situations, or events. The calling code is saying 'Hey, call me back if the user presses Ok.'.

I used to see a function as something that is declared and something that is invoked. The idea of storage was non-existent. The idea of passing them around was totally foreign to me. You passed around objects and objects had functions, but now functions were objects and it took me a while to see the real power in it. Callback functions were probably the first way that helped me through that, but there are others.
avatar
Nevyn
Admin

Posts : 1360
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 Nov 08, 2018 7:59 pm

.

Colliding - Direct UI in mid test. Here, two each, two particle collision sets were entered.

I’ve got the new user input scenario Colliding - Direct UI (Direct, as in ‘head-on’ collision with user interface – ow ) I requested, or well started, anyway. How could I not? You’ve provided plenty of code and guidance to go back to. Thanks.

I’m almost certain I’m learning, and enjoying it too. The idea this program is single threaded is amazing. Never having considered it before, I guess the hook you refer to is a mechanism to allow one to interrupt the program flow, and redirecting it depending on what functions are available from the UI’s ‘dialog box’. My idea of fun. The UI’s main negative I see is another page, the increased time or delay before executing a program requiring what? Cloudflare handshaking. What is that all about?

You mentioned including more Bootstrap UI functionality. Meanwhile I’ll add another UI or two. Oh no, I forgot to check number types, the variables edgeX and edgeY should be integers. I wouldn’t enter erroneous values unless I were testing or mistaken; but who knows what kids will do. Don’t we need a bunch of logical checks?

The bottom of the Scenario’s Gravity group is Random. The next group is Random. Suggest changing the first by adding UI, making it the Gravity Random UI. Or not, just trying to show I pay attention occasionally.

Thanks, plenty to do.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Thu Nov 08, 2018 10:21 pm

Cloudflare is a CDN (Content Delivery Network) and it is being used by this app to retrieve a Bootstrap plugin called popper.js. It is used to dynamically place dropdown menus. While we aren't currently using it, we will be shortly. I noticed that it would slow things down a bit too. We can pull it into our own code base and just serve it with our own JS files if it is a problem. It can also be a problem if your internet connection goes down because it will stop the page from loading.

Yes, you must make sure that the values retrieved from the user are valid and in a state that you can use them. In the gravity scenario, I used the Number function to make sure that they are a number, but I should have actually made sure that they are an integer, which can be done like this:

Code:

var myInt = parseInt( values.radius );

I wasn't thinking about the next scenario group when I made that change. Good call. It should be changed to something else. Maybe 'Randomized'. Feel free to make it something else or change the order of the scenarios, which you do at the top of test.html:

Code:

<script src="js/scenario/proton-stack.js"></script>
<script src="js/scenario/gravity.js"></script>
<script src="js/scenario/random.js"></script>
avatar
Nevyn
Admin

Posts : 1360
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 Nov 09, 2018 9:09 pm

.

I can report some small progress, a second Colliding group scenario with user interface. Here’s a screen shot of Lattice UI, 4 neutrons colliding with a 2 by 2 by 2 proton Lattice.  

Thanks for the parstInt() command - I'd never crossed paths with it before. Googling parstInt() led to Mozilla and GeeksforGeeks, which has a math section I’ve been looking for - I'll go back again. I also gave jQuery a couple of looks, I think I understand what it is a little better. I cannot say I used parstInt() correctly, as my style seems to be more a sort of semi-appropriate crude force. It seems to work.

This business with the UI side-tracked me. There's still some Graphics work to be done. You mentioned post collision spots of some time duration on particles. I hope to be able to demonstrate pre and post collision spin and velocity vectors as additional markers, along with the armillary. Please excuse my enthusiasm.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sat Nov 10, 2018 6:36 pm

.

More progress. The Offset Pair UI.

The scenario shows a collision between two offset particles (1.95 * the particle radius in the Y dimension). I just put a user interface on Colliding, Offset 02. The user can change the spin state of the ‘stationary’ target particle; its spin axis can be X,Y or Z, and its spin speed can vary between -10 to 10 (*Math.PI/2).

The goal here is to show how the program handles offset spin collisions, Offset Pair UI does that very well. We can add orientation. Of course, my programming is less than ideal; nevertheless, this scenario could develop into the full blown spin collision scenario I thought Spin 01 would become.

As is, Offset Pair UI might replace Colliding, Offset 01 and Colliding, Offset 02, but I didn’t want to do so without your approval. Given the two previous, Array and Lattice UIs, I could also eliminate Direct 02 and Direct 03.

I believe you’ve used Offset 02 to work the spin collision problem. With that in mind, I’ll share my impressions of the collision results for 6 number pairs: (spinAxis/+/-spinSpeed); 1,+/-1; 2,+/-1; 3,+/-1. Pre and post spin, for each; left arrow, left arrow again and again.  I’m far from certain, but here’s what I think I see:
1/1 looks ok
1/-1 looks wrong possible backwards y spin?
2/1 looks ok.
2/-1 looks ok.
3/1 looks like too much backward z-spin.
3/-1 looks good.
.

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by LongtimeAirman on Sun Nov 11, 2018 8:46 pm

.

A new Random group scenario, Select UI.

The previous Gravity group’s Scenario with user interface features only neutrons - their number and distribution radius. The new Random scenario Select UI allows the user to specify the: number of particles and their distribution radius; but also the protonRatio; velocityRatio; and orientRatio.  

That bit of thickly occupied space above the UI are pTotal ( len sounds eh ) particles within the distribution radius times math.random for each dX, dY, and dZ. It doesn’t appear very random – more like an artifact when it’s so compact and full.

P.S. Sorry, the UI quantities for the number of particles and distribution doesn't agree with the image shown; I think it was 200 particles, 50:50, in a 100 radius.
.


Last edited by LongtimeAirman on Sun Nov 11, 2018 9:17 pm; edited 2 times in total (Reason for editing : Added P.S.)

LongtimeAirman
Admin

Posts : 1044
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Sun Nov 11, 2018 11:09 pm

I am happy for some scenario menu items to go, once they are replaced with a better alternative or they just aren't needed anymore.

Not so happy with the way you have handled the Spin Axis assignment in the screenshot above, but that is not your fault. I have yet to add support for dropdown lists or radio buttons, which would be the preferred ways to do what you are doing. I have had a look into that, but haven't put much time into it.
avatar
Nevyn
Admin

Posts : 1360
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 Sun Nov 11, 2018 11:12 pm

That is a lot of controls in the Random scenario UI, if we need any more than that on the one form, then I might look in to allowing tabs to be used in these forms.
avatar
Nevyn
Admin

Posts : 1360
Join date : 2014-09-11

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

Back to top Go down

Re: Possible Charged Particle Field

Post by Nevyn on Mon Nov 12, 2018 6:14 pm

I will also look into adding support for sliders.

I think we should have tabs with the first one being a description of the scenario and it will be showing by default. Then we can add other tabs for the user input. It forces a click to get to the controls, but I think it is better to give the user some idea of what they are about to see. The Ok and Cancel buttons will always be displayed, not part of a tab, so the user can always easily select the defaults.
avatar
Nevyn
Admin

Posts : 1360
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 Sponsored content


Sponsored content


Back to top Go down

Page 21 of 23 Previous  1 ... 12 ... 20, 21, 22, 23  Next

Back to top


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