You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
(ca51464) before pull request #26 was
merged in, and that fixed the issue. I can send you my .env file if that
would be helpful.
The text was updated successfully, but these errors were encountered:
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.
@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?
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
(ca51464) before pull request #26 was
merged in, and that fixed the issue. I can send you my .env file if that
would be helpful.
The text was updated successfully, but these errors were encountered: