Technology Focus: Simulation (July 2019)

Technology Focus The original realm of this Technology Focus was reservoir simulation, but the scope has been expanded to include all simulation. This is, indeed, a broad sweep, and I fear that I may not be able to do full justice to technical domains in which I am not fully conversant. Nonetheless, muddling through, I have selected three papers with reasonably broad coverage. The one I particularly like describes an open-source 3D-printing micromodel tool kit. This highlights the need to validate simulation through experimental observation, and the work provides a practical means to do so. This will be my last editorial (it has been 6 years now), and I leave you with two main thoughts, one positive and one less so. My optimistic remark concerns the advances I have observed in the field of simulation of complex reservoirs, especially fracturing of tight reservoirs. While the topic remains challenging, the advances made have been quite significant over the past 5 years. Nonetheless, in my view, we still do not possess a full understanding of oil production in unconventional fractured reservoirs. Our ability to forecast such assets remains elusive, even with copious amounts of analytics, mountains of data, and an arsenal of machine-learning tools. We still cannot ascribe the level of confidence to such assets as we wish would be possible. More fundamental experimental investigation is necessary here, and, while we are gradually increasing our understanding, the journey has some way to go. My final comment concerns buttons. Specifically, I refer to these so-called big green “simulate” buttons: the ones that entice a user to blindly “press it, and for-get it” (with apologies to Ron Popeil). Well-crafted, user-experience-optimized, appealingly designed interfaces are now standard. Nothing new in that. Nonetheless, I cannot help but feel that, rather than assisting the engineer, such interfaces form a metaphorical barrier between the user and the simulation engine. I am of the generation that was quite happy navigating large keyword-driven ASCII files with the “vi” editor (remember that?). While these were awkward, slow, and often excruciatingly painful to operate, being forced to work directly with keywords and ASCII files yields one very significant advantage: an unavoidable and direct connection with the data. One had no choice but to become acquainted with all aspects of an important keyword and its input requirements. This ensured consistency of data input and facilitated a closer bond between user and simulator (greater transparency of what was going on under the hood). Being unashamedly old school, I feel that “optimized user-interface (UI) dashboards” often cast a misty veil over human/machine connectedness and sometimes may even impede the pathway to understanding of simulation behavior and the solution itself. My point here is this: Do not hesitate to dive into the files typically generated by these UIs and be unafraid to be old school, even if only for a few moments. The insight this affords is well worth the effort. Saying this, I am clearly showing my age, so it’s time for a fresh face to take over this editorial. I thank you for your patience over the past few years. Meanwhile, I feel an overwhelming urge to write another technical paper (that no one will read), written in TeX and coded in FORTRAN77, using my trusty “vi” editor—happiness awaits. Recommended additional reading at OnePetro: www.onepetro.org. SPE 191213 Application of Memory Formalism and Fractional Derivative in Reservoir Simulation by Mahamudul Hashan, Memorial University of Newfoundland, et al. SPE 193880 A Massively Parallel Algebraic Multiscale Solver for Reservoir Simulation on the GPU Architecture by A.M. Manea, Saudi Aramco, et al. SPE 193844 A Bayesian Sampling Framework With Seismic Priors for Data Assimilation and Uncertainty Quantification by Siavash Nejadi, University of Calgary, et al.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.