Squall: A Method Developed For The January 2021 Method Development Competition

[trangium]

This will be a place to discuss or ask questions about the Squall method.

Background:
Squall was developed for the January 2021 Method Development Competition.

The motivation behind Squall's steps are that a method’s speed depends on two factors:
(Solve time) = (movecount) ÷ (TPS)

The TPS can also be broken down into two factors:
TPS = (max TPS) × (proportion of solve spent turning)

These two formulas can be combined:
(Solve time) = (movecount) ÷ ((max TPS) × (proportion of solve spent turning))

This shows that the factors that contribute to a method’s speed are movecount (efficiency), max TPS (ergonomics), and the proportion of the solve spent turning (lookahead). With that in mind, Squall was made with the goal of good ergonomics, good lookahead, and good movecount.


Steps:
1. EOSquare: Solve a square in dbL while orienting all the edges. (8 moves)

2. L pair: Solve the dFL pair, extending the square into an EOFB. You have a lot more freedom here than in CFOP, since the entire right side of the cube is free. (5 moves)

3. DFDB: Solve dM (the DF and DB edges, along with the M centers), extending the EOFB into an EO2x2x3. (5 moves)

4. B pair: Solve the dBR pair. You have a lot more freedom than in CFOP, since the R layer is free. (5 moves)

5. F pair: Solve the dFR pair. You have slightly more freedom than in CFOP, since you can disturb the DR edge, although there are more cases where an dFR pair piece is stuck in the DR position. (7.5 moves)

6. CDRLL: Solve the remaining 4 corners as in COLL, but the DR edge can be disturbed, leading to better algs. (42 algs, 11.5 moves)

7. L5EP: Solve the remaining 5 edges. These algs are almost all RU or MU. (16 algs, 11 moves)


Additional Info:
More information can be found in the dedicated Squall method doc, including example solves, statistics, FAQs, and a more detailed analysis of the method.
Join the Discord Server here.

 

[tsmosher]

I always felt that the estimates for L pair and DF/DB seemed a little optimistic at 5 moves each. I would think that L pair is still somewhat restricted (much like F pair is) and would estimate 7-8 moves.

With EO and an untethered R layer, the estimate for DF/DB is probably accurate. One of the rewards you reap for executing EOSquare.

This method and the Mehta method have taught me that i really struggle with resisting the urge to just solve DR.

 

[trangium]

I always felt that the estimates for L pair and DF/DB seemed a little optimistic at 5 moves each. I would think that L pair is still somewhat restricted (much like F pair is) and would estimate 7-8 moves.

With EO and an untethered R layer, the estimate for DF/DB is probably accurate. One of the rewards you reap for executing EOSquare.

This method and the Mehta method have taught me that i really struggle with resisting the urge to just solve DR.

For L pair, try not to think of it as solving a CFOP F2L pair. This usually leads to high movecounts. Instead, pair the two L pair pieces anywhere on the cube, then set up to either an F2 or L' depending on the orientation of the EOSquare. There are only so many distinct L pair cases, so eventually a top solver would be able to execute a near-optimal solution every time, hence an average of around 5 moves.

 

[LukasCubes]

Should I do this for BCCF (I renamed my big cube method)?

Btw I didn't use it for the comp