How about adding GPU accelerations？

Although I haven't used your newest version of the program,  most likely you haven't introduced the function yet. As I don't know for sure whether users of other fields will agree, but in RS, we deal with images, raster images and vector images. GPU frameworks like CUDA or OpenCL could be a booster for our work. Actually, that is what I am learning these days, I plan to spend 1 or 2 years writing my own program using CUDA to calculate a few metrics during my spare time, starting by reading the book GPU Parallel Program Development Using CUDA by Tolga Soyata. The ultimate goal is to build the program I need to do 3km scale calculations on a global scale.
Besides, batch processing functions should be improved.  I have to create hundreds of batch files for my calculation as one batch file can only record hundreds of raster to be calculated, otherwise, it will just crash. It is probably because of the 32-bit program's memory limit. So that problem may have been solved now.
Last but not least, I remember when I was in college, the tutorial didn't provide an exact introduction to the program CLI, I learn that in the part introducing how to use the program with R. I find the CLI worth of separate introduction for it is important for secondary development as not all user knows R. For example, I use python more often and I may have missed the CLI I need haven't I know a bit R and read that part.
If you accept my proposal for adding GPU support, maybe I have to find something else to do  . But the process of finding another meaningful target like that is quite tough for me. So that is the reason why I said about joining you. LOL

Hello BubbleDragon,

First of all, thank you for contacting us. The CUDA suggestion sounds interesting, we will consider it in the context of the constraints of the Fragstats code. Some algorithms could benefit from the extra help from the GPU some cannot. Some people do not have powerful graphics cards and some do. Our priority at this point is making the algorithm as efficient as possible and that means first using the full potential of the host computer through parallelization where possible. We do acknowledge that this is not always possible, some algorithms are inherently sequential and for others the overhead of thread creation and management would eat all the gains.

Regarding the batch processing, I suspect that the accumulation of results from so many input landscapes caused an "out of memory" condition where there was no more memory to allocate for storage. This issue was acute in the 32-bit version, it should be less of a problem now. Most computers nowadays have plenty of RAM. There are also other solutions that we are considering. For example, storing results directly on disk in an appropriate format.

For the command line interface we did not consider producing extensive documentation because it was limited by design. It was meant to simply run an existing model created and/or altered through the GUI. That does not mean it could not be used creatively from any language that could launch a command in a system shell like R or Python. However, some level of proficiency in the aforementioned languages is necessary and is independent of Fragstats. We'll consider adding more examples to serve as starting points.

Best regards,
Eduard

High five！