1. Introduction

1.1. Purpose of the Correlator application

The Correlator application facilitates stratigraphic correlation of cores from multiple holes at a drill site Its features support depth shifting of cores based on high-resolution core logging data and the affine constraint to construct a core composite depth below sea floor (CCSF) depth scale, and splicing of selected core intervals to construct the most complete stratigraphy possible at a site.

1.2. The SCORS ecosystem

On the JOIDES Resolution (JR), the Correlator application is used as part of the stratigraphic correlation support (SCORS) ecosystem, in conjunction with additional software applications covered in a separate user guide (Table 1-21, Fig. 1-21).

Figure 1-21: Overview of SCORS tools and data flow and how they relate to the Correlator application. The yellow number labels 1 through 4 represent the sequence of use of applications when using Correlator as the main tool.

Use of the Splice File Fixer app is recommended when using an alternate tool for correlation.

Table 1-21. Stratigraphic correlation support (SCORS) applications and documentation

1.3. Software version and installation

Access to the current version supported on the JR

This user guide is for Correlator Version 3.0 released in March 2019. Find the application on the following JRSO web sites:

• http://web.iodp.tamu.edu/apps/

Follow your browser and operating system’s instructions to install and launch the application.

Access to the applications on the ship will be obvious, or assisted by JRSO staff, when you board the JR.

Correlator installs a directory for its internal database at a default location that looks something like this:

Documents [or other system folder]

Correlator

3.0 [or similar version number]

db

default.cfg

log

temp

When users import correlation data from a directory of choice, Correlator indexes the data and places them in this directory for internal use. Users doesn’t have to be aware of this directory but can change the path if needed (Fig. 1-31):

Figure 1-31. Correlator File menu.

Compatibility with version 2 affine tables

We don’t expect a significant need to import legacy affine tables. Therefore, the following feature has been minimally tested. Ignore this section if you create your affine tables with version 3.

Affine tables created in Correlator version 3 differ from those in version 2: they include additional information (last three columns, see Appendix 2) that allow Correlator to reconstruct the relationship between cores. The following details will become clear once the user is familiar with version 3.

Affine tables created in the last production version, 2.1_rc2, can still be imported in 3.0 by right-clicking "Saved Tables" in the Data Manager (available once data are loaded) and choosing Import legacy affine table. However, because legacy affine tables have no record of the reference core used to create a TIE, all cores shifted by a TIE will be converted to status REL on import into 3.0. This has no effect on their cumulative offsets, which will be preserved, but users will have to rebuild the TIEs manually (as was the case in version 2).

1.4. Basic functions of Correlator

Data Manager and Display views

Correlator operates within a single window that can be expanded as much as available monitor space permits. The window can be toggled between the Data Manager view (Fig. 1-41) and the Display view (Fig 1-42). To navigate between these views, use the top button on the floating tool bar (Figs. 1-41 and 1-42), which is always available on top of either view unless turned off in the View menu (Fig. 1-43).

Figure 1-41. Data Manager view. Also shown is the floating tool bar, where the top button can be used to toggle to the Display view.

The Data Manager view has two functional tabs across the top:

• The Data Manager tab (Fig. 1-41) lists the files imported into Correlator and provides the functions for adding and managing the data in Correlator.
• The Generic Data tab displays data from files being imported when such an import is triggered in the Data Manager tab (otherwise it’s an empty grid).

 Figure 1-42. Display view, with the Display Preferences tab open on the right.

The Display view has three areas, two for data plotting and one for the functional controls, organized in four control tabs.

• The left plot area is for depth shifting, and the corresponding controls are in the Shift Cores tab.
• The right plot area is for the construction of splices, and the corresponding controls are in the Splice Cores tab. This plot area can be turned off at the top of the Display Preferences tab (shown in Fig. 1-42) if more display space is preferred for depth shifting.
• The control area can be toggled among the following four tabs:
  •  Close: This tab acts like a button and closes the control panel. The control panel can be opened again by clicking any of the other four tabs.
  •  Shift Cores: This tab has controls for depth shifting, which are described in the Depth shift cores section.
  • Splice Cores: This tab has controls for splicing, which are described in the Construct the splice section.
  • Display Preferences: This tab has general data display controls, as shown in Fig. 1-42.
  • Data Filters: This tab offers data filtering options, including decimate, smooth and cull (Fig. 1-44).

Display Preferences and Data Filters

The Display Preferences are self-explanatory and not further described here. Additional, more fundamental display preferences are available in the View menu (Fig. 1-43).

Figure 1-43. View menu. This menu offers fundamental display options that are very rarely changed and can typically be ignored by users.

The Data Filters controls are largely self-explanatory but require some commentary (Fig. 1-44).

• Data filters are applied to the data from all cores for a specified data type. For a more specific filtering of known intervals with severe core disturbance, etc., you have the option to apply a file with those intervals specified in the Correlator Downloader application, at the time of data download.
• At this time, data culling can only be specified for top of cores (to remove data from “exotic” material washed down from higher up in the hole). A future version will include culling from core bottoms (“exotic” material “sucked in” when the piston core was removed) and culling from section ends (“edge effect”).
• Some odd behavior has been observed when deleting a cull filter under certain circumstances, and this has not yet been repaired. An easy workaround is to re-load the data.

Figure 1-44. Three data filtering options on the Data Filter tab: Decimate, Gaussian Smoothing, and Cull. Shown is a 9-point Gaussian filter applied to the magnetic susceptibility data whereby both original and smoothed (white trace overlay) are plotted. The filter can be edited or deleted.

2. Manage data in Correlator

