Atomic Model Editor

I have made another update, this time to show charge that flows across a proton stack as a result of through charge from an adjacent stack. I'm not sure I have all of the motions correct yet, but it is pretty close. With this enabled, you can completely turn off the charge discs and still see the atom.

The graphics performance setting now changes the types of charge particles that are shown. The default setting will only show charge emission. Higher settings will enable intake and through charge. You can always go to the setting yourself and turn them on/off so you can choose a low graphics setting and then turn on the particles to your liking. For the best performance, assuming your graphics system can handle shaders, it is probably best to use the minimum graphics setting and then turn off the charge discs and turn on all charge particles. This will move nearly all processing to the graphics card.

Nevyn wrote:I have looked into hosting arrangements but have not chosen a particular set of technologies that I may need in the future which makes it difficult to select a specific host. I am looking at 2 different kinds of hosts. The first is the normal web hosting setup where you usually have access to a web server running PHP and a back-end database, usually MySQL. The other hosting type is called Linode and basically gives you a Linux Virtual Machine that I can do whatever I want with. This is my preferred option since it gives me complete control over what I want to use. However, it also gives me complete responsibility to keep it running, secure it, etc. Public sites get attacked all the time and it can be a real time waster dealing with it.

The costs of the basic hosting arrangement is about US$8 a month. I can get it a bit cheaper at the moment as they have a special on and it is about $5 a month but that will eventually run out and it will go back up to the higher amount. There are also some hidden costs (that I can choose) for extra security, auto backups, etc, so it adds up in the end. The Linode cost is US$10 a month, no specials, and while this is a bit more expensive, it does provide me with much more power (but with great power comes great responsibility) and if I want more security, then I just implement it myself, same with backups, etc.

That's a great goal Nevyn. I think the Linode long-term might be the better and most flexible choice for web-server/mysql database. But that would require more work for upkeeping the server and preventing hacks. By all means look at getting a minimal income stream to at least upkeep the site.

I've been looking at Apache Drill or Apache Spark lately. They could work with a php/MongoDB combo -- they seem to be very json friendly. Might be a lot of configuration work over a simpler php/mysql start when including the on-going maintenance/security.

https://www.mongodb.org/downloads
https://github.com/mongodb/mongo-hadoop/wiki/Spark-Usage
https://drill.apache.org/
https://spark.apache.org/

Hmmm, non-relational databases? Didn't we throw those out in the 80's?

I am so used to working in relational databases I don't see how to use a non-relational one effectively. I've only spent about 10 minutes looking at it but at the moment I can't determine exactly what they mean by non-relational. Does it just mean that the database does not store any relationship information but you can still link things together in your SQL (like inner joins, etc)? Can a "table" contain child records directly instead of linking to another table? I'll have to look into it a bit deeper. Thanks for the links and getting me thinking in a new direction.

I don't have any ties to PHP. In fact, I've never built a site with it. I have fixed bugs in someone else's PHP code but there's a lot I don't understand with it (although it's just a matter of learning their syntax and function names, etc). My preference would be to use Java as my server language which would run inside Apache Tomcat which would be hidden behind an Apache Web Server (more secure and faster for basic file transfers). I would still do most of the coding in Javascript and only use the back-end server where it is absolutely needed. I was only thinking PHP/MySQL because nearly all hosting environments have those already (but that also makes it a more likely target to hack).

I do have to get things moving though as Miles has offered to put a link on his site to the AV app. I am 90% certain that I will go with Linode at this point. It may cause me some pain but at least I can figure out what it happening and apply fixes, etc. While a more standard web hosting system does provide some security, it is also a little sandbox where you don't always have access to what you may need to fix a problem. They are designed to make is easy for (almost) non-technical people to get up and running.

So my plan of attack is:

1) Clean up the interface. Dialogs, selecting elements, etc.
2) Find a way to separate viewing from editing such that they share code, not copy it.
3) Restructure the settings into a more coherent hierarchy.
4) Write some help pages within the app and some informational pages along side of it.
5) Apply code licensing. Not sure about this now, since it is moving away from an open source model.
6) Buy hosting environment.
7) Setup back-end services on host.
8) Secure services.
9) Setup backup regime.
10) Setup site monitoring system. Checks for dead processes, file changes, etc.
11) Buy domain name and link to host.
12) Research e-commerce frameworks, select one and set it up.

