Winboard Forum

Posted: **08 Apr 2005, 09:43**

Hi all.
Volker Annuss (Herrman) send me a FRC initial position where AICE plays an illegal castling move.

rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1
[diag]rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1[/diag]

What is your perft for this position? It seems to me that 0-0-0 is not possible if the rook stays in d1.

Posted: **08 Apr 2005, 13:17**

Hi Anastasios,

here are Hermanns perft results. The "debug on" is not necessary. It switches on error messages when the FEN string is bad.

Code: Select all: >uci <[...] >debug on >position fen rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1 >perft depth 1 <info depth 1 time 0 nodes 20 >perft depth 2 <info depth 2 time 0 nodes 400 >perft depth 3 <info depth 3 time 15 nodes 8832 >perft depth 4 <info depth 4 time 94 nodes 193554 >perft depth 5 <info depth 5 time 2250 nodes 4673537 >perft depth 6 <info depth 6 time 54828 nodes 111825069

For the castling rules, look at Reinhard Scharnagls homepage:
http://www.chessbox.de/Compu/fullchess3_e.html

Castling is permitted only, when nothing is standing from the king to his target square (incl.) except an involved rook, and when nothing is standing from the rook to its target square (incl.) except an involved king (from that it can be concluded, that all the squares must be free between both figures).

The rook on the d-file is not involved in the 0-0-0 castling, so it has to be moved first.

Greetings,
Volker

Posted: **10 Apr 2005, 22:33**

My 5 cents....

....... (depths 1-5) ........

Depth 5
Total: 4673537 Time: 0.655860 s 7125 kNps

Depth 6
Total: 111825069 Time: 12.543344 s 8915 kNps

Depth 7

2916765333 Time: 314.660610 s 9269 kNps

(move by move)

g1f3 123097238 2546 kNps
g1h3 104315113 10586 kNps
f1e3 129236831 4795 kNps
f1g3 106965913 10778 kNps
h2h3 100063439 5944 kNps
h2h4 110892695 10314 kNps
g2g3 152588850 6550 kNps
g2g4 174548427 9902 kNps
f2f3 122923722 7415 kNps
f2f4 140555187 9751 kNps
e2e3 100298471 7933 kNps
e2e4 105834364 9764 kNps
d2d3 194691044 7912 kNps
d2d4 226382994 9640 kNps
c2c3 228298685 8144 kNps
c2c4 234115811 9495 kNps
b2b3 129229194 8647 kNps
b2b4 154309566 9395 kNps
a2a3 128818628 8794 kNps
a2a4 149599161 9247 kNps

Hermann gives the same totals (sort of) up to depth 7.

Please send your results. I'm very interested in any discrepancies from 7 plies on, which is where bugs begin to appear.
By the way, Volker, the version I have for Hermann doesn't display large numbers (%d usually displays 32 bit signed), although the figures are correct after some modifications. Have you corrected this in newer versions?
Regards,

Posted: **11 Apr 2005, 02:08**

Well, here are Smirf's values:

Code: Select all: FEN: rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1 +-*--b--*--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 |[r][q][k][r][b][n][n][b]| (Compilation: Apr 11 2005) 7 |[p][p][p][p][p][p][p][p]| 6 | ::: ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | 4 | ::: ::: ::: :::| (without caching) 3 |::: ::: ::: ::: | 2 || Smirf Test No.: 00 1 |<R><Q><K><R><N><N>| =>+-*--b--*--*--e--f--g--h-+ Break Time 5.0 Sec. Ply Nodes all (x) (e.p.) all (+) all (++) Promot. Castl. Sec. ------------------------------------------------------------------------------- 1 20 0 0 0 0 0 0 0 2 400 0 0 0 0 0 0 0 3 8832 99 0 40 0 0 0 0 4 193554 2961 0 915 0 0 0 0 5 4673537 129047 257 39895 0 0 0 0.2 6 111825069 3793709 5166 983773 145 0 0 4.3 7 2916765333 132941956 314652 35568323 5512 0 37 106 -------------------------------------------------------------------------------

P.S.: less detailed results (using a transposition table):

Code: Select all: FEN: rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1 +-*--b--*--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 |[r][q][k][r][b][n][n][b]| (Compilation: Apr 11 2005) 7 |[p][p][p][p][p][p][p][p]| 6 | ::: ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | (With TT Caching 256.0 MB / 4-fold) 4 | ::: ::: ::: :::| TT Access Success 47.9% 3 |::: ::: ::: ::: | 2 || Smirf Test No.: 00 1 |<R><Q><K><R><N><N>| =>+-*--b--*--*--e--f--g--h-+ Break Time 20.0 Sec. Ply Nodes all (x) all (+) (e.p.) Sec. ---------------------------------------------------------------------------- 1 20 0 0 0 0 2 400 0 0 0 0 3 8832 99 40 0 0 4 193554 2961 915 0 0 5 4673537 129047 39895 257 0.1 6 111825069 3793709 983773 5166 1.2 7 2916765333 132941956 35568323 314652 14.5 8 75331645146 3972680374 941690347 6936954 192.9 ----------------------------------------------------------------------------

Regards, Reinhard

Posted: **11 Apr 2005, 08:43**

Jaime Benito de Valle wrote:By the way, Volker, the version I have for Hermann doesn't display large numbers (%d usually displays 32 bit signed), although the figures are correct after some modifications. Have you corrected this in newer versions?

The current version Hermann 1.3.5 uses a 64 bit counter.

Greetings,
Volker

Posted: **14 Apr 2005, 18:03**

Hi all,

there still are no verifications for the results of higher plys of that position.

After improving my cache using perft variant I add an extended statistic
including figures for promotion moves too.

Regards, Reinhard.

Code: Select all: FEN: rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1 +-*--b--*--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 |[r][q][k][r][b][n][n][b]| (Compilation: Apr 14 2005) 7 |[p][p][p][p][p][p][p][p]| 6 | ::: ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | (With TT Caching 256.0 MB / 4-fold) 4 | ::: ::: ::: :::| TT Access Success 38.2% 3 |::: ::: ::: ::: | 2 || Smirf Test No.: 00 1 |<R><Q><K><R><N><N>| =>+-*--b--*--*--e--f--g--h-+ Break Time 200.0 Sec. Ply Nodes all (x) (e.p.) all (+) Promot. Castl. Sec. ---------------------------------------------------------------------------------- 1 20 0 0 0 0 0 0 2 400 0 0 0 0 0 0 3 8832 99 0 40 0 0 0 4 193554 2961 0 915 0 0 0 5 4673537 129047 257 39895 0 0 0.1 6 111825069 3793709 5166 983773 0 0 1.2 7 2916765333 132941956 314652 35568323 0 37 14.4 8 75331645146 3972680374 6936954 941690347 0 12204 192.5 9 2093941843698 132045270050 304280183 32619777466 16808712 204861015 4492 ----------------------------------------------------------------------------------

P.S.: I am not sure about the last line. A newer result has been:

Code: Select all: Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 20 0 0 0 0 0 0 2 400 0 0 0 0 0 0 3 8832 99 0 40 0 0 0 4 193554 2961 0 915 0 0 0 5 4673537 129047 257 39895 0 0 0.1 6 111825069 3793709 5166 983773 0 0 1.3 7 2916765333 132941956 314652 35568323 0 37 14.8 8 75331645146 3972680374 6936954 941690347 0 12204 188.1 9 2093941558902 132045250042 304280172 32619775942 16808712 204860899 3074 -------------------------------------------------------------------------------

Regards, Reinhard.

Posted: **14 Apr 2005, 22:06**

Hi Reinhard,

Frenzee gets the same up to and including ply 8, I haven't tried ply 9.

There are better testpostions for FRC though, I have used the following
which have been confirmed by another frc engine:

[FRC - Perft]
Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1
perft 1 47
perft 2 1335
perft 3 60626
perft 4 1754084
perft 5 79306332
perft 6 2336234512

1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1
perft 1 42
perft 2 1533
perft 3 58858
perft 4 2208844
perft 5 82619281
perft 6 3163057546

One particular bug I remember finding was the long castle for black in the
first position. This kind of castling into check is only possible in FRC.

-S.

Posted: **14 Apr 2005, 23:23**

Hi Sune,

thank you for your posting! In exchange I can verify your figures:

