[Gmsh] mesh I/O in memory?
nico.schloemer at gmail.com
Wed Jul 20 01:36:34 CEST 2016
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.
On Tue, Jul 19, 2016 at 3:22 PM David Colignon <david.colignon at ulg.ac.be>
> Hi Nico,
> Have you heard about ONELAB and the onelab.py module ?
> 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
> On 19/07/16 15:09, Nico Schlömer wrote:
> > Hi everyone,
> > As the author of pygmsh  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
> >  https://github.com/nschloe/pygmsh
> > _______________________________________________
> > gmsh mailing list
> > gmsh at onelab.info
> > http://onelab.info/mailman/listinfo/gmsh
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gmsh