and experimentation is an everyday practice [@merali10error].

CUDA coding in particular is hard, not only in creating the algorithms, choosing a good block division and trying to take advantage of all its capabilities, but also, in the debugging and maintenance cycle. Debugging tools are evolving rapidly, for example there is a memory debugger [`cuda-memcheck`]{} that is shipped with current CUDA SDK. Nevertheless, we would rather adhere to some passive and active security measures within our code to make it easier to understand and modify, and at the same time, to make it robust in the sense of no unexpected hangs, miscalculations or silent fails.

Among passive security measures, we use assertions (boolean predicates) related to hardware limitations like the maximum of 512 threads per block. Other use of the assertions is checking for the integer representation limitations: given the computing power that GPGPU brings, lattices of $32768\times 32768$ are feasible to simulate, and integer overflow could be a possibility, for example when computing the total energy. Assertions were also used to enforce preconditions on algorithm running, for example, the spin updating cannot do well if $L$ is not multiple of the frame size. We also check every return condition of 