Timo Heister

bigger run shows the same behavior: ``` Number of active cells: 65536 Number of degrees of freedom: 1640961 ** TASKFLOW v4 ** n_cores auto 0.686414 0.722665 0.705674 0.699835 0.694059 avg:...

If I turn off hyperthreading in the OS, I see better results: - 32 cores is as fast as 16 cores - fastest time is as fast as the best...

While not amazing, this is at least not worse than TBB. > The separated point off to the right is the "automatic" choice the program outputs, which I believe means...

colored version (PR coming soon) is working pretty well: ``` $ nice ./tests/multithreading/bench_01.release/bench_01.release Number of active cells: 4096 Number of degrees of freedom: 103041 MultithreadInfo::n_cores()=32 (limited from 32) MultithreadInfo::n_threads()=32 0.459301...

I see two calls to ``soltrans.prepare_for_coarsening_and_refinement``. That can't be right. But we should have a better error message. :-)

Makes sense. I think the logic is only correct for isotropic refinement and with a connected domain. How do you propose we do this correctly? Even letting each process iterate...

> At least the first of these code snippets appears correct to me since it pertains to per-cell data. I I disagree. This is an offset into the data file...

@marcfehling I have the fix for the variable transfer ready to go as well. Do I see this right, that we do not test this anywhere?

details about the problem: ``` Proc 1 got line 110 from 0 wrong values! Proc 1 got line 111 from 0 wrong values! Proc 1 got line 114 from 0...

> does grid 3 look like? And what constraints are missing? 2d subdivided_hyper_cube with one coarsened and one refined cell (haven't looked at it). I assume it involves locally relevant...