It will probably take me a few months to get all of this done so I am thinking of a new years launch.

Now, if I can just stop playing the new Metal Gear Solid game so much, I might find some time for all of this!

I have updated AV to version 0.7 which is basically some bug fixes in the dialogs to select elements and define JSON objects and some lighting settings. The directional and spot lights still do not work properly and I think I will drop these as they are not really needed and were only in there because I wanted to play with them in the beginning of development of this app. I have also changed the navigation system back to the original Orbital type as this works better for 1 or 2 models and my alternate version had some issues that annoyed me every now and again.

I am trying to clean up the code so that I can split it into a Viewer and an Editor while also trying to figure out how I can use a common code base for both of them. I know how I can do this easily with a back-end server but not so easy without one. I think I really need to bite the bullet and just use one. It will open up a few possibilities that have sat in the back of my mind for a while. Might be a good opportunity to learn a bit more PHP. I keep thinking of Java technologies that I could use but something still tells me not to tie myself into such a hosting arrangement, even though I am nearly certain that I will go with a Linode VM.

I am a little over half way through Metal Gear Solid V and am really enjoying it, hang on, that's not why I'm here...

I haven't been putting much time into this project over the last few weeks, which I feel a bit guilty about since I had just committed myself to getting all of this set up, but I have now made some progress on the hosting arrangement. Last night, I bought a Linode VM, setup a Linux distribution, installed a Web Server, secured it as far as I want to at the moment and installed a copy of my site. It all came together very easily. Linode provides many great tutorials on how to get started and I only had one problem during the entire setup. I suspect that problem was a result of the Linux distro I chose as I went for the more up-to-date version rather than the recommended one. The VM is currently configured as I want it, but I don't think it will survive a reboot because of that error. I will try to track down and fix the problem but I may need to start all over again with the older Linux distro. Unix administration is not my forte, although I have done bits and pieces over the years.

So my updated plan of attack is:

1) Clean up the interface. Dialogs, selecting elements, etc.
   I have done some, but there is more to do.
2) Find a way to separate viewing from editing such that they share code, not copy it.
   I have PHP now so I think I will try to use that to bring all of the pieces together based on whether
   the user is viewing or editing. I could also setup a database and have formal users/groups that
   restrict access. Needs some thought on what is feasible in a small time frame.
3) Restructure the settings into a more coherent hierarchy.
4) Write some help pages within the app and some informational pages along side of it.
5) Apply code licensing.
   I have had a quick look into this but nothing substantial at the moment.
6) Buy hosting environment.
   Done.
7) Setup back-end services on host.
   Done.
8) Secure services.
   Done.
9) Setup backup regime.
   I had a look at my options but need a formal backup regime.
10) Setup site monitoring system. Checks for dead processes, file changes, etc.
11) Buy domain name and link to host.
   I have researched domain name registrars but have not decided on one yet.
   This is tricky because there are some real dodgy operators out there.
12) Research e-commerce frameworks, select one and set it up.
   I will probably not worry about this for now. Maybe later when I have something worth paying for.

So, in spite of not putting much effort into this lately, everything is coming along nicely enough. I really did need a break from it. The first 50% of a project is usually the easiest as you have that drive based on all of your ideas. The next 30% goes ok because of the momentum you build during the first half. But that last 20% is a killer. A lot of personal projects get left at this stage. Even in the professional world, that last bit requires so much work and you don't have the option to just walk away. I'm trying to keep that mind-set with this project because I think it deserves a professional attitude. I didn't intend for it to go this far but now that it is getting close, I really want to push it over the finish line and let it out into the world. For better or worse!

I now have my very own domain name! It took some thought to come up with one (that was also available) as I don't really know what this site is going to end up as. I settled on a more personal touch as I can always buy more domains later for different purposes and point them all to the same system (but completely separate in the web server).

I'm really struggling with an identity for the site. Right now, it is for these applications, but I am not limited to that or to Miles work. I feel like everything has opened up before me and I just don't know where to go. But I am a believer in an evolutionary approach to these things, so time will tell. I do feel that I need more pages around these apps and certainly more pages that describe the apps and how to use them. However, it is the front page that worries me. It really needs to set the scene.

I'm not used to creating this side of a system, usually I am creating the server side components with a bit of HTML/Javascript as an interface. It is good to be learning though, and I do like to be creative.

