I have noticed that in the Sevan Memorial tournament, Premier section (November 23-25, 2018), due to a computer glitch the MSA crosstable is missing the color assignments in rounds 1 and 2 for players who entered the 2-day schedule. (Other sections are not affected, the 3-day players are not affected, and rounds 3-5 are not affected.)
For anybody who wants to know the missing colors, here are my reconstructions. Player numbers and post-event ratings below are as seen on the MSA crosstable.
[/code][/size]
I had nothing to do with organizing or directing this tournament, although I played in it. (Nice job, by the way!) I’m just trying to be helpful. According to one of the TDs, adding these colors to the MSA crosstable after the fact may, for technical reasons, be impossible or highly inadvisable, so those of you who want the color information might be stuck with the above reconstruction.
It is very time-consuming to add colors to an event after it is rated because it has to be added to the individual player record for all players in the event. My guess is it would take the office around 10 minutes to update the approximately 16 players in the Premier section with missing colors.
It’s not all that easy for the submitting TD to add it to the online editing form during event validation, either. So if something goes wrong with creating or parsing the upload files, or if the upload format was the older one that doesn’t include color data, color data is probably not going to be added afterwards.
One thing that has happened in the past is a corrupted file that had to be restored from a report saved to the web. That report did not have color information and subsequent pairings were made assuming no color for those games.
My current speculation is that the 2-day and 3-day schedules might have been merged (after round 2) before all the round 2 results were entered (i.e. all the pairings were there, but a few of the results were not). This is reminiscent of a bug in a much older version of SwissSys (long since corrected), wherein late-arriving players (with half-point byes) could not be added for round 2 until all of the round 1 results were entered.
I hope that didn’t happen in this case. If it did, you can throw all those reconstructed colors out the window. If anybody becomes aware of any errors in the reconstructed colors, please let me know.
We process merged events all the time, including most CCA events, if there was a systemic problem in either one of the pairing programs or the upload/parsing programming, surely we’d have seen it before now.
A merge has to carry color information into the merged event, otherwise how could it do pairings correctly?
We haven’t changed anything on the server end that would impact uploading/rating events in several months, so unless this was a new release of whatever pairing program was used, I’m guessing some kind of one-off problem that may be nearly impossible to reproduce.
Yes, that section was FIDE rated. Assuming Bill Smythe is correct, the problem was that the color information for (I think) 16 players who were all in one of the pre-merge schedules is missing. When I get a chance, I’m going to see if I can locate the original upload files (we save them for a period of several weeks) and see if they had the color information for the first 2 rounds or not.
The color information appears to be there, so it looks like the upload/parsing program is the problem. I think Tom nailed it, though, it appears to be whether or not the game was FIDE ratable, because there’s an asterisk as the final character of the field (following the color) if the game is not FIDE ratable, and it looks like the parsing program isn’t dealing with that correctly. Interesting that nobody has pointed this out before, must not be a lot of FIDE rated events that utilize that field.
Executive Summary: Nothing to see here, folks, move along.
Detail: This was the result of a bug in SwissSys version 9.69. In a nutshell, versoin 9.69 generated an incorrectly formatted rating report if two sections were being merged, the merged section was FIDE rated, and some games had to be marked as not FIDE rated (because the time control was too fast, for instance). Under these circumstances, the results of the non-FIDE rated games was “broken.” When I submitted the rating report, I had to correct the results by hand, and I did not notice at the time that the colors for those games were missing.
This bug has been reported to Thad Suits, and he has already produced a fix in SwissSys version 9.7. I have also verified that, with this fix, the colors are present for the non-FIDE rated games.
I cannot say whether version 9.69 was correctly following an existing specification for the .DBF files for a rating report. In any case, the erroneous behavior is gone in SwissSys 9.7.
Actually, while there may have also been SS bugs, this specific bug was in the upload file parsing program. There are 4 components to the game result field:
Game Result
Opponent Pairing Number
Color
FIDE Status Flag (an asterisk if the game was not FIDE ratable)
Only the first 2 of these are required, and in fact for RR events only the first is given because the opponent number is determined by the column (eg, round), round 1 is pairing #1, round 2 is pairing #2, etc. The round that matches that player’s pairing number gets an asterisk, producing the classic RR table:
Player 1 *WWL
Player 2 L*DD
Player 3 LD*W
Player 4 WDL*
The upload parsing program should have ignored the asterisk, as FIDE status is not part of the pending events data. Fixing this will mean less work for TDs submitting FIDE ratable events, as the bug caused any rounds with the FIDE status flag set to be invalid.
This bug is in large part a result of the fact that the draft format was never actually approved, but when WinTD started using it we decided to process the color data as it was information players wanted us to collect and show. The FIDE status flag was overlooked, as it is not part of the pending events data that the online editing program utilizes.
Thanks to both Mike N. and Ken B. (and Thad Suits, too) for their work on this.
I gather, then, that the colors in rounds 1-2 were known to the pairing program (and taken into account) when round 3 was paired, and that they disappeared only later as part of a manual fix-up.
In that case, I feel confident in the reconstructed colors I posted at the top of this thread.
The color information for the 16 affected players disappeared when the upload files were processed during submission of the event for rating. This bug has been corrected, there are no plans at this time to retroactively correct any affected events.
Correct, SwissSys did not lose any color information at all. As Mike has confirmed, SwissSys uploaded the color information and the FIDE “not rated” status flag. That’s why when I first submitted the rating report I had a bunch of results that looked like “D24B*” (draw against player 24, had black, not FIDE rated) that were flagged as invalid. Once I realized the “D24” part was correct, I could fix the rating report by hand.
I also checked that SwissSys correctly excluded those games from the FIDE rating report before sending the SwissSys files to Grant Oen.
