Faster translation from PDDL to SAS

[Victor PALEOLOGUE]

Dear fast-downward community,

I am working with fast-downward on simple problems and it is not as fast as I expected: it appears clearly that the planning is indeed super fast (amazing, thanks), but the translation part (from PDDL to SAS, written in Python) is actually much much slower.

Would there be a way to improve its performance?

For instance can I replace it with a C/C++ library to make it faster?

Best regards,

Victor

This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system.
This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives.

---

Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés.
Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système.
Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée.

[Malte Helmert]

Dear Victor,

can you share some example PDDL files with us, and also information on
the planner configuration/command-line string you are using? There may
be a simple solution or workaround, or if not we could see if there is
something we can improve in the future.

Patrik Haslum mentioned recently that he has alternative code that can
generate SAS+ files that should work with Fast Downward's search
component, though when using external generators there are some caveats;
the search components is quite picky about input being normalized in a
certain way. (See the recent threads started 1-2 weeks ago by Marcos
Martín Pozo Delgado.)

Best regards,
Malte

On 13.08.20 10:01, Victor PALEOLOGUE wrote:
> Dear fast-downward community,
>
> I am working with fast-downward on simple problems and it is not as fast
> as I expected: it appears clearly that the planning is indeed super fast

> (amazing, thanks), but the /translation/ part (from PDDL to SAS, written

> in Python) is actually much much slower.
>
> Would there be a way to improve its performance?
> For instance can I replace it with a C/C++ library to make it faster?
>
> Best regards,
> Victor
>

> /This email and any attachment thereto are confidential and intended

> solely for the use of the individual or entity to whom they are addressed.
> If you are not the intended recipient, please be advised that
> disclosing, copying, distributing or taking any action in reliance on
> the contents of this email is strictly prohibited. In such case, please
> immediately advise the sender, and delete all copies and attachment from
> your system.
> This email shall not be construed and is not tantamount to an offer, an
> acceptance of offer, or an agreement by SoftBank Robotics Europe on any
> discussion or contractual document whatsoever. No employee or agent is
> authorized to represent or bind SoftBank Robotics Europe to third
> parties by email, or act on behalf of SoftBank Robotics Europe by email,
> without express written confirmation by SoftBank Robotics Europe’ duly
> authorized representatives.

> /
>
> ------------------------------------------------------------------------
>
> /Ce message électronique et éventuelles pièces jointes sont

> confidentiels, et exclusivement destinés à la personne ou l'entité à qui
> ils sont adressés.
> Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas
> divulguer, copier, distribuer ou prendre toute décision sur la foi de ce
> message électronique. Merci d'en aviser immédiatement l'expéditeur et de
> supprimer toutes les copies et éventuelles pièces jointes de votre système.
> Ce message électronique n'équivaut pas à une offre, à une acceptation
> d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion
> ou document contractuel quel qu’il soit, et ne peut être interprété
> comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est
> autorisé à représenter ou à engager la société par email, ou à agir au
> nom et pour le compte de la société par email, sans qu’une confirmation
> écrite soit donnée par le représentant légal de SoftBank Robotics Europe
> ou par toute autre personne ayant reçu délégation de pouvoir appropriée.

> /
>
> //
>
> --
> You received this message because you are subscribed to the Google
> Groups "Fast Downward" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fast-downwar...@googlegroups.com
> <mailto:fast-downwar...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fast-downward/536d893e-09c6-47bb-a944-c634c8a33fe5n%40googlegroups.com
> <https://groups.google.com/d/msgid/fast-downward/536d893e-09c6-47bb-a944-c634c8a33fe5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[stes...@unibz.it]

Hi Victor, we had a similar problems with an evaluation of different techniques for solving reachability problems on workflows. I tried to drill down the causes for the slowdown and I'm pretty sure that in our case was due to the size of the result of the grounding stage. 

