GeoTeam_GT-150-13_Data Processing Report_Rev01

PROcessinG Is the ART of hOw to Make the Data match Reality...

Data Processing Technical Report

By: Mohamed Metwally

CONFIDENTIAL DOCUMENT

FOR

GEOTEAM OFFICE

GeoTeam | Confidential

Page | 2

Table of Contents

DATA ACQUISITION.............................................................................................................4

TSS VERIFICATION:............................................................................................................... 4

DIGITAL TERRAIN MODEL:......................................................................................................7

DATA PROCESSING............................................................................................................12

NAVIGATION:.................................................................................................................... 12

BLOCKS OVERLAP:.............................................................................................................. 15

SENSORS:..........................................................................................................................16

DIGITIZING THE PIPE:........................................................................................................... 18

FUZZFACTOR:.................................................................................................................... 23

EVENTS:........................................................................................................................... 23

EVENTS IN OVERLAP AREA:....................................................................................................25

OFFLINE PROCESSING LOG:....................................................................................................27

RECOMMENDATIONS........................................................................................................28


Page | 3

Table of Figures

Figure 1 TSS Parameters......................................................................................................6

Figure 2 Pipe tracker depth above DTM in burial area........................................................7

Figure 3 PL#19 Bad DTM......................................................................................................8

Figure 4 PL#21 Bad DTM......................................................................................................9

Figure 5 Kalman filter parameters.....................................................................................13

Figure 6 PL#30 Navigation area need to be removed.........................................................14

Figure 7 overlap points causing bad SD calculations..........................................................16

Figure 8 Interpolate outliers..............................................................................................17

Figure 9 Interpolate points with no data from TSS.............................................................17

Figure 10 save kalman filter as digitized line......................................................................18

Figure 11 pipe tracker filter flexibility settings...................................................................19

Figure 12 Digitized line properties.....................................................................................20

Figure 13 Drape and smooth digitized line.........................................................................21

Figure 14 join digitized lines to be one line........................................................................22

Figure 15 Event KP is alternative for event position...........................................................23

Figure 16 Event position user offset in NE..........................................................................25


Page | 4

Figure 17 Event taken in blocks overlap area.....................................................................26

Data acquisition

TSS Verification:

At the first look of the data I observed that there is difference between the pipe tracker depths and the pipeline crown in the DTM in sections that pipe was exposed and show the pipe crown in DTM.

Prior to commencing the project survey operations, it is normal procedure to conduct an intersystem comparison between the TSS TOP and TOP derived from either DHSS or MBES. This provides the client with proof that the TSS is configured correctly and that the scale factor is valid.

The following steps should be followed when conducting a TSS Verification survey

1. Identify an area of exposed product – approx. 200m 2. Conduct background compensation and seawater check as per

procedure 3. Starting at an altitude of 0.5m fly the ROV along the product for 20m

maintaining a speed of approx 600m/hr 4. Increase the ROV altitude by 0.5m every 20m until the TSS is no

longer able to track the product. 5. Having logged 20m of data where the TSS is unable to track, decrease

the altitude again in 0.5m increments until the ROV is as low as possible.


Page | 5

6. After 20m rise the ROV to optimum survey altitude – dictated by the TSS target scaling report. Log 40m of data at this altitude.

7. The online surveyor should ensure that there is at least 20m of good quality TSS data before stepping the altitude up or down. This may require a distance far in excess of this to be flown

I explained the importance of the TSS verification to the Report Coordinator and he told me that he didn’t conduct this test before and contacted the party chief on phone and he asked me about the procedures of the test, then I explained to them the above mentioned steps for the test

And I had been told that the altimeter of the ROV isn’t working properly and we cannot conduct the TSS Verification test!!!!!

All they doing till my crew change regarding the TSS is the Background Compensation test which is correct but for completely different reasons than the TSS verification, as explained below

In order to tare the TSS system from static noise generated by the vehicle, the online surveyor must conduct a back ground compensation check. This quantifies the amount of background magnetic noise and effectively zeros the system prior to tracking the product.

