Ethereal kind of stops in some position

[andygrant]

Ethereal kind of stops in some position

[AndyGrant]

I took both V11.53, and current master (V11.57), and I was able to produce the same "stopping" behavior.

If I execute a go movetime <x> search, the process will eventually return a bestmove when <x> has expired, so Ethereal is not freezing, or crashing, or whatever else.

Most likely, and I'll allow the process to run for quite some time to perhaps demonstrate this, Ethereal has decided that the "expected" line of play from the depth 16 search is actually very very bad, and thus is coming up with an entirely new line of play, but starting with depth 17. That would take a very long time to do. There is a good reason why engines work from depth 1 -> N.

Also, after having looked at the actual position, its possible that Ethereal is either JUST about to resolve the position to a mate (could take some time since it was suddenly found, when no progress had been made otherwise), or Ethereal is now seeing that the position is drawn (perhaps correctly or incorrectly)

You can help me test as well -- repeat the position and inputs you did before, but just give Ethereal a few minutes, to see if any information starts to be reported.

[Matthies]

Testing with 11.57 now which stops output after

info depth 17 currmove c3d5 currmovenumber 1

I ran it for ~30 minutes without furter output. Then I added some debug output in your search

    thread->nodes++;

    if (thread->nodes % 10000000 == 0)
    {
        printf("nodes: %"PRIu64"  depth: %d  height: %d\n", thread->nodes, depth, height);
        fflush(stdout);
    }

Seems that Ethereal searches at very high (selective) depth on this position:

...
nodes: 260000000  depth: 1  height: 47
nodes: 300000000  depth: 1  height: 54
nodes: 310000000  depth: 1  height: 74
nodes: 330000000  depth: 2  height: 64
nodes: 340000000  depth: 2  height: 66
nodes: 360000000  depth: 1  height: 74
nodes: 390000000  depth: 1  height: 67
nodes: 410000000  depth: 1  height: 78
...

Some extensions that are not limited?

[AndyGrant]

So, nice observation, and its (unfortunately) not a knew issue. The outputs below are from disabling all extensions.

Ethereal is very aggressive in how extensions are applied. I've spent more time trying to limit them than I would like to share. I suppose these mate positions could likely be accounted for and adjust the extensions, but its not the kind of change to bring elo or appear as a simplification.

info depth 31 seldepth 32 score mate 48 time 6802 nodes 460973295 nps 67760000 tbhits 0
hashfull 52 pv c3e4 g1h1 e5f4 h1g1 f4g3 g1h1 e4f2 h1g1 g3d6 g1f1 d6h2 f1e1 f2e4 e1d1 h2e5 
d1e1 e5d4 e1f1 e4c3 f1e1 d4e3 e1f1 e3c5 f1e1 c3e4 e1d1 c5d4 d1e1 d4b6 e1d1 b6a5

info depth 71 seldepth 57 score mate 21 time 6072757 nodes 453974908712 nps 74755000 tbhits
0 hashfull 111 pv e5d6 g1h1 c3e4 h1g1 e4f2 g1f1 d6h2 f1e1 f2e4 e1d1 h2e5 d1c2 e4c5 c2d2 f3f2
d2d1 e5c3 d1c2 c3a5 c2d1 f2f1 d1c2 f1e2 c2c1 e2d3 c1d1 c5a4 d1c1 a5d2 c1b1 d3c3 b1a2 d2c1
a2b1 c3d2 b1a2 d2c2 a2a1 c1b2 a1a2 a4c3

[Matthies]

Okay, so it is no real problem, just some strange behaviour in some (probably) rare positions. So I will close this.