My understanding is that during the conversion to SAS a Datalog like program is generated and its minimal model it's used for constructing the SAS to be used in the search phase. In our experiments this minimal model exceeded the memory allocated for the experiments and took most of the computing time. The computation of the minimal model is implemented in Python, so I thought that it could be improved. Therefore I took the generated Datalog program and used the Clingo ASP system to compute the minimal model (we can hardly beat clingo on that). Unfortunately the results are more or less the same, both memory and CPU wise, so I don't believe that there's much room for improvements on that side.

My feeling is that for some kind of problems we hit the limitations of grounding-based techniques, in fact when compared with symbolic model checking (we used nuXmv) we realised that, although in general less efficient, the system was able to solve instances that FD couldn't manage. I'm not sure what would be the way out in your case, you can try to reduce the "size" of the problem (the number of the parameters, and their domain, of the actions are the main culprits). However, I believe that it would be interesting to investigate hybrid methods that combine symbolic and grounding based techniques; but I'm not an expert on these areas.

You can read the details of our experiments on <https://arxiv.org/abs/1909.12738>

Best,

--sergio

[Sergio Tessaris]

Hi Victor, I already replied on this thread but I cannot find my email anywhere and I don't know what happened to it;  I might repeat myself, so I apologise in advance for that.

By doing some experiments with different techniques for reachability verification on finite transition systems we came across a similar problem. In our case the slowdown was due to the grounding stage where the memory usage was spiraling out of control and exhausted the amount allocated for the experiments. First of all I'm not familiar with the internals of FD, so I might be imprecise here; I hope the FD guys will correct me if necessary.

During the grounding stage before the conversion to SAS the Python frontend creates a Datalog problem and uses a standard saturation technique to generate its minimal model. I assume that the latter is used to the SAS final conversion before the actual search. In our setting the creation of this minimal model was taking much of the time and consuming all the memory. I looked in the Python code and I understand that the rule engine is implemented in Python, so I thought that that would be the bottleneck. To verify it I took the Datalog out of that stage and converted to an ASP program to use Clingo solver (we can hardly beat it on model generation); unfortunately I got more or less the same results in terms of CPU time and memory occupation. Unfortunately it seems that it'd be an intrinsic problem with the grounding phase.

In our experiments we also use a symbolic model checker (nuXmv) to compare the performances and, although less efficient in general, the system was able to tackle instances that FD couldn't manage. If you've the same problem, the only advice I can give you is to try to reduce the size of the problems by reducing the number of parameters of the actions and (to a lesser extent) their domain. As expected, in our case the number of actions didn't affect much the performances of FD.

In general, I believe that there is room for improvements by trying to combine symbolic and "grounding" based techniques; but I'm not an expert in these areas.

You can read more details on our experiments on <https://arxiv.org/abs/1909.12738>.

Cheers,

--sergio

On Thu, 13 Aug 2020 at 21:10, Victor PALEOLOGUE <victor.p...@softbankrobotics.com> wrote:

Dear fast-downward community,

I am working with fast-downward on simple problems and it is not as fast as I expected: it appears clearly that the planning is indeed super fast (amazing, thanks), but the translation part (from PDDL to SAS, written in Python) is actually much much slower.

Would there be a way to improve its performance?

For instance can I replace it with a C/C++ library to make it faster?

Best regards,

Victor

This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system.
This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives.

---

Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés.
Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système.
Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée.

--

You received this message because you are subscribed to the Google Groups "Fast Downward" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fast-downwar...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fast-downward/536d893e-09c6-47bb-a944-c634c8a33fe5n%40googlegroups.com.

[Victor PALEOLOGUE]

I could share some obfuscated PDDL but it may take me some time to prepare it.

However I forgot to mention that we are dealing with very simple problems that can be solved in around a hundred milliseconds on a slow processor.

The translation phase, though fast, is significantly slower (up to a second) in comparison.