It's been great setting up the server. I expected a lot of it to be painful, finding info on the web that doesn't quite work, dependency conflicts, security holes, but it has been very easy with my compliments going to both the Linux OS and to Linode for their tutorials. Linux really has stepped up and fixed issues that I have had with it in the past and I really can't say enough good things about Linode. Great platform for anyone with some administration skills or the desire to learn them. Only slightly more expensive than other hosting sites but you get all the power that others don't provide.

So, without further ado, I present to you: Nevyn's Lab.

Updated plan of attack is:

1) Clean up the interface. Dialogs, selecting elements, etc.
  I have done some, but there is more to do.
2) Find a way to separate viewing from editing such that they share code, not copy it.
  I have PHP now so I think I will try to use that to bring all of the pieces together based on whether
  the user is viewing or editing. I could also setup a database and have formal users/groups that
  restrict access. Needs some thought on what is feasible in a small time frame.
3) Restructure the settings into a more coherent hierarchy.
4) Write some help pages within the app and some informational pages along side of it.
5) Apply code licensing.
  I have had a quick look into this but nothing substantial at the moment.
6) Buy hosting environment.
  Done.
7) Setup back-end services on host.
  Done.
8) Secure services.
  Done.
9) Setup backup regime.
  I had a look at my options but need a formal backup regime.
10) Setup site monitoring system. Checks for dead processes, file changes, etc.
  I have setup system monitoring, not site content monitoring.
11) Buy domain name and link to host.
  Done.

Nevyn, I’m not qualified to offer you any feedback in your server development, but it sounds like you’ve got the technical side nailed. Of course, the biggest costs are time and energy. You hinted at other interests; anything to do with World Domination? Maybe (Nevyn’s) Nefarious Laboratory.  I can help with a share and modest efforts but I’m glad I’m not here for the money.

I went looking for the Lab in the usual spot, but of course, it isn’t there yet. So I played with the… Periodic Table (PT), and AV0.7.

1)  PT. It’s really convenient to be able to go back and forth from the Periodic Table to the Atomic Model Editor (AV0.7). I can now easily dial through rows or columns and clearly understand the organization of the table, which, I'm sure you'll agree, has never been possible before.

2) PT, AV0.7. Control Settings are reset each time the Table accesses it. Any chance those settings, if changed, could remain constant?

3) AV0.7 I see that you have divided your view space, top and bottom, left and right, with the Hydrogen proton at the center. This center never changes - except to translate to the midpoint between the carousel alpha protons in the majority of elements - however the atomic structure grows, mostly up. Or with meta data on top. Please consider re-centering the vertical camera space as necessary.

4) You indicated the need for help pages or additional information. I second that. It could be meta data too.

5) PT. Currently, you can display the element’s details when you hover over the element, or hold shift down to keep the detail from changing. I think you can improve the page by displaying a reduced image of the element along with the details.

(5b) Alternatively, if you’re really in with threejs, why not use their famous floating transparent periodic table complete with your models?)

Spaater

Oh. http://www.nevyns-lab.com/

LongtimeAirman wrote:
2) PT, AV0.7. Control Settings are reset each time the Table accesses it. Any chance those settings, if changed, could remain constant?

Yeah, that is a good suggestion. Now that I have PHP I can look into these types of things. Currently, it is stateless, so there is no way to remember the settings. It could probably be done through cookies but I already plan on having session code in the PHP so I will do it all there.

LongtimeAirman wrote:
3) AV0.7 I see that you have divided your view space, top and bottom, left and right, with the Hydrogen proton at the center. This center never changes - except to translate to the midpoint between the carousel alpha protons in the majority of elements - however the atomic structure grows, mostly up. Or with meta data on top. Please consider re-centering the vertical camera space as necessary.

I'm not sure what you mean here. I assume it is a result of the change in navigation controls which now lock on to the center, unless moved with a right-click+drag.

You also might be referring to how zoomed in the camera is when you select a large element from the PT page. Yes, these need adjusting and it is entirely possible now, I just haven't gotten around to it.

Can you try to describe the problem again for me? I just went to the PT page and selected Platinum and it was very close to the atom so I think this is what you are referring to. I will fix it.

LongtimeAirman wrote:
5) PT. Currently, you can display the element’s details when you hover over the element, or hold shift down to keep the detail from changing. I think you can improve the page by displaying a reduced image of the element along with the details.

Another good suggestion. I need a way to generate the images which, again, now that I have PHP I can do this more easily. You've given me the idea to generate a slide show of images of all the elements in a table.