2.1. Import correlation data files

Where are the correlation data files?

Before you can start importing correlation data files, you need to store them in a compatible format in a directory of choice. Content of each data file must be for one hole and one data type. This is automatically true if downloading LIMS data using the Correlation Downloader application, which is highly recommended when working in conjunction with the LIMS infrastructure, such as on the JR, as this offers numerous other advantages.

It is best practice to organize the data in site folders.

Importing the first data set

When you first start up Correlator, you’ll find the empty Data Manager view with only one item, labeled:

• Root – right-click to add data (Fig. 1-41).

To import data files:

• Right-click on the Root item and select Add new data (the only option until data exist in Correlator).
• A browser window opens that allows you to browse to the data files in a directory of choice (the path will stick for future imports and updates). Select one or more files of exactly the same type (format). In our example in Fig. 2-11, we select magnetic susceptibility for holes 361-U1476A and 361-U1476B.
• The first 30 rows of data for each hole are displayed in the Generic Data tab (Fig. 2-11). For commonly used data types, all column headers and column data should be automatically and correctly populated.
• Click Import at the bottom right and the focus returns to the Data Manager tab where a data summary line is added.\

Figure 2-11. Data import opens in Generic Data window, where user may have to fill in the Data Type column by clicking on the header “Data Type” and selecting the appropriate item (in this case, Natural Gamma).

Figure 2-12. Upon importing data, line items for each data type and each hole are added in the Data Manager tab . Note the Saved Tables folder created for affine and splice tables later created.

Also note the Section Summaries folder automatically created and populated with the section summaries from the LIMS registry (more on that below).

Exceptional data type

Correlator normally detects the commonly used data types upon import, based on the header label of the data column. However, here is what you do if that should not be the case and you are getting an error message upon trying to import.

• If the Data Type column in Generic Data is not automatically populated, you need to select the appropriate data type from the drop-down list, by right-clicking on the Data Type column header.
• If a suitable data type is not available, create a data label using the Custom data type item from the choice list (Fig.2-13).
• If a depth column is not identified, you will get an error message. Identify the depth column and select “Depth” from the column header choice list.
• For the occasional column that has data and a question mark in the header, you typically need to select Bottom Offset, or Depth. Select appropriate items by right-clicking the header choice list.
• If you try to import a data file with a Hole ID and data type that already exist, you get an error message.
  •  If in fact you want to update the existing data, e.g., because you added another core to the hole file, use Update from the context menu (also see below).

Figure 2-13. Registering a data type not available in the Correlator choice list

Adding more data

Once you have imported, loaded and displayed you first data set, and you then go back to the data manager to Add new data, you will get the error message in Fig. 2-14. Click OK. This is simply to make you aware of how Correlator works. After you have imported the new data, you need to Load the data again anyway to get a current display.

Figure 2-14. When a user adds new data to an existing, plotted data set, a warning is displayed to make the user ware that the display will be cleared with this action.

2.2. Import section summary files

Correlator needs top and bottom depths of sections to compute splice intervals correctly. The application maintains an internal table for that purpose. Three options exist due to the evolution of the program and its use in different environments.

Method 1 (not recommended on the JR)

In Correlator version 1, the tops and bottoms of sections were exclusively computed by Correlator based on the imported data, which often resulted in small and sometimes larger errors in splice tables. This functionality still exists in version 3 for backward compatibility, however, it is disabled by default in the new Correlator/Preferences menu (Fig. 2-21). In situations where users do not have a section summary file for upload, they can enable the Infer Section Summary if none is provided feature and for each data file loaded (those with "Enable" on in the Data List), Correlator gathers the minimum and maximum depths of data points for each section. If multiple data types are loaded for a hole, all data types are considered and the minimum of minima offsets is used as the top of section and the maximum of maxima offsets is used for the bottom of section.

Figure 2-21. In the Correlator main menus, the Preferences item has a single option: Infer Section Summary if none is provided.

If enabled, Correlator will give a message at the time of data import that the section summary was inferred from the data (Fig. 2-22).

Figure 2-22. Message if Correlator infers section boundaries from the data.

Method 2 (standard method on the JR)

Starting with Correlator version 2, a section summary file is uploaded automatically when the user imports data to Correlator, if that section file exists in the same directory as the data file(s). This is the standard process on the JR because the Correlation Downloader application automatically downloads a section summary file from LIMS along with the data files, and also updates the section file along with the data file when a new core is appended in the real-time correlation workflow. The user will see the section summary file in the data folder but must not upload it separately (Correlator would try to load it like a regular data file). If the section summary does not exist or cannot be uploaded because of an incompatible format, an error dialog appears.

Method 3 (not needed on the JR)

Alternatively, section summary files can also be imported “manually” by right-clicking on the Section Summaries item in the Correlator Data Manager and selecting the Import Section Summary Files(s) option. Once the user browses to the appropriate file and selects it, an import dialog window opens showing (part of) the file content (Fig. 2-23). The user can click Import or Cancel.

Fig. 2-23. Manual section summary import.

Note: the section summary can also be uploaded the same way as any data file, but that is usually meaningless because we don’t need to plot the sections that way. If you need to upload section summaries manually, make sure you do so from the Section Summaries item so Correlator uses them as intended.

2.3. Load data for correlation

Once correlation data have been imported to Correlator and are listed in the hierarchy of the Data Manager, they reside in Correlator’s own local database. Users still need to load the data for display and correlation. To load data, select, then right-click on a line item in the Data Manager, and select Load.