Code: Select all: FEN: Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1 =>+-a--*--c--d--e--*--*--h-+ MS Vis. Studio C++ Vers. 13.10 8 |<R>[r] ::: [k][r]:::| (Compilation: Apr 15 2005) 7 |::: [p] :::[p][p][p]| 6 | :::[n][b][p]:::[n]:::| Perft Testseries 5 |::: :::[p]::: ::: | (With TT Caching 512.0 MB / 4-fold) 4 | [p]:::[q]:::[b]:::| TT Access Success 57.9% 3 |:::::: <N> | 2 | | Smirf Test No.: 00 1 |:::<N> <Q><K><R> | +-a--b--c--d--e--*--*--h-+ Break Time 30.0 Sec. Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 47 7 0 4 0 1 0 2 1335 151 0 40 0 43 0 3 60626 9240 1 4310 0 1409 0 4 1754084 221862 0 41138 0 51759 0.1 5 79306332 12483752 10861 5047355 0 1789561 1.3 6 2336234512 323467817 1379 49627186 0 62359539 22.9 7 104503613557 17032580975 20913802 6205691323 2817344 2158010800 388.3 ------------------------------------------------------------------------------- FEN: 1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1 +-a--*--c--*--e--*--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 | [r] [k] [r] :::| (Compilation: Apr 15 2005) 7 |[p][p][p] [b][p][p][p]| 6 | :::[n][p] ::: [q]| Perft Testseries 5 |::: ::: [p] ::: | (With TT Caching 512.0 MB / 4-fold) 4 |[b]:::::: :::<Q>:::| TT Access Success 54.5% 3 |<N> ::: [n]| 2 | | Smirf Test No.: 01 1 |:::<R>:::<K>:::<R>::: | =>+-a--*--c--*--e--*--g--h-+ Break Time 30.0 Sec. Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 42 3 0 2 0 1 0 2 1533 150 0 86 0 48 0 3 58858 6451 0 2442 0 1281 0 4 2208844 263066 34 128667 0 60664 0.1 5 82619281 11033942 124 3337584 0 1547446 1.5 6 3163057546 422595743 80606 183100448 0 73264323 26.8 7 116684109110 17568516847 474555 4813234553 0 1831394581 485.7 -------------------------------------------------------------------------------

Indeed, in the first example the long castling is initially impossible, because the involved rook b8 is pinned. Though moving along the direction of pinning, castling is impossible, because the king would face a check threat. Such a situation is indeed possible only in Chess960 (or in CRC, Capablanca Random Chess).

Regards, Reinhard.

P.S.: Oh, I noticed, that the captions of the colums have been misplaced, sorry. I have done a correction here.

Posted: **15 Apr 2005, 07:12**

Hi Reinhard,

Good that Smirf agress

I was thinking one should really also mirror the board and check that all 4
versions produce the same count.

Btw, what is the interpretation of the position when two rooks are on the
same side of the king, and he still has castle rights for that side?
I remember some time ago there was a discussion on this, but I don't
recall the outcome.

It doesn't seem possible to know this without the game
history, much like the problem with repetitions and 50 move counter.

We might see engines differ in perft here depending on their choice of
castling rook.

-S.

Posted: **15 Apr 2005, 14:23**

Hi Sune,

Sune wrote:Btw, what is the interpretation of the position when two rooks are on the
same side of the king, and he still has castle rights for that side?
I remember some time ago there was a discussion on this, but I don't
recall the outcome.

a) if a game has been played, the history will clear things up.
b) if nothing is specified except the castling side in the FEN, the OUTERMOST rook is affected.
c) if an inner rook should posses the castling right, the FILE LETTER of the affected rook has to FOLLOW its castling symbol in the FEN.