@Sergio: thanks, it confirms my intuitions. So it is possible that FD is finding it difficult to simplify my problem (there are many universal statements).  Nonetheless, it is still tractable and fast, but simply not fast enough. In my case, it feels that we cannot rule out yet that an optimization of the program (rather than the algorithm) could be enough.

Is there a way to bypass the simplification in FD, or a part of it?

It would leave more work to the planner, but we could check how much slower it goes, couldn't we?

@Malte: thank you for mentioning that thread, I had not guessed that it brought me some answers to this.

I am about to test Patrik's programs. @Patrik: could you point me at which tool I should use to produce SAS+ with hsps?

By the way, congratulations to FD maintainers for the quality of this software.

[Malte Helmert]

On 14.08.20 13:47, Victor PALEOLOGUE wrote:
> I could share some obfuscated PDDL but it may take me some time to
> prepare it.
> However I forgot to mention that we are dealing with very simple
> problems that can be solved in around a hundred milliseconds on a slow
> processor.
> The translation phase, though fast, is significantly slower (up to a

> second) /in comparison/.
[...]

> Is there a way to bypass the simplification in FD, or a part of it?
> It would leave more work to the planner, but we could check how much
> slower it goes, couldn't we?

Hi Victor,

some steps in the translator can be disabled or configured, others are
integral parts of the algorithm. It would be important to see the
problems and logs in order to understand where the bottleneck is.

What Sergio wrote is correct for some problems, but based on your
description, it seems that this is not what we're seeing in your case.
If you cannot share the problems yet because you have to obfuscate them
first, it would already be helpful if you shared the command-line
options you used and the planner log (perhaps remove the plan from the
output if that says too much about your application, but I think
everything else in the output should be sharable).

> By the way, congratulations to FD maintainers for the quality of this
> software.

Thanks! :-)

Cheers,
Malte

[Christian Muise]

Just wanted to add an extra bit of information that might be relevant (from the discussion over in slack): the magnitude of timing here is sub-second. So taking a second+ on the translation phase is out of the question for the setting.

This isn't typically the setting FD finds itself in (30min timeouts, etc).

Cheers!

--
You received this message because you are subscribed to the Google Groups "Fast Downward" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fast-downwar...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fast-downward/de6b229c-a962-5c6d-5caf-301a56234d00%40unibas.ch.

[Victor PALEOLOGUE]

Here is an example run on my machine where the times are almost 10 times smaller than on the target machine.

https://pastebin.com/mHSwaBZG

[Malte Helmert]

On 14.08.20 16:47, Victor PALEOLOGUE wrote:
> Here is an example run on my machine where the times are almost 10 times
> smaller than on the target machine.
> https://pastebin.com/mHSwaBZG

Hmmm, I see no real bottlenecks in this particular output. The total
translator runtime is 0.062s wall-clock time. (The 0.070s CPU time
reported seem to have a granularity of 0.01s on this machine, so that is
probably also 0.062s with some unfortunate rounding due to having
started late on the given hundredth of a second.)

Here is how much time it takes on my machine to run a Python program
that does nothing:

$ time python3 -c "pass"
real 0m0.042s
user 0m0.023s
sys 0m0.019s

So that's 0.042s wall-clock time and 0.042s CPU time (user+sys) for a
program that does absolutely nothing.

I think we'd need to see something closer to a second to potentially
diagnose a bottleneck. If something around 0.1 seconds is already far
too much, Python just isn't an option, and that includes the
fast-downward.py driver script, which will add a similar overhead. You'd
have to call the C++ component ("downward" executable) on a directly
produced sas file rather than a PDDL file.

Cheers,
Malte

[Victor PALEOLOGUE]

It is in fact possible to get deeper information, using cProfile: https://pastebin.com/yTiQ7Hp9

We can see that, besides the time for loading Python itself (which I can get rid of by preloading it), the parsing of the file is still not the largest time consumer.

The conversion into a prolog model and the simplification operation still takes the major part of the time.

Hence the idea that skipping some the steps could help. Is there a way?

