search

A-New-BellHope / bellhopcuda

CUDA and C++ port of BELLHOP / BELLHOP3D underwater acoustics simulator
GNU General Public License v3.0
60 stars 7 forks source link

arrival anomaly #28

Open oldstylejoe opened 5 months ago

oldstylejoe commented 5 months ago

First reported by Denton Woods on email: I was doing a very simple isospeed profile run where the source and receivers were at the same depth, with the receivers just marching out in range in 10 cm increments. I was only looking at the direct path entries, thus multiplying the delay variable by c should always equal the range. Most of the time, that is true, but for some entries, they do not match up. In fact, for those bad entries, they will be 10 cm farther. So instead of seeing values for c*t of 10.0, 10.1, 10.2, 10.3, etc., I would see something like 10.0 10.1, 10.3, 10.3. Out of curiosity, I checked out the commit (ca51464ba5502c6ee0a50c03e565dabda5ddc910) before pull request #26 was merged in, and that fixed the issue. I can send you my .env file if that would be helpful.

DentonW commented 5 months ago

I have attached the .env file here and the results of running the latest and prior commits: Bellhop-Eigenray.env.txt BellhopCxx-Eigenray.arr.txt BellhopCxx-Older-Eigenray.arr.txt

Since the direct path arrivals are easier to interpret and verify, I pulled those out of both arrival files: BellhopCxx-DirectPath.txt BellhopCxx-Older-DirectPath.txt

You can see that in BellhopCxx-DirectPath.txt, it has the time (7.99999980E-04 s) repeated on lines 13 and 14 for two different receiver ranges. There are other examples of this happening in the file, along with an NAN on line 47. The prior commit has correct values.

oldstylejoe commented 5 months ago

@DentonW I pushed a version to the DirectPath branch that fixes this issue. When bellhop finds a given ray segment that influences a receiver, bellhop linearly interpolates between the two ends of the segment to calculate things like delay time. The interpolation has a typo in the OAlib implementation that we faithfully copied over to bhc. When a user pointed it out, I then fixed wrong as you caught, sigh. The math is correct now so the delays should work as expected (great test, btw). This is reopening problems with the interpolation going haywire in 3D, but that's a different issue. Could you please verify that your issue is fixed?