<div dir="ltr"><div><div><div><div>Hi all,<br><br></div>We've updated the /etc/profile default file on the compute nodes to have the environment variable OMP_NUM_THREADS=1 by default.  This *should* make things behave the way they behaved before the update.  If you want the OpenMP library to do its threading for you then you can just override the environment variable in your own ~/.profile file, or set it when you start your script like Ben demonstrated.<br><br></div>NOTE that you will have to log out and log back in before this change takes effect.  This includes any screen or tmux sessions you may have active!<br><br></div>Let Predrag or I know if this causes other problems.<br><br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 5:32 PM, David Bayani <span dir="ltr"><<a href="mailto:dbayani@andrew.cmu.edu" target="_blank">dbayani@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"><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" target="_blank">https://stackoverflow.com/<wbr>questions/22418634/numpy-<wbr>openblas-set-maximum-number-<wbr>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="HOEnZb"><div class="h5"><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="m_4204650775239047730HOEnZb"><div class="m_4204650775239047730h5"><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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><font color="#888888">
Simon Heath, Research Programmer and Analyst<br>
Robotics Institute - Auton Lab<br>
Carnegie Mellon University<br>
<a href="mailto:sheath@andrew.cmu.edu" target="_blank">sheath@andrew.cmu.edu</a></font></span></div></div>
</div>