Figure. 1 GUI Interface
Figure 2
If the program came across any cores that did not satisfy the stability criteria, a warning window will pop up saying which cores did not meet stability criteria and that those cores where not averaged and included in the .csv file that gets uploaded to MUT. In this case, you will need to open the .xlsx file click on the tab for that core and select the data during the orientation period and average it manually, you can then copy and past these cells containing the averaged values into the .csv file for upload to MUT.
The program reads in the orientation data from the .prn file. This data has a time column but for whatever reason, it is not accurate and the difference in time is variable so it cannot be used. The datapoints are assigned a new time based on the time the user enters. This step is similar to what had been done in the past manually. Next, the standpipe pressure files are read in. The program takes all the files that the user selects, converts them into .csv files which python is better able to work with, then combines them into one file. The program then drops all columns except the time column and the pressure column(which the user can specify).
This next step is one of the most useful features of the program in sorting out the data. At the very least, it should make manually processing the data easier. The core summary file is read into the program and the time on deck for each core is extracted from this file. Using the time on deck, the program sets an upper and lower time limit for each core. Any time in between core X’s time on deck and the previous cores’ time on deck must inherently belong to core X. Based on these upper and lower limits, the data points from the orientation files, and the standpipe pressure files are assigned to a core.
This time period can be long depending on how long it took to retrieve the core etc.. Thus, we are not really interested in all of the data in this time period. We want the period that the core is being oriented. The program determines this period in up to 2 ways. First, it looks for stable values in the magnetic tool face (Tool-M) similar to what a user would do manually. To determine stability, the program calculates a rolling standard deviation over a window of 5 readings (50 seconds). If the standard deviation is less than the user specified standard deviation, the program determines this is stable and this is the period of orientation. 5 readings was chosen because if the period is too short, it may select data that just happens to be stable for a couple readings but isn’t within the true orientation window. If the period is too long, the orientation window will appear artificially shortened by the program. This criteria alone is generally accurate in determining the true orientation window but there are occasions where the tool may be sitting still for some reason but not actually orienting a core. If this happens between the upper and lower time limit of a core, the program will assume this data belongs to the orientation window and will include it. This is not desirable but it can be prevented by including the second (optional) method for selecting the orientation window.
The second method for determining the orientation window is using the standpipe pressure files. Standpipe pressure will increase to close to 3000 psi when a core is fired. Prior to firing the core, the core barrel (with the orientation tool) is left stationary for a period of 5 minutes to orient the core. This is the window we are looking for. Because standpipe pressure can be variable and does not always go up to 3000 psi when the core is fired, the program searches for peaks with a prominence of 2000 psi or more. These peaks are when the core has been fired. Because there may be more than one shot for core 1 (if the mudline was missed) the last peak before the core was on deck is selected as the fire time. The program determines that anything 6 minutes before the core is fired up to when the core is fired is the window of orientation. The data must ALSO satisfy the standard deviation criteria during this window. A window of 6 minutes was chosen versus 5 minutes in order to give a buffer window in case survey start time does not match exactly with rig watch time. Just because data is within the 6 minute window does not mean it is automatically included. It must also be stable (i.e. low standard deviation).
The program takes the data that it determines is within the orientation window and calculates the arithmetic mean of the values. This is done for each core that was oriented. Magnetic tool face and azimuth are handled slightly different since they are angles measured from 0-360 degrees. These measurements have the possibility of being off by 180 degrees if the arithmetic mean is calculated. An example of this would be if magnetic tool face values are clustered around 0°. In order to ensure the mean is correct, each angle is converted to its x and y vector components. All the x components are averaged together as are the y components. The average x and y vector component is then converted back to an angle in degrees.
The average from each column is added to a .csv file formatted for upload to MUT. This file is given the same name as the .prn file which was uploaded. This is to ensure all the file names are the same (with the exception of the extension). Any cores which did not satisfy stabilization criteria or that the program otherwise determined were not oriented are not included in this file. The program gives a warning saying which cores are not included.
A second file is also generated and saved to the same file location. This is the .xlsx file which also gets uploaded to MUT (again with the same file name as the .prn file).T his file contains the raw data from the .prn file with the corrected time (similar to what is done manually). The program creates a separate tab (or worksheet) for each core. This tab contains all the data points from both the standpipe files and the orientation data which belong the that core. The series lengths will be different because the standpipe files record every second while the orientation tool records every 10 seconds. A chart is generated plotting Magnetic Tool Face and Magnetic Tool Face standard deviation vs Time (you will need to expand the chart to make it readable). If standpipe pressure files were uploaded, the 6 minute orientation period based on core firing will be plotted on the same chart as steady green line (series value of 1). This chart provides a quick visual deference for how the data looks and can make it easy to identify if something does not look right. The user can also see which rows of orientation data were selected by the program if they use some conditional formatting to highlight rows which have a std less then the specified value AND contain a value of 1 (or any value) in the oriented column. This column contains a value of 1 during the 6 minute window after the core was fired.
Figure 3 .xlsx output graph
Figure 4 .xlsx output graph showing temperature tool
If the user wishes to override the program selected average, they can select the rows which were oriented and average them with an excel formula. This row of averaged values can be copy and pasted into the .csv file for upload to MUT. Keep in mind that azimuth and Magnetic tool face may be 180 degrees off so take a look at these to make sure they are accurate. The user will be required to do this for cores that did not meet the criteria.
A couple of other files will be generated and saved to the temp files folder within the hole directory. These generally should not be needed but may be useful for troubleshooting or sorting out where problems may have originated from. The first of these is an xlsx file with the same name as the files to be uploaded. This file will be identical to the .csv file which gets uploaded to MUT. A .xlsx file is created as an intermediate step in the process. You shouldn’t need this file at all.
There is also a subdirectory called standpipe files. These are files that the program creates as intermediate steps.
Most of these files are pretty redundant and may not be of any use. The majority do not even need to be generated for the program to function. They were invaluable during development to see what was going on behind the scenes and may prove useful for that during use if problems arise. This is why I have left them in.