Tuesday, 14 March 2017

dBSea 2.1

Expanding graphics


Tour of the additional/improved features in dBSea v2.1.

Improved Projection Handling:
dBSea no longer assumes that your imported map is square. For small data sets, and close to the equator this change is doesn't mean much, but as you increase the size of Earth's crust you wish to represent on a flat screen, or are interested in polar regions, the effect is huge. dBSea now finds the central UTM zone of the loaded bathymetry and uses that to project the data.
East-west distances are no longer distorted in dBSea. This makes a real difference for large datasets that cover large areas, especially close to the poles.
If you are working on large scale maps, this tweak should mean that all results now line up with maps exactly, even over long ranges. We still do not take to curvature of the earth into account during propagation calculation, but we agreed during R&D that the lack of curvature wasn't the limiting factor on prediction accuracy (over these long distances lack of accurate environmental data makes models inaccurate to a much higher degree than lack of a curved bathymetry surface).

The UTM zone designation can be somewhat ambiguous, as some just give the general UTM zone number (eg. 29 for Ireland) and then either "S" or "N" to determine Southern or Northern hemisphere. The fuller UTM zone gives more detail, and states how far north or south a given zone is by adding letters A-Z to the UTM zone (Ireland would be UTM 29U). dSBea uses this latter method.
UTM zones of the Earth. Read more on Wikipedia.
This change means that as long as you map is within the 6 degree wide UTM zone distortion is less than 0.1 %. On larger maps the distortion will increase, but as you can see from the picture of Europe at the top of this post, the distortion is much lower than a square approximation.

Image Overlays:
dBSea 2.0 introduced the ability to import ESRI format shapefiles into dBSea to better show areas of interest right in the modelling tool. From version 2.1 you can import JPEGs into dBSea should you wish to add roads, or true terrain and colours to the dBSea map.

Sound Level Contour Shapefiles:
Apart from being able to export exclusion zones, dBSea 2.1 can also export sound level contours as shapefiles.
Simple contour line export from Moray Firth in norther Scotland

We hope that these improvements will make it easier for you to produce better noise maps with less clutter and more focus on the details that matter.

If you wish to try out some of these features, go to dBSea's download page and download the free dBSea Basic, or if you're serious about your noise modelling request a trial licence and a quote for the full version, and get access to the advanced solvers.

As alway - Thanks for reading!



Tuesday, 10 January 2017

Dolphins in Greece

Making models better

We continuously try to improve dBSea, and many of our ideas come from user giving us valuable feedback relating to their uses and needs. 
As part of dBSea 2.0 (available January 31, 2017) we will include wider import and export opportunities to make workflow simpler and better. In this post I'll briefly describe one of these improvements, namely the handling of shapefiles.

For the uninitiated, shapefiles are vector files used to describe points, lines or areas along with their attributes for use in Geographical Information System (GIS). It is common to get shapefiles that are geotagged and designate a particular area of interest, such as a construction site or natural reserve.

I recently posted a video on the subject, so if you're more into listening than reading, have a look below.

As it's wintertime here, and rather cold, I opted for the Aegean Sea between Greece and Turkey, as a setting for this example. The ACCOBAMS project has proposed several Marine Protected Areas (MPA's) in the Aegean Sea, I have plotted three of them in the picture below (Figure 1).
Figure 1. The Aegean Sea. Green dotted line is ferry from Izmir in Turkey to Athens in Greece, red area is exclusion zone from dBSea and yellow areas are proposed Marine Protected Areas.
Areas like these MPA's are often given as areas bounded by a set of coordinates in a .shp, or shapefile format. These shapefiles can now be imported into dBSea and the effects of source level, species weightings and mitigation can be seen directly in relation to zones of interest.
Figure 2. The same scene as in figure 1, but in dBSeas' renderer.
With the option of also exporting shapefiles directly from dBSea, exclusion zones, like the red area/line in the above figures, can be easily integrated into any other map, for later presentation or editing. This new functionality makes GIS integrations like what I did in an earlier post ("There's a real world out there") much easier - especially if GIS work is not your speciality, and you'd just like to get on with it!

