Atomic Model Editor

Page 4 of 7 Previous  1, 2, 3, 4, 5, 6, 7  Next

View previous topic View next topic Go down

Re: Atomic Model Editor

Post by Nevyn on Thu Nov 26, 2015 12:31 am

I like the idea, but am not sure if it will work well. I will have to play with it to see what I can do. In my desktop application, I could actually load every element in the periodic table configuration. It was a lot for the system to handle and things slowed down a bit (mainly because of how I had implemented the animations) but it did load (this is when I started looking into Level of Detail stuff).

It was really good to be able to look across the table and see how the elements changed or look down the table to see why they had similar properties. I would like to be able to do a similar thing with AV, but I don't think it is feasible without creating a reduced element representation. That is, instead of creating every proton, neutron and electron, I use ready-made proton stacks which will probably only contain protons, maybe even just their charge field. I need to reduce the amount of stuff to be rendered since there will be around 100 elements on screen at the same time.

So far, AV has focused on a detailed presentation of an atom but I need to think about working the other way as well. I've been thinking about this for some time as I foresee the need for it when I get to molecules but I haven't put any effort into it since I don't need it right now (at least, that was the thought before this discussion). I want a smaller version of an atom that uses less objects to represent itself and hence, uses less system resources to render.

One problem I see with using an image of the atom structure in the periodic table is the images will be the same size, but the elements will not be sized relative to each other since larger elements will be smaller in the image. The larger elements will need to be further away from the camera in order to fit them into the image so they will appear smaller than they are, compared to other elements. I could find the furthest distance I require for the largest element and then use that distance for all elements, but then the small atoms will be tiny. I guess I won't know how well it can be until I get it working.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Fri Nov 27, 2015 5:40 pm

I have updated the periodic table page to support opening AV in a separate window/tab (depends on your browser settings). Unfortunately, I could not get it to open AV after the animations (element zooming in at you) as this caused the browser to show a warning and potentially block it. But if I open the page from the onClick event function directly (not in something I start from that function) then it opens without any trouble.

By default, just clicking an element will open up a new tab and if you go back to PT and click another element, it will load AV into the same tab as before.

However, sometimes you want to compare elements, so you can hold down the CONTROL key as you click and it will open into new tabs which allows as many as you want to be open at the same time.

If you actually want it to open in place of the PT page, hold down the SHIFT key as you click.

I have also fixed the Firefox scrolling issue. The navigation control had code that determined if it was a Firefox event (which uses different properties on the event object) or any other browser. The Firefox specific code was setting a different value which was probably correct at the time that the example code I used (stole?) was written but is now not needed, at least in the latest Firefox version. This stems from the different browsers having different ideas of what a scroll unit is. A scroll unit is the numeric value you get when the user scrolls 1 notch (multiplied by the number of notches they scrolled).
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Fri Nov 27, 2015 5:40 pm

I also tried to fix the missing elements when you go back to PT and it is a bit better, but not perfect.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Cr6 on Sun Nov 29, 2015 9:48 pm

Looks good Nevyn. I've noticed the performance has improved as well on my system.

Cr6
Admin

Posts : 655
Join date : 2014-08-09

View user profile http://milesmathis.the-talk.net

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Sun Dec 06, 2015 1:13 am

I have updated a few things in AV today. I made some small changes to the element selection dialog box. While it is still virtually the same, I have changed the coloring and the text on each tab so that they fit across the screen in a single row.

I found a bug in the placement of attached proton stacks. The attached stacks were closer to its owner stack than what the pillars are to the core stack. This was obvious if you looked at the Test Model -> Attachments structure and turned on all charge particles. The intake charge locations show that the attached stacks do not line up with the pillar stacks. Now they do.

This was not really a problem as no atoms have any attachments on the carousel level but I wanted to fix in regardless.

In looking through that bug, I realised that I had removed the control to explode the element (add space in between all stacks). That was not intentional, or at least I can't think of any reason why I would remove it, so I have put it back in.

As I was looking over some models, I realised that I really missed the rotation of the carousel level. While I do have the ambient charge field controls to make it spin, they also spin the north/south arms and that gets a bit distracting. So I added 2 new controls to apply a basic carousel rotation and its rotation rate. These can be found in 'Effects Settings' -> 'Carousel'.

You will find a new action in the 'View Settings' menu to capture a screen shot. You can also press 'p' to take it. It will send the image to the server and then bounce it back to you to save on your local file system. That is a real waste of time and resources so I will find a way to do this client side eventually. The last time I tried to do something like that it failed in IE and killed the whole app.

As a side project, I have started to create a database to contain the element data. Since I already have a relational database at my disposal, I have used that instead of a JSON friendly DB like Mongo. I am more comfortable in that anyway so I can get moving much faster.

In doing so I have decided to make a step back towards my older models in the desktop version of AV. The difference between the two is that the old models were based on placing entities where you wanted them where as the new models are based on defining the element structure and the code takes care of placing things for you. The old model knows nothing of the element structure but the new model is completely reliant on it or to be even more precise, it is reliant on the code that interprets it. Both ways have their strengths and weaknesses.

This came about because I was looking at some of the early nuclear papers of Miles and discovered that my model of Beryllium was wrong. Worse than that, there was no way for me to model it the correct way. I could get very close, but I could not put all of the neutrons in the required places since it has a single neutron in between 2 protons in a stack and I have only allowed for pairs in the code.

Upon this discovery, I saw the strength of the old model and the weakness of the new, to handle edge cases. Any strange requirement can be handled when you can put anything wherever you want it but it is not always easy or convenient to do so in the code.

So, I am now moving towards a middle ground that I think will work well. It will give the 'put it anywhere' strength of the old model to the 'let the code place it' strength of the new. I know, that sounds like a contradiction but I assure you, it is not because the two statements do not apply to the same thing.

I keep most of the structure that you know from the Element JSON definition, all the way down to the proton stacks. The stacks themselves will now be selected from a table that contains all possible proton stacks. That table allows you to create a stack using the 'put it where you want it' approach. Instead of just being a count of protons, neutrons and electrons in the stack, it now becomes a 3D model so that I can handle special cases with ease while still letting the code arrange the stacks.

I don't know how this will look in JSON just yet. Obviously most of the structure remains intact but the proton stacks will be a lot more complicated. I haven't finished the data model yet and I can't write any code for it until I do. I need to know that it will work before I get to that although I may write some in order to test it.

I am also thinking that I will load the element definitions as needed, rather than the current method of loading them all when you open the webpage. When the user clicks on an element to load it, I will make an AJAX call to the server to get the JSON for that element. I will use some sort of caching system to reduce server calls and also a loading system so that you can click the button multiple times and it will only load the element once and then put it into the scene however many times you pressed. I don't know if you guys do that much but I do it to stress test the app by loading lots of models into the scene.

Well, that's where I am at. Not making as much progress as I need to but still getting somewhere.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Sun Dec 06, 2015 10:45 am

Thanks for the report Nevyn. All aspects. What I could understand anyway.

I see the carousal change directions between charge field enabled, and carousal rotate enabled. Since you've described the carousal rotation as the sum of upper and lower sections’ rotations - reflecting the rate of recycling photons and antiphotons, the component spins are thereby related, and charge field enabled must be the correct rotation. Why complicate things with independent spins?

You have surpassed modeling every element. Do you see AV as a constructor set, to build larger nuclear structures?
.

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Sun Dec 06, 2015 6:06 pm

Well, sometimes, you are just there to study the model structure and the ambient field based rotations can hinder that because so much is moving. I also do not know if that is the correct way to apply the ambient field forces to the element, it was just a hunch and so I tested the idea through the code. But, ultimately, I spent a lot of years working in the desktop version which applied the basic carousel rotation by default and I am very used to seeing it do so. I originally thought that I didn't really need it because the user can move around the scene a lot easier than in the desktop version so it was easier to rotate the element a bit to see into the core.

Yes, I've always seen AV as a tool to build elements and, later, molecules and I tried to do that in the easiest way I could see at the time. I was explicitly trying to avoid the old model and make it very easy to define an element. I succeeded in that, too, but I didn't foresee some of the trickier cases that are not so easy to handle in the code without explicit instructions on where to place things. Saying that a stack has 5 neutrons is just not enough for some cases, I need to know where they must go.

So working both models together seemed like a good way to go. I can get the best of both worlds. It does move it closer to a construction set type of build system, but I don't mind that. I will try to use both ways of defining an element. The user will be able to just specify the proton, neutron and electron counts per stack and it will pick an appropriate proton stack for it. But when they need something special, they can go further in and select from a list of stacks. I'll have some sort of filtering system when presenting the list of stacks so the user can enter in the number of entities and the system will only show the stacks that fit that description.

