Upgrades to speed

[swmm-js]

My internal testing shows some large speed improvements at a cost of about 0.1% error. I'm sure I'm doing something wrong, I'll finish up the basics of the full web interface and then do some more testing on EPA-SWMM. Thanks for pointing me in the right direction.

[dickinsonre]

You probably need to add some details on the speed improvements so others can verity your findings.

[swmm-js]

I will, these are unit tests on large amounts of randomized data using currently ugly optimizations and my absolutely awful implementations of memos in c. They aren't in my codebase yet, but it looks promising, if 0.05%-0.09% errors don't compound too much.

…

On May 28, 2023, at 6:05 AM, dickinsonre_Autodesk ***@***.***> wrote:  You probably need to add some details on the speed improvements so others can verity your findings. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[michaeltryby]

@swmm-js I moved this from an issue to a discussion. Feel free to keep us updated on your progress. Thanks!

[swmm-js]

I've stabilized the computations for USER5 to near identical results. I'll see what else I can do.

Standard 5.23:

************************** Volume Depth
Runoff Quantity Continuity acre-feet inches
************************** --------- -------
Total Precipitation ...... 287.426 2.930
Evaporation Loss ......... 1.614 0.016
Infiltration Loss ........ 97.947 0.998
Surface Runoff ........... 172.956 1.763
Final Storage ............ 14.917 0.152
Continuity Error (%) ..... -0.003

************************** Volume Volume
Flow Routing Continuity acre-feet 10^6 gal
************************** --------- ---------
Dry Weather Inflow ....... 0.000 0.000
Wet Weather Inflow ....... 173.343 56.486
Groundwater Inflow ....... 0.000 0.000
RDII Inflow .............. 0.000 0.000
External Inflow .......... 121.535 39.604
External Outflow ......... 153.446 50.003
Flooding Loss ............ 0.000 0.000
Evaporation Loss ......... 0.070 0.023
Exfiltration Loss ........ 0.000 0.000
Initial Stored Volume .... 3.241 1.056
Final Stored Volume ...... 151.619 49.407
Continuity Error (%) ..... -2.353

---

Highest Continuity Errors

---

Node 3SB22 (61.19%)
Node 4SB21 (37.63%)
Node 42SB1 (32.88%)
Node 2SB21 (27.52%)
Node 1050 (25.52%)

Updated 5.23:

************************** Volume Depth
Runoff Quantity Continuity acre-feet inches
************************** --------- -------
Total Precipitation ...... 287.426 2.930
Evaporation Loss ......... 1.614 0.016
Infiltration Loss ........ 97.947 0.998
Surface Runoff ........... 172.956 1.763
Final Storage ............ 14.917 0.152
Continuity Error (%) ..... -0.003

************************** Volume Volume
Flow Routing Continuity acre-feet 10^6 gal
************************** --------- ---------
Dry Weather Inflow ....... 0.000 0.000
Wet Weather Inflow ....... 173.343 56.486
Groundwater Inflow ....... 0.000 0.000
RDII Inflow .............. 0.000 0.000
External Inflow .......... 121.535 39.604
External Outflow ......... 153.447 50.003
Flooding Loss ............ 0.000 0.000
Evaporation Loss ......... 0.070 0.023
Exfiltration Loss ........ 0.000 0.000
Initial Stored Volume .... 3.241 1.056
Final Stored Volume ...... 151.617 49.407
Continuity Error (%) ..... -2.353

---

Highest Continuity Errors

---

Node 3SB22 (61.20%)
Node 4SB21 (37.64%)
Node 42SB1 (32.87%)
Node 2SB21 (27.52%)
Node 1050 (25.52%)

[cbuahin]

@swmm-js it will be constructive to see what parts of the code you have modified to achieve these results. What is the improvement in performance you are seeing? This information will be helpful so that we are able to review and provide constructive ideas and feedback if warranted. It is hard to say anything or respond to the comments provided so far without this information.

[cbuahin]

Ultimately, what is your goal as it relates to your findings? Do you want it considered for inclusion into the SWMM code? If yes, providing clarity on the items I highlighted will be helpful for rigorous evaluation.

[swmm-js]

