gmsh issueshttps://gitlab.onelab.info/gmsh/gmsh/-/issues2024-01-26T09:33:38Zhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2784Partitioning, ghost elements and physical groups2024-01-26T09:33:38ZJames D. TrotterPartitioning, ghost elements and physical groupsHi Christophe,
I'm interested in partitioning a mesh for a problem involving multiple subdomains. At the moment, I am using physical groups to distinguish between the different subdomains, and I have partitioned the mesh using the METIS...Hi Christophe,
I'm interested in partitioning a mesh for a problem involving multiple subdomains. At the moment, I am using physical groups to distinguish between the different subdomains, and I have partitioned the mesh using the METIS-based partitioning built into Gmsh.
My question concerns the ghost elements as they are stored in the MSH4.1 ASCII format whenever the `-part_ghosts` and `-part_split` options are specified. If I understand correctly, any ghost element is added to a new entity block in the `$Elements` section, and this entity block is assigned an entity tag corresponding to a ghost entity. Furthermore, unlike the ordinary partitioned entities, ghost entities are listed separately at the beginning of the `$PartitionedEntities` section and they do not contain any information about physical tags.
In my case, I want to extract ghost elements belonging to a particular physical group. So, I'm wondering if this is a use case you have considered? Do you think it would require changes to the MSH4.1 format? Or can it already be done?https://gitlab.onelab.info/gmsh/gmsh/-/issues/27802D quasi-structured mesh for triangles2024-01-23T10:49:04ZMichael Ermakovermakov@ipmnet.ru2D quasi-structured mesh for trianglesA new 2D mesh generation function for a triangle [file.cpp](/uploads/f4523ff8aa35e0ae9273405f10efd1ac/file.cpp) .The triangle is splitted into 3 parts and for each part a TFI is employed. A number of mesh point along each curves is requi...A new 2D mesh generation function for a triangle [file.cpp](/uploads/f4523ff8aa35e0ae9273405f10efd1ac/file.cpp) .The triangle is splitted into 3 parts and for each part a TFI is employed. A number of mesh point along each curves is required to be the same and odd. I debuged it in the MeshGFaceTransfinite.cpp.
5 test geo files and figures are attached to demonstrate functionality.
[1.geo](/uploads/ecb75fc3fc8ea5ed04965756f6d2b545/1.geo)
[2.geo](/uploads/80a2f24afabc146f39c790998ddd3c9c/2.geo)
[3.geo](/uploads/f5a0d4e603a48a31bff146d91d6f0099/3.geo)
[4.geo](/uploads/efab67187ecbdbdf3e2778337d07f4c3/4.geo)
[5.geo](/uploads/da00e5d41e388da59daf5cfaceaf4346/5.geo)
![fig1](/uploads/7dba9b371aea01bc939c465a172382ad/fig1.png)
![fig2](/uploads/0c80eaa6537008354c111a39989e701c/fig2.png)
![fig3](/uploads/6154a15610972948f94fcd47eeb6921f/fig3.png)
![fig4](/uploads/b0cbbbb18e7b01af92b1e99221cb6c19/fig4.png)
![fig5](/uploads/14b4884f8cf927ff78035feb59ea70fe/fig5.png)https://gitlab.onelab.info/gmsh/gmsh/-/issues/2775What is the correct/practical way to make non-uniform mesh?2024-01-19T22:25:08ZCaleb WuWhat is the correct/practical way to make non-uniform mesh?I was trying to generate a multi-layer cube structure that contains parts of it using different finer meshes.
I found two ways to do it. (To simplify the case, I just have this structure having two layers with the same size and mesh size...I was trying to generate a multi-layer cube structure that contains parts of it using different finer meshes.
I found two ways to do it. (To simplify the case, I just have this structure having two layers with the same size and mesh size but part of the top layer should have finer mesh.) But it turns out that the two methods generate very different mesh. The second method seems to have some mistakes. It either generates some extra shape/mesh around the finer mesh sport or the finer mesh is not connected to the other part of the structure correctly.
The code is attached here.
[two_methods.zip](/uploads/e2febdf3b1ccd26a0f04da97e59e6966/two_methods.zip)
In the first method, it is done point by point, line by line, and surface by surface (Since two layers have the same mesh size, I did not really drtaw two layers there); while in the second method, the extrude method is used. The reason I was trying to do the second method is that I will have a much more complex structure so seems like the second method is more programmable because the first method needs to find every single point, line, and face in the order.
I need to put these two mesh into a solver to simulate the temperature map of the structure while the small part is the heat source.
Below are the images of the two mesh results from method 1 and method 2 respectively:
![compare1_2](/uploads/0a8a7c43e4db0d41368ea52311f61a3e/compare1_2.png)
The mesh and the temperature simulation result from method 1 looks reasonable while method 2 has a weird low-temperature spot overlapped with the heat source. It can also be seen that there is some mesh around that spot in the mesh plot. Feels like in method 2, mesh are not properly connected but I do not understand why.
Can anyone let me know what is the key difference between method 1 and method 2 and how to solve my problem?https://gitlab.onelab.info/gmsh/gmsh/-/issues/2773Can an stl file with a repeating mesh generate a Volume?2024-01-17T12:09:51ZbuzhiqiuyuebaiCan an stl file with a repeating mesh generate a Volume?I have two closed stl files, they are both closed but have overlapping parts, I can generate Volume using one of the stl meshes alone, but generating Volume using both stl at the same time will cause the Volume mesh to fail due to the ov...I have two closed stl files, they are both closed but have overlapping parts, I can generate Volume using one of the stl meshes alone, but generating Volume using both stl at the same time will cause the Volume mesh to fail due to the overlapping meshes, is there a good solution for this?
![image](/uploads/ec05c36d10824972241775e111ae06a3/image.png)
![image](/uploads/819e4914fd009b82b9ff297241ce572b/image.png)
![image](/uploads/9ac0323b3670a38a1c1c112f851ca2aa/image.png)
The file I use:
[Eye_Lens.stl](/uploads/5ca990fcb71705ae93c8ca2d14cc67a0/Eye_Lens.stl)
[Eye_Vitreous_.stl](/uploads/2b223b09a7626569ca71854c5e271a9d/Eye_Vitreous_.stl)
[loh.geo](/uploads/d5e8831a0000a383a8339c7fda0fcac4/loh.geo)https://gitlab.onelab.info/gmsh/gmsh/-/issues/2768Periodic Surfaces2024-01-15T16:30:19ZFrancesco Mario D'AfieroPeriodic SurfacesHello @geuzaine,
I'm trying to create two vertical periodic surfaces in 3D but when I check the created mesh they are not periodic at all.
The Info I get is: "No periodic vertices in surface 5 (maybe due to a structured mesh constraint ...Hello @geuzaine,
I'm trying to create two vertical periodic surfaces in 3D but when I check the created mesh they are not periodic at all.
The Info I get is: "No periodic vertices in surface 5 (maybe due to a structured mesh constraint on the target surface)"
The code I'm using is:
```
// Lines
Spline(l_idx+1) = {p_idx_last-7:p_idx_last-4};
Line(l_idx+2) = {p_idx_last-4:p_idx_last-3};
upp_bb() = Translate {0, Pitch, 0} { Duplicata{ Line{l_idx+1};} };
...
// Mesh size
Mesh.CharacteristicLengthMin = lc;
Mesh.CharacteristicLengthMax = lc;
// Transfinite
Transfinite Surface{2};
Mesh.RecombineAll = 1;
Mesh.Recombine3DAll = 1;
Mesh.Algorithm = 5;
Mesh.Smoothing = 1;
// Extrude
Extrude{0,0,lz}{ Surface{:}; Layers{neles_lz}; Recombine;}
Periodic Curve {l_idx+1} = {l_idx+3};
Periodic Surface {5} = {3} Translate {0, ly, 0};
```
Where am I wrong?
Best regardshttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2762Ask about using Cross-patch meshing with compounds to generate surface meshes...2024-02-04T13:41:57Zmike sunAsk about using Cross-patch meshing with compounds to generate surface meshes in the gmsh compiled version Hi,I am a beginner in gmsh software, I have successfully compiled the source code of gmsh under windows environment with VS2022 and cmake, but using the set compound function under the compiled version of gmsh causes problems in some m... Hi,I am a beginner in gmsh software, I have successfully compiled the source code of gmsh under windows environment with VS2022 and cmake, but using the set compound function under the compiled version of gmsh causes problems in some models, but these problems don't occur under the exe version from the gmsh website.
The error reporting model is in appendix 1, (the file EADS Mako_HEAT.geo records the set compound operation of EADS Mako_HEAT.stp), and these two files have to be placed in a folder to ensure that .geofile.The direct error is shown in Figure 1.![1](/uploads/f713a0ae68ce61393729f3e2e42b99da/1.png)
I looked at the source code to see exactly where the error is reported, it is in the parameterised solving lsys->systemSolve() of createGeometry of meshCompound of GFace::mesh, as shown in Figure 2, but this should not be the direct cause, I looked at the I've looked at the whole mesh generation process of gmsh, before 2D mesh generation, 1D mesh information is needed, for the model in the add-on during 1D mesh generation, the number and position of the nodes and line meshes of the mesh of my compiled version of gmsh are the same as those of the exe version of the official website of gmsh, but in the process of generating the 2D mesh, no matter which mesh algorithm is used, the mesh will be initial mesh, I have compared the compiled version with the exe version of gmsh, and I have found the error in lsys->systemSolve().
![2](/uploads/68319874aec47060fb4bb8bb38aeac7f/2.png)
compared the compiled version with the official website's exe version of the initial mesh, and found that there are not small differences between the two, in order to facilitate the display, I use a surface of the EADS Mako_HEAT.stp model (saved in EADS Mako_HEAT-face.stp) to generate the initial mesh as a demonstration, and Fig. 2 demonstrates the official website's exe version Figure 3 shows the exe version from the official website, and Figure 4 shows my compiled version.
![3](/uploads/3df407b0a74f7299605c6522a39f5b62/3.png)
![4](/uploads/035ecd2953c9c06501bfad9a1c15eb0d/4.png)
I tried many versions of opencascade and many versions of gmsh source code, but I can't avoid this problem. The exe version that can be used directly from the official website produces the same results, and the set compound operation handles the model without any model that can't generate a mesh.
I suspect that it may be a problem with my gmsh compilation, and I may not have turned on a certain option. The main configuration of my gmsh source code is shown in Figure 5.
![5](/uploads/f21e4908c8cb84c71ea562eb79cfd1d9/5.png)
Thank you for taking time to read this issues. I look forward to hearing from you soon.
[EADS_Mako_HEAT.geo](/uploads/eedd070b51c1887cfab712ed8f7a3307/EADS_Mako_HEAT.geo)
[EADS_Mako_HEAT.stp](/uploads/3dc87bac1642310183c05cc5b0ae75d0/EADS_Mako_HEAT.stp)
[EADS_Mako_HEAT-face.STEP](/uploads/42210a517c25094963367cd74a04da48/EADS_Mako_HEAT-face.STEP)https://gitlab.onelab.info/gmsh/gmsh/-/issues/2759Fillet function fails to compute2024-01-11T09:37:04ZGiannis NikiteasFillet function fails to computeI am having trouble getting the `gmsh.model.occ.fillet` function to produce fillets for slightly more complicated shapes like splines. The fillet operation fails with error
```log
Error : Could not compute fillet
```
I am not sure what...I am having trouble getting the `gmsh.model.occ.fillet` function to produce fillets for slightly more complicated shapes like splines. The fillet operation fails with error
```log
Error : Could not compute fillet
```
I am not sure what is going on. Any ideas how to fix this?
## Minimal Reproducible Example
```py
import gmsh
pts = [
[-0.034085297850175826, -0.015879999846220016, 0.05610177678812691],
[-0.025773123244386263, -0.015879999846220016, 0.055737574716152566],
[-0.01861002668738365, -0.015879999846220016, 0.049875155091285706],
[-0.020155801627512814, -0.015879999846220016, 0.04756111125307992],
[-0.0267215470989998, -0.015879999846220016, 0.0538179986178875],
[-0.03388876537948993, -0.015879999846220016, 0.04823366301018323],
[-0.02941742481905319, -0.015879999846220016, 0.04031772333946176],
[-0.033975317841607816, -0.015879999846220016, 0.03933049213305148],
[-0.03777569460804871, -0.015879999846220016, 0.04833597241423769],
]
gmsh.initialize()
pt_ids = [gmsh.model.occ.addPoint(*pt) for pt in pts]
spline = gmsh.model.occ.addBSpline(pt_ids + [pt_ids[0]])
surface = gmsh.model.occ.addPlaneSurface([gmsh.model.occ.addCurveLoop([spline])])
extrs = gmsh.model.occ.extrude([(2, surface)], 0, 0.01, 0)
vol = [e[1] for e in extrs if e[0] == 3]
gmsh.model.occ.synchronize()
gmsh.fltk.run()
gmsh.model.occ.fillet(vol, [spline], [0.0001])
gmsh.finalize()
```https://gitlab.onelab.info/gmsh/gmsh/-/issues/2754HomologyPostProcessing: false results for complicated geometry2023-12-30T17:19:20ZErik SchnaubeltHomologyPostProcessing: false results for complicated geometryHi everyone,
I'm moving [GetDP issue 164](https://gitlab.onelab.info/getdp/getdp/-/issues/164) here since it seems to be a problem with the `HomologyPostProcessing` plugin instead of `GetDP`.
We are trying to run a transient simulation...Hi everyone,
I'm moving [GetDP issue 164](https://gitlab.onelab.info/getdp/getdp/-/issues/164) here since it seems to be a problem with the `HomologyPostProcessing` plugin instead of `GetDP`.
We are trying to run a transient simulation of two insulated spiral pancake coils connected in series using an $\vec{H}-\phi$ formulation, see below for the geometry. Unfortunately, we could not reproduce the problem with easier geometries...
![geo](/uploads/6318b92f8318726c4775f093cc7e8dfb/geo.jpg)
This model setup then has two cohomology basis functions. We follow Section 5 of the Gmsh cohomology paper to create a cohomology basis of 2 elements with evident physical interpretation:
<details><summary>Details on the creation of the modified cohomology basis</summary>
- The original cohomology basis are regions 8 and 9
- We modify it by calling the `HomologyPostProcessing` plugin to make it compatible with the loops 6 (terminal current) and 11 ("free" current circulating in the cylindrical connecting parts)
- The resulting cuts are 12, 13 (and copies 3000001, 3000002), shown below
![first_one_chain](/uploads/15db5c5382919ba842f92e1a17f2b556/first_one_chain.jpg)
![second_one_chain](/uploads/62e615db55fa5ba0137d7161c85ded36/second_one_chain.jpg)
</details>
To check the cohomology basis, we then set up a very simple .pro file that only calls `InitSolution` in the `Resolution` and enforces a current of 1A in the first cut and 0A in the second (effectively "disabling" it). This should yield the following initial solution (log scale) with currents only in the conducting parts:
![12turns_okay](/uploads/2c21905a489dc5f830dd9e0ff605bd29/12turns_okay.jpg)
The above picture is for a spiral of 12 turns. When increasing the number of turns to 13, we have non-zero currents in the air domain:
![13turns_ko](/uploads/c3c6259b9ff0eb633a7c18ccc4284daa/13turns_ko.jpg)
- Using the cohomology basis created from the `HomologyComputation` (Regions 8 and 9 as commented in the `.pro`) without the rearranging to make homology and cohomology compatible, again no currents in the non-conducting domain. Thus, it seems to be a problem with the `HomologyPostProcessing` plugin
- Removing the second cut region, i.e. `DOM_airHoleCut = Region[{ }];`, there are no currents in non-conducting domains.
- Below 13 turns (exclusive), no air currents. Above 13 turns, air currents.
Please find below the simple .pro and two meshes for the two cases. We tested it with the official `GetDP 3.5.0` release.
[simple_init.pro](/uploads/6cb1fa203ab37b79defa701fe42c3799/simple_init.pro)
[12_turns_okay.msh](/uploads/ea7906290c08361f36bf676b7d26a0c6/12_turns_okay.msh)
[13_turns_not_okay.msh](/uploads/1daf106beb8f95b0060ab06fbcbcc676/13_turns_not_okay.msh)
Thank you for the help!
Erikhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2752Trying to split meshes, not using Metis, but manually for now.2024-01-02T16:30:58ZTodd DoehringTrying to split meshes, not using Metis, but manually for now.Hi! Apologies, I'm new to gitlab issue system, so I just assigned to defaults.
My question is:
Can, in the GUI, I select and 'split'; or in other words, select a subset of elements of a tetrahedral mesh into regions, by manual selection?...Hi! Apologies, I'm new to gitlab issue system, so I just assigned to defaults.
My question is:
Can, in the GUI, I select and 'split'; or in other words, select a subset of elements of a tetrahedral mesh into regions, by manual selection?
I understand the Metis approach, and will use that too, but I need to be able to manually select major regions first.
I see that I can select elements when I 'delete' them, but I don't want to delete them; just partition and keep them.
But since element selection during 'deletion' works... I'm guessing that I might be missing something obvious about the ability to select elements via a **lasso-type** method.
Or maybe not! I hope this question makes sense.
All suggestions are much appreciated.
Thanks! -ToddChristophe GeuzaineChristophe Geuzaine2024-01-03https://gitlab.onelab.info/gmsh/gmsh/-/issues/2749peculiar issue with opencascade : lines embedded in Volume conflict with non ...2024-01-02T11:54:23ZMarsyas Folvopeculiar issue with opencascade : lines embedded in Volume conflict with non intersecting surfaceHi everyone,
I have come up with a peculiar issue with a simple hexahedral mesh creation in GMSH GUI. Specifically I am including a surface and two lines in a box volume (model simplified from original to locate the issue), and I use OPE...Hi everyone,
I have come up with a peculiar issue with a simple hexahedral mesh creation in GMSH GUI. Specifically I am including a surface and two lines in a box volume (model simplified from original to locate the issue), and I use OPENCASCADE to configure any intersecting components and the embedment of lower dimension entities. The problem is that the line behind the surface is eventually removed from the volume when I include the surface in the volume through the booleanfragment command (see image bellow). If I move the line so that its projection to the surface plane is outside the surface it works ok. In any case gmsh does not give any errors.
![image](/uploads/88a54a1a2727db47043973c6734ed34e/image.png)
thank in advance for any help!
Here is the simple .geo file:
[MeshInputQuerry.geo](/uploads/36c02d355ee2ff33b16712dabe1c7f04/MeshInputQuerry.geo)
SetFactory("OpenCASCADE");
Point(1) = {30, 80, 0, 400};
Point(2) = {30, 80, -16.5, 400};
Point(3) = {30, 0, 0, 400};
Point(4) = {30, 0, -16.5, 400};
Point(5) = {-6.9, 1.5, -4, 400};
Point(6) = {-14.45, 1.5, -7, 400};
Point(7) = {36, 79.5, -4, 400};
Point(8) = {44, 79.5, -7, 400};
Line(1) = {1, 2};
Line(2) = {1, 3};
Line(3) = {3, 4};
Line(4) = {4, 2};
Line(5) = {5, 6};
Line(6) = {7, 8};
//This surface is the issue in combination with Line(6)!!!!!!!
Line Loop(7) = {3,4,-1,2};
Plane Surface(1) = {7} ;
//Create box volume:
Box(1) = {-50, -50, -30, 130, 180, 30};
v1() = BooleanFragments {Volume{:}; Delete; }{ Curve{:}; Delete; };
v2() = BooleanFragments {Volume{:}; Delete; }{ Surface{:}; Delete; };
Mesh.MshFileVersion = 2.2;https://gitlab.onelab.info/gmsh/gmsh/-/issues/2747(weird) trouble producing hexahedral mesh2024-01-03T08:12:28ZAndrea Vigliotti(weird) trouble producing hexahedral meshI am trying to produce a hexahedral mesh out of of domain obtained intersecting different polyhedral volumes by means of fragment operations.
If I try to produce a tetrahedral mesh of the domain all is fine, but if I try to produce a he...I am trying to produce a hexahedral mesh out of of domain obtained intersecting different polyhedral volumes by means of fragment operations.
If I try to produce a tetrahedral mesh of the domain all is fine, but if I try to produce a hexahedral mesh with these options
```
gmsh.option.setNumber("Mesh.SubdivisionAlgorithm", 1)
gmsh.option.setNumber("Mesh.RecombinationAlgorithm", 2)
gmsh.option.setNumber("Mesh.RecombineAll", 1)
```
the program crashes and nothing is produced. On the other hand, if I save the model as a `.step` file and reload the geometry from the `.step` file I am able to produce the mesh and save it, yet with a lot of errors of the type
```
Error : Pyramid top vertex already classified on volume 7 (!= 17) - non-manifold quad boundaries not supported yet
```
but still I can save the mesh. It seems as there are problems in the occ model that are solved when the file is saved as a `.step`. I am working from the `Julia` API so it seems I don't have the `Coherence` command. Does this ring any bell on what could be the problem?
many thanks in advance,
Andreahttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2746Issue with defining fields for Mesh adaptation2024-02-06T15:48:02ZQuentin SCHMIDIssue with defining fields for Mesh adaptationHi,
I am trying to refine the mesh based on fields like maximum Hessian eigenvalues or gradient of the distance but it is not very succesfull ...
attached is the code and the error I get.
It is largely inspired from tutoriel number 1
...Hi,
I am trying to refine the mesh based on fields like maximum Hessian eigenvalues or gradient of the distance but it is not very succesfull ...
attached is the code and the error I get.
It is largely inspired from tutoriel number 1
[Test_ADAPT_Interface.py](/uploads/6b7f262cbbe4244d8befc78fa4432ed3/Test_ADAPT_Interface.py)
![ResultGradient-ADAPT](/uploads/9959104e1f9498c90c2a1e0f4e37c801/ResultGradient-ADAPT.png)
![Screenshot_2023-12-18_135535](/uploads/b107b8f207657c8d9e979144b8e5e850/Screenshot_2023-12-18_135535.png)
any help would be really appreciatedhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2745Changing Points mesh size using Min Field2024-02-04T13:44:17ZPietro LizzioChanging Points mesh size using Min Field![nomesh](/uploads/ae31cf2beed3e9c887a0ccdd8f151740/nomesh.png)
Hello! I'm trying to change the mesh size of some points (shown in the first image), using the Min Field, via these instructions on a geo file:
`Field[1] = Constant;
Field...![nomesh](/uploads/ae31cf2beed3e9c887a0ccdd8f151740/nomesh.png)
Hello! I'm trying to change the mesh size of some points (shown in the first image), using the Min Field, via these instructions on a geo file:
`Field[1] = Constant;
Field[1].IncludeBoundary = 0;
Field[1].PointsList = {9,10};
Field[1].VIn = 1;
Field[1].VOut = 100000;
Field[2] = Constant;
Field[2].IncludeBoundary = 1;
Field[2].CurvesList = {1,2,3,4,5,6,7,8,9};
Field[2].VIn = 50;
Field[2].VOut = 100000;
Field[3] = Constant;
Field[3].IncludeBoundary = 0;
Field[3].SurfacesList = {1};
Field[3].VIn = 50;
Field[3].VOut = 100000;
Field[4] = Min;
Field[4].FieldsList = {1,2,3};Background Field = 4;`
The result is this:
![meshsize](/uploads/3fba305b3f17c453dd5ca67b465c1661/meshsize.png)
While the point (9) on the surface boundary is affected by the instructions provided in Field[1] and the mesh around it does seem to get finer, the point (10) doesn not seem to particularly care about VIn = 1. Am I missibg something? Maybe some instruction I'm overlooking?
For further info, this is the result if I remove Field[1]:
![meshsize_before](/uploads/7c06828b6aca63a9d9fd809ee54f85e1/meshsize_before.png)
Thank you!https://gitlab.onelab.info/gmsh/gmsh/-/issues/2738recursive occ.copy2024-01-02T09:11:23ZJan Brezinarecursive occ.copy# Context:
The model is prepared using several boolean operations with a set of primitives S.
In order to create boundary elements for prescribing BC, currently use this approach:
- We select boundary dimtags by auxiliary intersection ...# Context:
The model is prepared using several boolean operations with a set of primitives S.
In order to create boundary elements for prescribing BC, currently use this approach:
- We select boundary dimtags by auxiliary intersection with the boundary of some primitives from S.
- We add selected boundaries into the list of meshed entities and assign some region labels to them (using a map: dimtag -> region)
- After meshing, we use the region ma to assign regions to the elements.
This is a workaround for slow region/physical group operations in OCC.
We use the Python API.
# Problem:
The problem is that boolean operations break the original entities, so we want to apply boolean ops to the copies.
However, **OCC.copy is not recursive.**. It does not copy dimtag boundaries.
Therefore, the boundary of the primitives is broken, and if we try to use
some_primitive_copy.get_boundary() to select boundary elements through the intersection, the boundary is already invalid. We have to explicitly make copies of the boundaries we want to use later on.
There are two questions:
1. Is this approach appropriate? How do you deal with boundary marking?
2. Is it possible to perform a recursive copy in OCC model somehow?https://gitlab.onelab.info/gmsh/gmsh/-/issues/2735Create a circular pattern of axisymetric mesh2023-12-07T00:32:48ZEduardo FĂrvidaCreate a circular pattern of axisymetric meshHi, I'm cumming from this issue (https://gitlab.onelab.info/gmsh/gmsh/-/issues/1283) and I use the https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/examples/api/mirror_mesh.py example to perform my circular pattern.
My goal is to crea...Hi, I'm cumming from this issue (https://gitlab.onelab.info/gmsh/gmsh/-/issues/1283) and I use the https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/examples/api/mirror_mesh.py example to perform my circular pattern.
My goal is to create a axi-symetric rotatory machine mesh by copying its blade mesh N times as required. The problem here is that the common part of the mesh (blade base), seems to be a superposed unconnected meshes and not a single mesh. How can I do to re-mesh that part of the mesh to connect all blades bases, or some kind of mesh boolean union operation?, even if I loose the mesh symetry in that mesh part.
I want to do some FSI computations over this model.
I provide a simple "example" of my code:
[blade.geo](/uploads/cbc13c0d6d99b6443c2cdf15501ace44/blade.geo)
Python code:
```python
import math
import gmsh
import numpy as np
def rotate3D(p, v, angle):
angle = np.deg2rad(angle)
v = v / np.linalg.norm(v)
R = np.array(
[
[
np.cos(angle) + v[0] ** 2 * (1 - np.cos(angle)),
v[0] * v[1] * (1 - np.cos(angle)) - v[2] * np.sin(angle),
v[0] * v[2] * (1 - np.cos(angle)) + v[1] * np.sin(angle),
],
[
v[1] * v[0] * (1 - np.cos(angle)) + v[2] * np.sin(angle),
np.cos(angle) + v[1] ** 2 * (1 - np.cos(angle)),
v[1] * v[2] * (1 - np.cos(angle)) - v[0] * np.sin(angle),
],
[
v[2] * v[0] * (1 - np.cos(angle)) - v[1] * np.sin(angle),
v[2] * v[1] * (1 - np.cos(angle)) + v[0] * np.sin(angle),
np.cos(angle) + v[2] ** 2 * (1 - np.cos(angle)),
],
]
)
return (*np.dot(R, p),)
def rotate_mesh(
ref: int,
entities,
offset_entity,
offset_node,
offset_element,
ax=(1, 0, 0),
angle=180,
):
offset_entity = offset_entity * ref
offset_node = offset_node * ref
offset_element = offset_element * ref
m = {}
for e in entities:
bnd = gmsh.model.getBoundary([e])
nod = gmsh.model.mesh.getNodes(e[0], e[1])
ele = gmsh.model.mesh.getElements(e[0], e[1])
m[e] = (bnd, nod, ele)
for e in sorted(m):
gmsh.model.addDiscreteEntity(
e[0],
e[1] + offset_entity,
[(abs(b[1]) + offset_entity) * math.copysign(1, b[1]) for b in m[e][0]],
)
coord = []
for i in range(0, len(m[e][1][1]), 3):
x = m[e][1][1][i]
y = m[e][1][1][i + 1]
z = m[e][1][1][i + 2]
x, y, z = rotate3D((x, y, z), ax, angle)
coord.append(x)
coord.append(y)
coord.append(z)
gmsh.model.mesh.addNodes(
e[0], e[1] + offset_entity, m[e][1][0] + offset_node, coord
)
gmsh.model.mesh.addElements(
e[0],
e[1] + offset_entity,
m[e][2][0],
[t + offset_element for t in m[e][2][1]],
[n + offset_node for n in m[e][2][2]],
)
# ROTOR SETTINGS
N_BLADE = 3
GEO_FILE = "blade.geo"
# MESHING
gmsh.initialize()
gmsh.merge(GEO_FILE)
# get the Physical Groups before the circular pattern
physical_groups = gmsh.model.getPhysicalGroups()
physical_groups_names = [gmsh.model.getPhysicalName(*g) for g in physical_groups]
physical_groups_entities = [
gmsh.model.getEntitiesForPhysicalGroup(*g) for g in physical_groups
]
# perform circular pattern
entities = gmsh.model.getEntities()
offset_entity = len(entities)
offset_node = gmsh.model.mesh.getMaxNodeTag()
offset_element = gmsh.model.mesh.getMaxElementTag()
for i in range(1, N_BLADE):
ang = i * 360 / N_BLADE
rotate_mesh(i, entities, offset_entity, offset_node, offset_element, (1, 0, 0), ang)
# add Physical Groups to the new mesh
gmsh.model.remove_physical_groups(physical_groups)
for group in zip(physical_groups, physical_groups_names, physical_groups_entities):
dim = group[0][0]
tags = group[2]
name = group[1]
gmsh.model.add_physical_group(
dim,
tags.tolist()
+ [s + offset_entity * i for s in tags for i in range(1, N_BLADE)],
name=name,
)
gmsh.model.mesh.removeDuplicateElements()
gmsh.model.mesh.removeDuplicateNodes()
gmsh.model.mesh.reclassifyNodes()
gmsh.model.mesh.optimize()
gmsh.write("rotor.msh")
gmsh.write("rotor.stl")
gmsh.write("rotor.vtk")
gmsh.fltk.run()
gmsh.finalize()
```
If its useful for the project I don't have any problem to donate this example.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2728How to assign physical groups in imported mesh2024-01-03T08:15:22ZAdamya DhakerHow to assign physical groups in imported meshHello! I converted a .vtk file into a .msh file, and I want to assign physical groups (3 surfaces and 1 volume). But when I try to do that (for example press surface to create a surface group) I am unable to do so. Also I am able to visu...Hello! I converted a .vtk file into a .msh file, and I want to assign physical groups (3 surfaces and 1 volume). But when I try to do that (for example press surface to create a surface group) I am unable to do so. Also I am able to visualise only the mesh, not the geometry wireframe, am I doing something wrong? Or are there specific steps to deal with this? I have attached the converted file (.msh)
thank you in advance :[converted16_mesh.msh](/uploads/b509bc97fa12ab5411c3a978275bcc5b/converted16_mesh.msh)https://gitlab.onelab.info/gmsh/gmsh/-/issues/2727Problem Importing CGNS File (created by Ansys Mesher)2023-12-13T23:48:26ZSebastian BlauthProblem Importing CGNS File (created by Ansys Mesher)Hello,
I have a problem when importing a CGNS mesh file created with the Ansys Mesher. I have tagged / marked / named the various boundaries (inlet, outlet, wall1, wall2) and subdomains (volume1, volume2) in the mesher, and can see that...Hello,
I have a problem when importing a CGNS mesh file created with the Ansys Mesher. I have tagged / marked / named the various boundaries (inlet, outlet, wall1, wall2) and subdomains (volume1, volume2) in the mesher, and can see that these are present in the CGNS file. However, when I read the mesh with Gmsh (calling gmsh ansys_out.cgns) and inspect the mesh visibility, I can see the different boundaries as elementary entities (which is fine and works as expected), but only a single volume is created and I cannot find my subdomains represented in there.
In contrast, when I import this mesh, e.g., into Ansys Fluent, Fluent correctly recognizes the subdomains, indicating that they are indeed present in the CGNS file.
I have created a minimal working example, which I attach to this issue for you to reproduce the issue. I have tested this behavior with Gmsh 4.8.4 and 4.11.1.
[ansys_out.cgns](/uploads/23a4e283533f7b8adc098b922bbc4e04/ansys_out.cgns)
Thanks a lot for your time and help,
Sebastianhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2722free(): invalid pointer2024-02-05T15:51:18ZMartin Genetfree(): invalid pointerHello,
I am facing a weird issue: I have a small python library (https://gitlab.inria.fr/mgenet/dolfin_mech) that uses GMSH; I implemented continuous integration tests on our GitLab instance; problem is: on the (Ubuntu) images in which ...Hello,
I am facing a weird issue: I have a small python library (https://gitlab.inria.fr/mgenet/dolfin_mech) that uses GMSH; I implemented continuous integration tests on our GitLab instance; problem is: on the (Ubuntu) images in which the tests are run, if `gmsh` is imported after the rest of the library the code crashes at the `gmsh.initialize()` command; if `gmsh` is imported before it works fine. By the way, under MacOS or our cluster (Ubuntu images managed via OpenStack) this problem does not occur.
I tried to make a MWE to illustrate the issue: I made two examples scripts, one (`test_aa.py`) that imports `gmsh` first, one (`test_ab.py`) that imports `gmsh` last, cf. the associated commit: https://gitlab.inria.fr/mgenet/dolfin_mech/-/commit/01dbda70b75cb2a3bcfa9de493e935c8d551ce95. Now, when the tests are executed, the first scripts finishes fine, whereas the second script fails, cf. the traces: https://gitlab.inria.fr/mgenet/dolfin_mech/-/jobs/3650051#L7805 (Ubuntu 20.04 image) & https://gitlab.inria.fr/mgenet/dolfin_mech/-/jobs/3650052#L6203 (Ubuntu 22.04 image).
I have a workaround, but I thought this issue might be interesting to report. Thanks so much for all your work.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2717Testing the output of GMSH Python code2023-11-23T15:20:56ZMiguel Salazar de TroyaTesting the output of GMSH Python codeSay for instance, that I have this routine.
```
def generate_mesh(parameter):
# Lots of gmsh python API calls
# Generate the geo_unrolled and msh files.
```
Now I need to write a test for it. My goal is make sure I am generatin...Say for instance, that I have this routine.
```
def generate_mesh(parameter):
# Lots of gmsh python API calls
# Generate the geo_unrolled and msh files.
```
Now I need to write a test for it. My goal is make sure I am generating the same mesh even if I refactor the code within `generate_mesh`.
```
def test_generate_mesh():
# How to test that the output (geo_unrolled file) is reliable?
```
First, I tried to compare the output of the "geo_unrolled" files between the routine and a "ground-truth" file that I have saved in the repository's test directory. However, the "geo_unrolled" file becomes huge if we use splines with the OpenCASCADE kernel. This is not ideal because I have many "geo_unrolled" files and they would take a lot of space, making my repository huge in size. On the other hand, the "brep" files do not contain any information of the physical regions or the meshing options, so I can't test for that. What options do I have? Is there a light format that can save both the geometry, physical marking and meshing information in a lightweight manner?https://gitlab.onelab.info/gmsh/gmsh/-/issues/2713The plugin AnalyseMeshQuality does not compute the true validity of general p...2023-11-30T11:43:14ZAmaury JohnenThe plugin AnalyseMeshQuality does not compute the true validity of general plane surfacesCurrently, the validity of 2d planar elements that is computed by the plugin `AnalyseMeshQuality` is correct only in a specific case: if the geometric surface is a `GEntity::DiscreteSurface` in the xy-plane and oriented in +z direction.....Currently, the validity of 2d planar elements that is computed by the plugin `AnalyseMeshQuality` is correct only in a specific case: if the geometric surface is a `GEntity::DiscreteSurface` in the xy-plane and oriented in +z direction... (If the orientation is -z, the opposite of the validity is currently computed, see [ticket 736](gmsh/gmsh#736).)
To compute the true validity of an element, it must be planar and a normal should be given to define its correct orientation. If no normal is given, the element will always be considered as valid. Currently, the normal is not computed for general planar surfaces and incorrectly defined for the basic case given above.
Before, a normal was computed also for `GEntity::Plane` surfaces, but it was not working in general because I took an arbitrary parametric point that could not be inside the surface (see commit [f76c4936](f76c4936)).
Two questions :
1. Since we know at least one element of the surface (otherwise, there is no validity to compute), could I call 'GFace->normal(..)' on the parametric point taken from any existing node of the mesh?
2. What test ensures that the surface is a planar surface? Is it `if(geomType() == GEntity::Plane)`?Amaury JohnenAmaury Johnen