But all of that is a fair way off, at the moment. I am thinking towards the future but still focused on getting it ready as a viewer. I thought it wasn't a very good start if I can't model the 4th element in the periodic table, though. This new element model will not be ready for version 1.0 and I may have a go at trying to do it in the code but I was never happy with that particular bit of code anyway. It was always too specific but it handles most cases fairly well.

I will probably move the new rotation controls up into the same area that the ambient field controls are in. All of the settings need to be rearranged into a more coherent structure so it may all change at some point in the near future.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Thu Jan 07, 2016 12:21 am

I have been reading some old papers again (trying to get myself into the right mood to work on AV again) and found something that, I think, provides support for my 'ambient charge field' rotations in AV. I have said before that I don't know for certain that the north and south axis arms would spin (as a result of the charge flowing through them) but when reading the Period 4 paper I found this little bit of evidence that they do:

Miles Mathis wrote:
Since those “inner” protons are now pushed off the axis, they no longer add to the density as before.
Like additions to the carousel level, they now subtract from density. Being off the axis, they are now
spinning with the carousel, and they act like it in many ways. The primary way they act like the
carousel level is that they feel a centrifugal effect from the nuclear spin, and the more protons you have
in positions like that, the more centrifugal effect. This is why the density goes down for Selenium and
Bromine.

You will have to read the paper again to understand what Miles is talking about. There is an image of Bromine above that paragraph which shows the protons plugged into the pillar level and they are set quite a distance from the pillar stacks (rather than joined like I have them in AV). The important part is that these inner proton stacks rotate with the carousel level. I have them actually rotating with the axis arm and Miles does not mention that in any way but I also have the carousel rotating because of the axis arms so, in a way, it ends up in almost the same place.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Thu Jan 07, 2016 12:28 am

I just thought of something else in relation to the charge field rotations I have implemented. I had assumed that the north and south axis arms would spin opposite directions from each other since they have opposite charge flowing through them. However, photons and anti-photons only spin opposite ways when they are travelling in the same direction. When meeting head-on, like this, they are actually spinning in the same direction. This would cause the whole atom to spin in the same direction, but not as a whole.

To clarify that last statement, the axis arms would both spin in the same direction and the carousel level would also spin in that same direction so it is not the whole atom spinning but its parts.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Thu Jan 07, 2016 7:10 pm

I'm not sure if it was in this thread or another where I have said that nuclear and molecular bonds are different distances but I have found one of Miles papers that mentions this. Here is the quote:

Miles Mathis wrote:
Because the axial level is a stronger charge channel than the carousel level—for the reasons just
enumerated—the axial bond will actually be shorter. A stronger channel creates a tighter fit, which is a
shorter bond length.

It doesn't explicitly compare nuclear and molecular bonds, in fact it is comparing different molecular bonds, but we know that nuclear bonds (protons within the atom) are stronger than molecular bonds so I think it is applicable.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Cr6 on Fri Jan 08, 2016 2:51 am

Found this as well.  Isn't bond length on the southern Axial "shorter" due to stronger charge flows?
---------
http://milesmathis.com/orbiton.pdf

Mathis wrote:Nothing in my model is determined by math or ad hoc theory. It is determined by logic and mechanics. It is determined by what is necessary to physically channel the charge field through the nucleus.

You will say, “That is charge, but what you are plugging into these positions is protons, not charge.” But all charged particles follow charge. That is what “charged particle” means. Protons, like electrons, are physically pushed by the charge wind. They go where charge pushes them, because charge pushes them. Both their linear motions and spins come straight from charge. Spinning photons cause charged particles to spin, and moving photons cause charged particles to move. If we go back to Argon, without the top and bottom protons, we find charge whistling through the axial level of that nucleus. It also gets partially diverted by pull from the carousel level, and much charge is channeled that way, too. But the main line is axial. So when the ambient charge field passes Argon, it gets channeled first through the axial level. And if free protons are available (as in stars), as well as pressure to force a tight and permanent fit, the protons will follow the pre-existing charge channels and go to the axial level as well. That is how we build Calcium and other period 4 elements from Argon.

This explains the longer axial bonds of Cu-O in a natural way. It isn't that the bonds are longer, it is that the nucleus of Copper is actually taller than it is wide. You will say, “That isn't borne out by the numbers, which are not in a 10 to 7 ratio. According to you, the axial length here should be about 10/7th of 195, which is 279, not 238.” Good point, but easily answerable with straight mechanics. Because the axial level is a stronger charge channel than the carousel level—for the reasons just enumerated—the axial bond will actually be shorter. A stronger channel creates a tighter fit, which is a shorter bond length. We would expect this to also be in a 10 to 7 ratio, for the same reason, but this time the axial number should be 7 and the carousel number should be 10, to represent the shorter axial bond length relative to the longer overall axial length. All we need now to solve is the percentage that goes to each cause of length. Is the length of the nucleus more important or is the length of the bond more important? That is also easy to calculate, since we can take it straight from the diagram. If we let the length of the bonding proton stand for the bond length, then the bond length is just 1/10thof the total axial length. This gives us the simple equation:

[(10/7)(9/10)] – [(7/10)(1/10)] ≈ 1.216

If we multiply that by 195, we get 237. I needed to match 238, so you can see that I have confirmed the data with extremely simple mechanics and math. And I have proved that nuclear mechanics can explain bond differences, with no need for electron degeneracy.

Cr6
Admin

Posts : 655
Join date : 2014-08-09

View user profile http://milesmathis.the-talk.net

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Wed Jun 15, 2016 1:32 am

I've finally started working on AV again!

I started to write some documentation pages to explain the app and how to use it and was struggling with it. So I thought I would start by writing some pages to describe the more firm things such as the controls and actions that can be performed. However, I ran into a problem very quickly: I want to change the layout of all of those controls. No point writing documentation now if I am going to have to change it in a few weeks.

I was having a look around the code and some of the database stuff I had started to figure out the last time I worked on it and remembered that I was going to change the element definitions to support a more modeled approach (see a few posts above this one). After a bit of figuring out what I was planning to do, I continued on with the database definitions to create some tables to support the element data.

I soon realised that I needed some data to go into it, so I wrote a program (in Java) that read in my old models from the desktop version of AV and inserted them into the database. At first, I only wanted to insert the proton stacks but I soon started to think about inserting complete models. I didn't think this was going to be very easy, in fact I thought it would be bloody hard because there is no clear idea of where things are, but I found a way to determine which proton stacks were which through various sorting and testing methods. I then implemented a PHP script to read it out of the database and return the data to the AV web app.