• You can load an individual file, a set of files for a data type, or all files for a site. Typically, you just load the entire site because it is lightning fast.
• Make sure that the files you want to load are enabled. When saved, affine and splice tables are enabled and will be applied to the loaded data.
• After loading the data, the Data Manager view turns into the Display view where the data is plotted and correlation and splicing functions are available.

If you import data and switch to the Display view without loading, a message will appear in the plot window reminding you that you need to load the data for them to be plotted.

2.4. Update Correlator data

During the typical JR work flow, correlation specialists download the correlation data from LIMS each time the data from a new core are available. This iterative process is facilitated in at least two ways:

• The Correlation Downloader application has features that allow the download to be executed efficiently with pre-configured parameters and, most importantly, by appending core data sets to the hole data file so the entire data sets do not need to be downloaded each time (see SCORS Downloader user guide).
• The Correlator application remembers the source directory for each data file name so it can update its internal database efficiently.

To update the Correlator internal database with updated files:

• Select the highest practical item in the Data Manager, right-click and select Update.
  • No, you don’t have to delete the data and re-import!
  • If an update took place, you should get a confirmation (Fig. 2-41). If you don’t get a confirmation, the data in Correlator were presumably up to date already.

Figure 2-41. Data update context menu and confirmation dialog.

Updating the Correlator database is equivalent to an import. If you update data and switch to the Display view without loading, a message will appear in the plot window reminding you that you need to load the data for them to be plotted. Make sure you also load the affine and splice tables again, if applicable.

2.5. Export data

Export affine and splice tables

When working with the LIMS database, users on the JR will typically only be exporting affine tables and splice interval tables. Users will subsequently upload these two tables to the LIMS database for each correlated site, using the SCORS Uploader and Manager application, so all necessary data reports can be computed in, and reported from LIMS via the LORE reporting interface. This has the advantage that any LORE user can download any LIMS data type with the CCSF depth scale, or by splice, including data not used in the correlation process.

To export an affine or splice table, right-click on the item and select Export from the context menu. Browse to your data folder for the site (if necessary) and save.

When you export affine and splice tables, you give them a name, and Correlator adds extensions *. affine.csv and *.sit.csv, respectively. It is advisable that you assign names to these files that make sense as the files will ultimately be uploaded to, and available from the LIMS database. In particular, use a naming scheme that helps you and others recognize associated affine and splice tables.

Should you import an affine or splice table that you exported in an earlier session, be aware that Correlator will rename the files according to its internal rules.

• It will ignore your name.
• It will use the expedition, site and hole number information according to the data in your folder.
• It will add the extension *.#.affine.table and *.#.sit.table, respectively, where # is an incremental number relative to the existing tables in the Data Manager.

Export correlation data

The correlation data imported to, and managed in Correlator can also be exported using the context menu for data items in the Data Manager. Such exports would make sense if users worked outside of the LIMS ecosystem and were able to apply the enabled affine and splice tables. This is currently not possible and exporting correlation data has no use case.

2.6. Summary of data management functions

Seven different data management functions are accessible via context menus on the Data Manager tab (Table 2-61).

When opening Correlator for the first time, only one item is present in the Data Manager tab, called Root and it has only one function: Add new data. As soon as the first data file is imported, Correlator creates a data directory for the site, using the site name from the data file, and the following data group folders with all the data management functions appear:

• One folder for each imported data type. Within each data type, the imported data are represented by a line item for each hole.
• The Section Summaries folder described above, which needs one file and list item per hole.
• The Saved Tables folder where Correlator saves affine and splice tables for the site.

Table 2-61. Data Manager context menu items.

3. Depth shift cores

3.1. Depth shift concepts

Affine constraint

The goal of depth shifting is to construct a composite depth below seafloor (CCSF) depth scale by arranging the cores from one or more holes in a way that the combined data better represent the stratigraphy at a site than the cores do at their standard CSF-A depth scales.

The composite depth scale is defined in an affine table where each core has a cumulative offset, the difference between its CCSF and CSF-A depths. The affine constraint stipulates that no virtual stretching or squeezing is allowed within a core. This is a practical and effective approach because (A) it is based on straightforward rules and avoids the implementation complexity of virtual stretching and squeezing, and (B) sampling of the physical cores would become overly complicated if the CCSF depth scale was distorted in the correlation process relative to the CSF-A scale, which is true to the physical samples. Correlation under the affine constraint creates a “~95%” solution quickly and effectively, whereas resolving the remaining “~5%” of the correlation involves a lot more work and subjectivity and the result is far more difficult to apply.

The coring process does stretch and squeeze cores to a certain degree, and this artificial stratigraphic distortion, combined with actual variability in the stratigraphy in multiple holes, means that between two cores only one stratigraphic feature can be exactly correlated and assigned the same composite depth. Other correlative features will have somewhat different composite depths.

Shifting methods

Depth shifts can be defined by one of two methods: by creating a tie between two cores (TIE method) or by shifting a fixed amount or percentage of depth (SET method). A core shifted with the SET method can later be shifted by the TIE method, however, cores that are tied (part of a chain) cannot be shifted by the SET method. Cores have a type designation based on the (last) shift method applied: REL, TIE, or SET. These designations are used programmatically to implement the above rules and to control the color of the core data trace.

• At the beginning, all cores are of type REL (relative positions to each other based on the original CSF-A depth) and the core traces are yellow.
• When cores are tied to another core based on correlation features, their status changes to TIE and their traces are green.
• When cores in a single hole are shifted by a fixed offset or by a percentage of their CSF-A depth, the status of cores shifted in this manner changes to SET and trace turns orange.
• Ø However, when an entire chain of tied cores, including cores from multiple holes, are shifted by a fixed amount, the cores’ status does not change, they are still TIE.
• If a core of status SET is tied, its status changes to TIE and the trace color turns green.

