End of run statistics

End of run statistics

 

The end of run statistics try to give a synthetic view of what happened in the run.

 

The final count sum each band count. These counts are supposed to be reworked later to give ratios of value.

 

Room to collect 40 values has been included in the program. Currently, 23 are active, and the print table is in the top part of the file go_17sol_commands_cpp.h

 

       "0 bands1+2 processed entries M10",//0

       "1 chunks processed entries gochunk",//1

       "2 XY count",//2

       "3 XY passing UA filter",//3

       "4 XY brute force",//4

       "5 valid brute force",//5

       "6 number of y3 ",//6

       "7 total bands 3",//7

       "8 valid b12 after build active",//8

       "9 band3 active after build active",//9

       "10 critical band3",//10

       "11 not critical 1",//11

       "12 not critical 234",//12

       "13 not critical 56",//13

       "14 using socket 3",//14

       "15 entry band3 handler excluding critical+ua outfield",//15

       "16 critical + sub critical",//16

       "17 add 1 from active",//17

       "18 n uas at start",//18

       "19 n gua2s at start  ",//19

       "20 n gua3s at start  ",//20

       "21 n sockets2",//21

       "22 n sockets1",//22

 

The run is for a unique band1, and a slice of bands 2 depending on the checkpoint limits  given in the command line. The overall run time is printed at the end of the run.

 

All  bands 2 are counted for the checkpoint, but only bands 2 having bands 3 attached are processed (“0”). The number of bands 3 (“7”)  per bands 1+2 is over the average (9 bands 3) with low index band1 and close to 1 for high index band1. This influences strongly the number of GUAs sockets (“21” “22”) and the “8” “9” values.

 

Only 2 values are describing the steps/chunks behavior :

 

The number of chunks “1”

The number of  3y steps. “6” This value is expected to be small with bands 1 of low index and relatively big for higher index.

 

XY count and remaining XY

This is the main parameter followed.

The original XY count is the product nx * ny. Other XY count are done in specific places in the process. “2” “3” “4” “5” “8”

 

The last count “8” is where some bands 3 passing all control where seen. This is also where we switch from a band 1+2 analysis to a band 3 process. “9” / “8” gives the ratio of bands 3 per bands 1+2 at this point. This ratio is usually much smaller than the original ratio “7” / “0”

 

Last values “10” to “17” give an idea of the distribution of the “miss” cases in the bands 3 process

 

Results  band1 index      6       checkpoint limits 13500        14000

 

Here are the result of a test run done on my laptop with 2 cores active for a slice of 500 x64 bands 2.

The band 1 is the band index 6, known to produce several 17 clues with the searched distribution.

The overall time was close to 13 hours.

 

                                                       time/             av b3

bands3                    548231        0.085           18.49

bands1+2                29648          1.57 1         

 

Here the average run time per band 2 was 1.6 second. With an average 18.5 bands 3 attached, this gives  85 milliseconds per band 3. No 2x3y step was done in this run.

 

 

                                            per band     

nua                                      248    

n guas sock2                    2436  

n guas sock3                    2066  

nsock2                               79      

nsock3                               55      

 

The average number of UAs at start is relatively small. Test show that as soon as the number of XY requiring a bands 1+2  validity check grows, fresh uas with 6-9 digits are produced and the limit of 2000 uas can be reached. 

 

With an average 18 bands 3 per bands 1+2, the number of active sockets is close to the maximum 2 x81. the average number of guas produced at start is in the range 30-40 uas per socket. If we go in details, this is a mix of

very low numbers. one gua 2cells (plus the 2 cells in band 3) as a minimum when a grid UA size 4 exists

A number close to the limit of the table.

 

This is likely the place where a better set of UAs can be defined at the start (and for all the run, no addition are made in this set)

 

 

                                            ratio/XY                

XY                                                            33 431 838 

  passing ua filter             0.3252%      108 720      

  test brute force               0.1539%      51 456        

  valid brute force           0.1095%      36 624        

  giving bands 3               0.0531%      17 749        

 

This table shows the efficiency of the phase 1 for the clearing of XY.

Here, we have a relatively small number of XY, As a consequence, we have a limited number of calls to the brute force, not many UAs added.

However, the ratios of XY not cleared are already below 1%.

 The first ratio .325 % should go below 0.1%  with a higher number of XY (over 2 billions with high index of band 1)

 

                                 av b3

Bands3 processed                     51 741         1.75

  critical       61.54%        31 840        

  miss 1        29.53%        15 281        

  miss 234    8.92%          4 616 

  miss 56      0.01%          3        

 

This table shows more the efficiency of the GUAs collection.

Gus already contributed to the XY clearing above, checking the stack limit where th XY was close to the limit.

Here, we see the ration 1.75 band 3 processed per XY “valid”, far below the original 18.49 bands3 per band 1+2.

This means that 90% of the bands 3 either globally pass the 6 GUA2s GUA3s count or produce a stack with a minimum of given >6.

More than 90% of the bands 3 to process have an identified minimum number of clues >=5.

We have here a good example of the clearing power of the socket GUAs . A better start mix could still improve the situation.

We see also here that a band 3 with less than 2 clues out of the minimum GUA2sGUA3s count has a very low frequency.