help with long GPR profiles

[KaylaCahoon]

Hello and thanks for this wonderful package!

Let me start by saying I'm very new to R and am working with some very rudimentary limitations so if the issue is my code, apologies in advance!

I inherited a massive amount of GPR profiles (~150 lines, ranging from 500 to 2500 m long each) that I'm now trying to post process in RGPR. But some of the profiles are quite long. I'm in the early stages of processing and I think the issue is related to the length of the line. I'm at the DC shift step, and the line is 10036 traces (1985 m). When I tried to use the provided code, I got an error message.

Code:
x1 <- dcshift (x, u = 1:10036)

error:
Error in checkArgStop(msg) : Check arg
arg 'u': must be a vector of strictly positiv integer with max value <= 620.

How do I apply this (and I'm assuming other-) post processing steps on a line that is more than 620 traces long? Is there a way to break up the line and process in chunks then bring it back together? Thanks in advance for your help!

Kayla

[emanuelhuber]

Hello Kayla
Thank you for contacting me.

The solution to your problem is in the error message: u cannot have values larger than 620. That means if you would try u = 1:100 it would work.

Your data contains 10036 traces and each of these traces has 620 samples (you can check that with dim(x)). The function dcshift() estimates for each trace the so-called DC-shift based on the samples defined in the argument u. It takes a trace i, estimates the mean of the u sample of this trace and subtract this mean value from the trace. Normally, you take as samples, the samples before the signal. That means the samples corresponding to the ambient noise.

In the plot below I show you the first 30 ns of a single trace. You see that the signal clearly starts at about 13/14 ns (this is the first wave-break that you will encounter in the time-zero correction processing step). Maybe the signal already starts at 11 ns (there is a kind of "warm-up" before the amplitude decreases drastically). The DC-shift that we want to remove is indicated by the green horizontal line and was estimated using the mean of the first 13 samples, that are indicated by red dots. So here for this data, I would do:

x1 <- dcshift (x, u = 1:13)

The DC-shift is here very small. Note that it may vary from trace to trace. Note that you simply define which samples has to be used to estimate the DC-shift.

Advice for large data

The current version of RGPR may be slow. I recommend you to work on a sub-sample of your data to experiment processing and find the best processing parameters. Then you can apply these parameters to the full data. If the data were collected within the same survey, you can test the processing on one data and then apply the processing to the other data (see the online tutorial here: https://emanuelhuber.github.io/RGPR/04_RGPR_tutorial_GPR-data-survey/#processing-save-and-pdf-export).

Use the plotFast() function that is faster than the plot() function (but offers less options).

Do not hesitate to contact me if you have any question!

Best,

Emanuel

[KaylaCahoon]

Thanks so much for the quick response! I really appreciate it. I think I have resolved the issue with the DC shift, but have now moved on the an issue with the time 0 correction. It appears that in my GPR profiles, the first wave break occurs at 0.

But I know that there is a gap between the top of the trace and the first wave break.

When I try to remove that gap using the code:
time0Cor(y, t0 = NULL, method = c("pchip"), crop = TRUE, track = TRUE)

I get an error message that says:
In time0Cor(y, t0 = NULL, method = c("pchip"), crop = TRUE, track = TRUE) :
Nothing shifted because all 'ts' values are equal to zero!

I attempted to correct ts values using the command "ts <- -time0 (y) +keep" as is suggested in the help dialog, but this didn't work because "keep" doesn't exist anymore. I also tried to manually set ts to t0 (in my case -6.35), and again got the same error.

ts <- -6.354515
time0Cor(y, t0 = ts, method = c("pchip"), crop = TRUE, track = TRUE)

In time0Cor(y, t0 = ts, method = c("pchip"), crop = TRUE, track = TRUE) :
Nothing shifted because all 'ts' values are equal to zero!

How do I manipulate ts so the time 0 correction will work? I did this successfully with the sample dataset in the tutorial, but on my actual data it's not working.

[emanuelhuber]

Before you try to correct for time-zero, you must ensure that you estimate a reliable time-zero.
To estimate time-zero, you first estimate the first wave break time. Your first plot show clearly that the first wave break time was wrongly estimated. According to your second plot, the first wave break time should be around 16 ns... note that the first wave break time is positive.

You can try to adjust the argument of the function firstBreak(), taking carte that ns must be larger than w (w is the width in time unit of the leading window... check the help and you will find the reference to the paper with the Coppens method, you can find the PDF freely on the web).

tfb <- firstBreak(A1, w = 7, method = "coppens", ns = 15, bet = 10)

Just try to vary the arguments. Alternatively, you can choose manually the first wave break time (or interactively with the function locator() and then clicking on the plot where the first wave break occurs and then pressing esc or clicking on finish in the top-right in Rstudio).

Now that you have the first wave break time, you must account for the travel time of the wave through the air from the emitting antenna to the receiving antenna. This time is "antenna separation"/"wave speed".

You can use the convenient function:

t0 <- firstBreakToTime0(tfb, x)  

where x is your GPR data.

Then I recommend you to take a mean value of t0 since it should not vary along a GPR profile.

Then you set time-zero:

time0(x) <- mean(t0)   # here I take the mean  

Then you can convert shift the traces to time-zero (time-zero is positive):

x2<- time0Cor(x, method = "pchip")

Does it help you?

Best,

Emanuel

[KaylaCahoon]

This batch of code worked! I did play around with the arguments a bit to get it right, but I think I've found the parameters that work for this batch of data. Thanks so much for responding to me so timely and thoroughly. I think I have everything figured out for the baseline GPR processing. Thanks again! You've been super helpful.

Kayla

Kayla

[emanuelhuber]

Hello Kayla

Great! Thank you for your feedback.
Do not hesitate to contact me if you have any question or if you need some specific functionalities or if you have to recommendation to improve the user experience!

Best,

Emanuel