When encountering different types of products, it is important to understand and predict how the TSS will perform. Failing to account for these differences will undoubtedly lead to incorrect calculation of TOP and could eventually lead to false reporting to the client.


Page | 6

Figure 1 TSS Parameters

Regarding the absence of correct target scaling factor and coils threshold added to the TSS parameters in the ROV surface unit PC, we got a lot of troubles during gathering the data, couple of days before my crew change ROV wasn’t able to detect the pipe because it is going deeper in burial and I told the RC to check the threshold used to detect the pipe and regarding the feedback I got from the ROV pilot they change the threshold used and pipe tracker now gives us better data and detects the pipe deeper than before.


Page | 7

Figure 2 Pipe tracker depth above DTM in burial area

Digital Terrain Model:

Regarding the reasons mentioned in the previous section considering the TSS parameters, the ROV was not able to fly on top of pipe with reasonable altitude to get good coverage from the profilers (swath width) Because they will lose the pipe tracker signal if they try to fly much higher, especially with the absence of visibility making the only solution to depend on the pipe tracker to follow the pipe even when it is exposed.


Page | 8

This low altitude causes a bad influence on the quality of the DVL data and the DTM data regarding the flying objects coming from the seabed because of the ROV thrusters, also if we secure good data from the pipe tracker or DVL it can be useful to use it to remove the swell artifact and get better quality DTM

Figure 3 PL#19 Bad DTM


Page | 9

Figure 4 PL#21 Bad DTM

All sensors offsets values should be recorded in place in the mobilization report and to be up to date with any change, at the start of my trip they were changing the profilers offsets when the ROV maintenance carried out without measuring the new values and apply it in naviscan !!!Making fake relief in the DTM at the meeting point of the data gathered by the old values and the one gathered by new values

Disregarding to conduct alignment test for the profilers even when we relocate the profilers between vehicles (Cougar/Panther)Making problems in DTM especially in roll values and profilers Z offsets as per the mail coming from GeoTeam office suggesting conducting roll calibration test, attached below


Page | 10


Page | 11


Page | 12

Data Processing

Navigation:

Regarding the reasons mentioned above about the DVL data quality it wasn’t applicable to apply DVL on the navigation for all blocks or use it to remove the swell artifact from the data

Every time you apply kalman filter you add some rotation error angle to the navigation because it is always an error angle between the navigation and the Doppler data. So try to apply the filter by using small mean position error value and do it for many file as much as you can unless you haven’t a time gap between the files. If you applied to an individual SBD file so you need to rotate the navigation a bit to be matching the next file that doesn’t have time gap.

Apply good DVL data on the blocks and stop apply it on blocks with bad quality DVL regarding EIVA standard in figure 5 with small main position error value (0.1)

But applying DVL on all single block separately for blocks haven’t a time gap between, using kalman filter suggested parameters with mean position error value (0.4) as the current situation until my crew change isn’t recommended at all for the above mentioned reasons.


Page | 13

Figure 5 Kalman filter parameters


Page | 14

Navigation needs more cleaning especially in the area the ROV struggling due to strong current or recording data during the CP stabs, making loops show up in the navigation need to be deleted from navigation window in NaviEdit, this will delete also these bad scans attached to these points from the DTM and improve the DTM quality

Figure 6 PL#30 Navigation area need to be removed


Page | 15

Blocks Overlap:

There were two ways used to cut the overlap area on board

1. Cut a part from each block at the middle of overlap area keeping 1m of overlap to avoid the gabs in the ROV track, disregarding that this area covered from two blocks and we should check which block containing better data to keep it and cut from the bad one, also it will make troubles if there is online event taken in the overlap area belongs to the deleted part that we cannot find the corresponding event time in the track inside NaviModel.

