Miles Periodic Table with Standard Periodic Table reference

May need to skip this piece then. I'll upload a new Physics db with the .dll included.

Sorry LTAM for the .dll hassles with this. Here is the latest .bak file with it working apparently.

https://mega.nz/file/y4U1HaAb#_MgQipcyrvuY4E4XRaHu8adImbgV6VHr7Kf_A2kKZhM

.

Cr6 wrote. Sorry LTAM for the .dll hassles with this. Here is the latest .bak file with it working apparently.

No problemo Cr6, you’ve added transitive closure! After some thought or brief moment of doubt, you dealt with my dll difficulty perfectly.

My local database has been restored using 20230802Physics.bak. The image shows a small portion of my machine's LTAMKey query you posted on 25 July at 2:04 am. TransitiveClosure is present, listed under Assemblies as in your 31 July image.

I also ran the pivot query you posted Jul 25, 2023 at 2:28 and obtained a 1,730 row, 1-118 AtomNumber and sometimes very odd slotNumberBinding value I’ll need to think about.

Next, I executed the CREATE vwAtomicPivotedAtomCounts query you posted on Jul 28, outputting 105,179 rows in 2 min 13 sec which also requires study.

I certainly cannot follow most of your ideas and how you intend to get there (to machine learning and beyond!) but I do have a better appreciation and understanding of the ‘Physics’ database schema.

The current problem I recently noted – given our current complete sets of all possible atomic bonds for each valid molecule (a list greater than the total number of atoms in that molecule), we need to identify any or all valid specific atomic-bond sub-sets equal to the number of bonds in that molecule. There could be many solutions to a molecule's total bond set. I suppose that would be best handled by the database itself – hence, as you’ve pointed out, the need for a transitive-closure property.

I’m no help with SQL, and it looks like you're getting close to a solution. Please correct me if I’m wrong, it just occurred to me that this particular problem may also be solved using networkX. Granted, any networkX solution would be unnecessary if the database provided every molecule’s atomic-bond solution set. As a learning opportunity, having a specific goal allows me to follow your oft-repeated suggestion to get back to work on a Jupyter Notebook molecular graph.
.

Hi LTAM,

Yeah the TCC function might need a second look. It is pretty fast and can pivot a query well. Still working with it to see if it can do what is needed to allow a full combination of atoms with slots.

Btw, I was able to install do a pip install jupyter labs and can render the Atom3.ipynb file successfully.  Had to install the D3.js extension for jupyter labs 3.6. They now have an OpenAI plug-in with jupyter labs.  I can only get this to build in Linux though.

I did notice something that we might need to really look at.  If Miles layout can allow bonds between say Helium and Mercury with particular slots yet this doesn't exist in literature (or like how can this "connect" in the real world)... how to include/exclude these via conditions/rules? Working with Networkx as well.

Actually, I found that Chemspider has HgHe "bonding" here:
https://www.chemspider.com/Chemical-Structure.28719965.html?rid=fc21c26e-c9ec-43bb-b164-2069d990d0e7&page_num=0

Looking at these two queries to find out where Mathis style bonds don't have a match with ChemSpider:

Code:


-- Alpha Query. May need more revision for accuracy. Looking for "Bonds" between two atoms that exist in ChemSpider but not Miles' "Bonding" and vice versa.

SELECT
AtomicNumberSrc, AtomicNumberDest, SlotNumberSrc, SlotNumberDest,
ElementSrc, ElementDest, LTAMKeySrc, LTAMKeyDest, CanBindSrc, CanBindDest ,
AtomicSymbolSrc, AtomicSymbolDest
FROM
[dbo].[vwMathisMoleculesBindLogicXYZ] X
where Not EXISTS (
SELECT *
FROM
[Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] B
where
      X.[LTAMKeySrc]          = B.[LTAMKeySrc]        and
      X.[LTAMKeyDest]  = B.[LTAMKeyDest]  and
      X.[AtomicNumberSrc]  = B.[AtomicNumberSrc]   and
      X.[AtomicNumberDest]  = B.[AtomicNumberDest]  
 AND X.ProtonsSrc > 0
 AND X.ProtonsDest > 0
 AND X.AlphaTypeSrc > 0
 AND X.AlphaTypeDest > 0
 AND B.ProtonsSrc > 0
 AND B.ProtonsDest > 0
 AND B.AlphaTypeSrc > 0
 AND B.AlphaTypeDest > 0
 and B.CanBindSrc=1 and B.CanBindDest =1
 AND (
 B.SlotNumberSrc NOT IN (
 18
 ,19
 )
 OR B.SlotNumberDest IN (
 18
 ,19
 )
 )
 AND (
 X.SlotNumberSrc NOT IN (
 18
 ,19
 )
 OR X.SlotNumberDest IN (
 18
 ,19
 )
 )
and X.ElectronsSrc + X.SlotSpinSrc + X.ElectronsDest + X.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
and B.ElectronsSrc + B.SlotSpinSrc + B.ElectronsDest + B.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
)
and X.CanBindSrc =1 and X.CanBindDest =1  
and  X.LTAMKeySrc not like '%N%' and LTAMKeyDest not like '%N%'
and X.AtomicNumberSrc > 5 and X.AtomicNumberDest > 5
and (X.LTAMKeyDest not like 'A1%' or X.LTAMKeyDest not like 'A1%')
order by 1,2,3,4,5,6
GO

SELECT
AtomicNumberSrc, AtomicNumberDest, SlotNumberSrc, SlotNumberDest,
ElementSrc, ElementDest, LTAMKeySrc, LTAMKeyDest, CanBindSrc, CanBindDest ,
AtomicSymbolSrc, AtomicSymbolDest
FROM
[dbo].[vwMathisMoleculesBindLogicXYZ] B
where Not EXISTS (
SELECT *
FROM
[Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] X
where
      X.[LTAMKeySrc]          = B.[LTAMKeySrc]        and
      X.[LTAMKeyDest]  = B.[LTAMKeyDest]  and
      X.[AtomicNumberSrc]  = B.[AtomicNumberSrc]   and
      X.[AtomicNumberDest]  = B.[AtomicNumberDest]  
 AND X.ProtonsSrc > 0
 AND X.ProtonsDest > 0
 AND X.AlphaTypeSrc > 0
 AND X.AlphaTypeDest > 0
 AND B.ProtonsSrc > 0
 AND B.ProtonsDest > 0
 AND B.AlphaTypeSrc > 0
 AND B.AlphaTypeDest > 0
 and B.CanBindSrc=1 and B.CanBindDest =1
 AND (
 B.SlotNumberSrc NOT IN (
 18
 ,19
 )
 OR B.SlotNumberDest IN (
 18
 ,19
 )
 )
 AND (
 X.SlotNumberSrc NOT IN (
 18
 ,19
 )
 OR X.SlotNumberDest IN (
 18
 ,19
 )
 )
and X.ElectronsSrc + X.SlotSpinSrc + X.ElectronsDest + X.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
and B.ElectronsSrc + B.SlotSpinSrc + B.ElectronsDest + B.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
)
and B.CanBindSrc =1 and B.CanBindDest =1  
and  B.LTAMKeySrc not like '%N%' and LTAMKeyDest not like '%N%'
and B.AtomicNumberSrc > 5 and B.AtomicNumberDest > 5
and (B.LTAMKeyDest not like 'A1%' or B.LTAMKeyDest not like 'A1%')
order by 1,2,3,4,5,6

.
'Physics' database changes. The updated database requires a review, here are the latest changes.
New Tables:
AtomicOrbitalsinMilesDetailSummary.
AtomicMilesMathisOrbitalsMissing.
ElementsPositions2.
New Views:
gJSONNodes.
MathisGraphBondsTCC.
vwAtomicMilesMathisOrbitalsDetailAllBondsDupeAtoms.
vwAtomicOrbitalsCarbonCarousel.
vwAtomicPivotedAtomCounts.
vwSysRefreshViews
Old Prob. gAllowedBonds. Invalid object name error mentioned last time still has a problem.

Code:

////////////Updated 4-5 Aug 2023////
#Graph Tables.
gMathisPeriodicTableAtomLTAM. 1,530 rows, 17 cols. Familiar data with $node schema info/code
/////////////////////////////////
#Tables.
AllTable.  335 rows -  4 cols. Quantity, Value, Uncertainty, Unit.
 No primary key. 355 atomic constants and relationships.
AtomicMilesMathisElementsPositions. 1710 rows and 88 cols. Haven't figured it out yet.
AtomicMilesMathisFormulas. 4,790 rows, 9 cols. ZID, Formula, CurrentAtom, NextAtom1, … , NextAtom6.  
AtomicMilesMathisMoleculesBindLogicXYZ. 883,986 rows, 166 cols. Each row is a bond. 1 min 3 sec.
AtomicMilesMathisOrbitalBondsParsed. 4,879 rows, 64 cols. ZMolecule, CurrentAtom, NextAtom1, … , 8p, 9s, 9p, ZID.
AtomicMilesMathisOrbitalParsed. 14,483 rows, 47 cols. ID ZMolecule ZItem ZFormula ... .
AtomicMilesMathisOrbitalsDetailAllBonds. 810,891 rows, 182 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 8 secs. 1 min 16 sec
AtomicMilesMathisPeriodicTable. 2,983 rows, 17 cols. UID AtomicNumber AtomicSymbol ... color. Pt data in a strange order?
AtomicMilesMathisPeriodicTableBase. 157 rows, 153 cols. RemainderAlphaLevel ... 9p. Mainly Atomic data (?).
AtomicMilesMathisProtonBalance.  157 rows, 12 cols. Carousel ... AlphaTypeRemainder
AtomicOrbital. 21,161 rows 46 cols. ID ZMolecule ZItem ZFormula ... .
AtomicOrbital1. Zero rows. 46 cols.  ID ZMolecule ZItem ZFormula, … , 9p. 00:00:00.
NEW: AtomicOrbitalsinMilesDetailSummary. 563,022 rows, 172 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 00:00:37.
AtomicRDKit. 92 rows -  38 cols. Each atom’s (1-92) select atomic values.
AtomicSourcesRDKit. 26 rows -  5 cols (PropertyID, property, notes, units and source).
AtomPeriodicTableAtomLTAMKey. 132 rows, 5 cols. ID LTAMKey CanBind Electrons AlphaType.
Chemspider. 66,281 rows. 5 cols. UID Line Content ChemspiderID LoadDate.
 Content includes various Chemspider molecular names. 
