groupeLIAMG/ttcr

bug report [WinError 10054]

cumttc opened this issue · 2 comments

cumttc commented

python version:3.11.3 ttcrpy version:1.2.1 numpy:1.24.3 scipy: 1.10.1

src: 50 3D coordinates ,rcv: 50 3D coordinates
They are both generated in the following way:
src = np.array([[4356.383252, 1003.381716, 500.0514687].
[4356.383252, 1003.381716, 500.0514687].
................. ,])
xmin, xmax = 4200.00, 4600.00
ymin, ymax = 600.00, 1200.00
zmin, zmax = 500.00, 1000.00
#Gridding parameters
XGridlength = 25.0
YGridlength = 40.0
ZGridlength = 50.0
x = np.arange(xmin, xmax, XGridlength)
y = np.arange(ymin, ymax, YGridlength)
z = np.arange(zmin, zmax, ZGridlength)
#grid
grid = rg.Grid3d(x, y, z, cell_slowness=False, method='SPM',n_threads=12)

I made sure I entered the slowness correctly
The problematic line of code is as follows:
tt, rays = grid.raytrace(src, rcv, return_rays=True)
I encounter a warning message: [WinError 10054] The remote host forced an existing connection to close.

Additionally, if I attempt to solve only for the time-to-parameter (tt) using the following line of code:
tt = grid.raytrace(src, rcv)
I encounter a warning message:
"This evaluation is really slow and this is expected. In this case, it's possible to silence this error by raising the timeout, setting the PYDEVD_WARN_EVALUATION_TIMEOUT environment variable to a bigger value.

  • The evaluation may need other threads running while it's running. In this case, it's possible to set the PYDEVD_UNBLOCK_THREADS_TIMEOUT environment variable so that if after a given timeout an evaluation doesn't finish, other threads are unblocked, or you can manually resume all threads."
    Thank you for reading

Sorry for the delay, I'm currently traveling.

I have never seen these messages, but I work with macOS. Would you share your slowness model, src & rcv so I could test it on my machine?

cumttc commented

Dear Professor,

That's great to hear, and I also just finished my Dragon Boat Festival holiday.

I'm glad to inform you that the issue has been resolved. It seems that the problem arose from using meters as the coordinate unit, while the common unit is kilometers (km). This resulted in excessively large values for 'scv' and 'rcv' (reaching thousands), leading to computational difficulties.