gmsh issueshttps://gitlab.onelab.info/gmsh/gmsh/-/issues2019-04-09T12:11:28Zhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/481Rename internal classes to match documented terminology2019-04-09T12:11:28ZChristophe GeuzaineRename internal classes to match documented terminologyWe settled on the following names in the public API:
* geometry: points, curves, surfaces and volumes
* mesh: nodes and elements
We should refactor the internal classes to match those names:
* `GPoint` -> `GVertex`
* `GVertex` -> `G...We settled on the following names in the public API:
* geometry: points, curves, surfaces and volumes
* mesh: nodes and elements
We should refactor the internal classes to match those names:
* `GPoint` -> `GVertex`
* `GVertex` -> `GPoint`
* `GEdge` -> `GCurve`
* `GFace` -> `GSurface`
* `GRegion` -> `GVolume`
* `MVertex` -> `MNode`Gmsh 5.0Christophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/gmsh/-/issues/444MSH 4.x format revisions2023-03-03T10:56:41ZChristophe GeuzaineMSH 4.x format revisionsIdeas for future revisions of the MSH4 format:
MSH 4.1:
- ~~ability to use 64 bit node and element tags (see #395)~~ (done in MSH4.1)
- changes based on user feedback:
- ~~add min/max vertex/element tags in the section header (this ...Ideas for future revisions of the MSH4 format:
MSH 4.1:
- ~~ability to use 64 bit node and element tags (see #395)~~ (done in MSH4.1)
- changes based on user feedback:
- ~~add min/max vertex/element tags in the section header (this would allow to decide *beforehand* if a sparse (and slow) storage is necessary)~~ (done in MSH4.1)
- ~~switch `dim` and `tag` in Nodes/Element section to match the api and the Periodic section~~ (done in MSH4.1)
- ~~store onyly x, y, z for `$Entities` of dimension 0 (points), instead of xmin, xmax, ymin, ymax, zmin, zmax~~ (done in MSH4.1)
MSH 4.x:
- rework post-processing fields:
- ability to choose float size (this can be done without changing the format, by using one of the integer tags in the header to provide the float size)
- separate tags and values to not mix integer and floating point data
- block structure for `$ElementNodeData` (by `numcomp`), so that size is predictable
- rework `$GhostElements` section to not mix `int` and `size_t`
- additional features for high-performance parallel IO, for readers using MPI IO
- compress the binary arrays using zlib?
- store embedded entities in the brep ($Entities)
Not in the format per-se, but related:
- ~~include an option to renumber meshes *based on physical definitions*, i.e. renumber all the nodes/elements that are needed by physical groups first, followed by all the other nodes/elements? We could use something similar to `getAdditionalEntities` in the MSH4 code to sort entities.~~ (implemented in Gmsh 4.1.0)Gmsh 5.0Christophe GeuzaineChristophe Geuzainehttps://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