Hi David, Thanks for pointing that out to me.
If I see correctly, onelab isn't installable via pip or apt. As such, I won't be able to use it unless I prepare myself for a ton of support on how to install onelab. Too bad the functionality isn't part of Gmsh itself. Anyhow, I might look into bundling onelab for Debian in the future. Cheers, Nico On Tue, Jul 19, 2016 at 3:22 PM David Colignon <[email protected]> wrote: > > Hi Nico, > > Have you heard about ONELAB and the onelab.py module ? > > http://onelab.info/wiki/ONELAB > > http://onelab.info/wiki/Python > > Regards, > > Dave > > -- > David Colignon, Ph.D. > 1er Logisticien de Recherche > Université de Liège > ACE - Applied & Computational Electromagnetics > Quartier POLYTECH 1 - Montefiore B28 > Allée de la découverte 10 > 4000 Liège - BELGIQUE > Tél: +32 (0)4 366 37 32 > http://www.ulg.ac.be/nic4 > > > On 19/07/16 15:09, Nico Schlömer wrote: > > > Hi everyone, > > > > As the author of pygmsh [1] I sometimes get user complaints about how > slow mesh generation is. The way pygmsh works is that it > > generates a geo-file in memory, writes that out, has gmsh run over it to > generate a msh-file, then read in and parse that file > > to generate the nodes and cells in memory. I'm wondering if this could > be improved. > > > > What comes to mind straight away is passing the geo-file as a string to > gmsh, and to retrieve the msh-file as a string from > > gmsh. This way, the slow I/O on the hard drive is avoided. Is that at > all possible with gmsh? > > > > Even better would be to retrieve the mesh data directly from gmsh, but I > guess for this it'd need tighter integration with > > Python which just isn't there. > > > > Cheers, > > Nico > > > > > > [1] https://github.com/nschloe/pygmsh > > > > > > _______________________________________________ > > gmsh mailing list > > [email protected] > > http://onelab.info/mailman/listinfo/gmsh > > > >
_______________________________________________ gmsh mailing list [email protected] http://onelab.info/mailman/listinfo/gmsh
