There are a variety of ways to try to resolve boundary conditions; it's a problem you need to deal with whether you are doing direct convolution or FFT-based convolution. Unfortunately, it's not clear exactly what your difficulty is (your graphs don't have enough context for me to tell where they come from or what they mean); in the following, I will have to guess.

The thing you need to need to remember about FFT-based convolution is that it treats its input as a periodic loop. Your question mentions a problem that "does not arise if we directly integrate to find convolution"; that difference is probably due to this property.

You claim that "the zero padding is responsible for the undesired boundary effects". However, in order for fftconvolve() to match the results of direct convolution, you must ensure that there is sufficient zero padding added to the original data to keep the periodic nature of the FFT from interfering with the convolution. For this purpose, I believe that "sufficient zero padding" should be length of the filter you are convolving with. Try splitting the zero padding for your fftconvolve() evenly between the beginning and end of your data run.

If you are unsatisfied with the boundary effects of your direct convolution, I'm not sure what to tell you, since I don't know what your application is. I will advise that the result of your convolution will be as long as the original data plus the length of the filter, so you will need to provide for that.

There are a variety of ways to try to resolve boundary conditions; it's a problem you need to deal with whether you are doing direct convolution or FFT-based convolution. Unfortunately, it's not clear exactly what your difficulty is (your graphs don't have enough context for me to tell where they come from or what they mean); in the following, I will have to guess.

The thing you need to need to remember about FFT-based convolution is that it treats its input as a periodic loop. Your question mentions a problem that "does not arise if we directly integrate to find convolution"; that difference is probably due to this property.

You claim that "the zero padding is responsible for the undesired boundary effects". However, in order for FFT convolution to match the results of direct convolution, you must ensure that there is sufficient zero padding added to the original data to keep the periodic nature of the FFT from interfering with the convolution. For this purpose, I believe that "sufficient zero padding" should be length of the filter you are convolving with. Try splitting the zero padding for your fftconvolve() evenly between the beginning and end of your data run.

If you are unsatisfied with the boundary effects of your direct convolution, I'm not sure what to tell you, since I don't know what your application is. I will advise that the result of your convolution will be as long as the original data plus the length of the filter, so you will need to provide for that.

There are a variety of ways to try to resolve boundary conditions; it's a problem you need to deal with whether you are doing direct convolution or FFT-based convolution. Unfortunately, it's not clear exactly what your difficulty is (your graphs don't have enough context for me to tell where they come from or what they mean); in the following, I will have to guess.

The thing you need to need to remember about FFT-based convolution is that it treats its input as a periodic loop. Your question mentions a problem that "does not arise if we directly integrate to find convolution"; that difference is probably due to this property.

You claim that "the zero padding is responsible for the undesired boundary effects". However, in order for fftconvolve() to match the results of direct convolution, you must ensure that there is sufficient zero padding added to the original data to keep the periodic nature of the FFT from interfering with the convolution. For this purpose, I believe that "sufficient zero padding" should be the full effective width of the Gaussian you are convolving with (although, since the Gaussian technically has unbounded support, you will still need to decide how wide that "effective" width is...). Try splitting the zero padding for your fftconvolve() evenly between the beginning and end of your data run.

If you are unsatisfied with the boundary effects of your direct convolution, I'm not sure what to tell you, since I don't know what your application is. I will advise that the result of your convolution will always be wider than the original data, so you will need to provide for that.

There are a variety of ways to try to resolve boundary conditions; it's a problem you need to deal with whether you are doing direct convolution or FFT-based convolution. Unfortunately, it's not clear exactly what your difficulty is (your graphs don't have enough context for me to tell where they come from or what they mean); in the following, I will have to guess.

The thing you need to need to remember about FFT-based convolution is that it treats its input as a periodic loop. Your question mentions a problem that "does not arise if we directly integrate to find convolution"; that difference is probably due to this property.

You claim that "the zero padding is responsible for the undesired boundary effects". However, in order for fftconvolve() to match the results of direct convolution, you must ensure that there is sufficient zero padding added to the original data to keep the periodic nature of the FFT from interfering with the convolution. For this purpose, I believe that "sufficient zero padding" should be length of the filter you are convolving with. Try splitting the zero padding for your fftconvolve() evenly between the beginning and end of your data run.

If you are unsatisfied with the boundary effects of your direct convolution, I'm not sure what to tell you, since I don't know what your application is. I will advise that the result of your convolution will be as long as the original data plus the length of the filter, so you will need to provide for that.