Solving an Industrial-Scale Warehouse Delivery Problem with Answer Set Programming Modulo Difference Constraints

Round 1

Reviewer 1 Report

This paper proposes several ASP encodings for a problem of multi-agent path finding. The problem is an industrial one, and it is developed in a collaboration with a company developing robots.

The paper is well-written, except for the final part of the paper.
I think the path-based encoding should be introduced in a more intuitive form before starting discussing its bits and pieces (see below for additional comments).

In section 4.5.3 it should be clearly stated that the use of corridors make your approach incomplete: even if given enough running time, the solver could be unable to find the optimal solution because it is ruled out by the corridors approach. So, this becomes a heuristic method.

It is not clear to me in which instances one could have that the path-based approach cannot find the optimal solution (while the step-based one can). Could you please provide one example?

I think the experimental results would be better presented with some graphs than with tables. E.g., why not a cactus plot comparing all the methods?

line 134: I suggest to use another smbol for the number of 'b' literals, since 'm' is already used as the heuristic modifier. Indeed, the fonts of b_m and [w,m] are different, but using two different letters would simplify the reading.

line 218: f_E assigns the minimum travel time along an edge: can an edge have more than one travel times? Why? I thought the travel time for an edge was a constant (all robots take the same time to travel the same edge).

footnote 5 on page 6: if you have conflicts only on nodes and not on edges it means that you are assuming that the graph (V,E) is planar, otherwise there could be two edges AB and CD that cross each other even if the four nodes A, B, C and D are not in close each other (think of the diagonals of a square). This assumption should be stated, if indeed your formalization needs it.  

258: "For example, because there is a deliver relation from task t1 to task t2, and thus t1 must": either remove "because" or remove "and thus"

