gmsh issueshttps://gitlab.onelab.info/gmsh/gmsh/-/issues2024-01-11T09:37:04Zhttps://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/2633GMSH 3D hibrid mesh: ill elements, negative volumes and incorrectly oriented ...2024-01-07T15:41:34ZSergi GiménezGMSH 3D hibrid mesh: ill elements, negative volumes and incorrectly oriented facesHowdy y'all,
This is my first post, so I hope I am doing everithing right.
I'm designing a 3D mesh of a wing using gmsh in order to run it on Openfoam. I made a hibrid mesh, so the elements around the wing are hexahedra and the elemen...Howdy y'all,
This is my first post, so I hope I am doing everithing right.
I'm designing a 3D mesh of a wing using gmsh in order to run it on Openfoam. I made a hibrid mesh, so the elements around the wing are hexahedra and the elements far from it are tetrahedra; between those hexahedra and tetrahedra there is a layer of pyramids in order to combine the quadrangle faces of the structured mesh with the tetrahedra nodes (It's done by default with the Delaunay algo). When running the algorithm I have problems, I have two error messages which are the following: "Warning : Strange edge cavity (tet is deleted)" and "Warning : 12 ill-shaped tets are still in the mesh". I managed to reduce the number of ill-shapped tets from 2000 to 12 by reducing the aspect ratio of the quadrangles in contact with the un-structured volumes (this way the pyramids and the tetrahedra sorrounding it seem to be simpler and the algorithm seems to work better), but there are still cells that have 0 or negative volume according to OpenFOAM.
On the other hand, when runing the checkMesh code on openFoam i have several errors : " \*\*\*Zero or negative cell volume detected. Minimum negative volume: -0.00053318274, Number of negative volume cells: 83 ", "\*\*\*Open cells found, max cell openness: 1, number of open cells 432", " \*\*\*Number of non-orthogonality errors: 373." , " \*\*\*Error in face pyramids: 660 faces are incorrectly oriented." and "\*\*\*Max skewness = 45.903898, 27 highly skew faces detected which may impair the quality of the results".
I have been working on this for several days but now I'm at a point that I don't know how to advance further. Here is the .geo file:
[Cwing_hibridMesh_3_FineMeshCDependant_WingtipMesh.geo](/uploads/fa0fc67eb4b5630db5c41e6d1e326746/Cwing_hibridMesh_3_FineMeshCDependant_WingtipMesh.geo)
I have attached several images. On the last one can be seen the tetrahedra with a low gamma value, note how the nodes are almost on the same plane creating elements with very low volumes. Also, are images of only the pyramids and only the hexahedra (which are around the wing forming a local structured mesh). I have also attached images of the 2D mesh of the wing and the computational domain, so it is easier to understand the definition of the mesh.
Any help regarding these issues would be very appreciated, Kind regards,
Sergi Giménez Herrero
![Ill elements.PNG](/uploads/28e8606bb4171f4454cbda7891e059bb/Ill_elements.PNG)![2D computational domain.PNG](/uploads/75dc30dd9e16868c38c051ce6701da27/2D_computational_domain.PNG)![pyramids.PNG](/uploads/1a0bd9cbc00282fce7d2c09d920ada7b/pyramids.PNG)
![Hexahedra.PNG](/uploads/08896b5d8f0741857e963da7f226d011/Hexahedra.PNG)
![2D wing.PNG](/uploads/d45e70385a726ea3f30d24bb83712cb8/2D_wing.PNG)https://gitlab.onelab.info/gmsh/gmsh/-/issues/1928the 3d grid can be generatd by gmsh in linux but not in macos2024-01-03T10:57:05Zhui liuthe 3d grid can be generatd by gmsh in linux but not in macosHello developers,
I meet two strange problems on macos. I've tried a lot of things, and now I want to summarize the following two questions:
(1) This script can only be compiled by gmsh 4.9.5. The gmsh 4.10.1 will report an error that ...Hello developers,
I meet two strange problems on macos. I've tried a lot of things, and now I want to summarize the following two questions:
(1) This script can only be compiled by gmsh 4.9.5. The gmsh 4.10.1 will report an error that it cannot find the tag of an entity generated by a boolean operation. Are tag values of entities generated differently for different gmsh versions?
(2) This 3D grid can not be generated by gmsh on macOS (including python API on macOS), but the 3d grid can generated without any errors in gmsh on linux (including python API on Linux).
Note: The script was a bit cumbersome, and I tried to simplify it, but I was worried that it might not reproduce the problem. This geometry is not very complex.
Ps: Line 351 -- Line 355 in this geo file are important, I think the numbers of **Transfinite Curve** are the main reason of the second problem, and I don't understand why I can't arbitrarily set the different number for the value of **Transfinite Curve**?
Best regards,
[practice.geo](/uploads/b552c58e039f1eef0d2b3b1360b12eed/practice.geo)Hui.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2571Impossible to mesh periodic surface - OCCTargetUnit2024-01-03T09:38:19ZMerve AsilerImpossible to mesh periodic surface - OCCTargetUnitHi, I am generating 2D surface meshes for some 3D geometries. I was taking "Impossible to mesh periodic surface" error for some of the geometries. After I used different OCCTargetUnit, I noticed that gmsh could actually generate meshes w...Hi, I am generating 2D surface meshes for some 3D geometries. I was taking "Impossible to mesh periodic surface" error for some of the geometries. After I used different OCCTargetUnit, I noticed that gmsh could actually generate meshes when suitable OCCTargetUnit is used. For some geometries I get successful results with OCCTargetInit=MM, for some with OCCTargetInit=M and for some with OCCTargetInit=KM. My geometries are in a .step file. When I check step files, all geometries include the following lines:
LENGTH_UNIT()
NAMED_UNIT(*)
SI_UNIT(.MILLI.,.METRE.)
As far as I understand, all of them has the unit MM, but for mesh generation operation they need different OCCtargetUnits. How can I understand which OCCTargetUnit is the suitable for that geometry?
Tahnks.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2639How to specify the normal of the surface in gmsh/model/occ/addSurfaceFilling2024-01-03T08:41:31Zvincent skywalkerHow to specify the normal of the surface in gmsh/model/occ/addSurfaceFillingI see there is a `tolAng` argument passed in to `gmsh/model/occ/addSurfaceFilling`. And that means the maximum angle allowed between the normal of the surface and the constraints.
Is there a way to specify constraints of the normal of t...I see there is a `tolAng` argument passed in to `gmsh/model/occ/addSurfaceFilling`. And that means the maximum angle allowed between the normal of the surface and the constraints.
Is there a way to specify constraints of the normal of the surface?
Thank you very much!https://gitlab.onelab.info/gmsh/gmsh/-/issues/2689Correct way to mesh OCC cylinder2024-01-03T08:23:43ZJohn BELLCorrect way to mesh OCC cylinderHi,
Apologies if this is a trivial question, but what is the correct way to mesh a cylinder constructed using OCC when using `Algorithm = 8` (structured)?
Using `setSize` seems to generate very thin vertical elements and `MeshSizeFromC...Hi,
Apologies if this is a trivial question, but what is the correct way to mesh a cylinder constructed using OCC when using `Algorithm = 8` (structured)?
Using `setSize` seems to generate very thin vertical elements and `MeshSizeFromCurvature` only helps when using large values (e.g. 50). I have also tried the method (`getBoundary`) from t16.py.
Thanks, John
```plaintext
import gmsh
import sys
gmsh.initialize()
model = gmsh.model
occ = model.occ
radius = 0.2
occ.addCylinder(0,0,0, 0, 1, 0, radius)
vols = occ.getEntities(3)
cylinder = model.addPhysicalGroup(3, [vols[0][1]], tag = 1)
gmsh.model.occ.synchronize()
lc = 5e-03
# Taken from t16.py
model.mesh.setSize(gmsh.model.getBoundary(vols, False, False, True),lc)
# Gives same result
# model.mesh.setSize(occ.getEntities(0), lc)
gmsh.option.setNumber("Mesh.MshFileVersion", 2)
gmsh.option.setNumber("Mesh.Algorithm", 8)
# Set curvature only seems to help with using a large value
# gmsh.option.setNumber("Mesh.MeshSizeFromCurvature", 50)
gmsh.model.mesh.generate(3)
```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/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/2560PLC Error: A segment and a facet intersect at a point with OpenCascade - what...2024-01-02T21:16:40ZBrianPLC Error: A segment and a facet intersect at a point with OpenCascade - what is wrong with my volume assembly?Hello, I have a CAD file of a propeller that I'm trying to build a volume mesh for. I'm using a similar process as to what I've used with the Built-In kernel, but it does not appear to be working correctly so I think there's something si...Hello, I have a CAD file of a propeller that I'm trying to build a volume mesh for. I'm using a similar process as to what I've used with the Built-In kernel, but it does not appear to be working correctly so I think there's something simple I'm overlooking.
I have two groups of surfaces in the mesh: the propeller ("prop_surfs\[\]") and the farfield ("farfield_surfs\[\]"). I try to create a Physical Volume with the following code:
`prop_sl = newsl;`
`Surface Loop(prop_sl) = {prop_surfs[]};`
`farfield_sl = newsl;`
`Surface Loop(farfield_sl) = {farfield_surfs[]};`
`vol = newv;`
`Volume (vol) = {prop_sl, farfield_sl};`
I'm able to mesh this in 2D with no issues. The mesh looks good and I see no overlapping elements. However, when I try to mesh 3D, I get the error "PLC Error: A segment and a facet intersect at a point" and a boundary mesh issue is shown somewhere randomly along either the farfield cylinder or the propeller mesh.
If the boundary mesh issue were only seen along the propeller, I would expect a problem with the underlying CAD - but the cylinder is a very simple geometry created within Gmsh. Is there something I'm missing about working with OpenCascade?https://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/2709aneurysm.py double free or corruption2024-01-02T09:44:22Zedgar noneaneurysm.py double free or corruptionI tried `python aneurysm.py` (from the examples/api path), and I got this:
<pre>
Warning: could not find Gmsh shared library libgmsh.so.4.11
Info : Reading 'aneurysm_data.stl'
Info : 20294 facets in solid 0 Created by Gmsh
Info ...I tried `python aneurysm.py` (from the examples/api path), and I got this:
<pre>
Warning: could not find Gmsh shared library libgmsh.so.4.11
Info : Reading 'aneurysm_data.stl'
Info : 20294 facets in solid 0 Created by Gmsh
Info : Done reading 'aneurysm_data.stl'
Info : Classifying surfaces (angle: 180)...
Info : Splitting triangulations to make them parametrizable:
double free or corruption (out)
</pre>
Gmsh 4.11.1
Python 3.11.5
Arch Linux
Let me know if more info is needed.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/2192HXT Meshing stops with error 11 (Segmentation failed) (try 2)2023-12-31T14:43:09ZArtem KhoroshevHXT Meshing stops with error 11 (Segmentation failed) (try 2)I have simple, but massive geometrical model: big box (fragmented into 8 equal parts) with inserted thousands of randomly placed small boxes (then BooleanFragments performed). If the number of small boxes is more than some value (5k-20k ...I have simple, but massive geometrical model: big box (fragmented into 8 equal parts) with inserted thousands of randomly placed small boxes (then BooleanFragments performed). If the number of small boxes is more than some value (5k-20k or more) then the meshing usually stops with "Signal: Segmentation fault (11)".
This issue is reproduceable only in multithreaded mode (-nt > 1). Single thread HXT stopped normally. If "Mesh.MeshSizeMax" is very small (about 0.25...0.5 of small box edge size), then multithread meshing usually stops normally (~8 of 10 times, related onto random factor of small boxes placing; but number of tetrahedra is crazy).
```
Info : Final tet. mesh contains 3147497 tetrahedra
Info : Final tet. mesh contains 510508 vertices
Info : tEmptyMesh = 52.300
Info : tVerifyBnd = 8.801
Info : tBndRecovery = 21.359
Info : tConvertMesh = 27.710
Info : tRefine = 204.129
Info : tOptimize = 2145.993
Info : Mesh generated
Debug : Start Hxt2Gmsh
*** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Address not mapped (1)
Failing at address: 0x45f8a378c
[ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x87d1520]
[ 1] gmsh(+0x9342bb)[0xa3c2bb]
[ 2] /lib/x86_64-linux-gnu/libgomp.so.1(+0x1db9e)[0x8742b9e]
[ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x94b43)[0x8823b43]
[ 4] /lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x88b4bb4]
*** End of error message ***
```
Issue reproduced with prebuild Gmsh and with manually built Gmsh onto various hardware (FX-6300 + 32GiB RAM, Ryzen 3600 + 64 GiB, i7-870 + 12 GiB; all machines with Ubuntu 22.04).
Here unrolled geometry to reproduce (big box with 10k small boxes; 10k - before fragmentation): [t16v10_debug.geo_unrolled](/uploads/fade851ba483a2ad37e86696f0913f5d/t16v10_debug.geo_unrolled)
And here Valgrind log ( `valgrind --verbose --log-file=valgrind2.txt gmsh t16v10_debug.geo_unrolled -3 -algo hxt -nt 6 -v 99
`): [valgrind2.txt](/uploads/51ef376df21df09e67b4da9ce9da5ab2/valgrind2.txt)
I hope this information will be useful.Célestin Marotmarotcelestin@gmail.comCélestin Marotmarotcelestin@gmail.comhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2682HXT 3D Mesh Fail2023-12-31T14:43:06ZCUAeroHXT 3D Mesh FailHello! I have built a semi-automatic method for meshing some in-house geometries to obtain a 3D volume mesh. I first construct the 2D mesh in a .geo script and then pass it onto the volume mesh script in which we use HXT.
I have observe...Hello! I have built a semi-automatic method for meshing some in-house geometries to obtain a 3D volume mesh. I first construct the 2D mesh in a .geo script and then pass it onto the volume mesh script in which we use HXT.
I have observed that HXT is very sensititve to far-field dimensions and model geometry fidelity. In this case the "no elements in volume 6" error and "No closed volume" are not helpful since there is no visual que on exactly where the volume was found to be open. I have checked our 2D meshed gometry in external software and appear to be manifold, watertight with no duplicate nodes or facets.
Is it a bug or am I missing something?
Please find attached an example geometry 2D-meshed geometry from which I am trying to generate the 3D mesh. I am also attaching the 3D mesh script.
In other cases I have reduced the density of points on the model surface a well as increased the far-field dimensions which appears to solve the problem. I would greatly appreciate any explanation for this if known.
I appreciate every help I can get!
Best Regards
[2DMesh.stl](blob:https://gitlab.onelab.info/8429ce86-1b46-4ff7-9562-ec70deaacbb7)
[3DMeshScript.geo](/uploads/4c26fa62b3a16b51f030a4773571a98c/3DMeshScript.geo)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/2660Export periodic boundaries in CGNS2023-12-14T00:18:48ZClément BenazetExport periodic boundaries in CGNSHi, I am using your software through the python API to generate CGNS periodic meshes. The CGNS file generated has periodic nodes for points lines and surfaces, but the location of lines and surfaces is Vertex. CGNS norm allows to define ...Hi, I am using your software through the python API to generate CGNS periodic meshes. The CGNS file generated has periodic nodes for points lines and surfaces, but the location of lines and surfaces is Vertex. CGNS norm allows to define periodic conditions as well on surfacic elements (https://cgns.github.io/CGNS_docs_current/sids/cnct.html, §8.4, Note 4).
Here an exemple : [periodic_cube_raw.cgns](/uploads/ff84e56587b8839f99861d96e518ded3/periodic_cube_raw.cgns)
In this file, I think that `Per_0-S*` nodes could have a GridLocation node set to `FaceCenter` to tag through `PointList` and `PointListDonor` which faces are connected by the periodic condition (instead of Vertex now).
Do you think that is it possible to manage this case ?
I think that both informations (Vertex of FaceCenter) are interesting depending on application.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2036CGNS I/O and Tecplot2023-12-13T23:48:29ZMichael Ermakovermakov@ipmnet.ruCGNS I/O and Tecplot1. Gmsh does not read tut21.cgns (ADF) from benchmarks/cgns, reporting
![cgns_tut21](/uploads/a247724f2bc6d6b746b8ebef7c1281db/cgns_tut21.png)
2. Tecplot 360 reads and visualizes tut21.cgns correctly, however it does not read Gmsh mes...1. Gmsh does not read tut21.cgns (ADF) from benchmarks/cgns, reporting
![cgns_tut21](/uploads/a247724f2bc6d6b746b8ebef7c1281db/cgns_tut21.png)
2. Tecplot 360 reads and visualizes tut21.cgns correctly, however it does not read Gmsh mesh-export to cgns format (HDF), reporting
![cgns](/uploads/ff52a855d50c31b62e9f2e316f28a008/cgns.png).
Thank you in advance.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/2545Problems with CGNS2023-12-13T23:25:32ZMichael HeiderProblems with CGNSI have created in python a structured mesh which works but is not exporting to cgns
right now the only thing in my code is
> write(... .cgns)
which could export the file, but the output file is not readable by cgnscheck or Pyhyp.
Poin...I have created in python a structured mesh which works but is not exporting to cgns
right now the only thing in my code is
> write(... .cgns)
which could export the file, but the output file is not readable by cgnscheck or Pyhyp.
Pointwise, however, can work with it. So my guess is that the code is actually in .msh and it has just changed the name.
then I changed in the
> gmsh-options
file,
> Mesh.Format = 32
> Mesh.CgnsExportStructured = 1
and I get the same error when I try to open the file with Pyhyp, which is:
> cgio_open_file:invalid file type
Sadly I couldn´t find a better way to reach the mesh-options in python then the mentioned above.
Am I missing the obvious workflow or is my code screwed?
if it helps, I can send it aswell, but right now the only lines regarding CGNS are the mentioned above.
thank you very much in advance