There is also some time lost all around, probably due to Python itself (the code does not appear to waste time on anything useless).

Hence the idea of finding a C++ translator.

I managed to compile Patrik's hsps and its pddlcat tool, but did not manage yet to apply it on my PDDL files.

I was also suggested to have a look at cppdl, but did not figure out how to use it to produce an SAS+ problem.

[daniel mateu]

Hi guys,

I've a similar question (translation ~15min and solver ~0.5s)

I've ~0 knowledge of PDDL and this software, so I've taken the MAZE example from https://github.com/SoarGroup/Domains-Planning-Domain-Definition-Language/tree/master/pddl

, downloaded Fast-Downward and run it for this problem. The original maze is small (6x6) so the whole operation is quite fast.

Then I've increased the MAZE grid to be 100x100 (the target is just to go from A to B). At this point, translation is taking a peak memory of ~500M and it takes ~15min to complete it.

Maybe, the way I've scaled the maze is not appropriate in PDDL language (inefficient)...dont know... (I've just extended the x's and y's up to 100):

"

(define (problem maze0)
  (:domain maze)
  (:objects x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18 x19 x20 y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11 y12 y13 y14 y15 y16 y17 y18 y19 y20 - position joseph - agent)
  (:init
    (inc x1 x2)  (inc x2 x3)  (inc x3 x4)  (inc x4 x5)  (inc x5 x6)  (inc x6 x7)  (inc x7 x8)  (inc x8 x9)  (inc x9 x10)  (inc x10 x11)  (inc x11 x12)  (inc x12 x13)  (inc x13 x14)  (inc x14 x15)  (inc x15 x16)  (inc x16 x17)  (inc x17 x18)  (inc x18 x19)  (inc x19 x20)
    (inc y1 y2)  (inc y2 y3)  (inc y3 y4)  (inc y4 y5)  (inc y5 y6)  (inc y6 y7)  (inc y7 y8)  (inc y8 y9)  (inc y9 y10)  (inc y10 y11)  (inc y11 y12)  (inc y12 y13)  (inc y13 y14)  (inc y14 y15)  (inc y15 y16)  (inc y16 y17)  (inc y17 y18)  (inc y18 y19)  (inc y19 y20)
    (dec x2 x1)  (dec x3 x2)  (dec x4 x3)  (dec x5 x4)  (dec x6 x5)  (dec x7 x6)  (dec x8 x7)  (dec x9 x8)  (dec x10 x9)  (dec x11 x10)  (dec x12 x11)  (dec x13 x12)  (dec x14 x13)  (dec x15 x14)  (dec x16 x15)  (dec x17 x16)  (dec x18 x17)  (dec x19 x18)  (dec x20 x19)
    (dec y2 y1)  (dec y3 y2)  (dec y4 y3)  (dec y5 y4)  (dec y6 y5)  (dec y7 y6)  (dec y8 y7)  (dec y9 y8)  (dec y10 y9)  (dec y11 y10)  (dec y12 y11)  (dec y13 y12)  (dec y14 y13)  (dec y15 y14)  (dec y16 y15)  (dec y17 y16)  (dec y18 y17)  (dec y19 y18)  (dec y20 y19)
   
    (at joseph x1 y1))
  (:goal
    (at joseph x18 y15))
  )

"

Looking at the console output, I can see how it is first running a python script (translate.py), which generates a ~2MB 'output.sas' file and then running downward tool (reading this previously generated file) to solve the problem.

I guess this intermediate file only is valid for the specific problem (specific location of A and B). If we need to change A or B locations, is there any way to update this intermediary file without running again the translate script (~15min).

And... the last question... does it make sense the way I've extended the task (x1..x100)? It is not a big grid and these timings are quite big.

Thanks in advance.

Dani.

[Malte Helmert]

Hi Daniel,

I think the main issue here is that the maze.pddl file under the link
you gave (maze.pddl is the domain file you want, right?) models movement
with universally quantified conditional effects, and this is something
that is tough for Fast Downward and also other planners I know.

