Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”

[Pedro Freire]

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

[admin]

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

[luigiV]

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

Luigi

[Pedro Freire]

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

[admin]

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:

Code: Select all

gpell pedro.model -plot -plot -angle-deg
Reading file 'pedro.model'...
Error computing ellipticity curve (eventually increase verbosity to debug)

which is equivalent to

Code: Select all

gpell pedro.model -plot -min 0.2 -max 20 -step 1.025 -plot -angle-deg -verbosity 2
Reading file 'pedro.model'...
** Warning ** : mode jumping for mode 0 (end), reducing step ratio to 0.00277801
** Warning ** : mode jumping for mode 0 (end), reducing step ratio to 0.000277801
Current precision is too small (1e-15), aborting
Error computing ellipticity curve (eventually increase verbosity to debug)

If you change the sampling and ask for a finer sampling

Code: Select all

gpell pedro.model -plot -min 0.2 -max 20 -step 1.01 -plot -angle-deg
# 1 Rayleigh ellipticity mode(s)
# Mode 0
0.201492470133116 -36.4599245343613
[...]
8.32631075669766 83.9757945867757
8.40957386426464 16.2739758875048
[...]

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:

Code: Select all

gpdc pedro.model 
Reading file 'pedro.model'...
# 1 Rayleigh dispersion mode(s)
# CPU Time=7 ms
# Mode 0
[...]
8.15696423867392 0.00255831603531795
8.36088834464076 0.00256996016122236
8.56991055325678 0.00266667029529002
[...]

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

[luigiV]

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

[admin]

Hi,

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

[Pedro Freire]

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