http://www.k-wave.org/forum/topic/silent-runtime-failure-of-kspacefirstorder-cuda-omp-compiled-with-gcc-132 Support for the k-Wave MATLAB toolbox en-US Tue, 12 May 2026 22:27:03 +0000 http://bbpress.org/?v=1.0.2 q http://www.k-wave.org/forum/search.php http://www.k-wave.org/forum/topic/silent-runtime-failure-of-kspacefirstorder-cuda-omp-compiled-with-gcc-132#post-9174 Wed, 15 Jan 2025 13:09:51 +0000 Jiri Jaros 9174@http://www.k-wave.org/forum/ <p>Hi, we now about and working on releasing the fix. The GNU compiler changed the way it treats infinity. </p> <p>The following lines now cause the simulation to end with NaNs.</p> <p>if (absorbNabla1[i] == std::numeric_limits&lt;float&gt;::infinity()) absorbNabla1[i] = 0.0f;<br /> if (absorbNabla2[i] == std::numeric_limits&lt;float&gt;::infinity()) absorbNabla2[i] = 0.0f;</p> <p>a simple, however, not the best fix is:</p> <p>// Comparison with infinity is not supported with --ffast-math enabled<br /> if (absorbNabla1[i] &gt;= std::numeric_limits&lt;float&gt;::max()) absorbNabla1[i] = 0.0f;<br /> if (absorbNabla2[i] &gt;= std::numeric_limits&lt;float&gt;::max()) absorbNabla2[i] = 0.0f; </p> http://www.k-wave.org/forum/topic/silent-runtime-failure-of-kspacefirstorder-cuda-omp-compiled-with-gcc-132#post-9144 Sat, 28 Sep 2024 21:17:20 +0000 aschrempf 9144@http://www.k-wave.org/forum/ <p>Hi,<br /> I can confirm that. Tried to build on macOS (according to <a href="https://github.com/lennartverhagen/k-Wave-CPUGPU-macOS)" rel="nofollow">https://github.com/lennartverhagen/k-Wave-CPUGPU-macOS)</a> -- so completely different platform -- with gcc 14 and got always NaN after simulation. Also no error indication during simulation. Simulation on Matlab-Version of kspaceFirstOrder ist pretty stable.<br /> Thanks for the hint, "rich". After compiling with gcc 12 everything works as expected!</p> <p>Thanks also for the great k-wave SW!</p> <p>Kind regards<br /> Andreas </p> http://www.k-wave.org/forum/topic/silent-runtime-failure-of-kspacefirstorder-cuda-omp-compiled-with-gcc-132#post-9112 Sat, 13 Jul 2024 00:39:08 +0000 vich 9112@http://www.k-wave.org/forum/ <p>Hi there,</p> <p>Just passing by to report what I think may be a bug: when I compile kspaceFirstOrder-CUDA (<code>__KWAVE_GIT_HASH__=&quot;468dc31c2842a7df5f2a07c3a13c16c9b0b2b770&quot;</code>) on Linux with gcc version 13.2.1, the compilation succeeds and the binary runs successfully. But in fact it only appears to run successfully. In some simulations of mine, after running kspaceFirstOrder-CUDA, MATLAB's <code>h5read()</code> reads in the <code>/p_final</code> and <code>/p</code> fields of the output HDF5 file as all-NaN arrays (of the expected size), the three <code>/u[xyz]_non_staggered</code> as all-zeros arrays, and <code>/p_min</code> as an array with all entries set to 3.4028e+38 (which equals <code>realmax(&#39;single&#39;)</code>), for example. The compiled binary produces no unusual messages at runtime.</p> <p>However, when I revert to gcc version 12.3.1 and compile kspaceFirstOrder-CUDA anew, keeping all else unchanged, the resulting binary works properly; the output HDF5 file contains meaningful information.</p> <p>I tried fiddling with the NVIDIA drivers and the CUDA Toolkit, but I don't think they are to blame. The main reason being (as I found out later) that the kspaceFirstOrder-OMP (<code>__KWAVE_GIT_HASH__=&quot;0ba023063e3f29685e1e346f56883378d961f9f1&quot;</code>) binary also suffers from the same symptoms (except <code>/p_min</code> becomes an all-NaN array) when compiled with the more recent gcc 13.2.1; but not with the older gcc 12.3.1.</p> <p>I am not sure if that is a problem with my particular system or if the bug can be reproduced elsewhere. Maybe this info can be useful to someone. In any case, though, I think maybe the external binaries could do with some sort of sanity check on the output; something inexpensive, just to catch egregious conditions?</p> <p>Thanks for your great software! </p>