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
Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”

 Posts: 6
 Joined: Thu May 27, 2021 10:36 am
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
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
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
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
Sorry Marc,
out of curiosity I tried it too and I had a positive run.
Luigi
out of curiosity I tried it too and I had a positive run.
Luigi

 Posts: 6
 Joined: Thu May 27, 2021 10:36 am
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
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
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
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
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 1e7. When there is also an ellipticity to compute, it is dropped to 1e10. In gpell, the precision is even lower: 1e13. 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 64bit float.
A work around would be to introduce a user adjustable precision and to set a default precision of 1e10 even for gpell. I implemented it in 3.4.3preview.
Best regards,
Marc
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 angledeg
Reading file 'pedro.model'...
Error computing ellipticity curve (eventually increase verbosity to debug)
Code: Select all
gpell pedro.model plot min 0.2 max 20 step 1.025 plot angledeg 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 (1e15), aborting
Error computing ellipticity curve (eventually increase verbosity to debug)
Code: Select all
gpell pedro.model plot min 0.2 max 20 step 1.01 plot angledeg
# 1 Rayleigh ellipticity mode(s)
# Mode 0
0.201492470133116 36.4599245343613
[...]
8.32631075669766 83.9757945867757
8.40957386426464 16.2739758875048
[...]
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
[...]
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 1e7. When there is also an ellipticity to compute, it is dropped to 1e10. In gpell, the precision is even lower: 1e13. 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 64bit float.
A work around would be to introduce a user adjustable precision and to set a default precision of 1e10 even for gpell. I implemented it in 3.4.3preview.
Best regards,
Marc
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
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
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
 Attachments

 ell+disp.page
 (27.21 KiB) Downloaded 301 times

 osculation.jpg
 (46.47 KiB) Not downloaded yet
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
Hi,
I worked only the first model provided by Pedro (3 layers). Effectively the 4 layer model has an osculation point around 5 Hz.
I worked only the first model provided by Pedro (3 layers). Effectively the 4 layer model has an osculation point around 5 Hz.

 Posts: 6
 Joined: Thu May 27, 2021 10:36 am
Re: Gpell Error: "Error computing ellipticity curve (eventually increase verbosity to debug)”
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
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