Correlator keeps track of the cumulative offset of each core resulting from all shifts applied, the method used for the latest shift, and in the case of TIE relationships, the core to which a given core was tied. The specification for the affine table was expanded with Correlator version 3 for the purpose of recording the latest shift method and the tie relationships (see Appendix 2 for the affine table specification).

Chaining cores

Coring in one hole can never recover a complete stratigraphic sequence. Ideally, two holes can achieve that if the cores in the second hole are offset sufficiently to cover the coring gaps in the first hole. A CCSF scale is then defined by tying cores from the top (as close to seafloor as possible) to the bottom (as deep as correlations are possible), establishing ties from reference (REF) cores to shifting (SHIFT) cores, thus creating a simple chain of cores.

In many if not most cases, cores from two holes cannot achieve complete stratigraphic coverage due to a number of factors and cores from a third or even fourth hole are needed. Since the goal is (should be) to tie all cores from all holes into the CCSF framework, the cores will not form a simple chain anymore, but include multiple chain branches. A new chain branch is created when a core serves as a REF core for two or more SHIFT cores. Under no circumstance can a core be a SHIFT core to more than one REF core due to the affine constraint.

Because the CCSF scale construction proceeds from top to bottom, “upstream” tie changes, i.e., changing the tie from a SHIFT core to its REF core, are simply forbidden. Upstream tie changes would have undesirable and unintended effects. In such cases, the user needs to decide where to implement the tie change further upstream so the tie break effect is directed downstream. Downstream directed tie changes preserve the ties unless a chain branch must be broken off, which the program can identify and the user can be prompted to accept the consequence or cancel the action. An example will be given below.

Summary of shift rules

• A core can be depth shifted once or multiple times, resulting in one single cumulative offset, which is the difference between its top depth at the constructed CCSF scale and that at the original CSF-A scale.
• Cores can be shifted by the TIE method or the SET method.
• Two cores can be related with only one tie due to core distortion, stratigraphic variations from one hole to the other, and the affine constraint.
• A core can be REF core to multiple SHIFT cores, however, a SHIFT core can only be shifted by one REF core.
• Cores related with TIEs form a chain. If a core is the REF core for more than one SHIFT core, chain branches are formed.
• Upstream tie changes are not allowed. Downstream tie changes are allowed and users will be prompted to accept resulting tie breaks or cancel the action.

3.2. Shift cores with the TIE method

Depth shift controls and feedback

The user can shift cores by establishing tie points for two cores on the basis of correlative features in the data or by opting for a statistical correlation.

• Note: these ties are only for the purpose of shifting cores. They are not “splice ties”. However, in anticipation of splicing, the best correlation between two cores may be chosen where a splice interval boundary is likely to be established because alignment of stratigraphic features in other parts of the cores is not guaranteed.

To shift cores, select the Shift Cores tab of the Display view to see the control pane (Fig. 3-21), which provides both the controls for shifting cores and the feedback on the progress of shifting.

• Note: you can shift cores without selecting the Shift Cores tab, operating strictly with the context menu. However, you won’t have all controls or the graphic feedback.

At the top of the Shift Cores control pane three plots are available to choose from:

• Evaluation: This is a correlation coefficient plot that can provide a statistical assessment of how well two cores correlate (Fig. 3-21A).
• Growth Rate: This is a plot of the composite depth (CCSF) vs. the original depth (CSF-A) for each core top. The slope of the core segments is the “growth rate” (Fig. 3-21B). For APC-XCB coring, the rate is typically between ~1.2 to 1.0, gradually decreasing downhole as the formation gets firmer and elastic and gas expansion upon recovery diminish. If the curve exhibits erratic changes in growth rate for a hole or a core, and unless an unusual stratigraphic phenomenon exists, something may be wrong with the correlation.
• Shifts: This is a convenience display of part of the new affine table, listing all cores in play (Fig. 3-21C).
  • Core column: identity of hole and core.
  • Shift column: current offsets applied in Correlator
  • Type column: relationship a core has to other cores: TIE, REL and SET, as described above.

Beneath the graphic are the controls for depth shifting. The most important tie shift controls are also available as context menus.

Figure 3-21. (A) Shift Cores tab with Evaluation plot, (B) Growth Rate plot and (C) Shifts plot.

Basic procedure

Core traces are colored based on the depth scale and shift status of the cores. At the beginning, all core traces are yellow, indicating that they were not shifted and are still at the original CSF-A depth scale (Fig. 3-22). They have the status REL, meaning their positions are relative to the previous core as defined by the CSF-A scale. The fact that yellow traces and status REL go together is trivial at this stage but not later on.

Figure 3-22. Before any shifts are made, all core traces are yellow, all cores are of type REL, and all offsets are zero.

To prepare the first tie, we select the core with the shallowest data as the “anchor” or “root” core as the reference (REF) core. In the case of our example (Fig. 3-23), this is core B1:

• Shift-click the trace of REF core B1. A red dot and horizontal line will appear.
• Shift-click the trace of SHIFT core A1. A green square and horizontal line will appear.
• Furthermore, a white and red copy of the data trace from the SHIFT core is overlain on the trace of the REF core to visualize the correlation.
• Select the Evaluation graph on the control pane to show the best statistical correlation for the proposed shift.
• Make adjustment to the shift to achieve the desired correlation in one of two ways:
  • Select “To best correlation” from the control pane (Fig. 3-24). This option does not have a context menu equivalent. The alternative is to shift “To tie”, the more common option. Note that using the statistical “To best correlation” option blindly may result in unexpected shifts!
  • Arrow the green dot up or down to achieve the visually most appealing correlation on either the Evaluation graph or the trace overlay. This is perhaps the more common practice.

