 |
| Mikulov - a lovely town in southern Moravia |
 |
| Sampling local production in Mikulov |
GCDkit is a permanent work in progress, and lots of things evolve! In May 2016, we (Vojtech and Jeff) met for a week in Moravia, locked ourselves in a room and coded from morning to evening. A pity considering the touristic resources, and the view from our room (rest assured that we did sample some of the better options however), but a huge success in terms of writing code!
So, here is a quick list of what we've been up to: you may regard it as a list of features that will be included in GCDkit, sooner or latter (to be honest, latter is more likely than sooner).
Interfaces and connections
- We spent some effort towards making GCDkit truly platform independent. As we all know, GCDkit so far is a purely Windows-specific application; this is largely (only) due to the choice of using Windows-specific menu and interface functions (the menus that appear at the top of the R console). With help and incentive from some correspondents (Jesse Reimink, then at U. Alberta and now at DTM), we worked hard to make GCDkit usable under other systems. To some point, this can now be done. Jesse had GCDkit running under MacOS, and we had it functional in Linux (well, in an emulator). Of course, you should not expect it to be perfectly stable, and probably not 100% functional either. And obviously the menu system is missing; you have to run it purely from command line. Still, it works and it may be included in the distributed version in the not-so-far future.
 |
| GCDkit Development in Linux (Ubuntu) |
- As soon as GCDkit will become (mostly) platform independent and (mostly) usable without the Windows R GUI, nothing should theoretically stop us (or you) from developing other user interfaces. We explored the possibility, for instance, to run a Python application that would call R/GCDkit. Don't hold your breath, though.
- An additional benefit of a Python/R connection is that QGIS -- the main open source alternative for GIS -- supports Python plugins. There is therefore a long-term possibility for calling a fully interactive GCDkit session from QGIS, and therefore do GCDkit processing on geographic data.
- A simpler aternative is to use QGIS processing toolbox. As a proof of concept we managed, for instance, to load a shapefile (a geographic layer containing points with analyses) into GCDkit, calculate a CIPW norm, and return another geographic layer containing the normative values that you may then use in normal GIS way (for instance colour by proportion of a normative mineral, etc).
 |
| Running a GCDkit "geo-algorithm" from QGIS. |
Modelling
One of our main goals was to work on the long overdue modelling code. After several false starts, we had something to show during the last workshop in Krakow. This time, we totally overhauled the code, and now wrote something we believe is a rather flexible and powerful framework. From a user perspective, you'll be able to do something like that (don't try it on your system, it is not distributed, and it is very likely to change anyway!):
######## Direct melting of an avg Archaean basalt
# Define the mineral proportions
min.props.mod1<-c(0.6,0.4) # sum must be = 1
names(min.props.mod1)<-c("Cpx","Grt")
# Calculate the model
mod1<-pmDirectBatch(c0.lab="avg Arch basalt",min.prop=min.props.mod1,ff=0.7,min.name="mins",mjr.set=mjrs,kd.name="kds",trc.set=trcs)
# Add more info (calculating every 0.1 here)
petroCalc(mod1,0.1) # Calculate every 0.1
# Extract the data for plotting
mod1data<-mod1@cL.calc
# Prepare a plot (just the real data)
binary("SiO2","Sr")
# Add the model curve
figOverplot(var.name="mod1data",autoscale=FALSE,type="o",col="brown")
Under the hood, we have defined a "PetroModel" class that stores all the information on a model, and several functions to calculate it. With such an object-oriented approach, the nice thing is that we can very easily expand the possibilities. Since we defined the "overplot" function for the main class for instance, we need no additional work to plot a model curve on a graph -- and this will remain true for direct or reverse models, or even for more complex ones including accessories saturation, variable D values, etc., should we decide to include these at some point.
There is no user interface so far, and no real plans to develop one. At the moment one has to resort to the command line and type the functions in, but it is not so difficult. Eventually, we will think of something perhaps using Python (cf. above), or
Shiny.
Again, this is not released. It is our next main goal, but will take a bit more time to polish and package (and probably publish !).
Phase equilibria
During the Prague Goldschmidt conference last year, we presented an
abstract demonstrating how we could read a
PERPLE_X output and further process it to calculate trace elements compositions in the melt. Actually, this is a long standing idea (I [Jeff] started working on it using a monster of an Excel spreadsheet back in 2005, and we started writing this code during a chilly spring in Southern France in 2013). We did spend some work on that, too, tweaking and fixing the code once more (this nasty monazite saturation routine...), and thinking about a publication -- you're not likely to see this code soon and certainly not before we publish.
And more...
Well, we also spent some time discussing grant applications for funding our efforts, and celebrating the success of "ouR"
book... We also considered plans to link our work with the very nice job done by Matt Mayne on something called
RCrust. And, indeed, we enjoyed a lovely walk in the woods around Valtice.
