0

I know that in durative effects, I can compute based on #t, which is some flavor of elapsed time. But from the examples I see, it seems to be more like the duration of the effect itself: for instance, boil water, and heat it by a certain amount for the time it boils. Whereas, I want to have a cost that factors in total elapsed time since the start of the entire plan. Is that a different variable?

I tried (increase (total-cost) (* #t (num-not-yet-fixed ?group))) Where the num-not-yet-fixed goes down over time, and the idea is to increase the cost by a higher value if more things being "fixed" are fixed later rather than earlier. But (a) popf rejected the use of #t here, it seems, and (b) it seems like even if it worked, it would be for the fixed duration of the durative effect, and not since the start of execution.

Fred Douglis
  • 141
  • 10

1 Answers1

0

Any chance you can create a new function, say (now), that starts at 0, is added to linearly over time via a full-plan envelope action, and then used by the other actions to refer to things?

Something like this...

(:durative-action measure-time
 :precondition (begin)
 :effect (and
   (at start (going))
   (at start (not (begin)))
   (at end (not (going)))
   (increase (now) #t)
 )

; all other actions have a condition (over all (going))

; any action that needs to refer to the current time in the plan can use the function (now)

...and the init would have:

; used so that the measure-time happens only once
(begin)

; a function to measure the current time and use in an action
(= (now) 0)

...and the goal should be modified to also include (not (going))

haz
  • 625
  • 4
  • 12
  • First I guess I'd have to understand a "full-plan envelope action" :). But this means there really isn't the idea of a wall clock available to the actions? Quite surprising! – Fred Douglis Feb 28 '23 at 21:23
  • Google doesn't know that phrase, so I'm not exactly sure how it would work. I could add it in each other function, but then I'd double count if multiple functions are invoked in parallel. Can you please elaborate? – Fred Douglis Feb 28 '23 at 21:25
  • I'll add that if I whittle down the phrase to simply _envelope_ I do find hits, but mostly more theoretical stuff, not actual PDDL examples so far. So I still don't know how to use this suggestion. (As you can probably tell, I'm new to this area.) I appreciate all the feedback! – Fred Douglis Feb 28 '23 at 21:36
  • Sorry about that. Just meant that you have a single new action that encompasses every other action (using a new fluent like `(going)` to do this). That one new action is effectively marking the passage of time, and the only thing that changes the `(now)` value. – haz Feb 28 '23 at 23:02
  • I still don't quite see how it counts elapsed time of the form of the durations of actions, rather than the total number of tasks executed. So yeah, I could have every action increment a count, and it would be a rough idea of progress, but when many things can happen in parallel, or take a long time, it wouldn't really reflect time. – Fred Douglis Feb 28 '23 at 23:36
  • The actions don't increment the value. Only the mega action does. It should increment it as a (linear) function of time. Then all the other actions just need to fit within it. I.e., start & end entirely during the mega-action. All of the other actions could read from it, but just not write to it. – haz Mar 01 '23 at 19:36
  • I'm afraid I still don't see how it works. Is there a public example of this? – Fred Douglis Mar 01 '23 at 23:00
  • None immediately come to mind. Just updated the response to show the example. – haz Mar 03 '23 at 01:43
  • Thanks again, @haz. I've tried using this and am getting syntax errors (with no further info and nothing obviously amiss), including after I changed "precondition" to "condition (at start..." Increasing verbosity doesn't tell me what it doesn't like. – Fred Douglis Mar 03 '23 at 18:04
  • So an update on this. I'm not sure exactly why popf was balking. It seems like it didn't like the missing duration in the durative action. I tried running it with an explicit duration, and it executes, but it just keeps running for hours. With some verbose debugging I got: ``` .........................d...............................d...............................d...............................d...............................d............... ``` indefinitely. Tried trimming my problem but without any effect, it still blows up. From the envelope I assume? – Fred Douglis Mar 07 '23 at 19:49
  • I reran without the detailed debugging, and came back to it hours later with it being killed. I suppose it had a memory leak or something. `Initial heuristic = 37.000 b (36.000 | 1.000)b (35.000 | 1.001)b (34.000 | 1.001)b (33.000 | 1.001)b (32.000 | 1.001)b ...22.008)b (6.000 | 22.008)b (5.000 | 27.007)b (4.000 | 27.008)b (3.000 | 27.008)b (2.000 | 27.008)b (1.000 | 27.008) Resorting to best-first search b (36.000 | 1.000)b (35.000 | 1.001)b (34.000 | 1.001)b (33.000 | 1.001)b (32.000 | 1.001)b ... | 27.007)b (3.000 | 27.008)b (2.000 | 27.008)b (1.000 | 27.008)Killed` – Fred Douglis Mar 08 '23 at 15:24
  • Maybe run with optic using `-T` (forces it to search in a total ordering rather than partial -- sometimes useful) – haz Mar 09 '23 at 03:00
  • I was so hoping that would do it, but it's been running for close to an hour, and grown to close to 100GB, without producing a result. – Fred Douglis Mar 10 '23 at 15:55
  • I'm still very confused why it doesn't allow the durative action without a duration. You suggested a version without it, and I tried that at length, always hitting syntax errors and such. When I added duration=1, it ran, but blew up. Certainly making the overall duration be just 1 when individual steps take longer would be problematic ... so I tried increasing the envelope to a fixed duration of 100 (longer than any of the steps would cumulatively take). It now makes more progress but prints a boatload of "(G)" and seems to come up with a worse plan than before. LOL. – Fred Douglis Mar 10 '23 at 16:14
  • Another update: I've noticed that popf seems to run OK with my latest version, whereas optic hangs, with or without the `-T` flag or other ones I've tried. But it's progress... – Fred Douglis Mar 13 '23 at 15:08
  • I probably declared victory a bit early there. The "latest version" was a slimmed down problem with one group of thingies that could only be selected a smaller number at a time. But if I use the original problem, with three groups that each can have some number selected, popf behaves like optic was with the smaller problem, hanging while it blows up. – Fred Douglis Mar 13 '23 at 20:58
  • 1
    I think it always needs that duration spec. Maybe you could get away with saying the duration is just greater than or equal to 0? – haz Mar 14 '23 at 17:06
  • thanks, _progress!_ With that change, I got popf to run with the full set of objects, though optic still blows up with (G) forever. So that's something. What I don't understand is why it outputs that the total cost is 0. I have a function (total-cost), which I _increase_ each time the main action is performed, and for which the metric is to minimize that value. The plan seems reasonable, but I want to be able to play with the formula for `total-cost` and cause it to make different decisions based on how cost is added. If you have any thoughts (or even how to debug .... – Fred Douglis Mar 14 '23 at 18:59
  • Actually, hold off on that: while I wasn't seeing it toward the end of the output if I enabled verbose debugging, I see that it is tracking some changes earlier in the processing, which maybe I can sort out. – Fred Douglis Mar 14 '23 at 19:01
  • Yeah, I don't get it. If I look at the logs (`-v100`) I see it seeming to adjust total-cost by reasonable values, but then it still says the range is 0,0. Then at some point it declares the range is 0, X where X is a, I don't know, 200-digit number, which is then shown as 0,inf (infinity). Neither 0 nor infinity as an upper bound is reasonable. – Fred Douglis Mar 14 '23 at 19:14
  • Weird...any chance you can get things checked through VAL? It's available on planutils if that's what you happen to be using: `val -l domain.pddl problem.pddl plan.out > out.tex` (and then compile the latex) – haz Mar 16 '23 at 03:00
  • It looks like you meant `val Validate -l ...` -- I was surprised `val --help` failed after `val -t` but `val help` without hyphens set me straight. So I did that, and it complained that the plan I fed it didn't satisfy goals. I looked at what popf said, and it output that it was taking the necessary steps, but it wasn't including the side effects -- so the end goal was never mentioned. Maybe a different option to popf so that val sees under the covers? – Fred Douglis Mar 16 '23 at 17:03
  • I even tried popf -v 20 which showed that `at end` it was setting the things val was complaining about, but val still says no goal is satisfied. – Fred Douglis Mar 16 '23 at 19:14
  • Same with optic? – haz Mar 17 '23 at 18:05
  • For this one, optic just keeps stuttering: `(G)(G)(G)(G)(G)(G)...` It does produce a plan before that happens, which seems to be the same as POPF. In any case, val makes the same complaint about not meeting goals. – Fred Douglis Mar 17 '23 at 19:16
  • 1
    I suspect now both solvers can't handle such a thing. I've stripped it down to a fairly minimal example ( http://editor.planning.domains/#read_session=JNYvJV9480 ), and have reached out to the planner authors to see what they say. Will report back here. – haz Mar 20 '23 at 00:03
  • So, it's been a week; I'm still hoping you'll get an answer but I can't say I'm holding my breath. Is there a different planner that actually handles your example? – Fred Douglis Mar 27 '23 at 19:42
  • Aye, I think they just went and had another kid, so haven't been responding at all ;). No other planners that I'm aware of -- it's not exactly my sub-field of planning. You can come raise the question in the community slack ( slack.planning.domains ), as there may be some extra eyes over there. – haz Mar 28 '23 at 20:04
  • OK, thanks, I'll try that. Kids! They only get in the way. ...... – Fred Douglis Mar 29 '23 at 21:17