YAFU is the fire-and-forget method, or at least it should be, because a

bug seems to have crept in; hopefully Ben will fix this soon.

CADO can run SNFS perfectly well. EdH has written a

guide for running SNFS with CADO, though it still relies on YAFU for the polynomial so won't work until the bug is fixed. It's mostly very good, but with one small caveat (lambdas are not directly comparable between YAFU and CADO so best to just leave out the lambda lines completely, CADO can choose its own) and one big caveat, which is that copying the

tasks.sieve.rels_wanted line across from the CADO parameter file could lead to collecting vastly more relations than are needed if YAFU's chosen lpb bounds differ from CADO's. The easiest way around this is probably to use YAFU's own estimate of required relations. This is

fudge(lpbr) * 2^lpbr / log(2^lpbr) + fudge(lpba) * 2^lpba / log(2^lpba)

where the logs are natural log and the fudge factors are given by the following table:

Code:

lpb fudge(lpb)
24 0.40
25 0.50
26 0.60
27 0.70
28 0.76
29 0.84
30 0.89
31 0.91
32 0.95
33 0.98

SNFS parameters are trickier to figure out than GNFS ones, because while all GNFS jobs of a certain size will have pretty similar optimal parameters, this is not true of SNFS; you can't just run a bunch of SNFS-160 jobs to figure out what the best parameters are for any SNFS-160, and optimal parameters for similar-difficulty GNFS won't be optimal for most SNFS jobs. But at least 160 digits is a small enough SNFS job that picking slightly suboptimal parameters won't hurt you too much. For large jobs it's essential to test-sieve in order to figure out the best parameters - or indeed the best polynomial, as there are often multiple options.

If you don't want to wait for the YAFU bug to be fixed, it's not hard to adapt the techniques for b^n+-1 in the links that mathwiz gave to k*b^n+c.