org-arl / AcousticRayTracers.jl

Differentiable acoustic ray tracers
MIT License
6 stars 0 forks source link

Bellhop–RaySolver differences / comparison #9

Open apatlpo opened 3 years ago

apatlpo commented 3 years ago

Not being an acoustician, it's difficult to grasp whether there are what are the differences between Bellhop and RaySolver physics. Do we expect any?

The documentation states they are similar albeit a 2D vs 2-1/2D difference which I do not understand and would be happy to read any references about.

I gave a try to a direct comparison in deep water with Munk sound speed profile. The full script is found here. I tried to align input parameters for both models but am not 100% sure this was done correctly.

My preliminary observations are that:

You'll find below several figures illustrating the results

Would anybody have ideas in order to explain differences or align results (if this has any sense) ?

bell_vs_ray_ssp

bell_vs_ray_tloss_bell

bell_vs_ray_tloss_ray

bell_vs_ray_rays_bell

bell_vs_ray_rays_ray

bell_vs_ray_arrivals

mchitre commented 3 years ago

You're asking a very good question, but one with a difficult answer. This is the topic of a benchmarking paper that I'm working on, to compare the two models. Details will have to wait for the paper draft to be completed, but I can provide some insights here.

Both Bellhop and RaySolver use the same basic physics. They solve the same equations, but the numerical methods they use are quite different. Hence the differences. Playing around with many of the configurable options within RaySolver will permit a result closer to that of Bellhop, but not exactly the same. And the reason for that is that the Bellhop results for this example aren't quite accurate. Let's take an example to see why:

If you look at the Eigenray plot, you should expect all Eigenrays to pass through the source and the receiver. Bellhop Eigenrays don't do this. Some are actually very far away from the receiver. The main reason for this is that you've selected Gaussian beams, which theoretically have an infinite zone of influence. Gaussian beams are somewhat arbitrary approximations that work well in many practical circumstances, but yield strange results at times. If you turn off Gaussian beams, you'll get the following Eigenray plot:

image

This is much closer to the RaySolver result, but there still are extra rays in there that don't pass through the receiver. This is an artifact of the way Bellhop decides which rays are considered to pass through the receiver, which is different than RaySolver's criterion.

In this particular example, the RaySolver's solution is more accurate. You can see this if you examine the rays:

julia> a_bell
    :
 ∠  0.8°  0↑  0↓ ∠  0.8° | 13333.53 ms | -86.3 dB ϕ   0.0°
 ∠ -0.8°  0↑  0↓ ∠ -0.7° | 13333.56 ms | -88.9 dB ϕ   0.0°
    :
julia> a_ray
    :
 ∠ -0.0°  0↑  0↓ ∠ -0.0° | 13333.33 ms | -82.7 dB ϕ  -0.0°
    :

The transmitter and receiver in this example are at -1300 m depth, which is the minima of the SSP. A ray from the source to receiver at 0° will therefore not undergo any refraction, and so the RaySolver result is correct. Bellhop, in this case, gives you two bracketing rays at ±0.8°, neither of which is a true Eigenray. The ray always experiences 1500 m/s through it's 20 km journey, and so arrives at 13333.33 ms as correctly predicted by RaySolver in this case.

If you change Bellhop to use 101 rays (instead of the 100 you asked it to), you'd get the correct result for the ray angle and arrival time:

∠ -0.0°  0↑  0↓ ∠ -0.0° | 13333.33 ms | -78.6 dB ϕ   0.0°

I'm not claiming here that RaySolver is better, but rather than one needs to be very careful in choosing parameters for both Bellhop and RaySolver when comparing outputs. When simulating specific scenarios, the parameters play a critical role in yielding accurate results.

In the benchmarking paper, I'm trying to develop the appropriate guidelines for RaySolver, as it has a lot more tunable parameters than Bellhop has.

I hope this gives you some sense of why the results don't exactly tally.

mchitre commented 1 year ago

TODO: add a section to documentation to address this question.

For consideration: also include Kraken, PekerisRayModel in comparison.