Now I needed a way to test it, which meant changing the AV code to support the modeled proton stacks. I looked over the AV code and realised how much I have learnt since writing that (only last year) and I really wanted to change how it was written. While the existing code worked, it was a bit inefficient. I had defined my objects through what are called 'mixins' but I wanted to change it to use 'prototypes' instead. Mixins are great for some tasks but they are inefficient because they operate on objects instead of classes. This means that if a mixin wants to add a function, then the function is created for each object. Prototypes, on the other hand, allow you to define them once, per class, and then they are used by any objects that are instances of that class (a class is like the definition of an object which you then use to create objects of that type, Javascript doesn't really have classes but you can still do the same job in other ways).

I was a bit nervous since I hadn't been inside this code for some time and it is really good to understand how everything fits together before making serious changes like I was about to. So I took it slowly. I picked one area and converted it into a class, saved it and tested it in the browser. Then I would move on to the next one. I made it all the way through the classes I wanted to define, there were a couple that I left as mixins because it was easier and they didn't fit into the class hierarchy, and everything worked with no problems, not one. I was feeling quite proud of myself until it all came crashing down on me.

You see, I had forgotten about one little detail. One itsy, bitsy thing that meant all was not as it seemed.

At some point in the development of AV, probably as I was setting up my own server and started to think about download limits and system resources, I had added in the ability to minimise the code before it is deployed so that the file sizes were smaller and therefore  less to download, less system resources used, etc. The problem was, I had not been running this minification process during my changes which meant that I had not tested a single thing! My heart sank and I thought I would be in all sorts of trouble if there were problems. I had explicitly tested it after each small change so that if there was a problem, I would know where to look for the solution. Now, I had the complete set of changes, untested, and if there were bugs, and there were, then it would be harder to find where the problem was.

It took me most of the next day to track down the bugs and fix them. Most of that wasn't a result of my class changes but with the new code to support modeled proton stacks. The core and carousel level would show correctly, but the pillar, cap and hook levels did not. I spent hours trawling through the code with nothing making a difference. Finally, I spotted a piece of code (as I was scrolling by, not really looking for it) that sparked an idea in my head. Some parts of the code made use of the element definition to make decisions about how to handle their stacks (by looking at surrounding stacks). All of that was broken because the modeled stacks did not have the same structure as the old definition (which had counts of the protons, neutrons and electrons).

As a quick solution to see if this was the problem, I just changed the new definition to contain the proton, neutron and electron counts, just like the old one and everything worked again. I have left that in as it is a nice fallback since it means that the old method of defining stacks can work with the new definition as I didn't remove the existing way it builds elements, I just allowed the new modeled stacks to be supported if they were encountered while leaving the existing code to support the current models.

I had a few other issues that took a lot of time to track down. The main one was a problem with the modeled element definitions where they would have extra neutrons attached to things that they should not be attached to. This turned out to be caused by me trying to be smart. I was generating element definitions that did not contain the proton stack definitions and only specified the Id of the stack to use. The idea was that I would only load stacks that I needed and cache them so that the client did not need to go back to the server all the time. What I didn't realise is that those stacks are altered as they are processed and objects are added to them for attached stacks or neutrons, etc. So, basically, if any instance of a given stack was altered to have an attached neutron, for example, then everywhere else that same stack was used now had a neutron attached.

I tried to fix this by copying the stacks as they are added to elements but there were still some weird problems so I added a way to retrieve the complete element definition from the database so no stack sharing was possible. This fixed the issues and I moved on to the next problem. Charge particles.

All of those lovely charge streams I had created just didn't look like they were going to fit the modeled approach. The main problem was that I had no idea of what pieces were where. Which proton is the top and which is the bottom? There was no data to tell me so I just had to find them myself, which turned out to be easier than I expected. In fact, I actually prefer the new way of doing this so much that I am thinking about using it for both modeled and defined stacks. I don't like having the same code implemented twice as it means both need to be kept up-to-date and I need to make sure that both produce the same result, which is not always easy.

In the end, I got the charge streams working with either modeled or defined stacks and both looking the same. Since I was already in there, I noticed a few things that I had started but not fully implemented so I went through and made use of them. This was mainly around proton stack input charge streams which I had planned to disable on a given stack if there was another proton, or stack, feeding it at that location. For example, the core stack does not need input streams if there are pillar stacks and a pillar stack doesn't need an input stream where it meets the core but will need one if there is no hook stack.

I have extended the database to support periodic tables which will allow me to integrate them into AV a bit easier. I wanted a way to create all of my existing element definitions in the database. While I did create the Java tool to load in my old models, once I added support for both modeled and defined stacks in the DB I wanted to get the defined elements in there and then only use modeled stacks where they are required. After a bit of thinking about how to do that, I realised that I already had them in AV so why not just add a new button to save them to the database. I wrote some PHP to insert/update elements and spent a bit of time debugging all of that and ended up with being able to save the elements in any periodic table from AV. This led to a more formal definition of a periodic table which I now have to incorporate into the AV code base.

I still need to fully implement a database backend and will probably look into that over the next few days. I'll have a go at caching the elements and will probably try to find out why the cached stacks aren't working as I expect them to as well. After that I need to re-arrange the controls so they have a more coherent structure and naming scheme. Then it is back to the documentation or maybe I can find another idea to distract me from that again.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Wed Jun 15, 2016 1:21 pm

Hi Nevyn, Good. I reviewed the AV http://www.nevyns-lab.com/science/physics/AtomicWebViewer/AtomicViewer.php earlier this week. I'll try to throw a distraction at you.

Why don't we see electrons at the poles?
How about counter-rotation in the smaller elements?
How about isotopes?
In HOW THE ELEMENTS ARE BUILT Miles references an Argon AVI file. Did Miles comment on the spins (or lack thereof)?
Did you ever make Argon40?

I don't ever recall seeing neutrons in pole positions. Rb shows individual neutrons in cap positions. Miles said there are also neutron pairs in the cap positions.

Please see another example of the three.js periodic table solution at http://graphoverflow.com/graphs/3d-periodic-table.html
3D PERIODIC TABLE by Sarath Saleem.
Note the explore atom option showing a Bohr model.
.

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Thu Jun 16, 2016 12:56 am

Hi Airman,

LongtimeAirman wrote:Why don't we see electrons at the poles?

As I was working on it earlier in the week, specifically on the charge streams and getting them working again under a modeled stack, I looked at those electrons and thought about moving them into the correct position. I will definitely have a go at it soon.

My understanding is that the electrons should be on the outside of the stack. Very close to the red sphere that is the actual proton and circling about it.

LongtimeAirman wrote:How about counter-rotation in the smaller elements?

What do you mean by that, Airman? The only counter-rotation I have implemented is in opposite arms. That is, the electrons and neutrons in the east arm of the carousel rotates the opposite way to the west arm or the north arm rotates opposite to the south in the axis arms. As smaller elements don't have any arms (except the pillars and maybe the caps), there isn't much need for it. Maybe if you explain it a bit deeper I will see what you mean.

LongtimeAirman wrote:How about isotopes?

Yes, I have isotopes in my old models and I have allowed for it in the database tables (and allotropes) but AV itself doesn't handle them at the moment. I'm still not sure how to deal with them. Probably by presenting another dialog box when you select an element to insert into the scene that will give you the option to select from the available isotopes. Or maybe I could have a dropdown menu item that allows you to select the isotope of the selected element, but this is problematic when you have more than 1 element on screen. Maybe just have a button in the controls that presents a dialog box with the available isotopes. I'll probably start with something basic and work from there.

Isotopes are actually very important. I spent a lot of time working on different isotopes of various elements in my old models. They allow you to see the ways that the neutrons can be arranged. This is another area that I tentatively disagree with Miles. He likes to put the neutrons into blocking positions and that does work well and I don't have any argument against that. But what I found was that I could play with the number of neutrons in the more central stacks in order to find the various isotopes.

For example, if we had an element that had all 9 central stacks (core, pillars, caps and carousel) and each stack has 6 protons in it, then it is possible to alter the number of neutrons in those stacks to get isotopes. Each stack might start with 6 neutrons and this gives us the highest isotope. If the next isotope down removed 2 neutrons, then you could just remove 2 from the core stack. I start with the core and work my way out because the core and pillars are more protected so they could survive with less neutrons.

However, there were some elements that did involve the blocking positions so it may be that there is a happy mixture of mine and Miles approach. Of course, Miles has spent more time looking at the properties of the elements he has modeled. I did that for some but, in the interest of expediency, I started to build models by trying to figure out where another proton could be added to the last element. I would look at the element above it in the periodic table to find common properties and use its configuration as a guide. Then I would look at the isotopes to see if that worked. If not, then I would find another way to arrange the element with the given number of protons and see if that matched the isotopes. The isotopes were always my go-to test. If I could match the isotopes then I was happy enough to move on to the next element.

LongtimeAirman wrote:In HOW THE ELEMENTS ARE BUILT Miles references an Argon AVI file. Did Miles comment on the spins (or lack thereof)?
Did you ever make Argon40?

No, Miles didn't comment on the lack of spins, we were more concerned with element structure and neutron placement.

Yes, I made Argon-40, in fact, I made every model that Miles published and many others he has not. Most models had the main isotopes for it and the larger the model the more isotopes I created because they are important to figure out the element structure. Once you get above the 2nd period, nearly every element has 4 or 5 isotopes.

LongtimeAirman wrote:I don't ever recall seeing neutrons in pole positions. Rb shows individual neutrons in cap positions. Miles said there are also neutron pairs in the cap positions.

I just looked over Miles paper on How to Build the Elements to see his Rb model and it is quite different to mine in AV. I don't have access to my old models at the moment so I don't know if I got it right in that one or not. Either way, AV can support that element, it just needs to be defined correctly. I'll look into fixing that soon, thanks for pointing it out. The way Miles has made the green neutrons to mean doubles and the yellow neutron to mean a single is a bit confusing with respect to all of his other papers. Does green always mean 2 neutrons? I believe that is the only time he has had to differentiate them and I have always assumed that a green neutron was a single particle. I may have to go back over the papers to figure that out.

Strictly speaking, as I like to, those neutrons are not in cap positions. They are in hook positions. If you wanted to, you could say they are attached to the cap stack but I think that is a little confusing. With the way AV is implemented, it is correct to say they are hook positions as that is how you would have to define it. The cap stacks do not have attachments.

The rules are:
 If axis arm:
   odd numbered stacks can have attachments
 If carousel arm:
   even numbered stacks can have attachments
Where the stacks are numbered, for a given arm, in order of increasing distance from the core stack. So a pillar stack is number 1, cap 2, hook 3 and the first carousel stack is 1 and a hook would be 2 for a carousel arm.

LongtimeAirman wrote:Please see another example of the three.js periodic table solution at http://graphoverflow.com/graphs/3d-periodic-table.html
3D PERIODIC TABLE by Sarath Saleem.
Note the explore atom option showing a Bohr model.

Not bad, but I prefer mine (which I stole from the ThreeJS examples, so I can't really claim it as mine). The Bohr model is useless. It would be better not to show that garbage (and pretty much everything else he published). They are making the electron 'orbit' but not in the correct ways (but does point that out, so credit for that, and it would not be easy to model the orbits since they are flagrantly non-mechanical) and why do the electrons orbit faster the further out they are from the nucleus? However, the interface itself is well setup and looks quite professional (most of that interface was stolen from the same ThreeJS example).

It is interesting to look at the bohr models and compare them to Miles models. You can actually get information from Miles models but you get nothing at all from the bohr models. A bohr model can only remind you of what you already know but a Mathis model can truly tell you things about the element.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Thu Jun 16, 2016 1:55 am

I just had a thought about isotopes. I have always thought of them as separate models for the same element but when I created isotopes in my old models, I would create the element with the lowest number of neutrons first, then load that in for the next model and just define the extra neutrons. This meant that changes to the element itself, not involving the isotope neutrons, were only made in one place and filtered through to the isotopes.

This is not quite that easy in the new models but what I could do is introduce a new property on a stack called 'isotope' which is a number. Stacks with the number 1 (or no isotope property) will always be used, stacks with a number 2 would only show if we are looking at isotope 2 and so on and so on.

I don't think this will work in all cases though. Sometimes, the isotopes do not progress like that and you need to make more drastic changes, but it would handle a lot of elements. It also pollutes the element definition and makes it difficult to see exactly what it contains.

It may just be easier to define the whole element again for each isotope. This is a lot easier in the new models compared to the old ones.

Mmmm, requires more thought.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Thu Jun 16, 2016 10:42 pm

Nevyn,
Nevyn wrote:My understanding is that the electrons should be on the outside of the stack. Very close to the red sphere that is the actual proton and circling about it.
Electrons should be outside the “stack”? Don’t you mean to say electrons should be outside the alphas? Not within the alphas as the AV currently shows?

The stacks can be 6 protons deep. If neutrons can fit between stack protons, so can electrons. If you say electrons and neutrons cannot share the space, OK, … .
LongtimeAirman wrote:How about counter-rotation in the smaller elements?
Nevyn wrote:What do you mean by that, Airman?
Sorry, I’m spin happy. All particles spin all the time; you’ve modeled protons as discs to highlight their spins. Protons spin much faster than the atom can - that is if the atom is free to rotate, and is not part of a larger charge structure. Even the two protons in a single alpha have different spins, likely counter rotating to reflect the ambient matter to anti-matter ratio - as you’ve modeled with counter-rotating pillar stacks. Random impacts vary that equilibrium. Of course your model can’t actually show all that, but that’s how I've learned to see it. Still, I never realised your carousal arms were also counter-rotating.  

Isotopes. Thanks for the rundown. I suppose you confirmed your various choices by comparing/interpreting the energy values (MeV) of each isotope to each element. I admire your patience. If the element is determined strictly by the number of protons, and isotope by the number of neutrons, it seems multiple forms (allotropes?) of an element and/or isotope are possible.

Allotropes (I did have to look it up). I thought that AV was created to view individual atoms. It’s another thing entirely to view alternate atomic lattice forms; and then another to channel charge flows through those structures. Do you think you’ll create a charged flow construction simulator too? I’ve been spending more and more time thinking of charge flows within and between larger charge structures.

Thanks for pointing out the correct position names and hook attachment rules. I'm still learning.

Yes, this latest periodic table is professional, but no surprise. The bohr model with a quivering nucleus and well-ordered electrons is silly. Are mainstreamers retreating to the bohr model? Just wondering.
.

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Sat Jun 18, 2016 10:30 pm

LongtimeAirman wrote:
Electrons should be outside the “stack”? Don’t you mean to say electrons should be outside the alphas? Not within the alphas as the AV currently shows?

No, I meant the full proton stack but your point is valid. It is probably alphas that I should be thinking about, which is actually how I have modeled it at the moment (not updated on site yet). I have changed the electron placements so that they are above and below each pair of protons. So the neutrons are on the inside of the alpha and the electrons are now on the outside and close to the actual protons. They circle around the through-charge streams. Techically, they should be inside of those charge streams because that is what is pushing them into the proton but they would be hard to see in there so I am happy with them being a little bit further out from the center.

LongtimeAirman wrote:The stacks can be 6 protons deep. If neutrons can fit between stack protons, so can electrons. If you say electrons and neutrons cannot share the space, OK, … .

Yes, the electrons can fit inside of the alpha or anywhere inside of the stack but the question is can they get inside there after the alpha or stack has formed? Miles states that the electron can not fit through the hole in the proton (where through charge goes) and I doubt they could come in from the sides (where the proton equatorial emission is strongest).

If they could get inside of the alpha/stack, even before it forms, would it be possible to get them out again? The only charge that could affect them is through-charge and that is already present. Maybe a stronger through-charge stream could push them out a little bit and then the equatorial emission of the protons takes care of forcing it all the way out.

LongtimeAirman wrote:Sorry, I’m spin happy. All particles spin all the time; you’ve modeled protons as discs to highlight their spins. Protons spin much faster than the atom can - that is if the atom is free to rotate, and is not part of a larger charge structure. Even the two protons in a single alpha have different spins, likely counter rotating to reflect the ambient matter to anti-matter ratio - as you’ve modeled with counter-rotating pillar stacks. Random impacts vary that equilibrium. Of course your model can’t actually show all that, but that’s how I've learned to see it. Still, I never realised your carousal arms were also counter-rotating.

The counter-rotation in the arms, whether carousel or axial, is more obvious when you turn on neutron rotation. You can see it with the electrons too but, being so small and so far inside the stack, they are harder to see.

The other night I had an idea pop into my head as I was playing with the electron positions. Now that they are circling so much closer to the through-charge stream, it occurred to me that the through-charge stream could spin. So I put the charge stream into the group for electrons (in my ThreeJS objects), which was already being spun so it was a quick way to see how it looked, and it did look good. I set about creating a group for the through-charge streams so that I could spin them at their own rate, separate from the electrons, when I realised that not all of the through-charge streams are along the axis of the stack. Worse than that, I would need to create 2 streams per dimension and each of them would need to spin the opposite way to each other (have a look at the core stack in a large element, silver is a good example, with through-charge turned on to see what I mean here). While it is easy enough to do all of that, rotating 6 things in different ways, per proton stack, is a lot of computation to be done every frame. But I wanted it, so I started to implement it. I could always create a control to turn it off for performance.

However, I quickly realised that the concept was wrong. The charge stream does not spin, each individual charge photon spins, giving the stream a magnetic property. I almost implemented it anyway, because it looked pretty cool, but I talked myself out of it because I didn't want to give anyone the wrong idea of what is going on inside of an atom.

LongtimeAirman wrote:Isotopes. Thanks for the rundown. I suppose you confirmed your various choices by comparing/interpreting the energy values (MeV) of each isotope to each element. I admire your patience. If the element is determined strictly by the number of protons, and isotope by the number of neutrons, it seems multiple forms (allotropes?) of an element and/or isotope are possible.

No, I didn't go as far as calculating energy levels. I'm not even sure how to calculate that data from Miles models, but I am very interested to do it. All I did was look at what isotopes a given element could have, that is, what we find in nature and what we can create. I also looked at the half-life for each isotope which can indicate an imbalance to the structure when it has a short half-life.

You find that elements tend to add neutrons in certain ways. If an element can have 2, 4 or 6 extra neutrons then you know to look for pairs of neutrons so it might mean a particular stack can either have or not have a couple of neutrons or it might mean I can take 2 neutrons each from the core and pillar stacks or it needs to block pairs of holes to maintain balance.

If an element can have 1, 2 or 5 extra neutrons, then you look for reasons why 3 and 4 don't work and you often find it. Without too much trouble, you see why you can only add 1, 2 and 5 neutrons, never 3 and 4. The element tells you all of this, once you know how to listen to it. And that just takes time invested in working with them. I didn't have much choice. I wanted to model as many elements as I could and it helped to push the development of the original desktop AV but I am really glad I did it.

I think it is worth the effort to build your own periodic table, in AV which is not quite ready for that but I will attend to it shortly, if you want to really learn Mathis Chemistry (Mathistry?). Go over the papers and build the elements defined in them. Then try to fill in the gaps. Build the models Miles hasn't yet, going over the papers to find reasons why it might be built in certain ways. Go through the wiki pages for the element to see what its properties are, what isotopes it has and think about how you could implement that.

This has given me an idea to create an app focused on periodic table building. It could have a side panel that allows you to view Miles papers as you build the element. Ambitious, but possible. I could even create some sort of game where you build elements and are somehow able to use them so that the user learns basic Chemistry while learning how to build elements, Mathis style. Even more ambitious but I like the ideas.

LongtimeAirman wrote:Allotropes (I did have to look it up). I thought that AV was created to view individual atoms. It’s another thing entirely to view alternate atomic lattice forms; and then another to channel charge flows through those structures.

An allotrope is an alternate form or structure of an element. Nothing to do with a lattice which is multiple atoms bonded together. Allotropes can have very different properties to any other allotropes of a given element. Phosphorous is a perfect example. Have a look at the wiki page for it. The allotropes are quite different from each other and it makes it very difficult to model. I have discussed it with Miles and he recognizes the problem but I haven't seen a paper about it yet.

So, given that definition of an allotrope, AV absolutely must support them. I have provided a way to mark an element as an allotrope but I have no idea of how I am going to handle it in the interface. Up till now, AV has been, primarily, focused on a single atomic model. You can add many more to the scene but it is best with just one. Now I am working on larger concepts, like periodic tables, and how to make AV support those concepts. Isotopes and allotropes naturally come along with that so I need to figure out how to handle it soon. I might create a set of buttons on the side or bottom of the screen that allow you to quickly change which isotope or allotrope you are looking at. If multiple atoms in the scene, then it will require one to be selected.

It would probably make my life a bit easier if I limited AV to a single model at a time. Sometimes I like to compare models so I load in a few, but you could accomplish that with multiple browser tabs/windows. What do you guys think? Would it be ok to only have a single model in the scene?

LongtimeAirman wrote:Do you think you’ll create a charged flow construction simulator too? I’ve been spending more and more time thinking of charge flows within and between larger charge structures.

That is awesome that you are thinking like that. That's what it is all about. The charge flows are everything and the protons, neutrons and electrons are just what allow them to be created and manipulated. Working with molecules helps with thinking about charge flows so I recommend picking some area you want to know about, hydrocarbons, acids and bases, oxidation, etc, and read the wiki pages, look at the atoms in AV. Think about how you could join those atoms together, what charge flows could be created, where would it be weak or strong.

Do I want to build a charged flow construction simulator? I think I do! I'm not sure if your idea matches up with mine but I've been thinking about a simulator like that for a long time. Way before I ever started on AV, web or desktop version. I want a true physics model. That is why I have stuck with Miles for so long, he is the only one (I have found) that is being mechanical and allowed me to see how I could implement such a simulator. AV and SpinSim are stepping stones along that path.

More specifically though, I've thought about a chemistry simulator where you put elements and molecules together, set the ambient charge field settings and see what happens. In fact, only yesterday, my mind put two ideas together that could lead to such an app. I started to flesh out some code but it got complicated pretty quickly. I'll work on it at times, but my focus is AV at the moment.

LongtimeAirman wrote:Thanks for pointing out the correct position names and hook attachment rules. I'm still learning.

I know I can be pedantic at times, but I really believe that most problems come down to communication. So finding the right language is critical. All parties understanding that language in the same way is even more critical because it so rarely happens. The internet was created to fix that very problem. The US Army, Navy and Air-force all had their own network systems and none of them could talk to each other but they were suddenly mandated to do so. Now nearly every device on the planet can talk to other devices even though they are completely different hardware and operating systems.

I'll give you a more concrete example of how language causes problems in software development. A client asks a developer to build them a system. We ask them what it is they want it to do and how it should do it, in conceptual terms, not technical. During this process the developer may notice something that doesn't sound quite right and they will ask for clarification and ensure that such a thing can not happen because it seems to them that it should. The client will respond with 'No, that can never happen.'.

The experienced developer will respond with 'Never?' and the client will insist that it can never happen. I've even heard the words 'Never, ever' which is a definite, unambiguous statement. So we go away and start designing a system and we check with the client that this is what they need and explain certain problems we might foresee. The client agrees and we start building it.

At some point, the client will suddenly realise that they do need to do such a thing, every now-and-again. This will usually be within a month or two of release when the architecture is pretty much concrete and we've designed it knowing that it would not need that feature and we may have taken advantage of that in some way. This is how great systems turn into garbage.

You see, people can't even get their native tongue correct when it really matters and lots of dollars are on the line. Take notice of exactly what people say to you or around you over a day and see how much of it actually means exactly what the words mean. Obvious words are 'never' or 'literally', which are literally almost never used correctly in common language. We all use nuance and context to some degree but I guarantee that at least one statement, if not many more, will actually mean the exact opposite of the words said. So, when talking about the fundamentals of the universe, language is even more important.

LongtimeAirman wrote:Yes, this latest periodic table is professional, but no surprise. The bohr model with a quivering nucleus and well-ordered electrons is silly. Are mainstreamers retreating to the bohr model? Just wondering.
.

It's not so much that the mainstream are retreating to the bohr model and more that they have nothing else. No-one even wants one anymore, they are happy rolling around in their math. At least Bohr felt that he should try to come up with a model, make an attempt at being physical but they just don't seem to care anymore. It's a shame, really.

(Sorry for the wall-of-text, you've caught me on a lazy sunday morning)
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Sat Jun 25, 2016 2:51 pm

Hi, Nevyn,
I hope you don’t mind the diagram. I’m not sure what I’m aiming for.

I agree we need to identify essential electrons – especially when there aren’t any available in the ambient charge field.  I find it hard to believe any exposed electrons belonging to solitary atoms are stable in any but the most benign conditions.

a. Electrons within the alpha may have increased stability, especially in increasd ambient charge conditions, but your point that electrons must be available for atom/atom interactions is a good one. Still, when alpha example a. occurs, both particles must be the same (electrons or positrons). In an atomic lattice I would expect a wide range of ambient conditions that allow electrons to tuck themselves into convenient locations – I’m thinking of free electrons in a conductor where we want as many electrons available as possible.
 
b. Electrons circling the drain, too big to fit, Miles has described it often. Single electrons at both alpha-poles seem to make sense, except they are not both electrons; one is an electron and the other is a  positron. Miles indicated that neutrons within the alpha can re-orient In response to charge flow changes. In an ambient field with both photon and antiphoton charge flows, b. is a stable configuration.

c. An electron pair (as opposed to a positron pair) circling the appropriate alpha-pole is stable if photons outnumber anti-photons and we are dealing with only electrons.

It occurs to me that the true alpha prototype would have not just the possibility of electrons and positrons, but must itself consist of proton and anti-proton.

I had another insight I wanted to share. We have two electrons circling a pole when more electrons arrive; what happens? A pile up of sorts. Electrons cannot travel through the proton axis. Instead, charge pressure forces electrons through  the proton emission planes at some distance from the atomic axis, with characteristics specific to that element and charge flow. Electron flows are separate and significant currents themselves.

AV Comment. How do you turn on the alpha (He) main pole-to-pole through charge?  

AV Comment. My mouse wheel is giving me fits. How can I zoom into an image without my mouse? When I select + (or -) only the control panel changes its size, always leaving the atom the same size though fuzziness may vary. Since it’s so small to begin with, even a clear image also expands fuzzy.

Still thinking.
.

P.S. I'm convinced spirals exist as electron and positron charge flow spiraling around the proton axis.


Last edited by LongtimeAirman on Sat Jun 25, 2016 6:17 pm; edited 3 times in total (Reason for editing : in a, long term stable pairs must be the same polarity. Added P.S.)

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Tue Jun 28, 2016 12:35 am

I've had a bit of a think about whether the protons inside of an alpha will be 2 protons or a proton and anti-proton pair.

Firstly, does it even matter? I don't think it is a requirement that an anti-proton accepts anti-charge and a proton accepts normal charge. It might work better if it has the same type of charge, but I don't think it requires it.

Secondly, what type of protons are used to build an alpha is not dependent on where or how that alpha will be used at some indeterminate future time. It is solely dependent on the environment in which it forms. Given that that environment is deep inside of a star, I doubt it will have 2 different charge types available. Yes, a star will output both charge and anti-charge but to require both for an alpha would mean that the 2 protons must come from different hemispheres of the star. Which would require those protons to move against the flow of charge if they are to come together. Highly unlikely, if not impossible.

Thirdly, can a proton turn into an anti-proton if it finds itself in an anti-charge field? I don't think so. Miles has discussed neutrons flipping to accommodate the charge field, but a proton can not do that because it has its own charge field. A very large charge field with respect to the size of the proton itself. So a proton would need to unwind and then rewind into the opposite type but in doing so it would destroy the alpha that it is a part of.

We can take some of those principles up to atoms too. An atom is going to form in 1 hemisphere of a star, not both. We can not require that the top half be built in one hemisphere and the bottom in another and somehow they find each other to form the complete atom. They are all going to come from the same place within the parent star which is not likely to be near the border of the hemispheres.

So I don't think the type of charge is a concern for atom or alpha building. Does it matter at any time? I don't think so. It can make a difference in an atom but it can not be a requirement of it. We know there are bodies within our own solar system that do not have a magnetic field but do have a charge field and they are all made of the same atoms that make the earth so we know the atoms can live with equally mixed charge just as much as they can live with unequal charge.

On to electrons in an alpha.

Your pics are great, Airman. It really helps to have a concrete image to look at to avoid confusion. I have currently implemented a combination of b and c. It is really b, but the electrons are offset from the center a bit and the north one if offset one way while the south one is offset the other way. This allows 2 alphas to join and the electrons from each of them are still visible. The join location has 2 electrons circling around the 2 protons, which is what makes it a bit like c.

I don't agree with the need for electrons and positrons though. If the electrons are trapped inside of the alpha when the alpha is created, then they will be one type or the other. If they can get inside of an alpha after it has formed then it probably depends on the type of charge that is being channeled through that alpha at the time the electron/positron is pushed inside of it. However, I don't think it really matters which type it is. A charge stream will push an electron just as easily as a positron.

And finally, AV.

To turn on through-charge go to 'View Settings' -> 'Proton Stack' and enable 'Through particles'.

You have found a bug in AV. I'm not sure why yet, but atoms that only have a core alpha are not creating their through charge streams. Intake and Output charge works fine but the through charge doesn't. I have some logic in the code that sets up the charge streams for the core based on the proton stacks around it. This must be turning them off when it doesn't find any stacks. Most of my testing lately has been with large elements so I didn't notice that it broke something else. I'll look into it soon.

The core stack is treated differently to all of the other stacks because it is the place where everything comes together. The core stack can have through-charge streams that the others can't. It has cross streams to show the charge going to the carousel level. Some of the other stacks make use of these at times, such as the pillars, but the core can use all of them at the same time. It is the only stack that has charge coming from or going to all 6 directions.

There is no other way to zoom in or out at the moment. I'll look into using the page-up and page-down keys to zoom and probably WASD and the arrow keys for rotation.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Tue Jun 28, 2016 5:26 pm

Nevyn wrote: I've had a bit of a think about whether the protons inside of an alpha will be 2 protons or a proton and anti-proton pair.
Firstly, does it even matter? I don't think it is a requirement that an anti-proton accepts anti-charge and a proton accepts normal charge. It might work better if it has the same type of charge, but I don't think it requires it.
Airman. It’s information. It just may not be all that important. A new observer to AV has no idea that all particles are either left or right spinning, or whether various alpha configurations are possible. I wish that we could tell each at a glance. Maybe two different line colored - sorry. “I don't think it is a requirement that an anti-proton accepts anti-charge and a proton accepts normal charge” - Agreed.

Nevyn wrote:Secondly, what type of protons are used to build an alpha is not dependent on where or how that alpha will be used at some indeterminate future time. It is solely dependent on the environment in which it forms. Given that that environment is deep inside of a star, I doubt it will have 2 different charge types available. Yes, a star will output both charge and anti-charge but to require both for an alpha would mean that the 2 protons must come from different hemispheres of the star. Which would require those protons to move against the flow of charge if they are to come together. Highly unlikely, if not impossible.
Airman. “deep inside of a star” is filled with possibilities.  I see a much more fluid environment, where left and right protons are able to pair without the hemispherical limitations you imply. I assume a star can easily flip protons or alphas. More importantly, left and right spins react in opposing directions under charge influence; it seems to me that only left/right can spin against each other to form a stable pair, which may aid in alpha formation.

Nevyn wrote:Thirdly, can a proton turn into an anti-proton if it finds itself in an anti-charge field? I don't think so. Miles has discussed neutrons flipping to accommodate the charge field, but a proton can not do that because it has its own charge field. A very large charge field with respect to the size of the proton itself. So a proton would need to unwind and then rewind into the opposite type but in doing so it would destroy the alpha that it is a part of.
Airman. Agreed.
Nevyn wrote:
We can take some of those principles up to atoms too. An atom is going to form in 1 hemisphere of a star, not both. We can not require that the top half be built in one hemisphere and the bottom in another and somehow they find each other to form the complete atom. They are all going to come from the same place within the parent star which is not likely to be near the border of the hemispheres.
Airman. Your stringent hemispherical rules apply from protons to suns, and galaxies too I suppose. Maybe we could discuss those?

Nevyn wrote:So I don't think the type of charge is a concern for atom or alpha building. Does it matter at any time? I don't think so. It can make a difference in an atom but it can not be a requirement of it. We know there are bodies within our own solar system that do not have a magnetic field but do have a charge field and they are all made of the same atoms that make the earth so we know the atoms can live with equally mixed charge just as much as they can live with unequal charge.
Airman. I agree, in AV it may not matter. I’m thinking of the next step, higher matter current flows. Charged particles larger than charge photons. The internal spin composition of a stack accommodating 6 intersecting charge flows may indeed be significant.  

Nevyn wrote:I don't agree with the need for electrons and positrons though. If the electrons are trapped inside of the alpha when the alpha is created, then they will be one type or the other. … . A charge stream will push an electron just as easily as a positron.
Airman. General observation, electrons are available for molecular interaction. This comment reflects mainstream theory, not a charge field theory. The charge field doesn’t recognize electrons as covalent bonds. Charge channels between atoms are not dependent on the presence of electrons. There are no trapped electrons in the smaller elements. All exposed electrons, (and positrons), as determined by flow intensities, will become part of the charge current flow. The atoms will be passing those electrons along. Electrons present when the charge field diminishes will remain with the atom.

Under sufficient current flow conditions, electrons and positrons are both pressured to move forward – in opposite directions. The two will be differentiated by their direction of motion with respect to the charge channels or main ambient charge flow.

Nevyn wrote:
The core stack is treated differently to all of the other stacks because it is the place where everything comes together. The core stack can have through-charge streams that the others can't. It has cross streams to show the charge going to the carousel level. Some of the other stacks make use of these at times, such as the pillars, but the core can use all of them at the same time. It is the only stack that has charge coming from or going to all 6 directions.
Airman. I’m still working with alphas, not ready for stacks yet.

Obviously, my main point is to discuss current flow. Up to now, current flow has been b-photons or charge photons – central proton axis charge particle current. I’m trying to expand discussion past charge photons.

All particles unable to pass through the proton axis must circle, or orbit the proton. There are what, 256 different particle sizes, based on radius doublings to get from charge photons to electrons? Presuming that particle populations vary inversely with size, smaller particles make up the larger majorities of particles present. Electrons are the largest particles orbiting the proton, and they develop their own significant charge systems.

Back to electrons orbiting protons. The alpha central axis photon current can act gravitationally. Under increased charge flow, all particles will be pressured to advance, resulting in helical paths, toward the next ‘downstream’ proton. The smallest particles will advance most rapidly and closest to the alpha axis. The largest particles, electrons advance over the longest spiral distances, minimizing the possibility of a head-on collision with a positron.

I could go on and on. I'm somewhat enthused. With AV you’ve simulated atomic charge structures. Ideally, you should expect to be able to expand it to include charge currents.
Somewhere above you’ve eliminated the idea of helical photon streams. OK, I agree. Helical paths are probably necessary for all sub-c particles.

Closely resembling Don Scott’s Birkeland currents.

Possible physics summit item? Maybe Miles can give us a thumbs up or down?
.


Last edited by LongtimeAirman on Wed Jun 29, 2016 10:24 am; edited 1 time in total (Reason for editing : Corrected spelling Birkeland)

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Tue Jul 05, 2016 2:18 am

I just don't see why an alpha would require a proton/anti-proton pair. If you look at an alpha in isolation then I can see why it might be thought that it does, but once you place them into an atomic structure, the charge they receive is going to mainly be of one type or another.

With respect to whether a particular particle is spinning left or right, I don't think that is AV's responsibility. AV is used to view and build atomic models. It sits next to Miles papers as an aid to understanding, it is not meant to be a stand-alone tool that teaches you everything about it. I am happy to move as far along that path as possible but there has to be a limit as the more detail there is the more confusing it will be for a new-comer to understand it all.

I think that if we want to show the internals of a proton stack, then another app should be created just for that purpose (which I already have created but it could use a major overhaul). I don't want to clutter up a single app and reduce its effectiveness.

Airman wrote:Charge channels between atoms are not dependent on the presence of electrons.

While the charge channels are not totally dependent on the presence of electrons, a particular channel can be. The electrons limit the charge flow through the proton they are circling about, and a particular molecule may require that reduced charge flow in order to bond.

I believe it is a possibility that atoms create electrons. We tend to think of atoms as stable entities, and from our perspective they are, but from the perspective of a charge photon, they are chaotic with many different forces for a charge photon to interact with. This could easily impart more spins to a particular photon to create an electron that then gets stuck where ever it is in the atomic structure. If this happens often enough, then as more electrons are created, some would get kicked out. This could be how electron emitters are created. It might require an external charge stream (or more) to excite the atom enough to create new electrons.

I pitched this idea to Miles years ago when I first started work on my desktop AV app and he said that he had thought of the idea but did not want to publish anything until he had a reason for it.

Airman wrote:I could go on and on. I'm somewhat enthused. With AV you’ve simulated atomic charge structures. Ideally, you should expect to be able to expand it to include charge currents.

I'm not sure what you mean by charge currents here. I have implemented various charge currents through the nucleus, although these are implemented at the proton stack level. I do envision a full atom-wide charge current that takes the atomic structure into account in order to determine where charge will go, to the carousel level or more as through-charge. Although, I hope that can be implemented at the proton stack level as well, but I may need to look a bit higher.

Airman wrote:Somewhere above you’ve eliminated the idea of helical photon streams. OK, I agree. Helical paths are probably necessary for all sub-c particles.

Yes, larger particles will feel the magnetism of the charge stream and it can make them move in helical paths, just like electrons travelling through a plasma which is often mentioned in the Electric Universe.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Tue Jul 05, 2016 8:51 pm

Nevyn wrote: I just don't see why an alpha would require a proton/anti-proton pair. If you look at an alpha in isolation then I can see why it might be thought that it does, but once you place them into an atomic structure, the charge they receive is going to mainly be of one type or another."]
Airman. Nevyn, thanks for this discussion.

It seems (in the presence of free neutrons), that the proton and anti-proton join naturally, with only the other as resistance to motion in an otherwise open charge channel. The bond requires only a sufficiently energetic charge channel to: 1) keep them aligned; and 2) at the distance necessary for the alpha to form.  

I accept the truth that all matter is created from random addition of charged particles, two to one, spin and anti-spin. That applies to +/- protons in stacks as well. There must be variations in performance of some sort between the various spins.

In isolation, why wouldn’t the +/- alpha be the most stable (resistant to random collisions), as it’s got the most internal ‘attraction’?

Nevyn wrote: With respect to whether a particular particle is spinning left or right, I don't think that is AV's responsibility. AV is used to view and build atomic models. It sits next to Miles papers as an aid to understanding, it is not meant to be a stand-alone tool that teaches you everything about it. I am happy to move as far along that path as possible but there has to be a limit as the more detail there is the more confusing it will be for a new-comer to understand it all.

I think that if we want to show the internals of a proton stack, then another app should be created just for that purpose (which I already have created but it could use a major overhaul). I don't want to clutter up a single app and reduce its effectiveness.
Airman. You’re right. I shouldn’t step on your toes. How any aps do you have?

Airman wrote: Charge channels between atoms are not dependent on the presence of electrons.
Nevyn wrote: While the charge channels are not totally dependent on the presence of electrons, a particular channel can be. The electrons limit the charge flow through the proton they are circling about, and a particular molecule may require that reduced charge flow in order to bond.
Airman. I have no problem accepting that electrons somehow slow things down, though how, exactly, is yet to be described. It makes more sense to me to say that the number of electrons in motion between atoms is dependent on the ambient charge field’s net movement. What’s the orbital radius of the electron circling a charge channel versus a proton? Apparently, electrons can orbit much closer to a charge channel.  Also, the charge channel itself must have variable radius, related to the charge field net motion. Atom wide charge channels indeed.

Nevyn wrote:I believe it is a possibility that atoms create electrons. We tend to think of atoms as stable entities, and from our perspective they are, but from the perspective of a charge photon, they are chaotic with many different forces for a charge photon to interact with. This could easily impart more spins to a particular photon to create an electron that then gets stuck where ever it is in the atomic structure. If this happens often enough, then as more electrons are created, some would get kicked out. This could be how electron emitters are created. It might require an external charge stream (or more) to excite the atom enough to create new electrons.
Airman. What is matter creation? Inside a star – enormous temperatures and pressures creating matter sounds right, yet there are many implied assumptions. I’ve always thought that the elements found on earth were created in the sun’s photosphere or cooked below Earth’s surface. I now believe that all matter is created in intersecting charge channels. I see the total amount of matter is somewhat variable. Your atomic electron emitters sounds completely reasonable.

Aiman wrote: I could go on and on. I'm somewhat enthused. With AV you’ve simulated atomic charge structures. Ideally, you should expect to be able to expand it to include charge currents.
Nevyn wrote:I'm not sure what you mean by charge currents here. I have implemented various charge currents through the nucleus, although these are implemented at the proton stack level. I do envision a full atom-wide charge current that takes the atomic structure into account in order to determine where charge will go, to the carousel level or more as through-charge. Although, I hope that can be implemented at the proton stack level as well, but I may need to look a bit higher.
Airman. “charge currents” – I mean as north/south, east/west, front/back or vice versa. The individual charge flows in those directions. Charge currents can be defined in terms of electron flow, as opposed to total charge movement along the charge channels. I expect the atom to align with the earth’s vertical emission field, but east/west or front/back charge currents may vary.

Airman wrote: Somewhere above you’ve eliminated the idea of helical photon streams. OK, I agree. Helical paths are probably necessary for all sub-c particles.
Nevyn wrote: Yes, larger particles will feel the magnetism of the charge stream and it can make them move in helical paths, just like electrons travelling through a plasma which is often mentioned in the Electric Universe.
Airman. “larger particles will feel the magnetism of the charge stream” (?) Larger particles will orbit the charge stream, presumably blocked by current limiting pole electrons and the atom behind them. I still want to talk about how even the smaller charge particles sort themselves out. Spinning electron pole pairs must add a great deal of organization to smaller and faster charged particles attempting to slip past them, again, both ways.    

Nevyn, either way, I agree with the fact that the charge channel is where it’s at. Myriad forms.

A few days ago, a friend (he’s helped inspire me many times too) shared a possible explanation of a working free energy device he’s looking at in the following Heaviside quote. Note. Over the years I’ve made many attempts at, how shall I say it, reasoning with him. He’s never been impressed with ‘fotons’.    

“It [the energy transfer flow] takes place, in the vicinity of the wire, very nearly parallel to it, with a slight slope towards the wire… .  Prof. Poynting, on the other hand, holds a different view, representing the transfer as nearly perpendicular to a wire, i.e., with a slight departure from the vertical.  This difference of a quadrant can, I think, only arise from what seems to be a misconception on his part as to the nature of the electric field in the vicinity of a wire supporting electric current.  The lines of electric force are nearly perpendicular to the wire.  Their departure from perpendicularity is usually so small that I have sometimes spoken of them as being perpendicular to it, as they practically are, before I recognized the great physical importance of the slight departure.  It causes the convergence of energy into the wire.” —Oliver Heaviside, Electrical Papers, Vol. 2, 1887, p. 94.
Airman. If I substitute ‘wire’ with ‘charge channel’, and assume wires are the integration of a great many charge channels, Heaviside’s quote makes a great deal more sense.

One of the joys of our discussions are these aha moments. I know I’m trying at times, but I do mean well.

Thanks also for your patience, efforts and insights.
.

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Cr6 on Tue Jul 05, 2016 11:27 pm

Guys, the discussion is excellent and didn't want to butt-in with a crass joke or a naked pic of hot lady or something like that... but this is close. Mathis does delve into Tau neutrinos:
----


Shoulders then shows that electrons travel easily together, contradicting what we are taught about repulsing charges. He provides data proving that although electrons have some repulsion, they have nothing like a repulsion of -1. I have shown that this is because electrons have a smaller charge profile than the proton. We do not have equal and opposite charges, and never have. The mainstream's own experiments and equations have long indicated the electron has a charge of 1/1821 that of the proton, but as with the charge field itself, that data is ignored to suit old standing theories.

Furthermore, I have shown that it is the electrons' real spins and charge emissions through those spins that are keeping them apart, just as fans would keep one another apart. But in some cases, electrons can huddle even closer, stacking like the protons stack in the nucleus, pole to equator. To get there, they have to be driven by a non-linear charge field, which is rare. But this is the explanation of some quantum particles, such as the tau neutrino. The neutrino is not an indivisible particle: it is four x-spinning electrons.



Finally, here's the clincher:
Curiously, the critical number density of the substructure matches Avogadro’s number. To a first approximation, the parts within are spaced the same as if they were in an atomic lattice.

Why would Avogadro's number be showing up here? It is supposed to be the number of molecules per mole of substance. But we aren't looking at molecules or even atoms here. We are supposed to be looking at free electrons. This makes no possible sense until you read my paper re-assigning Boltzmann's constant and Avogadro's constant to the charge field. There I show that both constants are following the charge photons present, not the molecules. Once we understand that, we understand why Avogadro's number is showing up here with electrons. It is because, once again, Shoulders' devices aren't measuring the electrons in the field, they are measuring the photons. As with the molecules, the electrons are just along for the ride. Not only do they not cause any of the major effects, the math— such as it is—doesn't even apply to them. Like all previous researchers, these guys like Shoulders just assume that because they put electrons in (and nothing else), the electrons must be causing the effects. So they apply their field math to the electrons. But since it is the photons that are causing everything, the math should be applied to them.

To be fair, Shoulders himself was careful not to jump to conclusions. He has left the door wide open for me by admitting they have no evidence that electrons are the cause of anything here. He goes to extreme lengths to avoid that, even calling his particles “entities” rather than electrons. I think this was because he could see that his entities weren't acting at all like electrons. But he couldn't figure out what else might causing the energies, so he left the question open. This was refreshingly scientific of him. Needing a model—and not having one—he left the door open for a good modeler. I thank him heartily. Since I spent 20 years in Austin, where he did his research, it is too bad he and I never got together. I was at least a generation too late.

http://www.intalek.com/Index/Projects/Research/EVOsAndHutchisonEffect.pdf
http://milesmathis.com/evo.pdf
http://milesmathis.the-talk.net/t87-magnetic-fields_rotating-vortices

Cr6
Admin

Posts : 655
Join date : 2014-08-09

View user profile http://milesmathis.the-talk.net

Back to top Go down

Re: Atomic Model Editor

Post by LongtimeAirman on Wed Jul 06, 2016 5:31 pm

.
Hi Cr6, It’s good to hear from you.

You’re supposed to throw only one spaghetti at the wall, not the whole kitchen.

Rotating magnetic fields are equivalent to the ‘charge channel’ I've been describing. And I was trying to describe current flow.

Nevyn, Is that what you meant by "larger particles will feel the magnetism of the charge stream and it can make them move in helical paths"? I'm not at all sure we agree when I say that charge orbits the charge streams.

The other end of the rabbit hole. I’m going back in.
.

LongtimeAirman
Admin

Posts : 582
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Atomic Model Editor

Post by Nevyn on Fri Jul 08, 2016 1:10 am

I don't agree with charge orbiting the charge stream (at least how I am interpreting that statement), since the charge is the charge stream and I don't agree that a charge stream can act gravitational. While they do have gravity, as everything does, I don't think it is an important factor in how they act and how they affect other particles. I'm not even sure how gravity would affect a charge stream, so let me take a little diversion into that realm.

I'm going to write this as gravity = expansion to make it easier to explain. Each individual photon expands, moving all photons in the stream closer together. They do not have charge fields to exclude each other so they must group together, effectively making the charge stream more dense. If the stream exists long enough, the charge photons would actually touch and the stream becomes something a bit more solid than it was (but I don't mean solid like an atomic lattice). This would imply that a charge stream becomes more focused the longer it exists. It is not a cylinder but a cone.

