We’ve added a new feature to StrataBugs 2.1.1 to make it easier to access some of the wonderful resources that are available on the web. The “web lookup” button has long been around on the taxon matching dialog to enable generalised Google searches on the selected taxon name, as a quick QC method before adding new species names to your dictionary.
The Nannotax/Mikrotax team have made some elements of their underlying database available via an API, which means that StrataBugs is able to query the resource directly and display results ‘in-house’, without you having to go to your browser at all. At its simplest, this gives you a way to ‘verify’ your taxonomy against external dictionaries. If you do need more information, you jump directly to the relevant page.
With the latest update for 2.1.1 installed, you will notice a new button on the taxa list window in the Taxonomic Database module. Take any list of taxa: this could be obtained in a number of ways, for example…
- the contents of a group – open the group, select all the taxa and drag them into the main taxon list window
- all the taxa recorded in a well or project, by using the Taxa menu search option
- using the menu item to search by date, to find all recently added taxa
Now, with the taxa list populated, you press the Web References button:
The next window will ask to confirm the data source(s) used for the lookup. Currently only Nannotax/Mikrotax is supported, but we hope that we will be able to add other APIs to the list when they become available.
Each taxon in your list will be matched to the data source. Be patient for long lists, as it is dependent on your internet connection. When the search is finished the non-matching taxa are selected (in case you want to clear them perhaps), and a new column will appear with the reference (hint: you can make this column wider by grabbing the right side of the column header and dragging to the right). In common with other StrataBugs tables, you can sort the rows by clicking on the column headers.
You can see that two out of my eight original species were not found in Mikrotax. If I right-click on one of the taxon entries I can select the option “Go to URL”: this opens my web browser at the relevant page for the selected taxon.
Nannotax covers most of the nannoflora, but only some of the microfossil categories are covered in Mikrotax e.g. Radiolaria. Depending on the focus of your work, this ‘reference checker’ could be a useful tool for QC’ing your database. There is potential to do more with this data – please do approach us with your ideas on what you think would be most useful. And if you are connected with other database projects that offer a web services interface (or might be interested in creating one), we can look into building similar links.
Some months ago we started to work on an improvement to the new charts system to address what seemed to be a very common question: “Can I just change this panel in this one well?” The results are now available to everyone in version 2.1.1.
Recap on well block templates
A block template is an ordered list of panel templates, with captions. It is a saved design layout, usually belonging to one project, which can be used to display data from any well. It makes sense to be able create a standardised chart for each well in a project, especially where the different wells have similar data content which might be need to analysed or displayed in the same way. Because “charts” are always coupled to their templates, you can change your mind about the layout or design without having to edit a chart for every single well – just make the change to the template, and all your charts will be updated. This is far cleaner and more flexible than having separate charts for each well (as was the process in the old charts model).
So far so good, but it seems that standardisation can only go so far. Different wells have their quirks, and you need to tweak the design ever so slightly in some cases. Perhaps a different wireline log here, or a slightly different group of taxa there. In the original 2.1 charts module the only way you can do this is to duplicate the block template – probably giving it a name specific to the well for which you needed to make the tweak. Suddenly, instead of having one block template which is neatly shared around the project, you’ve got a separate “template” for each well and you’ve lost all the benefits of having templates in the first place.
New overrides feature
We wanted to allow the flexibility to tweak chart design for individual wells, whilst retaining the benefits of the template-driven model. Version 2.1.1 handles the complexities internally, giving you just a simple option to change some panel properties in individual wells, if you wish, and see those changes reflected wherever you use that template to display that well. You can still make changes to the base template and see them reflected everywhere.
Here is a simple example. I create a well block template with one panel, showing the sonic log. I create a new chart and add some blocks for wells in my project, using my new template.
The horizontal log scale looks fine for Well-4 and Well-5, but it’s not great for Well-1. Previously I would have had to make a compromise and decided on a scale which I could use for all wells (or create a separate well block template just for Well-1). With v2.1.1 I can right-click on the panel in Well-1 and select Panel Properties:
After adjusting the DT (sonic) scale, my chart is looking better.
When I have saved this chart, my override for this panel for Well-1 will be saved and applied whenever else I open this template for Well-1. So if I open a tab for it in Samples & Interpretations, my new scale applies. An arrow symbol in tab indicates that this block template has panel overrides in this well.
If I make a change to the block template, e.g. I add a depth scale panel, it updates for all wells.
You can see which wells have overrides (and delete them if necessary) by opening the template in Charts & Templates, and selecting Chart/Template > Overrides.
All you have to do is right-click on any templated chart block, choose Panel Properties, and then save the resulting chart. The block template will behave differently for that well, whenever you use it. You can’t change the order of panels and you can’t add or remove them – these must be done in the underlying block template.
Don’t be tempted to make the same change to a panel for each of your wells that use a template: it’s still better to change the underlying template instead.
To use this feature you will need to be running version 2.1.1. You can download this using the normal updater (select the version at the top, and make sure you get the “Latest” release), but you will need to upgrade your database as well.
The latest release of version 2.1.1 contains a new entry in the list of available sample types: the ‘spot’ or ‘bottoms-up’ cutting, SP.
Spot cuttings are taken by pausing the downward drilling and waiting for the cuttings to arrive from the bottom of the hole. When drilling is restarted, the exact depth is known from the length of the drill string, giving a more precise depth.
The sample depth has the same precision as for a core sample since the cutting is taken from a known depth, but it is still a cutting sample.
When applying core shifts, Spot samples are shifted using the same settings for Core samples, not cuttings samples. So, if Core samples are shifted then Spot samples will be shifted. You can optionally decide whether to also shift Cuttings samples.
You can choose whether to display spot cuttings on charts. Existing samples panel templates will display SP samples in line with their setting for cuttings.
Note that in a multi-user environment, all users should update to the latest version before SP samples are added to the database, or any new samples will be seen as just cuttings.
One of the consequences of moving to an integrated java based charting system in version 2.1 was that we lost the ability to generate Windows Metafiles (.wmf) from the chart program. The wmf format was a good vector based graphics format meaning that, for the graphics packages that could decode the files, the lines appeared sharp regardless of the scale it was plotted at. They were well supported by earlier versions of Windows and Microsoft Office, but more recent editions of Windows do not always render them very well. Unfortunately we have not been able to find a reliable code library that would created wmf files from our java code.
The alternatives are to create PDF files, which are vector based, or use the SVG format. The latter, which is short for Scaleable Vector Graphics, is an open graphics standard which is theoretically readable by a wide variety of software. We have found that although SVG files can be easily read by browsers like Internet Explorer, support was lacking in Microsoft Office. In Office, you needed to insert PDF files or bitmaps. These don’t always look optimal in Excel or Powerpoint.
Now, with the latest builds of Office, Microsoft have made good on their promise to be able to import SVG files. You will need a recent version – those who have an Office 365 subscription or similar will probably have received the update by now – specifically version 1705.
From the StrataBugs chart menus use the Export option and change the file type selector to show .SVG files. Create your file. Then in Office use the Insert Illustrations menu, select your file.
For large correlation charts which create large VGS files – particularly if you’re using logs and lithologies, the Office apps can get a bit sluggish, but otherwise it does reliably support the chart in pin sharp detail. Try it.
This file was 42Mb, and Powerpoint struggles, but it can read the file faithfully …
It has long been possible to use StrataBugs to create ‘closure’ diagrams, showing the relative abundance of different groups of species. I use the term ‘groups’ rather than ‘Groups’ intentionally, since the ‘groups’ may also be ‘categories’. A recent change has made this feature a little more flexible.
The new feature in brief
Let’s say a palynologist wants a quick overview of the relative abundance of marine vs terrestrial species. In practice this is achieved by comparing the abundance of dinocysts (category DC) with the abundance of pollen and spores (cateogry SP). Since all species belong to a category already, it’s simply a case of creating a panel which is grouped by category, and displayed as a relative stacked sawtooth plot. The only problem was that all the other palynology categories which happened to show up in the data would also be included in the plot (the left-hand panel in the image below). In the data below, the DA category represents the number of dinocysts in the first 100 specimens, so that’s what I want to compare to the SP count (N.B. your counting method might be different!).
We have now made it possible to ‘filter’ the panel by more than one category, which allows you to create the right-hand panel below comparing just DC and SP. Species not belonging to the filter categories are excluded from the data.
To make use of this setting, you need to select the ‘Outer’ panel properties tab, and choose ‘Restrict data to’. Here you can choose from a list of categories. To select more than one category, hold down CTRL while you select from the list.
A recap on groups and categories
All genera (and therefore species) must belong to one (and only one) category. This is a convenient way of, well, categorising taxa. Most StrataBugs users will not need to modify the standard list of categories – it would make exchanging data between databases more difficult.
Groups, on the other hand, are entirely under your control, and one species can belong to any number of groups. Groups can be attached to projects.
Both are useful for creating charts. You can find our more in the help.
More about closure diagrams
The inner panels above are created with the following options:
- ‘Group data by’ is set to ‘categories’ – this means that counts of species from the same category will be aggregated. You could also use groups here, in which case either the outer or inner panel must be filtered to a group set (which defines the selection of groups).
- ‘Plot type’ is set to ‘stacked curves’ – rather than showing the different categories in individual columns.
- ‘Calculation style’ is set to ‘relative (inner)’ which means that instead of showing the absolute count for each category, we’re showing the count as a percentage of the total for the inner panel. In this case you could also select ‘relative (outer)’ (i.e. the count is relative to the outer panel), because the inner and outer panels are showing the same data (more in this previous post).
You can find out more about the biostratigraphy panel options here.
In recognition of World Backup Day (no?, me neither), a quick run through the hows and whys of backing up your StrataBugs database.
Backing up your system seems a obvious no-brainer, but take a few minutes to consider what you’re backing up, why you’re doing it, and how you might recover the database, should it be necessary.
There are two main reasons to take a backup: the most obvious being a hard drive or system failure, a fire, or theft, that results in an unrecoverable data loss. The other reason, sometimes overlooked, is the need to go back to an earlier database state in the event of accidental data loss by deleting, mistaken editing, or even a programming error (I know, I know, highly unlikley, but let’s move on..).
For the first, you need a copy – any copy – on some kind of media that isn’t the computer that StrataBugs is installed on. Most sensibly this means an external drive or memory stick that isn’t stored (and fire damaged/stolen with) the computer itself, OR, files copied ino the cloud using Dropbox or similar services. The only real pitfall of this approach is that you need to ideally make multiple copies on different media and make sure you know which ones are most up to date. In the event of a system failure you want to be able to go straight back to the most recent copy without having to try to work out which of your myriad sources of backup contained the latest database.
For users of stand-alone databases, you only really need concern yourself with the database file(s) in the /Data folder ending in .db or .mdb, since this is the only file that we can’t restore for you. All the rest of the StrataBugs files can be downloaded afresh, or supplied by us.
For users of server-based databases like SQL Server and Oracle, this backup issue is out of your hands, and one would assume that server custodians would have a backup schedule fully in place. It’s worth asking however, how often the backups are performed.
Going back to an earlier state of data is more problematic if your backup schedule always involves overwriting the previous backup copy. You might be able to recover a database, but what if you discovered a previous problem that has only just come to light, or a loss of data that pre-dates your last backup? For this reason, you should keep snapshot copies stretching back say, every day for a week, then every month for a year, then each year.
Another way to create an effective backup, particularly for server based databases, it to export the data through Organiser, or through the process that creates project databases in the Wells & Outcrops module. In this way you can selectively restore data through the usual import mechanism.
To make this process as painless as possible, a recent addition to the Connection properties dialog for H2 databases allows you to Prompt for backup:
If you have this feature switched on, you will get the following dialog pop up whenever you exit from the system:
You can use this to quickly create a dated compressed backup file onto your chosen media. If you need to recover your database from the file, you need to unzip the database snapshot into the StrataBugs data folder, and provided your connection and database name are the same as the backup, you can be back up and running immediately.
Don’t let your backup be the one thing that you always meant to get around to doing … but never quite made it. If you haven’t done it recently – do it today!
Amongst the many voices of approval from those that have got to grips with the templated charts in v2.1 there are always a few folks who are permanently wedded to the idea of “one well, one chart”, and don’t want to work in a templated view of the world. They also prefer a WYSIWIG panel property editor, so they can make individual panel changes as required for the well they’re working on. For them, getting to know the options available on the standard chart is where they need to start.
The Standard chart tab in the Samples & Interpretations module is always present, and contains a panel for all the data types that are present in the well. You can customise the standard chart by clicking in the chart properties icon in the toolbar: and using the panel list to add/edit and delete panels. Right clicking on any panel in the chart will bring up the option to edit the panel’s properties.
In this way you can create the chart you want. When you’re done, you can then use the rightmost button to save the chart as a template.
At this point you can name your template for use in the next well. Any panels that have different properties to the default will be saved in the new template.
In your second well, use the penultimate button on the toolbar to load the template you previously made into the standard chart…
Now, make any changes you like to the panel properties. When you’re done, pres the last button again to save the template.At this stage you have a choice: if you update the existing template, then this will also apply to your first well and any others that happen to be using this template. This may or may not be what you want. To keep things simple, you can select New Template, and the template name will be suffixed by the well name, and thereafter opened in a new tab bearing the template name.
When you next open your wells, the template tabs will reopen in the same state they were saved in, while the standard chart will reset to the default layout. To make changes, see above (load your template into the standard chart ….)
Lots more information on the charts tab, as always, in the help here.
Today we introduce an exciting new feature: an online register of StrataBugs users. It sounds simple – and for you, it is!
All analytical data in StrataBugs is linked to an analyst, who has a name and an ID (usually their initials); the idea being that you could identify who created particular sets of data, and possibly even interact with them in the real world. Anybody who imports data must deal with “matching” analysts – that is, linking their information in the file with some details in your database. This is relatively easy with the newer SBG files because they always contain the analyst’s name. However, there are lots of files out there in many different formats which don’t contain anything more than an ID. Even in the relatively small community of biostratigraphers, we don’t all know each other. This can make matching analysts an uncertain process. Add to this the problem that different people may have the same initials, and things get very tricky indeed.
Our new web services project tackles this situation by giving you the opportunity to “claim” your StrataBugs ID. Anybody else using StrataBugs will be able to link a file with your ID back to you. Plus, newbie biostratigraphers won’t be able to “steal” your ID!
When you next log in, you’ll get the opportunity to opt in or out of using our web services.
If you accept, StrataBugs will check the online register to see whether your StrataBugs ID is registered. If not, you’ll get the opportunity to add it. If it is already registered, but not to your name, StrataBugs will suggest that you change your ID! If you or your system administrator changes your name or ID via the User dialog, your online record will also be updated.
Note that the only way to register your ID is for you to log in. No other user can do it for you.
Now when you are matching analysts from a file, you see a “lookup” button. This checks the register to see if there’s a match against the analyst ID.
In this case, there is, and you’ve got the option to add him as an analyst in your database.
In the interests of transparency, this is all the data we are collecting:
- Your StrataBugs ID
- Your full name
- Your discipline
- An optional link to a web page of your choice (personal website, LinkedIn profile etc)
- The date on which you last logged in to StrataBugs (this is so that we can detect unused accounts and delete them if necessary)
So – download the update (from test) and get claiming your ID before somebody else does!
We try to make it as easy and ‘safe’ as possible for you to explore StrataBugs without inadvertantly corrupting your data. That’s why we always ask you to confirm before deleting something. Last week we were clicking about in this way (exploring), trying to think through an idea, when we stumbled upon a feature that we’d completely forgotten was there.
A helpful user had made a great suggestion. In their own words:
Being able to add interpretations (e.g. chronostrat) via the charts in the Samples & Interpretations module would be a very useful addition, rather than having to keep switching tabs back and forth.
The thought process on our side goes something like this: Well, yes, that would be good! How would that work? Double-click somewhere? There’s already some double-click action in the zones panel (*try double-clicking in a zones panel*) – you can edit existing zones by double-clicking on them. So, maybe double-click where there isn’t a zone? (*double-click where there’s no zone*) Hey, look, it brings up the interval dialog! So we already implemented this! (*try the same on another panel*) Oh dear, doesn’t seem to work in this panel, why’s that?
There are, literally, millions of lines of code in StrataBugs. It’s not surprising that we forget about some of them.
Go to the full post…
Another year, and it comes to our attention that another new geological time scale is published in the form of GTS2016. This new work makes some 27 changes to stage boundaries compared to the previously published GTS2012. We have taken this opportunity to revisit our interpretation of the 2012 time scale and provide a 2016 version which shows the revised stage boundaries, and the resulting changes to the divisions further up the hierachy. We have also added more subdivisions where these didn’t exist before, e.g. the sub-epochs in the Cenozoic.
Because this new 2016 scheme has been created in StrataBugs v2.1, we have been able to add the boundary uncertainty indicator so you can see which are confident, probable or possible.
Users of Timescale Creator Pro may be able to import the new schemes directly from the data pack, but we have packaged the revised timescale so you can download your own copy and easily import this into StrataBugs. If you use the “Read…” button in the Schemes and Interpretations module, you can compare the new scheme on the Match Scheme dialog with the existing GTS2012. The match dialog shows you exactly which changes have been made:
As usual, items in the workspace are on the left, and existing items from the database are on the right. Green rows indicate the new units. Red rows show where there is some kind of difference. Many of the differences are where we have added further precision to the boundary ages.
Once you’ve imported the new scheme, you will need to ensure that zone boundaries in your existing zonation schemes are in alignment with the updated time units. You can get StrataBugs to do the bulk of the work for you using the “Recalibrate…” button. This will create a copy of your scheme with zone boundaries adjusted in the same propoprtion as the change in the corresponding time unit from one scheme to another.
You can also relink existing well data intervals to a new scheme using the “Reassign…” button on the “show wells” dialog for the existing scheme. This procedure looks for units of the same name in the new scheme, and switches the well data to point to the new scheme. For a transition between GTS2012 and GTS2016 there should be a complete match of unit names. The implication of the reassignment is that the unit positions will change when plotting depth/age curves, so your depth/age curves might also need revisiting if you switch to the new time scale.
Unless you are actually using the time to calculate accumulation rates, or measuring time gaps in Wheeler diagrams, or exporting curves into another system, it doesn’t really matter which time scale you use; as long as all your schemes are consistent with it, there is no ambiguity as to which stratigraphic unit zones or events belong to. It is for this reason that in v2.1 you must specify which time scale a zonation scheme belongs to. You can also group the display of schemes according to the base chronostratigaphic scheme.