2. Second way to keep the navigation lines in the overlap area inside NaviEdit as it is and reject the DTM points that we don’t need, and keep 1m DTM overlap inside NaviModel, this way is better but when we start reprocess the pipe in the office data processor should cut these overlaps before smoothing the navigation for all pipe bocks together because these overlap points will be included in the calculations of the standard deviation shifting the pipe position away from reality, and event taken in the overlap area problem will show up again in the final deliverables after cutting the overlap


Page | 16

Figure 7 overlap points causing bad SD calculations

Sensors:

Regarding DVL (Vx/Vy/Vz) and Pipe tracker (X/Z) it is recommended to interpolate the spikes points and points with no data coming from sensor in the sensor window in NaviEdit, regarding the current bad data quality coming from these sensors for the reasons mentioned previously in this report

Create a region around the points, then right click on the region and choose interpolate points option from the menu


Page | 17

Figure 8 Interpolate outliers

Figure 9 Interpolate points with no data fromTSSGeoTeam | Confidential

Page | 18

Digitizing the pipe:

Digitizing the pipe from the DTM when the pipe is buried by using low DTM opacity and following the kalman filter isn’t the best way to do the job, especially when the (80%) of the pipes are buried and sometimes the pipe crown show up in DTM for couple of meters only.Also sometimes this crown isn’t the pipe crown but it is a mattress or a huge anodes (3m /5m) length and the ROV get CP stab on it and the pipe still in burial.

1. import the pipe tracker in the final NaviModel project2. Right click on pipe tracker range and choose save as digitized

line option from the menu.

Figure 10 save kalman filter as digitized line


Page | 19

3. Import the saved digitized line to the project and interpolate it every 1m

No one can predict the pipe movement in burial status better than the kalman filter, but it is recommended to use different pipe tracker settings in NaviModel regarding the pipe diameter and save it in the project templates, because the pipe tracker filter horizontal and vertical flexibility will change regarding the pipe diameter

Figure 11 pipe tracker filter flexibility settings

4. Select the digitized line and in the properties window change the type to pipe, depth alignment to line Z and burial status to Auto


Page | 20

Figure 12Digitized line properties

5. Generate the pipe preliminary to be able to QC the digitized line in vertical from long profile window in NaviModel

6. Digitized line now ready for QC in horizontal and vertical for the areas need horizontal or vertical intervention from the data processor in burial status by deleting the bad points

7. When the pipe is exposed break the digitized line at the start and end point of exposed area by selecting the point you want to break at and then press (SHIFT+DEL)

8. Drop the digitized line in the exposed area to the DTM to get DTM depth

9. Smooth the line with reasonable iteration to be graphically representative well in the long profile window


Page | 21

Figure 13 Drape and smooth digitized line

10. Reconnect the digitized line from both ends after the breakto avoid having a spiky pipe in horizontal or vertical position

11. When the digitized line(s) finished, join the lines to be one line with name of (PL Name_QC)


Page | 22

Figure 14 join digitized lines to be one line

12. Recalculate the pipe and side flags then fly along the pipe for final QC.

Regarding the above mentioned steps to create the digitized pipe,It gives the data processor the advantage to make the intervention needed to produce good product even in the area with no reliable pipe tracker data in burial condition which is deserve to be used regarding the bad TSS data for the previously mentioned reasons.


Page | 23

Fuzz Factor:

Because of bad DTM, sometimes when we drape the cover flags to train, it rest on TOP or go deeper inside the pipe adding fuzz factor calculations to TOP depth when we export it for charting, making fake vertical spikes in the pipe profile created by AutoChart when these spikes doesn’t exist in long profile window in NaviModel, but if we use the digitized line properties in figure 12 to produce the digitized pipe as explained before, this problem will disappear completely.

Events:

Using the online events KPs as a reference to import MariSoft and CP events inside NaviModel regarding marisoft_02 template isn’t recommended at all because the KP column is alternative column for the event position


Page | 24

Figure 15 Event KP is alternative for event position