359-368: actually this formalization assumes that (v',v'') is not in C, i.e. moving from v' to v'' ensures that the robot exits the conflict zone of v'. You discuss the issue in lines 366-368, but it seems to me that to include such a case you could state in condition 12a that  v'' is not necessarily following immediately v in the sequence. So, I would add in line 359 some suspension dots between (v,a,e) and (v'',a'',e'').

Line 457: T2D: relation to Condition 14. . . ?
Maybe was a comment for yourselves. I suggest the use of the todonotes LaTeX package.

line 465: the Saxon genitive of t' becomes t''s, which is unreadable

lines 497-503: "In industry, there are often online settings in which new tasks arrive and plans have to be redone. Therefore, a makespan optimization cannot be exact and might be too costly
from a performance point of view."
This sentence is very interesting, and deserves a better explanation. I guess you mean that you do not run the solver to optimality, because it would take too much time, and, nevertheless, it would not make sense because other tasks would oblige you to replan. However, measuring the idle time is not a relibale measure, specially if the graph of the warehous layout allows for many loops: robots could try and take loops, or in general inefficient routes in order to avoid idle times, so the makespan looks like a better measure to me.

line 503: q_TP(...) smaller THAN 300.

Listing 1, line 14: the syntax with the semicolon was not explained in Section 2: either write it explicitly or explain the ';' syntax in Section 2.

Listing 2, line 8: can you comment on the relation T<T' ? Note that T and T' are tasks, so what does it mean to compare two terms? For instance, is t1<t2? Why?
Does the clause in line 8 require some naming convention on tasks, such that the ones that might depend on subsequent tasks have a "smaller" name (for the ordering of terms that is used here)?

Lines 622-625 seems again a discussion between the authors.

line 694: "r precedes r' in steps s and s'" is not very clear. Do you mean that "r in step s precedes r' in step s'"?

line 752: "at vertex l2": in this font "l2" is easily mistaken for "12"; maybe you could write in mathematical font $l_2$, as in Figure 1?

line 774: remove the full stop after "Condition k"

line 987: please fix the overfull hboxes; in this line I cannot read the end of the text.

line 1010: is possibly another communication between the authors.


1034: another comment between authors

1043: from itS starting vertex

1059: it's => its

Section 4.4 describes the advantages of the path-based approach, but at this point it is hard to understand, since you do not define what is a path. A path in which graph? Then in section 4.4.1 you move abruptly to the code, but again I missed an intuition of what types of path you are considering.
Also, it is not clear the intuitive meaning of predicate path/2: in line 1083 you say that "the first argument [of path/2] can be seen as the name of a path and the second as its destination", while on 1089: "the second argument identifies the path". From line 1083 I understood that the first argument identifies the path (is the name of the path). Anyway, it should be explained why there is one path per task (or per vertex, depending on which argument identifies the path). And what is the path: I expect a path to be a sequence of vertices in a graph, and I cannot see here neither the graph nor the meaning of the sequence; I guess the sequence is given by predicate path_sequence, but it is the same sequence by task_sequence (only the finale element differs), so why do you need that duplication?
After reading further Sect 4.4.2: the actual path is given by atoms move/3; this is a  very unintuitive organization of this section. Maybe you draw a picture (similar to Figure 1) showing the paths with different colors at the beginning of Section 4.4, then you could state immediately that the paths are made of move/3 atoms, and that they have names and are in sequences.

1114: the last atom path_sequence should be path_sequence(t7,r2) and not r1

1140-1144: it is not clear to me why the redundancy in lines 1-2 of listing 11 (and lines 3-4 as well) allows for more propagation in the solving phase. Which rules (I guess integrity constraints) are propagated in this way that would not be propagated otherwise? Can you give an example?
Maybe you mean the cardinality constraint? I.e. there is at most one incoming and one outgoing move to each vertex? If so, say it explicitly.

1215: another comment between the authors

1300: capitalize "Analogously"
"Lines 10-12" remove comma "add difference"

1315: please do not use the Saxon genitive with objects having a superscript: "p''s"

1463: remove "therefore"

1494: "from its starting vertex through to its final arrival its home vertex". I'd remove "through" and add "at" before "its home"
 
1505: do you really only store in the shortest_path/4 predicate the nodes v'' that are just after v (since you write (v,v')\in E ) ? I.e., for each shortest path, you only provide the second vertex in the sequence. Why is it enough? Don't you need to store the whole sequence?
In the example in lines 1529-1539 you list also the intermediate vertices, e.g., possible_shortest_path(r1,t1,w2) : here w2 is not the second vertex (there is not the edge (h1,w2) in the graph of Fig 1).


1518: it is not clear to me why there is static_shortest_path(t2,w3). Task t2, according to Fig 1 and 2, is on vertex s1, and depends on t1 in vertex l1. I do not see why, in order to go from l1 to s1, one should pass through w3; I would have expected w5 instead.

1556: another comment between the authors.

Sect 4.5.2: It is not clear to me what is the difference between (listing 18) the modifier "sign" and the modifier "false". Why didn't you write [-1,sign] in the third directive, instead of [1,false]? The short explanation on Section 2 (lines 133-141) does not help understanding the difference.
Possibly related to the same question: Line 1580: "only the latter additionally favors certain atoms." Why?

1609: "essentially removing the N’ <= N restriction from each rule." But if you remove the restriction all possible paths are accepted, right?
And even if you leave the restriction, you might obtain corridors that are worse than the shortes path. For example, if you have a graph that is grid, and you have to move from the upper left corner to the bottom-right one. Basically, all edges and all vertexes belong to a shortest path, so the corridor would contain all the graph (containing also paths that are longer than the shortest path).

1611: comment between authors

1624-1629: It is not clear here if the corridor shown here is obtained with the code in Listing 19 (as it is) or not. It seems to me that it contains also suboptimal paths (h1-w3-w7-w6-w5-l1), so it is not obtained with the code in listing 19. I would add a comment in line 1624: "A corridor that is unequal to a shortest path (obtained by removing N'<=N in listing 19) ...".

1633: "secondly, solutions are likely to have a higher quality". I disagree with this sentence: instead, by using corridors you are (somewhat arbitrarily) removing parts of the search space, which might even contain the optimal solution. So the quality of the solutions obtained by using corridors can only decrease by using corridors (if given enough time to the solver). I guess you mean that the quality of solutions obtained *within a given/strict timeout* might increase (this should be tested experimentally). But if you do not state "within a given timeout" your sentence is plainly wrong.

I suggest to emphasise better that (unlike all other optimizations you propose) corridors make your approach incomplete: the optimal solution might be ruled out, so it might not be found even if given enough time.

1964: the number OF tasks

1965: the number of tasks increaseS

1971: in a semi-realtime environment (comma) THEN

1978: Table 8 shows the Effect

1980: the size of the robots increaseS

2001: We DISCUSS this

2030: moves ALONG a path

2036: quality often improveS

Sections 5.3.3 and following seem written in a much worse English than the previous sections; I suggest to re-read them carefully.
E.g., the sentence in line 2041 is not understandable: "For example, the optimality search the solver returns solutions as they are found."

2066: used-defined factor

Author Response

Thank you for the detailed feedback and careful reading. The comments and our responses follow:

> This paper proposes several ASP encodings for a problem of multi-agent path finding. The problem is an industrial one, and it is developed in a collaboration with a company developing robots.
> 
> The paper is well-written, except for the final part of the paper.
> I think the path-based encoding should be introduced in a more intuitive form before starting discussing its bits and pieces (see below for additional comments).
>

The start of Section 4.4 has been expanded to better explain the path-based encoding.

> In section 4.5.3 it should be clearly stated that the use of corridors make your approach incomplete: even if given enough running time, the solver could be unable to find the optimal solution because it is ruled out by the corridors approach. So, this becomes a heuristic method.
>

Note, the path-based encoding is already incomplete, so the addition of corridors adds to this incompleteness. We've added more discussion and explanation to Section 4.5.3 clarifying this.

> It is not clear to me in which instances one could have that the path-based approach cannot find the optimal solution (while the step-based one can). Could you please provide one example?
>

We've added an example in the start of Section 4.4

> I think the experimental results would be better presented with some graphs than with tables. E.g., why not a cactus plot comparing all the methods?
>

Thank you for the suggestion. We will add a cactus plot (or eCNF) for a final version. Given the tight response schedule we haven't had the time to do it for the reviewer feedback.

> line 134: I suggest to use another smbol for the number of 'b' literals, since 'm' is already used as the heuristic modifier. Indeed, the fonts of b_m and [w,m] are different, but using two different letters would simplify the reading.
>

This has been fixed.

> line 218: f_E assigns the minimum travel time along an edge: can an edge have more than one travel times? Why? I thought the travel time for an edge was a constant (all robots take the same time to travel the same edge).
>

We've added some comments to the start of Section 3 emphasising and motivating the use of minimum travel times. A robot can potentially take longer than the minimum time to traverse an edge. This allows greater modelling flexibility for the robots and is an important practical consideration. For example, a robot that does a lot of stopping and starting at intermediate waypoints will have greater wear and reduced battery life.

 

> footnote 5 on page 6: if you have conflicts only on nodes and not on edges it means that you are assuming that the graph (V,E) is planar, otherwise there could be two edges AB and CD that cross each other even if the four nodes A, B, C and D are not in close each other (think of the diagonals of a square). This assumption should be stated, if indeed your formalization needs it.
>

We've added a comment that we assume planar graphs.

> 258: "For example, because there is a deliver relation from task t1 to task t2, and thus t1 must": either remove "because" or remove "and thus"
>

Fixed.

> 359-368: actually this formalization assumes that (v',v'') is not in C, i.e. moving from v' to v'' ensures that the robot exits the conflict zone of v'. You discuss the issue in lines 366-368, but it seems to me that to include such a case you could state in condition 12a that  v'' is not necessarily following immediately v in the sequence. So, I would add in line 359 some suspension dots between (v,a,e) and (v'',a'',e'').
>

Note that the use of (v'', a'', e'') in 12(a) is only within the scope of 12(a) itself. It is therefore not the same route point as the (v'', a'', e'') used in 12(b), which is similarly only for the scope of 12(b).

To remove this ambiguity we are now using (v''', a''', e''') for 12(b).

> Line 457: T2D: relation to Condition 14. . . ?
> Maybe was a comment for yourselves. I suggest the use of the todonotes LaTeX package.
>

Fixed.

> line 465: the Saxon genitive of t' becomes t''s, which is unreadable
>

Fixed.

> lines 497-503: "In industry, there are often online settings in which new tasks arrive and plans have to be redone. Therefore, a makespan optimization cannot be exact and might be too costly
> from a performance point of view."
> This sentence is very interesting, and deserves a better explanation. I guess you mean that you do not run the solver to optimality, because it would take too much time, and, nevertheless, it would not make sense because other tasks would oblige you to replan. However, measuring the idle time is not a relibale measure, specially if the graph of the warehous layout allows for many loops: robots could try and take loops, or in general inefficient routes in order to avoid idle times, so the makespan looks like a better measure to me.
>

We have added some motivation and explanation for why we consider the two quality measures; in particular that makespan minimization is not practical in this setting so alternative metrics need to be considered.

Note, we do not track the idle time of robots. We use the task-pair distance metric as a measure of the idle time of the loading bays, not the robots.

 

> line 503: q_TP(...) smaller THAN 300.
>

Fixed.

> Listing 1, line 14: the syntax with the semicolon was not explained in Section 2: either write it explicitly or explain the ';' syntax in Section 2.
>

The use of:

    conflict(V,V; V',V') :- edge(V,V',_).

is simply a convenient way of writing:

    conflict(V,V)   :- edge(V,V',_).
    conflict(V',V') :- edge(V,V',_).

For clarity we've changed the code to the more verbose version.

> Listing 2, line 8: can you comment on the relation T<T' ? Note that T and T' are tasks, so what does it mean to compare two terms? For instance, is t1<t2? Why?
> Does the clause in line 8 require some naming convention on tasks, such that the ones that might depend on subsequent tasks have a "smaller" name (for the ordering of terms that is used here)?
>

We've added a footnote in the discussion of this code to explain the use of T<T'. Clingo's grounder guarantees a total ordering over terms. We take advantage of this to remove redundant symmetries when grounding rules. Using T != T' instead of T < T' would have lead to redundant ground rules being generated with a ground rule for each combination of T and T'. Note, the actual ordering doesn't matter only that such an ordering exists. So the fact that the grounder does happen to use a lexicographic ordering for constant terms (hence t1 < t2) is not something that we rely on.

> Lines 622-625 seems again a discussion between the authors.
>

Fixed

> line 694: "r precedes r' in steps s and s'" is not very clear. Do you mean that "r in step s precedes r' in step s'"?
>

Yes. Fixed.

> line 752: "at vertex l2": in this font "l2" is easily mistaken for "12"; maybe you could write in mathematical font $l_2$, as in Figure 1?
>

For the final version we'll look at replacing the "l" (for location) with "d" (for depot) to make it more readable.

> line 774: remove the full stop after "Condition k"
>

The full stop is generated by latex because Condition k is a label within an enumeration.

> line 987: please fix the overfull hboxes; in this line I cannot read the end of the text.
>

Fixed.

> line 1010: is possibly another communication between the authors.
>

Fixed

> 
> 1034: another comment between authors
>

Fixed

> 1043: from itS starting vertex
>

Fixed

> 1059: it's => its
>

Fixed

> Section 4.4 describes the advantages of the path-based approach, but at this point it is hard to understand, since you do not define what is a path. A path in which graph? Then in section 4.4.1 you move abruptly to the code, but again I missed an intuition of what types of path you are considering.

We've added more explanation and expanded on the example in Section 4.4. 

 

> Also, it is not clear the intuitive meaning of predicate path/2: in line 1083 you say that "the first argument [of path/2] can be seen as the name of a path and the second as its destination", while on 1089: "the second argument identifies the path". From line 1083 I understood that the first argument identifies the path (is the name of the path). Anyway, it should be explained why there is one path per task (or per vertex, depending on which argument identifies the path). And what is the path: I expect a path to be a sequence of vertices in a graph, and I cannot see here neither the graph nor the meaning of the sequence; I guess the sequence is given by predicate path_sequence, but it is the same sequence by task_sequence (only the finale element differs), so why do you need that duplication?
> After reading further Sect 4.4.2: the actual path is given by atoms move/3; this is a  very unintuitive organization of this section. Maybe you draw a picture (similar to Figure 1) showing the paths with different colors at the beginning of Section 4.4, then you could state immediately that the paths are made of move/3 atoms, and that they have names and are in sequences.
>

Please see the start of Section 4.4 which now provides more explanation of paths with reference to the running example.

> 1114: the last atom path_sequence should be path_sequence(t7,r2) and not r1
>

Fixed. It should have been path_sequence(t8,r2).

> 1140-1144: it is not clear to me why the redundancy in lines 1-2 of listing 11 (and lines 3-4 as well) allows for more propagation in the solving phase. Which rules (I guess integrity constraints) are propagated in this way that would not be propagated otherwise? Can you give an example?
> Maybe you mean the cardinality constraint? I.e. there is at most one incoming and one outgoing move to each vertex? If so, say it explicitly.
>

We've clarified this. As you say, it is based on the fact that there is at most one incoming and one outgoing move for any given vertex. The solver can then generate a chain of moves, propagating either from a vertex back to some source for forward to some destination.

> 1215: another comment between the authors
>

Fixed.

> 1300: capitalize "Analogously"
> "Lines 10-12" remove comma "add difference"
>

Fixed.

> 1315: please do not use the Saxon genitive with objects having a superscript: "p''s"
>

Fixed.

> 1463: remove "therefore"
>

Fixed.

> 1494: "from its starting vertex through to its final arrival its home vertex". I'd remove "through" and add "at" before "its home"
>

Fixed.

> 1505: do you really only store in the shortest_path/4 predicate the nodes v'' that are just after v (since you write (v,v')\in E ) ? I.e., for each shortest path, you only provide the second vertex in the sequence. Why is it enough? Don't you need to store the whole sequence?

Yes, this is enough. The last parameter v'' specifies the next vertex along the shortest path from v to v'. But there will also be a shortest_path fact from v'' to v' via some other vertex v'''. This will get repeated until we reach a vertex that is directly connected to the destination vertex v'. So the whole sequence of the shortest path from v to v' is encoded in a set of shortest_path/4 facts.

 

> In the example in lines 1529-1539 you list also the intermediate vertices, e.g., possible_shortest_path(r1,t1,w2) : here w2 is not the second vertex (there is not the edge (h1,w2) in the graph of Fig 1).
> 
>

Note: there is no order implicit in the possible_shortest_path/3, so w2 does not refer to the second vertex. We've added some clarification of the use of possible_shortest_path/3. In particular the way to read the fact possible_shortest_path(x,p,v) is that v is a vertex on the shortest path for path p if x is the path that preceded p in the path assignment or x is the name of a robot in the case that p is the first path assigned to the robot x.

 

> 1518: it is not clear to me why there is static_shortest_path(t2,w3). Task t2, according to Fig 1 and 2, is on vertex s1, and depends on t1 in vertex l1. I do not see why, in order to go from l1 to s1, one should pass through w3; I would have expected w5 instead.
>

Correct. This is a mistake and the w3 fact has been replace with w5.

> 1556: another comment between the authors.
>

Fixed.

> Sect 4.5.2: It is not clear to me what is the difference between (listing 18) the modifier "sign" and the modifier "false". Why didn't you write [-1,sign] in the third directive, instead of [1,false]? The short explanation on Section 2 (lines 133-141) does not help understanding the difference.
> Possibly related to the same question: Line 1580: "only the latter additionally favors certain atoms." Why?
>

We've added more explanation of the modifier and clarified the text. Basically [1,false] is a shorthand for the combination of [-1,sign] and [1,level]. This means that [1,false] atoms will be resolved before the [1,sign] atoms, so the system will first prefer to make all moves that are not along the shortest to false, and secondly, prefer to make moves along the shortest path to true.

> 1609: "essentially removing the N’ <= N restriction from each rule." But if you remove the restriction all possible paths are accepted, right?

No. A vertex that is on the corridor must still be directly connected to a shortest path vertex. We've added some clarification in the text.

> And even if you leave the restriction, you might obtain corridors that are worse than the shortes path. For example, if you have a graph that is grid, and you have to move from the upper left corner to the bottom-right one. Basically, all edges and all vertexes belong to a shortest path, so the corridor would contain all the graph (containing also paths that are longer than the shortest path).
>

Moves selected along a corridor will almost always allow for paths that are worse than the shortest path. The only way that this is not the case is if every corridor is composed of exactly one shortest path. Otherwise if the corridor is composed of multiple shortest paths or if it contains vertices that are not part of a shortest path, then the robot may zig-zag between nodes along the corridor, slowly getting closer to destination but doing it in a non-optimal way.

There may be some confusion about the shortest path or corridor definitions.

Given a grid and a starting location at the upper left corner and a destination at the lower-right corner, then the shortest paths will NOT include all vertices or edges. Only the vertices that are part of a zig-zag down from top-left to bottom-right will be part of a shortest path. The corridor  definition will make this slightly larger including vertices that are directly connected to a shortest path vertex.

 

> 1611: comment between authors
>

Fixed.

> 1624-1629: It is not clear here if the corridor shown here is obtained with the code in Listing 19 (as it is) or not. It seems to me that it contains also suboptimal paths (h1-w3-w7-w6-w5-l1), so it is not obtained with the code in listing 19. I would add a comment in line 1624: "A corridor that is unequal to a shortest path (obtained by removing N'<=N in listing 19) ...".
>

There may have caused some confusion about the corridor definition.

We've fixed some typos in the example for corridor/2 where the corridor/2 facts should have been referring to t2 not t1. The corridor for t2 can be derived from purely static information whereas the corridor for t1 will need corridor/3 facts. Hopefully this and some added explanation of the example in the text will clarify the definitions.

The example corridor/3 facts shown for task t1 when it is assigned to robot r1 is obtain from Listing 19 (as is). And yes, it does allow for the the suboptimal path h1-w3-w7-w6-w5-l1.

A couple of points. 1) being on the corridor doesn't guarantee an optimal path because it can include vertices that are not on the shortest path. Even if the corridor definition only included vertices on the shortest path it wouldn't guarantee an optimal path because there could be multiple optimal paths and the corridor could allow the selection of a zig-zag across these vertices.

2) the second example is not obtained by removing N' <= N.

Hopefully the expanded example clarifies this.

 

> 1633: "secondly, solutions are likely to have a higher quality". I disagree with this sentence: instead, by using corridors you are (somewhat arbitrarily) removing parts of the search space, which might even contain the optimal solution. So the quality of the solutions obtained by using corridors can only decrease by using corridors (if given enough time to the solver). I guess you mean that the quality of solutions obtained *within a given/strict timeout* might increase (this should be tested experimentally). But if you do not state "within a given timeout" your sentence is plainly wrong.
>
> I suggest to emphasise better that (unlike all other optimizations you propose) corridors make your approach incomplete: the optimal solution might be ruled out, so it might not be found even if given enough time.
> 

In Section 4.5.3 we've expanded the explanation as well as adding a small example to clarify the usage of corridors, both in terms of its potential advantages but also the incompleteness of the approach and potentially missing out on being able to determine the optimal makespan.

 

> 1964: the number OF tasks
>

Fixed.

> 1965: the number of tasks increaseS
> 

Fixed.

> 1971: in a semi-realtime environment (comma) THEN
> 

Fixed.

> 1978: Table 8 shows the Effect
> 

Fixed.

> 1980: the size of the robots increaseS
> 

Fixed.

> 2001: We DISCUSS this
> 

Fixed.

> 2030: moves ALONG a path
> 

Fixed.

> 2036: quality often improveS
> 

Fixed.

> Sections 5.3.3 and following seem written in a much worse English than the previous sections; I suggest to re-read them carefully.
> E.g., the sentence in line 2041 is not understandable: "For example, the optimality search the solver returns solutions as they are found."
>

Thank you. We are re-read this section and tried to improve the quality of the English expression.

> 2066: used-defined factor
>

Fixed.

 

Reviewer 2 Report

The article is written quite precisely and clearly. It is clear that the authors have carried out extensive research in collaboration with industrial partners (due to data and environment). The article is focused on the theoretical solution to the problems of supply and logistics of data warehouses, where the authors used a rich theoretical basis from several disciplines (graph theory, logic programming, specifically answer-set programming mostly for detecting the conflict detection, routing ...) and so on. The individual sections of the article are logically arranged and follow each other. The core of the article is section 4, where the authors present their ASP-based solution to the warehouse delivery problem. The practical use and verification of the results in practice on real data is in section 5. The literature is in order, relevant sources are cited.

 

The article itself is quite long, which is not contrary to the rules for publishing in the given journal.

 

The reviewer advises the Authors to add the possibilities of formal verification of some aspects of the developed method in the future (e.g. for ASP programs the use of e.g. axiomatic semantics or the construction of natural semantics) - not necessarily in this article due to its length.

 

Here is a list of some inaccuracies:

- some grammatical errors (missing commas), some stylizations (In order to => To) and so on.

 

- consider formatting, e.g. lines 121, 123, 323, 585, Listing 3, 

- for better readability, consider to "restart" enumerator in each enum list (see e.g. list j., k., l.) -- if necessary

 

 

Author Response

Thank you for the feedback and suggestions.

> The article is written quite precisely and clearly. It is clear that the authors have carried out extensive research in collaboration with industrial partners (due to data and environment). The article is focused on the theoretical solution to the problems of supply and logistics of data warehouses, where the authors used a rich theoretical basis from several disciplines (graph theory, logic programming, specifically answer-set programming mostly for detecting the conflict detection, routing ...) and so on. The individual sections of the article are logically arranged and follow each other. The core of the article is section 4, where the authors present their ASP-based solution to the warehouse delivery problem. The practical use and verification of the results in practice on real data is in section 5. The literature is in order, relevant sources are cited.
> 
>  
> 
> The article itself is quite long, which is not contrary to the rules for publishing in the given journal.
> 
>  
> 
> The reviewer advises the Authors to add the possibilities of formal verification of some aspects of the developed method in the future (e.g. for ASP programs the use of e.g. axiomatic semantics or the construction of natural semantics) - not necessarily in this article due to its length.
> 
>

Thank you.

> 
> Here is a list of some inaccuracies:
> 
> - some grammatical errors (missing commas), some stylizations (In order to => To) and so on.
>

We've re-read for grammatical errors and reduced some of the "in order to" statements to "to" statements.

>  
> 
> - consider formatting, e.g. lines 121, 123, 323, 585, Listing 3, 
>

We've reformatted most of the text to make it readable for the reviewers, and will fix any remaining code line width overflows.

> - for better readability, consider to "restart" enumerator in each enum list (see e.g. list j., k., l.) -- if necessary
> 

This would create redundancies so that we couldn't refer to this items in the text. We will look at whether there is a better way to present these.

> 

Round 2

Reviewer 1 Report

I am happy with the new version of the paper, the authors replied to all my concerns and the new version of the paper is satisfactory.