Matthias Maier

@jppelteret is exactly right. The issue is that the `std::function` objects within the `LinearOperator` have to copy the function body from other `LinearOperator` object on creation. We (as in @luca-heltai,...

@bangerth Specifically for `operator-`. This had been a situation that always annoyed me: The problem being that our interface for `vmult()` and `vmult_add()` for our matrices should really read `vmult(Number...

@bangerth > Separately, though, since we take references to the matrix objects, couldn't we also just keep references to their respective Epetra_Map objects, rather than copying them? If that happens...

Just as an example that this is possible for a (really) large scale project: The linux kernel is moving towards merging the "fast kernel headers" patchset: https://lwn.net/ml/linux-kernel/[email protected]/

Some of our polynomials/fe classes use a `Thread::mutex` to guard scratch data. How shall I proceed? I can give all of them appropriate copy constructors/etc. or make the scratch area...

> Threads::Mutex is difficult to replace by std::mutex because the former is copyable whereas the latter is not. In essence, if you want to make the replacement, you will have...

@bangerth Yes. No thread local storage in this case then.

@tjhei Yes. This line unconditionally sets `SET(DEAL_II_WITH_THREADS ON)` in the project configuration. If you want to have a different behavior for now you can simply replace the `ON` by `${DEAL_II_WITH_TBB}`...

On Fri, May 29, 2020, at 08:54 CDT, Timo Heister wrote: >> If you want to have a different behavior for now > > We now always support creation of...

@tjhei The results for taskflow v4 look very promising. Out of curiosity: Would you mind to run the assembly also for, say about 2-4M DoF (just comparing taskflow v4 versus...