Timing issue with Malfunctions

[Ravio-li]

The context provided when a malfunction occurs has constraint rules describing actions that have already taken place and ones that require wait actions during the malfunction duration.

Action at timestep 14 in this example causes an issue. The encoding must generate this action, but the malfunction will already occur at timestep 14 and ignores all given actions.

This means primary encodings cannot solve Env's with malfunctions right now. Removing the last action from the context past actions might still cause desync issues. The train must wait at the first timestep of the malfunction, ignoring the last occured action as it did nothing in Flatland either.

Alternatively, a primary encoding can use the malfunction(ID,Duration,Timestep) fact to simulate the lost action. I will try this out next. Maybe this is better than changing the provided context.

[helloKep]

Thanks for sharing this, @Ravio-li. It looks like it is as simple as adjusting the range of time steps being passed into the convert_formers_to_clingo function.

I've changed two lines of code in solve.py from this:

past = convert_formers_to_clingo(actions[:timestep+1])
present = convert_malfunctions_to_clingo(malfunctions, timestep)
future = convert_futures_to_clingo(actions[timestep+1:])

to this:

past = convert_formers_to_clingo(actions[:timestep])
present = convert_malfunctions_to_clingo(malfunctions, timestep)
future = convert_futures_to_clingo(actions[timestep:])

By removing the +1, in your example then the action at time step 14 would not be encoded as an enforced move. I'm not sure about whether it would be necessary to adjust the malfunction scope (in your example lines 84-87). I don't currently have test instances with malfunctions, so if you could try the new version of solve.py and let me know whether that fixes the problem, that would be great. If this is the only fix necessary, I'll be excited to close out this issue.