CIDAI standard 5 : Well log joining
[This standard is only issued as a set of guidelines and is not a mandatory CIDAI standard]
Purpose of joined data
- Joined data is a convenience for all users
- Joined data is used extensively in regional studies but historically only raw data has been traded. Joined data could become a part of the traded data set.
- Joined data is used on quick turnaround projects
- Joined data could be used as the basis for production of Composite Logs
Definition of joined data
Joined data, within the CIDAI context, will be data that relates at least to the seven generic curve types i.e.
Natural gamma ray
Density
Neutron
Sonic
Resistivity
Inclinometry
Caliper
It will be the best valid data and as complete as possible a top to bottom record of the seven curve types. All data should be consistently depth matched, any missing data should be identified and there should be no value judgements made.
There should be a complete record of what was done to the data in an Audit Trail.
Standard
The method in outline should involve :
- Data verification
- Choosing base curve
- Depth match back to base curve
- Depth shift runs to agree with each other
- Recording which curves and depths have been used to join
All of the above should be documented in an Audit trail which should be delivered as a separate ASCII file associated with the joined data.
a. Data verification
Data should be verified for accuracy.
This may involve QC checks between a print and the digits.
The data set should be checked for completeness, any suspected missing data will be identified.
There should be no filtering or environmental corrections performed as part of the joining exercise but it should be recorded in the Audit Trail if any corrections were undertaken prior to joining.
Editing may be required for
- removal of bad data,
- despiking the Sonic,
- in-filling of gaps from repeat sections.
If in-filling is undertaken then the Audit Trail should record the curves used to in-fill together with any relevant comments.
b. Choose base curve
This will involve a value judgement.
The goal is the best possible complete record of well from top to bottom which is easily depth matched between runs and from open hole to cased hole.
c. Depth match
Match all curves of a particular log combination and runs covering the same hole section back to the base curve, where possible.
The depth reference should be that as recorded on base curve. It is necessary to know the datum of the base curve.
To complete these exercises it may be necessary to stretch and squeeze.
d. Depth shift
Match curves covering different hole sections back to the base curve, where log overlap between sections allows this to be done.
The Audit Trail should record joined depths or depth ranges.
Bulk shifting back to base curve of previous run without stretching and squeezing
e. Audit trail
The major purpose of the Audit Trail is to give confidence to the data user.
The Audit Trail should be a separate ASCII file associated with the joined data. This ASCII file will comprise data to identify the author of the joining and the principle processes followed in the joining operations. How the specific data required below is recorded in the ASCII file is left to the discretion of the company undertaking the work.
An initial statement should be made stating :
- Well number
- The company that performed the joining
- The company for whom the joining was performed.
- The name of the individual who did the work.
- Date joined
- Statement of whether the joining was undertaken according to CIDAI guidelines.
- A note of the entire interval covered by the joining process.
Information on the actual joining process should then contain at a minimum.
- A list of which curves are hybrid curves.
- A list of which curves are digitised.
- The base curve chosen and reason for choice.
- The number, dates and depth intervals of the logging runs used in the joining process (to avoid confusion over intervals that have been logged twice).
- A record of any LWD data used in the joining process noting the curves and relevant depth intervals.
- Any data identified to be missing during data verification
- Notes on any editing undertaken, e.g. bad data removed, Sonic despiked, together with the relevant depth intervals
- Any curves where data has been spliced in from repeat sections etc. and the depth intervals over which this occurs. The source of infill data should be specified.
- A statement on how depth matching for each logging run was performed (stretch and squeeze etc.)
- All depths and depth ranges of depth shifting operations
- Details of depth shifting processes utilised.
- A list for each curve of the depth intervals joined to create a single curve and, in the case of hybrid curves, which log curve was used over each depth interval.
Click here to return to Standards menu