Pieter just ran into an issue where the JVM was just allowing single-threaded execution. It seems that then matsim also runs single-threaded, ignoring all of our config settings. In consequence, the random numbers are different, leading to different results.
It might be worthwhile to find out if there is a way to find out from inside matsim how many threads the JVM will allow, and abort with an exception is that is less than what the config demands.
What JVM was that?
What OS was it run on?
It seems that then matsim also runs single-threaded, ignoring all of our config settings.
This sounds strange.
MATSim just creates the number of threads as specified in the config file. I would expect Java to produce some kind of Exception if I create more threads than the JVM allows. But clearly not: “Oh, you’re creating 5 threads, well, I only create 1 and do all the work in there”, because, how should the JVM know how to combine the work of the multiple threads into one thread.
Is there any logfile of such a run available? Because at the moment I can’t believe this really happened, and rather think there must have been something overseen.
the JVM was just allowing single-threaded execution
How, and why? Normally, at least parts of the garbage collection already run in parallel, so I cannot imagine how one wants to restrict the JVM to only use a single thread. Maybe with some OS limits you can make the JVM use only a single physical core of the CPU, but the JVM should still support multiple threads and will just run slower as all the threads are run somehow sequentially on that one CPU.
I agree, it sounds strange. It was run on some mainframe somewhere. Maybe the thread limit for the jvm was indeed one, and matsim died, and the operators, after looking at the error, set the number of threads in the config file to one, and didn't tell Pieter.
The internet is returning "something" (e.g. https://plumbr.io/outofmemory-threads), but there should have been an interpretable error message.
➝ closing the issue