Figure 3-23. Preparing the first tie by shift-clicking the reference (REF) core B1 (red dot and horizontal line) and the SHIFT core A1 (green square and horizontal line).

Figure 3-24. Tie control options “To tie” and “To best correlation”.

• Next you can pick one of two shift scope options by either right-clicking the green dot or by using the widget on the control pane (Fig. 3-25):
• Ø “This core and all related cores below” is the more commonly used option because it prevents shifted cores from “running over” un-shifted cores as you proceed deeper in the hole.
• Ø “This core only”.
• Committing to or cancelling the shift works differently in the context menu and the control pane:
• Ø In the context menu, selecting one of the two scopes in Fig. 3-25A executes the shift, and the “Clear tie point(s)” option cancels it.
• Ø On the control pane, two buttons are available to Apply Shift or Clear Tie (Fig. 3-24).

Figure 3-25. The user can pick one of two scope options: “This core and all related cores below” or “This core only”. Shown are (A) the options on the context menu and (B) the options on the control pane.

A.                                                                    B.

Figure 3-25. The user can pick one of two scope options: “This core and all related cores below” or “This core only”. Shown are (A) the options on the context menu and (B) the options on the control pane.

• Once you commit to the shift, the following happens (Fig. 3-26):
  • A white arrow is drawn from the REF tie point to the SHIFT tie point, one arrow for each data type.
  • The SHIFT core’s trace turns green and its type changes to TIE
  •  If “all related cores below” was selected, all core traces below the SHIFT core turn orange and their type changes to REL because they are still in the original relative position to each other.
  • The shift table shows the offset amount of the SHIFT core (and all cores below, if that was the selection), and indicates the REF core used for the shift (B1 in Fig. 3-26 example).
  • The growth rate plot is updated (plot examples are shown in Figs. 3-21 and 3-27).
  

Figure 3-26. First tie is completed.

The remaining controls on the Shift Cores tab (SET, Undo and Save) are described in subsequent sections.

Changing ties

What happens when you change your mind about a tie between two cores and want to redo it? Or what if you created a chain using cores from the first two holes, and now core data arrive from the third hole and it makes sense to “weave them in”? The latter scenario is exemplified by Fig. 3-26 where it is obvious that the first core gaps in the first two holes align exactly, meaning that correlation of the first two cores to subsequent cores is not possible using only Holes A and B. We are therefore introducing additional data from a third Hole D.

Ties can be revised anywhere in an existing chain as long as the change is made downstream, i.e., in the direction of the existing tie, or if a new core (e.g., from Hole D) is added as a SHIFT core anywhere in the chain. All ties from related cores below the SHIFT core remain intact if the user selects to shift “all related cores below”.

Two exceptions exist.

• If you are trying to reverse the shift direction of a tie, Correlator will throw the error in Fig 3-27 if you try. The reason is that reversing a shift would lead to a SHIFT core having two REF cores, which is not possible. Thus, one would create a chain reaction of tie breaks. If you really want to reverse that tie, first break the offending tie (see below) and then repair your chain as needed.
• If multiple chain branches exist, a common occurrence when cores from more than two holes are tied into a chain, tie change may cause a conflict. Correlator will warn the user of the ties to be broken while preserving unaffected ties. You can decide whether to proceed and then fix the damage to the chain, or cancel the tie change (Fig. 3-28).

Figure 3-27. Reversing a tie direction to a SHIFT core is forbidden. In this case, a tie revision is attempted from B2>D2 (red and green dots). However, the existing tie B2>D2 tie does not allow that. The user would have to break that tie first.

Figure 3-28. A typical situation where applying a tie change creates a conflict. The  user decided to correlate D2>A2 (see red and green dots). This is a “downstream” change and thus allowed.

However, because D2>B2 and B2>A2 ties already placed D2 and A2 in a fixed relationship, the B2>A2 tie has to be broken if D2>A2 is to be tied.

Breaking individual ties

It may happen that you want to (or have to) break out a core from the chain because you found better chaining options. The easiest thing may be to delete a tie or two and correlate them again using suitable correlative features. This is now easy:

• Right click on a tie and selecting Break tie.

Alternatively, you can break a tie via the control pane:

• Go to the Shift table in the Shift Cores tab.
• Select the SHIFT core (at the receiving end of the white arrow) of the ties to be removed.
• Click the Break TIE button underneath the Shift table.

It is then your task to fix whatever consequences your action has. Correlator assists you by coloring the broken-out cores orange, representative of the status type REL.

3.3. Shift cores with the SET method

Rationale for using SET

Sometimes you may want to shift one or more cores by a certain distance or a certain percentage, rather than by tying them. Example use cases are:

