skim calculation taking quite long

[Tim Klein]

Hi All,

using 1.5.2 on python 3.12.10 / windows 11 now and arrived at skim matrix calculation. Which seems to take much longer than what i was used to with 0.9.5. (when it was still working), and it also produces somewhat psychedelic console output. Is there a way to speed this up, am i missing some parameter?

My script goes like this:

        project = Project.from_path(fldr)

        # build graph
        fields = [mode + '_minutes', mode + '_distance']
        modes = [mode]
        project.network.build_graphs(fields, modes)
        graph = project.network.graphs[mode]

        # see what graphs are available
        print('project.network.graphs.keys()')
        print(project.network.graphs.keys())

        # try to save/overwrite
        try:
            project.matrices.clear_database()
        except:
            pass

        # skim travel time
        # minimize the time
        m = mode + '_minutes'
        graph.set_graph(m)
        graph.set_skimming([m])
        # allow paths to be computed going through other centroids/centroid connectors
        graph.set_blocked_centroid_flows(False)
        skm = NetworkSkimming(graph)
        skm.set_cores(4)
        skm.execute()

And here's the console output...

Cheers, Tim

[Pedro Camargo]

Hey Tim,

There has been no performance regression in AequilibraE that we know of, and we have tested it quite a bit.  There are differences in how it is compiled, so I guess there is a possibility that using an old version of Numpy could be causing problems (I find it implausible, however).

My guess here is that there is some issue in the graph itself that is tripping AequilibraE up and sending it on an infinite loop, but it is hard to tell without looking at the data itself.  Have you tried computing paths from point to point to see if you can isolate the issue?

You can use 

graph.compute_path(origin, destination)

Also, the API for skimming is a little more elegant now:

        graph.set_graph(m)
        graph.set_skimming([m])
        # allow paths to be computed going through other centroids/centroid connectors
        graph.set_blocked_centroid_flows(False)

        skm = graph.compute_skims(cores=4)

On the outputs, I can only say that working with tqdm is hard... We are working on a complete overhaul, but unfunded work is slow...

You can turn it off if you'd like.

import os

os.environ["AEQ_SHOW_PROGRESS"] == "FALSE"

Cheers,

Pedro

--
You received this message because you are subscribed to the Google Groups "AequilibraE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aequilibrae...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/aequilibrae/c5568c22-4beb-4a9f-a9fe-707686428224n%40googlegroups.com.

[Tim Klein]

Hi Pedro,

thanks fo rthe quick reply. I'll try both suggestions. Old numpy version is rather unlikely after i installed aequlibrae in various setups 4 or 5 times over by now. Also - i was so much faster with 0.9.5 last year! 

Regarding the outputs, i do not really understand what they're about but i'm tempted to think that it documents some kind of iterative path optimisation when what i need for the skim is just one (1) shortest path in an unloaded network? The skript is still running, at 9% now, but at that pace i might be faster if i write a python loop over "graph.compute_path" myself. 

Also thanks for the info on how to turn output off - I've seen python skripts bogged down by too much of it in the shell. Or maybe we can throw in a carriage return '\r' somewhere?

And finally, unfunded work, well, i see and i wholeheartedly approve the emergence of some opensource competition to ptv etc., but i'm underwater with this myself, freelancing and all. If i ever find the time i might think about wrapping up an example for a prt demand model and submit a workshop at https://agit.at/en/ for it, if that'd help.

Cheers, tim

Op vrijdag 13 februari 2026 om 00:11:09 UTC+1 schreef Pedro Camargo:

[Tim Klein]

oops, regarding the output:

Traceback (most recent call last):
  File "xxxxxxxxxx\py\02b skims assignment.py", line 608, in <module>
    environ["AEQ_SHOW_PROGRESS"] == "FALSE"
  File "<frozen os>", line 714, in __getitem__
KeyError: 'AEQ_SHOW_PROGRESS'

??

Op vrijdag 13 februari 2026 om 00:11:09 UTC+1 schreef Pedro Camargo:

Hey Tim,

[Jake Moss]

Hi Tim,

The output you are seeing is the skim progress bar. Unfortunately the IDLE editor is not a terminal emulator and is unable to correctly render the return carriages in the output. If you set the environment Pedro mentioned it will disable the progress bar output.

As for the slowdown I believe it is cause by IDLE taking longer and longer to render the “progress bar” output. We haven’t observed a regression in performance recently. If it persists when disabling the progress bars please file an issue with a minimal example.

In your stack trace there it should be a single equals to assign the variable, rather than get, then compare equality.

Regards,

Jake

On 13 Feb 2026, at 7:05 pm, Tim Klein <tristram...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/aequilibrae/e8c02823-2f55-4e59-bcd0-a83a7cc941efn%40googlegroups.com.

[Tim Klein]

oh well, yeah, that did it. cool. thanks. 

Op vrijdag 13 februari 2026 om 10:19:11 UTC+1 schreef Jake Moss:

[Pedro Camargo]

Ops... My bad!

To view this discussion visit https://groups.google.com/d/msgid/aequilibrae/b0dc4a13-8fe3-42a6-ae26-10915156cee2n%40googlegroups.com.