LongtimeAirman wrote:
(5b) Alternatively, if you’re really in with threejs, why not use their famous floating transparent periodic table complete with your models?)

This is an even better idea and I might be able to find a way to incorporate both the periodic table and the selected element into the same scene. It might be a bit tricky on screen space but it is worth a try.

I've been thinking of having as much of my site in Three.JS as possible. Long term goal, but if I can do it right, will work out well, I think. The onus then becomes creating the artwork for 3D environments which is not really my forte. I'll keep the idea in the back of my mind and see if anything pans out.

Sorry not to comment more frequently Nevyn and LTAM.  

Looking over things, it is really very impressive what you have done Nevyn.

I too, like LTAM, find this a great tool to see the structures by flipping the Atomic editor and Periodic table.

The PHP looks like a great option to try.

As for MongoDB, it allows JSON rendering to "tables" in a virtual way. Basically, a JSON atom could be stored in single line of text that can be auto-rendered into a table format from just a single database entry.  I was thinking down the road when Atom Bonding Mathis style is on the horizon, it could allow a full "molecule" to be rendered from a single database entry rather than combining tables with joins (though still available).  Don't want to sidetrack too much on the non-table entities. It might provide fast flexibility in JSON when needed rather than adjusting table structures with alters and such.  Just a thought.

This image relates the story:

http://drill.apache.org

The site looks very nice and presentable.

I spent some time back in the code for AV last night. I updated the PT page so that it sets the position of the camera better when it goes into AV. It could probably still use some fine adjustment, but it is pretty close. This is working on the new site now.

I have also added in PHP so that I can do all sorts of things I couldn't before, but I have not updated the server with these updates yet. PHP is a server-side scripting language. It allows me to put logic into the existing HTML/Javascript source code to control what parts of it get served to the user or maybe alter those parts based on settings in a database, etc. It does plenty of other things but that is generally what I will be using it for in this project.

All previous versions were just straight HTML/Javascript so the app was completely client-side. Once the files were served to the browser, there was no server interaction at all. Now, I am using PHP and a database (currently just for user/role information) to send back code for either a Viewer or an Editor. It is all in the same source files, but PHP allows me to choose which parts I want to serve for a given request. If the user has the 'editor' role, then they will get extra bits of code that implements that functionality. There is no way to actually login yet, so the user is selected by me in the source code, but I will get to that eventually. I don't actually need an editor at the moment so it is really just for my own testing to make sure the code works as both a viewer and an editor.

Right now, I just want to get a viewer up and running so that I can give a link to Miles to publish. This will be a very cut-down version of what you guys have seen so far. I am thinking of removing all of the Graphics Settings and only leaving the Performance selector. Any settings related to the actual parts of the element, such as rotating neutrons/electrons, will remain, but moved somewhere else in the menu structure. I have removed backgrounds and element positioning since these aren't needed and I may have some licencing restrictions on some of the textures I have used. They were all free ones, but often you need to acknowledge the author on your site somewhere and I don't have that information at the moment. It will take a bit of a search to find it.

The other thing I have done with PHP is to save the performance settings so that when you come back to the page it will set it again for you. This is stored as session data on the server and will expire after a certain amount of time. Usually this is set to 30 minutes, I haven't looked to see what my value is, and I think that it expires 30 minutes after it was last used, not 30 minutes since you created it. In the future, these will be saved in the database so that they work all of the time if you are logged in. Might be one of those nice features you have to pay for. I don't wan't to hold back functionality to force people to pay for the system but I think this is a nice middle ground.

I am still working on this. I have the performance setting working but I also wanted to add in whether it shows the metadata or not (atom name, symbol, number, etc). I am thinking of changing how it works so that it can save all of the settings but I think I will have to re-organise some of the settings to make this effective. Basically, there is data in the settings object that are actually values used by the settings rather than actually being settings and I need to move these out so that they are not saved with the settings which would be a waste of space and network IO. This is data like links to background textures, positioning algorithms, etc.

I find myself thinking about things like network, cpu and memory usage on my server. I usually don't have to worry too much about these things because my clients can afford nice powerful systems. Ask any system administrator and they will tell you the developer solution to performance problems is always 'give it more hardware' while the admin is thinking 'make your app work more efficiently'. Now I find myself being both of these roles and stuck somewhere in the middle. I can give it more hardware, but it will cost me more per month. Oh, yeah, I'm the treasurer too.