• Seed core offsets: You know what the approximate growth rate will be (typically 1.05 to 1.1, or ~5 to 10% in APC cores) and you like to “seed” corresponding offsets for all cores so they are spaced out near their CCSF depth positions and are easier to tie together. This is particularly useful when you get data for a third or fourth hole after you have constructed a preliminary CCSF scale with the previous two or three holes, respectively.
• Adjust for an odd stratigraphic feature or coring artifact: A stratigraphic feature such as bedform or mass wasting may be inferred in a hole based on apparent increase or decrease in strata thickness. In some rare cases, an interval may have been cored twice (or been missed) by accident due to human or mechanical error. These situations can be mitigated by shifting cores by a fixed amount. On the SET dialog in Fig. 3-31, use the appropriate selections and apply.
• Extend the CCSF construct when ties are not possible: At some point, tying cores by correlating stratigraphic features in the data is not possible because of insufficient signal in the data or insufficient core coverage. This can be an intermittent interval where ties are possible above and below, or it occurs typically at greater depth. It is often possible to “stretch” the extent of the CCSF construct by applying a well-informed growth rate as a SET Percentage for one or more cores.
• You may have constructed a chain of tied cores and then decide that the seafloor reference (of the anchor core), or the position of a second chain at depth, should be changed by a small amount. Rather than having to start over building the entire chain, you can shift an entire chain of tied cores by a fixed distance.

SET options

To set one or more cores:

• Click the SET... button on the Shift Cores tab (Fig. 3-31).
• Select the Hole and a Core from the dropdown lists.
• Select one of three options for the scope of the shift (Fig. 3-31):
• Ø Selected core and all untied cores below in this hole
• Ø Selected core only
• Ø Entire TIE chain starting from core… (select from available root cores)
• Opt whether to shift by:
• Ø Percentage, a percentage of the original CSF-A depth, or
• Ø Fixed distance (m), the absolute distance from the original depth CSF-A depth
• Add a comment for future users or yourself (optional)
• Click Cancel or Apply.

The following happens when you apply a shift with the SET method:

• The core trace is changed to blue to indicate the data has been depth adjusted by SET (Fig. 3-32).
• The type (SET) and amount of shift (m) is shown on the plot.
• The Shifts table is updated with the Type of one or more shifted cores changed to SET.
• The Growth Rate plot is updated.

Note: With the first two of the three SET scope options, cores that are in a TIE relationship cannot be SET. They first need to be un-tied (Fig. 3-33).

Note: The percentage or absolute shifts are always relative to the original CSF-A depth, not relative to the depth cores may already have been shifted!  For example, a core may already have a cumulative offset of 5 m and if an absolute shift of 1 m is applied the core actually shifts 4 m upward, not 1 m downward.

Figure 3-31. Seeding core positions near their future CCSF depth. This needs to be done for each hole separately. Shown here is the SET dialog and the Shifts table, where all offsets are zero (and core traces are accordingly yellow).

Figure 3-32. All cores in Hole A are shifted by 5% of their CSF-A depth and are spaced out suitably for creating ties. The color of the core traces turned blue. The SET operation in this case would be repeated for holes B and D.

Figure 3-33. The attempt to SET cores that are part of a chain failed.

3.4. Undo shifts

You can undo shifts in two principal ways: one shift at a time, or all shifts in one swoop.

To undo shifts one at the time:

• Use the Undo Previous Shift button on the Shift Cores tab.
  • Shifts that were achieved with the TIE and/or the SET methods are undone in the reverse order they were made.
  • Undo also works for shifts that were saved to the affine table. Save/Update of the affine will account for any undo actions. (See below for more information on Save.)

Undo all shifts in one action by disabling the affine table:

• Go to the Data Manager (and save the affine table when prompted).
• Open the Saved Tables tree.
• Disable the affine (and splice, if applicable) table using the right-click context menu.
• If you try to switch directly back to display, you get the prompt in Fig. 3-41).
  • Say No and you will not proceed to the Display, allowing you to Load the changes you made in the Data Manager, which will get you back to the Display with all shifts and ties gone.
  • If you say Yes you will find the Display NOT representing the disable/enable action you just took.
• Disabling affine tables allows you to start over with all cores at the original CSF-A depths, while keeping the disabled affine table just in case you want to apply it again later.

Figure 3-41. Prompt when user tries to switch to Display without first re-loading the data.

Undo shifts in one action by deleting the affine table:

• Go to the Data Manager (and save the affine table when prompted)
• Open the Saved Tables tree.
• Delete an affine (and splice, if applicable) table using right-click context menu.
• You will get the warning in Fig. 3-42.
  •  Say OK and the table is gone, as intended. All you need to do now is select Load from the site folder and you are back to the Display, with all shifts undone.
  • Say Cancel and nothing happens.

Figure 3-42. Deleting a table will clear the data from the Display. You need to Load the data again to ensure the Display reflects changes made in the Data manager.

3.5. Manage affine tables

Save affine table

Depth shifts are saved in an affine table within the Correlator application. Users can save as many affine tables as they like. Users have three ways to trigger a save of recent shift changes to the affine table, each:

• Click Go to Data Manager on the Tool Bar.
• Ø The prompt in Fig. 3-51 appears.
• Ø If you click Yes, the Save dialog in Fig. 3-52 comes up.
• Click Save on the Tool Bar, which brings up the Save dialog in Fig. 3-52.
• Click the Save Affine Table button on the Shift Cores tab, which also brings up the Save dialog in Fig. 3-52.

Figure 3-51. Save confirmation prompt.

Figure 3-52. Affine Save dialogue if the Save Affine Table button is used.

If no enabled affine table exists, the current shifts will be saved in a new, enabled affine table without any prompt or confirmation. The file name generated by Correlator will include a number that is incremented by 1 from the highest numbered affine in Correlator, including disabled affines.

If an enabled affine table exists, you have the option of updating an affine rather than creating a new one.

Upon saving, you will receive a confirmation (Fig. 3-53).

Figure 3-53. Confirmation message of successful affine table saving.

Enable and load affine table

If you want to use an affine table that already exist in Correlator but is disabled:

