Hi there Thomas, Thanks for your reply.
It is interesting that you were also using UMFPACK as your solver. However, I want to clarify that UMFPACK is not responsible for the threads as far as I can see, they are spawned by threaded building blocks. I recompiled my code without my call to task_scheduler_init and using CG rather than UMFPACK. The large number of threads are spawned before the solver is even reached in this case. They are spawned as DoFs are setup, which I believe corresponds to the first time tasks are used. So threaded building blocks spawns multiple threads, and the number can be controlled by calling taks_scheduler_init in most cases (however it shouldn't be unless really required for example when using part of a large SMP machine). However somehow the wrapping of the UMFPACK solver seems to make a call to tasks outside of the scope of the main program which by passes the fix described above. I presume that it is possible some other solvers external to deal.II may behave in a similar way. Cheers, Michael On Fri, May 28, 2010 at 11:49 AM, Thomas Wick <[email protected]> wrote: > Hi Michael, hi all! > > I would like to support your statement: > > This is the answer to my question to Wolfgang B. some weeks ago. > I was running a deal.ii program without any explicit calls for threads but > using UMFPACK for solving the linear equations. > However, I observed that my program spawned threads. > > Now, it seems clear that umfpack is responsible for the threads, but somehow > annoying. > > Cheers, > > Thomas > > > > > On Fri, 28 May 2010, Michael Rapson wrote: > >> Hi all, >> >> I wanted to follow up my previous message about setting the number of >> threads used by deal.II with some new information. >> >> In my previous message I said that I had found out that you can >> control the number of threads that TBB uses by calling >> task_scheduler_init before anything else in the code, and specifying >> the number of threads to use. The code snippet is: >> #include <tbb/task_scheduler_init.h> >> using namespace tbb; >> >> And then call the following method early in your main loop: >> task_scheduler_init init(n_desired_threads + 1); >> >> This was more successful than I realized and when I went through my >> program with gdb I found that the correct number of threads were used >> until the program reached a call to SparseDirectUMFPACK (the >> initialize routine I believe), where a large number of threads were >> spawned. When I changed my solver to deal.II's CG solver the program >> executed using the desired number of threads. >> >> I find this a little surprising because as far as I know UMFPACK >> itself is not multithreaded. My rough understanding of what is >> happening is that when UMFPACK is called it is somehow outside of the >> scope of my original program and hence my task_scheduler_init call. If >> something not directly related to UMFPACK made a call to >> task_scheduler_init outside of the scope of my original call TBB would >> determine a good number of threads to spawn and hence cause the >> observed behavior. >> >> So for the moment I am not using UMFPACK, which is a pity because it >> was a very efficient solver for my system, but the method outlined >> above seems like a usable way to control the number of threads in most >> cases. >> >> Cheers, >> Michael >> _______________________________________________ >> dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii >> > _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