Online event KP is coming from the raw event position that NaviPac drape it perpendicularly to the run line to get the equivalent (Raw KP), but NaviModel use the event position after moving it to the TOP and drape it perpendicularly to the run line to get the equivalent (Processed KP), TOP position should be the reference position for the deliverables, so that moving the events in NaviModel to be identical to the raw KPs is completely wrong.

It is recommended to use the event raw position as a reference to import events inside NaviModel and moving events to the right event time regarding the ROV track, and then drape it to the TOP,If the event time close to event time in video and the KPs within reasonable difference from raw KPs (2-3m), it is enough to deliver the events to the client.


Page | 25

I surprised that they tried to solve the event problem by deleting the user offset created in NaviEdit for event position used to export the ROV track and change the online setting to push the NaviPac to send event position to NaviScan instead of CRP position!!!!This will shift all sensors position away from reality in Y direction.(Data processing is the art of how to make the data match reality)

Data processor to use the event user offset created in NE as a reference to export the ROV track (*.etr) file to import in the NM final project, especially when we gather the data using the two ROVs (Cougar / Panther ) for the same pipeline, should export the ROV track (*.etr) for blocks gathered by each ROV separately.


Page | 26

Figure 16 Event position user offset in NE

Events in overlap area:

Regarding the two ways using onboard to handle the blocks overlap previously mentioned in blocks overlap section, most of the time NaviModel pick up the time stamp from the wrong ROV track in the overlap area, especially with importing the DNU blocks track to the project to have time stamp for every event when we import the events.


Page | 27

Figure 17 Event taken in blocks overlap area

I changed the criteria of eventing asking the online eventor to take the events in the overlap again in the rerun block, if they decide to rerun this block with overlap area for any reason and the two events to be included in MariSoft event list

Now we have two events for the same object taken in each block of the overlapped blocks, and it is up to the data processor to check which block have better sensors data to keep and delete the bad one keeping 1m of overlap to avoid gaps, and keep the event taken in the used block included in the final event list and delete the event belongs to deleted block.


Page | 28

There is event template created and saved with name (MM) to import events inside NaviModel using the event position as reference instead of KP with all static event data to compare it with the dynamic event data before exporting, and designed to match the last MariSoft event list template approved by RC.

Offline processing log:

I created this sheet before the operation start contains all processing steps sequentially through all EIVA processing modules to control the data overflow through the processing operation and to make any edit on the data during processing documented to improve the cooperation between the data processors especially in daily handover and I think it worth to be up to dated.

There is additional column added to the sheet this trip with name (Vehicle) to trace which ROV used to gather the data block to consider which event user offset will use as a reference to export the ROV track (*.etr) for final NaviModel project.


Page | 29

Recommendations

Conduct a pre shift meeting every day to avoid MIS-communication between the team and improve the cooperation between the different departments.

Conducting TSS verification test to avoid a lot of future problems in the final deliverables as previously explained in this report.

TSS verification to be included in the GeoTeam operation procedures for future projects.

Replacing the profilers with dual head multibeam. Conduct a full alignment test calibration for profilers in issue of reinstall the

profiler frame on the vehicle for any reason. Conduct a roll calibration for profiler in case of moving just one head from

the profiler frame. Profilers offsets to be measured and imported in naviscan after any change ROV to fly gently on TOP during gathering the data at the curved sections

especially at the pipeline ends close to the platform, to give the profilers the ability to cover the pipe curvature without gaps.

Pay more attention for the project documentation update such as mobilization report.

Use different project settings template regarding the different pipe diameters considering the different flexibility for the pipe and the pipe tracker filter regarding the diameter.

No need to import the DNU block track (DNU.etr) to the final NM project regarding the new eventing criteria to avoid pick up the wrong event time stamp as explained previously.

Pay more attention to keep the offline processing log up to date with all processing steps.


Page | 30


Page | 31

Date post:	10-Jan-2017
Category:	Documents
Upload:	mohamed-mohamed
View:	14 times
Download:	0 times

GeoTeam_GT-150-13_Data Processing Report_Rev01

Documents