Tuesday 25 June 2013

Making (kind of) good-looking data tables

Unavoidable task in writing up any scientific paper is to prepare a data table, or rather several of them.  You will probably agree that it quite easy to waste a lot of time trying to format such a table so that it complies with in-house rules of the given Journal or just (often worse) our own needs/wishes. Most commonly, we would like to arrange the analyses according to some key, for instance grouping together the analyses coming from the same intrusion or locality. Moreover, we may want to order the analyses within each of the groups according to an additional criterion, say the increasing silica contents. Lastly, the page width is finite and thus there is likely to be a limit on number of analyses we can fit across a page.
Fortunately the new GCDkit comes with a function which makes this ask easier. In fact, it is currently not attached to the menu system and this is exactly the moment when it is good to be a power user, i.e. not afraid to type in a few lines of code. ;-)

The function in question is called HTMLtableOrdered and outputs the data stored in the numeric matrix specified by parameter 'what'. Optional argument 'which' gives the list of sample names (rows) in the matrix to be saved. The data are first sorted based on 'key2', which typically gives a grouping information (name of a column in 'labs'). Within each of the groups, the data are further sorted based on the numeric variable 'key1'. And the number of analyses across a page is indicated by the parameter 'split.by'. For example, we can produce a table of Large Ion Lithophile Elements (LILE) from our sample datafile, sazava.data:
# Read in the sample data
title="LILE (ppm)",split.by=7)
There are some other parameters which can be included, for instance the table can have samples in rows, as we are used to from the GCDkit system, and the analyses summed up:

title="Major-element data (wt. %)",split.by=14,rotate=FALSE,sum.up=TRUE)
And here is the last example, generating the table from results, here of the CIPW norm calculation.
title="CIPW norm",split.by=5)

I just hope you have found the today's tip useful and that it will save you some time to do something more sensible than formatting tables.......

Friday 21 June 2013

First patch for GCDkit 3.00 released on 5 June 2013

A patch for the GCDkit 3.00 number 130605 is available, addressing following bugs:
  • Redrawing plates in plateCexLab()
  • Verma() was not working correctly for datasets with only total iron determined
  • crashing gcdOptions() (missing were some underlying TclTk functions)
  • multipleMjr() and multipleTrc() did not work at all from the command line

The newest patch installation file can be downloaded here.

Read more about GCDkit patches

Thursday 20 June 2013

About GCDkit patches

As any other software, neither GCDkit is immune from coding bugs. For this reason, GCDkit 3.00 comes with support for patching, which allows the user to improve the program easily, without need for re-installation. There are some facts worth noticing regarding the patches, which will be documented in this spot. However, let us start with the most important:

 What to do with a GCDkit patch?

  1. Download the patch installation file from the GCDkit website (hold ALT when clicking the link to block automatic opening in your browser)
  2. Start GCDkit
  3. Drag-and-drop the installGCDpatchXXXXXX.r file from your download folder onto the R-console (the verbose GCDkit window)
If you see the "Installing the file patch XXXXXX.r" message, well, it is done.

How does the patch work

The idea is simple: Patch for GCDkit is a file containing all updated functions, stored in the Patch folder of the GDkit package. This file is read (sourced) at the end of GCDkit startup, so all the updated functions replace its previous versions.

The patch installation file is also a piece of R code, which writes the patch itself in appropriate folder when executed (or updates another GCDkit files if necessary). This implies further ways of patch installation: Besides the preferred drag-and-drop approach, the install file can be also copied into Patch folder, or its content may be copied into the R-console via clipboard.

What the patch is, and what it is not

The patches are intended to fix existing problems in GCDkit functions, or mistakes in build-in variables etc.

On the other hand, the patches are not here to bring brand new functionality or changes in the system (this will be done via plugins or even new GCDkit version). The reason is simple - the patches should bring more reliability instead of new problems. Also, plugins will not be patched.

Patch versions

Each patch has its number, mirroring the release date (YYMMDD). It is stored in the patchID variable, and it can be also viewed by clicking the GCDkit | About GCDkit menu entries, or typing about(). If the patch available from the website is newer, it is time to install.

On the other hand, each patch is cumulative so only the newest one is necessary. The installation of the GCDkit itself comes with the last patch available, so there is no need to download patches for new GCDkit installations.


If you have problems during patch installation, try another way of installing the patch, as described earlier. There may be also problems with writing rights for the Patch directory, so check the system permissions. And please let us know, even if you have solved the problem successfully (preferably in the discussion here) to help others.

There may also happen, that (despite of all our effort) the new patch will hamper somehow your (previously problem-free) work with GCDkit. To restore to previous state, go to the patch location (something like C:\Program Files\R\R-2.13.2\library\GCDkit\Patch) and delete the last patch (GCDpatchXXXXXX.r  with highest XXXXXX number). The GCDkit will get back to its previous configuration after restart. And again: let us know.

Follow us for new patches

 Unlike the GCDkit 2.3, which remained unchanged for five years in its public version, we plan to release patches for GCDkit 3 more often, generally whenever new bugs are identified and smashed. We recommend to check for new versions. The easiest way is to check this weblog (you can subscribe to its Atom feed), or follow our twitter account. Of course you can also check the website manually time by time.

Tuesday 18 June 2013

How to introduce your own normalization scheme for spiderplots?

Many users would like to add a new normalization scheme to their  spiderplots in GCDkit, or at least to alter some normalization value or change the order of elements. It is easier than you may think.

The composition of various standards available for normalization and subsequent plotting of spiderplots is stored in the file 'spider.data' in the main GCDkit directory. It is a comma delimited and may look  like this:
REE chondrite (Boynton 1984)

ORG (PearceEtAl.1984)

For each normalization scheme, there are always three rows, separated by an empty one from the previous record.

1. The first row contains the title and reference. If the title starts with 'REE', the normalization is supposed to be for REE only and special parameters, such as 'Eu/Eu*', are calculated.

2. The second line gives a comma delimited list of elements in the order they should appear on the plot.

3. The last line is a comma delimited list of normalization values. Please note that the trailing zero before decimal point is optional.

As the file 'spider.data' is read every time spiderplot is drawn, the user can add or delete normalization schemes on his will using any text editor, such as Notepad. Just make sure that you keep a backup of copy of the original file somewhere safe, in case that something gets wrong.

Happy plotting!