Latest Features as of 15-Sep-2019
Two new versions of the Cascades suite - "Cascades5Lite" and "Cascades5" have been added to the Nanosoft package:
Cascades5Lite
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
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.
Usage of the Cascades Suite of Programs
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.
Latest Features as of 31-Jul-2019
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)".
Calculation of Binding Energy per Nucleon (BEN)
The principle source used here was the Wikipedia article on Nuclear Binding energy.
Constants:
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
For a Given Nuclide:
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
Formulas:
Version 1: BEN = (Z * (Mp + Me) + N * Mn - AMU * K)/A;
Version 2: BEN = Mn - AMU * K / A;
Notes
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.
The Naming of Files of Results
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.
The AllTables Program
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.
Results Files Storage
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.
Latest Features as of 10-Jan-2019
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.
Latest Features as of 25-Oct-2018
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.
However, 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.
Latest Features as of July 2018
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 |
Latest Features as of June 2018
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.
Original Background Notes
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.
Earlier Programs
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.
Later Programs
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.
Other Programs
FusFis - Denis LaMotte's Positive Simple Nuclear Reaction Search Site.
Downloads
Original SQL Tables
Fission.sql (50KB) Fusion.sql (81KB) TwoToTwo.sql (28,163KB) ElementNames.sql (4KB) StableIsotopes.sql (16KB)
FusFis.xlsx (Original Parkhomov Spreadsheet, 67,219 KB)
Latest SQL Tables - which include the boson-fermion fields
FissionBF.sql (76KB) FusionBF.sql (125KB) TwoToTwoBF.sql (48,746KB)
SelectedIsotopesBF.sql (20KB)
Footnote
I intend to continue updating this post as required, so that it may serve as an interim reference page for this constantly evolving package.
P W Power