CMake: WarpX_PSATD -> WarpX_FFT

[ax3l]

Rename WarpX_PSATD to WarpX_FFT in the build configuration options. We now use FFTs for more than the PSATD solver since the introduction of the IGF solver for electrostatic simulations.

[dpgrote]

Rather than breaking the build interface, could a new flag WARPX_FFT be added that turns on the FFT code, and have it turned on when WARPX_PSATD is turned on? This would also avoid including all of the PSATD stuff when a user wants the IGF electrostatic solver.

[ax3l]

Hi Dave,

We (cc @RemiLehe , @aeriforme) thought initially to delay the break by making WarpX_PSATD an alias. But in the end it just complicates the build logic instead of a clean update.

For your idea to have PSATD control separately, I would be inclined to not add this. The reason is as follows: we do not really want to separately control if PSATD is compiled or not - we want it available all the time ideally. The primary reason we had the old flag, and name it now FFT, is that we want to be able to build versions of WarpX with limited/simplified dependencies.

As a follow-up PR, I would also try to default-enable WarpX_FFT (as in openPMD and ADIOS2 build flags that are AUTO by default), because it is (nearly/practically) dependency free for GPU builds (besides RZ).

We will also as a follow-up add a flag for WarpX_heFFTe for multi-GPU FFTs, probably also as AUTO/ON/OFF.

[dpgrote]

This is all good. I'm just trying to avoid API breaking changes. Also, note that with my suggestion, this PR would be substantially smaller since none of the hpc scripts, none of the yml files, and none of the spectral solver code would need to be changed. Also, keeping PSATD separate from FFT would make it easier to later remove the PSATD flag since it doesn't directly depend on a third party package (but only via FFT).

[ax3l]

I'm just trying to avoid API breaking changes.

Understood. Yes, that was my initial inclination as well (my suggestion: keep an alias around for a few releases) before I spoke with @RemiLehe and @aeriforme .

Also, note that with my suggestion, this PR would be substantially smaller since none of the hpc scripts, none of the yml files, and none of the spectral solver code would need to be changed.

Changes that are not user-facing are no problem per se, but HPC scripts and docs are user-facing here.

For CI and other non-user-facing scripts, I can put them in smaller commits for the PR to review easier.

keeping PSATD separate from FFT would make it easier to later remove the PSATD flag since it doesn't directly depend on a third party package (but only via FFT).

I think the argument that @RemiLehe made was if we do continue to advertise the PSATD flag, then people will just have the same breakaging change later.

Shall we chat more in the weekly developer meeting which transition path we prefer?

[ax3l]

Discussed today:
Will add a (now undocumented) PSATD control flag for a few months so that users do not need to change their build logic immediately. (Warn if used.)

[ax3l]

@dpgrote @RemiLehe @aeriforme this is ready now as we discussed :)

(ON/OFF both work. The old option takes precedence if both are passed, because that is easier to check in CMake.)

We keep the flag WarpX_PSATD as an alias around for a few releases before we drop it.
But we do not document it anymore, so new people do not pick it up. And we raise a warning, so people transition.

[dpgrote]

I can approve.