I'd like to explain a little about why I am holding back. I once had a job (more than one like this story, really) where my manager had a program that took two weeks to run. He was very proud of that program, and bragged that it was so complex that it takes two weeks to run. I offered to help him with it, and spent a few days optimizing the process. I reduced the run speed to less than a second, and showed him how. He then had me moved to error checking subcatchment delineations and presented my work to the bureau as his own.

In another case, a group of 20+ engineers had been working for more than a decade on developing standardized rainfall events, claiming that it was too complex to predict. I spent a few days looking at the decades of rainfall data and presented them with a full range of easily traceable rainfall events, explained how they could be replicated and why they worked. I was fired and they immediately published my work as their own.

In another case, I was introduced to an asset management system that previously was so broken that it required a technician to sit at a computer for over a month while the process chugged away and the technician waited for it to stop and break and then fix that one record entry and then reinitiate the process. I reduced the runspeed to seconds and integrated it with the current geospatial system and I do not care to retell what happened to me after that.

There have been many good people that I have met that I love to work with and love my work and that are very appreciative of my help. Still, getting falsified parking tickets and being assaulted after work and having my home vandalized has shown me that some people do not appreciate my help.

I want this to go well, and I'd like to finish these changes because there are so many of them.

[michaeltryby]

@swmm-js That sounds rough. I'm sorry you had those experiences.

[cbuahin]

@swmm-js, I understand your concerns. Experiment away! I am sure we will all love to see your results and approach when you are ready to share details.

[michaeltryby]

@cbuahin I'm of the mindset that experimentation is good. If nothing else it is constructive to see what @swmm-js can achieve using a memoization approach. It may prove useful elsewhere in the project or inspire other ideas.

[bemcdonnell]

@swmm-js, I always find that it's a good idea to wear a hard hat when working in open source. This mainly helps prevent me from knocking myself out on my own laptop when I bang my head against it after I push my bugged code. Writing code and sharing it with the public is an art form and exposes you to a lot of vulnerability. I don't think this audience is going to see that you get parking tickets. Some of us (here) have been working in open source for 10 years. It's a very respectable place to work and play.. and it's way more fun than just watching other people do it. Barely anyone actually engages in any form of open source SWMM! But when you do, you'll be thankful that you have a hard hat on. Anyway, if you feel open to it, sharing code is something tangible that we can have a conversation around. :-)

[michaeltryby]

Thanks for your perspective @bemcdonnell. @swmm-js is welcome to do as he pleases.

[dickinsonre]

@swmm-js Getting the same CE is good but what about speed? If your code is faster than native SWMM5 then assuming the inp files are the same the difference has to be the average time stepa and the average number of iterations - when you show a comparison you might also show the routing time step summary

---

Routing Time Step Summary

---

Minimum Time Step : 0.50 sec
Average Time Step : 2.06 sec
Maximum Time Step : 30.00 sec
% of Time in Steady State : 0.00
Average Iterations per Step : 3.22
% of Steps Not Converging : 10.10
Time Step Frequencies :
30.000 - 13.228 sec : 0.01 %
13.228 - 5.833 sec : 0.04 %
5.833 - 2.572 sec : 1.04 %
2.572 - 1.134 sec : 97.87 %
1.134 - 0.500 sec : 1.03 %

[swmm-js]

Depending upon the model, it varies, with the older updates it was usually around 4.5% better times, with increases in speed as the base system took more time, so 7% was the cap that I saw with that, but those were only 1 minute model runs.

The new system I have modified user5 to get some more time step changes but I'm really tired and need to sleep so I'm sure there's something wrong with my mods. Shows a 20% faster (though its only 4 vs 5 second run time) run for user5:

Updated:
Final Stored Volume ...... 151.594 49.399
Continuity Error (%) ..... -2.338

Analysis begun on: Thu Jun 1 13:18:54 2023
Analysis ended on: Thu Jun 1 13:18:58 2023
Total elapsed time: 00:00:04

Standard:
Final Stored Volume ...... 151.602 49.402
Continuity Error (%) ..... -2.341

Analysis begun on: Thu Jun 1 13:18:47 2023
Analysis ended on: Thu Jun 1 13:18:52 2023
Total elapsed time: 00:00:05

