<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello Mahmoud,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">When you have the repository ready we can make an appointment to check what needs to be done.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Right now I am still working on the release of 3.0.0, some PR I need to merge, then I will be able to make the release, and</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">get the develop branch ready for accepting PR merges.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">By the way, I am not the only developer please subscribe to the <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><a href="https://lists.osgeo.org/mailman/listinfo/pgrouting-dev">https://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">So that everyone knows what we are doing.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 19, 2020 at 8:22 AM Vicky Vergara <<a href="mailto:vicky@georepublic.de">vicky@georepublic.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Mahmoud Sakr</b> <span dir="auto"><<a href="mailto:m_attia_sakr@yahoo.com" target="_blank">m_attia_sakr@yahoo.com</a>></span><br>Date: Tue, May 19, 2020 at 7:26 AM<br>Subject: pgr_dijkstra(edges_sql, combinations_sql)<br>To: Esteban Zimanyi <<a href="mailto:estebanzimanyi@gmail.com" target="_blank">estebanzimanyi@gmail.com</a>>, Vicky Vergara <<a href="mailto:vicky@georepublic.de" target="_blank">vicky@georepublic.de</a>><br>Cc: Arthur Lesuisse <<a href="mailto:alesuiss@gmail.com" target="_blank">alesuiss@gmail.com</a>><br></div><br><br><div><div style="font-family:times new roman,new york,times,serif;font-size:16px"><div><div dir="ltr">Hi Vicky,</div><div dir="ltr">The new signature is working now.<br></div><div dir="ltr">The tests are quite impressive. Here I summarize the results, while the test queries are given below. Two tests have been done: speed/scalability, and correctness. The speed/scalability test shows that the new signature scales linearly, and can afford a big number of (source, target) combinations. It was possible to test up to 1e5 combinations. The 1e6 test ran out of memory. I think that the reason is that the size of the result is too big for the memory. The correctness test shows that the result is exactly the same as what one would get using multiple calls to pgr_dijkstra(edges, source, target).<br></div><div dir="ltr"><br></div><div dir="ltr"><span> In another email, I'll share the git repository with you. Please guide us in the following:</span></div><div dir="ltr"><span>- </span>what kind of testing shall be needed, and how to integrate it with the repository.</div><div dir="ltr">- how to manage our fork, to ease the merge with pgRouting. The steps done so far: fork -> branch 'combinationsSQL' -> multiple push -> merge into master</div><div dir="ltr">- <span>what kind of documentation shall be needed, and how to integrate it with the repository. In the code, I copied the coding and commenting styles as good as I could observe.</span></div><div><br></div><div dir="ltr">best regards,<br></div><div dir="ltr"><span>Mahmoud<br></span></div><div dir="ltr"><br><span></span></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">--------------------Speed/scalability test:</div><div dir="ltr"><br></div><div dir="ltr"><div>do $$<br>declare<br> i int;<br> count bigint;<br> startTime timestamptz;<br> endTime timestamptz;<br>begin<br> for i in 0..100000 BY 10000 loop<br> DROP TABLE IF EXISTS temp;<br> CREATE TABLE temp AS (<br> select <a href="http://s.id" target="_blank">s.id</a> as source, <a href="http://t.id" target="_blank">t.id</a> as target<br> from nodes s, nodes t<br> limit i<br> );<br> SELECT clock_timestamp() INTO startTime;<br>--> begin<br> PERFORM count(*)<br> FROM pgr_dijkstra(<br> 'SELECT id, source, target, cost_s AS cost, reverse_cost_s as reverse_cost FROM edges',<br> 'SELECT source, target FROM temp', true);<br>--> end<br> SELECT clock_timestamp() INTO endTime;<br> raise notice 'count = %, time = %', i, endTime - startTime;<br> end loop;<br>end; $$</div><div><br></div><div><br></div><div dir="ltr"><div><div>NOTICE: count = 0, time = 00:00:00.127069 <br clear="none"></div><div>NOTICE: count = 10000, time = 00:00:04.514361 <br clear="none"></div><div>NOTICE: count = 20000, time = 00:00:08.476031 <br clear="none"></div><div>NOTICE: count = 30000, time = 00:00:11.895231 <br clear="none"></div><div>NOTICE: count = 40000, time = 00:00:16.177429 <br clear="none"></div><div>NOTICE: count = 50000, time = 00:00:19.482188 <br clear="none"></div><div>NOTICE: count = 60000, time = 00:00:24.499867 <br clear="none"></div><div>NOTICE: count = 70000, time = 00:00:34.240081 <br clear="none"></div><div>NOTICE: count = 80000, time = 00:00:35.538692 <br clear="none"></div><div>NOTICE: count = 90000, time = 00:00:44.128275 <br clear="none"></div><div>NOTICE: count = 100000, time = 00:00:48.345672</div></div><div><br></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><img title="Inline image" alt="Inline image" src="cid:1722d19c3bc721c701b2" style="max-width: 637px; width: 100%;"></span><br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><div dir="ltr"><span>--------------------Correctness test:</span></div></div><div><br></div><div dir="ltr"><div>WITH solution1 AS(<br>SELECT *<br>FROM pgr_dijkstra(<br> 'SELECT id, source, target, cost_s AS cost, reverse_cost_s as reverse_cost FROM edges',<br> 'SELECT homeNode as source, workNode as target FROM Vehicle',<br> true)<br>)<br>, solution2 AS(<br>SELECT * FROM<br> (SELECT * FROM Vehicle) V,<br> pgr_dijkstra(<br> 'SELECT id, source, target, cost_s AS cost, reverse_cost_s as reverse_cost FROM edges',<br> V.homeNode, V.workNode, true) P<br>)<br>SELECT count(*) AS Joined, <br> (SELECT count(*) FROM solution1) AS NewSolution, <br> (SELECT count(*) FROM solution2) AS CurrentSolution<br>FROM solution1 a, solution2 b<br>WHERE a.start_vid = b.homeNode AND a.end_vid = b.workNode AND a.path_seq = b.path_seq <br><br>--Successfully run. Total query runtime: 2 min 2 secs.<br>--21121; 21121; 21121</div><div><br></div></div></div></div><div dir="ltr"><br></div><div><br></div><div><div><font size="2">Best regards,<br></font></div><div style="color:rgb(20,19,18);font-size:13px;font-family:arial,helvetica,clean,sans-serif;background-color:transparent;font-style:normal"><font size="2">Mahmoud Sakr<br></font></div></div></div>
<div><br></div><div><br></div>
</div><div id="gmail-m_7296966084110741442m_1091654474487630567ydpd8a74d75yahoo_quoted_0200411574">
<div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div>
On Monday, May 18, 2020, 5:52:42 PM GMT+2, Vicky Vergara <<a href="mailto:vicky@georepublic.de" target="_blank">vicky@georepublic.de</a>> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="gmail-m_7296966084110741442m_1091654474487630567ydpd8a74d75yiv0747291965"><div><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><a shape="rect" href="https://drive.google.com/drive/u/0/folders/1uUWb-AtJGnckBDMBuFT_84ywksjoPALB" rel="nofollow" target="_blank">https://drive.google.com/drive/u/0/folders/1uUWb-AtJGnckBDMBuFT_84ywksjoPALB</a></div></div><br clear="none"><div id="gmail-m_7296966084110741442m_1091654474487630567ydpd8a74d75yiv0747291965yqt08014"><div><div dir="ltr">On Sat, May 16, 2020 at 1:53 AM Esteban Zimanyi <<a shape="rect" href="mailto:estebanzimanyi@gmail.com" rel="nofollow" target="_blank">estebanzimanyi@gmail.com</a>> wrote:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Vicky<div><br clear="none"></div><div>In mobility applications we need to generate data according to a given scenario at various scale factors to make simulations. This requires to send thousands of requests to pgrouting and this number of requests increases with the scale factor used for the generation.</div><div><br clear="none"></div><div>As a concrete example, the BerlinMOD data generator</div><div><a shape="rect" href="http://dna.fernuni-hagen.de/secondo/BerlinMOD/BerlinMOD.html" rel="nofollow" target="_blank">http://dna.fernuni-hagen.de/secondo/BerlinMOD/BerlinMOD.html</a> <br clear="none"></div><div>uses a workweek scenario in which persons go in the morning to work, return back to home in the afternoon, and possibly do an extra trip after working hours for leisure. As another example, we described in</div><div><a shape="rect" href="https://www.mdpi.com/2220-9964/8/4/170/htm" rel="nofollow" target="_blank">https://www.mdpi.com/2220-9964/8/4/170/htm</a> </div><div>a scenario in which a home appliances shop needs to deliver the appliances to the customers and thus vehicles are loaded at a warehouse in the morning and spent the day delivering to the clients given a specified schedule to finally return back to the warehouse at the end of the day.<br clear="none"></div><div><br clear="none"></div><div>We have done a first profiling of these data generators and realized that 87% of the time is spent in pgrouting building the graph thousands of times, at each query sent to pgrouting. On the other hand, the real work of MobilityDB only accounts for 0.11%</div><div><br clear="none"></div><div><div><img src="cid:1722d19c3bb4161c9be1" alt="VirtualBox_mobilitydb-dev_13_05_2020_17_11_39 (1).png" style="width: 452px; max-width: 800px;"><br clear="none"></div><div><div dir="ltr"><div dir="ltr"><div><br clear="none"></div><div>For this reason we would need an API in which we build the graph once at the beginning of the simulation, send to pgrouting thousands of calls to pgr_dijkstra, pgr_aStar, pgr_dijkstraVia, etc. and then delete the graph, free the memory and start the simulation.</div><div><br clear="none"></div><div>Any idea how to achieve this ?</div><div><br clear="none"></div><div>Many thanks for your valuable help.</div><div><br clear="none"></div><div>Esteban</div><div><br clear="none"></div><div>------------------------------------------------------------<br clear="none">Prof. Esteban Zimanyi<br clear="none">Department of Computer & Decision Engineering (CoDE) CP 165/15 <br clear="none">Universite Libre de Bruxelles <br clear="none">Avenue F. D. Roosevelt 50 <br clear="none">B-1050 Brussels, Belgium <br clear="none">fax: + 32.2.650.47.13<br clear="none">tel: + 32.2.650.31.85<br clear="none">e-mail: <a shape="rect" href="mailto:ezimanyi@ulb.ac.be" rel="nofollow" target="_blank">ezimanyi@ulb.ac.be</a><br clear="none">Internet: <a shape="rect" href="http://cs.ulb.ac.be/members/esteban/" rel="nofollow" target="_blank">http://cs.ulb.ac.be/members/esteban/</a><br clear="none">------------------------------------------------------------</div></div></div></div></div></div>
</blockquote></div></div><br clear="all"><br clear="none">-- <br clear="none"><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a shape="rect" href="http://georepublic.de" rel="nofollow" target="_blank">georepublic.de</a>
Web: <a shape="rect" href="https://georepublic.info" rel="nofollow" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
</div></div></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>