Fusion Reactions | Fission Reactions | Two To Two Reactions | All Tables
CascadesAll | Cascades4 | Cascades5Lite | Cascades5 | All Results
Show Element Data | Tables in Detail | Downloads | Notes
The original 'Nuclides' table, comprising 293 nuclides, that Dr Parkhomov based his spreadsheets on, has now been suplemented by an extended table, 'NuclidesPlus', comprising 324 nuclides.
To browse either of these (and all other relevent tables in the Nanosoft package), the 'AllTables' program may given a simple SQL command. In the case of the extended Nuclides table and with the listing in standard order, the command is "select * from NuclidesPlus order by Z, A". The extended nuclides table is the result of allowing all nuclides with a half life of greater than about 30,000 years to be included. Specifically, he criterion is that the log10 of the half life in years - 'LHL' - should be greater than 4.5. It should be noted that the original 'Nuclides' table already included the likes of Tritium, Co60 and Sr137 and these have been retained in both tables.
Both these tables are now also the basis of new sets of reaction tables. Thus, to the original (neutrino including) set of 'FissionAll', 'FusionAll' and 'TwoToTwoAll' reaction tables have been added two further sets. In the first, 'FissionAllNew', 'FusionAllNew' and 'TwoToTwoAllNew', based on the original 'Nuclides' table, the '*New' set allows for the MeV values to be either positive (exothermic) or negative (endothermic). The even more recent set is 'FissionAllPlus', 'FusionAllPlus' and 'TwoToTwoAllPlus' and these are based on the extended - 'NuclidesPlus' - table but, like the original set, this is confined to exothermic values (MeV > 0).
In parallel with the above work, the 'Nuclides'/'NuclidesPlus' and 'Elements' tables have had new fields added to them. As a way of reflecting this additional data, the 'Elements' table has been renamed 'ElementsPlus'. To also reflect these new supersets, the program 'Show Element Data' now lists entries from the 'NuclidePlus' and the 'ElementsPlus' tables. In a futher enhancent to all Nanosoft's main programs - 'Fission', 'Fusion', 'TwoToTwo', 'CascadesAll', 'Cascades4', 'Cascades5Lite' and 'Cascades4' - all now detail lists of both the nuclides (from 'NuclidesPlus') and the elements (from 'ElementsPlus') appearing in the primary results tables. It should be noted that these superset tables are fundamentally indexed by their 'Z' and 'A' values - not their primary SQL indices ('id'). Thus a row in either sub or superset will be identical (asisde from 'id') - always assuming that the subset table ('Nuclides') actually has a corresponding entry to one in the 'NuclidesPlus' table.
In the Nuclides table, the Binding Energies per Nucleon have been further refined according to the latest available data from NIST as follows:
Mn = 939.56542052, Neutron mass in MeV.
Mp = 938.27208816, Proton mass in MeV.
Me = 0.510998950, Electron mass in MeV.
K = 931.49433355837, 1 a.m.u. in MeV (= 1/12 of a Carbon nucleus).
MeVbeta = Mn - (Mp + Me), neutrino mass-energy contribution, as detailed earlier.
The updated AMU values were all taken from this table: https://physics.nist.gov/cgi-bin/Compositions/stand_alone.pl
Using the above values, the Binding Energies (BE) and the Binding Energies Per Nucleon (BE) were recalculated for each Nucleon and re-entered in the updated Nucleon table.
A new column - BE - was created in this updated Nuclides table for that purpose.
The Formula used for the BE's reflected Version 1, as below, and was: BE = Z * (Mp + Me) + (A - Z) * Mn - AMU * K . Each BEN was set at BE/A .
As before, the only exception was for Hydrogen (Z = 1, A = 1) where the BE and the BEN remained at 0.0, to reflect the fact the H1 is not bound to any other nucleon.
In the Nuclides table, the Binding Energy per Nucleon values have been re-calculated from their values as set in 31-July-2019, as detailed below:
The principle source used here was the Wikipedia article on Nuclear Binding energy.
Mp = 938.2720813 // Proton mass in MeV
Me = 0.5109989461 // Electron mass in MeV
Mn = 939.5654133 // Neutron mass in MeV
K = 931.494028 // Standard Atomic Mass of 1.00 in MeV
Z = Atomic Number of Element - the number of protons in its nucleus
N = The number of neutrons in its nucleus
A = The Atomic Mass Number = Z + N
AMU = Its Measured, Bound Atomic Mass in MeV
Version 1: BEN = (Z * (Mp + Me) + N * Mn - AMU * K)/A;
Version 2: BEN = Mn - AMU * K / A;
To generate the current version of the Nuclides table, Version 2 of the BEN formula was used. It was considered that this version slightly amplifies the differences between the BENs for each nuclide and this should, in turn, enhance any algorithm which seeks to highlight LENR.
"In the re-calculation, Version 1 was used because, aside from being more detailed, it was realised that the resultant values for BEN were much closer to the ones likely used by Dr Parkhomov to calcuate the exothermic energies for each reaction in all the respective Fission, Fusion and TwoToTwo spreadsheets/tables.
For example, in the neutrino = 'none' cases for TwoToTwo (2-2), these exothermic energies are the difference between the total input and the total output binding energies, thus:
MeV = (A1 *BEN1 + A2 *BEN2) - (A3 * BEN3 + A4 * BEN4)
In the cases of neutrino = 'left' or 'right', the neutrino energy is generally small compared with the extra energy required to either free or absorb a bound electron, denoted here as MeVbeta.
Using the mass definitions above, MeVbeta = Mn - (Mp + Me), which is approximately 0.78233 MeV. MeVbeta is subtracted from the initial MeV calculation above for the neutrino = 'left' reactions but added for the neutrino = 'right' reactions
It should also be noted that these recalculated BEN entries in the now updated Nuclides table will also appear in legacy results files, including the tables of "All Nuclides Appearing in Results Table" that are listed with all runs of the Fission, Fusion and TwoToTwo programs. You may chose to re-run any of these where the BENs are a significant factor in your conclusions.
In each of the current Cascades programs - Cascades4, Cascades5Lite and Cascades5 - when any element is not to be fed back because it is a radionuclide, its symbol will appear in the Reactions Table with the string *r appended.
Similar appendages that signal other criterion failures are:
*mp = Melting Point
*bp = Boiling Point
*f = Fermion
f*d = Fermion but also a Dimer.
Each of the programs Fusion, Fission and TwoToTwo, in addtion to presenting the Results Table itself, now also presents a list of all the Nuclides which appear in those results. Note that these lists include LHL (Log10 Half Life) values from which the user may see how radioactive they are relative to each other. Stable nuclides are assigned LHL's of 50 (implying half lives of 10**50 years)
With the sole exceptions of neutrons (n*), all nuclides in the Nanosoft programs or tables now appear without asterisks. This is partly to avoid the artibrary assignment of asterisks to those nuclides whose LHL's are less than 18.0 and partly to remove any confusion which can result from uncertainty when composing queries involving mixtures of nuclide symbols - including or not inclduing asterisks.
It has been decided to remove Cascades3. This program followed the original way of starting the cascading process - by specifying a core query to be run by both the Fusion and the TwoToTwo tables - but it has been realised that this can result in incomplete initial population of the results tables. By contrast, the current Cascades versions - 4, 5Lite and 5 - are both sounder and simpler to initiate. All three are started in only slighly different ways, by the user listing the core fuel, and all then share common processing software.
As a result of the above incomplete initiation process in Cascades3, refinements were also made to versions 4, 5Lite and 5 and users are therefore advised to re-run all cascade simulations which used these three programs.
A noteworthy point here is that, for beginners, the perhaps counterintuitive choice of Cascades5 is recommended. This is because, for a particular choice of parameter and switch settings, it previews exactly what will happen with each and every nuclide in the tables and permits the user to repeatedly refine those choices before executing the cascading simulation.
Cascades3 has replaced Cascades and Cascades4 has replaced CascadesAll.
Cascades3, as with Cascades, requests the user to enter a core query that both FusionAll and TwoToTwoAll can use to initiate the Cascading process. After this, Cascades3 resembles Cascades4 and Cascades5Lite in features.
Cascades4, as with CascadesAll, requests the user to enter a list of core fuel elements. All isotopes of these elements that are in the Nuclides table are implicitly included and Cascades4 then proceeds as with Cascade5Lite. Note that Cascades5Lite allows for individual nuclides to be entered in the core fuel list, thus allowing for particular nuclides to be effectively excluded from what would otherwise amount to Cascades4.
All programs and links in the Nanosoft Package have now been modified so as to better fit smaller width screens as found in tablets or phones. To do this, the left and right sidebars in most programs have been removed. However, the program "Tables in Detail" still displays all the information that those left and right sidebars proevioulsy contained.
Two new versions of the Cascades suite - "Cascades5Lite" and "Cascades5" have been added to the Nanosoft package:
Cascades4 has been replaced by Cascades5Lite. Like Cascades4, Cascades5Lite requires the user to enter the core fuel in a space-separated list of nuclides in "EA" format - the element symbol followed by its Atomic Weight, A, such as B10: the A = 10 isotope of Boron (implicitly, Z = 5). A typical core fuel list might then be: H1 Li7 Al27 N14 Ni58 Ni60 Ni62 B10 B11. The core list initiates the Reactions Table, which is then added-to, as described below.
Cascades5Lite then precomputes the Feedback Criteria for each and every nuclide in the (Parkhomov) Nuclides table, based on the user's switch and threshold settings, before proceeding with the central algorithm, common to all Cascades versions.
To recap, this central algorithm consists of looking for any and all possible pairs of nuclides, in both Fusion and 2-2 modes, which are to be found in the Parkhomov reaction tables and which exceed the corresponding user-set energy thresholds. Those nuclides which appear in the RHS of those "found" reactions are then "fed back" - added to the Reactions Table - provided that they pass all the above pre-computed criteria (and provided that they have not already been added). Those reactions looked for but not found in the Parkhomov tables are none-the-less noted and not looked for again. The user may opt for a listing of these as well as the found reactions. Naturally, all Results files will include the final version of the above table of core-fuel and fed-back (transmutation) nuclides.
Cascades5, like Cascades5lite, also pre-computes the switch and threshold settings and uses the same central algorithm, but it first presents a fully detailed "Nuclide Feedback" table for the user to see the explicit results of his/her settings and edit/refine them as many times as required, before finally allowing the central algorithm to proceed. A further, unique, feature of Cascades5 is that the user may overrule the net feedback criterion for any given nuclide using its corresponding master switch option on the Feedback Table.
In the light of the above two programs, it is expected that users may make little more use of the older Cascades and CascadesAll programs and these may soon be taken off the main menu. A typical user might decide to try Cascades5Lite first with a given set of core fuels, together with switch and threshold settings, to explore the extent of the transmutation and found reaction outcomes. He/she might then turn to Cascades5 to obtain the fully flexible and detailed picture.
Others might prefer to use Cascades5 exclusively, as both a useful explanatory tool and a way of exercising full control over the algorithm.
It should be noted that, with any of the Cascades programs, the user must ultimately be able to justify his/her choice of all switches and settings, in terms of the real physical experiment that he/she is trying to predict the output energies and transmutations of.
A new table - "Nuclides" - has now replaced "Selected Isotopes". Its structure may be seen on the left or right columns of a number of programs, namely "AllTables", "Tables In Detail" and "Show Element Data". Nuclides contains all the useful fields that Selected Isotopes does. Its extra fields are mostly self explanatory but note the following:
BEN = Binding Energy per Nucleon. These values were computed from the A, Z and the AMU in MeV.
LHL = Log10(HL) = Log10(Half Life in Years). This brings standardization to all Half Life data.
The second new table - RadioNuclides - (see below) also includes the LHL feature.
The new program "Show Element Data" displays all known data for a given element from the "ElementProperties", "Nuclides" and "RadioNuclides" tables.
The RadioNuclides table was added partly to ensure coverage of any and all possible isotopes. It was created from the publically available spreadsheet here, on the RADAR Decay Data page. The LHL field was not included in this original spreadsheet but was generated from the fields "HL" and "Units". The "Units" field can take on the values Y, D, H, M, S, MS, US and NS (the last three being milliseconds, microseconds and nanoseconds, respectively). For example, the LHL for values where Units = S (seconds) would be effectively computed as LHL = log10(HL) - log10(S*60*60*24*365.25). The actual code was more efficient than this and drew upon the simple additive and subtractive nature of logarithms. Thus, precomputed constants to "correct" the necessary, initial Log10(HL) were used. Here, log10(365.25) is the precomputed number which may be subtracted from the Log10(HL) number, if Units = D.
It is thus considered that the use of LHL's in both the Nuclides and RadioNuclides tables affords an easy basis for comparison of all half lives for all Nuclides. For the Stable Primordial Nuclides (SPN), which appear only in the Nuclides table, an arbitrary value of LHL = 50 (implying 10**50 years) has been set but, depending on expert advice, that value could, in future, be changed, probably upwards.
In general, LHL's may be used in very simple ways with the SQL's. Thus, to select half lives (in years) that are within a factor of 10 up or down from a given value whose corresponding LHL is K, the partial SQL would include the string: "where (LHL <= K + 1 and LHL >= K - 1)".
The principle source used here was the Wikipedia article on Nuclear Binding energy.
Mp = 938.2720813 // Proton mass in MeV
Me = 0.5109989461 // Electron mass in MeV
Mn = 939.5654133 // Neutron mass in MeV
K = 931.494028 // Standard Atomic Mass of 1.00 in MeV
Z = Atomic Number of Element - the number of protons in its nucleus
N = The number of neutrons in its nucleus
A = The Atomic Mass Number = Z + N
AMU = Its Measured, Bound Atomic Mass in MeV
Version 1: BEN = (Z * (Mp + Me) + N * Mn - AMU * K)/A;
Version 2: BEN = Mn - AMU * K / A;
To generate the current version of the Nuclides table, Version 2 of the BEN formula was used. It was considered that this version slightly amplifies the differences between the BENs for each nuclide and this should, in turn, enhance any algorithm which seeks to highlight LENR.
As before, most of the programs in this package will generate publically accessible Results files. The name assigned to each of these reflects, as much as possible, the SQL command used to generate it and the file-naming algorithm has been further refined to improve the way this works. This includes the ability to deduce the SQL command itself from the file name, as the above Results program shows.
The longest file name allowed in Linux is 255 characters and the file-naming algorithm will intelligently truncate all names which exceed this. In practice, all the programs except "AllTables" generate resulting file names whose lengths are usually well below this limit. For the special demands of the AllTables program, see below.
This program is basically unchanged from the previous version but the size of the SQL box has been increased to hold up 2250 characters. This is to accommodate much longer and more complicated SQL commands than have so far been used with this all-purpose program. AllTables can draw on all the Parkhomov- derived tables as well as the publicly derived ones like "ElementProperties", "Nuclides", "RadioNuclides" and "AtomicRadii".
Obviously, an SQL command that seeks to combine various fields from a number of these, in order to test how those fields may or may not be relevant to a particular LENR effect, will likely be a very long one. Even so, many file names, even for AllTables results, fall inside the 255 character limit. Those exceeding it will be truncated but it is likely that each will be sufficiently unique in its first 255 characters to be distinguished from any other. In the unlikely event of two or more file names matching even after 255 characters, they can be distinguished by their date and time stamps which appear alongside their names in the Results listings.
In the spirit of Open Science, all Results files are, at least initially, stored on the site, as indicated above, and anyone may browse them. However, the site's capacity is not unlimited and the Webmaster reserves the right to prune them at any time. That will apply especially to older files and to those that have produced no rows because of errors with the SQL format. As the programs indicate, it is up to you, the user, to make you own copies of your results.
Further to the spirit of Open Science, as of July 31st, no record is displayed or kept as to the location or identity of any user of the package. Thus, all your results and, implicitly, the line of thought you are testing, the will be visible to the world but, only of you choose to publish those thoughts independently (such as in ECW) would your identity then be visible (and even then only if you do not have an anonymous pseudonym on the likes of ECW.
All that said, please use the package responsibly. A good rule is to make routine use of the "Limit" sub-command to limit the number of rows and get a preliminary idea of how a particular SQL command will perform. If those restricted results look like what you were expecting, you could then extend the limits or, just as likely, insert extra sub commands to eliminate irrelevant rows and so arrive at your ideal SQL command by this constructive trial and error process.
This entire software package, centred on Dr Parkhomov's data, has now been moved to a new website at www.nanosoft.co.nz. This URL is very appropriately named since it reflects both the dedicated software and the typically nanometer scale of LENR.
Clicking on the above URL will send you directly to AllTables.php, the central program of the package. The array of links carried by it and each other program now also has two extra ones:
All Results: In which the results of recent runs are temporarily stored but the site is not designed for mass storage and all users should make their own copies as soon as possible.
Downloads: In which all spreadsheets and SQL files used by the package may be downloaded.
On the further suggestion of Bob Greenyer, I have recently added two closely related parameters to the Atomic Mass, A, and the Atomic Number, Z, which define each distinct isotope in all of the relevant tables (Fission, Fusion, TwoToTwo and SelectedIsotopes).
The first is "nBorF" which denotes whether the nucleus is considered a Boson or a Fermion. The criterion for this is whether A is even - a Boson (b), or odd - a Fermion (f). So, for any and all isotopes in the tables, nBorF will be either 'b' or 'f'.
The second is "aBorF"which denotes whether the atom is considered a Boson or a Fermion. The criterion for this is whether the number of neutrons (A - Z) is even - a Boson (b), or odd - a Fermion (f). So, any and all isotopes in the tables, aBorF will also be either 'b' or 'f'.
Just as for the A and Z parameters, the above extra parameters can be used either passively by observing the distributions of 'b' and 'f' in inputs and/or outputs, and/or actively by including some or all of them in the SQL commands themselves.
When integrated into the Cascades.php program, the above two parameters can be used in an even more interactive way. As Bob Greenyer recently pointed out to me:
A key hypothesis is that the Active Agent (AA) can accept any Boson and note that a Dimer of an atom is a Boson even if the atom itself is a fermion.
If a fermion is synthesised in the AA and survives long enough before re-transmutation, it may be "spat out". This would lead to isotopic distortions. Ultimately with enough elemental feedstock, natural ratios of isotopes would prevail since that is the "solution" that nature would iterate to (and has done) over time and space.
So, fermionic atoms/nuclei should not get added into the mixer unless they are dimers. And if fermions are synthesised and survive before expulsion, they may get expelled. So in the case of only a few elements within the range of the AA influence, there may be a relative increase in the amount of fermion type nuclei.
- So, in the latest version of Cascades, there are three new switches that the user can set to either "Exclude" or "Include" to decide whether an atom should be "fed back" to the Nuclei Table (if it is not already there) and so be tried with all the other nuclei in all possible combinations (that have not already been tried) of both the Fusion and TwoToTwo reactions:
1) A Nuclear Fermion Exclude/Include switch (defaulting to "Exclude").
2) An Atomic Fermion Exclude/Include switch (defaulting to "Exclude").
3) A Dimer Include/Exclude switch (defaulting to "Include"). Here the atoms of H, D, N, O, F, Cl, Br, I, Li, Na, K, R and Cr - each being able to form Dimers - may be (optionally) included in the above "feedback", even if they are nuclear and/or atomic fermions (thus overruling the first two switches).
To reflect the above workings of the switches, any atom appearing in the Reactions Table as just its one or two letter symbol, e.g. 'Au', will have been fed-back to the Nuclei Table.
If its symbol appears with an asterisk appended, e.g. 'C*', it will have failed the "Reaction Temperature Threshold", i.e. not have melted and therefore not have been fed back.
If its Nuclear or Atomic Fermion ('f') appears with an asterisk appended (i.e. 'f*'), it will have failed the Fermion Switch Test and also not have been fed back.
owever, if a further "d" is also appended (i.e. 'f*d'), its potential exclusion from feedback will have been overruled by the Dimer switch (if that switch was set to "Include" and the element was in the Dimers List) and it will have been fed back.
1)A new table, "ElementProperties", has now been added. It contains selected fields and data from the Periodic Table
The fields and structure of ElementProperties are below:
Z = Atomic Number
E = Element Symbol
EName = Element Name
Period
Group
Melting Point in K
Boiling Point in K
Negativity in Volts
Affinity in KJ/mol
Valence
Maximum Ionization Number
Maximum Ionization in KJ/mol
STP Density in kg/m3
Electrical Conductivity in MS/m
Thermal Conductivity in W/mK
Specific Heat in J/kgK
null = Not Known or N/A
| Field | Type | Null |
| Z | int(3) | no |
| E | varchar(2) | no |
| EName | varchar(31) | no |
| Period | int(2) | no |
| Group | int(2) | no |
| Melting | float | yes |
| Boiling | float | yes |
| Negativity | float | yes |
| Affinity | float | yes |
| Valence | int(3) | yes |
| MaxIonNum | int(3) | yes |
| MaxIonization | double | yes |
| STPDensity | float | yes |
| ElectConduct | float | yes |
| ThermConduct | float | yes |
| SpecHeat | float | yes |
2) Also derivable from the above Periodic Table source is a separate table, "AtomicRadii" in picometers (pm). It contains an empirical measurement, a calculated one and the van der Waals, Covalent Single, Covalent Triple and the Metallic estimates. Where there is no known or applicable figure, a "null" is entered. The details of AtomicRadii are below:
Z = Atomic Number
Emp = Empirical
Cal = Calculated
VDW = van der Waals
Cov = Covalent Single
Tri = Covalent Triple
Met = Metallic
All Radii in Picometers (pm)
null = Not Known or N/A
| Field | Type | Null |
| Z | int(3) | no |
| Emp | int(3) | yes |
| Cal | int(3) | yes |
| VDW | int(3) | yes |
| Cov | int(3) | yes |
| Tri | int(3) | yes |
| Met | int(3) | yes |
<2) The "StableIsotopes" table has been replaced by the "SelectedIsotopes" table. In the new table, for unstable/radioactive elements, where the "StableIostopes" variously replaced percentage abundance figures by half-lives in seconds or years, the new table indicates these field mismatches with a "null" (to maintain SQL integrity, all entries in the "PC" column should be numbers < 100 or nulls). In SQL, a null can mean either that the data is not known or, as here, is not applicable (N/A). Also, note that the "MeV" field is (and was) simply the "AMU" field (formerly called the "a.e.m") multiplied by 931.4941 MeV/AMU. The SelectedIsotopes table details are below:
id = Index
A = Atomic Mass Number
Z = Atomic Number
E = Element Symbol
AMU = Atomic Mass Unit
MeV = AMU x 931.4941 MeV/Unit
PC = Percentage Abundance on Earth
null = Not Known or N/A
| Field | Type | Null |
| id | int(11) | no |
| A | int(3) | no |
| Z | int(3) | no |
| E | varchar(3) | no |
| AMU | decimal(12,7) | no |
| MeV | decimal(12,3) | no |
| PC | float | yes |
Full, core or starting queries in the respective programs are now more user-friendly, in that the user may enter unquoted elements in the E fields (e.g. E = Ni or E1 = D or E2 = Ni, etc). These will automatically be corrected e.g. to E = 'Ni' or E1 = 'D' or E2 = 'Ni', etc before the query proceeds.
Similarly, the user may now enter A and Z numbers with quotes (e.g. A = '64' or Z = '28', etc). Again, these will be automatically corrected (here, to A = 64 or Z = 28) before the query proceeds.
As those who have been following E-Cat World (ECW) will already know, Russian Physicist and LENR researcher, Dr Alexander Parkhomov, produced a program that looked at all of the stable element isotopes and calculated the nucleon exchange reactions and the fusion and fission reactions that lead to stable products with a net energy yield.
In order to generate all that data, Dr Parkhomov had to run the program for 10 days continuously! On the suggestion of Bob Greenyer, a leading researcher with the Martin Fleischmann Memorial Project, Dr Parkhomov generously agreed to release his spreadsheet of results to the world. This was useful in itself but Bob then invited open science programmers to copy the data into an online, accessible and queryable database form.
I was the first one to do so with the largest of the spreadsheet pages, which listed the "2-2" reactions (two nuclei -> two nuclei). That first version of my program was called 'FissionFusion' - an inaccurate name, as I see now. The new version of it is TwoToTwo. My online discussions with Bob about the evolution of the first version is recorded as part of this post on ECW. It and the new version can present an SQL query to the TwoToTwo (2-2) table and the results list on the same page. As well, a link to a file containing those results also appears. That feature is common to all programs in the package.
A few weeks later, another programmer, Denis LaMotte, produced a handy set of online programs that can separately query each of the Parkhomov tables, although not to the same degree of SQL flexibility as in this package. To see this set, click here.
Since then, I have produced a complete set of SQL queryable tables which also cover all the Parkhomov tables. However, the earlier versions, Fusion, Fission and TwoToTwo, are restricted to their own implicit tables (unsurprisingly named 'Fusion', 'Fission' and 'TwoToTwo') and can cater only for SQL commands that begin with "select * from".
The latest version of this class of program, which is intended to replace all the above three, is called AllTables and, as its name suggests, it can accept any non-destructive but otherwise full SQL query that involves any and all of the tables. Thus, it can, in principle, perform highly sophisticated queries on the full range of table combinations, limited, ideally, only by the degree of SQL skill possessed by the user. Naturally, the server itself, while quite well resourced, does occasionally run out of memory or time allocation to compute very long and complicated queries.
This class of direct database querying program has now been joined by the latest version of another class of program, Cascades, which seeks to predict all the nuclei that would be generated by - cascading from - a starting reaction, represented by a single fusion query. That "Starting Query" can be chosen to match the LENR ingredients of a given test run.
Fission - Can query the Fission table only.
Fusion - Can query the Fusion table only.
TwoToTwo - Can query the TwoToTwo (2 nuclei -> 2 nuclei) table only.
AllTables - Can query any and all of the following tables: 'ElementNames', 'StableIsotopes', 'Fusion', 'Fission' and 'TwoToTwo' tables. Their structures are listed in the left and right columns of the program.
Cascades- Seeks to predict all the nuclei that would be cascade from a starting Fusion or TwoToTwo reaction, represented by a single fusion query.
FusFis - Denis LaMotte's Positive Simple Nuclear Reaction Search Site.
Fission.sql (50KB) Fusion.sql (81KB) TwoToTwo.sql (28,163KB) ElementNames.sql (4KB) StableIsotopes.sql (16KB)
FusFis.xlsx (Original Parkhomov Spreadsheet, 67,219 KB)
FissionBF.sql (76KB) FusionBF.sql (125KB) TwoToTwoBF.sql (48,746KB) SelectedIsotopesBF.sql (20KB)
I intend to continue updating this post as required, so that it may serve as an interim reference page for this constantly evolving package.