<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="bbPress/1.0.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>k-Wave User Forum &#187; Topic: Save only uz_non_staggered</title>
		<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered</link>
		<description>Support for the k-Wave MATLAB toolbox</description>
		<language>en-US</language>
		<pubDate>Tue, 12 May 2026 23:28:59 +0000</pubDate>
		<generator>http://bbpress.org/?v=1.0.2</generator>
		<textInput>
			<title><![CDATA[Search]]></title>
			<description><![CDATA[Search all topics from these forums.]]></description>
			<name>q</name>
			<link>http://www.k-wave.org/forum/search.php</link>
		</textInput>
		<atom:link href="http://www.k-wave.org/forum/rss/topic/save-only-uz_non_staggered" rel="self" type="application/rss+xml" />

		<item>
			<title>Bradley Treeby on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4989</link>
			<pubDate>Thu, 19 Feb 2015 19:41:46 +0000</pubDate>
			<dc:creator>Bradley Treeby</dc:creator>
			<guid isPermaLink="false">4989@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;Hi Anthony,&#60;/p&#62;
&#60;p&#62;Yes we did consider this for the calculation of I_avg or Q for CW fields. It would involve the user having to define the length of the acoustic period over which to average, and preferably defining the time discretisation to use an integer number of points per period. However, it would save a lot of memory as you say. Any other suggestions most welcome!&#60;/p&#62;
&#60;p&#62;Brad.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>Anthony on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4980</link>
			<pubDate>Thu, 05 Feb 2015 09:07:09 +0000</pubDate>
			<dc:creator>Anthony</dc:creator>
			<guid isPermaLink="false">4980@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;Hi Brad,&#60;/p&#62;
&#60;p&#62;Thanks for this important remark (and the pointer to the kspaceFirstOrder_saveIntensity.m function) :-) By the way, I hadn't seen it anywhere in the doc, maybe it would be worth adding it or mentioning it in the release notes, where you speak about &#34;the additional input options&#34;.&#60;/p&#62;
&#60;p&#62;If you want to perform only heat deposition calculation, maybe you could only unstagger the last period as you basically only want to have a mean deposited power over one period. It would save a lot of memory...&#60;/p&#62;
&#60;p&#62;Anthony
&#60;/p&#62;</description>
		</item>
		<item>
			<title>Bradley Treeby on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4979</link>
			<pubDate>Thu, 05 Feb 2015 00:07:33 +0000</pubDate>
			<dc:creator>Bradley Treeby</dc:creator>
			<guid isPermaLink="false">4979@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;Hi Anthony,&#60;/p&#62;
&#60;p&#62;You are correct - the output &#60;code&#62;&#38;#39;u_non_staggered&#38;#39;&#60;/code&#62; is only non-staggered in space, it is still staggered in time. To calculate intensity within the MATLAB code, this is then passed to the &#60;code&#62;timeShift&#60;/code&#62; function before being multiplied by the pressure. You can take a look inside the private function &#60;code&#62;kspaceFirstOrder_saveIntensity.m&#60;/code&#62; to see exactly what is done. Once we figure out an efficient and general way to do it, we'd like to put the calculate of intensity (and heat deposition) back inside the C++ code. I agree it would be more convenient this way.&#60;/p&#62;
&#60;p&#62;Brad.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>Anthony on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4971</link>
			<pubDate>Wed, 04 Feb 2015 16:49:13 +0000</pubDate>
			<dc:creator>Anthony</dc:creator>
			<guid isPermaLink="false">4971@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;Hi Jiri,&#60;/p&#62;
&#60;p&#62;Thanks a lot for your reply: the solution you describe seems to work according to my first tests.&#60;/p&#62;
&#60;p&#62;I understand the problem of memory and it is definitely a good reason not to allow for computing the intensity directly in the simulation code. &#60;/p&#62;
&#60;p&#62;You answer just raised a question in my mind: I thought that &#34;u_unstaggered&#34; was unstaggered both in space and time but your post let me think that it is only unstaggered in space, isnt'it? &#60;/p&#62;
&#60;p&#62;Actually, the reason why I only want to save uz is that I compute the integral of Iz over each XY plane to check the evolution of the power along the propagation (so I can check the increase in absorption due non linear effects around the focus for example...). &#60;/p&#62;
&#60;p&#62;Cheers,&#60;br /&#62;
Anthony
&#60;/p&#62;</description>
		</item>
		<item>
			<title>Jiri Jaros on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4970</link>
			<pubDate>Tue, 03 Feb 2015 20:28:18 +0000</pubDate>
			<dc:creator>Jiri Jaros</dc:creator>
			<guid isPermaLink="false">4970@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;To answer the second question &#34;Calculate intensity in the C code&#34;, I have to reply that it is impractical due to memory limitations.&#60;/p&#62;