• Click Go to Data Manager on the Tool Bar and open the saved tables tree (Fig. 3-54).
• Enable the one you want to load – this will automatically disable the previously enabled one.
• Right-click on the saved tables item and choose Load from the context menu.

Figure 3-54. Saved affine tables are listed in the Data Manager. Only one can be enabled at any one time. Enabling a disabled one will disable the enabled one.

Export and Import affine table

To export your final affine table (i.e., to load it into the LIMS database), use the Export option on the context menu (Fig. 3-54).

In some cases, you may want to import an affine table that you exported in a previous session. To do so, right-click on the Saved Tables item in the Data Manager and select Import affine table. (Fig. 3-55).

Note the option to Import legacy affine table, which allows the import of affine tables created prior to Correlator v. 3.0.

Figure 3-55. Import an affine table function.

4. Construct the splice

4.1. Splice concepts

A splice is constructed by selecting cores from multiple holes that were stratigraphically aligned relative to a common core composite depth below seafloor (CCSF). The specification of the splice interval boundaries, where a core interval from one hole is spliced to a core interval from another hole, is a subjective matter. Ideally the splice interval boundaries are at positions where high-resolution stratigraphic features are at the same CCSF depth. This is the reason why the choice of splice interval boundaries should be on the correlation specialist’s mind when selecting TIE points in the depth shifting process.

Basic rules:

• A splice interval can only consist of one interval from one core.
• A splice is always based on one specific affine table (and the CCSF depth scale derived from that affine). Correlator fully protect you from associating a splice table with an incompatible affine table. However, if you are loading an incompatible affine table with a splice table, Correlator will through an error, as shown later.

4.2. Create a basic splice

Before starting to splice, go to the Preferences control panel and make sure that

• the Show Splice window partition check box is checked so plot area for the splice is enabled.
• The Independent Splice scroll bar check box is un-checked (unless you really fancy looking at different depth intervals in the two plot partitions).

Then switch to the Splice Interval tab to show the control panel for splicing on the right side of the plot window (Fig. 4-21).

Next, repeat the following for each core you want to include in the splice:

• Drag core data traces from the depth shift window partition on the left to the splice window partition on the right side of the divider.
  • The part of the trace covering a depth interval not yet covered by a previous core is added to the splice, in blue, resulting in a default splice where each interval extends to the bottom of the core.
• To highlight the splice interval that was added, click on the splice trace (Fig. 4-21)
  • The highlighted interval turns green.
  •  The trace of the entire core is added to the right in red for reference.
  • The top and bottom boundaries of the splice interval appear with handle dots.

Figure 4-21. Core traces dragged into the splice partition turn blue. To highlight one, select it and the lower part that was spliced to the previous core turns green. At the same time, the entire core trace appears in red for reference.

• The default splice boundaries are usually not the desired ones as they are exactly at the bottom of cores.
  • Try to drag any of the lower interval boundary dots down. It will turn red and say “Bottom of Core X”
• To move the splice interval boundaries to the desired depth, drag or arrow the boundary button up (Fig. 4-22).
  • The resulting splice interval table in the control panel to the right shows the exact depth.
  • Note how the labels on the plotted splice interval boundaries change to indicate the top and bottom of a core if you drag them far enough.
  • This is where the user may want to align splice interval boundaries with the appropriate white TIE arrows in the depth shift window.

Figure 4-22. Drag the upper interval boundary up to desired splice depth. Compare with previous figure.

• For each addition of a core to the splice, a record will be added to the Splice Intervals table on the control panel, which is a short form of the formal splice interval table that will ultimately be saved. The table has the following three columns (Fig. 4-22):
  • Core: a combination of hole ID and core number.
  • Top (m): splice interval top CCSF depth of the interval based on current affine.
  • Bot (m): splice interval bottom CCSF depth of the interval based on current affine.
• The interval selected in the display is selected in the table and vice versa.
• Interval Comments: A text box where users can add a comment about the selected interval. The comment will be exported with the splice interval table.
• Delete Interval <X> button: removes the selected splice interval.

NOTE: Correlator doesn’t care from which data type you drag a trace, it simply uses whatever trace you drag over. It normally makes sense to drag traces from only the same data type. In the end, any data type can be retrieved by splice.

4.3. Insert a core into an existing splice

You may have created a tentative splice using cores from holes A and B, and now that depth-shifted cores are available from hole C you would like to splice some of them in, or you simple decided on better interval from another core. If you try to drag a core over an existing  splice, Correlator simply won’t add it because no more than two overlapping core intervals can be in any one splice depth interval. You first need to create a gap, which requires you to split the splice.

To create a gap and insert a new core interval:

• Select a splice interval that overlaps in depth with the core you want to insert.
• Note the labels at the top and bottom splice interval boundaries, respectively, on the splice plot (Fig. 4-22):
• Ø Tie D6 & A6
• Ø Tie A6 & B6
• Also note the corresponding buttons in the control panel, which offer the user the option of splitting the splice either at the top or the bottom of the splice interval:
• Ø Top: Split D6 & A6
• Ø Bottom: Split A6 & B6
• Say you decide to Split D6 & A6, the following happens:
• Ø the label in the plot changes to A6 bottom.
• Ø the button changes to Bottom: Tie A6 & B6, which would allow you to revert the split.
• Now you can simply drag the new core D7 into the splice area, select the splice intervals, and adjust top and bottom boundaries. Alternatively, you can first move the A6 bottom up to create a visible gap and then drag the trace of core D7 into the splice area.

Figure 4-31. Create a gap to insert an interval from Core A3 into the splice.

Figure 4-32. Insert Core A3 into the gap.