And for the ending - I must admit I like the animation tool more than I should.
Figure 3. Animation of the ferry from Izmir to Athens. We have tried to give you more tools to present your work, both directly from dBSea and in conjunction with other software.

Thanks for reading - please feel free to comment and/or ask questions!

Friday, 6 January 2017

On the bottom

What difference rocks make


Sometimes I get asked how important environmental parameters are when predicting underwater noise levels. I will try to give you a small example of what happens if the sediment is not right in the model.

By the bad fortune of an unlucky intern the entire Seabed of the Persian Gulf was turned into rock! Well, if the sound if mostly carried by the water how much of a difference can it make!?

Figure 1. Three scenarios: rocky seabed, mixed seabed and sandy seabed. Red area indicate levels over 110 dB.

The hardness of the rock means that the speed of sound in it is much higher than in the water. Snell's Law tells of about refraction and reflection between two substances with different soundspeed.

Figure 2. Snell's Law

In sand the soundspeed is roughly 1700 m/s, in basalt (what I used above) it's about 5300 m/s and in water I'll use the familiar 1500 m/s.

I will use the first part of Snell's law for this (sin(θ1)/sin(θ2)=v1/v2)
A little fiddling around shows that in the rock situation, if the angle of incident for the sound is more than 16.5 degrees (or 18 %)  from vertical, the sound is reflected by the sediment rock rather than propagating into it (within this "window" ~80 % of the sound is reflected anyway due to impedance differences, see Fig 3.).

This efficiently keeps the sound in a channel formed by the boundaries of the seabed and the water surface, and only lets a minimal amount of energy leak out of it.

For the sandy seabed the corresponding angle is 62 degrees from vertical, meaning that 70 % of incidence angles result in sound transmitted into the sediment (with about 40 % being reflected due to impedance differences)

The below equation can be used to estimate reflection between materials of different impedances.

Figure3. Reflection coefficients can be calculated from this equation.
θ is angle from 90 degrees to plane, ρ is the density and c soundspeed, i & t are incident & transmitted.

The sandy seabed is much more "leaky", and much of the energy propagates into it, and dissipates there, leaving the surroundings quieter.

So seabed is important.

In the center image of Figure 1 (up top), I have placed some rock in the center of the Persian Gulf. In the figure below you can see that there are some dots, these are my fictitious measuring points. All the red points indicate a rock seabed, yellow ones a sandy one.

Figure 4. Red dots are areas of rock (in this example) while yellow dots represent sand. Areas between points are interpolated from a combination of its surrounding points.

Apart from being an example of what a mixed bathymetry can do to modelling results, This option of having different bathymetry at different locations is one of the features in the new dBSea 2.0 - coming out at the end of this month. We are quite excited, and hope you are too.

Figure 5. Animation of exclusion zone with sandy seabed.


As a visualisation feature, we've added animation export for moving sources :)

Remember to know your seabed!

Thanks for reading.


Friday, 16 December 2016

one, one hundred, one thousand or ten thousands?

How many is enough?

One of the algorithms for calculating transmission loss in dBSea is a Ray Tracing algorithm. It shares a lot of functionality with the Bellhop algorithm, but has been optimised a lot both in respect to solving speed and ability. 
A Ray Tracer fundamentally projects rays of sound into the environment, and calculates how each ray interacts, splits, attenuates, refracts and reflects. Every single ray is sent out at a slightly different angle from the source in an attempt to characterise all possible ray paths.
Figure 1. Example of ray paths in presence of a SOFAR channel at 1000m.
Calculating all of this, for thousands of rays can often take hours (literally!), so we sometimes get the question: "How many rays do I really need to use to get good accuracy?".
The answer to this is "It depends".

We're faced with trying to come up with a simple answer to a complex problem, so here goes:

I have attempted to model the change in predicted transmission loss as a function of the number of rays used. I was hoping to see that transmission losses converge and "agree" on a level, and that calculating transmission losses for more rays will not increase the accuracy of the prediction. 

