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.
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.