So I have to really think about what I am going to implement and how that affects the system. It might work fine with 100 users but not with 1000 while an alternative implementation might work better at that scale. I have to think about these things now because I will be charged extra if my server uses more resources than I am allowed, whether that be download quota, cpu usage or memory. I don't expect too much load, but there could be a sudden influx of users when Miles publishes a link to it. I am actually really interested to see those numbers so I better find a way to record them.

A quick search later and I have a solution for that, too.

Cr6 wrote:
As for MongoDB, it allows JSON rendering to "tables" in a virtual way. Basically, a JSON atom could be stored in single line of text that can be auto-rendered into a table format from just a single database entry.  I was thinking down the road when Atom Bonding Mathis style is on the horizon, it could allow a full "molecule" to be rendered from a single database entry rather than combining tables with joins (though still available).  Don't want to sidetrack to much on the non-table entities. It might provide fast flexibility in JSON when needed rather than adjusting table structures with alters and such.  Just a thought.

I understand the attraction of these flexible data structures, reducing the need to change rigid database schemas. My worry is that query performance will suffer because of it. Also, the SQL needed to query these sorts of tables can become horrendous. I was thinking of a schema that would facilitate nice, or at least effective, queries but maybe I shouldn't worry about that. Horrible SQL can always be hidden behind views, stored procedures (I assume procedures are available in these databases) or in the application code (but preferably not). And maybe I was creating horrible SQL by trying to split it into a few tables in order to reduce data redundancy. I was dealing with quite complex data (our element JSON structure) so I will assume that I am at fault, for now.

I got the persistent metadata settings working last night and updated the site which is now at version 0.8. I also spent some time minifying and collating the Javascript files in order to reduce network IO and loading time. It also obfuscates the code, which makes it difficult to read and figure out what is going on. That wasn't really my aim but I don't mind either.

Sorry I missed out on your progress till now, but maybe I can catch up a little. Looks interesting.

Hey Lloyd, welcome back! We were getting a bit worried about you for a while there.

We've made some great progress lately. It seemed a real shame to me that you weren't here for it because you were the real driver for this kind of stuff. Trying to get us organised and productive. Glad your back and I am looking forward to hearing your input. There's plenty for you to look over and absorb, most of my apps are on my new website (www.nevyns-lab.com) except the Solar System app so if you want a link to that, just give me a PM and I will send you the URL. I didn't get very far with that one which is why I didn't publish it on my new site.

I just noticed that this is your first post. What happened to your old account?

Hi Lloydd, Welcome back? I saw you posting at TB and wondered. Any news?

I've rewritten my periodic table page. I took the Three.JS example and wove it to my own needs. I think it works pretty well.

I colored the elements based on their groups and added a legend. You can click each legend item and it will color all other elements black, highlighting that type. Click on the currently selected item again to turn them all back to their default colors. I just used the same colors I had on my existing page but these are transparent (25%) so they are a bit darker. I would like to brighten them up a bit.

You’re getting there. Here's a little feedback. I'll try to be clear.

1. As far as I can tell, it launches perfectly.
2. Wow, firefox shows only the table and view space! A new full screen mode (move mouse to top margin to recover browser control). Also near perfect. I don't ever remember seeing that before. AV0.8 also looks better this way.  In Chrome, the top browser tabs, and bottom taskbar remains visible.  
3. In this mode, the atomic symbols are clear, but the names and numbers are not. All those S’s don’t make any sense to me. I clearly see what they do.
4. In Firefox, if I rotate my mouse wheel one increment to get closer, the table is expanded such that I can only see the element tiles -top row: Ru,RhPd,Ag; and bottom row: Os,Ir,Pt,Au. When I wheel back one increment, the table is reduced to half size. The wheel basically just switches between the two views, … Fix the dolly! Chrome’s dolly works fine.
5. When an element is selected, the element’s table tile rushes toward the viewer. Works well. It eases one’s mind while being redirected to AV0.8.
6. In Firefox, when returning to the table from AV0.8. The background color is what was left by the rushing tile - black is no longer the view space color when the browser tabs are visible. With the mouse over the view space the background color returns to black. The tile is actually in front of the camera. Real fit inducing to be able to flip between the color schemes and small size difference between the two (full screen and browser view) by just moving the mouse past the top margin boundary. I can right click to shift the camera position sideways, and go on selecting elements and returning to displaced tiles. In chrome, there is no such problem as the page is simply reloaded.
7. Please consider giving the user the option to select a new browser tab (ideally without conflicting with the rush (5) above) so that when an element is selected, AV0.8 doesn’t need to keep reloading between the two applications to simply go back and forth.
8. Please consider loading smaller scale elemental images directly to the Table rather than launching the full AV0.8 editor.
9. AV0.8's element selector now looks rather shabby in comparison to the table. Maybe you can pull a periodic table in to replace it.

