There are immense problems associated with putting a rock name on a fine grained or glassy sample. Thus one sees in the Oceanic basalts the vast majority, from 10 to 2% MgO and from extreme NMORB to extreme EMORB are merely named "basalt" which is not exactly helpful. At least a third of the samples in GEOROC are misnamed and while NAVDAT claim to have on file over 30,000 analysed rocks none are given a name as yet.

The best part of a century ago, Cross, Iddings, Pearson and Washington devised a method of calculation simplified minerals from a chemical analysis. If a rock possessed normative excess silica, and has a normative feldspar in the range An30 to 40 it became an "andesite". If the normative feldspar was labradorite, it was a "basalt": If silica exceeded 69% and the feldspar was albite, it was, by definition, a rhyolite..

In the early 1960’s we had a Fortran-based computer program which would read in boxes of cards (at about 1200 per box) of chemical data, print out the analysis and Norm in columns of ten until it hit a card saying "end". It then printed out some ternary diagrams of qz – hy – ol - ne etc and was very useful. It also gave a rock name which was usually correct.

Since the advent of the 16, 32 and 64 bit PC simple languages like Fortran have almost vanished and so have programs that compute Norms. There are some based on EXCEL but can only do one hand-entered set of data at a time.

Early data bases had a problem deling with variable number of tr acelements which could be anywhere from 2-3 up to 70 in number and published in any order. The problem was, how to plot them on a common diagram. Some people, eg Felix Mutschler's with "Petros" never solved this problem, and ignored trace lements all together. We simply packed them together in any order, read the headers and kick-sorted them into a common standard order. We could them computer plot as may files as we liked until we ran out of memory. With even 50 possible trace elements, memory ran out at about 2000 samples.

We really need a program that can compute 10 or 20,000 at a time, preferably within a few seconds regardless of the order the elements are in, in a file.. Without a reasonably accurate rock name a database is relatively useless. We recently decided to define the compositional envelope of "Alkali Basalts" to find samples included under this name had from 35 to 70% SiO2! Most AOBs in fact have about 45%.
We are at present trying two avenues, one using "Python" which is simple enough language but with poor array handling, and JAVA which is more complex but can do anything and has sophisticated graphics. Perl, C, C++ and Action Script were also looked at and rejected. A program is needed which can be modified and improved by the average academic who is often not as computer literate as he perhaps ought to be.

Identying elements accoring their order in columns is now out of date. In "Python" Kirby Urner, a "Python" expert, suggest setting up a hash table or dictionary in which a sample number is assocated with a header, eg "CaO" and with the vulaue, eg "10.25%". It not longer matters whether two files or two databases have the elements in the same order or whether there are columns of metadata in between. This has immense application, one can take several files from different databases by clicking on them, they are read in and output into a common .csv file in some standard order and can be plotted or have statistics done on them. Making up a file from 3 - 4 sources with a total of 30,000 analysed rocks does not take more than about 20 sec.

Preliminary results show that the JAVA version can compute NORMS for the entire PETDB glasses file of 15,000 lines of which only about 10,000 are complete and write the results to an EXCEL-compatible .csv file in about 3 sec.

A number of decisions have to be made. Any rock sample, even a glass has some of the iron oxidized. For the present we shall assume 80% of the iron is FeO and 20% is oxidized to Fe203. This may be not be constant, EMORBS have a higher water content than do NMORBs.
Input data shall for the present be summed to 100% water free. Several versions of the NORM calculation have different approaches for calculating the distribution of silica to different phases in order to use up the ferro-magnesian content. Some appear to be only approximations, some are illogical and some we simply do not understand so we have derived our own. In extreme alkaline or altered rocks, the calcuated Norm appears to depart from reality so GEONORM stops when all albite has been converted to nepheline and all orthoclase in converted to leucite and prints "Failed".

The Oceanic basalts have up to 12% normative orthoclase and 2% apatite. High silica commendites have up to 32% normative silica which is higher than might be expected.

We have been able to confirm that the "Trachytes" of the Revillagigedo Is (esp Socorro) are not even alkaline, the "Trachytes " having about 10% normative Qz and being commendites. As we suspected from the Zr-Nb-Y data they are median EMORBS, slightly enriched above the average, but much more fractionated than is seen in the small submerged off-ridge cones along oceanic ridges. The Galapagos Islands are also confirmed as being slightly below median EMORB on composition and as we have said for some time, can be matched with Icelandic centres.

We will later present here a page of analysed glasses, NORMS and rock names. EXCEL can only take 256 samples laterally compared with 64 K vertically. Those wishing to publish in the traditional format will have to restrict the numbers presented.

The interface is now complete but other implications have to be considered.