gmsh issueshttps://gitlab.onelab.info/gmsh/gmsh/-/issues2018-11-17T07:50:20Zhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/432Handle self-intersecting 1D mesh in periodic case2018-11-17T07:50:20ZChristophe GeuzaineHandle self-intersecting 1D mesh in periodic caseThe subject says it all :-)
We need to port the self-intersecting 1D mesh fix to `meshGeneratorPeriodic`.The subject says it all :-)
We need to port the self-intersecting 1D mesh fix to `meshGeneratorPeriodic`.Gmsh 5.0https://gitlab.onelab.info/gmsh/gmsh/-/issues/39564 bit Node and Element tags2019-02-20T15:18:53ZChristophe Geuzaine64 bit Node and Element tagsWe should switch MVertex::_num/_index and MElement::_num to 64 bit integers, to support meshes > 2 billion nodes/elements.
Doing so while ensuring C++98 support is complicated, as "long" is only 32 bits on Win64 (and 64 bits elsewhere)....We should switch MVertex::_num/_index and MElement::_num to 64 bit integers, to support meshes > 2 billion nodes/elements.
Doing so while ensuring C++98 support is complicated, as "long" is only 32 bits on Win64 (and 64 bits elsewhere). It would be better to ensure that we are 64 bit everywhere, while still using a standard C++ type and not some ugly OS-dependent typedef. C++11 defines "long long" (and optionally int64_t), which is guaranteed to be 64 bits: we should probably use that.
This is a non trivial change:
* the binary MSH4 format should allow to store tags in 32 or 64 bits (to save space). We should use the currently unused `size(unsigned long)` field in `$MeshFormat` (and change its meaning to "byte size of any tags in the file") to switch. All the binary I/O should be adapted to handle this.
* all the direct index-based iterations on std::vectors (currently using `unsigned int`) should switch to `std::vector<int>::size_type`.
* Note that we use negative node numbers in some meshing algorithms, so we should keep a signed type for nodes.Gmsh 5.0Christophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/gmsh/-/issues/394C++112020-08-25T16:04:24ZChristophe GeuzaineC++11We will switch to C++11 in Gmsh 5.0. This bug is simply to there as a reminder :-)
Other switches:
* require CMake 3We will switch to C++11 in Gmsh 5.0. This bug is simply to there as a reminder :-)
Other switches:
* require CMake 3Gmsh 5.0https://gitlab.onelab.info/gmsh/gmsh/-/issues/188Stabilize a small public API in C++, C and Python2018-01-10T06:52:52ZChristophe GeuzaineStabilize a small public API in C++, C and PythonThe title says it all: we need to provide a small, stable API in C++, C and Python.
This is a major goal for Gmsh 4.0.
Work in progress: http://gitlab.onelab.info/gmsh/gmsh/blob/master/api
Examples in C++ and Python: http://gitlab.one...The title says it all: we need to provide a small, stable API in C++, C and Python.
This is a major goal for Gmsh 4.0.
Work in progress: http://gitlab.onelab.info/gmsh/gmsh/blob/master/api
Examples in C++ and Python: http://gitlab.onelab.info/gmsh/gmsh/blob/master/demos/api
Gmsh 5.0Christophe GeuzaineChristophe Geuzaine