Figure 2. The level at distance from a 200 dB source. Lighter grays represent fewer rays, darker greys represent more rays. The 20*log(range) and 10*log(range) are given for comparison.  
As you might be able to discern from the plot above (Figure 2), the lines seem to be more or less the same distance apart (linear behaviour), but as the increase in number of rays is exponential, chances are that there is a logarithmic relationship at play. Logarithmic functions don't converge, but the do grow very slowly, so we can set some sort of limit on when we're not bothered trading added accuracy for computation time anymore.

From the data in Figure 2 i can model the change in dB-level as a function of number of rays used:

[All those decimals are just for show, exact value 137343^(1/6)]
This above equation results in some information on how much extra computation has to be done to increase accuracy by a little bit.

The above equation is wrong! Logically the results level will converge, but for this specific scenario the best curve fit was a logarithmic model. (I would like to do a whole paper on this if I had a supercomputer in the basement).

At this point I have to add in a disclaimer: This example is valid for this scenario only. It's based on a bit of the north sea at 40-60 metres depth, with a sandy seabed, sea state 0 and well mixed water column (flat sound speed profile).
Figure 3. Computation time vs number of rays and increase in precision/doubling of rays (red).
The red curve is the change in the result for a doubling of rays versus the number of rays used. At 1000 rays your results will change less 10 % (here equivalent to ~2 dB) for doubling the computational effort to 2000 rays. 

Where to draw the line is up to you, and there will be different relationships for different scenarios, but I bet that if you look over your data acquisition, handling and assumptions, it's not ~2 dB from the ray tracing algorithm that's gonna ruin your results.

So to recap and answer how many rays is enough - ... it depends...  😉



Friday, 2 December 2016

Catch you on the flip side (of sound) - Updated!

Particle motion - not all animals are pressure sensors

Update: We have partnered up with GMIT and Irwin Carr to create a PhD funded position on the topic of this blog post. Read more here.

Mammalian ears are pressure sensors, indeed the ears of most animals that spend some time in air are. We sense pressure fluctuations in our environment and our brains translate those to a perception of hearing sound. Our hearing system really is very elegant and interesting (it performs realtime, mechanical Fourier Transforms!), but that isn't really a topic for this blog.

The catch is that to be a good pressure sensor you need to be able to detect pressure. We do this by having lots of compressible air in our middle ear, so that pressure from the outside can make our eardrum vibrate. But everyone who's ever tried to dive knows that having all that compressible air in your head can be a problem!

Many fishes and all invertebrates (as far as I know) do not have any air-filled cavities associated with their ears, so they do not suffer from aural problems when diving. But this lack of air in the ear means that it must be mostly full of water, water that does not like to be compressed. in fact water is over 16,000 times harder to compress than air...

Luckily (for those guys), sound pressure waves travel through fluids by having molecules push each other in an orderly, sequential fashion, see the middle example in the video below. 


video


All the particles oscillate around a fixed point, transmitting the signal/pressure wave by pushing the next particle in line. The two other wave types (left and right in the video) are transverse (shear) waves that only occur in solids, and surface (Rayleigh) waves that occur the surface of solids.

Many of the animals that cannot detect pressure changes very well are adept at picking up certain components of how the particles themselves move in the medium.

This particle component of sound is not understood as well as the pressure component, and with respect to modelling it, we're a little stuck.
Nedelec et al. [2] provides sources for calculating peak particle motion (displacement/velocity/acceleration) from sound pressure, frequency and range from source, but only away from interacting boundaries and under the assumption that the wave is a plane wave i.e. far from the source. So many caveats...
All the following values are peak values; peak particle displacement, peak particle velocity & peak particle acceleration.

Nevertheless I tried to plot the resulting planes in a space given by frequency (1 Hz - 100 kHz) and a large pressure range (0-220 dB re μPa). As much as I like 3D plots, to my surprise, what i found when only looking at the effect of frequency on particle motion surprised me more (Figure 2).
Figure 1. Depicting how Particle motion related to frequency and pressure. "Plane wave limit" refers to the lower frequency limit where an assumption of plane waves applies (80 Hz at 10 m depth over sand). The "Far field lower limit" is a simple assumption that over two wavelengths from the source, the field behaves as in far field. Adapted from equations in [2]
Looking at the same data, but in 2D, it becomes clear that something interesting is going on.
In Figure 2 particle acceleration is constant in the near field (left of red line), but becomes dependent on frequency in the far field (right of red line). For the particle velocity the opposite is true; particle velocity is independent from frequency in the far field - not sure this makes intuitive sense, but otherwise it would be no fun!
Note that in this figure i have included the "Plane wave limit" also. This is the limit (here ~80 Hz) at which we can expect sound waves to propagate approximately as plane waves and we can infer particle motion from pressure and frequency [2] (here at 10 metres depth, sandy seabed).
Figure 2. Same as Figure 1, but only looking at the effect of frequency on particle motion.