Here is an example (watch, that the castling rights also are marked by stars within the board's border):

Code: Select all: FEN: r2k3r/8/8/8/8/8/8/3K2RR w Kgq - 0 1 +-*--b--c--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 |[r]::: [k] ::: [r]| (Compilation: Apr 15 2005) 7 |::: ::: ::: ::: | Testscenario (sorted, O(n*log(n))): 6 | ::: ::: ::: :::| Move generation 5 |::: ::: ::: ::: | 4 | ::: ::: ::: :::| Smirf Test No.: 00 3 |::: ::: ::: ::: | 2 | ::: ::: ::: :::| Move Count: 22*3306712 1 |::: :::<K>::: <R><R>| per Second: 22383896 =>+-a--b--c--*--e--f--*--h-+ Time: 3.250 sec 5.695 Rh1xh8+ 0.887 Rg1-g8+ 0.445 Rg1-g7 0.438 O-O 0.402 Rg1-g6 0.391 Rh1-h7 0.359 Rh1-h6 0.336 Rg1-g5 0.305 Rh1-h5 0.262 Rg1-g4 0.238 Rh1-h4 0.180 Rg1-g3 0.164 Rh1-h3 0.098 Kd1-d2 0.090 Kd1-e2 0.090 Rg1-g2 0.090 Kd1-c2 0.082 Rh1-h2 0.055 Rg1-e1 0.035 Rg1-f1 -0.008 Kd1-e1 -0.008 Kd1-c1 FEN: r2k3r/8/8/8/8/8/8/3K2RR w Kq - 0 1 +-*--b--c--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 |[r]::: [k] ::: [r]| (Compilation: Apr 15 2005) 7 |::: ::: ::: ::: | Testscenario (sorted, O(n*log(n))): 6 | ::: ::: ::: :::| Move generation 5 |::: ::: ::: ::: | 4 | ::: ::: ::: :::| Smirf Test No.: 01 3 |::: ::: ::: ::: | 2 | ::: ::: ::: :::| Move Count: 21*3464175 1 |::: :::<K>::: <R><R>| per Second: 25861242 =>+-a--b--c--*--e--f--g--*-+ Time: 2.813 sec 5.695 Rh1xh8+ 0.887 Rg1-g8+ 0.445 Rg1-g7 0.402 Rg1-g6 0.391 Rh1-h7 0.359 Rh1-h6 0.336 Rg1-g5 0.305 Rh1-h5 0.262 Rg1-g4 0.238 Rh1-h4 0.180 Rg1-g3 0.164 Rh1-h3 0.098 Kd1-d2 0.090 Rg1-g2 0.090 Kd1-c2 0.090 Kd1-e2 0.082 Rh1-h2 0.055 Rg1-e1 0.035 Rg1-f1 -0.008 Kd1-e1 -0.008 Kd1-c1

Regards, Reinhard.

Posted: **15 Apr 2005, 18:26**

Sune Fischer wrote:[FRC - Perft]
Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1
perft 1 47
perft 2 1335
perft 3 60626
perft 4 1754084
perft 5 79306332
perft 6 2336234512

1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1
perft 1 42
perft 2 1533
perft 3 58858
perft 4 2208844
perft 5 82619281
perft 6 3163057546

Thanks Sune for your suggestion: I've found a bug that would have been almost impossible to find by trying a typical starting position like the ones we usually post here. I realized almost instantly what the problem was when I saw that rook on A8 next to the black's castling line... so I corrected it quicly.
My results now match yours and Reinhard's

Depth 1 Nodes: 47
Depth 2 Nodes: 1335
Depth 3 Nodes: 60626
Depth 4 Nodes: 1754084
Depth 5 Nodes: 79306332
Depth 6 Nodes: 2336234512

Depth 1 Nodes: 42
Depth 2 Nodes: 1533
Depth 3 Nodes: 58858
Depth 4 Nodes: 2208844
Depth 5 Nodes: 82619281
Depth 6 Nodes: 3163057546

Regards,

Jaime

P.S. - Hermann (engine) gives the same figures

Posted: **16 Apr 2005, 17:02**

Hermann 1.3.7 is available for testers at http://www.nnuss.de/Hermann/Hermann137.zip

It has a new command

Code: Select all: uci debug on position fen <fen-string> perft depth <d> Hash <m>

or

Code: Select all: perft Hash <m> depth <d>

where <m> is the size of a hash table in megabytes. The old perft command without hash still works.

Please do not use this version in tournaments.

Greetings,
Volker

Posted: **16 Apr 2005, 18:48**

Hi, I have the same perft numbers for Sune's positions.
Also in AICE 0.92 I have a new command for perft in an epd file:

Code: Select all: perft <depth> [epdfile]

This command calculates the perft for depth <depth> for all positions in the epd-file.

Posted: **16 Apr 2005, 21:15**

Hi all,

Sune wrote:I was thinking one should really also mirror the board and check that all 4 versions produce the same count.

Mirroring left to right would not work because of the asymmetric nature of castling. But switching the position up to down with changing all colors should give positions with identic perft countings. I did it for both positions:

Code: Select all: FEN: Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1 =>+-a--*--c--d--e--*--*--h-+ MS Vis. Studio C++ Vers. 13.10 8 |<R>[r] ::: [k][r]:::| (Compilation: Apr 16 2005) 7 |::: [p] :::[p][p][p]| 6 | :::[n][b][p]:::[n]:::| Perft Testseries 5 |::: :::[p]::: ::: | (With TT Caching 256.0 MB / 4-fold) 4 | [p]:::[q]:::[b]:::| TT Access Success 55.4% 3 |:::::: <N> | 2 | | Smirf Test No.: 00 1 |:::<N> <Q><K><R> | +-a--b--c--d--e--*--*--h-+ Break Time 5.0 Sec. Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 47 7 0 4 0 1 0 2 1335 151 0 40 0 43 0 3 60626 9240 1 4310 0 1409 0 4 1754084 221862 0 41138 0 51759 0.1 5 79306332 12483752 10861 5047355 0 1789561 1.3 6 2336234512 323467817 1379 49627186 0 62359539 22.1 ------------------------------------------------------------------------------- FEN: 1nb1qkr1/1ppp1ppp/1p2p1n1/1Pb1Q1B1/3P4/2NBP1N1/2P2PPP/rR3KR1 w KQk - 0 1 +-a--b--c--d--e--*--*--h-+ MS Vis. Studio C++ Vers. 13.10 8 | [n][b]:::[q][k][r]:::| (Compilation: Apr 16 2005) 7 |:::[p][p][p]:::[p][p][p]| 6 | [p] :::[p]:::[n]:::| Perft Testseries 5 |:::[b] <Q> | (With TT Caching 256.0 MB / 4-fold) 4 | ::: ::: :::| TT Access Success 55.5% 3 |::: <N> <N> | 2 | :::::: | Smirf Test No.: 01 1 |[r]<R>::: :::<K><R> | =>+-a--*--c--d--e--*--*--h-+ Break Time 5.0 Sec. Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 47 7 0 4 0 1 0 2 1335 151 0 40 0 43 0 3 60626 9240 1 4310 0 1409 0 4 1754084 221862 0 41138 0 51759 0.1 5 79306332 12483752 10861 5047355 0 1789561 1.3 6 2336234512 323467817 1379 49627186 0 62359539 22.3 ------------------------------------------------------------------------------- FEN: 1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1 +-a--*--c--*--e--*--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 | [r] [k] [r] :::| (Compilation: Apr 16 2005) 7 |[p][p][p] [b][p][p][p]| 6 | :::[n][p] ::: [q]| Perft Testseries 5 |::: ::: [p] ::: | (With TT Caching 256.0 MB / 4-fold) 4 |[b]:::::: :::<Q>:::| TT Access Success 57.9% 3 |<N> ::: [n]| 2 | | Smirf Test No.: 02 1 |:::<R>:::<K>:::<R>::: | =>+-a--*--c--*--e--*--g--h-+ Break Time 5.0 Sec. Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 42 3 0 2 0 1 0 2 1533 150 0 86 0 48 0 3 58858 6451 0 2442 0 1281 0 4 2208844 263066 34 128667 0 60664 0.1 5 82619281 11033942 124 3337584 0 1547446 1.5 6 3163057546 422595743 80606 183100448 0 73264323 26.3 ------------------------------------------------------------------------------- FEN: 1r1k1r2/pppb1p1p/n2pp1pN/B1b3q1/4P3/2NP3Q/PPP1BPPP/1R1K1R2 b KQkq - 0 1 =>+-a--*--c--*--e--*--g--h-+ MS Vis. Studio C++ Vers. 13.10 8 | [r] [k] [r] :::| (Compilation: Apr 16 2005) 7 |[p][p][p][b]:::[p]:::[p]| 6 |[n]::: [p][p]:::[p]<N>| Perft Testseries 5 | [b] ::: [q] | (With TT Caching 256.0 MB / 4-fold) 4 | ::: :::::: :::| TT Access Success 57.9% 3 |::: <N>::: :::<Q>| 2 |:::| Smirf Test No.: 03 1 |:::<R>:::<K>:::<R>::: | +-a--*--c--*--e--*--g--h-+ Break Time 5.0 Sec. Ply Nodes all (x) (e.p.) all (+) Prom. Castl. Sec. ------------------------------------------------------------------------------- 1 42 3 0 2 0 1 0 2 1533 150 0 86 0 48 0 3 58858 6451 0 2442 0 1281 0 4 2208844 263066 34 128667 0 60664 0.1 5 82619281 11033942 124 3337584 0 1547446 1.5 6 3163057546 422595743 80606 183100448 0 73264323 26.0 -------------------------------------------------------------------------------

Volker wrote:... where <m> is the size of a hash table in megabytes.

It is great to see another perft and cache combination!

Regards, Reinhard.

Winboard Forum

FRC position

FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position

Re: FRC position