Skip to content

Commit

Permalink
improved docs for gpu_spreadinterponly and upsampfac=1 advanced use c…
Browse files Browse the repository at this point in the history
…ase; CHANGELOG
  • Loading branch information
ahbarnett committed Oct 8, 2024
1 parent cabda72 commit cf25e43
Show file tree
Hide file tree
Showing 4 changed files with 20 additions and 13 deletions.
12 changes: 7 additions & 5 deletions CHANGELOG
Original file line number Diff line number Diff line change
@@ -1,10 +1,12 @@
List of features / changes made / release notes, in reverse chronological order.
If not stated, FINUFFT is assumed (cuFINUFFT <=1.3 is listed separately).

Master (9/10/24)
Master (10/8/24)

* Support and docs for opts.gpu_spreadinterponly=1 for MRI "density compensation
estimation" type 1&2 use-case with upsampfac=1.0 PR564 (Chaithya G R).
* reduced roundoff error in a[n] phase calc in CPU onedim_fseries_kernel().
#534 (Barnett).
PR534 (Barnett).
* GPU code type 1,2 also reduced round-off error in phases, to match CPU code;
rationalized onedim_{fseries,nuft}_* GPU codes to match CPU (Barbone, Barnett)
* Added type 3 in 1D, 2D, and 3D, in the GPU library cufinufft. PR #517, Barbone
Expand All @@ -14,9 +16,9 @@ Master (9/10/24)
- Minor fixes on the GPU code:
a) removed memory leaks in case of errors
b) renamed maxbatchsize to batchsize
* Add options for user-provided FFTW locker (PR548, Blackwell). These options can be be
used to prevent crashes when a user is creating/destroying FFTW plans and
FINUFFT plans in threads simultaneously.
* Add options for user-provided FFTW locker (PR548, Blackwell). These options
can be be used to prevent crashes when a user is creating/destroying FFTW
plans and FINUFFT plans in threads simultaneously.

V 2.3.0 (9/5/24)

Expand Down
9 changes: 6 additions & 3 deletions docs/c_gpu.rst
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
.. _c_gpu:

C interface (GPU)
=================

Expand Down Expand Up @@ -311,8 +313,9 @@ while ``modeord=1`` selects FFT-style ordering starting at zero and wrapping ove

**gpu_device_id**: Sets the GPU device ID. Leave at default unless you know what you're doing. [To be documented]

**gpu_spreadinterponly**: if ``0`` do the NUFFT as intended. If ``1``, omit the FFT and kernel FT deconvolution steps and return garbage answers.
Nonzero value can be used *only* with `upsampfac=1` and `kerevalmeth=1` for using cufinufft for only spread and interpolate mode. This has applications into estimating the density compensation, which is conventionally used in MRI. (See [MRI-NUFFT](https://mind-inria.github.io/mri-nufft/nufft.html))
**gpu_spreadinterponly**: if ``0`` do the NUFFT as intended. If ``1``, omit the FFT and deconvolution (diagonal division by kernel Fourier transform) steps, which returns *garbage answers as a NUFFT*, but allows advanced users to perform an isolated spreading or interpolation using the usual type 1 or type 2 ``cufinufft`` interface. To do this, the nonzero flag value must be used *only* with ``upsampfac=1.0`` (since the input and output grids are the same size, and neither represents Fourier coefficients), and ``kerevalmeth=1``. The known use-case here is estimating so-called density compensation, conventionally used in MRI. (See [MRI-NUFFT](https://mind-inria.github.io/mri-nufft/nufft.html)) Please note that this flag is also internally used by type 3 transforms (which was its original use case).




Algorithm performance options
Expand All @@ -323,7 +326,7 @@ Algorithm performance options
* ``gpu_method=0`` : makes an automatic choice of one of the below methods, based on our heuristics.

* ``gpu_method=1`` : uses a nonuniform points-driven method, either unsorted which is referred to as GM in our paper, or sorted which is called GM-sort in our paper, depending on option ``gpu_sort`` below

* ``gpu_method=2`` : for spreading only, ie, type 1 transforms, uses a shared memory output-block driven method, referred to as SM in our paper. Has no effect for interpolation (type 2 transforms)

* ``gpu_method>2`` : (various upsupported experimental methods due to Melody Shih, not for regular users. Eg ``3`` tests an idea of Paul Springer's to group NU points when spreading, ``4`` is a block gather method of possible interest.)
Expand Down
2 changes: 1 addition & 1 deletion docs/error.rst
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ has the following meanings (see codes in ``include/finufft_errors.h``):
18 size of bins for subprob/blockgather invalid
19 GPU shmem too small for subprob/blockgather parameters
20 invalid number of nonuniform points: nj or nk negative, or too big (see defs.h)
23 invalid upsampfac set while using gpu_spreadinterponly mode.
23 invalid upsampfac set while using gpu_spreadinterponly mode

When ``ier=1`` (warning only) the transform(s) is/are still completed, at the smallest epsilon achievable, so, with that caveat, the answer should still be usable.

Expand Down
10 changes: 6 additions & 4 deletions docs/opts.rst
Original file line number Diff line number Diff line change
Expand Up @@ -160,16 +160,18 @@ There is thus little reason for the nonexpert to mess with this option.

**upsampfac**: This is the internal real factor by which the FFT (fine grid)
is chosen larger than
the number of requested modes in each dimension, for type 1 and 2 transforms.
the number of requested modes in each dimension, for type 1 and 2 transforms. It must be greater than 1.
We have built efficient kernels
for only two settings, as follows. Otherwise, setting it to zero chooses a good heuristic:
for only two settings that are greater than 1, as follows. Otherwise, setting it to zero chooses a good heuristic:

* ``upsampfac=0.0`` : use heuristics to choose ``upsampfac`` as one of the below values, and use this value internally. The value chosen is visible in the text output via setting ``debug>=2``. This setting is recommended for basic users; however, if you seek more performance it is quick to try the other of the below.
* ``upsampfac=0.0`` : use heuristics to choose ``upsampfac`` as one of the below values exceeding 1, and use this value internally. The value chosen is visible in the text output via setting ``debug>=2``. This setting is recommended for basic users; however, if you seek more performance it is quick to try the other of the values exceeding 1.

* ``upsampfac=2.0`` : standard setting of upsampling. This is necessary if you need to exceed 9 digits of accuracy.
* ``upsampfac=2.0`` : standard setting of upsampling. Due to kernel width restrictions, this is necessary if you need to exceed 9 digits of accuracy.

* ``upsampfac=1.25`` : low-upsampling option, with lower RAM, smaller FFTs, but wider spreading kernel. The latter can be much faster than the standard when the number of nonuniform points is similar or smaller to the number of modes, and/or if low accuracy is required. It is especially much (2 to 3 times) faster for type 3 transforms. However, the kernel widths :math:`w` are about 50% larger in each dimension, which can lead to slower spreading (it can also be faster due to the smaller size of the fine grid). Because the kernel width is limited to 16, currently, thus only 9-digit accuracy can currently be reached when using ``upsampfac=1.25``.

* ``upsampfac=1.0`` : an obscure advanced setting peculiar to a "spread/interpolate only" mode specific to the GPU (see :ref:`GPU usage<c_gpu>`), which does not even in fact execute a NUFFT. Thus, do not use this unless you know what you are doing!

**spread_thread**: in the case of multiple transforms per call (``ntr>1``, or the "many" interfaces), controls how multithreading is used to spread/interpolate each batch of data.

* ``spread_thread=0`` : makes an automatic choice between the below. Recommended.
Expand Down

0 comments on commit cf25e43

Please sign in to comment.