Fheew.... ok - so why is this important?

First of all most of the animals that we are concerned about rely on coastal (i.e. shallow) or seabed environments in their life-cycle, and protecting them becomes a lot easier if we have an idea about what they experience. For the above example, we have almost no idea about what the particle motion is doing under 80 Hz if we only measure and/or model pressure waves. Close to the seabed (and in it) we start to see propagation as in the video up top, and that makes modelling hard(er). 

The good people from [1] did lots of measurements of particle velocity in a shipbuilding dock showing that for frequencies below 400 Hz the pressure part of the signal no longer correlate "nicely" with the particle velocity.
This is directly taken from [1] and you should really check it out, they explain it very well!

Thanks for reading!
I hope that I have managed to give you a little bit of insight, and hopefully something to think about.

Graphwork from GNU Octave.

References:

Monday, 21 November 2016

Underwater noise course Belfast

November 17-18th in Belfast saw another run of our UW noise course.
We were happy to have participants from Denmark, England, Finland, Ireland, New Zealand, Portugal and USA. 

On day one we were introduced to a new player in the underwater noise field - the tidal turbines. They are a relatively unknown feature in the underwater soundscape, but as nearby Strangford Lough is a bit of a hotspot for these devices. Two specialists from CASE in Belfast came to show us the current state of the art tidal turbines, some of which they are currently testing.

The remaining of day one was focussed on learning about the issue of underwater noise by approaching the issue from several disciplines. We went over the legislation that largely dictates the content of environmental impact assessments. An introduction to marine fauna followed, with an in-depth look at shortcomings in the current legislation's focus on noise limits that do not alway align with the intent in the legal text or the marine biology.
We do this to facilitate understanding between especially biologists and acousticians. 
In line with the recent move in academia towards a better understanding of the role of particle motion in underwater acoustics, we discussed what impact this has now, and will have on future work in the industry.

The second day was the day of modelling. Everyone got working with dSBea to characterise soundscapes in scenarios that we had prepared or in a site of their choice with their own noise sources.

I want to say a big thank you to the participants contributing with their extensive expertise to the conversation, making it a great learning experience for all of us.

I you want to see some dBSea examples yourself, have a look at dBSea's download page and download dBsea Basic and example scenarios to view them for yourself.

Thank you for reading - if you're interested in our courses e-mail me at: rasmus.pedersen(at)irwincarr.com

Thursday, 22 September 2016

Making it move

When pictures just aren't enough

Admitted, this one was mostly for the fun of it, but like most fun it taught me something useful.

I was at a conference recently, and was rather mesmerised by some of the animations of modelled noise sources. But dBSea does not output animations, so I went the long way and got "Autohotkey", a program that lets you automate repetitive tasks, such as running dBSea's modelling algorithms 90 times over and moving the source in small increments between each image export. 
This process is essentially a batch process (i.e. running similar processes repeatedly), and can be very useful if you wish to run many models while systematically changing the input variables.

The below animation is what I came up with, a boat making it's way into Chesapeake Bay to "Bush Park Camping Resort". Note that the boat is travelling 180 km's in nine seconds (for your viewing pleasure), as the full eighteen hour video was a bit over the top for my laptop.
Boat sailing in through the mouth of Chesapeake Bay
It's important to outline that the results do not differ from using the "Moving source" option in dBSea, but for visual representation this is certainly more eyecatching.
dSBea 2.0 can export animations!


Thank you for reading, please feel free to comment or ask questions below.

Resources:
https://autohotkey.com/
http://www.gebco.net/data_and_products/gridded_bathymetry_data/gebco_30_second_grid/