Circle. 36001 rows - 360 degrees in hundreths. Cols x y and z are NULL. Replaces rotation calculations with a table lookup.
Compounds. 262 rows - 3 cols. No, Compound, Formula.
CompoundsSmiles. 1351 rows - 6 cols. SMILES info(PID,id,EntryName,SMILES,MW,Selectivity_Index).
ElementAbundance. 78 rows – 9 cols. 78 Elements’ crustal abundances.
ElementsPositions. 1710 rows – 87 cols. 90 element data including SL diags.
NEW: ElementsPositions2. 1710 rows – 86 cols. Don't know which col was dropped.
EnergyLevel. 6 rows – 7 cols. EnergyLevel,ShellLetter,ElectronCapacity,s,p,d,f.
FormulaSuperConductor. 176 rows of FormulaSuperConductors
GraphMilesAtomNode – 157 rows - Through Atomic number 153. 8 columns (AtomicNumber, AtomicSymbol, Element,
GraphTempAtomNode. 90 rows, Up to Thorium. 8 columns (AtomicNumber, AtomicSymbol, Element,
 OrbitalGroup, Protons, Neutrons, GroupNumber, Period).
Ions. 64 rows – 5 cols. IonID,Ion,Charge,AlphaNm,Name
Mathis. 1282 rows – 5 cols. UID, AtomicNumber,Position,SlotNumber,AlphaType
MilesMathis. 12 rows – 4 cols. ID,Description,RawCalculation, Set2. Miles calcs.
MilesMathisPeriodicTable. 2983 rows – 18 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD. 2983 rows – 15 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD2. 2993 rows, 18 columns.
nci. 150 rows – 2 cols. Compoundid, smiles.
Numbers. 65,536 rows – 1col, Number. Rows 1 to 65536 containing Number 0 to 65,535.
Orbital1. 344 rows – 27 cols. Atomic electron orbital info.
OrbitalMatrix. 157 rows – 30 cols. 163 elements with atomic electron orbital info.
Orbitals. 172 rows – 13 cols. 172 elements’ atomic electron orbital info.
PeriodicTable. 118 rows – 74 cols. 118 elements’ atomic data.
PeriodicTableGrouping. 110 rows – 30 cols. 110 elements’ atomic data.
PeriodicTableState. 112 rows – 12 cols. 112 elements’ atomic data.      
PeriodType. 10 rows – 2 cols. Period, PeriodTypeDescription - Atomic types, alkaki metals to noble gases.      
Species. 105,179 rows, 4 cols. ID, Molecule, Formula, Detail. Like Chemspider.
Species_Stg. 1998 rows – 3 cols. Molecule, Formula, Detail.      
Species20230212. 103,185 rows. 4 cols. ID, Molecule, Formula, Detail. 1 Sec.
sqlmol_bond_type. 0 rows. btid symbol.    
sqlmol_compound. 150 rows. compoundid, smiles  cols.    
sqlmol_compound_bonds. 0 rows. cbid, compoundid, btid, ceid1, ceid2.  
sqlmol_compound_elements. 0 rows. ceid, compoundid, atom, nodeid.    
sqlmol_compound_hfbonds. 0 rows. compoundid, chbid, ceid, cbid, btid, parseid.
sqlmol_element_type. 0 rows. symbol.                                
sqlmol_hfbond_type. 0 rows. btid, symbol.                                
sqlmol_symbol. 28 rows. 3 cols, code, type, Aromaticity.                              
STG_Orbital. 172 rows. 28 cols. 172 elements’ electron orbital data.

/////////////////////////////////
#Views.

NEW: AtomicMilesMathisOrbitalsMissing. Zero rows, formula col header .
AtomicOrbitalBonds. 9028 rows. 53 cols. Atomic details and orbitals. All ZmoleculeOrder values equal 1.
AtomicPivotedByAtomicNumber. 3,809 rows. 92 cols. Atom1-Atom90 cols. 4 secs. 
Function_Assist_GETDATE. 1 row. 1 col, GetDate. Gives the date and time of the query function.
Function_Assist_RAND. 1 row. 1 col, RAND. Returns a random value between 0 and 1.

gAllowedBonds. Msg 208, Level 16, State 1, Procedure gAllowedBonds, Line 6 [Batch Start Line 2]
 Invalid object name 'dbo.gPeriodicTableAtomLTAM'.
 Msg 4413, Level 16, State 1, Line 5
 Could not use view or function 'dbo.gAllowedBonds' because of binding errors.

NEW: gJSONNodes. 215,301 rows. 1 col, Nodes. All molecular bonding sites?
MathisEdgesGraphML. 247,747 rows. 6 cols. RowN, Source, Target, srcElement, trgElement, edges. 10 secs.  
NEW: MathisGraphBondsTCC. 2,677 rows. 8 col, Nodes. All molecular bonding sites?
MathisNodesEdgesAllBinds. 175,964 rows. 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, … , Color.
MathisNodesGraphML. 896 rows. Nodes.      
MilesMathisCalculus. 50 rows. 5 cols. Z, 2z, z3, NextNumber, MathisCalculus.      
vwAllTable. 335 rows. 4 cols. FloatValue, Quantity, Value, Uncertainty.        
vwAtomic. 391,741 rows. 160 cols. 50 seconds.
NEW: vwAtomicMilesMathisOrbitalsDetailAllBondsDupeAtoms. 391,741 rows 160 cols.
vwAtomicOrbital. 13,791 rows. 47 cols. ID, ZMolecule, Zitem, … , 9p, ZID.
vwAtomicOrbitalBonds. 4,736 rows. 56 cols. ZMoleculeOrder, CurrentAtom, ... , ZID.
 Atomic details and orbitals. All Zmolecule, Order values equal 1.
vwAtomicOrbitalPerm. 21,161 rows. 46 cols. ZID, ZMolecule, ZItem, … , 9p.
vwAtomicOrbitalsAllMiles. 2,557 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula. 17 seconds.
vwAtomicOrbitalsAllowed. 2,020 rows, 12 cols. MinAtomicNumberSrc, MaxAtomicNumberSrc,
 MinAtomicNumberDest, MaxAtomicNumberDest,nAtomicSArc, ... , AlphaTypeDest.
NEW: vwAtomicOrbitalsCarbonCarousel. 494 rows, 5 cols. ElementSrc, ElementDest, cnt, LTAMKeySrc, LTAMKeyDest.
 Every row contains at least 1 carbon.
vwAtomicOrbitalsinMiles. 2,544 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula. 23 secs.
vwAtomicOrbitalsinMilesDetail. 13,791 rows. 47 cols.  ID, ZMolecule, Zitem, … , 9p, ZID.
vwAtomicOrbitalsinMilesDetailAllBonds. 633,369 rows. 174 cols. CurrentAtom, NextAtom1, … ,
 Formula, … , SlotDirectionElectronBond. 01:17:21.
vwAtomicOrbitalsinMilesDetailCarbonFilteredOut. 156,668 rows. 170 cols. CurrentAtom, NextAtom1, … , Formula. 00:25:10.
vwAtomicOrbitalsinMilesDetailSummary. 742,355 Rows, 180 cols. SlotDirectionSrc, SlotDirectionDest,
 SlotDirectionElectronSrc, SlotDirectionElectronDest, SlotDirectionElectronBond2, ZID, Formula,
 CurrentAtom, NextAtom1, … , e6zDest. 00:01:08.
vwAtomicOrbitalsinMilesDetailSummaryPeriodicDetail. 1,620,765 rows and 328 columns. ZID thru 9p. 00:12:22. A lot of info.
vwAtomicOrbitalsinMilesDetailSuperConductors. 110,524 rows, 170 cols. CurrentAtom, NextAtom1, … , e6zDest.
vwAtomicOrbitalsNotinMiles. 63 rows. 8 cols. CurrentAtom, NextAtom1, … , Formula. 00:00:18.
vwAtomicOrbitalsNotinMilesAll. ? rows and ? cols. Old: With reasons: SlotOrientation and BindLogic. 32 secs.
 Msg 245, Level 16, State 1, Line 22
 Conversion failed when converting the nvarchar value 'R' to data type int.
vwAtomicOrbitalsNotinMilesBySlotOrientation. 789 rows and 170 cols.
 Msg 245, Level 16, State 1, Line 22
 Conversion failed when converting the nvarchar value 'R' to data type int.
vwAtomicPeriodicTableLTAMSpins. 13,740 rows 177 cols. ID, ZMolecule, … , SL4. 00:00:04
vwAtomicPivoted. 33,740 rows. 92 cols. ID, ZMolecule,  … , MolOrder. Took 4 secs to run this query. 00:00:03
NEW: vwAtomicPivotedAtomCounts. 105,179 rows, 23 cols. ID, ZMolecule, ZFormula, Atom1, AtomNumberCount10. 00:02:04
vwChemSpider. 4,774 rows, 3 cols. ChemspiderID, Formula, Molecule. 00:00:00
vwCircle. 36001 rows. 1 col. Degree. Looks like random rotations (with select *) between zero
 and sequential rotations when using the select top 1000 values.
vwDeutrium. 85 rows. 4 col. ID, Molecule, Formula, Detail. 00:00:00
vwElementsPositions. 1710 rows. 89 cols. AtomicNumber, AtCurrentAtom, NextAtom1, … , Formula. 0 seconds.
 Element, AtomicTuple, … , SL4,LTAMKey, BindKey.  00:00:00
vwMathisLTAMMolecules. 397,328 rows. 121 cols. ZID, ZMolecule, … , 9p. 00:00:22.
vwMathisMaxSlotPivoted. 90 rows. 28 cols. AtomicNumber, AtomicSymbol, … , Slot19. 00:00:00.
vwMathisMoleculesBindLogic. 35,509 rows. 162 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest. The query took 3 secs.
vwMathisMoleculesBindLogicXYZ. 718,171 rows. 165 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest, SlorDirectionElectronBond. 00:00:46.
vwMathisMoleculesFullBindLogic. 4,174,262 rows. 254 cols. BondType, AtomicNumber, AtomicSymbol Dest, … , e6zDest. 00:07:17.
vwMilesMathisElectronBondingMapped, 2983 rows. 179 cols. UID, mOrbitalGroup, mProtons,mNeutrons, , ZSeqNo, ZItem, ZElement, ZFormula, … , 9p. 00:00:01.
 Resembling AtomicOrbitalBonds with plenty of potential ml atomic attributes.
vwMilesMathisPeriodicTable. 2,983 rows. 17 cols. UID, AtomicNumber, AtomicSymbol, … , Color. 00:00:00.
vwMilesMathisPeriodicTablePivoted. 2,983 rows. 35 cols. UID, AtomicNumber, AtomicSymbol, Element, , … , 19. 00:00:00.
vwMolecule. 829,361 rows. 8 cols. ID, Molecule, Formula,  Item, RW, ASCIINum, Number, CharPlaceType. 00:00:41.
vwMoleculeAtomicWeight. 4,744 rows. 7 cols. ID, MolecularWeight, Formula,  Molecule, Number, NistLookup, ChemspiderLookup ,Total1stIonization. 00:00:02.
vwNumbers. 2,476,099 rows. 1 col. n. 1-2,476,099. 00:00:13.
vwPeriodicTable. 157 rows. 153 cols. RemainderAlphaLevel1, REM2, REM3, … , 9p. 00:00:05.
vwProtonBalanceMathis. 157 rows. 12 cols. Carousel, AlphaProtonCarouselRemainder, Alphas, Element, AtomicSymbol, Period, … , AlphaTypeRemainder.
vwServerIPAddress. 1 row, 7 cols. net_transport protocol_type auth_scheme ... public_nrt_transport
NEW: vwSysRefreshViews. 1 row, 7 cols. net_transport protocol_type auth_scheme ... physical_net_transport
vwSysTableSizes. 55 rows, 6 cols. SchemaName TableName RowCounts Used_MB Unused_MB Total_MB


Cr6 wrote. I did notice something that we might need to really look at. If Miles is allows bonds between say Helium and Mercury with particular slots but this doesn't exist in literature (or like how can this "connect" in the real world)... how to include/exclude these via conditions/rules?


Airman. I entered the Helium and Mercury query above before your latest post. It shows 15 possible bond sites to consider for HeHg, sorted according to Hg’s slot number. Using paint, I added yellow highlighting to the image where all 3 binding values, ‘isValid’, CanBindSrc, and CanBindDest, are equal to 1. Those 8 ‘good’ bonding slots are: 2, 3, 10, 11, 12, 13, 14, 15. The following data is taken from the above output for those 8 possible bond sites. Under columns:
LTAMKeySrc, LTAMKeyDest, SlotDirectionElectronBond
A2Y6A, A1Z2A, AAAA
A3Y6A, A1Z2A, AAAA
B10Z4R, A1Z2A, BRAA
T11Z4R, A1Z2A, TRAA
T12Z4L, A1Z2A, TLAA
B13Z4L, A1Z2A, BLAA
T14Y4L, A1Z2A, TLAA
B15Y4R, A1Z2A, BRAA
The SlotDirectionElectronBond data appears deficient and needs correcting.

Hg and He aside, I think we need another alpha rule or two.


Once again, please pardon 2d slotlayout diagrams for a ‘relatively simple’ 3d discussion. Mercury and Helium’s SL’s are shown at the top left. The eight remaining SL’s show Helium’s two proton alpha added to each of the eight possible Hg bonding slots. When He is added to Hg’s empty hook positions 2 or 3, the alpha retains it’s two-proton integrity. When the Helium alpha is added to Hg’s  six each 4 proton stack slots 10-15, one side or the other, the result is a 6 proton stack. They are unlabeled and need to be filled with the correct slot data.

In Diatomic Hydrogen, Miles reduced the problem of bonding protons with accompanying electrons to it’s barest essentials in order to describe what electron-configuration and proton-spin combinations make for valid or invalid proton/proton bonds. If I recall correctly, Miles indicated that a proton stack can only support a single change in proton spin directions; two parallel alphas cannot parallel bond into a single 4 proton stack since the resulting stack would contain more than a single proton spin direction change.
In this project we have an extra degree of difficulty. We’ve defined all atomic slots according to the +x, +y and +z directions and we need to know when a given slot has been flipped in order to properly evaluate a bond’s validity.

LR or RL Alphas. Some z oriented alphas contain left (top proton) and right (bottom proton) spinning protons. The remaining z oriented alphas contain right (top) and left (bottom) spinning protons. We currently indicate A, meaning ‘both L and R’. We need to assign either of those two types of alphas to all our atomic alpha designations, LR or RL. Any LR and RL alphas may only bond with TBRL protons and proton stacks. We need to track whether the TBRL protons are right-side up or upside down in evaluating molecular bonds, it seems LR or RL alphas remain the same whether they are right-side up or upside down.


In this diagram, it appears that RL type alphas may only bond with TR or BL proton stacks, at either the proton stack top or bottom, not both. LR alphas appear to only bond with the remaining BR or TL proton stacks, again, at either the proton stack top or bottom, not both.
 
With respect to Hg and He, I suspect that the charge flow imbalance due to the resulting 6 proton stack, comprised of 1 L and 5 R spinning protons or vice versa, would not be conducive to bonding. I would guess the most likely HeHg bond bond would be at Hg slots 2 or 3.  
 
Nice to see AB3 working with Jupyter Lab.

You seem a bit urgent and I'm anxious to point out a possible error, so I decided to post this before looking at your two last two Select queries.

What do you think? Do you agree I should add another alpha type to our atomic data?
.

.

I’m grateful for any incremental progress and every ‘aha’ moment. Realizing that alphas can take two possible forms, RL or LR qualifies.

Whether an alpha is RL or LR hardly matters when it comes to displaying individual atoms. Legitimate charge field molecular rules however require knowing the difference. Shared slot bonds between alphas (of either type) and proton stacks with up to four protons sharing a single spin direction must follow the same TBRL rules. Likely half of our molecules’ shared slot proton/alpha bonds are wrong and we would see that if we rendered them.

Adding a new alpha value to the existing atomic data is easy. ‘A’ is used in two columns, ‘Electrons’ and ‘SlotSpin’. ‘A’ can be left alone, knowing that it will end up representing, say, just the RL alpha type. The new LR type alpha might be represented by a capital ‘V’, a new unique character, that kind of resembles an upside down capital A. I can replace half of all our atomic ‘A’s to ‘V’s.  The second form of He might even be added as a new atomic element(?).

I imagine changing ‘Physics’ to accommodate the new alpha type requires considerably more thought and effort. You’re our database expert and understand that far better than I do. I’m happy to discuss and follow any directions you think necessary.  
.

.

On Mon Aug 07 Cr6 wrote. Looking at these two queries to find out where Mathis style bonds don't have a match with ChemSpider:

Code:

USE [Physics]
GO

-- Alpha Query. May need more revision for accuracy. Looking for "Bonds" between two atoms that exist in ChemSpider but not Miles' "Bonding" and vice versa.

SELECT
AtomicNumberSrc, AtomicNumberDest, SlotNumberSrc, SlotNumberDest,
ElementSrc, ElementDest, LTAMKeySrc, LTAMKeyDest, CanBindSrc, CanBindDest,
AtomicSymbolSrc, AtomicSymbolDest
FROM
[dbo].[vwMathisMoleculesBindLogicXYZ] X
where Not EXISTS (
SELECT *
FROM
[Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] B
where
      X.[LTAMKeySrc]  = B.[LTAMKeySrc]  and
      X.[LTAMKeyDest]  = B.[LTAMKeyDest]  and
      X.[AtomicNumberSrc]  = B.[AtomicNumberSrc]   and
      X.[AtomicNumberDest]  = B.[AtomicNumberDest]  
 AND X.ProtonsSrc > 0
 AND X.ProtonsDest > 0
 AND X.AlphaTypeSrc > 0
 AND X.AlphaTypeDest > 0
 AND B.ProtonsSrc > 0
 AND B.ProtonsDest > 0
 AND B.AlphaTypeSrc > 0
 AND B.AlphaTypeDest > 0
 and B.CanBindSrc=1 and B.CanBindDest =1
 AND ( B.SlotNumberSrc NOT IN ( 16, 17, 18 ,19 ) OR B.SlotNumberDest IN ( 16, 17, 18 ,19 ) )
 AND ( X.SlotNumberSrc NOT IN ( 16, 17, 18 ,19 ) OR X.SlotNumberDest IN ( 16, 17, 18 ,19 ) )
 and X.ElectronsSrc + X.SlotSpinSrc + X.ElectronsDest + X.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
 and B.ElectronsSrc + B.SlotSpinSrc + B.ElectronsDest + B.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
)
and X.CanBindSrc =1 and X.CanBindDest =1  
and  X.LTAMKeySrc not like '%N%' and X.LTAMKeyDest not like '%N%'
and X.AtomicNumberSrc > 5 and X.AtomicNumberDest > 5
and (X.LTAMKeyDest not like 'A1%' or X.LTAMKeyDest not like 'A1%')
order by 1,2,3,4,5,6
GO

SELECT
AtomicNumberSrc, AtomicNumberDest, SlotNumberSrc, SlotNumberDest,
ElementSrc, ElementDest, LTAMKeySrc, LTAMKeyDest, CanBindSrc, CanBindDest ,
AtomicSymbolSrc, AtomicSymbolDest
FROM
[dbo].[vwMathisMoleculesBindLogicXYZ] B
where Not EXISTS (
SELECT *
FROM
[Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] X
where
      X.[LTAMKeySrc]  = B.[LTAMKeySrc]  and
      X.[LTAMKeyDest]  = B.[LTAMKeyDest]  and
      X.[AtomicNumberSrc]  = B.[AtomicNumberSrc]   and
      X.[AtomicNumberDest]  = B.[AtomicNumberDest]  
 AND X.ProtonsSrc > 0
 AND X.ProtonsDest > 0
 AND X.AlphaTypeSrc > 0
 AND X.AlphaTypeDest > 0
 AND B.ProtonsSrc > 0
 AND B.ProtonsDest > 0
 AND B.AlphaTypeSrc > 0
 AND B.AlphaTypeDest > 0
 and B.CanBindSrc=1 and B.CanBindDest =1
 AND ( B.SlotNumberSrc NOT IN ( 16, 17, 18 ,19 ) OR B.SlotNumberDest IN ( 16, 17, 18 ,19 ) )
 AND ( X.SlotNumberSrc NOT IN ( 16, 17, 18 ,19 ) OR X.SlotNumberDest IN ( 16, 17, 18 ,19 ) )
 and X.ElectronsSrc + X.SlotSpinSrc + X.ElectronsDest + X.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
 and B.ElectronsSrc + B.SlotSpinSrc + B.ElectronsDest + B.SlotSpinDest  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
)
and B.CanBindSrc =1 and B.CanBindDest =1  
and  B.LTAMKeySrc not like '%N%' and B.LTAMKeyDest not like '%N%'
and B.AtomicNumberSrc > 5 and B.AtomicNumberDest > 5
and (B.LTAMKeyDest not like 'A1%' or B.LTAMKeyDest not like 'A1%')
-- And ElementSrc = 'mercury'
order by 1,2,3,4,5,6

The Alpha Query - after making changes 1 and 2 below.

Tried reviewing the Alpha Query, actually two Select queries I’ll call Top and Bottom. Both output 125,238 rows and 12 columns with the same names.

Two typo sets I tried correcting that need your coordination review/approval.

1. Removed several returns to reduce the script containing the first set of typos to single AND lines for an easier read. Both AND’s are included in both top and bottom queries. Hook slot positions 16 and 17 are missing. Replaced:

AND ( B.SlotNumberSrc NOT IN ( 18 ,19 ) OR B.SlotNumberDest IN ( 18 ,19 ) )
AND ( X.SlotNumberSrc NOT IN (18 ,19 ) OR X.SlotNumberDest IN ( 18 ,19 ) )

With:

AND ( B.SlotNumberSrc NOT IN ( 16, 17, 18 ,19 ) OR B.SlotNumberDest IN ( 16,17, 18 ,19 ) )
AND ( X.SlotNumberSrc NOT IN (16, 17, 18 ,19 ) OR X.SlotNumberDest IN ( 16, 17, 18 ,19 ) )

The changes had no effect on the query’s two output lengths.  

2. Missing 'X.' and 'B.'. In the Top Select changed:

and  X.LTAMKeySrc not like '%N%' and LTAMKeyDest not like '%N%'

to

and  X.LTAMKeySrc not like '%N%' and X.LTAMKeyDest not like '%N%'

And in the Bottom Select changed:

and  B.LTAMKeySrc not like '%N%' and LTAMKeyDest not like '%N%'

to

and  B.LTAMKeySrc not like '%N%' and B.LTAMKeyDest not like '%N%'

These changes had no effect on the two query output lengths.

The Top Select query ‘identifies’(?) the data from vwMathisMoleculesBindLogicXYZ as X, and data from AtomicMilesMathisOrbitalsDetailAllBonds as B. The Bottom Select query does the opposite, assigning
vwMathisMoleculesBindLogicXYZ as B and AtomicMilesMathisOrbitalsDetailAllBonds as X.  

Referring to the 'Physics’ Table and View info:
AtomicMilesMathisOrbitalsDetailAllBonds. 810,891 rows, 182 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 8 secs.
The AtomicMilesMathisOrbitalsDetailAllBonds table contains 291, 619 rows where WHERE CanBindSrc = 1 and CanBindDest=1 and IsValid =1; as well as 4,709 distinct formulas.
vwMathisMoleculesBindLogicXYZ. 718,171 rows. 165 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest, SlotDirectionElectronBond. 00:00:46.
vwMathisMoleculesBindLogicXYZ contains no formulas.

I assume that when you say Mathis style bonds you are referring to the data contained in vwMathisMoleculesBindLogicXYZ.

And when you say “have a match with ChemSpider” you are referring to AtomicMilesMathisOrbitalsDetailAllBonds(?).

I'm sure I'm missing something. Any clues?
.

Hi LTAM,

Thanks for looking at this again. I kind of threw it up on the forum without much validation.  I'll double check things a bit more before posting them here.  
What I was trying to reach for here were cases where we take Miles' Periodic Table with SlotNumbers and directions (e.g., RL, LR, etc.)  -- then see if there is a similar "find" in the version derived from Chemspider? And vice-versa by flipping the tables.

Overall I was trying to get at:

1. Tighten rules for known good bonds per Miles. SlotNumber, SlotType, Neutrons, Protons, Electrons, Slot Orientation (XYZ-V?), Can Bind Y/N.
Overall, I was looking to strengthen AND/OR logic with what is allowable.  This is still a work in progress.

2.  Throwing Miles' Periodic Table against Chemspider atoms/bonds to see what is left over (like
SELECT * KNOWNCHEMSPIDERORBITALs that are NOT IN (SELECT * FROM MATHIS' Bonds)

) and then look at these cases. Is this something even possible or real? Does it look valid per Miles. It is also to ensure the Views-Filters applied so far still hold valid and true. I know we are trying to 2-D something that is actually 3-D in dynamics. We can probably combine elements back for a lookup in the other table (%ElementSrc%ElementDest%) like in part of the '%Formula%'  in SQL or just use a RegEx function for matching either Python-SQL Function. Basically, can we get code to match/not match Miles' with "known bonds" in ChemSpider or [Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds].

Just kind of dorking around with these ideas.  Trying to get at "Show Valid Miles' bonds that are not in what has been loaded in Chemspider so far". There are a lot positional dynamics in play. I figured that Chemspider is saying "these are known good bonds" with their Formulas with epn logic-"electron sharing logic". Okay what does Miles have to prove it and how does it validly connect per Miles or not connect.  First beta attempt tbh. Was drinking a bit too. I tend to try wilder SQL after a few beers and think "can we see this?".

I'll delete the old graph stuff that isn't working from the tables/views. I deleted the source table because it started to get really big storage wise.  Like with Hg-He, I had no idea that it was in Chemspider as valid. I just saw the two elements stacked and thought it would be a good example of "is this possible?"-  like should these bond? Can Miles' allow it? In the real world you wouldn't think this was even possible. I'll look again at the Diatomic Hydrogen paper... thanks!

Networkx is the next Big Dork Project (BDP) just because it can allow more 3-D (multiple connections outside of just SQL 2-D) and it is usually quite fast.

By the way, I've added over 9,000 new formulas. Current counts. The stored procedure took about 2 hours to run. The table is at about 3 million rows. This is with the TopoMat data file added to Chemspider entries at  https://www.materialscloud.org/discover/topomat

Will upload a new DB this week after more validation-cleanup.

DistinctFormulas
13442
UniqueRowcounts
3016617

SELECT
 Count(distinct Formula) as DistinctFormulas,
 Count(1) as UniqueRowcounts
 FROM [Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds]

 order by 1

I may have to redo the horizontal ordering in this table since each element is alphabetically sorted instead of by position in the formula. Saw some issues with the sorting in earlier SQL code but probably can get it ordered correctly now. This is at a pretty a good point to stop now with adding new formulas if we are just using Desktop SQL Server 2022.

TopoMat developers wrote:
About TopoMat database
The database (version 0.1, 8-Aug-2018) contains 16705 unique entries, of which 4482 compounds show non-trivial Z2 indices. Each entry contains basic information about the materials, its crystal structure, Brillouin zone, calculated band structure, Wannier charge center plots (when available), and other data.

The crystal structures originate from ICSD [1] and COD [2] databases subject to the following pre-screening filters:

20 atoms or fewer in the unit cell;
even number of electrons per unit cell;
no rare-earth elements.
The first-principle calculations have been performed using the Quantum-ESPRESSO package [3] on experimental crystal structures without relaxation. Our computational methodology relies on the PBE exchange-correlations functional, pseudopotentials from the SSSP library [4], and take into account the spin-orbit coupling. The Z2 indices have been calculated using either the parity analysis for the centrosymmetric materials, or the Z2Pack methodology [5] for noncentrosymmetric crystal structures.

If you use this work please cite the following publication in progress:
G. Autès, Q. S. Wu, N. Mounet & O. V. Yazyev, “TopoMat: a database of high-throughput first-principles calculations of topological materials”, in preparation (2018).

.

Cr6 wrote. By the way, I've added over 9,000 new formulas. Current counts. The stored procedure took about 2 hours to run. The table is at about 3 million rows. This is with the TopoMat data file added to Chemspider entries at https://www.materialscloud.org/discover/topomat

DistinctFormulas
13442
UniqueRowcounts
3016617

SELECT
 Count(distinct Formula) as DistinctFormulas,
 Count(1) as UniqueRowcounts
 FROM [Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds]

 order by 1

Airman. Hi Cr6, 'Formulas' is just the first Topomat database column shown, was it difficult to ‘scrape’ or copy them? The Topomat site contains lots of alternative choices that suggests plenty of built-in database structure to choose from (including 3d). You must have enjoyed finding it. Did you find any inspirations?

I tried running the select query in order to see the ‘pre-Topo’ data totals.
DistinctFormulas
4709
UniqueRowcounts
810891

9,000 new formulas is a huge addition, almost twice as large as our previous 4,709 formula total, a lot more out there than I had come to expect. Topomat increases our Formulas count 2.85… times, and our unique row counts are increased 3.72... times. 3 Million rows seems about 2, 3, or 4 times larger than the pre-Topo Physics data as well. Shouldn't be a problem.

The Topomat homepage indicates 13,628 materials (formulas(?)), which is greater that 13,442. I suppose 13,442-9,000=4,442 Topomat formulas were already present in Physics’ 4,709 formula list(?). Did you and chemspider find formulas that Topomat doesn't list; maybe share that list with Topomat? Perhaps a couple hundred Topomat formulas didn’t meet ‘Physics’ formula constraints?

Sounds like you think we've got enough of all the “up to 8 atom type” molecules in the universe to work with for a while.

/////\\\\////////\\\\////////\\\\////////\\\\////////\\\\////////\\\\///

Elements-Positions3.csv Promethium, PM, Atomic number 61. Showing CA-SlotOrien, CB-SlotSpin, CC-TCount, CD-CanBind and CE … SlotLayout diagram columns.

Project update. I worked on the atomic data’s alpha slots. Please pardon all the excruciating details.

1. Corrected Elements-Positions2 csv, Br slot 13, 2 proton alpha (line 666), ‘Electrons’ value changed from ‘T’ to ‘A’.

2. Copied the atomic data file Elements-Positions2 then renamed it Elements-Positions3 in order to add the the second alpha type ‘V’. Haven’t decided which alpha spin pair directions (RL or LR) A or V are yet. Half of all the previous 253 alpha type slots (rows) were changed from ‘A’ to ‘V’. There are currently 127 A rows and 126 V rows in the 1,710 row (19 slots x 90 elements) atomic data.

3. Added a new column to Elements-Positions3, ‘TCount’ in order to identify all alpha slot proton RLTB details. That addition changed the atomic database structure and so a new Elements-Positions3 was needed. ‘TCount’ is inserted into column CC, after col CB-SlotSpin and before col CD-CanBind, followed by col CE-SlotLayout.
Given an alpha type proton stack (‘A’ or ‘V’), that contains two proton spin directions, ‘TCount’ identifies the number of protons in the alpha’s top-side with top proton spin direction and T (top) proton pole electron positions.  

The (TCount+1)th and higher count protons will spin in the alpha’s bottom half direction and be accompanied by only bottom type electrons.

For example: If an alpha proton stack contains 2 protons, TCount must equal 1.
If an alpha slot contains 5 protons, from the top of the slot, TCount may equal 1 (or 2, 3 or 4) protons; the corresponding opposite proton spin direction group with bottom pole electron configurations would begin at proton 2 (or 3, 4, or 5).

‘A’ type alpha slots, containing 2-6 protons, reduced from the previous 253 slot rows, are now assigned to 127 rows across all 90 elements as follows:
AlphaSlotProtonStackTotal:, OccurancesOfThatTotal:, TCount values:.  
2P: 42: 1. 3p: 0: None. 4p: 28: 2. 5p: 21: alternating 2 or 3. 6p: 36: 3.
42+0+28+21+36=127 A’s.
‘V’ type alpha slots, containing 2-6 protons now show up in 126 slot rows as follows:
SlotPStackTotal:, NumOfOccurancesOfThatTotal:, TCount values:  
2P: 41: 1. 3p: 0: None. 4p: 28: 2. 5p: 21: alternating 2 or 3. 6p: 36: 3.
41+0+28+21+36=126 V’s.
There are no 3 proton alpha slots of either A or V types yet.

All remaining non-alpha TCount values (1,457 out of 1,710 total rows) are set to 0.

4. Updated both Elements-Positions2 and Elements-Positions3 at github.
https://github.com/LtAirman/ChargeFieldTopics

Jupyter Notebook does not yet read the new alpha slot RLTB data in Elements-Positions3. After making those changes, then reviewing rendered (matplotlib) atoms for verification, I may need to make as many reassignments (such as adding 3 proton alpha slot2) as needed before finally letting AB3 and mBuilder read the new csv file. Then tossing out old unused files might be nice.

P.S. Added two 36's to correct the 127 A and 126 V summations.
.

Hi LTAM,

Here's the most recent file with the 9,000+ topomat atoms added in. There was some overlap with Chemspider. At the topomat linked site, I basically just saved the webpage page and brought it in as .csv file.  If there are particular structures you might want to see...I can see what I can find.

This is 1.42 GBs. The Physics db was shrunk before the backup:  

https://mega.nz/file/rwcRkAiD#GKIiFkOSWtWy2Y2aET4ucJl0RLw3TB7bN65uQgHkHM0

I'll work on getting your new files into tables and integrate them. Using A/V and the T-Count is a good idea IMHO.

For the graph DB stuff...I'm looking at Networkx or Spark Graphx or OrientDB or commercial "Neo4j" now ArangoDB. It is really about how simple things can be done in a Jupyter notebook. Looking at recent work, I'm looking now at the community edition of ArangoDB. It has a python connector. Each of these Graph DBs have a very different syntax language for queries. I've played around with Tinkerpop for awhile but I'm not a command line-export kind of guy to see results. ArangoDB kind of gives more info on what is being actually looked at.  They have a graphing engine display built in which is nice.

ArangoDB wrote:# Entity Resolution in ArangoDB

This notebook will dive into the world of Entity Resolution in ArangoDB.

This notebook is one of a few ways you can learn about Entity Resolution with ArangoDB:
* [Entity Resolution Lunch and Learn video](https://www.arangodb.com/resources/lunch-sessions/graph-beyond-lunch-break-15-entity-resolution/)
* It is the interactive version of the [Entity Resolution Blog Post](https://www.arangodb.com/2021/07/entity-resolution-in-arangodb/)
* There is a runnable example demo available on [ArangoDB Oasis](https://cloud.arangodb.com/) in the 'Examples' tab.


In this notebook we will:

*   give a brief background in Entity Resolution (ER)
*   discuss some use-cases for ER
*   discuss some techniques for performing ER in ArangoDB

What is Entity Resolution?

Entity Resolution is the process of disambiguating records of real-world entities that are represented multiple times in a database or across multiple databases.

An entity is a unique thing (person, company, product, etc.) in the real world with a set of attributes that describes it (a name, zip/postal code, gender, deviceID, title, price, product category, etc.). The single entity might have multiple references across multiple data sources. For example, a single user might have two different email addresses, and a company might have multiple phone numbers in CRM and ERP systems. Many real-world datasets do not contain unique identifiers. In such cases, we have to use a combination of fields to identify unique entities across records by grouping or linking them together.
Entity Resolution (ER) is a process akin to data deduplication that aims to uniquely resolve data that potentially comes from multiple sources to a single real-world entity. The applications for entity resolution are wide and varied across industry verticals, including:
* fraud detection
* KYC
* recommendations engine
* customer 360

Entity Resolution is an ideal use-case for a graph database like ArangoDB. In subsequent sections, we will discuss the steps to take and things to consider when you build ER applications with ArangoDB.

https://colab.research.google.com/github/arangodb/interactive_tutorials/blob/master/notebooks/EntityResolution.ipynb#scrollTo=3ocJYA-BRDHs

.

https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/quickstart-backup-restore-database?view=sql-server-ver16&tabs=ssms

Cr6, the latest database doesn't appear to contain the new Topomat data.

With the tutorial open, verifying my every move, I selected 20230815Physics.bak as the Physics database backup file. Next I dropped Physics. Then I restored Physics. Then I exited, and restarted microsoft SSMS.

Running:

Code:

SELECT
 Count(distinct Formula) as DistinctFormulas,
 Count(1) as UniqueRowcounts
 FROM [Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds]

 order by 1


Returned the Output:
DistinctFormulas
4709
UniqueRowcounts:
810891

I also noted that AtomicMilesMathisFormulas table is still 4,790 rows.

Double checked and saw 20230815Physics.bak is the current Physics backup file and added the image at the top.

Is there a kickstart query I haven't been briefed on yet?
.

Ok, let me make sure I uploaded the correct .bak file.

You should see counts like the following with the new row counts:

DistinctFormulas
11,344
UniqueRowcounts
1,889,598


New File:
https://mega.nz/file/mhUC2Jaa#86JfV_OozqPQs6CNV34_s393Wn1jcyXXbqwpHUqQDQI

The new file should be about 1.42 GBs.  Once downloaded, put in in your "Backup" folder and try to restore it with a command like this:

Link:  https://mega.nz/file/mhUC2Jaa#86JfV_OozqPQs6CNV34_s393Wn1jcyXXbqwpHUqQDQI

Code:


DROP DATABASE Physics
GO

/* restore from the latest full backup */
 
-- restore database
RESTORE DATABASE [Physics] FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\20230816Physics.bak'
WITH MOVE N'Physics' TO N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\Physics.mdf',  
     MOVE N'Physics_log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\Physics_log.ldf',  
RECOVERY, -- 'with recovery' is optional here - it's the default if not specified - database will be available
REPLACE;

.
Thank you Cr6, we have Joy.

Running your restore query returned the output:

Code:

Processed 185432 pages for database 'Physics', file 'Physics' on file 1.
Processed 2 pages for database 'Physics', file 'Physics_log' on file 1.
RESTORE DATABASE successfully processed 185434 pages in 2.552 seconds (567.672 MB/sec).

Completion time: 2023-08-16T19:33:34.1902498-07:00

Re-running the latest select query I see the expected new formula and row count values.
DistinctFormulas
11,344
UniqueRowcounts
1,889,598


Please note my windows explorer shows that
20230815Physics.bak is 2,957,536 KB and  
20230816Physics.bak is 1,484,916 KB.
.

LongtimeAirman wrote:.
Thank you Cr6, we have Joy.

Running your restore query returned the output:

Code:

Processed 185432 pages for database 'Physics', file 'Physics' on file 1.
Processed 2 pages for database 'Physics', file 'Physics_log' on file 1.
RESTORE DATABASE successfully processed 185434 pages in 2.552 seconds (567.672 MB/sec).

Completion time: 2023-08-16T19:33:34.1902498-07:00

Re-running the latest select query I see the expected new formula and row count values.
DistinctFormulas
11,344
UniqueRowcounts
1,889,598


Please note my windows explorer shows that
20230815Physics.bak is 2,957,536 KB and  
20230816Physics.bak is 1,484,916 KB.
.

No problem LTAM....yeah I shrunk the database before backing it up to a .bak file.  The logs were shrunk quite a bit. I think the stored procedure for compiling the database creates a pretty big log file. Shrunk it can save almost 1.5 gig which is always good.

By the way, the TopoMat usually has a .09 in the ZID column which is now a "float" data type instead of "int".  
Example:
ZID Formula               CurrentAtom NextAtom1
5.09 Ag2C4Sb2N4Cl4F12 Ag                C
6.09 Ag2C6N4S2H12       Ag                C

I wonder if Miles' structures could line up better with this paper?
https://archive.materialscloud.org/record/2023.124

Data-driven discovery of organic electronic materials enabled by hybrid top-down/bottom-up design

J. Terence Blaskovits1, R. Laplaza1, S. Vela1, C. Corminboeuf1*
1 Laboratory for Computational Molecular Design, Institute of Chemical Sciences and Engineering, Ecole Polytechnique Fédérale de Lausanne (EPFL), 1015 Lausanne, Switzerland
* Corresponding authors emails: clemence.corminboeuf@epfl.ch
DOI10.24435/materialscloud:aa-2w [version v3]

Publication date: Aug 10, 2023

How to cite this record
J. Terence Blaskovits, R. Laplaza, S. Vela, C. Corminboeuf, Data-driven discovery of organic electronic materials enabled by hybrid top-down/bottom-up design, Materials Cloud Archive 2023.124 (2023), doi: 10.24435/materialscloud:aa-2w.

Description

The high-throughput molecular exploration and screening of organic electronic materials often starts with either a 'top-down' mining of existing repositories, or the 'bottom-up' assembly of fragments based on predetermined rules and known synthetic templates. In both instances, the datasets used are often produced on a case-by-case basis, and require the high-quality computation of electronic properties and extensive user input: curation in the top-down approach, and the construction of a fragment library and introduction of rules for linking them in the bottom-up approach. Both approaches are time-consuming and require significant computational resources. Here, we generate a top-down set named FORMED consisting of 117K synthesized molecules containing their optimized structures, associated electronic and topological properties and chemical composition, and use these structures as a vast library of molecular building blocks for bottom-up fragment-based materials design. A tool is developed to automate the coupling of these building block units based on their available Csp2-H bonds, thus providing a fundamental link between the two philosophies of dataset construction. Statistical models are trained on this dataset and a subset of the resulting hybrid top-down/bottom-up compounds (selected dimers), which enable on-the-fly prediction of key ground state (frontier molecular orbital gaps) and excited state (S1 and T1 energies) properties from molecular geometries with high accuracy across all known p-block organic compound space.
With access to ab initio-quality optical properties in hand, it is possible to apply this bottom-up pipeline using existing compounds as molecular building blocks to any materials design campaign. To illustrate this, we construct and screen over a million molecular candidates (predicted dimers) for efficient intramolecular singlet fission, the leading candidates of which provide insight into the structural features that may promote this multiexciton-generating process.

Materials Cloud sections using this data
No Explore or Discover sections associated with this archive record.

https://archive.materialscloud.org/record/2023.124

Here's another data source (151mb) that might interesting to look at in terms of Miles'. Looks like there is a research focus on Weyl-semi  metals at the moment:

Prediction of a novel type-I antiferromagnetic Weyl semimetal

Davide Grassano1*, Luca Binci1*, Nicola Marzari1,2*
1 Theory and Simulation of Materials (THEOS), and National Centre for Computational Design and Discovery of Novel Materials (MARVEL), École Polytechnique Fédérale de Lausanne, CH-1015 Lausanne, Switzerland
2 Laboratory for Materials Simulations (LMS), Paul Scherrer Institut (PSI), CH-5232, Villigen PSI, Switzerland
* Corresponding authors emails: davide.grassano@epfl.ch, luca.binci@epfl.ch, nicola.marzari@epfl.ch
DOI10.24435/materialscloud:ph-3c [version v1]
Publication date: Aug 03, 2023

Davide Grassano, Luca Binci, Nicola Marzari, Prediction of a novel type-I antiferromagnetic Weyl semimetal, Materials Cloud Archive 2023.123 (2023), doi: 10.24435/materialscloud:ph-3c.

Description

Topological materials have been a main focus of studies in the past decade due to their protected properties that can be exploited for the fabrication of new devices. Among them, Weyl semimetals are a class of topological semimetals with non-trivial linear band crossing close to the Fermi level. The existence of such crossings requires the breaking of either time-reversal or inversion symmetry and is responsible for the exotic physical properties. In this work we identify the full-Heusler compound InMnTi₂, as a promising, easy to synthesize, T- and I-breaking Weyl semimetal. This material exhibits several features that are comparatively more intriguing with respect to other known Weyl semimetals: the distance between two neighboring nodes is large enough to observe a wide range of linear dispersions in the bands, and only one kind of such node's pairs is present in the Brillouin zone. We also show the presence of Fermi arcs stable across a wide range of chemical potentials. Finally, the lack of contributions from trivial points to the low-energy properties makes the materials a promising candidate for practical devices.

https://archive.materialscloud.org/record/2023.123

In some cases we may need to look at SMILES converters:

My apologies LTAM,

I had bug in the ordering by MolOrder. Used to use the SeqNo but that creates gaps in the order horizontally for atoms, atom counts.

This version is much more solid and shows more accurately what is represented by MolOrder. A simple mistake so sorry about this. The CurrentAtom often dropped because it took the second order instead of the first order. Hence, alignment was incorrect.

This .bak file should be more accurate than the last file:
https://mega.nz/file/a4UBzaxb#1ciXlqWlAZxcrtsWv-A7HHmzob2SaBpGELw3K2pBpUA

For some Formulas...previously you might see:
Formula CurrentAtom NextAtom1
NbNiAs2 Ni As
Instead of:
Formula CurrentAtom NextAtom1 NextAtom2
NbNiAs2 Nb Ni As

This version is a "Full Show Boat" as well...
Saw this one as interesting:
Formula
Rb4Br2O

Currently looking at 15,283 formulas represented with Miles' layout.

SELECT [ZID]
,[Formula]

FROM [Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds]
Group By [ZID]
,[Formula]

.

I wrote. Please note my windows explorer shows that
20230815Physics.bak is 2,957,536 KB and  
20230816Physics.bak is 1,484,916 KB.

Cr6 wrote. No problem LTAM....yeah I shrunk the database before backing it up to a .bak file.  The logs were shrunk quite a bit. I think the stored procedure for compiling the database creates a pretty big log file. Shrunk it can save almost 1.5 gig which is always good. 

Airman. Ok, but both bak files looked different  to me. Also, good to know a simple restoral query no longer works for Physics, but your full restoral query does.

Reviewing the Tables and Views. Anxious to see what changes I could find, I once again began a Select * inspection of all the latest Tables and Graphs.

Reviewing the Tables went smoothly.

The Views were different. The second View – AtomicOrbitalBonds stopped me. My previous index note indicated: “9028 rows. 53 cols. Atomic details and orbitals. All ZmoleculeOrder values equal 1”. This time however, the query kept running, I let it go 11 hours before stopping the query execution.
I expected at least two or three 3+ hour query response times, but none greater than 9 hours. Convinced myself I had a memory problem. Once again, time to free up some memory by removing un-needed bak files from the Backup folder.


Backup folder image section ‘a’. I was surprised to see that 20230816Physics.bak, which was 1,484,916 KB in the backup folder image I posted last time had grown to 2,957,536 KB, the same size as 20230815Physics. Well, I guess those two bak files were the same after all.
 
Backup folder image section ‘b’ shows the folder contents after a clean up. I kept the pre-Topo db available since I thought I probably had a memory problem.

Next morning I resumed the View inspections, looking at just five more before hitting my second problem, MathisEdgesGraphML. According to the notes, this previous 247,747 row, 6 cols. RowN, Source, Target, srcElement, trgElement, edges  completed in 10 secs. I let it run 25 hours before stopping it.
MathisEdgesGraphML. 247,747 rows. 6 cols. RowN, Source, Target, srcElement,
   trgElement, edges. 10 secs.
   Currently no output. Interrupted over 25 hrs later.

Cr6 wrote. My apologies LTAM,

I had bug in the ordering by MolOrder. Used to use the SeqNo but that creates gaps in the order horizontally for atoms, atom counts.

This version is much more solid and shows more accurately what is represented by MolOrder. ...

Airman. No apologies necessary Cr6, not for cleaning up and repetitions. Had no idea how that bug might have manifested itself. Downloaded you latest ‘Physics’ backup file, 08192023Physics. Selected it as the bkup, dropped Physics, then restored Physics with your full Restoral query. Then removed 20230816Physics.bak from the backup folder (image section ‘c’).

Resumed my review.

Three new tables:
tmpRawJSONFiles. 2 rows. 4 cols: UID JSONString SourceFile LoadDate  
tmpRawJSONFilesFormulas. 2001 rows. 4 cols: Formula LoadType MND5 LoadDate.
tmpTopoMat. 9212 rows. 2 cols: TopoMatID Formula. Sorted on the numbers.

Some View findings:

1. vwAtomicPivotedAtomCounts has an error output. “Could not use view or
function 'Physics.dbo.vwAtomicPivotedAtomCounts' because of binding
errors”.

2. The following 6 Views’ Select * do not execute properly, the queries continue
to run indefinitely - without completion. They needed to be interrupted as I noted
in the following latest Tables and Views index update notes.  
AtomicOrbitalBonds.
MathisEdgesGraphML.
vwAtomicOrbitalsinMilesDetail.
vwAtomicOrbitalsNotinMilesAll.
vwCircle.
vwNumbers.

Code:

////////////Updated 17-20 Aug 2023////
#Graph Tables.
gMathisPeriodicTableAtomLTAM. 1,530 rows, 17 cols. LTAMKey assignments
    data with $node schema info/code

/////////////////////////////////
#Tables.
AllTable.  335 rows -  4 cols. Quantity, Value, Uncertainty, Unit.
 No primary key. 355 atomic constants and relationships.
AtomicMilesMathisElementsPositions. 1710 rows and 88 cols. All 1,710 atomic data
 slot rows are assigned(?) LTAMKey and BindKey values.
AtomicMilesMathisFormulas. 11,348 rows, 9 cols. ZID, Formula, CurrentAtom,
    NextAtom1, … , NextAtom6.  
AtomicMilesMathisMoleculesBindLogicXYZ. 883,986 rows, 166 cols. Each
    row is a bond. 51 sec.
AtomicMilesMathisOrbitalBondsParsed. 15,846 rows, 65 cols. ZMolecule,
    CurrentAtom, NextAtom1, … , 8p, 9s, 9p, ZID, MolOrder.
AtomicMilesMathisOrbitalParsed. 47,548 rows, 48 cols. ID ZMolecule ZItem ZFormula ...
    9s, 9p, ZID, MolOrder.
AtomicMilesMathisOrbitalsDetailAllBonds. 1,889,598 rows, 182 cols. ZID Formula
    CurrentAtom NextAtom1 ... e6zDest. 00:01:50.
AtomicMilesMathisPeriodicTable. 2,983 rows, 17 cols. UID AtomicNumber AtomicSymbol ...
    color. Pt data in a strange order?
AtomicMilesMathisPeriodicTableBase. 157 rows, 153 cols. RemainderAlphaLevel ... 9p.
    Mainly Atomic data (?).
AtomicMilesMathisProtonBalance.  157 rows, 12 cols. Carousel ... AlphaTypeRemainder
AtomicOrbital. 21,161 rows 46 cols. ID ZMolecule ZItem ZFormula ... 8p 9s 9p.
AtomicOrbital1. Zero rows. 37 col headers.  ID ZMolecule ZItem ZFormula, … 8p 9s 9p.
AtomicOrbitalsinMilesDetailSummary. 563,022 rows, 172 cols. ZID Formula CurrentAtom
    NextAtom1 ... e6zDest. 00:00:32.
AtomicRDKit. 92 rows -  38 cols. Each atom’s (1-92) select atomic values.
AtomicSourcesRDKit. 26 rows -  5 cols (PropertyID, property, notes, units, source).
AtomPeriodicTableAtomLTAMKey. 132 rows, 5 cols. ID LTAMKey CanBind Electrons AlphaType.
Chemspider. 66,317 rows. 5 cols. UID Line Content ChemspiderID LoadDate.
 Content includes various Chemspider molecular names. 
Circle. 36001 rows - 360 degrees in hundreths. Cols x y and z are NULL. Replaces
    rotation calculations with a table lookup.
Compounds. 262 rows - 3 cols. No, Compound, Formula.
CompoundsSmiles. 1351 rows - 6 cols. SMILES info(PID,id,EntryName,SMILES,
    MW,Selectivity_Index).
ElementAbundance. 78 rows – 9 cols. 78 Elements’ crustal abundances.
ElementsPositions. 1710 rows – 87 cols. 90 element data through SL diags col SL4.
ElementsPositions2. 1710 rows – 86 cols. Through SL diags col SL4. Don't know which
    column was dropped.
EnergyLevel. 6 rows – 7 cols. EnergyLevel,ShellLetter,ElectronCapacity,s,p,d,f.
FormulaSuperConductor. 176 rows of FormulaSuperConductors
GraphMilesAtomNode – 157 rows - Through Atomic number 153. 8 columns (AtomicNumber,
    AtomicSymbol, Element,
GraphTempAtomNode. 90 rows, Up to Thorium. 8 columns (AtomicNumber, AtomicSymbol,
    Element, OrbitalGroup, Protons, Neutrons, GroupNumber, Period).
Ions. 64 rows – 5 cols. IonID,Ion,Charge,AlphaNm,Name
Mathis. 1282 rows – 5 cols. UID, AtomicNumber,Position,SlotNumber,AlphaType
MilesMathis. 12 rows – 4 cols. ID,Description,RawCalculation, Set2. Miles calcs.
MilesMathisPeriodicTable. 2983 rows – 18 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD. 2983 rows – 15 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD2. 2993 rows, 18 columns.
nci. 150 rows – 2 cols. Compoundid, smiles.
Numbers. 65,536 rows – 1col, Number. Rows 1 to 65536 containing Number 0 to 65,535.
Orbital1. 344 rows – 27 cols. UID 1s 2s ... 8p 9s 9p. Atomic electron orbital info.
OrbitalMatrix. 157 rows – 30 cols. AtomicNumber AtomicSymbol Element OrbitalGroup
    1s 2s ... 8p 9s 9p. 163 elements with atomic electron orbital info.
Orbitals. 172 rows – 13 cols. 172 elements’ atomic electron orbital info.
PeriodicTable. 118 rows – 74 cols. 118 elements’ atomic data.
PeriodicTableGrouping. 110 rows – 30 cols. 110 elements’ atomic data.
PeriodicTableState. 112 rows – 12 cols. 112 elements’ atomic data.      
PeriodType. 10 rows – 2 cols. Period, PeriodTypeDescription - Atomic types, alkaki
    metals to noble gases.      
Species. 105,179 rows, 4 cols. ID, Molecule, Formula, Detail. Like Chemspider.
Species_Stg. 1998 rows – 3 cols. Molecule, Formula, Detail.      
Species20230212. 103,185 rows. 4 cols. ID, Molecule, Formula, Detail. 00:00:01.
sqlmol_bond_type. 0 rows. btid symbol.    
sqlmol_compound. 150 rows. 2 cols: compoundid, smiles  
sqlmol_compound_bonds. 0 rows. cbid, compoundid, btid, ceid1, ceid2.  
sqlmol_compound_elements. 0 rows. ceid, compoundid, atom, nodeid.    
sqlmol_compound_hfbonds. 0 rows. compoundid, chbid, ceid, cbid, btid, parseid.
sqlmol_element_type. 0 rows. symbol.                                
sqlmol_hfbond_type. 0 rows. btid, symbol.                                
sqlmol_symbol. 28 rows. 3 cols, code, type, Aromaticity.                              
STG_Orbital. 172 rows. 28 cols. 172 elements’ electron orbital data.
NEW: tmpRawJSONFiles. 2 rows. 4 cols: UID JSONString SourceFile LoadDate  
NEW: tmpRawJSONFilesFormulas. 2001 rows. 4 cols: Formula LoadType MND5 LoadDate.
NEW: tmpTopoMat. 9212 rows. 2 cols: TopoMatID Formula. Sorted on the numbers.

/////////////////////////////////
#Views.
AtomicMilesMathisOrbitalsMissing. Zero rows, formula col header. 00:00:00.
AtomicOrbitalBonds. 9028 rows. 53 cols. Atomic details and orbitals. All
    ZmoleculeOrder values equal 1.
 Currently no output. Interrupted after 11 Hrs.

AtomicPivotedByAtomicNumber. 3,818 rows. 92 cols. Atom1-Atom90. 4 secs. 
Function_Assist_GETDATE. 1 row. 1 col, GetDate. Gives the date and time of
    the query function.
Function_Assist_RAND. 1 row. 1 col, RAND. Returns a random value between 0 and 1.
gAllowedBonds. Ouputs a message, 'Not in use any longer - deleted due to size'.
gJSONNodes. 215,301 rows. 1 col, Nodes. All molecular bonding sites?
MathisEdgesGraphML. 247,747 rows. 6 cols. RowN, Source, Target, srcElement,
    trgElement, edges. 10 secs.
 Currently no output. Interrupted over 24 hrs later.
 
MathisGraphBondsTCC. 2,677 rows. 8 col, Nodes. All molecular bonding sites?
MathisNodesEdgesAllBinds. 175,964 rows. 182 cols. LTAMKeySrc, LTAMKeyDest,
    AtomicNumberSrc, … , Color.
MathisNodesGraphML. 896 rows. Nodes.      
MilesMathisCalculus. 50 rows. 5 cols. Z, 2z, z3, NextNumber, MathisCalculus.      
vwAllTable. 335 rows. 4 cols. FloatValue, Quantity, Value, Uncertainty.        
vwAtomic. 391,741 rows. 160 cols. 50 seconds.
vwAtomicMilesMathisOrbitalsDetailAllBonds. 1,889,598 rows 182 cols. ZID Formula
    CurrentAtom NextAtom1 ..., e6zDest.
vwAtomicOrbital. 13,814 rows. 47 cols. ID, ZMolecule, Zitem, … , 9p, ZID.
vwAtomicOrbitalBonds. 4,745 rows. 56 cols. ZMoleculeOrder, CurrentAtom, ... ,
    ZID. Atomic details and orbitals. All Zmolecule, Order values equal 1.
vwAtomicOrbitalPerm. 21,161 rows. 46 cols. ZID, ZMolecule, ZItem, … , 9p.
vwAtomicOrbitalsAllMiles. 2,565 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula.
    17 seconds.
vwAtomicOrbitalsAllowed. 2,106 rows, 13 cols. MinAtomicNumberSrc, MaxAtomicNumberSrc,
 MinAtomicNumberDest, MaxAtomicNumberDest,nAtomicSArc, ... , AlphaTypeDest.
vwAtomicOrbitalsCarbonCarousel. 517 rows, 5 cols. ElementSrc, ElementDest, cnt,
    LTAMKeySrc, LTAMKeyDest. Every row contains at least 1 carbon.
vwAtomicOrbitalsinMiles. 2,552 rows. 7 cols. CurrentAtom, NextAtom1, … ,
    Formula. 15 secs.
vwAtomicOrbitalsinMilesDetail. 13,814 rows. 47 cols.  ID, ZMolecule, Zitem,
    … , 9p, ZID.
 Currently no output. Interrupted after three hours.

vwAtomicOrbitalsinMilesDetailAllBonds. 633,400 rows. 174 cols. CurrentAtom,
    NextAtom1, … , SlotDirectionElectronBond. 01:15:18.
vwAtomicOrbitalsinMilesDetailCarbonFilteredOut. 156,695 rows. 170 cols.
    CurrentAtom, NextAtom1, … , Formula. 00:23:28.
vwAtomicOrbitalsinMilesDetailSummary. 1,663,797 Rows, 187 cols. SlotDirectionSrc,
    SlotDirectionDest, SlotDirectionElectronSrc, SlotDirectionElectronDest,
 SlotDirectionElectronBond2, ZID, Formula, CurrentAtom, NextAtom1, … ,
 e6zDest. 00:02:16.
vwAtomicOrbitalsinMilesDetailSummaryPeriodicDetail. 3,778,328 rows and 335 columns.
    ZID thru 9p. 00:30:25. A lot of info.
vwAtomicOrbitalsinMilesDetailSuperConductors. 37,170 rows, 170 cols. CurrentAtom,
    NextAtom1, … , e6zDest. 00:00:13.
vwAtomicOrbitalsNotinMiles. 64 rows. 8 cols. CurrentAtom, NextAtom1, … , Formula. 00:00:17.
vwAtomicOrbitalsNotinMilesAll. ? rows and ? cols.
    Currently no output. Interrupted at 45 min 25 secs

vwAtomicOrbitalsNotinMilesBySlotOrientation. 15 rows and 187 cols. SlotDirectionSrc,
    SlotDirectionDest, SlotDirectionElectronSrc, SlotDirectionElectronDest,
 SlotDirectionElectronBond2, ZID, Formula, CurrentAtom, NextAtom1, … ,
 e6zDest. 00:00:50
vwAtomicPeriodicTableLTAMSpins. 13,763 rows 177 cols. ID, ZMolecule, … , SL4. 00:00:04
vwAtomicPivoted. 13,763 rows. 92 cols. ID, ZMolecule,  … , MolOrder. 00:00:03
vwAtomicPivotedAtomCounts. 105,179 rows, 23 cols. ID, ZMolecule, ZFormula, Atom1, AtomNumberCount10.
     Msg 208, Level 16, State 1, Procedure vwAtomicPivotSource, Line 41 [Batch Start Line 2]
     Invalid object name 'Physics.dbo.TopoMat'.
     Msg 4413, Level 16, State 1, Line 42
     Could not use view or function 'Physics.dbo.vwAtomicPivotedAtomCounts' because of binding errors.

vwChemSpider. 4,753 rows, 3 cols. ChemspiderID, Formula, Molecule. 00:00:00
vwCircle. 36001 rows. 1 col. Degree. Looks like random rotations (with select *) between zero
 and sequential rotations when using the select top 1000 values.
    Currently no output. Interrupted at 15 minutes.
 
vwDeutrium. 85 rows. 4 col. ID, Molecule, Formula, Detail. Detail is empty. 00:00:00
vwElementsPositions. 1710 rows. 89 cols. AtomicNumber, AtCurrentAtom, NextAtom1, … ,
    Formula, Element, AtomicTuple, … , SL4,LTAMKey, BindKey.  00:00:00
vwMathisLTAMMolecules. 397,328 rows. 121 cols. ZID, ZMolecule, … , 9p. 00:00:20.
vwMathisMaxSlotPivoted. 90 rows. 28 cols. AtomicNumber, AtomicSymbol, … , Slot19. 00:00:00.
vwMathisMoleculesBindLogic. 35,509 rows. 165 cols. AtomicNumberSrc, AtomicNumber
    Dest, … , e6zDest. The query took 3 secs.
vwMathisMoleculesBindLogicXYZ. 718,171 rows. 165 cols. AtomicNumberSrc, AtomicNumber Dest, … ,
    e6zDest, SlorDirectionElectronBond. 00:00:41.
vwMathisMoleculesFullBindLogic. 4,174,262 rows. 254 cols. BondType, AtomicNumber, AtomicSymbol
    Dest, … , e6zDest. 00:07:17.
vwMilesMathisElectronBondingMapped, 2983 rows. 179 cols. UID, mOrbitalGroup, mProtons,
    mNeutrons, , ZSeqNo, ZItem, ZElement, ZFormula, … , 9p. 00:00:01.
 Resembling AtomicOrbitalBonds with plenty of potential atomic attributes.
vwMilesMathisPeriodicTable. 2,983 rows. 17 cols. UID, AtomicNumber, AtomicSymbol, … ,
    Color. 00:00:00.
vwMilesMathisPeriodicTablePivoted. 2,983 rows. 35 cols. UID, AtomicNumber, AtomicSymbol,
    Element, , … , 19. 00:00:00.
vwMolecule. 829,361 rows. 8 cols. ID, Molecule, Formula,  Item, RW, ASCIINum, Number,
    CharPlaceType. 00:00:39.
vwMoleculeAtomicWeight. 4,753 rows. 7 cols. ID, MolecularWeight, Formula,  Molecule,
    Number, NistLookup, ChemspiderLookup ,Total1stIonization. 00:00:02.
vwNumbers. 2,476,099 rows. 1 col. n. 1-2,476,099. 00:00:13.
    Currently no output. Interrupted at 10 minutes.
 
vwPeriodicTable. 157 rows. 153 cols. RemainderAlphaLevel1, REM2, REM3, … , 9p. 00:00:02.
vwProtonBalanceMathis. 157 rows. 12 cols. Carousel, AlphaProtonCarouselRemainder, Alphas,
    Element, AtomicSymbol, Period, … , AlphaTypeRemainder. 00:00:00.
vwServerIPAddress. 1 row, 7 cols. net_transport protocol_type auth_scheme
    ... public_nrt_transport. 00:00:00
vwSysRefreshViews. 53 row, 1 cols. RefreshView. 00:00:00
vwSysTableSizes. 58 rows, 6 cols. SchemaName TableName RowCounts Used_MB Unused_MB Total_MB


Relaxed a bit, no longer believing I have a memory problem.

Cr6, I haven’t spend much time looking at your latest information, the two materialscloud links look pretty deep. 2023.124 ‘Data-driven discovery of organic electronic materials enabled by hybrid top-down/bottom-up design’ appears to provide well developed data sets in support of projects with machine learning goals like ours, helping to validate Miles’ data and building up from there. I couldn’t help but notice the XYZ-dimers information, outside the ‘usual’ 2d graph data. Is 2023.123 'Prediction of a novel type-I antiferromagnetic Weyl semimetal' some kind of example of a successful application of the dataset?  

Cr6 wrote. Currently looking at 15,283 formulas represented with Miles' layout.

SELECT [ZID]
,[Formula]

FROM [Physics].[dbo].[AtomicMilesMathisOrbitalsDetailAllBonds]
Group By [ZID]
,[Formula]

Airman. I didn’t notice the 15,283 number during my review. When I ran this Select Zid/Formula query you posted, the output was 11,344 rows, the same as the Distinct formulas total row output.

I also saw the new real ZID values including the 0.09 indicating Topomat formulas.

As well as bigger numbers such as AtomicMilesMathisOrbitalsDetailAllBonds 1,889,598 rows,

Couldn't let another day go by without posting.
.

Hi LTAM,

Sorry to see a few of these views time-out/error. Basically if a query doesn't finish in like at most 3-5 minutes...just cancel it. There is either a bug or a database issue.

This query can help to dynamically check views. For the Topomat errors, just do this to fix the missing table issue:

SELECT *
INTO dbo.Topomat
FROM dbo.tmpTopomat
;
-------

--Build a dynamic query of the views.

SELECT 'SELECT COUNT(*) as rws, '''+TABLE_SCHEMA+'.'+TABLE_NAME+''' as tbl FROM '+TABLE_SCHEMA+'.'+TABLE_NAME+';' as Qry
FROM INFORMATION_SCHEMA.VIEWS
order by TABLE_NAME
GO

--Output copied

SELECT COUNT(*) as rws, 'dbo.AtomicMilesMathisOrbitalsMissing' as tbl FROM dbo.AtomicMilesMathisOrbitalsMissing;
SELECT COUNT(*) as rws, 'dbo.AtomicOrbitalBonds' as tbl FROM dbo.AtomicOrbitalBonds;
SELECT COUNT(*) as rws, 'dbo.AtomicPivotedByAtomicNumber' as tbl FROM dbo.AtomicPivotedByAtomicNumber;
SELECT COUNT(*) as rws, 'dbo.Function_Assist_GETDATE' as tbl FROM dbo.Function_Assist_GETDATE;
SELECT COUNT(*) as rws, 'dbo.Function_Assist_RAND' as tbl FROM dbo.Function_Assist_RAND;
SELECT COUNT(*) as rws, 'dbo.gAllowedBonds' as tbl FROM dbo.gAllowedBonds;
SELECT COUNT(*) as rws, 'dbo.gJSONNodes' as tbl FROM dbo.gJSONNodes;
SELECT COUNT(*) as rws, 'dbo.MathisEdgesGraphML' as tbl FROM dbo.MathisEdgesGraphML;
SELECT COUNT(*) as rws, 'dbo.MathisGraphBondsTCC' as tbl FROM dbo.MathisGraphBondsTCC;
SELECT COUNT(*) as rws, 'dbo.MathisNodesEdgesAllBinds' as tbl FROM dbo.MathisNodesEdgesAllBinds;
SELECT COUNT(*) as rws, 'dbo.MathisNodesGraphML' as tbl FROM dbo.MathisNodesGraphML;
SELECT COUNT(*) as rws, 'dbo.MilesMathisCalculus' as tbl FROM dbo.MilesMathisCalculus;
SELECT COUNT(*) as rws, 'dbo.vwAllTable' as tbl FROM dbo.vwAllTable;
SELECT COUNT(*) as rws, 'dbo.vwAtomic' as tbl FROM dbo.vwAtomic;
SELECT COUNT(*) as rws, 'dbo.vwAtomicMilesMathisOrbitalsDetailAllBonds' as tbl FROM dbo.vwAtomicMilesMathisOrbitalsDetailAllBonds;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbital' as tbl FROM dbo.vwAtomicOrbital;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalBonds' as tbl FROM dbo.vwAtomicOrbitalBonds;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalPerm' as tbl FROM dbo.vwAtomicOrbitalPerm;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsAllMiles' as tbl FROM dbo.vwAtomicOrbitalsAllMiles;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsAllowed' as tbl FROM dbo.vwAtomicOrbitalsAllowed;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsCarbonCarousel' as tbl FROM dbo.vwAtomicOrbitalsCarbonCarousel;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMiles' as tbl FROM dbo.vwAtomicOrbitalsinMiles;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetail' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetail;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetailAllBonds' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetailAllBonds;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetailCarbonFilteredOut' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetailCarbonFilteredOut;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetailSummary' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetailSummary;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetailSummaryPeriodicDetail' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetailSummaryPeriodicDetail;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetailSuperConductors' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetailSuperConductors;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsNotinMiles' as tbl FROM dbo.vwAtomicOrbitalsNotinMiles;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsNotinMilesAll' as tbl FROM dbo.vwAtomicOrbitalsNotinMilesAll;
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsNotinMilesBySlotOrientation' as tbl FROM dbo.vwAtomicOrbitalsNotinMilesBySlotOrientation;
SELECT COUNT(*) as rws, 'dbo.vwAtomicPeriodicTableLTAMSpins' as tbl FROM dbo.vwAtomicPeriodicTableLTAMSpins;
SELECT COUNT(*) as rws, 'dbo.vwAtomicPivoted' as tbl FROM dbo.vwAtomicPivoted;
SELECT COUNT(*) as rws, 'dbo.vwAtomicPivotedAtomCounts' as tbl FROM dbo.vwAtomicPivotedAtomCounts;
SELECT COUNT(*) as rws, 'dbo.vwAtomicPivotSource' as tbl FROM dbo.vwAtomicPivotSource;
SELECT COUNT(*) as rws, 'dbo.vwChemSpider' as tbl FROM dbo.vwChemSpider;
SELECT COUNT(*) as rws, 'dbo.vwCircle' as tbl FROM dbo.vwCircle;
SELECT COUNT(*) as rws, 'dbo.vwDeutrium' as tbl FROM dbo.vwDeutrium;
SELECT COUNT(*) as rws, 'dbo.vwElementsPositions' as tbl FROM dbo.vwElementsPositions;
SELECT COUNT(*) as rws, 'dbo.vwMathisLTAMMolecules' as tbl FROM dbo.vwMathisLTAMMolecules;
SELECT COUNT(*) as rws, 'dbo.vwMathisMaxSlotPivoted' as tbl FROM dbo.vwMathisMaxSlotPivoted;
SELECT COUNT(*) as rws, 'dbo.vwMathisMoleculesBindLogic' as tbl FROM dbo.vwMathisMoleculesBindLogic;
SELECT COUNT(*) as rws, 'dbo.vwMathisMoleculesBindLogicXYZ' as tbl FROM dbo.vwMathisMoleculesBindLogicXYZ;
SELECT COUNT(*) as rws, 'dbo.vwMathisMoleculesFullBindLogic' as tbl FROM dbo.vwMathisMoleculesFullBindLogic;
SELECT COUNT(*) as rws, 'dbo.vwMilesMathisElectronBondingMapped' as tbl FROM dbo.vwMilesMathisElectronBondingMapped;
SELECT COUNT(*) as rws, 'dbo.vwMilesMathisPeriodicTable' as tbl FROM dbo.vwMilesMathisPeriodicTable;
SELECT COUNT(*) as rws, 'dbo.vwMilesMathisPeriodicTablePivoted' as tbl FROM dbo.vwMilesMathisPeriodicTablePivoted;
SELECT COUNT(*) as rws, 'dbo.vwMolecule' as tbl FROM dbo.vwMolecule;
SELECT COUNT(*) as rws, 'dbo.vwMoleculeAtomicWeight' as tbl FROM dbo.vwMoleculeAtomicWeight;
SELECT COUNT(*) as rws, 'dbo.vwNumbers' as tbl FROM dbo.vwNumbers;
SELECT COUNT(*) as rws, 'dbo.vwPeriodicTable' as tbl FROM dbo.vwPeriodicTable;
SELECT COUNT(*) as rws, 'dbo.vwProtonBalanceMathis' as tbl FROM dbo.vwProtonBalanceMathis;

.
Cr6, affirmative, running your select Topomat query -  

Code:

SELECT *
INTO dbo.Topomat
FROM dbo.tmpTopomat;

Corrected the select all vwAtomicPivotedAtomCounts Topomat table view problem.

Code:

vwAtomicPivotedAtomCounts. 14,118 rows, 23 cols: ID Molecule Formula Atom1, … , Atom10, AtomNumberCount1, … , AtomNumberCount10. 00:00:18 secs.

Next, I shut down and restarted SSMS and re-ran the select all query obtaining the same 14,118 row output, confirming the Topomat fix is ‘permanent’.

Cr6 wrote.
--Build a dynamic query of the views.

Code:

SELECT 'SELECT COUNT(*) as rws, '''+TABLE_SCHEMA+'.'+TABLE_NAME+''' as tbl FROM '+TABLE_SCHEMA+'.'+TABLE_NAME+';' as Qry
FROM INFORMATION_SCHEMA.VIEWS
order by TABLE_NAME
GO

Airman. Thanks for the guidance Cr6. Of course you know your ‘dynamic query’ sent me to the books and tutorials before I could begin to understand it. Now I can see that the ‘--Output copied’ is a list of select count(*) queries intended to provide every View’s total number of rows.

Code:

--- Query format. 
SELECT 'SELECT COUNT(*) as rws, '''+TABLE_SCHEMA+'.'+TABLE_NAME+''' as tbl FROM '+TABLE_SCHEMA+'.'+TABLE_NAME+';' as Qry

--- The query for a particular View row count,
SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetailSummary' as tbl FROM dbo.vwAtomicOrbitalsinMilesDetailSummary;
   --- Outputs cols: rws  tbl
   --- Outputs values: 1,663 ,797 dbo.vwAtomicOrbitalsinMilesDetailSummary

Ok, here are the latest notes for those six, time-out error Views after running their select count row queries.

Code:

AtomicOrbitalBonds. 9028 rows. 53 cols. Atomic details and orbitals. All
   ZmoleculeOrder values equal 1.
   SELECT * results in a timeout error.  Running the dynamic query:
   SELECT COUNT(*) as rws, 'dbo.AtomicOrbitalBonds' as tbl FROM dbo.AtomicOrbitalBonds;
   Verifies the 9028 row count.
MathisEdgesGraphML. 247,747 rows. 6 cols. RowN, Source, Target, srcElement,
   trgElement, edges. 10 secs.
   SELECT * results in a timeout error. Running the dynamic query:
   SELECT COUNT(*) as rws, 'dbo.MathisEdgesGraphML' as tbl FROM
      dbo.MathisEdgesGraphML; Verifies the 247,747 row count.
vwAtomicOrbitalsinMilesDetail. 13,814 rows. 47 cols.  ID, ZMolecule, Zitem,
   … , 9p, ZID.
   SELECT * results in a time out error. Running the dynamic query:
   SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetail' as tbl FROM
       dbo.vwAtomicOrbitalsinMilesDetail; also results in a time out error.
vwAtomicOrbitalsNotinMilesAll. ? rows and ? cols.
   SELECT * results in a time out error. Running the dynamic query:
   SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsNotinMilesAll' as tbl FROM
       dbo.vwAtomicOrbitalsNotinMilesAll; also results in a time out error.
vwCircle. 36001 rows. 1 col. Degree. Looks like random rotations (with select *) between zero
   and sequential rotations when using the select top 1000 values.
   SELECT * results in a time out error. Running the dynamic query:
   SELECT COUNT(*) as rws, 'dbo.vwCircle' as tbl FROM dbo.vwCircle;  
   also results in a time out error.
vwNumbers. 2,476,099 rows. 1 col. n. 1-2,476,099. 00:00:13.
   SELECT * results in a timeout error. Running the dynamic query:
   SELECT COUNT(*) as rws, 'dbo.vwNumbers' as tbl FROM dbo.vwNumbers;
   [b]Verifies the 2,476,099 View row count[/b].

In summary, three of the six Views outputted row counts and the other three are getting second time-out errors.

How does one generally go about ferreting out desired info? I also reviewed related SQL topics: SQL Tables vs. Views; Creating Stored Procedures; Debugging Stored Procedures.

Then, in the SSMS Object Explorer Physics database, under Programmability, right-clicking the Stored Procedure and selecting Modify.

Code:

/****** Object:  StoredProcedure [dbo].[spBuildAtomicMilesMathisOrbitalsDetailAllBonds]    
Script Date: 8/23/2023 12:16:14 PM ******/

...


Cr6, I hadn't seen this before. Wowsers. Just looking.
.

.
Rather than crudely selecting Modify to view a stored procedure, apparently the proper thing to do is to - View the Dependencies of a Stored Procedure.
https://learn.microsoft.com/en-us/sql/relational-databases/stored-procedures/view-the-dependencies-of-a-stored-procedure?view=sql-server-ver16

Expand Stored Procedures, right-click the procedure and then select Script Stored Procedure as, and then select one of the following: Create To, Alter To, or Drop and Create To.
Select New Query Editor Window. This will display the procedure definition.

Code:

/****** Object:  StoredProcedure [dbo].[spBuildAtomicMilesMathisOrbitalsDetailAllBonds]    
Script Date: 8/26/2023 9:18:37 AM ******/

So, for starters, I copied spBuildAtomicMilesMathisOrbitalsDetailAllBonds, a 1,693 line script to Notepad for quick and easy reference.

Looking at what appears to be the bonding stuff beginning at line 1,162.

Code:

INTO [dbo].[AtomicMilesMathisMoleculesBindLogicXYZ]
FROM Mathis A
FULL OUTER JOIN Mathis B ON 1 = 1
WHERE (
...

I think I see what you're doing Cr6, but I'm still far from a proper understanding. My appreciation of your coding skills has definitely increased.

///\\\\/////\\\\\\/////\\\\///\\/\\

I know I’ve been somewhat lost and aimless lately. I fully intend to concentrate on Notebook molecular graph as soon as I can, but mBuilder (and AtomBuilder3 too for that matter), need attention first. I've mainly been stymied by the lack of any animation showing right and/or left spins (for each slot’s positive x y or z orientation).  

A simple alternative occurred to me, I can make due with static matplotlib atomic plots by using two possible proton colors indicating Right or Left spins and two electron colors for alternate Top or Bottom proton pole positions. The neutrons can all remain red. All colors should be easy to distinguish.

With that goal in mind, I can move forward. First I’ll try applying some of BasedPhysics’ AB3 changes to mBuilder.

Latest mBuilder github changes:
1. Removed markdown cell 2 containing JavaScript error information - JS is not used in mBuilder.
2. Converted reading from filename Elements-Positions2.csv to Elements-Positions3.csv – which contains both LR and RL alpha types.  
3. Made changes to mBuilder leftmost tab enclosure’s Slotlayout(SL) diagram (the one with just: slot number, slot orientation, and slot proton total) using BasedPhysics’ appending operations.

I’ll look at modifying the more complicated TBLR SL diagram next.
.

LongtimeAirman wrote:.
Rather than crudely selecting Modify to view a stored procedure, apparently the proper thing to do is to - View the Dependencies of a Stored Procedure.
https://learn.microsoft.com/en-us/sql/relational-databases/stored-procedures/view-the-dependencies-of-a-stored-procedure?view=sql-server-ver16

Expand Stored Procedures, right-click the procedure and then select Script Stored Procedure as, and then select one of the following: Create To, Alter To, or Drop and Create To.
Select New Query Editor Window. This will display the procedure definition.

Code:

/****** Object:  StoredProcedure [dbo].[spBuildAtomicMilesMathisOrbitalsDetailAllBonds]    
Script Date: 8/26/2023 9:18:37 AM ******/

So, for starters, I copied spBuildAtomicMilesMathisOrbitalsDetailAllBonds, a 1,693 line script to Notepad for quick and easy reference.

Looking at what appears to be the bonding stuff beginning at line 1,162.

Code:

INTO [dbo].[AtomicMilesMathisMoleculesBindLogicXYZ]
FROM Mathis A
FULL OUTER JOIN Mathis B ON 1 = 1
WHERE (
...

I think I see what you're doing Cr6, but I'm still far from a proper understanding. My appreciation of your coding skills has definitely increased.

///\\\\/////\\\\\\/////\\\\///\\/\\

I know I’ve been somewhat lost and aimless lately. I fully intend to concentrate on Notebook molecular graph as soon as I can, but mBuilder (and AtomBuilder3 too for that matter), need attention first. I've mainly been stymied by the lack of any animation showing right and/or left spins (for each slot’s positive x y or z orientation).  

A simple alternative occurred to me, I can make due with static matplotlib atomic plots by using two possible proton colors indicating Right or Left spins and two electron colors for alternate Top or Bottom proton pole positions. The neutrons can all remain red. All colors should be easy to distinguish.

With that goal in mind, I can move forward. First I’ll try applying some of BasedPhysics’ AB3 changes to mBuilder.

Latest mBuilder github changes:
1. Removed markdown cell 2 containing JavaScript error information - JS is not used in mBuilder.
2. Converted reading from filename Elements-Positions2.csv to Elements-Positions3.csv – which contains both LR and RL alpha types.  
3. Made changes to mBuilder leftmost tab enclosure’s Slotlayout(SL) diagram (the one with just: slot number, slot orientation, and slot proton total) using BasedPhysics’ appending operations.

I’ll look at modifying the more complicated TBLR SL diagram next.
.

Let me try to get your new files added in. Recently I ported the basics over to OrientDB which has full a Traverse function to show all possible slot bonds with atoms.  Still working on this but have something coming together. Ideally, a good schema-model of relationships can be built to make this work for a lot of queries-examinations and is quite fast. It is expandable too which is quite nice. Still getting a grip on OrientDB but I see it as a possible solution for modeling these relationships. Shows bonds by slots with Calcium (AtomicNumber 20). "CanBind" is the edge. It is fairly basic at the moment:

Hi LTAM and Team,

I have a new .bak file uploaded with your new file added below:

LTAM wrote:
4. Updated both Elements-Positions2 and Elements-Positions3 at github.
https://github.com/LtAirman/ChargeFieldTopics

It is now about 1.9 Gigs at:
https://mega.nz/file/OlsATS7S#I8hkhWIU-3JwUWM81An0aJR28Jjh0h5lb4DEXTAhlAY

.
I worry whether my atomic TBLR assignments are correct or not. If Helium can take two forms, LR or RL, I imagine all atoms can include some variability at their bonding extents. With two alpha types it will likely become more difficult to find “all the bonds” between single fixed atom types, since some 'real' atomic variations may be missing. Once mBuilder matplotlib plots start showing color coded TBLR atoms I’ll review all the atoms to see whether any TBLR assignments need any obvious changing. We may eventually need to find a way within the bonding logic to introduce atomic variability in any given atom’s bonding extents.  

Cr6 wrote,
I have a new .bak file uploaded with your new file added below:

Alrighty, I dropped and restored Physics using 20230829Physics.bak and your 16 August Restore query.

Reran your 3 August Select query checking the current number of
DistinctFormulas: was 11,344, is now 15,282.
UniqueRowcounts: was 1,889,598, is now 3,485,659.
A 33% increase in formulas almost doubling the number of unique bonds between atoms. I understand that each bond is a possible individual molecular graph edge.

Tables and Views. Sufficient changes to warrant another quick review.

NEW Tables
ElementsPositions3. 1710 rows, 87 cols. From the csv file including SL diags.
ElementsPositions3Old. 1710 rows. Looks the same as ElementsPositions3.

NEW Views
gOrientDBAtomic.
gOrientDBPeriodicTable.

View Time-out errors. Of the six Views with time-out errors I pointed out last week, four Views now execute select * without the time-out error:
AtomicOrbitalBonds
MathisEdgesGraphML
vWCircle
vWNumbers
Two Views still have time-out errors:
vwAtomicOrbitalsinMilesDetail
vwAtomicOrbitalsNotinMilesAll

Code:

////////////Updated 29 Aug 2023////
#Graph Tables.
gMathisPeriodicTableAtomLTAM. 1,530 rows, 17 cols. LTAMKey assignments
    data with $node schema info/code

/////////////////////////////////
#Tables.
AllTable.  335 rows -  4 cols. Quantity, Value, Uncertainty, Unit. No primary key. 355 atomic constants and relationships.
AtomicMilesMathisElementsPositions. 1710 rows and 88 cols. All 1,710 atomic data slot rows are assigned(?) LTAMKey and BindKey values.
AtomicMilesMathisFormulas. 15,282 rows, 9 cols. ZID, Formula, CurrentAtom, NextAtom1, … , NextAtom6.  
AtomicMilesMathisMoleculesBindLogicXYZ. 883,986 rows, 166 cols. Each row is a bond. 51 sec.
AtomicMilesMathisOrbitalBondsParsed. 15,479 rows, 65 cols. ZMolecule, CurrentAtom, NextAtom1, … , 8p, 9s, 9p, ZID, MolOrder.
AtomicMilesMathisOrbitalParsed. 46,786 rows, 48 cols. ID ZMolecule ZItem ZFormula ... 9s, 9p, ZID, MolOrder.
AtomicMilesMathisOrbitalsDetailAllBonds. 3,485,659 rows, 182 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 00:01:50.
AtomicMilesMathisPeriodicTable. 2,983 rows, 17 cols. UID AtomicNumber AtomicSymbol ... color.
AtomicMilesMathisPeriodicTableBase. 157 rows, 153 cols. RemainderAlphaLevel ... 9p. Mainly Atomic data (?).
AtomicMilesMathisProtonBalance. 157 rows, 12 cols. Carousel ... AlphaTypeRemainder.
AtomicOrbital. 21,161 rows 46 cols. ID ZMolecule ZItem ZFormula ... 8p 9s 9p.
AtomicOrbital1. Zero rows. 37 col headers.  ID ZMolecule ZItem ZFormula, … 8p 9s 9p.
AtomicOrbitalsinMilesDetailSummary. 563,022 rows, 172 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 00:00:32.
AtomicRDKit. 92 rows -  38 cols. Each atom’s (1-92) select atomic values.
AtomicSourcesRDKit. 26 rows -  5 cols (PropertyID, property, notes, units, source).
AtomPeriodicTableAtomLTAMKey. 132 rows, 5 cols. ID LTAMKey CanBind Electrons AlphaType.
Chemspider. 66,317 rows. 5 cols. UID Line Content ChemspiderID LoadDate. Content includes various Chemspider molecular names. 
Circle. 36001 rows - 360 degrees in hundreths. Cols x y and z are NULL. Replaces rotation calculations with a table lookup.
Compounds. 262 rows - 3 cols. No, Compound, Formula.
CompoundsSmiles. 1351 rows - 6 cols. SMILES info(PID, id, EntryName, SMILES,     MW, Selectivity,_Index).
ElementAbundance. 78 rows – 9 cols. 78 Elements’ crustal abundances.
ElementsPositions. 1710 rows – 87 cols. 90 element data through SL diags col SL4.
ElementsPositions2. 1710 rows – 86 cols. Through SL diags col SL4. Don't know which column was dropped.
ElementsPositions3. 1710 rows, 87 cols. From the csv file, including SL diags.
ElementsPositions3Old. 1710 rows. Looks the same as ElementsPositions3.
EnergyLevel. 6 rows – 7 cols. EnergyLevel,ShellLetter,ElectronCapacity,s,p,d,f.
FormulaSuperConductor. 176 rows of FormulaSuperConductors
GraphMilesAtomNode – 157 rows - Through Atomic number 153. 8 columns (AtomicNumber, AtomicSymbol, Element, GraphTempAtomNode. 90 rows, Up to Thorium. 8 columns (AtomicNumber, AtomicSymbol, Element, OrbitalGroup, Protons, Neutrons, GroupNumber, Period).
Ions. 64 rows – 5 cols. IonID,Ion,Charge,AlphaNm,Name
Mathis. 1282 rows – 5 cols. UID, AtomicNumber,Position,SlotNumber,AlphaType
MilesMathis. 12 rows – 4 cols. ID,Description,RawCalculation, Set2. Miles calcs.
MilesMathisPeriodicTable. 2983 rows – 18 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD. 2983 rows – 15 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD2. 2993 rows, 18 columns.
nci. 150 rows – 2 cols. Compoundid, smiles.
Numbers. 65,536 rows – 1col, Number. Rows 1 to 65536 containing Number 0 to 65,535.
Orbital1. 344 rows – 27 cols. UID 1s 2s ... 8p 9s 9p. Atomic electron orbital info.
OrbitalMatrix. 157 rows – 30 cols. AtomicNumber, AtomicSymbol, Element, OrbitalGroup, 1s, 2s, ... 8p, 9s, 9p. 163 elements with atomic electron orbital info.
Orbitals. 172 rows – 13 cols. 172 elements’ atomic electron orbital info.
PeriodicTable. 118 rows – 74 cols. 118 elements’ atomic data.
PeriodicTableGrouping. 110 rows – 30 cols. 110 elements’ atomic data.
PeriodicTableState. 112 rows – 12 cols. 112 elements’ atomic data.      
PeriodType. 10 rows – 2 cols. Period, PeriodTypeDescription - Atomic types, alkaki metals to noble gases.      
Species. 105,179 rows, 4 cols. ID, Molecule, Formula, Detail. Like Chemspider.
Species_Stg. 1998 rows – 3 cols. Molecule, Formula, Detail.      
Species20230212. 103,185 rows. 4 cols. ID, Molecule, Formula, Detail. 00:00:01.
sqlmol_bond_type. 0 rows. btid symbol.    
sqlmol_compound. 150 rows. 2 cols: compoundid, smiles  
sqlmol_compound_bonds. 0 rows. cbid, compoundid, btid, ceid1, ceid2.  
sqlmol_compound_elements. 0 rows. ceid, compoundid, atom, nodeid.    
sqlmol_compound_hfbonds. 0 rows. compoundid, chbid, ceid, cbid, btid, parseid.
sqlmol_element_type. 0 rows. symbol.                                
sqlmol_hfbond_type. 0 rows. btid, symbol.                                
sqlmol_symbol. 28 rows. 3 cols, code, type, Aromaticity.                              
STG_Orbital. 172 rows. 28 cols. 172 elements’ electron orbital data.
tmpRawJSONFiles. 2 rows. 4 cols: UID JSONString SourceFile LoadDate  
tmpRawJSONFilesFormulas. 2001 rows. 4 cols: Formula LoadType MND5 LoadDate.
tmpTopoMat. 9212 rows. 2 cols: TopoMatID Formula. Sorted on the numbers.

/////////////////////////////////
#Views.
AtomicMilesMathisOrbitalsMissing. Zero rows, formula col header. 00:00:00.
AtomicOrbitalBonds. 9028 rows. 53 cols. Atomic details and orbitals. All ZmoleculeOrder values equal 1.
AtomicPivotedByAtomicNumber. 3,818 rows. 92 cols. Atom1-Atom90. 4 secs. 
Function_Assist_GETDATE. 1 row. 1 col, GetDate. Gives the date and time of the query function.
Function_Assist_RAND. 1 row. 1 col, RAND. Returns a random value between 0 and 1.
gAllowedBonds. Ouputs a message, 'Not in use any longer - deleted due to size'.
gJSONNodes. 215,301 rows. 1 col, Nodes. All molecular bonding sites?
gOrientDBAtomic. 114,782 rows, 13 cols'. SlotUniqueID, AtomicUniqueID AtomicNumberSrc, AtomicNumberDest, SlotNumberDest, AlphaTypeDest, ElementSrc, LTAMKeySrc, SlotNumberSrc, SlotOrienSrc, SlotSpinSrc, AlphaTypeSrc, AlphaTypeRemainderSrc as tbl FROM dbo.gOrientDBAtomic. 4 secs.
gOrientDBPeriodicTable. 1710 rows, 16 cols. 90 elements' data up to and including SlotSpin. Noted that 'Tcount' and 'CanBind' cols are not yet included.
MathisEdgesGraphML. 247,747 rows. 6 cols. RowN, Source, Target, srcElement, trgElement, edges. 10 secs.
MathisGraphBondsTCC. 2,677 rows. 8 col, Nodes. All molecular bonding sites?
MathisNodesEdgesAllBinds. 175,964 rows. 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, … , Color.
MathisNodesGraphML. 896 rows. Nodes.      
MilesMathisCalculus. 50 rows. 5 cols. Z, 2z, z3, NextNumber, MathisCalculus.      
vwAllTable. 335 rows. 4 cols. FloatValue, Quantity, Value, Uncertainty.        
vwAtomic. 391,741 rows. 160 cols. 50 seconds.
vwAtomicElementsMolOrder. 47,592 rows, 8 cols. ID, Molecule, SeqNo, Item, Element, Number, Formula, MolOrder. Converts formulas into atom types, number of that type atom, and that atom type's positional order, 1,2,3, ... within that formula.
vwAtomicMilesMathisOrbitalsDetailAllBonds. 1,889,598 rows 182 cols. ZID, Formula, CurrentAtom, NextAtom1, ..., e6zDest.
vwAtomicOrbital. 13,814 rows. 47 cols. ID, ZMolecule, Zitem, … , 9p, ZID.
vwAtomicOrbitalBonds. 4,745 rows. 56 cols. ZMoleculeOrder, CurrentAtom, ... , ZID. Atomic details and orbitals. All Zmolecule, Order values equal 1.
vwAtomicOrbitalPerm. 21,161 rows. 46 cols. ZID, ZMolecule, ZItem, … , 9p.
vwAtomicOrbitalsAllMiles. 2,565 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula. 17 seconds.
vwAtomicOrbitalsAllowed. 2,106 rows, 13 cols. MinAtomicNumberSrc, MaxAtomicNumberSrc, MinAtomicNumberDest, MaxAtomicNumberDest,nAtomicSArc, ... , AlphaTypeDest.
vwAtomicOrbitalsCarbonCarousel. 517 rows, 5 cols. ElementSrc, ElementDest, cnt, LTAMKeySrc, LTAMKeyDest. Every row contains at least 1 carbon.
vwAtomicOrbitalsinMiles. 2,552 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula. 15 secs.
vwAtomicOrbitalsinMilesDetail. 13,814 rows. 47 cols.  ID, ZMolecule, Zitem, … , 9p, ZID.
    SELECT * results in a time out error. Running the dynamic query:
    SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsinMilesDetail' as tbl
    FROM dbo.vwAtomicOrbitalsinMilesDetail; Also results in a time out error.
vwAtomicOrbitalsinMilesDetailAllBonds. 633,400 rows. 174 cols. CurrentAtom, NextAtom1, … , SlotDirectionElectronBond. 01:15:18.
vwAtomicOrbitalsinMilesDetailCarbonFilteredOut. 156,695 rows. 170 cols. CurrentAtom, NextAtom1, … , Formula. 00:23:28.
vwAtomicOrbitalsinMilesDetailSummary. 1,663,797 Rows, 187 cols. SlotDirectionSrc, SlotDirectionDest, SlotDirectionElectronSrc, SlotDirectionElectronDest, SlotDirectionElectronBond2, ZID, Formula, CurrentAtom, NextAtom1, … , e6zDest. 00:02:16.
vwAtomicOrbitalsinMilesDetailSummaryPeriodicDetail. 3,778,328 rows and 335 columns. ZID thru 9p. 00:30:25. A lot of info.
vwAtomicOrbitalsinMilesDetailSuperConductors. 37,170 rows, 170 cols. CurrentAtom, NextAtom1, … , e6zDest. 00:00:13.
vwAtomicOrbitalsNotinMiles. 64 rows. 8 cols. CurrentAtom, NextAtom1, … , Formula. 00:00:17.
vwAtomicOrbitalsNotinMilesAll. ? rows and ? cols.
    SELECT * results in a time out error. Running the dynamic query:
    SELECT COUNT(*) as rws, 'dbo.vwAtomicOrbitalsNotinMilesAll' as tbl FROM dbo.vwAtomicOrbitalsNotinMilesAll; Also results in a time out error.
vwAtomicOrbitalsNotinMilesBySlotOrientation. 15 rows and 187 cols. SlotDirectionSrc, SlotDirectionDest, SlotDirectionElectronSrc, SlotDirectionElectronDest, SlotDirectionElectronBond2, ZID, Formula, CurrentAtom, NextAtom1, … ,  e6zDest. 00:00:50
vwAtomicPeriodicTableLTAMSpins. 13,763 rows 177 cols. ID, ZMolecule, … , SL4. 00:00:04
vwAtomicPivoted. 13,763 rows. 92 cols. ID, ZMolecule,  … , MolOrder. 00:00:03
vwAtomicPivotedAtomCounts. 14,118 rows, 23 cols: ID Molecule Formula Atom1 … Atom10, AtomNumberCount1, … , AtomNumberCount10. 00:00:18
vwChemSpider. 4,753 rows, 3 cols. ChemspiderID, Formula, Molecule. 00:00:00
vwCircle. 36001 rows. 1 col. Degree. Looks like random rotations (with select *) between zero and sequential rotations when using the select top 1000 values.
vwDeutrium. 85 rows. 4 col. ID, Molecule, Formula, Detail. Detail is empty. 00:00:00
vwElementsPositions. 1710 rows. 89 cols. AtomicNumber, AtCurrentAtom, NextAtom1, … , Formula, Element, AtomicTuple, … , SL4,LTAMKey, BindKey.  00:00:00
vwMathisLTAMMolecules. 397,328 rows. 121 cols. ZID, ZMolecule, … , 9p. 00:00:20.
vwMathisMaxSlotPivoted. 90 rows. 28 cols. AtomicNumber, AtomicSymbol, … , Slot19. 00:00:00.
vwMathisMoleculesBindLogic. 35,509 rows. 165 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest. The query took 3 secs.
vwMathisMoleculesBindLogicXYZ. 718,171 rows. 165 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest, SlotDirectionElectronBond. 00:00:41.
vwMathisMoleculesFullBindLogic. 4,174,262 rows. 254 cols. BondType, AtomicNumber, AtomicSymbol, Dest, … , e6zDest. 00:07:17.
vwMilesMathisElectronBondingMapped, 2983 rows. 179 cols. UID, mOrbitalGroup, mProtons, mNeutrons, , ZSeqNo, ZItem, ZElement, ZFormula, … , 9p. 00:00:01. Resembling AtomicOrbitalBonds with plenty of potential atomic attributes.
vwMilesMathisPeriodicTable. 2,983 rows. 17 cols. UID, AtomicNumber, AtomicSymbol, … , Color. 00:00:00.
vwMilesMathisPeriodicTablePivoted. 2,983 rows. 35 cols. UID, AtomicNumber, AtomicSymbol, Element, , … , 19. 00:00:00.
vwMolecule. 829,361 rows. 8 cols. ID, Molecule, Formula,  Item, RW, ASCIINum, Number, CharPlaceType. 00:00:39.
vwMoleculeAtomicWeight. 4,753 rows. 7 cols. ID, MolecularWeight, Formula,  Molecule, Number, NistLookup, ChemspiderLookup, Total1stIonization. 00:00:02.
vwNumbers. 2,476,099 rows. 1 col. n. 1-2,476,099. 00:00:13.
vwPeriodicTable. 157 rows. 153 cols. RemainderAlphaLevel1, REM2, REM3, … , 9p. 00:00:02.
vwProtonBalanceMathis. 157 rows. 12 cols. Carousel, AlphaProtonCarouselRemainder, Alphas, Element, AtomicSymbol, Period, … , AlphaTypeRemainder. 00:00:00.
vwServerIPAddress. 1 row, 7 cols. net_transport protocol_type auth_scheme ... public_nrt_transport. 00:00:00
vwSysDynamicQueryViews. Outputs select count(*) queries, providing each View’s total row count. Currently 59 views listed.
vwSysRefreshViews. 53 row, 1 cols. RefreshView. 00:00:00
vwSysTableSizes. 58 rows, 6 cols. SchemaName TableName RowCounts Used_MB Unused_MB Total_MB


Also noticed you did some work on the stored procedure spBuildAtomicMilesMathisOrbitalsDetailAllBonds
at around line 100. Can't say it made it any easier to understand.

Cleaned up mBuilder’s TBLR SlotLayout diagram, again using BasedPhysics’ appending operations, and updated github with those changes.

Periodic table buttons. My code included 378 lines to create the Periodic table's 90 buttons. BasedPhysics did a much nicer job in AtomBuilder3 with just 116 lines. Unfortunately, as I mentioned a couple of months ago (time sure flies), I’m unable to select an atom from AtomBuilder3’s gui dropdown or Periodic table. I’m using a previous AB3 version in which one can select an atom from the gui dropdown but not from the periodic table. Selecting from the table always results in 90 Thorium Th as shown by the gui atom dropdown.
The periodic table cell’s code ends with the following.

Code:

# The periodic table button functions
output = widgets.Output()

for i in range(len(a_buttons)):

   def on_clicked(b):
       selectAtom.value = i + 1

   a_buttons[i].on_click(on_clicked)


That ‘for loop’ at the very end alone replaced 180 lines of my code; but unfortunately - again, it seems to contain the periodic table button problem.

OrientDB. Had to see if OrientDB was compatible with Jupyter Notebook.  
https://github.com/dritter-sap/orientdb-jupyter
Copied the  orientdb-jupyter/README.md to a new OrientDB folder. It references another location.
https://github.com/orientechnologies/pyorient/tree/master/pyorient
Its been two years since there’s been a change.
https://github.com/orientechnologies/pyorient/tree/master
A decent 10 year old Readme file which appears to be the source for this set of pyorient docs.
.

Right now I'm building up an OrientDB graph database with Classes (Schema), Vertexes (Tables) and Edges (links-constraints). Using this current query from the most recent database upload.  I plan to make a query that can output CREATE object INSERTS from this query for the graph database.  OrientDB often requires the use of `Object` for notation. Plan to export from SQL Server tables-views to OrientDB objects with the the Export functionality in DBeaver. I have the query engine in DBeaver hookup to both the SQL Server database (physics) and the OrientDB Classes. It looks like I may have to do the create objects and inserts for Vertexes/Edges/Classes explicit from MSSQL instead of using a direct export from MSSQL to OrientDB which would be cool. Their enterprise version has it with "Teleporter". The export engine to OrientDB looks like it worked with older OrientDB 2.0. I'm working with the 3.2 version which is more SQL friendly. Dynamic SQL in SQL Server can probably overcome this direct export limitation. May make long Insert statement scripts. View below is what I'm working with:

Code:

CREATE View [dbo].[gOrientDBAllRules]
AS
  SELECT TOP 100 PERCENT
  B.*,  A.*
 -- ,TRIM(A.Electrons) + Cast(A.[SlotNumber] as varchar(2)) + B.SlotOrien + cast(B.protons as varchar(2))+B.SlotSpin as LTAMKey
 --  ,TRIM(A.Electrons) + B.SlotSpin as BindKey
  FROM [dbo].[VwMilesMathisPeriodicTable] A
  LEFT JOIN [Physics].[dbo].[vwMathisMoleculesBindLogicXYZ] B  on 1=1 --and A.SlotNumber = B.SlotNumberSrc
  where
  (A.SlotNumber not in (17,19)) and A.SlotNumber = B.SlotNumberSrc
  and A.AtomicNumber = B.AtomicNumberSrc
  and A.AlphaType >= B.AlphaTypeDest
  and (B.SlotSpinDest <> 'N' and B.SlotSpinDest <> 'N')
  and (B.CanBindDest = 1 and B.CanBindSrc = 1)
  and CASE WHEN B.SlotNumberDest < 2 and A.AtomicNumber > 5 then 0 else 1 end = 1
order by AtomicNumber, SlotNumber, B.AtomicNumberDest, B.SlotNumberDest
GO

The question is really the "edges" what to keep as a "node-vertex" and what to keep as an "edge"? Do I break out "Slots" with their own vertex-properties(columns) or keep them all in the same vertex? Just wanted to get some thoughts on the modeling exercise.
Working on building up these nodes-vertexes (vertices)

• Atom - properties Atomic Number-Element
  
• Slot - Linked Key with Atom above showing SlotNumber-LTAMKey-AlphaType-SlotSpin-Electrons-CanBind
  
• Edge - Links between Slots-Atoms via [Physics].[dbo].[vwMathisMoleculesBindLogicXYZ]
  

Example on Nodes-Vertices and Edges via Traveling Salesman example. Trying to do the "HasProfile" with this query:
https://www.orientdb.org/docs/3.0.x/gettingstarted/demodb/DemoDB-DataModel.html


Unfortunately, it looks like the pyOrientDB libraries are a bit dated.

.

Showing Xenon’s (Xe), 54 protons. Nine occupied slots, S1-S9, each with 6 protons. including 27 R (red) and 27 L (blue) spin directions. S1 and S3 are ‘A’ types (LR) and S2 is a V type (RL) alpha. The text is the output of two print commands for Xe’s three alphas:

Code:

print('Slot=',j+1,', Tcount=',tc,', pSDir=',pSDir,', y =',pYvalue,', z =',pZvalue,'P',k+1)
print(number, len(allPLSpinXs),len(allPRSpinXs))

Nothing ever seems to go as smoothly as I hope. An embarrassing print debug output tracing is what that image's text is. After several code corrections it’s now outputting as intended. I’d forgotten the order in which protons are placed in a given slot. A 6 proton (or epn) stack, with up/down z spin axis orientation is filled starting from just above the slot’s vertical center. P2 is added below P1. P3 is added above P1. P4 is added below P2. P5 is added above P3. P6 is added below P4. From +z to -z. The slot sequence is P5,P3,P1,P2,P4,P6. That order can be seen most easily by looking at slot1’s P1 through P6 z coordinates.

For a 6 stack ‘A’ type alpha, such as Xe slot1, P5, P3 and P1 are L spinners, and P2, P4, P6 are R spinners. Next I need to be able to include altering the ‘Tcount’ value in the code such that the slot’s single spin direction change may occur between any two protons within a stack, and not just automatically at the slot middle between P1 and P2 as shown here with Xe’s three alpha type stacks which is what is expected with a Tcount=3.

Periodic table atom selection error. Spent a couple of days trying to find the problem without success.

Cr6 wrote. The question is really the "edges" what to keep as a "node-vertex" and what to keep as an "edge"? Do I break out "Slots" with their own vertex-properties(columns) or keep them all in the same vertex? Just wanted to get some thoughts on the modeling exercise.
Working on building up these nodes-vertexes (vertices)

Airman. If there were single atomic configurations, with fixed bonding slot configurations as we’ve been working with up to now, I’d say it makes perfectly good sense identifying all the possible bonds between all atoms, and to validate them against all the known molecules as we’ve been doing.

If, on the other hand, an atom’s bonding slot is able to take various TBLR forms, limited only by the number of protons in a slot, and charge field conditions we really haven’t gotten into yet, the task of identifying all possible molecular bonds is greatly increased. The problem is actually reduced to identifying all possible bonds between any two possible slot configurations. Bonds between particular atoms at particular extents may present additional constraints, like whether the bond is on an atom’s spinning carousel or not - identifying molecular bonds would amount to finding appropriate allowed bonds from a comprehensive pair bond list. I believe such an allowed pair bond list is a more general and robust solution which would allow us to find a more accurate number of all possible molecular bonds for up to eight or so atom type molecules. I suppose any accurate pair bond list should be validated against known molecules.

Running your new Create view query:
gOrientDBAllRules. 168,452 rows, 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, AtomicNumberDest, ... , ColorR, ColorG, ColorB. 14 seconds. A couple of comments. I see slots 17 and 19 included but not slots 16 and 18. Why do LTAMKeys include 'N' values which should indicate empty slots?

Unless I’m mistaken, that pair bond logic looks to me to be the basis for your new view, gOrientDBAllRules. But 168,452 bonds between any two given atoms is a much larger number than any comprehensive pair bond list that I can imagine. How does the new view list compare to UniqueRowcounts: 3,485,659? Is it because the larger number is counting all the bonds within all verified molecules? But how exactly is each bond unique? And source and destination atoms, after all is said an done, all atomic bonds are bidirectional.

All confused again, I’ll get back to work.
.

LTAM wrote:Running your new Create view query:
gOrientDBAllRules. 168,452 rows, 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, AtomicNumberDest, ... , ColorR, ColorG, ColorB. 14 seconds. A couple of comments. I see slots 17 and 19 included but not slots 16 and 18. Why do LTAMKeys include 'N' values which should indicate empty slots?

Hi LTAM,

Yeah the Elements3.csv didn't have any binds past 15 using "CanBind=1".
Script out these views to see how it looks logic wise:
[Physics].[dbo].[vwMathisMoleculesBindLogicXYZ]
[Physics].[dbo].[vwElementsPositions]

Nothing shows here:

Code:

SELECT *
  FROM [Physics].[dbo].[vwMathisMoleculesBindLogicXYZ]
  WHere (SlotNumberDest > 15 or SlotNumberSrc > 15)
  and (CanBindSrc = 1 and CanBindDest =1)

Or from the source:

Code:

SELECT e.*
 ,m.AlphaType
 ,m.SlotOrder
 ,pbm.MathisCarouselAlphaTypeFull
 ,pbm.AlphaTypeRemainder
 ,m.Protons AS ProtonsMM

 FROM [Physics].[dbo].[vwElementsPositions] e
 JOIN [Physics].[dbo].[vwMilesMathisPeriodicTable] m ON e.AtomicNumber = m.AtomicNumber
 AND e.SlotNumber = m.SlotNumber
 LEFT JOIN [Physics].[dbo].[vwProtonBalanceMathis] pbm ON m.AtomicNumber = pbm.AtomicNumber
 where
 --e.Protons > 0
 --and
 e.CanBind = 1
 and m.SlotNumber >  15

However, there are apparently some valid bonds with a few atoms greater than Slot 15:

Code:

 
SELECT *
  FROM [Physics].[dbo].[vwMilesMathisPeriodicTable]
  where SlotNumber > 15 and AlphaType > 0
  order by Protons

LTAM wrote:Why do LTAMKeys include 'N' values which should indicate empty slots?

Yeah just be sure to include the "CanBindsrc > 0 and CanBindDest > 0" it should remove the "N" binding.

LTAM wrote:Airman. If there were single atomic configurations, with fixed bonding slot configurations as we’ve been working with up to now, I’d say it makes perfectly good sense identifying all the possible bonds between all atoms, and to validate them against all the known molecules as we’ve been doing.

If, on the other hand, an atom’s bonding slot is able to take various TBLR forms, limited only by the number of protons in a slot, and charge field conditions we really haven’t gotten into yet, the task of identifying all possible molecular bonds is greatly increased. The problem is actually reduced to identifying all possible bonds between any two possible slot configurations. Bonds between particular atoms at particular extents may present additional constraints, like whether the bond is on an atom’s spinning carousel or not - identifying molecular bonds would amount to finding appropriate allowed bonds from a comprehensive pair bond list. I believe such an allowed pair bond list is a more general and robust solution which would allow us to find a more accurate number of all possible molecular bonds for up to eight or so atom type molecules. I suppose any accurate pair bond list should be validated against known molecules

I totally hear you on this one. I've added in the Tcount if it helps with the next build. This is all fairly still primitive at this point with what is a "bond". More variables are in play than what we are using at this time. I'll build another "validation" query using known atomic bonds in the formulas against Miles' bonding per his slots configs-LTAMKey.  Might produce some useful drop-outs to analyze.

Your work with the Tcount added above looks good!

Keep in mind sometimes more direct queries off of the raw data can show items that should drop out later in the more refined tables-views. This update tags these atoms as "not valid". Basically, CanBind=1 and IsValid=1 are the "gold standard" for queries from the table below.  It is definitely possible to add more conditional logic for tagging the "IsValid" column. :

Code:

BEGIN
UPDATE A
SET IsValid =0
FROM [dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] A
WHERE (SlotSpinSrc = 'N' or  SlotSpinDest = 'N');
END

.
Airman wrote. I see slots 17 and 19 included but not slots 16 and 18.

Cr6 wrote. Yeah the Elements3.csv didn't have any binds past 15 using "CanBind=1".

Airman. True, Elements3.csv does not contain any "CanBind=Y" for any slots past 15.

All ‘CanBind’ values in Elements3.csv are either ‘Y’, (yes) or ‘N’, (no). All unoccupied slots have ‘N’ values. All slots greater than slot15 also have ‘CanBind’ = ‘N’ values; as you know, those slots may not bond with another atom. The only slots that contain ‘Y’ values are those occupied atomic slots at which the atom may bond with with another atom, including the atom’s +/- x,y,z extents or slots 2 and 3.

Cr6 wrote.
Script out these views to see how it looks logic wise:
[Physics].[dbo].[vwMathisMoleculesBindLogicXYZ]
[Physics].[dbo].[vwElementsPositions]

Nothing shows here:

SELECT *
  FROM [Physics].[dbo].[vwMathisMoleculesBindLogicXYZ]
  WHere (SlotNumberDest > 15 or SlotNumberSrc > 15)
  and (CanBindSrc = 1 and CanBindDest =1)

Or from the source:
CODE:
SELECT e.*
 ,m.AlphaType
 ,m.SlotOrder

...

Airman. Confirmed that both those select queries output zero rows.

Throughout this exercise Both views’ vwMathisMoleculesBindLogicXYZ  and vwElementsPositions query editors are open in SSMS for review and easy reference.

Cr6 wrote. However, there are apparently some valid bonds with a few atoms greater than Slot 15:
CODE:
SELECT *
  FROM [Physics].[dbo].[vwMilesMathisPeriodicTable]
  where SlotNumber > 15 and AlphaType > 0
  order by Protons

Airman. Ran that select * and saw a 145 row output in atomic number order.

I see that AlphaType values come from MilesMathisPeriodicTable and may be equal to 0,1 or 2; presumably indicating whether an alpha type slot is either an LR or RL spin type(??). I also see an ‘AlphaTypeBind’ column with values 0 and 1.
 
In Elements3 there is no AlphaType column. Alphas are coded as ‘A’ or ‘V’ values in both the ‘Electrons’ column – indicating the electron alpha slot positions of both Top and Bottom; and in the ‘SlotSpin’ column, indicating that proton spin directions at the top and bottom of the alpha slot are either LR or RL.

Atoms may of course include one or two protons in any or all their hook positions; however, as you know very well, those occupied slots (16-19) are not allowed to bond with other atoms.

Up to 4 very small atoms – none larger than a single slot - can validly bond to a larger atom’s slots 2 or 3. Such small atoms may appear as occupied hook positions but even those small atoms should not be allowed to bond with a third atom.

Cr6 wrote. “there are apparently some valid bonds”.
Airman. Back to the 145 row output. Noticed that the last 21 rows were related to atoms larger than Thorium (Th, 90). Disregarding them for this discussion leaves 124 rows. That is very close to the total number of occupied hook positions in Elements3.

Occupied hook positions in Elements3.
s16. 16 single protons and 13 double protons. Tot 29 slots.
s17. 24 single protons and 9 double protons.  Tot 33 slots.
s18. 19 single protons and 14 double protons. Tot 33 slots.
s19. 21 single protons and 11 double protons. Tot 32 slots.
Total occupied hook position slots in Elements3.csv is 127.

Compared Elements3 127 occupied hook position slots to the select query’s 124 rows of “apparent bonds”.

35 atoms with 88 occupied hook position slots appeared in both Elements3 and the 124 row output.

The following 16 atoms exhibit slightly different occupied slots. I don't believe the order difference is a problem.
Astatine occupies slots(16,17,18). Shows up in slots (17,16).
Radon occupies slots(18,19). Shows up in slots (17,16).
Mercury occupies slots(18,19). Shows up in slots (17,16).
Platinum occupies slots(16,17). Shows up in slots (16,17,18,19).
Osmium occupies slots(18,19). Shows up in slots (16,17).
Lutetium occupies slots(18,19). Shows up in slots (18,17).
Ytterbium occupies slots(16,17,18,19). Shows up in slots (18,17).
Promethium occupies slots(16,17,18,19). Shows up in slots (19,18,17).
Neodymium occupies slots(16,17,18,19). Shows up in slots(19,18,17).
Tellurium occupies slots(18,19). Shows up in slots(16,17,18,19).
Antimony occupies slots(17,18,19). Shows up in slots (16,17,18).
Rhodium occupies slots(17,18,19). Shows up in slots (16,17,18).
Ruthenium occupies slots(18,19). Shows up in slots (16,17).
Technetium occupies slots(19). Shows up in slot (16).
Arsenic occupies slots(16,17,19). Shows up in slots (16,17,18).
Zinc occupies slots(18,19). Does not show up in the 124() row output.

All remaining atoms in Elements3 did not contain any occupied hook position nor did those atoms show up in the 124 row output.

Consequently, I don’t believe the 145 row query output shows any valid bonds. There’s likely more than one problem, but mistaking occupied hook positions as valid bonds strongly indicates a logic problem.

I agree we are dealing with more variables than we’re aware of.

Cr6 wrote. It is definitely possible to add more conditional logic for tagging the "IsValid" column.
Airman. Very good.

Ran

Code:

BEGIN
UPDATE A
SET IsValid =0
FROM [b][dbo].[AtomicMilesMathisOrbitalsDetailAllBonds][/b] A
WHERE (SlotSpinSrc = 'N' or  SlotSpinDest = 'N');
END


and received the error.

Code:

Msg 102, Level 15, State 1, Line 36
Incorrect syntax near '.'.

I should strive to do data comparisons in SQL/TSQL, thanks for the personal attention and excellent learning opportunities.

I'll take another look for that logical problem tomorrow.
.

Here's the latest backup file. Sorry for the repeated restores. This has the MolOrder and Tcount added to the tables and views.

https://mega.nz/file/Ch8g2KzJ#FI3HrZYGyg6Xv8YflEjfw01M8OD8v2G3IkX0d8NgYSE

This had html tags added. With them removed it should update fine:

Code:

BEGIN
UPDATE A
SET IsValid =0
FROM [dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] A
WHERE (SlotSpinSrc = 'N' or  SlotSpinDest = 'N');
END

.

Cr6 wrote. Here's the latest backup file. Sorry for the repeated restores. This has the MolOrder and Tcount added to the tables and views.

Airman. Copy that MolOrder and Tcount are added Cr6. Dropped and restored to the new backup. Restores gave me catatonic panic attacks at first. Now the restoral routine is a relative comfort and good way to start the day.

Ran

Code:

BEGIN
UPDATE A
SET IsValid =0
FROM [dbo].[AtomicMilesMathisOrbitalsDetailAllBonds] A
WHERE (SlotSpinSrc = 'N' or  SlotSpinDest = 'N');
END

Checked DistinctFormulas and UniqueRowcounts, they remain at 11,344 and 3,485,659.

Did a select all from vwSysTableSizes to see no new tables, appreciating the view’s convenience.

Likewise ran the dynamic views query, (thank you very much), and saw a new View.
gOrientDBAllRules. 168,452 rows, 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, … , Color.

Cr6 wrote. This had html tags added. With them removed it should update fine:  

Airman. Oops, I should have read ahead, I think you’re saying a simple standard sql restore would work fine. Too late, I’d already used your modified restore. Let's say I'm happy with just one restore a day.

Two View reviews. vwElementsPositions and vwMathisMoleculesBindLogicXYZ. As per your recommendation to try and figure out your SQL binding logic.

vwElementsPositions. 1710 rows. 89 cols. AtomicNumber, AtomicSymbol, … , e6z, SlotOrien, SlotSpin, CanBind, LTAMKey, BindKey.

This 102 script line view is taken from the table, ElementsPositions3 with a few changes. That table looks the same as the atomic data, currently the ElementsPositions3 csv file, ‘including the slotlayout diagrams’. The view however, doesn’t include the SL diagrams, instead the view adds two new columns after ‘CanBind’.

1. ‘LTAMKey’– Five values  from: ‘Electrons’ + ‘SlotNumber’ + ‘SlotOrien’+ ‘Protons’ + ‘SlotSpin’. Same 5 value code used in Jupyter notebook’s TBLR SL diagram tab.

2. ‘BindKey’ - Two values  from: ‘Electrons’+’SlotSpin’ as BindKey. Which would appear as TL,TR,BL,BR, just like from Miles’ Diatomic Hydrogen paper. The values also include alpha values AA and VV.  

vwMathisMoleculesBindLogicXYZ. Select * currently returns 668,212 rows  165 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest, SlotDirectionElectronBond.

All the atomic details necessary to compare two potential atomic bonding slots, A and B (‘Src’ and ‘Dest’) as a possible valid bonding site.  

For starters, I know most of the data, but there are still plenty of columns I don’t. Such as: AlphaType, AlphaTypeRemainder, MathisCarouselAlphaTypeFull, ProtonsMM. Neverthheless, just reading a single row of the select all query output is nice. One can review all the details (atoms, LTAMKeys, TBLR data, … ) needed to evaluate that particular atomic bond. I’ve always thought the binding rules would apply equally well in either direction. Maybe that’s why A.AlphaType must be equal to or larger than ‘B.AlphaType’.  ‘CanBindSrc’ and ‘CanBindDest’ values can be 0 or 1. I assume both values should be 1 for valid bonds.

“A.Electrons  + A.SlotSpin + B.Electrons + B.SlotSpin  as SlotDirectionElectronBond”.
The final column, ‘SlotDirectionElectronBond’ appears to be the shared-slot bond’s TBLR description.

Code:

 ,

CREATE VIEW [dbo].[vwMathisMoleculesBindLogicXYZ]

AS


WITH Mathis
AS (
 SELECT e.*
 ,m.AlphaType
 ,m.SlotOrder
 ,pbm.MathisCarouselAlphaTypeFull
 ,pbm.AlphaTypeRemainder
 ,m.Protons AS ProtonsMM

 FROM [Physics].[dbo].[vwElementsPositions] e
 JOIN [Physics].[dbo].[vwMilesMathisPeriodicTable] m ON e.AtomicNumber = m.AtomicNumber
 AND e.SlotNumber = m.SlotNumber
 LEFT JOIN [Physics].[dbo].[vwProtonBalanceMathis] pbm ON m.AtomicNumber = pbm.AtomicNumber
 where e.Protons > 0
 )

From near the top of the view’s script.

Near the top, ‘WITH Mathis AS (  SELECT e.* …  ’. How the two slots are selected (?) doesn’t make sense to me yet. Why are there e, m, ppm prefixes? The section also draws from two other views (vwMilesMathisPeriodicTable and vwProtonBalanceMathis) and the Mathis table.

Next I see two times eighty-two atomic column names (script lines not shown) assigned to both A and B.  

Understanding the view’s SQL binding logic is the current goal. Believed to be located somewhere within this final section.

Code:

FROM Mathis A
FULL OUTER JOIN Mathis B ON 1 = 1
WHERE (
 (
 A.Protons > 0        
 AND B.Protons > 0
 )
 OR (
 A.ProtonsMM > 0        
 AND B.ProtonsMM > 0
 )
 )
 AND (A.AlphaType >= B.AlphaType)  
 AND (
 (
 (A.SlotSpin <> B.SlotSpin)
 OR (
 A.SlotSpin = 'N'
 AND B.SlotSpin = 'N'
 )
 OR NOT (
 (
 A.SlotSpin = 'A'
 AND B.SlotSpin <> 'A'
 )
 OR (
 A.SlotSpin <> 'A'
 AND B.SlotSpin = 'A'
 )
 )
 )
 -- AND NOT (A.SlotSpin = B.SlotSpin)
 )
 --and A.CanBind = B.CanBind
 --AND A.CanBind > 0
 --AND B.CanBind > 0
 AND A.Protons > 0
 AND B.Protons > 0
 AND B.AlphaType > 0
 AND A.AlphaType > 0
 AND (
 A.SlotNumber NOT IN (
 18
 ,19
 )
 OR B.SlotNumber IN (
 18
 ,19
 )
 )

and A.Electrons + A.SlotSpin + B.Electrons + B.SlotSpin  not in (  
     'TRTL', 'BRBL', 'BRTR','BRTL' )
--and
--Case when (A.Electrons = 'A' and B.Electrons = 'A') then 1 else
--Case when A.Electrons = 'B' and B.Electrons = 'T' then 1 else
--Case when A.Electrons = 'T' and B.Electrons = 'B' then 1 else 0 end end end =1
--and CASE WHEN ((A.SlotNumber=1 and A.AtomicNumber <= 4) or (B.SlotNumber = 1 and B.AtomicNumber <=4)) Then 0 else 1 End = 1
ORDER BY A.AtomicNumber
 ,A.SlotNumber
 ,B.AtomicNumber
 --,B.SlotLayout

GO

The binding logic contained within the second recommended view looks simple but its whooping my butt.

a. First test that each slot contains one or more protons (A.Protons > 0 AND B.Protons > 0).

b. There are those ‘ProtonsMM’ values again, this time for A and B.

c. “AlphaType >= B.AlphaType”. ‘AlphaType’ is one of five columns from the 'Mathis' table.
“Mathis. 1282 rows – 5 cols. UID, AtomicNumber,Position,SlotNumber,AlphaType”.
‘AlphaType’ takes a values of 1,2,3,4,5 or 6. I think that number indicates how many protons the slot contains, of any TBLR type, not just alphas(?)

Why must the larger of the two AlphaTypes, if present, be the A slot at left? Is it a size sorting? Would the slots need to be reversed if the larger ‘AlphaType’ were on the right?  

d. Don’t know what exactly the spin checks are doing.

e. The three comparisons: 1. “--and A.CanBind = B.CanBind”;  2. “--AND A.CanBind > 0”;  3. “--AND B.CanBind > 0”; are not currently used but appear to be a reminder for future inclusion.

f. “AND (A.SlotNumber NOT IN (18,19) OR B.SlotNumber IN (18,19)”. Why are only two of the 4 hook slots(16-19) included? This is the sort of error that could account for those 124 hook positions appearing as “apparently valid bonds”. Except those 124 apparently valid bonds include all 4 hook positions, not just slots 16,and 17.

g. “and A.Electrons + A.SlotSpin + B.Electrons + B.SlotSpin  not in ( 'TRTL', 'BRBL', 'BRTR','BRTL' )”.
Looks like it came directly from the Diatomic Hydrogen paper.  We know that Miles stuck to the minimum essentials, shouldn’t we also include the remaining invalid combinations:  'TLTR', 'BLBR','BLTL','BLTR'?

h. Looks like other electron position cases are included for future consideration.

i. Also special rules are needed for single slot1 atoms, Hydrogen (H,1), Helium (He,2) and Lithium (Li,3).

j. All the commented out “--AND cases …” look like things to be played with, the beginnings of a possible binding logic sandbox(?).

Its clear I’ll need to spend a great deal more time and effort studying your scripts before I can properly understand ‘Physics’. Thanks for the exercise and your patience.

Having Second Alpha Thoughts. I’m having second alpha thoughts. Looking at the paper once again I realized ‘Diatomic Hydrogen’ includes two more valid “alphas” with TB electron configurations and single directional slot spins that we haven’t included or mentioned. TLBL and TRBR. Do we need two new alpha designations beside A (LR), V (RL), like U(LL), and W(RR)?  

Perhaps we can work with TBLR designations for each epn in the stack or modify or discard the A, V, (and never mind U, W) special case types. I believe the Tcount value is still needed to determine where within the single or double proton spin directional slot the electron position changes from Top to Bottom; and not where the change in spin direction occurs as I previously stated. Tcount also identifies where the LR and/or TB change occurs in odd numbered epn set alpha stacks (3, 5). But you're right, Tcount may not amount to anything.
.

Thanks LTAM for looking over the latest file.

I'm thinking that I may need to build out possible layouts-geometry with a view using "alpha" or "beta" in the name.  The convention these days is to use "Bronze-Silver-Gold" for loading.  Bronze is the actual source data and it is curated there after to better elements.

Since we are trying to layout 2-D records for a 3-D layout per Miles with fidelity, it is tricky.  Some 3-D force graph force layouts with javascript engines can do the basics:
https://github.com/H4kor/graph-force

List of engines people are working on: https://github.com/topics/force-directed-graphs

What you've built with Jupyter and what Nevyn has built up with his engine is really quite nice since it renders as expected. With databases and chain-linking sources to destinations...the geometry gets a bit compromised, hence we have to use flags like IsValid and CanBind. I tried to chain Sources to Destinations from known good rules. If one starts on "either" side then the syntax has to account for it. I tried to set up something a bit trustworthy with Src to Dest bonding. The drop outs are a concern. I was leaning to going to a graph database structure just because it is easier to account for relationships-entities/parent-child wise. When looking at relationships or possible relationships...database links tend to be too conservative. Hence, we can use the parsed elements as sources but their linkages may need a graph style or full on javascript-python-3D engine (ala DragonFace's renderings). Keeping the rules across this is very tricky as you know. Basically, we have to take the questions: "How does this bind with classic bonding notation? How does it bond with Miles?"

I was just trying to get the basics of how does Miles' rules-slot bonds work with mostly "known bonds" from sources. I know it is a marriage in hell but was trying to find a nice place where the relationships could be explored with it all inclusive. We can definitely work with "IsValid" flags to leave out bad relationships. Basically, Chemspider or other sources can say "these xAtoms 'bond'!"....but per Miles.. can we capture and show all the detail with them? We may need to do more exploration with "alpha" and "beta" style tags in the 2-D world.

Also, I had a bunch of legacy stuff from years ago included such as protonsMM and AlphaTypeRemainder....this can be left in but doesn't need "filtering" or focus...basically leave some older stuff as artifacts (columns).

Going forward I'll script out "views" here on the site directly. If a rebuild of the Physics database-tables is needed we can do it but. It is generally easier to just work and share perspectives with queries initially. Essentially we need to get that pic of yours from Miles for spins into a SQL friendly matrix that can be used for a 2-D model. Graph layouts may give some flexibility with this. The 2-D tables were meant to align Miles' structures with parsed atoms. Of course, the 3-D with geometry is the actual "truth" of it...and 2-D can only somewhat approximate it.  Just my thoughts...

.

Cr6 wrote. Essentially we need to get that pic of yours from Miles for spins into a SQL friendly matrix that can be used for a 2-D model.

Airman. If I understand correctly, this is another opportunity to describe charge field atomic bonds in terms of Miles’ Diatomic Hydrogen paper * (DH). Good thing too, with a total of 16 possible bonds, 8 valid and 8 invalid, its my best effort yet.

As described in the paper, a vertically spin oriented proton with either a left or right (L R) spin and a captured electron at either the proton’s top or bottom (T or B) pole A – as in the diagram’s top rows of electron/proton e-p sets) may or may not bond to another proton and its attendant electron (B – the second row e-p sets). Bonding depends on the vertically adjacent e-p pairs’ specific e-position (Top or Bottom) and p-spin directions (Left or Right). A single e-p set is described by a two letter code with four possibilities: TR, BR, BL or TL. Valid and invalid bonds are described using two such two letter e-p BTLR codes, resulting in a total of 16 possibilities, numbered 1-16 for reference.

1. TRTR, 2. TRBR, 3. TRBL, 4. TRTL, 5. BRTR, 6. BRBR, 7. BRBL , 8. BRTL,
9. BLTR, 10. BLBR, 11. BLBL, 12. BLTL, 13. TLTR, 14. TLBR, 15. TLBL, 16. TLTL

Valid bonds from the paper include check marks (and green highlighted TBLR data):
1. TRTR, 3. TRBL, 6. BRBR, and 15. TLBL.  
Invalid bonds from the paper include red X’s (and lavender highlighted TBLR data):
4. TRTL, 5. BRTR, 7. BRBL, and 8. BRTL.


The validity of the remaining 8, A and B combinations are as follows.
2. TRBR, is valid because of the electron TB combination.
9. BLTR, is not valid because of the electron BT combination.
10. BLBR is not valid – similar to 7. BRBL.
11. BLBL is valid – similar to 6. BRBR.
12. BLTL is not valid because of the electron BT combination.
13. TLTR is not valid – similar to 7. BRBL.
14. TLBR is valid because of the electron TB combination.
16. TLTL is valid – similar to 6. BRBR.

The 8 of 16 valid bonds (green highlight):
1. TRTR, 2. TRBR, 3. TRBL, 6. BRBR, 11. BLBL, 14. TLBR, 15. TLBL, 16. TLTL.
The 8 of 16 invalid bonds (lavender highlights):
4. TRTL, 5. BRTR, 7. BRBL, 8. BRTL, 9. BLTR, 10. BLBR, 12. BLTL, 13. TLTR.


Valid Charge field atomic e-p stacks. Any given slot may contain from 1-6 e-p sets, all of which must follow the same essential BTLR rules between vertically adjacent e-p's. From the top of the column to the bottom, there can be either a single spin direction (R or L) or there can be only one change in spin direction, from R to L or from L to R. There can also be either a single T to B change in the column’s electron positions, or not. Note that a B to T electron position change is not allowed since it prevents proton-proton bonding.

All valid columns shown are numbered 1-8.
a. Columns with a constant e-pos (T or B) and a constant p-spin (L or R):
1. TRTR, 4. BRBR, 5. BLBL, 8. TLTL.
b. Columns containing a T to B change in e-positions:
2. TRBR, 3. TRBL, 6. TLBR, 7. TLBL.
c. Columns with a single change in spin direction (R to L) or (L to R).
3. TRBL, 6. TLBR.

Again, stacks contain 1 up to six e-p sets. It is assumed that the single change in either the electron position and/or proton spin need not occur at the vertical center of the slot.

Shared slot bonds between atoms must also follow the same column configurations. Bonds that result in e-p stacks greater than six are not allowed, the resulting increased charge current would blow or break the stack apart.

*
http://milesmathis.com/index.html
332. Diatomic Hydrogen. My new charge bonding explains this much better than electron sharing. Plus an analysis of spin isomers. 9pp. http://milesmathis.com/diatom.pdf
.

Just wanted to give a quick update with OrientDB and modeling Miles' work.  This is extremely Alpha at the moment but something did show that was curious. 4 groups for HasBind between Atoms? Not sure why the engine laid it out this way in the graph. It hints at what I'm trying to get at...there may be a limit at 2000 in settings for Nodes/Edge to Edge. Each green link is a slot bond. I still need to work on getting Slot Labels added. I'll have to get you guys set up with OrientDB since the freeware community version is really free but loading takes effort. Not all rules are included with this yet either. I'll need to use the matrix above for more filtering:



Here's Neodymium in the bottom left corner:



Bottom Right with Aluminum:

.
Airman. Very interesting images Cr6. Maybe the four groups do indicate 2000 non-contiguous(?) bonds.

Cr6 wrote. Essentially we need to get that pic of yours from Miles for spins into a SQL friendly matrix that can be used for a 2-D model.

Cr6 wrote. I'll have to get you guys set up with OrientDB since the freeware community version is really free but loading takes effort. Not all rules are included with this yet either. I'll need to use the matrix above for more filtering:

Airman. I’m not sure if I’ve helped with that sql friendly matrix yet or not. Last time I showed a table with 6 sets of e-p’s and 5 rows of bonds for each of the 8 valid slot columns. That table is too small to account for all possible slot bond combinations. I’ll try again, this time adding 4 more rows of bonds.

The 8 valid bonds between any two vertically adjacent protons are 1. TRTR, 2. TRBR, 3. TRBL, 4. BRBR, 5. BLBL, 6. TLBR, 7. TLBL, 8. TLTL. The columns are renumbered 1-8 according to those valid bond references which appear halfway down the chart, the underlined row of bonds between values P1 and P2. P5, P3, P1, P2, P4, P6 is the sequence in which 6 protons are added to a slot.

   1      2      3       4      5        6       7      8

TRTR TRTR TRTR BRBR BLBL  TLTL  TLTL  TLTL

TRTR TRTR TRTR BRBR BLBL  TLTL  TLTL  TLTL
                  P5
TRTR TRTR TRTR BRBR BLBL  TLTL  TLTL  TLTL
                  P3
TRTR TRTR TRTR BRBR BLBL  TLTL  TLTL  TLTL
                  P1
TRTR TRBR TRBL BRBR BLBL TLBR TLBL TLTL
                  P2
TRTR BRBR BLBL BRBR BLBL BRBR BLBL TLTL
                  P4
TRTR BRBR BLBL BRBR BLBL BRBR BLBL TLTL
                  P6
TRTR BRBR BLBL BRBR BLBL BRBR BLBL TLTL

TRTR BRBR BLBL BRBR BLBL BRBR BLBL TLTL

Showing bond type 'TRBL' ProtonCount=6, and Tcount=3. Whether the 1-8 type of bond occurs between P1 and P2 depends on the numbers of protons in the slot, and the slot's Tcount value.

In order to identify every slot’s TBLR data, I now believe that instead of using AA or VV to identify just the two special case alphas: TRBL and TLBR, every slot will need to be assigned one of the eight valid type bonds along with a Tcount value. Although Tcounts aren’t needed for constant p-spin and constant e-position cols 1. TRTR, 4. BRBR, 5. BLBL, 8. TLTL. Then let those four Tcount values equal N/A.


Here are 8 examples of completely determined TBLR slot data.
a. Type TRTR, ProtonCount=6, Tcount=4. Although Tcounts aren’t needed for constant p-spin and constant e-position cols 1. TRTR, 4. BRBR, 5. BLBL, 8. TLTL. Then let Tcount=N/A
b. Type TRBR, ProtonCount=4, Tcount=3.
c. Type TRBL, ProtonCount=6, Tcount=4.
d. Type BRBR, ProtonCount=3, Tcount=N/A.
e. Type BLBL, ProtonCount=6, Tcount=N/A.
f. Type TLBR, ProtonCount=6, Tcount=1.
g. Type TLBL, ProtonCount=5, Tcount=4.
e. Type TLTL, ProtonCount=2, Tcount=N/A.

Does that sound any more sql friendly to you?

\//\\\////\\\\\//////\\\\\\/////\\\\///\\/


Update on plotting protons with two different spin colors: blue for left (L) and red for right (R). The colors ‘fade’ for points further from the viewer, making some of the red protons orange. Neutrons are larger green markers. Blue and green fade to a color between the two. That option is easily disabled. Electrons are smaller and cyan colored only, not yet broken into two different top or bottom types yet. There’s enough confusion as is.
I always find it amazing that with a slight constant motion, such as rotation, the positions of all the particles in any of the four subplots are entirely discernible. The moment the motion stops however, the pattern is lost, any plot then requires careful study. Protons with stylized emission planes would help make images of charge field atomic configurations easier to perceive. I wish matplotlib included 3D markers or markers that could be assigned to any single axis like a circular emission plane would be acceptable. I checked but didn’t see any new inspirations in the section, I did however see something I hadn’t noticed before


https://matplotlib.org/stable/gallery/mplot3d/rotate_axes3d_sgskip.html

Rotating a 3D plot A very simple animation of a rotating 3D plot about all three axes.
See Animate a 3D wireframe plot for another example of animating a 3D plot.
(This example is skipped when building the documentation gallery because it intentionally takes a long time to run)

Downloaded and ran the ipynb file for that page, rotate_axes3d_sgskip.ipynb and received an error.
ValueError: 0 is not a valid value for vertical_axis; supported values are 'x', 'y', 'z'

There’s also -
https://matplotlib.org/stable/gallery/mplot3d/wire3d_animation_sgskip.html

Animate a 3D wireframe plot A very simple "animation" of a 3D plot. See also :doc:rotate_axes3d_sgskip.
(This example is skipped when building the documentation gallery because it intentionally takes a long time to run.)

Downloaded and ran wire3d_animation_sgskip.ipynb but it just sat there.

I don’t have high hopes, I’ll try a bit harder to see if I can get a matplotlib charge field atom to rotate about just the vertical z-axis and see how intentionally long it takes.

P.S.
1. 'case alphas: BRBR and TLBR'. Changed to 'TRBL and TLBR'.
2. Added underline to the Vertical center bond row containing all valid bond types.
3. Added underline to the image.
4. Added " the underlined row of bonds' to the text.
P.P.S.
Corrected a. and c. Tcount's from 3 to 4.
.

LongtimeAirman wrote:.
Airman. Very interesting images Cr6. Maybe the four groups do indicate 2000 non-contiguous(?) bonds.

I don’t have high hopes, I’ll try a bit harder to see if I can get a matplotlib charge field atom to rotate about just the vertical z-axis and see how intentionally long it takes.
.

I can get it up to 10,000 before I get out-of-memory errors. I just may need a bigger machine to get at 100,000+. I may need to remodel this a bit to show almost every column as a sub-graph. It should allow cleaner specificity in graph db queries. Graph databases are often hard to debug to explain what X connects to Y 5 times in a layout. Frankly, the graph db, whether OrientDb or Networkx, is more friendly to Miles' layouts. Most of these layouts don't work over time or in 3-D changes like rotations, so mostly they are snapshots.

.
Spent more time looking into automated rotating plots - such as with matplotlib and ipyvolume, without success.  

Added the code to a. properly read the atomic R and L, ‘V’ alpha type spinning proton configuration (RL) data; and b. plotting the separate R and L spins in either single or 4 subplot type, 3d plots. Then Pushed those changes to github.

Once again, considering the 8 valid bonds:
1. TRTR, 2. TRBR, 3. TRBL (V), 4. BRBR, 5. BLBL, 6. TLBR (A), 7. TLBL, 8. TLTL.

Four of those eight possible proton stacks are the constant proton spin, constant electron position epn sets with ‘Tcount’ value of zero (or N/A):  
1. TRTR, 4. BRBR, 5. BLBL, 8. TLTL
The remaining four proton stack types are TB electron position epn’s:
2. TRBR, 3. TRBL (V),6. TLBR (A), 7. TLBL. Lately I’ve been considering the TB electron position type stacks as the so-called ‘alpha’s, each needs a ‘Tcount’ value of 1 thru 5.

Need to add 'E' (TRBR), and 'W' (TLBL) types to the atomic data next.
TRBR - Since both the T and B protons are spinning R, I decided to call the TRBR alpha type ‘E’ - for east.
TLBL - Since the T and B protons are spinning L, TLBL can be west, ‘W’.


Where should the E and W alpha slots be located? Consider Thallium, Tl, 81. A render from a year and a half ago, a more recent TBLR slot layout diagram and a plot including the latest R and L colored protons. I would expect that with a 2:1, upward/downward, charge/anti-charge field prevailing field we can expect the ‘E’ alpha, TRBR might fit best at slot5, channeling charge mainly 'E' and upward, while the ‘W’ alpha might fit best at slot4, channeling charge to the left and downward. The four carousel arms mainly channel charge outward, but I don’t see those arms (slots 6-9) being E’s or W’s. Ill go with slots 4 and 5 for starters.

Any yea or nay or other thoughts?

Maybe more than half of the slot1’s stacks will be ‘A’s (TLBR), and the other half would be ‘V’s (TRBL)?

That’s all for now.

Oh, by the way, my domestic responsibilities have increased. I've been told I’ll be doing most all chores here at home, (nowhere near as well as she can), for the next few months. Due to a long awaited medical procedure (not for me) and recuperation.

P.S. Changed "'TRBR' can be west, ‘W’". to "'TLBL' can be west, ‘W’"
.

Hi LTAM,

Sorry to hear about family medical procedures.
.I know the "extra" effort needed after my wife was out for 1 month. No worries, I'll keep plugging away with your charts-matrices.  

Just want to model using a matrix for numbers using matrix style math if possible.

Examples:  
https://bvanderlei.github.io/jupyter-guide-to-linear-algebra/Matrix_Algebra.html


Interesting application with vectors and chemical formulas:
https://bvanderlei.github.io/jupyter-guide-to-linear-algebra/Applications_VS.html

https://en.m.wikipedia.org/wiki/Rotation_matrix

.

Indium, In 40. The TBLR slotlayout diagram shows Alpha slots ‘W’,’V’,’A’,’A’, and ‘E’ down along the z axis. The 'W’ and ‘E’ proton spin directions have been added to all atoms’ slots four and five and the proton plots. Adding a second electron type is next.

Cr6 wrote. Essentially we need to get that pic of yours from Miles for spins into a SQL friendly matrix that can be used for a 2-D model.

Cr6 wrote. Just want to model using a matrix for numbers using matrix style math if possible.

Airman. I’m sure I’m not understanding you properly Cr6. I’m familiar with linear algebra – I bought the text and passed the class. The laguide info you included looks real interesting and definitely worth studying. I’d be happy to include matrix operations if I could see how to apply them to the 8 valid epn stack bond type sets.

Maybe I’ve made things too complicated with alpha codes ‘A’, ‘V’, ‘E’, ‘W’ and ‘Tcount’.

The main advantage of using ‘A’, ‘V’, ‘E’, ‘W’, and ‘Tcount’ is that it allows us to fully describe the slot’s correct two letter p-spin/e-position values (TR,BR,BL,TL) for each and every epn within that slot without explicitly identifying each and every (1-6)  p-spin/e-position.

The main ‘disadvantage’ of using ‘A’, ‘V’, ‘E’, ‘W’, ‘Tcount’ and ‘Protons’ is the need for that conversion code to build or determine possible bonds between atoms. Does that extra coding requirement present an additional, detrimental burden on the sql database?

If so, there’s an easy alternative. I’ll just add 10 (or 12) new data columns to the atomic data such that every slot can include each and every epn set’s (1-6) proton spins – containing only R or L spin values, and 1-6  ‘Electrons’  data - containing only T or B position values. All the information needed to completely identify the slot’s TBLR data without ‘A’, ‘V’, ‘E’, ‘W’, and ‘Tcount’. That could also make coding the Notebook atoms and molecules easier as well.  

Or I could keep the ‘A’, ‘V’, ‘E’, ‘W’, ‘Tcount’ information and also add the explicit 1-6 p-spin and 1-6 e-position data, making sure the two redundant data sets agree.

Does that sound any more sql matrix friendly to you??
.

This what I was looking at: https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/matrix-math-in-sql/

.

Argon, Ar 18. I’ve taken the liberty of adding pale green lines between each proton pair along the shared spin axis and numbered slot labels for each slot, 1-9. Smaller, ‘T’ (top, cyan) and ‘B’ (bottom, black) electrons have been added since last time. ‘R’ (right) spinning protons are red, and ‘L’  (left) spinning protons are blue. Neutrons are the larger green circles, two in every Ar slot. ‘A’ is TLBR, ‘V’ is TRBL. ‘E’ is TRBR, and ‘W’ is TLBL. Slot6 is TLTL, slot7 is BRBR, slot8 is BRBR, and slot9 is TLTL. A couple of slot bond sets are not present - TRTR and BLBL (I wasn't trying to include then all). All the plotted particles appear to me to agree with the slotlayout diagram.

Hi Cr6. Element-Positions3.csv now has ‘W’ and ‘E’ alpha types (with TB electron configurations), assigned to each atom’s slots 4 and 5. Those changes are pushed to github. Next, having included new type bond sets, I’ll make the necessary ‘W’ and ‘E’ csv electron position changes to agree with the new bond types, as I’ve done with Ar in the image above. An easy change with the proper (slotNumber, Protons, AtomicNumber) sort.  

Nevyn mentioned that occasionally one comes across code that one has written, and yet is unable to immediately understand or even figure out how the code is supposed to work. It took me a couple of errors, days and effort to see how the whole copy atom and plot process works. The more I think about it, the more I like the idea of adding 10 or so columns to the atomic data width, identifying each and every epn's type (TR,BR,BL,TL). It should make working with that data easier, especially if I can get it into some numeric matrix form    .

Cr6 wrote. This what I was looking at: https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/matrix-math-in-sql/

https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/matrix-math-in-sql/
Joe Celko’s 2012 Redgate Topic, MatrixMath in SQL is short and simple. It briefly states most all the linear algebra matrix operations one needs to know when using SQL. Joe informs us that additional matrix operations will involve more complex math.

https://github.com/bvanderlei/jupyter-guide-to-linear-algebra/blob/main/Applications.ipynb
On the other hand, the Jupyter guide to linear algebra, laguide appears to be a linear algebra course using graphs.

That’s my impression anyway, I look forward to possibly studying them in the future.

Thanks for your regular additional site postings Cr6.  

And thanks for understanding my coming domestic changes.
.

Looking good LTAM!

Well described as well. I can refactor a new layout file fairly quickly at this point.

Found this that might be useful as a good reference at some point.
Python Programming And Numerical Methods: A Guide For Engineers And Scientists
https://pythonnumericalmethods.berkeley.edu/notebooks/Index.html

BTW, I added in your most recent .csv file to the ElementPositions3 table and have a new backup file below. Note the new file added almost 1 gig in size to the database. Looks like a lot more bonds were formed. We have 15,277 distinct formulas loaded.
-----
Link to .bak file: https://mega.nz/file/m4UHwBjS#MOuBmDPbrWln6vjl8oeUC35MgtfzgyvLQWqZbcLMinE

.

Reviewing the atoms and their slot stacks, Yttrium looks good.

Cr6, You beat me to it. I posted my latest csv changes to github today too. That is, after downloading and restoring the sql database using 20230928Physics.
 
The projected 30 minute mega download stopped three times. I was able to proceed at first by opening a second browser download page at mega, and twice later by clicking on the M icon, arriving at the login screen, then clicking on the browser’s back arrow – to get to the previous mega download screen, including a prompt asking if I wanted to resume the download. Clicking yes worked every time, for a while anyway. Are they nudge, nudging me to register?

New ‘Physics’ updates require immediate review. I saw 20230928Physics.bak was 3.3 gbytes for starters, it became 5.26 gbytes after the restoral.    

Once again, using your neat and dynamic queries help speed things up, thank you very much.

DistinctFormulas: was 15,282, is now 15277. We lost five formulas? Maybe they were redundant?
UniqueRowcounts: was 3,485,659, is now 4,168,383. A 20% increase.

New Views:
gOrientDBAllRules. 133,823 rows. 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, … , Color.
gOrientDBAtomic. 122,051 rows. 13 cols. SlotUniqueID, AtomUniqueID, ... , AlphaTypeSrc,       AlphaProtonCarouselRemainder.
gOrientDBPeriodicTable. 1710 rows. 16 cols. AtomicNumber, AtomicSymbol, Element, SlotNumber, AlphaType, ... , SlotSpin.
vwAtomicElementsMolOrder. 47,592 rows. 8 cols. ID, Molecule, SeqNo, Item, Element, Number, Formula, MolOrder.
vwAtomicPivotSource. 40,627 rows, 8 cols. ID, Molecule, SeqNo, Item,Element, Number, Formula, OrderSeq.
vwSysDynamicQueryViews. The 61 views are listed
vwSysExecutingQuery. Opened a new Query Edit Window to see it. No idea what this is.

New Tables:
tmpRawJSONFiles. 2 rows. 4 cols. UID,JSONString,SourceFile,LoadDate.
tmpRawJSONFilesFormulas. 2,001 rows. 4 cols. Formula,LoadType,MD5,LoadDate
tmpTopoMat. 9,212 rows. 2 cols. TopoMatID, Formula.
ElementsPositions3.  1710 rows – 87 cols.
ElementsPositions3old.  1710 rows – 87 cols.
ElementsPositions3old2.       "             "
ElementsPositions3old3.       "             "

I haven’t spent enough time looking at the changes, here’s the updated index

Code:

////////////Updated 28 Sep 2023////
#Graph Tables.
gMathisPeriodicTableAtomLTAM. 1,530 rows, 17 cols. Familiar data with $node schema info/code

/////////////////////////////////
#Tables.
AllTable.  335 rows -  4 cols. Quantity, Value, Uncertainty, Unit. No primary key. 355 atomic constants and relationships.
AtomicMilesMathisElementsPositions. 1710 rows and 88 cols. Haven't figured it out yet.
AtomicMilesMathisFormulas. 4,790 rows, 9 cols. ZID, Formula, CurrentAtom, NextAtom1, … , NextAtom6.  
AtomicMilesMathisMoleculesBindLogicXYZ. 883,986 rows, 166 cols. Each row is a bond. 1 min 3 sec.
AtomicMilesMathisOrbitalBondsParsed. 4,879 rows, 64 cols. ZMolecule, CurrentAtom, NextAtom1, … , 8p, 9s, 9p, ZID.
AtomicMilesMathisOrbitalParsed. 14,483 rows, 47 cols. ID ZMolecule ZItem ZFormula ... .
AtomicMilesMathisOrbitalsDetailAllBonds. 810,891 rows, 182 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 8 secs. 1 min 16 sec
AtomicMilesMathisPeriodicTable. 2,983 rows, 17 cols. UID AtomicNumber AtomicSymbol ... color. Pt data in a strange order?
AtomicMilesMathisPeriodicTableBase. 157 rows, 153 cols. RemainderAlphaLevel ... 9p. Mainly Atomic data (?).
AtomicMilesMathisProtonBalance.  157 rows, 12 cols. Carousel ... AlphaTypeRemainder
AtomicOrbital. 21,161 rows 46 cols. ID ZMolecule ZItem ZFormula ... .
AtomicOrbital1. Zero rows. 46 cols.  ID ZMolecule ZItem ZFormula, … , 9p. 00:00:00.
AtomicOrbitalsinMilesDetailSummary. 563,022 rows, 172 cols. ZID Formula CurrentAtom NextAtom1 ... e6zDest. 00:00:37.
AtomicRDKit. 92 rows -  38 cols. Each atom’s (1-92) select atomic values.
AtomicSourcesRDKit. 26 rows -  5 cols (PropertyID, property, notes, units and source).
AtomPeriodicTableAtomLTAMKey. 132 rows, 5 cols. ID LTAMKey CanBind Electrons AlphaType.
Chemspider. 66,281 rows. 5 cols. UID Line Content ChemspiderID LoadDate. Content includes various Chemspider molecular names. 
Circle. 36001 rows - 360 degrees in hundreths. Cols x y and z are NULL. Replaces rotation calculations with a table lookup.
Compounds. 262 rows - 3 cols. No, Compound, Formula.
CompoundsSmiles. 1351 rows - 6 cols. SMILES info(PID,id,EntryName,SMILES,MW,Selectivity_Index).
ElementAbundance. 78 rows – 9 cols. 78 Elements’ crustal abundances.
ElementsPositions. 1710 rows – 87 cols. 90 element data including SL diags.
ElementsPositions2. 1710 rows – 86 cols.
NEW: ElementsPositions3.  1710 rows – 87 cols.
NEW: ElementsPositions3old.  1710 rows – 87 cols.
NEW: ElementsPositions3old2.  1710 rows – 87 cols.
NEW: ElementsPositions3old3.  1710 rows – 87 cols.
EnergyLevel. 6 rows – 7 cols. EnergyLevel,ShellLetter,ElectronCapacity,s,p,d,f.
FormulaSuperConductor. 176 rows of FormulaSuperConductors
GraphMilesAtomNode – 157 rows - Through Atomic number 153. 8 columns (AtomicNumber, AtomicSymbol, Element,
GraphTempAtomNode. 90 rows, Up to Thorium. 8 columns (AtomicNumber, AtomicSymbol, Element, OrbitalGroup, Protons, Neutrons,
      GroupNumber, Period).
Ions. 64 rows – 5 cols. IonID,Ion,Charge,AlphaNm,Name
Mathis. 1282 rows – 5 cols. UID, AtomicNumber,Position,SlotNumber,AlphaType
MilesMathis. 12 rows – 4 cols. ID,Description,RawCalculation, Set2. Miles calcs.
MilesMathisPeriodicTable. 2983 rows – 18 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD. 2983 rows – 15 cols. 163 Atomic numbers x 19 slots.
MilesMathisPeriodicTableOLD2. 2993 rows, 18 columns.
nci. 150 rows – 2 cols. Compoundid, smiles.
Numbers. 65,536 rows – 1col, Number. Rows 1 to 65536 containing Number 0 to 65,535.
Orbital1. 344 rows – 27 cols. Atomic electron orbital info.
OrbitalMatrix. 157 rows – 30 cols. 163 elements with atomic electron orbital info.
Orbitals. 172 rows – 13 cols. 172 elements’ atomic electron orbital info.
PeriodicTable. 118 rows – 74 cols. 118 elements’ atomic data.
PeriodicTableGrouping. 110 rows – 30 cols. 110 elements’ atomic data.
PeriodicTableState. 112 rows – 12 cols. 112 elements’ atomic data.      
PeriodType. 10 rows – 2 cols. Period, PeriodTypeDescription - Atomic types, alkaki metals to noble gases.      
Species. 105,179 rows, 4 cols. ID, Molecule, Formula, Detail. Like Chemspider.
Species_Stg. 1998 rows – 3 cols. Molecule, Formula, Detail.      
Species20230212. 103,185 rows. 4 cols. ID, Molecule, Formula, Detail. 1 Sec.
sqlmol_bond_type. 0 rows. btid symbol.    
sqlmol_compound. 150 rows. compoundid, smiles  cols.    
sqlmol_compound_bonds. 0 rows. cbid, compoundid, btid, ceid1, ceid2.  
sqlmol_compound_elements. 0 rows. ceid, compoundid, atom, nodeid.    
sqlmol_compound_hfbonds. 0 rows. compoundid, chbid, ceid, cbid, btid, parseid.
sqlmol_element_type. 0 rows. symbol.                                
sqlmol_hfbond_type. 0 rows. btid, symbol.                                
sqlmol_symbol. 28 rows. 3 cols, code, type, Aromaticity.                              
STG_Orbital. 172 rows. 28 cols. 172 elements’ electron orbital data.
NEW: tmpRawJSONFiles. 2 rows. 4 cols. UID,JSONString,SourceFile,LoadDate.
NEW: tmpRawJSONFilesFormulas. 2,001 rows. 4 cols. Formula,LoadType,MD5,LoadDate
NEW: tmpTopoMat. 9,212 rows. 2 cols. TopoMatID, Formula.

/////////////////////////////////
#Views.
AtomicMilesMathisOrbitalsMissing. Zero rows, formula col header .
AtomicOrbitalBonds. 9028 rows. 53 cols. Atomic details and orbitals. All ZmoleculeOrder values equal 1.
AtomicPivotedByAtomicNumber. 3,809 rows. 92 cols. Atom1-Atom90 cols. 4 secs. 
Function_Assist_GETDATE. 1 row. 1 col, GetDate. Gives the date and time of the query function.
Function_Assist_RAND. 1 row. 1 col, RAND. Returns a random value between 0 and 1.
gAllowedBonds. Not in use any longer - Deleted due to size.
gJSONNodes. 215,301 rows. 1 col, Nodes. All molecular bonding sites?
NEW: gOrientDBAllRules. 133,823 rows. 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, … , Color.
NEW: gOrientDBAtomic. 122,051 rows. 13 cols. SlotUniqueID, AtomUniqueID, ... , AlphaTypeSrc, AlphaProtonCarouselRemainder
NEW: gOrientDBPeriodicTable. 1710 rows. 16 cols. AtomicNumber, AtomicSymbol, Element, SlotNumber, AlphaType,
      ... , SlotSpin
MathisEdgesGraphML. 247,747 rows. 6 cols. RowN, Source, Target, srcElement, trgElement, edges. 10 secs.  
MathisGraphBondsTCC. 2,677 rows. 8 col, Nodes. All molecular bonding sites?
MathisNodesEdgesAllBinds. 175,964 rows. 182 cols. LTAMKeySrc, LTAMKeyDest, AtomicNumberSrc, … , Color.
MathisNodesGraphML. 896 rows. Nodes.      
MilesMathisCalculus. 50 rows. 5 cols. Z, 2z, z3, NextNumber, MathisCalculus.      
vwAllTable. 335 rows. 4 cols. FloatValue, Quantity, Value, Uncertainty.        
vwAtomic. 391,741 rows. 160 cols. 50 seconds.
NEW: vwAtomicElementsMolOrder. 47,592 rows. 8 cols. ID,Molecule,SeqNo,Item,Element,Number,Formula,MolOrder
vwAtomicMilesMathisOrbitalsDetailAllBondsDupeAtoms. 391,741 rows 160 cols.
vwAtomicOrbital. 13,791 rows. 47 cols. ID, ZMolecule, Zitem, … , 9p, ZID.
vwAtomicOrbitalBonds. 4,736 rows. 56 cols. ZMoleculeOrder, CurrentAtom, ... , ZID.
 Atomic details and orbitals. All Zmolecule, Order values equal 1.
vwAtomicOrbitalPerm. 21,161 rows. 46 cols. ZID, ZMolecule, ZItem, … , 9p.
vwAtomicOrbitalsAllMiles. 2,557 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula. 17 seconds.
vwAtomicOrbitalsAllowed. 2,020 rows, 12 cols. MinAtomicNumberSrc, MaxAtomicNumberSrc,  MinAtomicNumberDest,
      MaxAtomicNumberDest,nAtomicSArc, ... , AlphaTypeDest.
vwAtomicOrbitalsCarbonCarousel. 494 rows, 5 cols. ElementSrc, ElementDest, cnt, LTAMKeySrc, LTAMKeyDest.
     Every row contains at least 1 carbon.
vwAtomicOrbitalsinMiles. 2,544 rows. 7 cols. CurrentAtom, NextAtom1, … , Formula. 23 secs.
vwAtomicOrbitalsinMilesDetail. 13,791 rows. 47 cols.  ID, ZMolecule, Zitem, … , 9p, ZID.
vwAtomicOrbitalsinMilesDetailAllBonds. 633,369 rows. 174 cols. CurrentAtom, NextAtom1, … ,
     Formula, … , SlotDirectionElectronBond. 01:17:21.
vwAtomicOrbitalsinMilesDetailCarbonFilteredOut. 156,668 rows. 170 cols. CurrentAtom, NextAtom1, … , Formula.
     00:25:10.
vwAtomicOrbitalsinMilesDetailSummary. 742,355 Rows, 180 cols. SlotDirectionSrc, SlotDirectionDest,  SlotDirectionElectronSrc,
     SlotDirectionElectronDest, SlotDirectionElectronBond2, ZID, Formula, CurrentAtom, NextAtom1, … , e6zDest. 00:01:08.
vwAtomicOrbitalsinMilesDetailSummaryPeriodicDetail. 1,620,765 rows and 328 columns. ZID thru 9p. 00:12:22. A lot of info.
vwAtomicOrbitalsinMilesDetailSuperConductors. 110,524 rows, 170 cols. CurrentAtom, NextAtom1, … , e6zDest.
vwAtomicOrbitalsNotinMiles. 63 rows. 8 cols. CurrentAtom, NextAtom1, … , Formula. 00:00:18.
vwAtomicOrbitalsNotinMilesAll. Stopped at 5 minutes
vwAtomicOrbitalsNotinMilesBySlotOrientation. 17 rows and 187cols.
vwAtomicPeriodicTableLTAMSpins. 13,740 rows 177 cols. ID, ZMolecule, … , SL4. 00:00:04
vwAtomicPivoted. 33,740 rows. 92 cols. ID, ZMolecule,  … , MolOrder. Took 4 secs to run this query. 00:00:03
vwAtomicPivotedAtomCounts. 105,179 rows, 23 cols. ID, ZMolecule, ZFormula, Atom1, AtomNumberCount10. 00:02:04
NEW: vwAtomicPivotSource. 40,627 rows, 8 cols. ID,Molecule,SeqNo,Item,Element,Number,Formula,OrderSeq.
vwChemSpider. 4,774 rows, 3 cols. ChemspiderID, Formula, Molecule. 00:00:00
vwCircle. 36001 rows. 1 col. Degree. Looks like random rotations (with select *) between zero
 and sequential rotations when using the select top 1000 values.
vwDeutrium. 85 rows. 4 col. ID, Molecule, Formula, Detail. 00:00:00
vwElementsPositions. 1710 rows. 89 cols. AtomicNumber, AtCurrentAtom, NextAtom1, … , Formula. 0 seconds.
 Element, AtomicTuple, … , SL4,LTAMKey, BindKey.  00:00:00
vwMathisLTAMMolecules. 397,328 rows. 121 cols. ZID, ZMolecule, … , 9p. 00:00:22.
vwMathisMaxSlotPivoted. 90 rows. 28 cols. AtomicNumber, AtomicSymbol, … , Slot19. 00:00:00.
vwMathisMoleculesBindLogic. 35,509 rows. 162 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest. The query took 3 secs.
vwMathisMoleculesBindLogicXYZ. 718,171 rows. 165 cols. AtomicNumberSrc, AtomicNumber Dest, … , e6zDest, SlorDirectionElectronBond. 00:00:46.
vwMathisMoleculesFullBindLogic. 4,174,262 rows. 254 cols. BondType, AtomicNumber, AtomicSymbol Dest, … , e6zDest. 00:07:17.
vwMilesMathisElectronBondingMapped, 2983 rows. 179 cols. UID, mOrbitalGroup, mProtons,mNeutrons, , ZSeqNo,
      ZItem, ZElement, ZFormula, … , 9p. 00:00:01. Resembling AtomicOrbitalBonds with plenty of potential atomic
      attributes.
vwMilesMathisPeriodicTable. 2,983 rows. 17 cols. UID, AtomicNumber, AtomicSymbol, … , Color. 00:00:00.
vwMilesMathisPeriodicTablePivoted. 2,983 rows. 35 cols. UID, AtomicNumber, AtomicSymbol, Element, , … , 19.
vwMolecule. 829,361 rows. 8 cols. ID, Molecule, Formula,  Item, RW, ASCIINum, Number, CharPlaceType. 00:00:41.
vwMoleculeAtomicWeight. 4,744 rows. 7 cols. ID, MolecularWeight, Formula,  Molecule, Number, NistLookup, ChemspiderLookup ,Total1stIonization. 00:00:02.
vwNumbers. 2,476,099 rows. 1 col. n. 1-2,476,099. 00:00:13.
vwPeriodicTable. 157 rows. 153 cols. RemainderAlphaLevel1, REM2, REM3, … , 9p. 00:00:05.
vwProtonBalanceMathis. 157 rows. 12 cols. Carousel, AlphaProtonCarouselRemainder, Alphas, Element, AtomicSymbol, Period, … , AlphaTypeRemainder.
vwServerIPAddress. 1 row, 7 cols. net_transport protocol_type auth_scheme ... public_nrt_transport
NEW: vwSysDynamicQueryViews. The 61 views are listed
NEW: vwSysExecutingQuery. Opened a new Query Edit Window to see it. No idea what this is.
vwSysRefreshViews. 1 row, 7 cols. net_transport protocol_type auth_scheme ... physical_net_transport
vwSysTableSizes. 55 rows, 6 cols. SchemaName TableName RowCounts Used_MB Unused_MB Total_MB

Csv file changes. I’d intended to complete an atomic review before posting my ‘E’ ‘W’ changes, but your new ‘Physics’ backup motivated me to post my latest csv file today.
1. CSV file. The slots 4 and 5 changes I mentioned last time, converting some electron position changes to match new alpha types 'E' and 'W'.
2. CSV file. This may be a biggy. Carbon C has occupied slots 1, 2 and 3. Slot1 is a four proton ‘A’ type. Single ‘Electrons’ in C Slots 2 and 3 were erroneously labeled ‘N’. Changed the ‘N’s to ‘T’ and ‘B’.
3. mBuilder. The notebook can now read the atomic data's eight TBLR  proton stack bonding types, and display plots including Right (red) and Left (blue) spinning protons and Top (cyan) and Bottom (black) electron positions.

I realize Carbon is an extremely common element, present in many formulas, would it be difficult to see how the Carbon correction affects(?) the totals?
.

Hi LTAM...

Here's your most recent file included. I might need to check out how "Cl" is getting faithfully parsed out. I have a few that don't render properly apparently. I deleted everything out that had "(" or ")" in the structures. This dropped out those 5 molecules. Can add them in later as needed with an update. A lot more bonds are now formed:

https://mega.nz/file/jgV2GQaJ#x98xF71-E0I1nD07h1e0Euqm82q0bld9-TbDGKAHsHA

.


Downloaded and restored to the new 20230930Physics.bak.

Modified Elements-Positions3.csv, creating a new csv atomic file Elements-PositionsEP. Adding 12 new data columns:  ep1, ps1, ep2, ps2, ... , ep6, ps6; where 1-6 ep1-ep6, indicate electron positions, with either 'T' or 'B' values; and 1-6 ps1-ps6 indicate proton spin values 'L' or 'R'. The new columns are added after ‘CanBind’ and before ‘SlotLayout’. The top left shows the new TBLR data for Thorium’s 1-19 slots.

As I recently indicated, I believe this change will make it easier for the ‘Physics’ sql database to read each atom’s TBLR data and to determine valid molecular bonds.

I’ll review the new csv file again before changing the Notebook code to read from it.
.

.

The above includes another change to the new ep1-ep6, (electron/position - T or B) and ps1-ps6, (proton/spin - L or R) data. The columns are re-ordered from: ep1, ps1, ep2, ps2, … , ep6, ps6. To: ep5, ps5, ep3, ps3, ep1, ps1, ep2, ps2, ep4, ps4, ep6, ps6. This change allows the slot’s complete TBLR data string to be read directly from the atomic data. The atomic data file Elements-PositionsEP has been pushed to github.

Cr6, I hope you're good with the ep and ps column additions. This last change seems like baby step progress, I wasn’t sure at first, it took me a couple of days to decide it was needed. Any assignment changes to a given slot's TBLR data now involves many separate atomic data columns. Rather than being limited to a single explicit slot TBLR assignment, I think we'll be needing a slot TBLR randomizing function to better account for likely slot TBLR variability.  

After my previous insufficient efforts, I think I’m finally justified in citing and following Miles’ Diatomic Hydrogen paper. The first and last time I added the atomic graphs to the Notebook, all the potential atomic bonding extents were identified with just the atoms’ slot number – 1-19. I think you’ll agree that having all potential bonding slots identified by complete TBLR data strings is an improvement. I can now move back to atomic graphs.

Cr6 wrote. I might need to check out how "Cl" is getting faithfully parsed out. I have a few that don't render properly apparently.

Airman. Is that something I can help with?

Cr6, with the latest ‘Physics’ bak files I forgot to mention that that berkeley.edu source you shared on Monday, Sep 25th, is a partial excerpt but it can still serve as a fine way to learn how to code in python using Jupyter notebook. That and the rest, thanks for the fine new set of resources.

On the subject of possibly expressing epn’s and bonds numerically and so allow matrix operations. I don’t see an easy solution, how does this sound. We can replace the T B L R with two pairs of two new number types - Dir and Rot. Dir indicates linear direction (T or B) and Rot indicates rotation direction (L or R) for any given x y or z axis:  xDir, yDir, zDir, xRot, yRot, zRot. As previously understood, each axis’ Dir and Rot values are defined with respect to the positive axis pointed upward.

There are three linear direction numbers. xDir, yDir, and zDir. An electron at a proton’s top ‘T’ pole could be given the number +1. A ‘B’ electron position may be numbered -1. Likewise, there are three rotation direction numbers xRot, yRot and zRot. An L spinning proton could be numbered -1 and an R spin could be numbered +1, as per the right hand rule. All existing 'T', 'B', 'L', and 'R' values may be changed to +/- 1.

Interesting that both Dir and Rot can only take binary values, -1 and 1. Dir and Rot are, of course, two completely different attributes and should not be mixed without good reason. If they are both countable, and follow basic addition and subtraction rules, certain matrix operations might be possible   . Does that seem like a possible basis for a valid binary, or, by adding zero, a ternary numerical system to you?

https://www.rosettacode.org/wiki/Balanced_ternary
https://cp-algorithms.com/algebra/balanced-ternary.html
.

Was looking at this for SQL: https://www.red-gate.com/simple-talk/databases/sql-server/learn/sql-and-the-snare-of-three-valued-logic/

Hi LTAM,

Just wanted to get your eyes on this query. It is kind of "check" on what is allowable. Looking for unique or low counts for src-dest with the LTAMKeys and CanBind = 1 (true). There are 2,500 +  unique values. Was looking at A1 through A3 LTAMKeys. Trying to firm up "allowed" and "not-allowed":
----------
With SmallBondCounts as (
SELECT TOP 100 PERCENT
LTAMKeySrc
,LTAMKeyDest
,CanBindSrc
,CanBindDest
,SlotDirectionElectronBond
,count(1) AS RecCount
,Count(DISTINCT ElementSrc) AS ElementSrcCnt
,Count(DISTINCT ElementDest) AS ElementDestCnt
,Min(AtomicNumberSrc) AS AtomicNumberSrcMin
,Min(AtomicNumberDest) AS AtomicNumberDestMin
,Max(AtomicNumberSrc) AS AtomicNumberSrcMax
,Max(AtomicNumberDest) AS AtomicNumberDestMax
FROM [Physics].[dbo].[vwAtomicMilesMathisOrbitalsDetailAllBonds]
WHERE CanBindDest = 1
AND CanBindSrc = 1
GROUP BY LTAMKeySrc
,LTAMKeyDest
,CanBindSrc
,CanBindDest
,SlotDirectionElectronBond
HAVING count(1) < 3
ORDER BY 1
,2
,3 DESC
,4 DESC
)


SELECT Distinct Formula, ElementSrc, ElementDest, A.LTAMKeySrc, A.LTAMKeyDest , SB.RecCount
FROM
[Physics].[dbo].[vwAtomicMilesMathisOrbitalsDetailAllBonds] A
JOIN SmallBondCounts SB
ON A.LTAMKeySrc = SB.LTAMKeySrc
and A.LTAMKeyDest = SB.LTAMKeyDest
where A.CanBindSrc = 1 and A.CanBindDest =1
order by 1 ,2,3
--------------------
This shows a 1 Record count. This Formula has Barium and Radium bonding with unique LTAM Keys:

SELECT *
FROM
[Physics].[dbo].[vwAtomicMilesMathisOrbitalsDetailAllBonds]
where
LTAMKeySrc = 'A3Y6A' and LTAMKeyDest = 'B10Z5R'

ZID        Formula
29315100 BaO8RaS2

-------------------

Just wanted to get this checked out for validity.