[swmm-js]

Yeah still about 5% when I tweak it to go slower.

[swmm-js]

I see what you are saying:

New:

---

Routing Time Step Summary

---

Minimum Time Step : 0.10 sec
Average Time Step : 1.00 sec
Maximum Time Step : 1.00 sec
% of Time in Steady State : 0.00
Average Iterations per Step : 2.00
% of Steps Not Converging : 0.02
Time Step Frequencies :
1.000 - 0.631 sec : 99.77 %
0.631 - 0.398 sec : 0.11 %
0.398 - 0.251 sec : 0.06 %
0.251 - 0.158 sec : 0.04 %
0.158 - 0.100 sec : 0.02 %

Analysis begun on: Thu Jun 1 15:38:44 2023
Analysis ended on: Thu Jun 1 15:39:39 2023
Total elapsed time: 00:00:55

Standard:

---

Routing Time Step Summary

---

Minimum Time Step : 0.10 sec
Average Time Step : 1.00 sec
Maximum Time Step : 1.00 sec
% of Time in Steady State : 0.00
Average Iterations per Step : 2.00
% of Steps Not Converging : 0.02
Time Step Frequencies :
1.000 - 0.631 sec : 99.77 %
0.631 - 0.398 sec : 0.11 %
0.398 - 0.251 sec : 0.07 %
0.251 - 0.158 sec : 0.04 %
0.158 - 0.100 sec : 0.02 %

Analysis begun on: Thu Jun 1 15:37:35 2023
Analysis ended on: Thu Jun 1 15:38:33 2023
Total elapsed time: 00:00:58

[swmm-js]

Here's a modified user5 with the timeseries extended to a 6-day input and 10-second max time steps:

New:

---

Routing Time Step Summary

---

Minimum Time Step : 0.10 sec
Average Time Step : 2.02 sec
Maximum Time Step : 10.00 sec
% of Time in Steady State : 0.00
Average Iterations per Step : 2.02
% of Steps Not Converging : 0.07
Time Step Frequencies :
10.000 - 3.981 sec : 0.02 %
3.981 - 1.585 sec : 97.49 %
1.585 - 0.631 sec : 2.06 %
0.631 - 0.251 sec : 0.34 %
0.251 - 0.100 sec : 0.09 %

---

Routing Time Step Summary

---

Minimum Time Step : 0.06 sec
Average Time Step : 2.02 sec
Maximum Time Step : 10.00 sec
% of Time in Steady State : 0.00
Average Iterations per Step : 2.02
% of Steps Not Converging : 0.06
Time Step Frequencies :
10.000 - 3.981 sec : 0.02 %
3.981 - 1.585 sec : 97.49 %
1.585 - 0.631 sec : 2.06 %
0.631 - 0.251 sec : 0.34 %
0.251 - 0.100 sec : 0.10 %

[dickinsonre]

In your code did the this value decrease from 0.07 or vice versa "% of Steps Not Converging : 0.06"

[swmm-js]

Yes, but its something I can calibrate to match the traditional pattern.