Any further word? My fingers are still crossed.

8. Please consider loading smaller scale elemental images directly to the Table rather than launching the full AV0.8 editor.

I've made similar comments before. As I see it, adding a hundred image files to the program begins to get burdensome. Sure. But if the images were based on Cr6's excel "orthographic view", we could zoom into the image on each tile itself. Cr6 images become the smaller scale. We shouldn't just jump to the full editor every time our interest moves casually along.

Speaking of that orthoview, it is the clear basis to replace or add to the tile geometry list: table, sphere, helix, grid, and ortho.

Every new proton is added to a structure: beginning at the origin; expanding along +/-Y (vertical axis), X and Z (carousal), etcetera. An animated sequence might be nice. But the point is, there is now a structure to replace the table.

LongtimeAirman wrote:3. In this mode, the atomic symbols are clear, but the names and numbers are not. All those S’s don’t make any sense to me. I clearly see what they do.

I left these as they were in the example app. I agree with you that they are too small to see and I will probably implement something like what I had in the original where hovering over an element will display its values at the top of the table. I had a different structure in mind for the legend which was closer to my original page where the group name was beside the legend icon. Space was the main problem with this approach so I left it like it is until I can find a better way to fit it all in.

LongtimeAirman wrote:4. In Firefox, if I rotate my mouse wheel one increment to get closer, the table is expanded such that I can only see the element tiles -top row: Ru,RhPd,Ag; and bottom row: Os,Ir,Pt,Au. When I wheel back one increment, the table is reduced to half size. The wheel basically just switches between the two views, … Fix the dolly! Chrome’s dolly works fine.

Yeah, I noticed that too. Annoying, since it is only in Firefox. I will see what I can do about it.

LongtimeAirman wrote:6. In Firefox, when returning to the table from AV0.8. The background color is what was left by the rushing tile - black is no longer the view space color when the browser tabs are visible. With the mouse over the view space the background color returns to black. The tile is actually in front of the camera. Real fit inducing to be able to flip between the color schemes and small size difference between the two (full screen and browser view) by just moving the mouse past the top margin boundary. I can right click to shift the camera position sideways, and go on selecting elements and returning to displaced tiles. In chrome, there is no such problem as the page is simply reloaded.

Saw that too. It seems Firefox remembers the page and just takes you back to where you were. Kind of annoying in this instance. Not sure if there is an event I can listen for to reset everything.

LongtimeAirman wrote:7. Please consider giving the user the option to select a new browser tab (ideally without conflicting with the rush (5) above) so that when an element is selected, AV0.8 doesn’t need to keep reloading between the two applications to simply go back and forth.

Yeah, that's easy enough. It will also allow me to reset the position of a selected element in the table after it has sent you to another tab.

LongtimeAirman wrote:8. Please consider loading smaller scale elemental images directly to the Table rather than launching the full AV0.8 editor.

I want it to link to the editor/viewer, but will see what I can do with some images for quick viewing.

LongtimeAirman wrote:9. AV0.8's element selector now looks rather shabby in comparison to the table. Maybe you can pull a periodic table in to replace it.

I've been annoyed with that dialog for some time. Every time I look into fixing it, I don't seem to get very far. I'll see if I can use the periodic table directly but the problem I foresee is that the table uses a different kind of renderer (CSS3DRenderer, rather than the WebGLRenderer or CanvasRenderer) and I don't think I can use them at the same time, at least not on the same HTML (DOM) element.

LongtimeAirman wrote:8. Please consider loading smaller scale elemental images directly to the Table rather than launching the full AV0.8 editor.

I've made similar comments before. As I see it, adding a hundred image files to the program begins to get burdensome. Sure. But if the images were based on Cr6's excel "orthographic view", we could zoom into the image on each tile itself. Cr6 images become the smaller scale. We shouldn't just jump to the full editor every time our interest moves casually along.