4.4. Change the affine during the splicing process

Ideally, depth shifting should be concluded before a splice is assembled. However, life is not ideal and you may want to shift a core after you have made a splice. Because splice intervals are defined by their CCSF depths, shifting their cores invalidates the splice interval boundaries.

If you are trying to shift a core that is part of the splice, Correlator will warn you that this (and other related cores, if so opted) will be removed from the splice (Fig. 4-41):

• If you continue, these cores will be removed from the splice.
• If you choose “No”, the shift is canceled.
• If you chose “Yes”, an additional warning may be provided, identifying the shift ties that will be broken with this new shift. This follows the same rules described in the Depth shift cores section.
• Ø If you continue, the affected splice interval will be eliminated from the splice and listed ties will be broken.
• It is up to you to drag the trace of the same or an alternate core over into the splice area to fill the gap, and to adjust the splice interval boundaries as needed.

Figure 4-41. Warning message resulting from an attempt to shift Core D2. Because the option “This core and all related cores below” was selected, an entire set of cores would be removed from the splice.

NOTE: If you commit to the shift and then regret it, the shift can be undone with the Undo Previous Shift button. The shift ties are re-established, however, the splice intervals that were removed are not replaced. Here is a simple workaround to get the splice back:

• Go to Data Manager.
  • When asked whether to save, choose No.
  •  In the Data manager, load your site data again and your splice is restored.

If the user has at some point created an alternate splice, the cores with compromised splice interval boundaries are not removed from that splice. Only if and when the user switches to that alternate splice using the Alternate Splice button will they find a surprise in the form of an error like this:

• “Error: Core B2: Applied affine shift (9.243) does not match shift in Splice Table (7.918), can’t load splice.”

This is because Correlator keeps track of the affine offsets in the splice registry and compares the offsets from the affine and the splice when the user is loading the tables. It allows loading only if no difference is detected.

4.5. Manage splice tables

Loading splice tables

The basic functions and dialogs to save, enable and disable, load, export and import, or delete splice tables works in principal the same way as for affine tables, described in the section Manage affine tables.

Two important exceptions exist for loading splices:

• Splice tables remember the data type used for each splice interval when the splice is created and saved. If all data types used in a splice are not enabled in the Data Manager, loading that splice will fail with the message in Fig. 4-51.
• Splices remember the core offsets at the time the splice is created and saved. This means a splice has always one compatible affine table and if you are trying to load an incompatible affine or splice you will get the warning in Fig. 4-52. Unfortunately, spices and affines are not  associated in Correlator and it is up to the user to keep track of who matches who.
  • However, Correlator does help you keep a quasi-association by using the same number in the file names of the affine and splice tables if you choose to Create New on the save dialog.

Figure 4-51. Message displayed when you are trying to load a splice and a data type used to make the splice is not enabled.

Figure 4-52. User is trying to load a splice that was saved/exported with a different offset for core B2 than the offset of core B2 in the currently enabled affine table.

Exporting and importing splice tables

If you export affine and splice tables, you give them a name, and Correlator adds extensions *. affine.csv and *.sit.csv, respectively. It is advisable that you assign names to these files that make sense as the files will ultimately be uploaded to, and available from the LIMS database. In particular, use a naming scheme that helps you and others recognize associated affine and splice tables.

When you import an affine or splice table, be aware that Correlator will rename the files according to its internal rules.

• It will ignore your name.
• It will use the expedition, site and hole number information according to the data in your folder.
• It will add the extension *.#.affine.table and *.#.sit.table, respectively, where # is an incremental number relative to the existing tables in the Data Manager. This is the way Correlator keeps track of things.

Select alternate splice feature

On the Splice Cores tab, you’ll find a button Select Alternate Splice. This feature allows you to view another, existing splice in the third (right-most) splice plotting track. You will probably have to expand your splice window width to see that column.

When you click the button, you get the dialog in Fig. 4-53. You can specify a data type and a splice.

• Data Type: you can select any data type currently loaded and plotted in the Display.
• Splice: you can select one of splices listed in the Data Manager.
  • CAVEAT: If you select a splice that is not compatible with you currently enabled affine table, you will get the Message in Fig. 4-52. This means this feature is mainly useful to display the current splice with a different data type than the one used to create the splice in the leftmost splice track.

Figure 4-52. Loading a different existing splice.

Alternatively, you can Go to Data Manager, open the Saved Tables tree, enable another splice and its associated affine table, and reload the tables.

Appendix 1: Section summary specifications

Correlator benefits significantly from having a section summary file imported along with the correlation data. The table below shows the section summary exported automatically from LIMS when using the Correlation Downloader application. As long as the section summary file is located in the same folder as the correlation data, Correlator will import it automatically.

Appendix 2: Affine table specifications

The affine table exported from Correlator has the 15 columns described in the table below. In order to take advantage of the features offered from within the LIMS database, affine tables exported from Correlator or any other correlation programs must meet import requirements of the SCORS Uploader and Manager application. As a minimum requirement, the first 7 columns must be present.

Appendix 3: Splice table specifications

The splice table exported from Correlator has the 15 columns described in the table below. In order to take advantage of the features offered from within the LIMS database, splice tables exported from Correlator or any other correlation programs must meet import requirements of the SCORS Uploader and Manager application.

Credits

This user guide was written by Peter Blum, March 2019 for Correlator Version 3.0.  See archived version for the user guide for the previous version of SCORS- Correlator.

Archived versions

Stratigraphic Correlation Support (SCORS) User Guide.docx:  Word file written by P. Blum (2016-10-8)

Correlator UG - 24022020