opencl backend only supports a number of harmonics (k) in range(3,11) about bfast HOT 4 OPEN

Moreover, I just tested !pip install git+https://github.com/mirt001/bfast.git@mirt001-testing-k-1-2#egg=bfast branch on my fork, which comments the lines that check whether k is in k_valid.

It works with seemingly correct results on google colab, and I assume nothing exploded on google side of things.

This is far from proper testing, but whatever prompted imposing the k>2 limitation, might not be in the code anymore.

from bfast.

This limitation has been there from before I joined the project, so I don't know exactly why it is there. I think it has something to do with performance of the GPU version. 2k + 1 is the inner dimension of multiple vector/matrix operations in the code, and the GPU kernels are tuned with this assumption in mind. It should still run for k=1 and k=2, but the performance would probably be suboptimal. More testing needs to be done.

from bfast.

@mortvest I understand that performance might be suboptimal, when compared to k=3, but the performance is still better than the R bfast. Also, python and opencl backends are at least comparable with k=1, and I believe opencl is still faster.
At most, the performance decrease for k=1 and k=2 for opencl should be documented and left to the user. Especially since, imo, most users need specifically k=1 and k=2.

What do you have in mind for testing? I have to run bfastmonitor quite a few times these days. If I can watch out for something extra that would help with development, that would be great. I am currently running my fork that allows me to run with k=1 and k=2. No issues so far.

from bfast.

Thanks for your input @mirt001, I didn't know that it was a popular setup. By testing, I meant how much performance decrease there is and if it actually produces the correct results. The latter is probably true. Regarding the former, we would probably need to retune some parameters for the GPU version. I'll look into it next week.

from bfast.