Written by Andy James, Chief Product Officer
Do you want to unlock efficiencies that modern day computing provides, such as mega-data visualization and cost-effective storage, but your current data format and applications are slowing you down?
Bluware Volume Data Store (VDS™) allows you to compress raw and interpreted volumes of seismic data sets that are adaptable and scalable depending on your business needs, workflows, and visualization requirements. Geoscientists can realize the value that Bluware VDS can deliver without changing existing interpretation applications through Bluware Flexible Access Storage Transcoding (FAST™) to store seismic data in VDS format and stream it from the cloud or on premise. It does this by acting as a translator between VDS and the read requests made by the interpretation application on a SEG-Y, SEP, or ZGY file.
Figure 1: Bluware FAST – simplified view
Before diving into how it works, it is important to understand some of the key concepts of Bluware FAST.
FAST Concepts
About Transcoding
Transcoding is the action of converting information from one form of coded representation to another. This is the crux of FAST. It transcodes from VDS to SEG-Y or other formats on-the-fly. This differs from conversion whereby the whole survey is converted; FAST just transcodes the data being read by the legacy application. This is a significant benefit for data management processes as it enables a single source of data in a central location as opposed to having to copy and convert data for specific applications to run.
About Pre-Fetching
The definition of pre-fetching is to transfer data from main memory, or in our case, VDS to temporary storage, for later use. FAST pre-fetches data into the legacy format. This legacy format is created locally and is intended to be temporary. Pre-fetching can be used when the computer is used offline of the VDS data or when a file format cannot be transcoded as the format is closed.
How is FAST Deployed?
FAST is installed on the same workstation as the application and works on Windows and Linux. On Windows, it runs as a Windows service and on Linux it runs as a daemon process. There are plans in the future to create a non-service-based deployment as Windows services can sometimes create IT challenges.
Mapping Files in FAST
FAST works by creating a virtual file. This virtual file is a representation of a local stored legacy file format. For example, if you have a SEG-Y file on your local or network drive, this could be replaced with a virtual SEG-Y file in FAST. This virtual file is created within the FAST interface where a mapping is made between the VDS implementation of the survey and a local SEG-Y file. The virtual SEG-Y file will appear as a file within the operating system. Inspecting the size of the file will show the actual size of the survey (though it won’t be using any space locally). During the mapping process the header information for the survey is read and cached.
When FAST is running, a virtual folder named FASTMOUNT will be available. This will appear as a folder on the computer. The folder contains the mount point for virtual files generated by FAST. All the virtual files will appear in this folder. The name and path of the folder are configurable. By default, it is “C:\fastmount” on Windows and “/mnt/fast” on Linux. FAST virtual files will have the same extensions as legacy files would have.
Figure 2: FAST mapping workflow shows what happens when a new survey is mapped during FAST or the FAST service restarts and re-maps an existing mapping.
How FAST Works
FAST is intended to be completely seamless to the end user. This is how it works from the end-user perspective.
Opening a FAST Virtual File
The FAST-virtual file is presented to the user within the application in the same way that an actual legacy file format would be presented. If the workflow is to select the file menu and navigate to a file, the exact same process would apply when using FAST. The user will navigate to the FAST mount path as noted above and select the virtual FAST file.
Reading Virtual Files
When an application opens a virtual file, the workflow is identical to the workflow if using the local legacy file. For example, when that application reads data from the file, such as a crossline, FAST will make an API call to VDS to fetch the requested crossline. The data will be transcoded into the legacy format and returned to the application.
It is important to note that if FAST is serving a virtual file as a SEG-Y file, then the application simply reads the whole SEG-Y and converts it internally to its own format. This is a one-time function. Unless the user re-opens the SEG-Y, the application is no longer leveraging FAST.
FAST Reading
FAST responds to the read request that is made within the application. When the application makes a read request, FAST fetches the data from VDS. Using Bluware Adaptive Streaming™, FAST can select a signal quality that can be customized by the user within the FAST interface. When the data is received, FAST can recreate the data in the legacy format on-the-fly and return it to the original read request within the application.
The use of Bluware Adaptive Streaming indicates that just the signal quality needed by the application can be retrieved within the application. By returning less data, the application can end up receiving a performance boost when compared to reading a legacy format within the application.
Figure 3 Application Read Data Workflow
FAST Configuration
FAST has several different configuration options.
Signal Quality
Bluware VDS has a feature called adaptive streaming. This allows selection of different signal quality levels from VDS. FAST exploits this feature and can be customized to select a higher compression ratio than what is stored in VDS. This allows the end-user to choose a balance of quality and performance.
The combination of receiving only the data required for the application in conjunction with adaptive streaming, significantly reduces the data delivered to the application resulting in performance benefits and less network traffic.
VDS Mapping
This is the link to the VDS file or the VDS cloud URI reflecting the survey.
The Legacy Format
FAST is designed to support plug-in format adapters to allow expansion over time. VDS can output to one or many legacy formats without copying data. The legacy format setting will control this.
FAST currently supports SEG-Y, SEP, and ZGY. ZGY can only be cached, not transcoded.
It is important to note that the legacy format is not compressed or a smaller file in anyway. The APIs in FAST recreate the legacy format in an uncompressed form.
Bounding Box or Area (Future)
A setting for the FAST-virtual file to select a bounding box for 3D data or an area for 2D data will be defined in the configuration. The FAST virtual file will be restricted by this setting.
Cached Mode
FAST has a mode that allows caching. Caching creates a full version of the legacy data format in a local or network cache. FAST then uses mirror transcoding to access a virtual file; reading is performed against the cached file rather than VDS. Subsequent reading via the virtual file does not re-read VDS. All the read requests are made against the cached file.
Figure 4: Cached Mode within FAST
The current formats used to store seismic data are stifling innovation within the oil and gas industry. Bluware VDS unleashes new workflows that exploit the rich data that oil and gas companies own. Bluware FAST is a simple, yet powerful tool, that enables oil and gas companies to migrate to VDS without disrupting legacy application workflows and gain access to new workflows such as Bluware InteractivAI Deep Learning.