This is probably not an issue as charge streams are very small, short lived things.

When I said "larger particles will feel the magnetism of the charge stream and it can make them move in helical paths", I meant electrons but not protons. Protons will be affected but they are so much larger that they won't be affected as much as smaller particles. I think an electron would be controlled by the stream, almost locked inside of it, where-as a proton will be pushed along but may escape fairly easily. I think a proton would be more of a block to the stream where-as an electron would be carried along easily. The electron will still block the stream but it will be pushed much faster than a proton. However it happens, the proton is too large to be pushed into a helical path unless it is in a very large charge stream (which has made me realise that I have been imagining the streams as very small, such as through-charge in an atom).

Please note that I am talking about charge streams and not charge fields. A charge field is much bigger and less dense than a charge stream and would affect protons differently since they would not so easily escape a field.

I'm not really sure. I'm just typing off the top of my head. I have probably forgotten some things that may be important.

Airman wrote:You’re right. I shouldn’t step on your toes. How many apps do you have?

I didn't mean to imply that you were 'getting in the way'. These discussions often make me think about things that I haven't put enough time into. If I say that I don't think AV needs to worry about something, that doesn't mean it is not important, just that AV needs to focus on its job and not get too bogged down in details. But I do want to make sure AV shows whatever it does implement, correctly. I also might choose to show something in a more specific app rather than clutter up AV in order to reduce confusion. There is always some balancing point I need to maintain.