I am wondering about rkqs, which seems to only have values of errmax>1.0 at the beginning of each day:

    // --- error too large; reduce stepsize & repeat
    if (errmax > 1.0)
    {
    printf(" %f", errmax);

only fires results at the beginning of the day.

[swmm-js]

This isn't important for this model, it looks like.

[dickinsonre]

odesolve uses rkqs for integrating the runoff depth and groundwater depth. It is not a source of slowness in SWMM5 as the bulk of SWMM5's computational efforts deal with the link hydraulics. Hydrology time steps as well have longer computational time steps whereas the links are often solved at second time steps or even smaller.

[swmm-js]

I think I'm going to move on to memoizing functions, but I just want to check some error results I'm seeing on my end. Do I have my math wrong? Is A_Circ in xsect.dat modified in some way? I know there isn't much of a difference, but I want to know what the acceptable error is on static tables and dynamic memo storage and I just thought I'd pull up A_Circ to get a comparison.

in published code:

double A_Circ[51] = // A/Afull v. Y/Yfull
{0.0,.00471,.0134,.024446,.0374,.05208,.0680,.08505,.1033,.12236,
.1423,.16310,.1845,.20665,.2292,.25236,.2759,.29985,.3242,.34874,
.3736,.39878,.4237,.44907,.4745,.500,.5255,.55093,.5763,.60135,
.6264,.65126,.6758,.70015,.7241,.74764,.7708,.79335,.8154,.83690,
.8576,.87764,.8967,.91495,.9320,.94792,.9626,.97555,.9866,.99516,1.000};

calcs:

double A_Circ[51] =
{0, 0.00477, 0.01342, 0.0245, 0.03748, 0.05204, 0.06797, 0.08509, 0.10328,
0.1224, 0.14238, 0.16312, 0.18455, 0.2066, 0.22921, 0.25232, 0.27587,
0.29981, 0.3241, 0.34869, 0.37353, 0.39858, 0.42379, 0.44912, 0.47454,
0.5, 0.52546, 0.55088, 0.57621, 0.60142, 0.62647, 0.65131, 0.6759,
0.70019, 0.72413, 0.74768, 0.77079, 0.7934, 0.81545, 0.83688, 0.85762,
0.8776, 0.89672, 0.91491, 0.93203, 0.94796, 0.96252, 0.9755, 0.98658,
0.99523, 1.000};

[swmm-js]

It's really not much of a difference at all, and totally negligible to the results. I'm just thinking about the count of objects in the table (51) and the gap tolerance for table entries. These entries are not really in question, and the differences are so tiny it isn't worth discussing an update, I just wanted know if there's a factor here I don't know about.

[dickinsonre]

I would read the EPA manual for how the values in XSECT are computed. If you remember or maybe not remember the values originally came from the SWMM4 Fortran code - a combination of the Transport layer of SWMM and the Extran program.

[swmm-js]

What I am doing right now if deciding if my gap tolerances of table entries for static and dynamic tables are acceptable.

I just want to make clear: I am not error-checking current tables, I am finding the current acceptable gap error.

I am not looking to correct any code here, I am trying to find a point where differences between the new results and the traditional results agree within acceptable error.

Widening the table entries for A_Circ to 201 entries instead of 51 entries gives the following result changes for 849_1 of user5.inp:

published code results (51 entries):

index ID

179 849_1
Date/Time Flow Depth Velocity Volume Capacity

08/11/1998 00:01:00 0.000 0.003 0.000 0.269 0.000
08/11/1998 00:02:00 0.000 0.019 0.000 1.992 0.001
08/11/1998 00:03:00 0.000 0.053 0.000 7.935 0.002
08/11/1998 00:04:00 0.000 0.121 0.001 26.468 0.006
08/11/1998 00:05:00 -0.034 0.225 -0.084 64.354 0.016
08/11/1998 00:06:00 -0.449 0.381 -0.626 121.367 0.035
08/11/1998 00:07:00 -0.833 0.611 -0.626 215.069 0.070
08/11/1998 00:08:00 1.309 0.881 0.499 352.511 0.119
08/11/1998 00:09:00 6.163 1.127 1.837 498.871 0.169
08/11/1998 00:10:00 12.096 1.412 2.628 684.207 0.232

with 201 entries:
index ID

179 849_1
Date/Time Flow Depth Velocity Volume Capacity

08/11/1998 00:01:00 0.000 0.003 0.000 0.158 0.000
08/11/1998 00:02:00 0.000 0.019 0.000 1.772 0.000
08/11/1998 00:03:00 0.000 0.054 0.000 8.069 0.002
08/11/1998 00:04:00 0.000 0.123 0.000 27.059 0.007
08/11/1998 00:05:00 -0.033 0.226 -0.083 64.666 0.016
08/11/1998 00:06:00 -0.433 0.376 -0.613 119.356 0.034
08/11/1998 00:07:00 -0.827 0.616 -0.617 217.437 0.071
08/11/1998 00:08:00 1.299 0.881 0.498 352.778 0.119
08/11/1998 00:09:00 6.172 1.127 1.837 499.175 0.169
08/11/1998 00:10:00 12.245 1.418 2.646 688.055 0.233

[dickinsonre]

The reason for having more table entries is to have more precision. I assume.

[swmm-js]

Yes. If your pipe is 8+' in diameter, a 51-entry table loses granularity. I am not going to go into the geometry comparisons, but it is apparent that this impacts results in the 1% range even for smaller pipes.

[swmm-js]

As a test, I'm showing one of the static table updates, which is probably a bad idea on my end - feel free to dismiss it entirely:

funcs.h:

double altfunc1(double val);

dwflow, findconduitsflow, line 208:

// --- compute terms of momentum eqn.:
// --- 1. friction slope term
if ( xsect->type == FORCE_MAIN && isFull )
     dq1 = dt * forcemain_getFricSlope(j, fabs(v), rMid);
else {
    if(rWtd >= 4 ){
        dq1 = dt * Conduit[k].roughFactor / pow(rWtd, 1.33333) * fabs(v);
    } else {
        dq1 = dt * Conduit[k].roughFactor / altfunc1(rWtd) * fabs(v);
    }
}

altfuncs.c (new):

//=============================================================================

double altfunc1(double val)
//
{
return lookup(val/4.0, W_altfunc1, N_W_altfunc1);
}

int N_W_altfunc1 = valcount;
double W_altfunc1[valcount] = {...}

so for valcount 801, which has much better error result tolerance than A_Circ, that (static) table would start like this:

{0, 0.000855, 0.002154, 0.003699, 0.005429, 0.00731, 0.009322, 0.011449,
0.01368, 0.016006, 0.01842, 0.020916, 0.023489, 0.026135, 0.028849, 0.031629,
0.034471, 0.037373, 0.040333, 0.043348, 0.046416, 0.049536, 0.052706,
0.055924, 0.05919, 0.0625, 0.065856, 0.069254, 0.072695, 0.076178, 0.0797,
0.083262, 0.086862, 0.0905, 0.094175, 0.097886, 0.101632, 0.105414, 0.10923,
0.113079, 0.116961, 0.120876, 0.124823, 0.128801, 0.132811, 0.13685, 0.14092,
0.145019, 0.149148, 0.153305, 0.157491, 0.161705, 0.165946, 0.170214,
0.17451, 0.178832, 0.18318, 0.187555, 0.191955, 0.19638, 0.200831, 0.205306,
0.209806, 0.21433, 0.218878, 0.22345, 0.228045, 0.232663, 0.237305, 0.241969,
0.246656, 0.251366, 0.256097, 0.260851, 0.265626, 0.270423, 0.275241, ...}

[swmm-js]

I'll hold off on posting more, but these "static" tables can be dynamically allocated at startup and initialized using a fill function (like for(int val = 0; val <=valcount; val++) altfunc[val] = pow(val, 1.33333), to allow for fine tuning of results and also to keep the code clean.

I'm pretty sure the same can be done for xsect.dat, but that isn't really a performance upgrade, just a architecture shift.

[swmm-js]

Well, sorry, technically it would be a result upgrade for all xsect results, but not a speed upgrade, because it would allow for higher resolution xsect tables with less clutter and better traceable function inputs.

[dickinsonre]

does valcount 801 mean you are using 800+ table entries for the link hydraulics?

[swmm-js]

It's a variable you can set at runtime. So if you are running on a low-memory system like a cellphone or an IoT microprocessor, you can keep it at 50. If you are running on a supercomputer, you can just go wild with 10,000. I just set it at 800 last and pulled the variables. Yes, it means 800 table entries. Which does not impact speed, and has a minimal impact on memory.

The newer form of table entries will simply be formulas that are run prior to the full model run. The user or program sets the precision and the results are either what you are used to at 51 table entries or super-precise at 800+. This is great for the newer, larger pipe systems. I remember several projects modeling larger pipes that needed something like this.

[dickinsonre]

Others have suggested a power function for the xsect variables - which essentially gives you the 10.000 cross section points.

[swmm-js]

I have created the dynamic table system for xsect variables and am waiting on review of the dwflow pull request.

The xsect variables use a static or dynamic table system instead of a power function because of the extreme cost and repetition of these types of calculations. There is another solution, but it would be considered silly

[swmm-js]

I have tidied up these changes and created a pull request.

I have also created a similar update for xsections, but it is not in a pull request yet.