Speaking of that orthoview, it is the clear basis to replace or add to the tile geometry list: table, sphere, helix, grid, and ortho.

Every new proton is added to a structure: beginning at the origin; expanding along +/-Y (vertical axis), X and Z (carousal), etcetera. An animated sequence might be nice. But the point is, there is now a structure to replace the table.

Not sure what you mean by 'orthographics view' here. I think you mean the camera is positioned above and looking down at the element so you get more of an angled view of it. If there was a button along the bottom for 'ortho' mode, are you suggesting that it replace all elements with images?

I have added the ability to capture screenshots within AV now (not updated on site yet) and I should be able to extend that into something that can generate all of the images for me. I'm just not sure how to show them yet. Maybe I could create an element image which zooms out towards the viewer, much like a selected element does now, and then move the camera back so that you can see the image, leaving the periodic table in the background. Maybe reset all of the table items to be more transparent to reduce their impact. How would the user select between showing an image of an element vs opening AV? That's why I prefer the idea of showing an image when hovering over an element and leaving the click to open AV.

Here’s what I mean.

I submit the tile array above right as an addition to the tile configuration choices: table, sphere, helix, grid, nuclear. I referred to it previously as orthoview. Even though I have my drawing as an orthoview, I believe it should be in perspective view.

I know it may be a bit over simplistic, but it makes more sense to me than helix, grid, or sphere, though those are fun to have.
It even makes more sense to me than the table view. The table developed over time as the only logical way to view the properties of the elements, so it became the object we all recognize.

H is at 0,0.5,0. He is at 0,-0.5,0. As you go through the legend selectors, the tiles displayed might be interpreted in light of their own configurations.

And again. In the three.js editor. The editor (and the code sources) is scary complicated to me, not to mention all the grief. So now I have this 800 line json file and have to figure out what to do with it. No snickers. I'm just trying to practice a bit. A few editor questions, like how do I select more than one object at a time? How should I save and use the scene?

Properly ordering the tiles seems to be the next in order. I should note that each tile is easily visible - and clickable - in the ortho view. Hovering over any would bring up a reduced image in a side pane - I think you described that. Actual clicking launches the editor - OK. The table configuration fills the screen, while the ortho fills just the center screen and allows a side pane.

I get enthusiastic too. You can always tell me to sit in a corner.

LongtimeAirman wrote:A few editor questions, like how do I select more than one object at a time? How should I save and use the scene?

There is no concept of selection in Three.JS. That is entirely up to you as the application developer. What it means to be selected, how you show that something is selected, how you actually select/deselect something.

Programmatically selecting an entity:

Assuming you want the user to click (or press if touch device) the scene to select/deselect entities, you need to look into picking. Picking is a concept based on ray-tracing where we take, what is usually, a 2D point on the screen and convert it into a ray that projects into the scene from the current camera position (you can use any ray you want, not limited to the camera). Any entity that is marked as pickable (depends on the 3D API, some do not have a concept like pickable) that intersects that ray will be returned to you and then you must determine which one you actually want to select. Please note that the entity you do select may not actually be the entity that was picked. For example, in the AV, the entities returned from a picking operation are protons and neutrons but I don't want to select them, I want to select the atom they are a part of. Therefore, I traverse up the scene hierarchy from that proton/neutron until I find the entity that I want to select.

Showing what is selected:

This really depends on your application. In the case of AV, I created a way to alter the colors used by parts of an atom so that I could make everything white, for example. This is accomplished through THREE.Material objects. A Material stores all information about what a 3D object looks like. Color, texture, bump maps, rendering choices and many more things are stored in a Material (there are many different types of Material for specific purposes). Materials can, and should, be shared, where appropriate. When you first start out programming 3D apps, you tend to create every object as its own thing and there is no sharing going on but it is more efficient to share when you can.

A 3D object (or Mesh) contains a Geometry and a Material. The Geometry tells the system where the vertices are for this object and the Material tells it how to render those vertices and the space between them. If you have 2 squares in your app, then you can share the same Geometry object between them to save memory and rendering time. They don't have to remain the same size as we can place these squares into THREE.Group objects and alter their position, rotation and scale through their Group rather than specify unique Geometry for each. Actually, I think you don't even need the Group as the Mesh has its own position, rotation and scale values that you can manipulate.

