gmsh issueshttps://gitlab.onelab.info/gmsh/gmsh/-/issues2022-04-01T07:19:55Zhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/22Improve 1D transfinite algorithm2022-04-01T07:19:55ZChristophe GeuzaineImprove 1D transfinite algorithm** Add linear lc progression in 1D transfinite generator
* Implement easier to understand "bump" function (double progression?)** Add linear lc progression in 1D transfinite generator
* Implement easier to understand "bump" function (double progression?)https://gitlab.onelab.info/gmsh/gmsh/-/issues/24Improvements to extrusion algorithms2023-10-09T19:19:02ZChristophe GeuzaineImprovements to extrusion algorithmsThis issue tracks some ideas about generalizations of the extrusion algorithms:
* It would be nice to be able to create extruded meshes for OCC pipes
* not clear how to do this in all cases (cf. all the possible `trihedron` values: ...This issue tracks some ideas about generalizations of the extrusion algorithms:
* It would be nice to be able to create extruded meshes for OCC pipes
* not clear how to do this in all cases (cf. all the possible `trihedron` values: "DiscreteTrihedron", "CorrectedFrenet", "Fixed", ...); maybe just for the simplest case where we would evaluate the "guiding" curve?
* It would be nice to be able to provide a scaling function - see e.g. #1991
* It could be useful to introduce Right/Left/Alternate for extruded meshes, as for transfinite meshes
* We could fill transfinite_vertices in meshG{Face,Region}Extrude when it makes sense (so that we can use extruded+recombined surfaces to create Transfinite Volumes, or use the P3D or structured CGNS output format)
* It could be useful to define some templates to extrude + refine in order to generate "structured refinements"
* in 2D: from 1 curve to 3, or from 1 curve to 2 (left and right)
* in 3D: the usual patterns...https://gitlab.onelab.info/gmsh/gmsh/-/issues/29Mesh/view capping2023-07-27T12:31:09ZChristophe GeuzaineMesh/view cappingAdd new visu option to cap the mesh instead of displaying "whole"
elementsAdd new visu option to cap the mesh instead of displaying "whole"
elementshttps://gitlab.onelab.info/gmsh/gmsh/-/issues/33Problem with datasets with bounding box < 1e-6 on Mac OS X2023-07-27T12:34:34ZChristophe GeuzaineProblem with datasets with bounding box < 1e-6 on Mac OS XOn Mac OS X, datasets with a bounding box < 1.e-06 don't display
properly (probably because all the OpenGL stuff is done internally in
single precision...). Should we rescale?On Mac OS X, datasets with a bounding box < 1.e-06 don't display
properly (probably because all the OpenGL stuff is done internally in
single precision...). Should we rescale?https://gitlab.onelab.info/gmsh/gmsh/-/issues/63add ability to pick/select mesh vertices in GUI2023-07-27T12:34:49ZChristophe Geuzaineadd ability to pick/select mesh vertices in GUIWe should draw mesh vertices using vertex arrays and add the ability to select them.
This requires some changes
* in the VertexArray class to store vertex pointers if necessary
* in drawMesh to not use immediate drawing mode for ve...We should draw mesh vertices using vertex arrays and add the ability to select them.
This requires some changes
* in the VertexArray class to store vertex pointers if necessary
* in drawMesh to not use immediate drawing mode for verticeshttps://gitlab.onelab.info/gmsh/gmsh/-/issues/75Tensorial fields visualization enhancements2018-08-21T10:17:59ZChristophe GeuzaineTensorial fields visualization enhancementsMay I suggest two enhancements for better tensorial fields visualization:
- In Node data or Elmt data section of .msh2 file format, the second int tag corresponds to the number of values defined by node/element. For the visualization, ...May I suggest two enhancements for better tensorial fields visualization:
- In Node data or Elmt data section of .msh2 file format, the second int tag corresponds to the number of values defined by node/element. For the visualization, it automatically recognizes the values 1 (scalar), 3 (norm of vector) and 9 (von Mises equivalent value). It would be useful to recognize 6 as well to reduce amount of data in result file (symmetric tensor as for strain/stress under SPH).
For this, a convention has to be adopted for:
- The way values are listed (v0-v4-v8-v1-v5-v2 or v0-v4-v8-v5-v2-v1 or v0-v1-v2-v4-v5-v8)
- Multiplicative factor for shear values - classically, a '2' is used for strain, and '1' for stress; other approach is to use sqrt(2) for all fields; maybe for coherence with the other fields type in gmsh, better to always keep '1'.
- In the 'Extract' plugin, if dealing with a tensorial field and von-Mises stress is illustrated, it would be logical to have the corresponding von Mises formula instead of sqrt(v0*v0 + v1*v1 + v2*v2), which is valid for vectors.https://gitlab.onelab.info/gmsh/gmsh/-/issues/78deal with relative paths with -watch option2017-08-05T11:31:52ZChristophe Geuzainedeal with relative paths with -watch option-watch works well with absolute paths -- check what's going on with reltive paths-watch works well with absolute paths -- check what's going on with reltive pathshttps://gitlab.onelab.info/gmsh/gmsh/-/issues/125Transfinite Volume does not accept a surface which has not been explicitly 'T...2017-08-06T06:54:09ZChristophe GeuzaineTransfinite Volume does not accept a surface which has not been explicitly 'Transfinite(d)'Transfinite Volume doesn't accept a surface which has not been explicitly 'Transfinite(d)' : for example it does not accept surface whose mesh was obtained using Periodic Surface with a master Surface 'transfinited' (and recombined).
The...Transfinite Volume doesn't accept a surface which has not been explicitly 'Transfinite(d)' : for example it does not accept surface whose mesh was obtained using Periodic Surface with a master Surface 'transfinited' (and recombined).
The same problem occurs if we try to transfinite a volume containing a new "top" surface num[0] obtained by extruding a 'transfinited' surface (or all other surfaces that are created during the extrusion)
[test_periodic_surface.geo](/uploads/194f0c158b86634e4416e94ab7ad1ebc/test_periodic_surface.geo)https://gitlab.onelab.info/gmsh/gmsh/-/issues/136enhance Plugin(MathEval)2018-08-25T06:48:43ZChristophe Geuzaineenhance Plugin(MathEval)It would be nice to enhance MathEval to handle:
- vector operations (dotProd, crossProd, grad, div, curl)
- operations on complex numbers
- any number of views (and not only current+other)It would be nice to enhance MathEval to handle:
- vector operations (dotProd, crossProd, grad, div, curl)
- operations on complex numbers
- any number of views (and not only current+other)https://gitlab.onelab.info/gmsh/gmsh/-/issues/175"Adapt Visualization Grid" hides complete result of med library result2017-08-06T06:59:52ZChristophe Geuzaine"Adapt Visualization Grid" hides complete result of med library resultI’m loading a file in gmsh which was created by code_aster (a “med” format). It is easy to visualize the results on second order displacements:
1. Switching on “Adapt visualization grid”
2. Maximum recursion level = “1”
3. Target visual...I’m loading a file in gmsh which was created by code_aster (a “med” format). It is easy to visualize the results on second order displacements:
1. Switching on “Adapt visualization grid”
2. Maximum recursion level = “1”
3. Target visualization error = “-0.0001”
The gmsh debug info about this field is
```
Info : Reading 2-component field <<&RESUR1_DEPL>>
Debug : MED: eletyp=0 entity=3 (0:cell, 3:node, 4:elenode) ngauss=1 localizationName= profileName= -- stepDataType=1
```
However, when visualizing another field (here a nodal stress field"), pressing the "Adapt visualization grid" button will hide the entire result!. I found no options for "recursion level" or "target visualization error" which allows me to restore the result.
For example a result from a plain strain analysis:
```
Info : Reading 4-component field <<&RESUR1_SIGM_NOEU>>
Debug : MED: eletyp=0 entity=3 (0:cell, 3:node, 4:elenode) ngauss=1 localizationName= profileName= -- stepDataType=1
```
I'm attaching the file which contains both fields in order to let you reproduce this. The best way to see it is when using "Numerical Values" as "Intervals Type" and switching on the nodes "Mesh.Nodes=1".
-SebastianChristophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/gmsh/-/issues/181'Data source' in post-processing doesn't respect 'Visibility -> Force Component'2017-08-06T06:55:50ZChristophe Geuzaine'Data source' in post-processing doesn't respect 'Visibility -> Force Component'I noticed that setting the option
```
Post processing options -> Aspect -> Data Source
```
to a different view only uses the default `Visibility`. E.g. for a six component field (a stress tensor), the _Von Mises_ scalar is used as c...I noticed that setting the option
```
Post processing options -> Aspect -> Data Source
```
to a different view only uses the default `Visibility`. E.g. for a six component field (a stress tensor), the _Von Mises_ scalar is used as colour.
This is a often utilized as a way of showing stresses on a deformed structure.
When looking at the undeformed stress field view, the tab
```
Post processing options -> Visibility -> Force Scalar
```
allows one to select components of the tensor (e.g. only normal stress sigma_x). The deformed view doesn't allow this selection, as far as I can tell.
It would be best if the visibility settings of the tensor field are respected also in the 'deformed view'. Furthermore, the settings in `View[i].CustomMax` and `View[i].CustomMin` should be respected.
Steps to reproduce:
As an example, I'm attaching two files. One holds the deformation information and the other one the stress tensor
1.
```
gmsh smarter-cuboid-micro-stress.rmed smarter-cuboid-micro.rmed
```
2. Set `View[0] -> Visibility -> Force Scalar` and `View[0] - > General -> Range mode` to _Custom_. Hit the `Min`, `Max` button.
3. remember how the picture changed from Von Mises to sigma_x
4. turn off the visibility of `View[0]`
5. Set `View[1] -> Aspect -> Data Source` to `View[0]` (the Von Mises data of `View[0]` is shown).
Changes in `View[0] -> Visibility -> Force Component` and changes in `View[0].CustomMin/Max` are not affecting the current `View[1]`.
I _think_ this would be the expected behaviour. Thanks for your attention.
[smarter-cuboid-micro-stress.rmed](/uploads/64f6dd197fd400e4c40a0174bf0cbaef/smarter-cuboid-micro-stress.rmed)
[smarter-cuboid-micro.rmed](/uploads/da788ca02c496aca741b5a9b0086aa8b/smarter-cuboid-micro.rmed)
https://gitlab.onelab.info/gmsh/gmsh/-/issues/213Add support for PERMAS mesh files2017-08-06T07:10:27ZChristophe GeuzaineAdd support for PERMAS mesh filesAny patch would be welcome. Check out one of the Geo/GModelIO_*.cpp files: integrating a new mesh format is quite easy.Any patch would be welcome. Check out one of the Geo/GModelIO_*.cpp files: integrating a new mesh format is quite easy.https://gitlab.onelab.info/gmsh/gmsh/-/issues/226missing leading zeros with command Printf/Sprintf for gmsh-2.8.3-Windows642023-07-30T20:47:31ZChristophe Geuzainemissing leading zeros with command Printf/Sprintf for gmsh-2.8.3-Windows64The following commands were written in a geo script:
n=100;
Printf("n=%04g",n);
The script was tested with gmsh-2.8.3 under windows (using gmsh-2.8.3-Windows64.zip) and linux (using gmsh-2.8.3-source.tgz + own build)
Executing the s...The following commands were written in a geo script:
n=100;
Printf("n=%04g",n);
The script was tested with gmsh-2.8.3 under windows (using gmsh-2.8.3-Windows64.zip) and linux (using gmsh-2.8.3-source.tgz + own build)
Executing the script on linux lead to the expected result: n=0100
Executing the script on windows leads to n=100 instead of n=0100.
Similar behavior is observed with Sprintf command.Christophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/gmsh/-/issues/232Extrusion with scaling2017-08-06T07:00:42ZChristophe GeuzaineExtrusion with scalingThe possibility to extrude mesh with simultaneous scaling, for example to create mesh in truncated cone would be very helpful.The possibility to extrude mesh with simultaneous scaling, for example to create mesh in truncated cone would be very helpful.https://gitlab.onelab.info/gmsh/gmsh/-/issues/242Suggest Copy Transfinite Properties for Periodic Slave Faces in Volumes2017-08-05T11:43:00ZChristophe GeuzaineSuggest Copy Transfinite Properties for Periodic Slave Faces in VolumesPresently when using periodic master/slave faces the master
face meshing successfully copies to the slave face for 1D and 2D
including transfinite and 'recombined' properties (i.e. generating
quadrilaterals).
However to transfinite me...Presently when using periodic master/slave faces the master
face meshing successfully copies to the slave face for 1D and 2D
including transfinite and 'recombined' properties (i.e. generating
quadrilaterals).
However to transfinite mesh a *volume(, the slave faces must be
separately re-declared as transfinite, otherwise
MeshTransfiniteVolume(GRegion*) does not recognise them as such
(face.index() remains uninitialised as -1) and rejects the volume
(it does not recognise the faces as 'all transfinite').https://gitlab.onelab.info/gmsh/gmsh/-/issues/245Ellipse arc is wrong when symmetric start-end points are provided2017-08-05T11:42:17ZChristophe GeuzaineEllipse arc is wrong when symmetric start-end points are providedConsider this example:
```
R1 = 1.0;
R2 = 2.0;
Point(1) = { 0.0, 0.0, 0.0 };
Point(2) = { R1 * Cos(0), R2 * Sin(0), 0.0 };
Point(3) = { R1 * Cos(Pi/2), R2 * Sin(Pi/2), 0.0 };
Point(4) = { R1 * Cos(Pi), R2 * Sin(Pi), 0.0 };
Point(6) = ...Consider this example:
```
R1 = 1.0;
R2 = 2.0;
Point(1) = { 0.0, 0.0, 0.0 };
Point(2) = { R1 * Cos(0), R2 * Sin(0), 0.0 };
Point(3) = { R1 * Cos(Pi/2), R2 * Sin(Pi/2), 0.0 };
Point(4) = { R1 * Cos(Pi), R2 * Sin(Pi), 0.0 };
Point(6) = { R1 * Cos(Pi/6), R2 * Sin(Pi/6), 0.0 };
Point(7) = { R1 * Cos(5*Pi/6), R2 * Sin(5*Pi/6), 0.0 };
Ellipse(1) = { 2, 1, 3, 7 }; // Ok
Ellipse(2) = { 6, 1, 3, 7 }; // Wrong
```
Ellipse 2 is wrong. It is worth noticing that a Circle arc under the same conditions works fine:
```
R = 1.0;
Point(1) = { 0.0, 0.0, 0.0 };
Point(2) = { R * Cos(Pi/6), R * Sin(Pi/6), 0.0 };
Point(3) = { R * Cos(5*Pi/6), R * Sin(5*Pi/6), 0.0 };
Circle(1) = { 2, 1, 3 };
```
A workaround is to draw the ellipse in two pieces:
```
Ellipse(4) = { 6, 1, 3, 3 };
Ellipse(5) = { 3, 1, 3, 7 };
```https://gitlab.onelab.info/gmsh/gmsh/-/issues/313"ellipse is wrong" still plagues - diagnostic and workaround2018-08-21T08:01:08ZLuís Henrique Camargo Quiroz"ellipse is wrong" still plagues - diagnostic and workaroundI noticed a problem while creating some ellipse segments within a script.
Attached is a small geo file which shows the problem, and also with a solution for my particular case, at least. As I know the radiuses of the ellipse, I could ...I noticed a problem while creating some ellipse segments within a script.
Attached is a small geo file which shows the problem, and also with a solution for my particular case, at least. As I know the radiuses of the ellipse, I could find a workaround; my ellipse is aligned with X and Y.
This is the same problem shown in http://onelab.info/pipermail/gmsh/2012/007549.html and http://onelab.info/pipermail/gmsh/2011/006322.html years ago.
Rotating the start, major axis and end points with the GUI and creating the ellipses again shows the same problem. In other words, when start and end points are simmetrical, regarding any of the axes, major or minor, the strange behavior will appear.
Here's the geometry file: [gmsh_bugs.geo](/uploads/d5f5f64eda5cd8bddec725501910ac2c/gmsh_bugs.geo)
This is how the two wrong ellipses show up:
![Gmsh_with_2_buggy_ellipses](/uploads/b2314644673b02a061b55cf0a5958bed/Gmsh_with_2_buggy_ellipses.png)
This is the desired result, here obtained subdividing the arcs, as the error message tells. In my case I know what the new points should be ;)
![Gmsh_with_buggy_ellipses_replaced](/uploads/65181f85e2a3629affa2df0410711bdd/Gmsh_with_buggy_ellipses_replaced.png)https://gitlab.onelab.info/gmsh/gmsh/-/issues/326closures not implemented for pyramids and prisms of order > 22018-07-29T11:19:22ZKoen Hillewaertclosures not implemented for pyramids and prisms of order > 2I see that the face closures are used essentially for optimizing high order meshes. Would it be possible to complete the missing functionality for the pyramid and prism up to order 4 ?I see that the face closures are used essentially for optimizing high order meshes. Would it be possible to complete the missing functionality for the pyramid and prism up to order 4 ?https://gitlab.onelab.info/gmsh/gmsh/-/issues/338Physical Groups and Periodic Implementations not Persistent2023-07-31T11:24:16ZElizabethPhysical Groups and Periodic Implementations not PersistentWhen a physical group or a periodic element is defined, an OpenCASCADE operation will remove them.
A physical line that is intersected with a boolean operation will disappear.
In the case of a cube with a periodic surface, this means...When a physical group or a periodic element is defined, an OpenCASCADE operation will remove them.
A physical line that is intersected with a boolean operation will disappear.
In the case of a cube with a periodic surface, this means that it is not possible to enforce periodicity in the mesh. In the tested scenario, the periodic cube has a single sphere intersecting the surface, therefore, it is replicated on both sides of the cube. Even if the user uses the GUI to find the new surface ID's and manually re-implements a periodic surface for the sliced surfaces, the mesh is not periodic.https://gitlab.onelab.info/gmsh/gmsh/-/issues/363Element data format can only hold displacement and not rotation2018-02-06T05:20:46ZSaeid M.Element data format can only hold displacement and not rotationDear GMSH development team,
GMSH can be very useful in post-processing DEM (Discrete Elements Method) data; where there are almost no alternative software and GMSH has the potential to fill this gap and become a popular software among r...Dear GMSH development team,
GMSH can be very useful in post-processing DEM (Discrete Elements Method) data; where there are almost no alternative software and GMSH has the potential to fill this gap and become a popular software among researchers in this field by what seems like a minor improvement.
While GMSH can save displacement data of elements and visualize them, currently there is no option to save element rotations in element data field.
Best regards,
Mehrpay