dbeurle / imr Goto Github PK

@phuschke Can we rely on c++14?

When outputting a serial mesh, sometimes the code speeds a very long time allocating and deallocating memory. This behavior is not apparent with decomposed meshes.

Abaqus has a nice structured mesh generator that should be read in and converted.

It would be cool to output the data into json format. It would be used to read in the data quickly by each process and the parsing can be minimal.

Placeholder for discussion about the best way to process meshes for the FETI method.

The output for the distributed mesh is a little confusing. @phuschke What exactly does the following mean? I have a unit square with four partitions of each one element. For the first partition I get:

{
    "GlobalStartId" : [ 4 ],
    "Master" : [ 1 ],
    "NodeIds" : [
       [ 9 ]
    ],
    "Slave" : [ 4 ],
    "Value" : [ 1 ]
}

From what I can gather, Master is the owner (partition 1) and Slave is partition 4. But this node is also shared on process 2 and 3, but there is no mention of this here. Is this something specific to FETI?

Also for the Value field: it is 1 if this partition is the owner from processId == master_partition - 1 ? 1 : -1 but can't this be determined from Master and the current process number? Also will these fields ever be more than one element? If not - can't we just use single values?

We can get cmake to fetch catch using their instructions here: https://github.com/philsquared/Catch/blob/master/docs/build-systems.md#cmake

I think that the catch path in missing in tests/ReaderTest.cpp. Maybe use #include <catch/catch.hpp> instead of #include <catch.hpp>?

There is a new gmsh format. We should handle that.

Problem

Neither

gmshreader --with-indices gmshMWE.msh

nor

gmshreader --local-ordering --with-indices gmshMWE.msh

gives the expected result.

MWE

gmshMWE.msh

$MeshFormat
2.2 0 8
$EndMeshFormat
$Nodes
5
1 0 0 0
2 1 0 0
3 1 1 0
4 0 1 0
5 0.5 0.5 0
$EndNodes
$Elements
4
1 2 5 7 6 2 2 -1 1 2 5
2 2 5 7 6 2 1 -2 1 5 4
3 2 5 7 6 2 2 -1 2 3 5
4 2 5 7 6 2 1 -2 3 4 5
$EndElements

It should be deriving from std::runtime_error instead and defining our own classes.

See http://en.cppreference.com/w/cpp/error for implementation details

Currently the clang toolchain does not enjoy those GNU macros.