k-Wave User Forum » Topic: 'Real' directivity

k-Wave User Forum » Topic: 'Real' directivity http://www.k-wave.org/forum/topic/real-directivity Support for the k-Wave MATLAB toolbox en-US Wed, 13 May 2026 00:11:02 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://www.k-wave.org/forum/search.php bencox on "'Real' directivity" http://www.k-wave.org/forum/topic/real-directivity#post-957 Thu, 01 Nov 2012 12:12:40 +0000 bencox 957@http://www.k-wave.org/forum/ Hi Erik, A directivity pattern indicates how a sensor responds to plane waves arriving at different angles. In kspaceFirstOrder2D (but not kspaceFirstOrder3D) we apply directivity patterns by decomposing the pressure field into its constituent plane waves (simply using a 2D FFT) and multiplying the amplitudes of each plane wave by the directivity pattern. So, for example, the directivity pattern associated with spatial averaging across the sensor is <code>sinc(k*element_size/2)</code> where <code>k</code> is the magnitude of the wavevector along the element face. If you define <code>sensor.directivity_pattern = 'pressure';</code> it is this function that is used. You have noticed that it is equivalent to spatial averaging. The other directivity pattern included <code>'gradient'</code> weights the plane waves according to how well they would be detected by a sensor element that detected pressure gradient rather than pressure (for example, the plane waves travelling perpendicular to the sensor face will not be detected at all). In practice, an ultrasound transducer's directivity response will depend on what in the field it is sensitive to (i.e.. pressure, pressure gradient, ...) and how it spatially averages. The details of this are in the function <code>directionalResponse.m</code> in the 'private' folder in the Toolbox (you could add other directional responses here, if you wanted too, even measured ones). The drawback of this approach is that the field at every timestep needs to be multiplied by the directivity pattern before the result is sampled at the sensor points, which makes it slow - especially if different sensor points have different directivity patterns. That's the main reason we haven't added this functionality to the 3D model <code>kspaceFirstOrder3D</code>. By taking the dot product of the velocity vector with a direction vector you are effectively saying your sensor is sensitive to just a single plane wave; no real sensors would be that directional. Hope that helps, Ben styxed on "'Real' directivity" http://www.k-wave.org/forum/topic/real-directivity#post-946 Wed, 31 Oct 2012 17:58:52 +0000 styxed 946@http://www.k-wave.org/forum/ Hello, Thanks for the quick reply. I am working in 2D now. I wasn't aware of the 'ReturnVelocity' option; it indeed gives a neat solution to my problem. This is what I considered directivity. I have to dive a little deeper into the first thing you mention. Because it looks to me that the example which we both mentioned, a) either does spatial averaging by enlarging the sensor element with <code>sensor.directivity_size</code> on both sides, perpendicular to the directivity angle; and then averages over the enlarged sensor element. Or, b) does not seem to be influenced much by the directivity settings. Let me explain on the basis of how I used the example to come to these conclusions: at the visualization part of the initial value problem, add the codelines: <pre><code>% plot pressure distribution over time, sensed by individual elements figure, plot(sensor_data(1:3:16,:)'); grid; break;</code></pre> which plots the pressure felt by 6 of the left elements (1 to 16). With <code>sensor.directivity_pattern = 'pressure';</code> and <code>sensor.directivity_size = 16*kgrid.dx;</code> you can clearly see that the leftmost element sensed the pressure wave 16 pixels earlier than the center element. Which leads me to conclude point a) Without setting <code>sensor.directivity_pattern</code> and <code>sensor.directivity_size</code> (just commenting them out) I would expect to see the same directivity as I did now via multiplying the velocity output with the directivity vector which I did like this: <code>rx_signal = sensor_data.ux.*cos([(-1:1/15:1)*pi/2]') + sensor_data.uy.*sin([(-1:1/15:1)*pi/2]');</code> Instead, in the example I get 6 times the pressure distribution of the initial pressure wave which are almost similar to each other. Can you explain me with this example what ´a directivity pattern which is applied in k-space´ means? ____ In order to compare the two ideas of directivity I wanted to plot the systems next to each other. But somehow in this example I can't run kspaceFirstOrder2D with the 'ReturnVelocity' option when I haven't commented out the directivity entries. I ended up with this: <pre><code>% define the angle of max directivity for each single-element sensor % 0 = max sensitivity in x direction (up/down) % pi/2 or -pi/2 = max sensitivity in y direction (left/right) %sensor.directivity_angle = zeros(Nx,Ny); %sensor.directivity_angle(24,2:2:63) = (-1:1/15:1)*pi/2; % define the directivity pattern %sensor.directivity_pattern = 'pressure'; % define the directivity size %sensor.directivity_size = 16*kgrid.dx; % ========================================================================= % SIMULATION AND VISUALISATION FOR AN INITIAL VALUE PROBLEM % ========================================================================= % define the initial pressure distribution source.p0 = zeros(Nx,Ny); source.p0(39:41,:) = 2; % run the simulation [sensor_data, p_final] = kspaceFirstOrder2D(kgrid, medium, source, sensor, 'PMLAlpha', [2 0], 'ReturnVelocity', true); % calculate 'real' directivity rx_signal = sensor_data.ux.*cos([(-1:1/15:1)*pi/2]') + sensor_data.uy.*sin([(-1:1/15:1)*pi/2]'); % plot pressure distribution over time, sensed by individual elements figure; %subplot(211); plot(sensor_data.p(1:3:16,:)'); grid; % doesn't work subplot(212); plot(rx_signal(1:3:16,:)'); grid; title('real directivity'); break;</code></pre> bencox on "'Real' directivity" http://www.k-wave.org/forum/topic/real-directivity#post-944 Wed, 31 Oct 2012 12:59:09 +0000 bencox 944@http://www.k-wave.org/forum/ Hi Erik, Are you working in 2D or 3D? In 2D an individual element can be assigned a directivity pattern which is applied in k-space (so not spatial averaging in the spatial domain). See<code>Sensor Element Directivity in 2D Example</code>. You could obtain the sort of directional response you describe with a simple post-processing step: set the option 'ReturnVelocity' to be true and the vector particle velocity will be returned. From this you can calculate the component in which ever direction you like using a dot product. (Note that in the forthcoming release the notation for kspaceFirstOrder1D/2D/3D will change slightly to allow you to choose from a variety of outputs more easily.) Ben styxed on "'Real' directivity" http://www.k-wave.org/forum/topic/real-directivity#post-937 Tue, 30 Oct 2012 17:18:10 +0000 styxed 937@http://www.k-wave.org/forum/ Hello, Today I wanted to do simulations on single elements sensors with a specific directionality. I was happy to see that directivity was implemented (Sensor Element Directivity in 2D Example). Only to find out that it was just a big cheat. Sorry, maybe not the correct use of words. I was expecting something else. From the documentation of the example I understood that the 'gradient' and 'pressure' were something additional; which would be useful if you want a spatial averaging function. When I plotted the sensor_data of a single sensor element over time, I realized you increase the sensor element to a set of elements, perpendicular to the directivity angle, with a width of sensor.directivity_size to average over all of those elements. So for example the left element already senses the pressure wave sensor.directivity_size pixels earlier that when the wave is supposed to be on the element. What I expected is what I am now posting as feature request: Directivity in which a sensor output is given by the velocity of the medium in that point (differential of pressure), multiplied (inner product) by the directionality vector of the sensor. (So the inverse of creating a velocity source) Is that possible? Erik