I am a reservoir engineer with a number of years experience building reservoir simulation models in a large corporate environment. The models have ranged from simple to complex, and have been used for a variety of purposes from optimizing injection patterns and picking development locations to helping to justify major capital expense projects.
One of the problems of a working reservoir engineer is that you are always busy trying to get the trash out, and never have enough time to think more clearly about how to do the job better. I am currently free of organizational encumberances, which means I have time to pursue interesting projects, but with limited resources to pursue them. This makes working on open source tools an obvious choice, but expense is certainly not the only reason.
Oil companies often closely guard their internal software in a mistaken understanding of which parts of the business actually add value (probably because they have hired too many attorneys). Large projects always have partners, and the primary goal is always to get both internal and partner support for a project. Proprietary software is usually a hinderance, because each of the partners has a different view of the issues and problems. A transparent work process powered with open source tools provides a better path for both reaching agreement, and for each of the partners to add their particular expertise in a way that can make the project move forward more efficiently and quickly.
The software tools which I have started working on are intended to provide an open source computer assisted methodolgy for history matching a reservoir simulation model. In addition they are intended to support an open workflow to allow transparent collaboration among partners towards reaching understanding and agreement.
How should time be apportioned between developing, documenting and thinking? The process of building a history matching workflow, taking advantage of existing tools, will require learning more about numerous modeling related subjects. Creating tools will require learning more about programming in general, and R in particular. Some C/C++/Fortran work may also be necessary when, performance becomes a problem. My background and experience have been more as a user than as a developer. Documenting the work as it proceeds will probably make progress slower, but will force clearer thinking. Hopefully, this will result in a better product.
Documentation is a multilevel problem/opportunity. The lowest level is to document functions as they are being developed Using ROxygen eases this process to allow standard R Style help files to be quickly and easily generated. The next level is to document workflows. This will be an iterative process during tool creation using RMarkdown, and will be in the form of R Vignettes. The highest level will be documentation of the research, thought processes, experimentation and problems during tool development. That is the purpose of this blog.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.