I currently have 4 apps available on my site and I was referring to the Proton Charge Field app in my last post. I have plenty of other apps that I have built over the years and plenty more that are little more than ideas. There's just not enough time to build them all! When we get into these discussions, I often find myself seeing a new app that I could create to show something. For example, I recently started thinking about a charge field app that allows you to define charge fields and particles and see how those fields affect the particles. I re-read Miles recent paper on the Stark Effect last week and thought it would be a good paper to create some apps to demonstrate what he is talking about. This led to a more general idea of having apps for specific papers, sort of a visual guide to the paper.

One of my old apps that I would really like to implement in a browser setting is about Relativity. I implemented a very simple model that only used the definition of velocity (and acceleration if you chose to use it) to show an emitter, observer and the photons moving from emitter to observer (emitted every second). It recorded the emission time, observation time, distance traveled, etc, and presented a table of the results where you could see the way the velocity of the emitter affected the observations. Directly showing that Relativity does not apply to real time, only measurement of it. The graphics were crude but the data was effective at showing time dilation.

I implemented a second version of that to show length contraction. This one had 2 emitters, one on the stern and one on the bow (offset in the Y dimension so you could see the photons from each emitter, which were also color coded). This allows you to see how the photons from the front were released before the photons from the back which causes the 2 photons to be observed at the same time (or close to it), even though there were emitted at different times.

