Properly handle unsupported SETUP_TRANS GPU features

[samhatfield]

Now that we have API tests for SETUP_TRANS, we should clarify which features are and aren't supported for GPUs. This PR adds abort statements when the following arguments are passed to SETUP_TRANS for GPU:

• LDSPSETUPONLY: currently this is ignored with a warning
• LDLL: currently this is handled with an abort followed by some pointless logic
• LDGRIDONLY: currently this is ignored with a warning

Personally I think the "warn and carry on" approach is only appropriate for arguments which don't have relevance for the GPU implementation, e.g. "use FFTW". When a feature is requested and the functionality just isn't implemented at all, we should abort (this is what we currently do when the FLT is requested for the GPU version).

[wdeconinck]

Hi Sam,
I agree with the removal of pointless code after an abort. 👍

However the workarounds for LDSPSETUPONLY and LDGRIDONLY should not be deleted and not abort. Let me explain.
The use of LDSPSETUPONLY or LDGRIDONLY is to speed up setup_trans in terms of computation and memory when the other "space" is not needed.
Because a single "space" is not yet implemented for GPUs, and I would not want to abort because of this, the workaround which I implemented was to create a minimal "other space", taking not too much memory or computations.
This was the quickest workaround I could do rather than dive in deeper to actually implement it. It should probably be not too much work, following CPU code path logic, but hey, this was minimally invasive.

[samhatfield]

Fair enough. So perhaps I should try to actually implement these features for the GPU version?

[wdeconinck]

Fair enough. So perhaps I should try to actually implement these features for the GPU version?

Indeed... 😇

[wdeconinck]

Please either restore the mentioned workarounds, or repurpose PR to implement GPU version.