Add support for parallel 2D simulations on static, uniform mesh

[sloede]

Corresponds to WP1 in #159.

TODO

• [ ] Parallelize smooth_alpha! postponed as discussed
• Add testing capabilities for MPI tests
• Test all parallel algorithms to increase coverage again >= 97%
• Run basic tests on Odin with O(100) ranks

[codecov]

Codecov Report

Merging #167 into master will decrease coverage by 0.17%.
The diff coverage is 86.49%.

@@            Coverage Diff             @@
##           master     #167      +/-   ##
==========================================
- Coverage   91.53%   91.36%   -0.18%     
==========================================
  Files          36       42       +6     
  Lines        8037     8863     +826     
==========================================
+ Hits         7357     8098     +741     
- Misses        680      765      +85     

Impacted Files	Coverage Δ
src/solvers/dg/2d/amr.jl	96.15% <0.00%> (ø)
src/solvers/dg/3d/containers.jl	91.93% <0.00%> (ø)
src/auxiliary/containers.jl	88.70% <40.00%> (-2.05%)	⬇️
src/solvers/dg/1d/amr.jl	94.96% <50.00%> (+0.07%)	⬆️
src/solvers/dg/3d/amr.jl	95.07% <50.00%> (+0.04%)	⬆️
src/mesh/abstract_tree.jl	90.27% <57.14%> (ø)
src/solvers/dg/3d/dg.jl	92.20% <61.29%> (+0.09%)	⬆️
src/solvers/dg/1d/dg.jl	93.10% <65.38%> (+0.17%)	⬆️
src/io/io.jl	89.10% <68.75%> (-1.81%)	⬇️
src/mesh/mesh.jl	86.30% <75.00%> (-0.59%)	⬇️
... and 19 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bea72a0...a7011af. Read the comment docs.

[sloede]

@ranocha After I shut down Zoom for a while, I started to get consistent timings for executing

time -p julia --project=. -e 'using Trixi; Trixi.run("examples/2d/parameters.toml")'

with the different implementations. Here's what I got on my laptop:

Code version	Time (julia)	Time (TimerOutputs)	Time (rhs!)	Memory (TimerOutputs)	Memory (rhs!)
master	74.4s	22.6s	26.4ms	8.89 GiB	1.36 MiB
msl/mpi_parallel @ a0bb098	79.8s	24.3s	26.9ms	9.79 GiB	1.36 MiB
msl/mpi_parallel @ 3566b47	❗ 101.6s	32.3s	27.4ms	❗ 19.1 GiB	1.36 MiB
msl/mpi_parallel @ f7d2463	70.9s	18.8s	34.1ms	1.83 GiB	1.36 MiB

master:

msl/mpi_parallel @ a0bb098:

msl/mpi_parallel @ 3566b47:

msl/mpi_parallel @ f7d2463:

Thus it seems that our change in the implementation, which mostly comes down to adding the MeshType to the Dg2D struct in a fancy way, increased the total time by >25%, and almost doubled the memory use. The runtime (and memory usage during the run) seems virtually unchanged, though, so I think this is not so much an issue of run time performance but of compile time performance. While I usually would discard this as something that shouldn't matter too much, the jump is just large enough that I do not feel comfortable with using the current version.

Update (2020-09-09, 5pm): I removed the mesh from the Dg2D struct again and instead used the "ugly" way of calling the auto-generated constructor for Dg2D. And, behold, this changes everything (as witnessed in the table above for f7d2463)! I don't know why the current branch even improves upon the memory usage in comparison to the current master (maybe there is a weird caching effect?), but if theses results continue to hold, I think I'll continue with this implementation.

[sloede]

Just for comparison, here are the numbers for the corresponding setup in 3D, i.e.,

time -p julia --project=. -e 'using Trixi; Trixi.run("examples/3d/parameters.toml")'

Code version	Time (julia)	Time (TimerOutputs)	Time (rhs!)	Memory (TimerOutputs)	Memory (rhs!)
master	73.4s	22.8s	251ms	8.07 GiB	1.53 MiB
msl/mpi_parallel @ a0bb098	76.2s	25.0s	277ms	8.10 GiB	1.53 MiB
msl/mpi_parallel @ 3566b47	❗ 100.6s	33.3s	268ms	❗ 15.6 GiB	1.53 MiB
msl/mpi_parallel @ d8212ca	69.4s	16.6s	245ms	1.53 GiB	1.53 MiB

master:

msl/mpi_parallel @ a0bb098:

msl/mpi_parallel @ 3566b47:

msl/mpi_parallel @ d8212ca:

Overall, it tells a similar story.

Update (2020-09-10, 5:30am): As expected, the same changes to Dg3D in d8212ca result in considerable improvements regarding time-to-first-solution and memory usage. I still do not get why this change also improves the memory usage so tremendously over master, but right now I'll just accept it and be happy about it...

[sloede]

The branch is ready for merge from my side. It would be great to get a final review (or a go-ahead).

[ranocha]

Nice work, @sloede!