Re: [Gmsh] how do we do to export a mesh in med 3.3 from Gmsh 4.2.3
> So it seems like you cannot create a MED3 file when using the MED4 library. > > Maybe you could escalade this to the MED developers? There was some discussion of this over at https://github.com/nschloe/meshio/issues/347#issuecomment-474367765 and it had been raised before that at https://www.salome-platform.org/forum/forum_10/835834708 The makeshift proposed in the meshio thread was: …MED file, where the version is changed from 4.0.0 to 3.0.0, by modifying manually INFOS_GENERALES. …This file can be loaded by gmsh ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge
> On 11 Apr 2019, at 18:22, Nathan RICKS wrote: > > Sorry for the repeated messages, just trying to sort out the issue and coming > across new things/information that might help resolve the issue. In the .geo > file attached, it demonstrates what "I think" is the cause of my errors - if > you generate the 2D mesh and look at the trailing edge, there are cells/nodes > crossing over the lines/edges where they obviously shouldn't be. This occurs > on both Mac and Linux for me at least. Have you seen this issue before by any > chance? > It seems that you ran into a case where the small random perturbation we use in our 2D initial triangulation is too large. A new version of the algorithm without any such perturbation will be available in a future release; but in the meantime you can set e.g. "gmsh -rand 1e-12" (or set Mesh.RandomFactor = 1e-12 in your script), which seems to solve the issue. Christophe > Thanks again, > > Nathan Ricks > VUB > > > > > > From: Nathan RICKS > Sent: Thursday, 11 April 2019 11:41 AM > To: Christophe Geuzaine > Cc: gmsh@onelab.info > Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > > I'm not sure if this helps determine the issue, but it seems if I generate > the mesh using the Delaunay algorithm, there are cells that break through > boundaries of the surfaces, and if I use Frontal-Delaunay (which I was) these > correspond to the broken cells shown in the first screenshots. I've attached > two screenshots showing this, if you compare between the two you can see > "correspondence of errors". > > From: Nathan RICKS > Sent: Thursday, 11 April 2019 9:00 AM > To: Christophe Geuzaine > Cc: gmsh@onelab.info > Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > > Dear Prof. Geuzaine, > > Thanks for the response. Indeed, I just tested this using Gmsh on my Mac, and > the resultant mesh runs fine. > > So it seems the problem is restricted to the workstation, which is running > Linux 64-bit (red hat). I just tried instead compiling from the source code > and the error persists there also unfortunately. Are you aware of anything > that may cause this? It's for an optimisation routine, so thousands of meshes > are generated, so using my Mac isn't feasible unfortunately. > > In regards to the boundary layer, I was originally using the BL field > directly, however ran into issues as I couldn't have a growth rate "around" > the airfoil spline (to have narrower cells at leading and trailing edges), as > well as perpendicular to the airfoil. Also, at the trailing edge using the > fan node resulted in too small cells causing numerical errors, and without it > the cells were too bad quality, also causing errors. Using the transfinite > surfaces gave me flexibility in the boundary layers, allowing two different > growth rates perpendicular to the surface. With that it was running very > well, until now on trying to include the blunt TE. > > Thank you again, > Kind Regards, > > Nathan Ricks. > > > > > From: Christophe Geuzaine > Sent: Thursday, 11 April 2019 12:09 AM > To: Nathan RICKS > Cc: gmsh@onelab.info > Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > > > > > On 10 Apr 2019, at 21:57, Nathan RICKS wrote: > > > > Hi all, > > > > I have quite a particular problem, but I'm hoping someone can help. I'm > > meshing an airfoil using transfinite surfaces in the boundary layer. > > > > I've just had to add a blunt trailing edge (mesh was working well with > > sharp trailing edge) to the airfoil, and now I have this one error stopping > > me, and I just can't figure it out... > > > > When I increase the NNodesByEdge on Field[11] from 6 to 15, the mesh ends > > up bad quality, with cell corners not matching other cells at the boundary > > of surfaces, and it causes SU2 to diverge instantly. It runs fine with 6, > > but crashes at 15. I've attached two images showing that it is a mesh issue > > causing this (nothing else is being changed in the setup). > > > > I cannot seem to reproduce the issue on my Mac. Attached is the mesh > generated on your .geo file: > > > > Other things such as reducing lcMin on Field[12] can also make it crash for > > example, however the above has visible errors in the mesh. > > > > Idem... What OS are you running on? > > PS: instead of generating the BL by hand, why not using the boundary layer > field directly? Cf. e.g. > > https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12BL.geo > https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12_2d_trailing.geo > > > Does anyone have an idea on why I can't use the Distance/Threshold field as > > normal on this edge? > > > > If you can provide any guidance that would be greatly appreciated, it's so > > close...! I've already tested with the latest release with the same results. > > > > Thanks a lot, > > Kind Regards, > > > > Nathan Ricks > > >
Re: [Gmsh] how do we do to export a mesh in med 3.3 from Gmsh 4.2.3
> On 11 Apr 2019, at 11:20, jean pierre aubry > wrote: > > hello > > how do we do to export a mesh in med 3.3 from Gmsh 4.2.3 Unfortunately I think it's impossible. Gmsh is now linked with MED4, and uses "MEDfileVersionOpen" to create MED files. From the MED documentation (see the first "remarque"): ``` med_idt MEDfileVersionOpen (const char *const filename, const med_access_mode accessmode, const med_int major, const med_int minor, const med_int release ) Ouverture d'un fichier MED en indiquant la version du modèle à utiliser en cas de création d'un nouveau fichier. Paramètres filenameNom du fichier. accessmode Mode d'acces au fichier. major Numéro de version majeur. minor Numéro de version mineur. release Numéro de release. Valeurs retournées med_idt résultat i.e. l'identificateur entier (ID) retourné sera utilisé par les routines de l'API pour accéder au contenu du fichier. Ouverture d'un fichier MED. Remarques • Le numéro major ne peut être que le numéro majeur utilisé par la bibliothèque. • Le numéro minor ne peut être que dans la plage des versions mineurs des bibliothèques distribuées avec le numéro majeur égal à celui de la bibliothèque utilisé. • Le numéro release n'est pas pris en compte. Le numéro release utilisé sera le numéro le plus élévé associé à la version mineure demandée. • Si aucun fichier de nom filename n'existe, il est crée dans les modes MED_ACC_RDWR et MED_ACC_RDEXT. • En mode MED_ACC_CREAT un nouveau fichier filename est crée qu'il en existe déjà un ou non. Définition à la ligne 44 du fichier MEDfileVersionOpen.c. ``` So it seems like you cannot create a MED3 file when using the MED4 library. Maybe you could escalade this to the MED developers? Christophe > > thanks > > jean pierre aubry > > -- > jean pierre aubry > jeanpierreaubry[at]ouvaton.org > 33 688 670 795 > > > > ___ > gmsh mailing list > gmsh@onelab.info > http://onelab.info/mailman/listinfo/gmsh — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge
Sorry for the repeated messages, just trying to sort out the issue and coming across new things/information that might help resolve the issue. In the .geo file attached, it demonstrates what "I think" is the cause of my errors - if you generate the 2D mesh and look at the trailing edge, there are cells/nodes crossing over the lines/edges where they obviously shouldn't be. This occurs on both Mac and Linux for me at least. Have you seen this issue before by any chance? Thanks again, Nathan Ricks VUB From: Nathan RICKS Sent: Thursday, 11 April 2019 11:41 AM To: Christophe Geuzaine Cc: gmsh@onelab.info Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge I'm not sure if this helps determine the issue, but it seems if I generate the mesh using the Delaunay algorithm, there are cells that break through boundaries of the surfaces, and if I use Frontal-Delaunay (which I was) these correspond to the broken cells shown in the first screenshots. I've attached two screenshots showing this, if you compare between the two you can see "correspondence of errors". From: Nathan RICKS Sent: Thursday, 11 April 2019 9:00 AM To: Christophe Geuzaine Cc: gmsh@onelab.info Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge Dear Prof. Geuzaine, Thanks for the response. Indeed, I just tested this using Gmsh on my Mac, and the resultant mesh runs fine. So it seems the problem is restricted to the workstation, which is running Linux 64-bit (red hat). I just tried instead compiling from the source code and the error persists there also unfortunately. Are you aware of anything that may cause this? It's for an optimisation routine, so thousands of meshes are generated, so using my Mac isn't feasible unfortunately. In regards to the boundary layer, I was originally using the BL field directly, however ran into issues as I couldn't have a growth rate "around" the airfoil spline (to have narrower cells at leading and trailing edges), as well as perpendicular to the airfoil. Also, at the trailing edge using the fan node resulted in too small cells causing numerical errors, and without it the cells were too bad quality, also causing errors. Using the transfinite surfaces gave me flexibility in the boundary layers, allowing two different growth rates perpendicular to the surface. With that it was running very well, until now on trying to include the blunt TE. Thank you again, Kind Regards, Nathan Ricks. From: Christophe Geuzaine Sent: Thursday, 11 April 2019 12:09 AM To: Nathan RICKS Cc: gmsh@onelab.info Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > On 10 Apr 2019, at 21:57, Nathan RICKS wrote: > > Hi all, > > I have quite a particular problem, but I'm hoping someone can help. I'm > meshing an airfoil using transfinite surfaces in the boundary layer. > > I've just had to add a blunt trailing edge (mesh was working well with sharp > trailing edge) to the airfoil, and now I have this one error stopping me, and > I just can't figure it out... > > When I increase the NNodesByEdge on Field[11] from 6 to 15, the mesh ends up > bad quality, with cell corners not matching other cells at the boundary of > surfaces, and it causes SU2 to diverge instantly. It runs fine with 6, but > crashes at 15. I've attached two images showing that it is a mesh issue > causing this (nothing else is being changed in the setup). > I cannot seem to reproduce the issue on my Mac. Attached is the mesh generated on your .geo file: > Other things such as reducing lcMin on Field[12] can also make it crash for > example, however the above has visible errors in the mesh. > Idem... What OS are you running on? PS: instead of generating the BL by hand, why not using the boundary layer field directly? Cf. e.g. https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12BL.geo https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12_2d_trailing.geo > Does anyone have an idea on why I can't use the Distance/Threshold field as > normal on this edge? > > If you can provide any guidance that would be greatly appreciated, it's so > close...! I've already tested with the latest release with the same results. > > Thanks a lot, > Kind Regards, > > Nathan Ricks > > > > > > ___ > gmsh mailing list > gmsh@onelab.info > http://onelab.info/mailman/listinfo/gmsh — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine airfoil_level1_edit.geo Description: airfoil_level1_edit.geo ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge
Dear Prof. Geuzaine, Thanks for the response. Indeed, I just tested this using Gmsh on my Mac, and the resultant mesh runs fine. So it seems the problem is restricted to the workstation, which is running Linux 64-bit (red hat). I just tried instead compiling from the source code and the error persists there also unfortunately. Are you aware of anything that may cause this? It's for an optimisation routine, so thousands of meshes are generated, so using my Mac isn't feasible unfortunately. In regards to the boundary layer, I was originally using the BL field directly, however ran into issues as I couldn't have a growth rate "around" the airfoil spline (to have narrower cells at leading and trailing edges), as well as perpendicular to the airfoil. Also, at the trailing edge using the fan node resulted in too small cells causing numerical errors, and without it the cells were too bad quality, also causing errors. Using the transfinite surfaces gave me flexibility in the boundary layers, allowing two different growth rates perpendicular to the surface. With that it was running very well, until now on trying to include the blunt TE. Thank you again, Kind Regards, Nathan Ricks. From: Christophe Geuzaine Sent: Thursday, 11 April 2019 12:09 AM To: Nathan RICKS Cc: gmsh@onelab.info Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > On 10 Apr 2019, at 21:57, Nathan RICKS wrote: > > Hi all, > > I have quite a particular problem, but I'm hoping someone can help. I'm > meshing an airfoil using transfinite surfaces in the boundary layer. > > I've just had to add a blunt trailing edge (mesh was working well with sharp > trailing edge) to the airfoil, and now I have this one error stopping me, and > I just can't figure it out... > > When I increase the NNodesByEdge on Field[11] from 6 to 15, the mesh ends up > bad quality, with cell corners not matching other cells at the boundary of > surfaces, and it causes SU2 to diverge instantly. It runs fine with 6, but > crashes at 15. I've attached two images showing that it is a mesh issue > causing this (nothing else is being changed in the setup). > I cannot seem to reproduce the issue on my Mac. Attached is the mesh generated on your .geo file: > Other things such as reducing lcMin on Field[12] can also make it crash for > example, however the above has visible errors in the mesh. > Idem... What OS are you running on? PS: instead of generating the BL by hand, why not using the boundary layer field directly? Cf. e.g. https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12BL.geo https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12_2d_trailing.geo > Does anyone have an idea on why I can't use the Distance/Threshold field as > normal on this edge? > > If you can provide any guidance that would be greatly appreciated, it's so > close...! I've already tested with the latest release with the same results. > > Thanks a lot, > Kind Regards, > > Nathan Ricks > > > > > > ___ > gmsh mailing list > gmsh@onelab.info > http://onelab.info/mailman/listinfo/gmsh — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
[Gmsh] how do we do to export a mesh in med 3.3 from Gmsh 4.2.3
hello how do we do to export a mesh in med 3.3 from Gmsh 4.2.3 thanks jean pierre aubry -- jean pierre aubry jeanpierreaubry[at]ouvaton.org 33 688 670 795 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
