Singular

liftstd computes much more: not just a Groebner basis, but also the transformation matrix and the syzygies.
The current Singular(github version) tries to improve that by not computing the syzygies, if one does not need them.

Using option(prot) I can see that "slimgb" almost immediately diverges in strategy when used in groebner versus liftstd.
How can I make liftstd proceed like the groebner calculation?

For comparison, here are some snippets of output (I added newlines added in the prot output to make it easier to read and compare with a diff).
Groebner calculation with "slimgb":
[code]
...
STDIN 94> option(redSB);
STDIN 95> option(prot);
STDIN 96> ideal I2 = groebner(I, "slimgb");
slimgb in ring (QQ),(... snip variable list ...),(dp(54),C)
2M[81,81](648)
3M[100,100](2061)
3M[100,100](3833)
3M[100,100](5768)
3M[100,100](7465)
3M[100,100](9490)
3M[100,100](11436)
3M[48,48](12558)
...
[/code]
liftstd calculation with "slimgb":
[code]
...
STDIN 94> option(redSB);
STDIN 95> option(prot);
STDIN 96> module s;
STDIN 97> matrix T;
STDIN 98> ideal I2 = liftstd(I,T,s,"slimgb");
{1}slimgb:
2M[81,81](729)
3M[100,100](2412)
3M[100,100](4197)
3M[100,100](6043)
...
[/code]

With the same ideal, the first finishes in 10 seconds and under 100MB total memory usage (including program). While the second one is still running after hours. This is why I'd like to be able to have liftstd follow the same strategy and groebner.

Is it possible liftstd is changing the problem (homogenizing first?) under the hood? If so, in my particular case, the basis would explode to something huge, so I really hope it is not trying to do that.

As a check to see if groebner was doing extra heuristics, I also ran a test calling slimgb directly for calculating the groebner basis "ideal I2 = slimgb(I);"
The prot output matched exactly with the "ideal I2 = groebner(I, "slimgb");" case, so groebner is not added extra heuristics here.

What is causing the change in strategy between using slimgb for groebner and for liftstd?