<div dir="ltr"><div>Thanks Ben. You beat me to the punch sending this out. I give credit to you for first suggesting updates to scipy were responsible. As Ben pointed out in person, this is expected to become more of an issue as the machines in the lab have their packages updated, motivating this group email so everyone knows now. Providing a bit more material below on the subject in case anyone is interested:<br><br></div>The place this flag suggestion was initially found was:<br>    <a href="https://stackoverflow.com/questions/22418634/numpy-openblas-set-maximum-number-of-threads">https://stackoverflow.com/questions/22418634/numpy-openblas-set-maximum-number-of-threads</a><br><div><div>There are some conversations and related links there that might be enlightening. Checking the release notes on the newer versions of scipy and numpy were also useful.<br><br></div><div>For me, this became an issue when multiple threads were being spawn despite the fact that multithreading was not explicitly invoked in the code in question.<br></div><div>Specifically, using only scipy sparse matrix libraries and looking at the column NLWP in htop,  some machines could be seen using one thread and others using as many threads as thread contexts.<br></div><div>Machines that had single threads listed for the processes were using:<br><div style="margin-left:40px">>>> import scipy<br>>>> scipy.__version__<br>'0.12.1'<br>>>> import numpy<br>>>> numpy.__version__<br>'1.7.1'<br></div></div><div>and machines that invoked multiple threads were using:<br><div style="margin-left:40px">>>> import scipy<br>>>> scipy.__version__<br>'1.0.0'<br>>>> import numpy<br>>>> numpy.__version__<br>'1.14.0'<br></div>For the runs in question, life went much better after forcing the number of threads to one. As Ben said, using more threads does not imply that runs will go no slower.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 3:59 PM, Matthew Barnes <span dir="ltr"><<a href="mailto:mbarnes1@andrew.cmu.edu" target="_blank">mbarnes1@andrew.cmu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This happens even with basic multiprocessing in Python, for example the multiprocessing.Pool.map operation. Don't be like me and accidentally start 2500 processes :)</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 30, 2018 at 3:53 PM Benedikt Boecking <<a href="mailto:boecking@andrew.cmu.edu" target="_blank">boecking@andrew.cmu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
With newer versions of numpy (and maybe scipy) it is possible that some operations use all available CPUs by default (thanks to David Bayani for pointing this out). This can also happen if you use packages that rely on numpy and scipy such as statsmodels. On our servers this appears to be caused by the use of the open MP API. <br>
<br>
While automatic multi processing can be a great feature, it can cause trouble if it is combined with additional multi processing (e.g. your own use of the multiprocessing or joblib libraries) or when multiple users unwittingly spawn too many threads at the same time. <br>
<br>
If you want to control the number of threads used through open MP, use the OMP_NUM_THREADS environment variable  when you run your python code (with a reasonable number of threads):<br>
<br>
[user@server ~]$ OMP_NUM_THREADS=8 python yourscript.py <br>
<br>
Also, it is a great habit to run top or htop to monitor your resource consumption to make sure you aren’t inconveniencing other users of our lab’s resources.<br>
<br>
Best,<br>
Ben<br>
</blockquote></div>
</div></div></blockquote></div><br></div>