Being curious and also interested in organizing events in similar format,
is MUIR setup ready for this kind of merged section to appear as one section ang get rated correctly?
Or the merged section (1-day 3SS G/10 d2 + 3SS G/60 d5 and 2-day 6SS G/60 d5, merges in Round 4) still has to be submitted and rated as THREE sections:
Only the rounds that are faster than 30 minutes (MM+SS) have to be separated from the slower rounds. You CAN mix dual-rated and regular-only rounds, that section will be regular-rated only.
Keep in mind that before dual-rating existed (it was created to improve the reliability of quick ratings), G/30 events were regular rated, so this is no change from historical practices for regular-rated games, but dual-rated events cannot have any rounds slower than G/65 (MM+SS).
MUIR does not currently have the ability to record time controls by round or schedule, so you enter the slowest of the time controls, and excluding blitz or quick-only rounds is done on the honor system, which means if you’re caught doing it, you will likely face sanctions.
Before MUIR could do anything with mix rating systems in same tournament I think the software would need to track rating system on a game level – round isn’t sufficient since they can be mixed (by round with a game override?)
I think the bottom line is the case that happens most of the time is the regular vs dual and that is ok to rate as regular only.
The next case which was talked about is the Blitz, Quick, Dual which is based on rounds and that really mitigated MUIRwise by 3 sections and is up to the software/manual to provide the framework for the scoring/pairing/standings rules.
of course >99% would never consider these so my O is the resources are much better spent on other things!
I think the only way the time control could be different in the same round for players is if the section has multiple schedules that are merged. The old system could handle both a section where the time control changed from round to round but was the same for everybody in any given round and a section with merged schedules where the time control could be different in any given round due to merged schedules.
A limitation with merged schedules is that the pairing programs don’t always keep track of which schedule someone was in, so although it could report the various time controls used for a round, it was not clear which time control applied to the games for a specific player.
If we decide to implement detailed time control information on MUIR, it would be desirable to include information about merged schedules so it is clear which time control applied to each game. That would likely force the pairing programs to change what they keep in a merged section. (WinTD doesn’t track which pre-merge schedule someone was in, for example.)
The limitation on not having time controls faster than 30 minutes mixed in with dual or regular-only games is a statistical data issue, there’s plenty of evidence that faster time controls (like blitz or quick-only) are more likely to produce upsets than slower ones. There are no plans to allow a section to contain blitz or quick-only games along with dual or regular-only games.
We may need to update the time control information to allow for time controls where the increment/delay is not the same throughout the game. (FIDE has run events where the increment didn’t start until move 40.) As far as I know, there is scant interest for organizers running those types of events in the USA.
Several of the example time controls from the US Chess rulebook don’t have increment/delay starting until later in the game.
What we have consistently stated for quite a few years is that any increment or delay setting is assumed to be in effect for the entire game, because the idea of an increment/delay that didn’t start until the 2nd time control didn’t exist in 2012.
A format that accommodates multiple increment/delay settings would probably have to look something like this in shorthand form, with each time control subfield including the increment/delay in effect for that time control. Example below. (Note that this just a prototype, not an official shorthand notation form.) The rulebook and other places where time controls examples are given will need to be revised.
40/90d0;SD/60+30
As of a week or so ago, any time control that does not explicitly state increment or delay is being rewritten during event validation to include ;d0. This change will be eventually be retroactive to the start of MUIR, but that update has not yet been made.
That never made any sense based on the rulebook examples, though; 40/90 SD/30 inc/30, to take the literal first example from the 5C TD TIP, would never have been interpreted as “40 moves in 90 minutes but gaining 30 seconds each move, followed by a sudden death time control of 30 minutes with a 30 second increment.” It always would have been interpreted as your 40/90d0;SD/30+30.
Except that was NEVER how it was interpreted. In 2012, I don’t think there were even any clocks that allowed changing the increment/delay between time controls.
The shorthand time control uses a semicolon between the time control(s) and the increment/delay to (hopefully) make it clear that it applies for the entire game, ie
G/30;d0
40/90, SD/30;d5
Could it stand being updated? Yes, it needs to keep up with evolving time control usage, and increment/delay settings that can be different in each time control now exist, though as far as I know they aren’t being used much in the USA and a lot of increment/delay clocks don’t have that capability, I’m not sure even all the latest models do. (The rules committee would probably be better informed about that.)
But we will need to have some discussion with the rules committee and the developers as to what an appropriate shorthand notation form should be.
Requiring TDs to enter 40/90d5,SD/30d5 or 40/90+15,SD/30+15 seems a tad redundant, but that may be a necessary redundancy.
From an event validation point of view, the information is needed to determine what the total time for a 60 move game will be, including increment or maximum delay usage, because that affects which ratings system(s) the section uses. My suspicion is that any event that has two time controls with increment/delay changing in those time controls will usually be a long enough game to be regular-only rated, but the validation code cannot make that assumption.
…the DGT North American clock was released in 2012. And it’s not even that fancy a clock.
Personally I am strongly in favor of having the same delay or increment throughout a game regardless of how many time controls there are. The DGT NA (and a number of other clocks) are often set to only trigger the next time control when all of the time from the first one is used up. The reason for that is that there is not a clock on the market that has a move counter. They only have button press counters and there have been a number of cases where a clock that reads the button presses as moves ended up in causing flagging problems (either too early or too late).
What if we put 40/120, d/0; SD/30, d/5 or 40/120; d/0, SD/30; d/5? Will MUIR accept those time controls in one game? If so, what is the correct syntax for the controls?
I do not believe that MUIR is currently capable of accepting that type of format, but I haven’t tried it, nor do I plan to, because that is not part of the current specs for time controls. I’ve got more than enough to do just checking on the things that are supposed to work.
Why not try it yourself and see what happens?
I know this is off topic but what do you think about the way the LEAP KK9909 and LEAP KK9908 clocks (both of which are FIDE certified) handle adding the subsequent time period to the display? On these clocks, the subsequent time period is always added to the display for both players once one player runs out of time in the current time period (and having the freeze function on doesn’t change anything here). If the prescribed number of moves in the current time control were met (according to the clocks “move counter”), a solid white flag appears on the side that ran out of time in the current time period. If the prescribed number of moves in the current time control were not met, a solid black flag appears on the side that ran out of time in the current time period. Whichever flag appears, it stays on the screen for five minutes of real time. (As a side note, when a player runs out of time in a sudden death time control, the clock shows a flashing black flag). The clock also shows what time period the clock is in by having either a “1”, “2” etc. displayed on each players side.
Micah. are you saying that time is added to both sides once White runs out of time?
There is (at least) one very rare case where that might be an issue. If Black is in the restroom while White is flagging on move 38 of a 40 move time control. Then the flag may disappear before Black gets back. Then Black would have to overlook both the sudden time increase and the (time control) 2 being displayed.
If the clock was started a half-move early (Black’s time running first and then White’s time starting for the first move - resulting in the clock thinking White is playing Black and vice versa) then if Black flags on the final move of the time control the clock will think it is White flagging in the first move of the next time control and it will display a white flag. Any white flag display should still trigger a scoresheet review so that is not a big issue.
I dislike clocks that can handle only a single time control so it is nice to see LEAP making ones with multiple time controls.
PS do they do US Delay, Bronstein delay or both?
The subsequent time control period is added to the display for both players once one of the players (white or black) runs out of time in the current time control.
Both clocks do US delay but not Bronstein delay. The KK9908 covers up the base time while showing the delay countdown but the KK9909 does not.