The Material may be shared between objects that look the same. If we want both of our squares to be blue, then we can create 1 Material that specifies the color blue and then assign it to both of the squares. Now, let's say that the user has made some change through your interface that changes the squares to yellow. We only have to change the color on the 1 Material object and both squares will change. If we wanted to only change the color of 1 of the squares, then we would need to have a Material object per square.

So you need to be clear about what you are selecting and how you want to present it. In AV, I know that I want to select Atoms so I apply my Materials from this point in the code so that all lower level entities get the same Material if they are the same type of entity. That is, any proton stack with 2 protons will get the same Material (blue) and any proton stack with 3 protons would get a different Material than a 2 proton stack, but all of those stacks get the same one (purple). So in effect, I have 6 different Materials for every Atom (there are actually others, but they are irrelevant to this discussion) which are all applied to the protons based on the size of the stack they are in. When an Atom is selected, I just set all of these Materials to be white. When it is deselected, I set them back to their proper colors. This is much easier and more efficient than trying to traverse through every entity in the Atom to change its color.

You may be thinking that all proton stacks with 2 protons are colored the same and so we could use only 6 Materials for the entire application, but this is wrong (in this instance, perfectly fine in others). We need a way to differentiate selected Atoms from unselected Atoms and we are doing that through the color, so we need to separate everything at the level of the selected entities (Atoms in this case). Otherwise, if we used only 6 Materials, then changing the color would change the color of every Atom, regardless of whether it was selected or not.

Determine if an entity is selected:

We usually need to know, in the code, what is selected and what is not., Otherwise, what is the point of selecting them? There are many ways to do that and you need to figure out what is the best approach for your app. It can be as simple as declaring a variable that is an array of the selected entities and you add to and remove from that array as they are selected or deselected. This allows you to quickly find all selected entities just be iterating through the array. Another approach, which I use in AV, is to have a property on your selectable entities that marks them as selected or not. This does mean that you have to iterate through all entities to find the selected ones, but sometimes you need to do that anyway so it is not a big loss. It also depends on how many things you want to be able to select. If it is a large number, or you have a large number of entities, then an array of selected entities might be better.

When the user actually selects an entity, you need to determine if they are deselecting any currently selected entities or if they are adding to the selection. I use the control key for this such that if the control key is down when an Atom is selected, then it adds to the selection, but if it is not down, then all currently selected Atoms are deselected first. This is what most operating systems do for multiple selection so it is best to remain consistent with user experience.

The Scene

The Scene is not really an object that you need to worry about. It is just the top node of the hierarchy and is used to link your 3D objects to the 3D API. That is the strict definition of the Scene but you may be using the term in a more general sense to mean all of your 3D objects, which I will call scene (upper-case is specific, lower-case is generic). In the latter case, if you want to save the state of your objects, then you need to traverse the Scene and store everything in your objects that you want saved. You could save this into some variable as an object hierarchy which you could then convert into JSON (call JSON.stringify( <object> )) and save it somewhere. Then you need code that can read that in and apply it to your Scene objects. You read the contents of the save as a string and convert it into a JS object by calling JSON.parse( <string> ). Then you use that object to change your 3D objects.

Actually saving and loading data is a bit troublesome in HTML because of security concerns. In HTML5, you can save and load files from the client machine but I have had trouble getting this to work across different browsers. Usually, a back-end server is involved so you just send the data to be saved to the server which then sends it back to the browser for it to save. Loading is a bit more difficult but kind of the same. You need to create a UI that allows the user to select a local file and upload it to the server and figure out how to get that data into your application. Probably just through the response to the upload request.

Other than that, you can present the content to be saved as text to the user which they can copy out and save in a file themselves. Similarly, you create a place for the user to paste content which you then parse and apply to your scene. This is what I did with the Element JSON data in AV as it is quick and easy to get setup.

Thanks Nevyn, It's making more and more sense. I appreciate the time and effort. MM physics animations is a wonderful pursuit. I'm trying to catch up.

Picking was presented, and an example used. I didn't realize the ray-tracing aspect. I recognize various renderers, but not their limitations. I found and started another series of three.js examples from cvdlab. Mr. Doob said "animation for dummies", I've got to agree. The whole scene is falling into place. Aside from Boids, I'm not trying to take on any additional developer responsibilities just yet.

What do you think of the tile configuration idea?

.

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.

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

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

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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.

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

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
https://milesmathis.forumotion.com/t87-magnetic-fields_rotating-vortices

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

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.