&#60;p&#62;As you may know, p and u are staggered both in space and time to improve accuracy (Brad could explain that in detail). In k-Wave 1.0, we used a linear interpolation to get u at the same grid as p, however it had to low accuracy. &#60;/p&#62;
&#60;p&#62;In k-wave 1.1 we introduced fft-based shifts that improved accuracy. The down side is that to do so in space, you need all spatial data for ux, uy and uz even if you sample 1 single grid point! Thus to sample even a tiny region you need 6 more matrices! (speaking about a domain 512^3, we need additional 3GBs of RAM). Let me say tat This is the easy part.&#60;/p&#62;
&#60;p&#62;Now it starts to be tricky, to do the same shift in TIME we need the whole time history - over the sampling period. I talk here about tens to hundreds of GBs of RAM...:-)&#60;/p&#62;
&#60;p&#62;The only solution for now is to progressively store the non-staggered velocity to file, then terminate the simulation, load the data in a different order (1 gridpoint at time, but at all time steps), run the FFT shift and store the data back to file. - this is not implemented in the C code now, and you have to do that in Matlab (I agree that's not very convenient).&#60;/p&#62;
&#60;p&#62;Cheers&#60;br /&#62;
Jiri
&#60;/p&#62;</description>
		</item>
		<item>
			<title>Jiri Jaros on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4969</link>
			<pubDate>Tue, 03 Feb 2015 20:08:39 +0000</pubDate>
			<dc:creator>Jiri Jaros</dc:creator>
			<guid isPermaLink="false">4969@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;Hi Hypermoi,&#60;/p&#62;
&#60;p&#62;To only store uz_non_staggered you need to comment out a couple of lines at different places in the C code.&#60;/p&#62;
&#60;p&#62;This is not a clear solution&#60;/p&#62;
&#60;p&#62;1. MatrixContainer.cpp&#60;br /&#62;
You have to inspect the `TMatrixContainer::AddMatricesIntoContainer() routine and remove these lines&#60;br /&#62;
&#60;pre&#62;&#60;code&#62;MatrixContainer[ux_shifted].SetAllValues(....);
MatrixContainer[uy_shifted].SetAllValues(....);&#60;/code&#62;&#60;/pre&#62;
&#60;p&#62;This removes the matrices from the Matrix container (prevents allocation of memory)&#60;/p&#62;
&#60;p&#62;2. &#60;code&#62;TOutputStreamContainer::AddStreamsIntoContainer()&#60;/code&#62;&#60;br /&#62;
Here, remove these two lines&#60;br /&#62;
&#60;pre&#62;&#60;code&#62;OutputStreamContainer[ux_shifted_sensor_raw] = CreateNewOutputStream(...)
OutputStreamContainer[uy_shifted_sensor_raw] = CreateNewOutputStream(...)&#60;/code&#62;&#60;/pre&#62;
&#60;p&#62;which will stop sampling the quantities. &#60;/p&#62;
&#60;p&#62;3. You need to disable calculating the x and y components&#60;/p&#62;
&#60;p&#62;Inspect &#60;code&#62;TKSpaceFirstOrder3DSolver::Calculate_shifted_velocity()&#60;/code&#62; and remove the code for X and Y&#60;/p&#62;
&#60;p&#62;If it does not work, let me know and I'll send you a patch.&#60;/p&#62;
&#60;p&#62;I might also add a command line parameter to let you choose which components to sample, however we thought it would not be of any use :)
&#60;/p&#62;</description>
		</item>
		<item>
			<title>Anthony on "Save only uz_non_staggered"</title>
			<link>http://www.k-wave.org/forum/topic/save-only-uz_non_staggered#post-4967</link>
			<pubDate>Tue, 03 Feb 2015 10:32:20 +0000</pubDate>
			<dc:creator>Anthony</dc:creator>
			<guid isPermaLink="false">4967@http://www.k-wave.org/forum/</guid>
			<description>&#60;p&#62;Hi Brad,&#60;/p&#62;
&#60;p&#62;I would like to save only uz_non_staggered in my result file because don't need the other components and u_non_staggered is simply too big. &#60;/p&#62;
&#60;p&#62;I guess there is juste one or two lines to comment in the source code but I can't figure out precisely what to do. My hypothesis is that it should work if I comment the lines 705 to 714 in MatrixContainer.cpp but I am not familiar enough with the methods you use to write the HDF5 files...&#60;/p&#62;
&#60;p&#62;Best regards,&#60;br /&#62;
Anthony&#60;/p&#62;
&#60;p&#62;PS: by the way, it was convenient to be able to save directly intensity in k-wave 1.0 (instead of pressure and velocity), I would love to see it back in 1.2 :-)
&#60;/p&#62;</description>
		</item>

	</channel>
</rss>