I then took it another step forward and added gravity, stepping out of Special Relativity and into General Relativity. I implemented gravity as an expansion of the observer so it would effectively move the observation point closer to the emitter (assuming the emitter is not moving) over time. You kind of had to exaggerate things to see the results but it worked ok.

My main apps have always been AV and SpinSim. I don't think SpinSim gets enough love, as it is, by far, the app that has helped me the most with understanding Miles work. But it is hard for me to separate the app from the building of the app. I learn a lot in the building as I have to figure out what I think is happening and how I can show it effectively.

Airman wrote:I have no problem accepting that electrons somehow slow things down, though how, exactly, is yet to be described.

I don't think 'slow things down' is the right way to say it in this case. The electron takes up space so it just blocks the charge field, reducing the amount of charge that reaches the proton. This can produce a weaker bond but in some cases, a weak bond is required for the 2 elements to bond at all.

Airman wrote:It makes more sense to me to say that the number of electrons in motion between atoms is dependent on the ambient charge field’s net movement. What’s the orbital radius of the electron circling a charge channel versus a proton? Apparently, electrons can orbit much closer to a charge channel.  Also, the charge channel itself must have variable radius, related to the charge field net motion. Atom wide charge channels indeed.

I don't think a proton would orbit a charge channel. A proton sort of becomes part of the stream because it uses the charge, some for emission and some for through-charge which allows the stream to continue on, although with a reduced density. A proton could be re-oriented by the charge stream but no circling around or through it like an electron would. Remember that the electron gets stuck between the proton and charge stream. It wants to keep going but the proton just won't let it.

I don't think the ambient charge field has much to do with it. Being ambient, it is less dense than the charge stream itself. It may have some affect but not a major one.

If we are talking about charge streams emitted from atoms or proton stacks (same thing, in this case) then the radius is not variable but the density of the charge stream can be. This is because the proton sets the radius since that charge stream has to go through the protons central hole which gives us a size limit.
avatar
Nevyn
Admin

Posts : 795
Join date : 2014-09-11

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

Back to top Go down

Page 4 of 7 Previous  1, 2, 3, 4, 5, 6, 7  Next

View previous topic View next topic Back to top


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