The more idiomatic way of modelling this in PDDL is to make the
coordinates of the current and next map position action parameters. I
have attached a different domain model that you can use instead of the
given maze.pddl. With this, I get a solution for the 20x20 problem you
included in your email in less than a second. I would expect a 100x100
would also be reasonably fast, or at least many times faster than with
the original domain file.

If you swap out maze.pddl in favor of the attached maze-modified.pddl,
you should get much better results. Note that the plans look a bit
different now: rather than actions like

(move-right joseph)

you will now see actions like

(move-right joseph x11 y15 x12)

but if that's a bother, perhaps you can postprocess the plans to remove
the extra arguments?


But to also answer the main question directly: if the maze has only one
connected component, then most of the work the translator does could in
principle be reused, although it is a bit fiddly to change the
output.sas file to set a new initial state or goal. We're planning to
make things like these easier in the future, but there is no ETA for
this yet.

If you want to have initial and goal states in multiple different
connected components, then reusing the output.sas file would be harder
because the translation step will only generate movement actions for
maze locations that are reachable from the given initial state, and this
is intrinsic to the grounding algorithm and not easy to change.

Best,
Malte

> --
> You received this message because you are subscribed to the Google
> Groups "Fast Downward" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fast-downwar...@googlegroups.com
> <mailto:fast-downwar...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/fast-downward/bda4ae1b-bc86-413a-8fa4-69bbb4fa7f16n%40googlegroups.com
> <https://groups.google.com/d/msgid/fast-downward/bda4ae1b-bc86-413a-8fa4-69bbb4fa7f16n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[daniel mateu]

Thanks Malte!

Your approach is much much faster. Even a 100x100 grid is done in less than 5s.(peak memory 160M)

Then, I've tried a bigger grid (1000x1000) and things get worse (eats all my 8GB ram during translation process).

Kind regards.

Dani.

[daniel mateu]

Hi,

I have a few more questions related to PDDL and Fast downward.

Based on the previous simple maze, I've modeled a more elaborated problem:

- A grid (10x5) where there are two robot arms and 4 pieces. Each piece must be carried to its predefined grid location. Finding a solution would be good. Finding the optimal solution better :)

I've already implemented this under a different framework (MDP) and I wanted to try it in PDDL

SInce there are two arms, I've defined a lot of actions (left-left, left-right, left-pick, ....). Each timestep, both arms (or only one) can move to one of the adjacent cells or pick/drop a piece (if in the appropriate location).

Questions?

- Problem is solved successfully without constraints. In this problem, there are many invalid scenarios (an arm can not physically reach some grid cells, or many arms grid locations end up in arm collisions (each arm is represented in a single cell location, but physically each arm has many links occupying the 3D space). I've all these constraints in excel, so I've tried to add them in the 'preconditions' area of each action.

The point is that adding a few of them in one single action is enough to kill my session (eats all the available RAM). I've commented on this area in the attached example.

Do you know a better way to introduce these constraints in the problem?

- I'm aware (googling) of other variants like MA-PPDL that maybe fits better for a two-agents problem. Does Fast downward support it? Any advice?

My main question is about how to add those constraints (same for all actions, so not to move to an invalid state). Everything seems to work properly without them.

Thanks.

Kind regards. Dani.

To unsubscribe from this group and stop receiving emails from it, send an email to fast-downwar...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fast-downward/995f20b7-8a00-4f82-9eea-211fedab2175n%40googlegroups.com.

[daniel mateu]

I forgot to attach the files :)

[Florian Pommerening]

Hi Daniel,

I'm not sure if I really understand your domain but it seems that you
want to encode the movement of multiple agents as a single action. It
might be faster to let the agents make their moves individually one
after the other. You could introduce a predicate that indicates whose
"turn" it is and that flips between "agent1" and "agent2" with every
action. You can then add it as a precondition to all actions and flip it
in the effect.

