geopsy.org

Hello!
I am using Gpell to create ellipticity curves with models of 3 layers.
When I input a text file with over 10 000 combinations,I get an error in the combination number 2758, in which the parameters are :

3
3 280 163 2100
7 700 211 2100
0 850 521 2100

I receive the following answer : ': “Error computing ellipticity curve (eventually increase verbosity to debug)”.

The poison coefficient of each layer is :

0.243
0.45
0.2

Do you know why does this error happen and how can I avoid it when creating the input files?

Thank you very much for your work,
Any help is really appreciated

Hi Pedro,

I've just checked gpell with your model but I got a correct run without error. What are the options you are passing to gpell?

Best regards,

Marc

Sorry Marc,
out of curiosity I tried it too and I had a positive run.

Luigi

Hi Marc and Luigi
Thank you for your repply!
I am very sorry.
I typed the wrong parameters in the previous post. I also had a positive run with those.
The actual parameters are :

3
3 330 163 2100
7 700 211 2100
0 850 521 2100


The poison coefficient of each layer is :
0.3386
0.45
0.2

To avoid this error I tried to fix de poison coefficient to a single value(0.3).
In another run of 20 000+ combinations I obtained the same error in a 4 layered model with the following parameters:

4
12 280.624304 150 2100
10 935.4143467 500 2100
2 1216.038651 650 2100
0 1122.497216 600 2100


I didn't change any settings on the gpell so I must be using the default ones.

Best regards,
Pedro Freire

Hi Pedro,

This is the case of a difficult osculation point. In the attached figures, you can see that the fundamental mode is very close to the first higher mode. However if you zoom, you can see that the two curves are separated. If you run: which is equivalent to If you change the sampling and ask for a finer sampling In the last case, it is fine, you get the curve. You can see that the sampling is jumping over the osculation point. By chance, it avoids it. With the default sampling with a step of 1.025: With this default step, we are not lucky enough and there is one sample right in the middle of the osculation point. I also check by forcing the removal of samples between 8.32 and 8.4 in the code. It works for any kind of sampling, hence it confirms that it is the problematic frequency range. If you are computing manually, it is possible to adapt yourself: do the computation below the osculation point and above separately. If you are running an inversion with almost blind computations, this is an annoying situation.

As I wrote in my thesis some twenty years ago (p. 63), to compute an ellipticity the error on the dispersion curve must not exceed a certain threshold. The ellipticity computation requires first the dispersion curve. The default precision for a dispersion curve is 1e-7. When there is also an ellipticity to compute, it is dropped to 1e-10. In gpell, the precision is even lower: 1e-13. It works in most case and provides sufficient precision at high frequency. In this case, the imposed higher precision leads over the arithmetic precision limits of 64-bit float.

A work around would be to introduce a user adjustable precision and to set a default precision of 1e-10 even for gpell. I implemented it in 3.4.3-preview.

Best regards,

Marc

Hi Marc,
could you please clarify me why you defined the osculation point at about 8Hz?
Calculating the dispersion curves for the Pedro.model it turns out to me that the osculation point is close to 5Hz (see images) ...
What am I doing wrong?

Thanks
Luigi

Hi,

I worked only the first model provided by Pedro (3 layers). Effectively the 4 layer model has an osculation point around 5 Hz.

Marc,

Thank you so much for your kind answer. Really appreciate your work.
I did a simple Matlab program to rewrite the input when an error happens, detecting the one that cause the error and deleting it. It is a little bit slow but it works for me, it allows me to try large amounts of combinations.
If anyone needs this code, please feel free to ask me. My email is pedro.b.freire@tecnico.ulisboa.pt.

Best regards,
Pedro Freire