Issue1150

Title Duplicate constraint entries in potential optimizer
Priority bug Status resolved
Superseder Nosy List florian, jendrik, malte, silvan
Assigned To florian Keywords
Optional summary
PR: https://github.com/aibasel/downward/pull/230

Created on 2024-08-29.15:17:58 by florian, last changed by florian.

Summary
PR: https://github.com/aibasel/downward/pull/230
Messages
msg11688 (view) Author: florian Date: 2024-09-05.15:11:38
We discussed this on Discord and saw an interaction with issue1146:
If we decide that tasks have to satisfy the original assertion and that task transformations have to maintain the properties, then the bug is not in the heuristic but in the task transformation that introduces the effect on the prevail condition.

We will still merge this change now, which is not wrong and in the worst case, redundant later on.
msg11687 (view) Author: florian Date: 2024-08-29.15:40:44
I created a PR with the change. Seems straight-forward enough. Any objections to merging this?
msg11686 (view) Author: florian Date: 2024-08-29.15:17:58
When constructing the LP for potential heuristics, we have an assertion that prevail conditions are encoded as a precondition without an effect (instead of a precondition with an effect that sets the same fact again). This is important because if we loop over effects and look up the corresponding precondition, we would not get a self loop. For the LP, every outgoing edge occurs in the constraint with coefficient +1 and every incoming edge with -1, so a self loop cancels out. If we are not skipping self loops, however, we end up adding the same variable once with coefficient +1 and once with -1, which is not allowed in the interface of the solver and can lead to segfaults.

For the root task, the assertion is valid, because we parse it in way that prevail conditions are represented only as a precondition. But if the potential optimizer is used on a transformed task, the assertion can fail. 

Instead of asserting that the precondition of a variable is different from its effect, we can just check for this and skip the effect if it corresponds to a prevail condition.
History
Date User Action Args
2024-09-05 15:23:25floriansetstatus: reviewing -> resolved
2024-09-05 15:11:38floriansetmessages: + msg11688
2024-08-29 15:40:44floriansetstatus: unread -> reviewing
messages: + msg11687
summary: PR: https://github.com/aibasel/downward/pull/230
2024-08-29 15:17:58floriancreate