gmsh issueshttps://gitlab.onelab.info/gmsh/gmsh/-/issues2024-02-08T09:32:45Zhttps://gitlab.onelab.info/gmsh/gmsh/-/issues/2799can't using OCC in Gmsh2024-02-08T09:32:45ZWENBO ZHANGcan't using OCC in Gmshwhen i compile gmsh source with cmake, why there are no variable “OCC_INC”. there are any information about OCC module,
![屏幕截图_2024-02-07_115914](/uploads/82732948c758b7981b2cfa8649d8005d/屏幕截图_2024-02-07_115914.png)when i compile gmsh source with cmake, why there are no variable “OCC_INC”. there are any information about OCC module,
![屏幕截图_2024-02-07_115914](/uploads/82732948c758b7981b2cfa8649d8005d/屏幕截图_2024-02-07_115914.png)https://gitlab.onelab.info/gmsh/gmsh/-/issues/2798Peculiar behaviour when using HXT with 2 threads2024-02-08T18:40:01ZFadime BekmambetovaPeculiar behaviour when using HXT with 2 threadsWe have encountered a very strange issue that when we use HXT with 2 threads to generate a 3D mesh, the timing of subsequent 2D mesh generation is affected. We thought we should let you know in case this is a symptom of resources not bei...We have encountered a very strange issue that when we use HXT with 2 threads to generate a 3D mesh, the timing of subsequent 2D mesh generation is affected. We thought we should let you know in case this is a symptom of resources not being fully deallocated by the 3D mesh generation or some settings being modified. In our case, the issue appears with python 3.8.18 on Windows and seems to be dependent on the numpy library (e.g. it appears if numpy is not installed).
Please find attached the code that produces the peculiar result along with the .ps1 script that creates a clean environment in a way that causes the issue to appear.
[check_strange_behaviour_at_2_threads.py](/uploads/43401064b04ffca6bf0b3ec9e215ea92/check_strange_behaviour_at_2_threads.py)
[run_script.ps1](/uploads/82fc30e0df902936a7ab3b08158ff889/run_script.ps1)
The output we see is this:
```
2D mesh generation took 1.245 s
2D mesh generation took 5.981 s
2D mesh generation took 5.912 s
```
After the first 2D mesh generation there is a call to gmsh.model.mesh.generate(3), which seems to affect the behaviour of gmsh.model.mesh.generate(2) called afterwards.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2797Extracting 2D Mesh from 3D mesh diff format.2024-02-07T08:51:35ZAHMED OUHAMMOUExtracting 2D Mesh from 3D mesh diff format.Hi,
I've generated a 3D mesh of my geometry and saved it in .diff (3D) format. Now, I'm looking to extract the 2D mesh of the surfaces based on this diff(3D) mesh. Is it possible with Gmsh?
Thanks in advance.Hi,
I've generated a 3D mesh of my geometry and saved it in .diff (3D) format. Now, I'm looking to extract the 2D mesh of the surfaces based on this diff(3D) mesh. Is it possible with Gmsh?
Thanks in advance.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2796Periodic curves and translation/rotation2024-02-06T14:48:01ZJared FrazierPeriodic curves and translation/rotationI am trying to create a puzzle-piece like mesh for which the right curves are periodic copies of the left curves, and the top curves are periodic copies of the bottom curves. Getting the line-curves to be periodic is a straightforward ca...I am trying to create a puzzle-piece like mesh for which the right curves are periodic copies of the left curves, and the top curves are periodic copies of the bottom curves. Getting the line-curves to be periodic is a straightforward call to `Translate`; however, I am having difficulty with the ellipses curves resulting from the boolean difference of the rectangle and disk planes. In my attempt, I have tried getting the top ellipse to be a periodic copy of the bottom ellipse by doing an affine transformation that translates the ellipse 1 unit in the y-direction and rotates it 180 degrees, but I get this error: `Info: Error in transformation from curve 1 (1-2) to 8 (8-9) (minimal transformed node distances 0.5 1.5, tolerance 1.41421e-08)`. And I also don't know how to get the desired periodicity for the left and right ellipses curves since the left side is made up of two ellipses but the right is only a single ellipse.
```geo
//+
SetFactory("OpenCASCADE");
Rectangle(1) = {0, 0, 0, 1, 1, 0};
//+
Disk(2) = {1, 0.5, 0, 0.25, 0.25};
//+
Disk(3) = {-0, 0.5, 0, 0.25, 0.25};
//+
Disk(4) = {0.5, 1, 0, 0.25, 0.25};
//+
Disk(5) = {0.5, -0, 0, 0.25, 0.25};
//+
BooleanDifference{ Surface{1}; Delete; }{ Surface{3}; Surface{4}; Surface{2}; Surface{5}; Delete; }
// Right-side lines are periodic copy of left-side lines
Periodic Curve {10} = {6} Translate {1, 0, 0};
Periodic Curve {12} = {3} Translate {1, 0, 0};
// ----------------------------------------------------
// NEED HELP IN THE SECTIONS FOLLOWING THIS COMMENT!!!!!
// -----------------------------------------------------
// Top-ellipse is periodic copy of bottom-ellipse
// Affine transformation is translate 1 unit in y dir and rotate 180 deg
Periodic Curve {8} = {1} Affine { -1, 0, 0, 0,
0, 1, 0, 1,
0, 0, -1, 0,
0, 0, 0, 1};
// The left ellipse is made up of two different curves but the right
// ellipse is made up of only curve... how to impose periodicity??
// TODO
```
Visually, here is what I am having trouble with:
![image](/uploads/fb0a36ac60f3f55b24b00218717b7c63/image.png)https://gitlab.onelab.info/gmsh/gmsh/-/issues/2795Rotatable labels feature could be considered2024-02-07T12:08:21ZResat SABIQRotatable labels feature could be consideredPlease tell me if i'm wrong, but i've concluded that it's impossible to rotate labels even if they contain some 3D characteristics (like
`{0.5, 1.5, -0.5}`
in x3 tutorial).
This could be considered for an enhancement (also).Please tell me if i'm wrong, but i've concluded that it's impossible to rotate labels even if they contain some 3D characteristics (like
`{0.5, 1.5, -0.5}`
in x3 tutorial).
This could be considered for an enhancement (also).https://gitlab.onelab.info/gmsh/gmsh/-/issues/2794Support for rotating images (currently addable via gmsh::view::addListDataStr...2024-02-07T12:09:44ZResat SABIQSupport for rotating images (currently addable via gmsh::view::addListDataString(...)) could (or should) be enhancedPlease tell me if i'm wrong, but i've concluded the following:
1) it's almost impossible to rotate an image (currently addable via gmsh::view::addListDataString(...)) to match a plane resulting from a rotation;
2) when the rotation (e.g....Please tell me if i'm wrong, but i've concluded the following:
1) it's almost impossible to rotate an image (currently addable via gmsh::view::addListDataString(...)) to match a plane resulting from a rotation;
2) when the rotation (e.g. of everything) is done programmatically, the images are not rotated even if they contain some 3D characteristics; e.g.:
`file://../share/doc/gmsh/tutorials/t4_image.png@0.01x0,0,0,1,0,1,0`
This could be considered for an enhancement.https://gitlab.onelab.info/gmsh/gmsh/-/issues/2791t4.cpp radius != R1 used in tangent (angle) calculations: addition of calcula...2024-02-01T18:34:59ZResat SABIQt4.cpp radius != R1 used in tangent (angle) calculations: addition of calculation comments likely to be usefulHi,
The radius suggested by the code is as follows[1]:
`R1=0.01`
The radius observed on the UI is different (as follows): 0.0117076
It gets slightly better if +-`R1 * ssin` is used for x coordinates for points 14 & 16: 0.0116577
But it...Hi,
The radius suggested by the code is as follows[1]:
`R1=0.01`
The radius observed on the UI is different (as follows): 0.0117076
It gets slightly better if +-`R1 * ssin` is used for x coordinates for points 14 & 16: 0.0116577
But it's still `!= R1`.
Especially for those who try to follow the calucations, addition of calculation comments is likely to be useful.[2]
P.S.
[1] https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/tutorials/c++/t4.cpp?ref_type=heads
[2] At present, on might try to verify the calculations (given that this seems not to be overly complicated at first glance) & not understand them, or conclude that they are approximative, etc.
[3] In the worst case, something like the following would already be clearer:
`double R1 = 1 * cm /* approximate radius */ // ...`https://gitlab.onelab.info/gmsh/gmsh/-/issues/2790Combining twisting and boolean operators2024-01-31T10:37:31ZSantiago GomezCombining twisting and boolean operatorsHi! I am interested in creating a geometry which combines boolean operations with twisting. Specifically, I want to create a geometry with a "twisted hole", which I would do by taking a boolean difference. However, I noticed that the twi...Hi! I am interested in creating a geometry which combines boolean operations with twisting. Specifically, I want to create a geometry with a "twisted hole", which I would do by taking a boolean difference. However, I noticed that the twist is only possible with the built in kernel, whereas the boolean operators are only available with occ. Is there anyway to combine these two kernels, or get one of the functions running with the other kernel?
Thanks in advance!https://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/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!