Learnings from Over 5 Years of Design, Implementation, and Analysis of the Modified Flowback DFIT, DFIT-FBA
Bibliographic record
Abstract
Abstract The diagnostic fracture injection test (DFIT’) has become a standard well-test method applied to obtain critical information (e.g., minimum in-situ stress, reservoir pressure and permeability, etc.) for the evaluation of low-permeability (‘unconventional’) reservoirs. In modern applications, DFITs are commonly performed at the toe of horizontal wells. The conventional (pump-in/shut-in) DFIT involves pumping into the well at high pressure to create and propagate a small hydraulic fracture, and then shutting in the well with the resulting pressure falloff evaluated using pressure-transient analysis (PTA) approaches to obtain the various parameters of interest. However, extensive test times (days, weeks, or even months) may be required to acquire information such as reservoir pressure. As an alternative, a modified version of a flowback DFIT, referred to as ‘DFIT-FBA’ (where FBA = flowback analysis), was recently introduced to accelerate information obtained from a DFIT. After the pump-in stage, a brief shut-in (~ 5 minutes) is followed by flowback of the well at a (rule-of-thumb) initial flowback rate of 2-5% of the injection rate for (typically) 2-4 hours. Recent studies have suggested that, with properly designed, implemented, and analyzed DFIT-FBA tests, all of the same information can be obtained as a conventional DFIT, but in a fraction of the time. This time savings has created new opportunities for DFIT applications (e.g., multiple along-well tests performed in a day) that were not previously practical with a conventional DFIT. However, DFIT-FBA is a relatively new method (introduced in 2019), with over 300 tests being performed to date, and continuous improvements are being made. The objective of this paper is to share the learnings from over 5 years of design, implementation, and analysis of DFIT-FBA in the field, with an emphasis on analysis. To achieve this, the theoretical background for DFIT-FBA interpretation developed by the authors, which is rooted in rate-transient analysis (RTA), is reviewed, and the practical application of a DFIT-FBA analysis workflow is demonstrated using simulated and field cases. For completeness and comparison purposes, the conventional DFIT (PTA-based) workflow is demonstrated using conventional DFIT simulated and field cases. The conventional DFIT workflow is also applied to field cases of the precursor to DFIT-FBA, the ultra-low flowback rate (<0.1% of injection rate) DFIT, where the influence of flowback rate on the analysis is ignored. The primary findings from the analysis of DFIT-FBA are as follows: Flowback rates must be measured to 1) correct for near-wellbore tortuosity (particularly important for horizontal wells) and perforation friction – failure to do so will result in an under-estimate of minimum in-situ stress; 2) identify flow regimes (using a log-log plot of rate-normalized pressure, and its derivative with respect to the natural log of material balance time, versus material balance time), and estimate pore pressure using the flow-regime identification plot; and 3) perform before-closure straight-line (rate-transient) analysis to obtain permeabilityApplication of conventional DFIT (PTA-based) analysis approaches, which ignore the effect of flowback rates, consequently result in significant errors in critical parameter determination; for example, application of this approach to the simulated DFIT-FBA example results in a permeability estimate that is approximately two orders of magnitude different from the simulator input valuePore pressure estimation from the flowback portion of DFIT-FBA test is currently the most uncertain aspect of test interpretation; it is recommended that select DFIT-FBA tests are followed by shut-in (rebound) tests to obtain an independent estimate of reservoir pressure It is hoped that the findings of this study can be used by operators to increase the chance of obtaining successful test results. While DFIT-FBA is showing much promise as a new well-testing method, there are improvements that can be made in test design, implementation, and analysis.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.011 | 0.011 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.003 | 0.003 |
| Open science | 0.004 | 0.002 |
| Research integrity | 0.001 | 0.003 |
| Insufficient payload (model declined to judge) | 0.006 | 0.004 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".