Skip to content

Oversample FD - #224

Closed
SeanMollet wants to merge 1 commit into
thliebig:masterfrom
SeanMollet:fd_oversampling
Closed

SeanMollet wants to merge 1 commit into
thliebig:masterfrom
SeanMollet:fd_oversampling

Conversation

@SeanMollet

Copy link
Copy Markdown
Contributor

Oversample FD to reduce aliasing at the edge.

Tested on the Horn example and Dipole_SAR.

Somewhat expensive on a CPU, essentially free on a GPU. This changes results for anyone using FD dumps or probes. Happy to put it behind a separate variable defaulting to 1 if you'd rather preserve existing behavior.

Thanks,
Sean

The frequency domain dumps and probes (DFT during the run) were sampled at
the Nyquist rate of the excitation, while the time domain dumps and probes
use OverSampling (default 4) samples per Nyquist interval. At the Nyquist
rate the spectrum just above the highest excited frequency aliases onto
the upper band edge. Now all recording follows OverSampling.

Horn antenna example (10-20 GHz), NF2FF box with frequencies: directivity
at 20 GHz 15.87 -> 16.91 dBi, the value of the time domain dumps; the
patterns at 10, 15 and 20 GHz now agree with them within 0.001 dB (were
up to 18 dB off at 20 GHz). On the GPU engine the samples are one kernel
each: timestepping 2.65 s -> 2.82 s on an RTX 5090. On the CPU engines
the host work of the frequency domain dumps grows with the factor.

Dipole_SAR.py: the reference peak SAR values, calibrated with Nyquist
sampling, were ~2 % high (1 GHz in a 0-1.5 GHz excitation). They are
recalibrated at the default OverSampling, where they have converged
(OverSampling 8 and 16 within 0.01 %).

The OverSampling documentation (Python, Matlab) now names the frequency
domain recording and the probes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@thliebig

Copy link
Copy Markdown
Owner

Well in the Dipole_SAR tutorial with its rather large FD SAR dumpbox I see a speed penalty of ~20% while the SAR values only differs less than 0.5% and it seems the total number of timesteps which happens to end at has an even bigger influence.
That all said, I think this topic is important and giving the user the option to choose a higher/better sampling rate is good. But the questions are, what should be the default. My opinion, the oversampling should remain at 1 per default, but the user should have the option to change it. Most likely by setting this as an option to the dump box.
What do you think @SeanMollet ?

@SeanMollet

Copy link
Copy Markdown
Contributor Author

Yeah, I think a configurable option with a 1 default is great.

@thliebig

Copy link
Copy Markdown
Owner

I have rewritten this commit, the default is now 1 again but now can be set via CSXCAD per dump-box. Make sure to update and rebuild CSXCAD.
I will close this as is. Thanks @SeanMollet

@thliebig thliebig closed this Sep 21, 2026
@SeanMollet
SeanMollet deleted the fd_oversampling branch September 24, 2026 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants