gz_waves: FFT backend - Part 4/4#885
Open
caguero wants to merge 4 commits into
Open
Conversation
3253aa3 to
c9ba107
Compare
f4a163e to
4d50173
Compare
c9ba107 to
aa40214
Compare
7df415e to
3a1f9b0
Compare
…I registrar Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Carlos Aguero <caguero@honurobotics.com>
… FFT the default in open_water.sdf Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Carlos Aguero <caguero@honurobotics.com>
Make the FFT engine build on the rebased stack and match its conventions: - ParticleVelocity/Normal return gz::math::Vector3d (the IWaveField interface is now gz::math); Eigen stays internal to EncinoWaves and the grid accessors. - std::cerr/std::cout -> gzerr/gzmsg (wire gz-common into the engine target). - Members switch to gz-style this->member (no trailing underscore). - Wire gz-math/gz-common into CMake + package.xml. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Carlos Agüero <caguero@honurobotics.com>
aa40214 to
c14f9f6
Compare
…ence) ParticleVelocity was a zero stub, so buoyancy/drag saw still water under the FFT backend. EncinoWaves exposes no velocity field or public spectral coefficients, so compute the Eulerian water velocity as the time derivative of the displacement field (∂Dx/∂t, ∂Dy/∂t, ∂η/∂t): each Update propagates a scratch state at t+dt and finite-differences it into velocity grids that ParticleVelocity bilinear-samples. Adds two tests. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Carlos Agüero <caguero@honurobotics.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fourth in the series. Adds the second wave engine, the FFT spectral backend built on the EncinoWaves library, and wires it into the visual and the demo world as a selectable alternative to Gerstner.
How to test it?
What this PR adds
FFTWaveSimulation,libgz-waves-provider-fft) — a plainIWaveFieldbacked by EncinoWaves (TMA/JONSWAP/PM spectra + directional spreading + dispersion).MakeFFTWaveField()is its factory.gz-sim-waves-fft-system) — aWavesSystemBasesubclass that builds the FFT engine and writes theWavefieldcomponent. Its doc block documents the full parameter surface and the<sea_state>precedence rules.gz-sim-waves-fft-gui) — registers the"fft"factory in the GUI soWaterVisualcan rebuild a private FFT engine; same bare, no-ISystem, static-init form as the Gerstner registrar.test/fft_test.cc, 18 tests).gz-sim-waves-fft-guito thewater_surfacemodel (next to the Gerstner registrar) and offers FFT as a commented alternative inopen_water.sdf. Gerstner stays the active default — flip by commenting the Gerstner<plugin>and uncommenting the FFT one.