If you want to encode both movements as a single action, that is
possible as well. It would make sense if you externally compute exactly
which moves are possible in parallel and this is different from the
moves that could be done in sequence. In that case, I would generate
multiple actions. For example, to move agent 1 from x11/y1 to x12/y1 and
agent 2 from x21/y2 to x22/y2, you wouldn't introduce a single action
(move-left-left x11 x12 y1 x21 x22 y2) with a large disjunction of all
possible choices for the coordinates but instead introduce an action
(move-x11-x12-y1-x21-x22-y2) for each possible choice.

My intuition is that the approach of encoding parallel moves as a single
action will not scale that far, no matter how you encode it, but it
might work if you only have 2 agents and a reasonably small amount of
actions for them. Multi-agent planning and temporal planning could be
useful alternatives.

Cheers
Florian

On 10.09.21 12:41, daniel mateu wrote:
> I forgot to attach the files :)
>
> El vie, 10 sept 2021 a las 12:38, daniel mateu (<damag...@gmail.com

> <mailto:damag...@gmail.com>>) escribió:

>
> Hi,
>
> I have a few more questions related to PDDL and Fast downward.
>
> Based on the previous simple maze, I've modeled a more elaborated
> problem:
> - A grid (10x5) where there are two robot arms and 4 pieces. Each
> piece must be carried to its predefined grid location. Finding a
> solution would be good. Finding the optimal solution better :)
>
> I've already implemented this under a different framework (MDP) and
> I wanted to try it in PDDL
> SInce there are two arms, I've defined a lot of actions (left-left,
> left-right, left-pick, ....). Each timestep, both arms (or only one)
> can move to one of the adjacent cells or pick/drop a piece (if in
> the appropriate location).
>
> Questions?
> - Problem is solved successfully without constraints. In this
> problem, there are many invalid scenarios (an arm can not physically
> reach some grid cells, or many arms grid locations end up in arm
> collisions (each arm is represented in a single cell location, but
> physically each arm has many links occupying the 3D space). I've all
> these constraints in excel, so I've tried to add them in the
> 'preconditions' area of each action.
> The point is that adding a few of them in one single action is

> enough to kill my session (*eats all the available RAM*). I've

> commented on this area in the attached example.

> *Do you know a better way to introduce these constraints in the
> problem?*

> - I'm aware (googling) of other variants like MA-PPDL that maybe
> fits better for a two-agents problem. Does Fast downward support it?
> Any advice?
>
> My main question is about how to add those constraints (same for all
> actions, so not to move to an invalid state). Everything seems to
> work properly without them.
>
> Thanks.
> Kind regards. Dani.
>
>
> El jue, 9 sept 2021 a las 0:31, daniel mateu (<damag...@gmail.com

> <mailto:damag...@gmail.com>>) escribió:

> <https://groups.google.com/d/msgid/fast-downward/bda4ae1b-bc86-413a-8fa4-69bbb4fa7f16n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/fast-downward/bda4ae1b-bc86-413a-8fa4-69bbb4fa7f16n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Fast Downward" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to fast-downwar...@googlegroups.com
> <mailto:fast-downwar...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/fast-downward/995f20b7-8a00-4f82-9eea-211fedab2175n%40googlegroups.com
> <https://groups.google.com/d/msgid/fast-downward/995f20b7-8a00-4f82-9eea-211fedab2175n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Fast Downward" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to fast-downwar...@googlegroups.com
> <mailto:fast-downwar...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/fast-downward/CAH4L3L_XEDFGc2HQ_Fjyu6k7yEzV1q%3DNuGr_UZkBRALjb4yXqQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/fast-downward/CAH4L3L_XEDFGc2HQ_Fjyu6k7yEzV1q%3DNuGr_UZkBRALjb4yXqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[daniel mateu]

Hi,

I'm trying out a different approach for the constraints. Sorry if anyone was investing time on this. I will back if it doesn't work.

Thanks.

Dani.