Why the new API?
The Roxar API is designed to meet the evolving requirements of industry. Today, users may deploy components from Schlumberger’s Ocean/Petrel, Landmark’s DecisionSpace and Paradigm’s Epos. Users want to connect these into custom workflows. The API encourages standards-based data management and creative thinking. We also needed the API ourselves to realize our internal goal of evolving our legacy software to a new architecture. The new API is built around, but separate from RMS.
What happened to Dot Rox and the RMS OpenAPI?
Our earlier Dot Rox and OpenAPI have evolved into the new Python API. Also our IPL scripting language is being upgraded, but it will not be retired as it includes as rich set of scripts developed by our clients.
What data standards are you leveraging?
We access third party data and applications and data in e.g. Excel. But our main standards push is for Energistics’ Resqml where we are very involved. We also access Roxar shared earth model project data from outside of RMS. This real vendor independence was expensive to develop. The Python API can be used to develop apps for visualizing data in a web browser from multiple projects, to perform data management and perform data QC to corporate standards.
[We watched a short demo of smoothed log data using the API and NumPY and SciPy libraries. The functionality can be delivered as either a Python Job in the RMS IDE and/or as a stand-alone WebGL app for multi-endpoint visualization from the Roxar server.]
Does the multi-endpoint functionality use the Calgary Scientific technology you showed a couple of years back?
No. Now it is all home grown. The API supports desktops, tablets or smartphones. Some of this multi endpoint visualization is still work in progress. But there are other ways of doing this than Calgary Scientific. They were one of the first out there, but it takes a lot of work to embed their technology in legacy software.
Do you offer an Eclipse-based IDE?
It could be or any IDE you prefer. We provide an environment that takes full advantage of Python community bells and whistles. We support Python 3.4, the latest and greatest and the Jupyter Notebook. Which we also in our own development process internally.
[Another demo showed Petrel-to-RMS interoperability combining the Ocean and Roxar APIs to create new workflows, demonstrating data transfer from a Petrel plug-in that pushes data to RMS.]
How much of the Ocean API is accessible, can you manipulate Petrel from the API?
The plug-in is limited to functionality we have developed in the API. You could manipulate Petrel but this would be slow. We use the Ocean license and our API to move stuff between the two platforms.
A bit like Open Spirit?
Yes. Data movement is a lot easier today. But we are happy to leave the data management to specialists we just provide the tools.
Is this most for research or production?
A good question. Our current target is our existing clients with lots of scripts that have become a challenge to maintain. Interoperability is another short-term target. The API is also designed to support our ‘big loop’ solution. Here we are in dialog with the main software providers to leverage the API in smaller niche applications. The API will evolve and its footprint will broaden. Today, it is still hard to connect with legacy apps. We bring platform independence, web browser based access (tablet/phone) and support for Resqml, this is very important to us and to some clients.
Back in the day, Roxar’s differentiator was its platform independence and support for Unix…
Yes. A few years ago Windows was very strong. But then came Android, iOS and the iPad. Today, it is important to avoid OS platform lock-in. The cloud is mostly about Linux too so this remains crucial to us. Scripting via the API is an important differentiator.
Will you be sharing the code?
We are thinking along the lines of a community – like the Ocean store or maybe Github.
The Roxar API is a ‘traditional’ API. What is your position on the ‘new’ container-based microservies APIs?
The current API allows us to move in a new strategic direction that remains to be decided. Software has been transformed by mobile and we expect that our world will change too. The API is a first step on the road to SaaS-style business models and enhanced collaboration and will allow us to build the appropriate infrastructure. We don’t even know if our clients will have in-house IT in the future. Maybe there will be a shift to Google/Amazon although not all the infrastructure is in place for this yet. The API has value in the traditional environment. But our focus on the cloud is real, as we showed in Amsterdam.
More on the API from Roxar.
This article originally appeared in Oil IT Journal 2017 Issue # 1.
For more information or to comment on this topic email here.