[Gmsh] Remarks Gmsh2 && Re: (Saturated Vector Display || Logarithmic)&&(Windowsize)

Colignon David David.Colignon at ulg.ac.be
Sat Feb 10 09:35:11 CET 2007

> Hello Gmsh-Developers!
> Finally I had the time to "switch" to your new release. That must have
> been a terrible lot of work, and personally, I want to thank all
> involved people for that.
> The first test gave rise to the following infos/questions.
> I compiled the current versions with
> "OPTIM= -O3  -fomit-frame-pointer  -march=pentium4  -pipe"
> using gcc 4.1, and it works like a charm. Also, I really enjoy the
> antialiasing checkbox :), thank you for the implementation.
> The first shot with "--enable-parallel" however failed, probably as
> there is no "--with-mpi-prefix" yet, and there are multiple MPIs on my
> machine (e.g for shared memory). Is this option intended to create some
> mesh-partition, by filling the 3rtd tag in the gmsh2-msh-format? Or is
> the intention to do parallelised meshing?
> Building with OpenCascade failed because I could not manage to install
> OpenCascade (wrong clib, Ubuntu 6.10 , I did not try to play around with
> LD_LIBRARY_PATH). However, with the precompiled windows version, I
> opened a sample IGES geometry file. Gmsh reads the file fine, without
> errors. "Edit" opened the Iges file. However, trying to save as ".geo"
> file format created an empty geo. Also, I could not find a way of
> setting the characterist lengths of the involved points.

Hi Bernhard,

we should add this in the manual and in the FAQ:

In order to "modify" an iges file, create a simple .geo file with just the

Merge "my_iges_file.iges" ;

and open this .geo file instead of the .iges file.

Now you can modify the characteristic length of the points and your
modifications will saved in the .geo file



>Apart from
> that, I really find it great that you use opencascade.
> [Just as info, my iges file was created by the following workflow:
> parameterized gmsh-geo file->own converter->Gambit (Fluent's commercial
> mesher) journal file->Gambit export as iges. Parameterizing geometries
> in gmsh is much-much nicer than using just Gambit.]
> Also, I find it great that there is now a binary mesh format. Reading
> times are about 30% faster here.
> Is it allright, if I try to implement this into GetDP, or is somebody
> else already working on that?
>> Are you still happy with this patch? If you think this is the way to go,
>> could you generalize it so that it works for both COG- and vertex-drawn
>> arrows? Then I'll merge it into the trunk.
> My collegues and me are still using this patch. We find it quite
> valueable for magnetic far-fields, as they decay rapidly.
> I just spend half an hour trying find what you mean by "COG- and
> vertex-drawn". In PostElement.cpp,
> all routines "Draw_Vector*()" basically refer to "Draw_VectorElement()".
> And the latter routine, I edited for my Log/Saturation stuff. The only
> other vector-drawing routines I found are associated with "Normals" and
> "Tangents", where the vector length is given by the view panel's
> settings in pixel(?).
> About the geo-script-image-creating-missng-geometry problem:
>> Can you you send the file?
> Yes, I'll put it online for you (on monday, I guess, as a look on the
> watch tells me), but we better do this off-the-mailing-list, as the mesh
> is from a customer-project.
> Meanwhile, I already found an ugly workaround: I made two geo-sripts.
> The first one loads the pos and the geometry and finally does all the
> setting up. The second just saves the picture. Calling "gmsh first.geo
> second.geo" resulted in having the geometry included in the pngs. [One
> picture of the animation I just uploaded to
> http://www.geuz.org/getdp/wiki/Gallery at the bottom. ]
> About the way the sourcecode (this also includes GetDP) is written, I
> have some (honest) questions, so I might improve my personal coding
> style:
> You seem to use custom created trees and lists. Is this just historical,
> or are they really so much better than e.g. std::map and std::list?
> Because, as far as I found out, map also uses balanced trees.
> Also, there are a hell lot of "#define blabla 5" in the source. Is this
> faster then "const int blabla=5", I always thought that the compiler
> replaces const-variables at copmile-time anyway, and one doesn't run
> into problem is one define contains another one as a substring? Also,
> e.g. in GmshDefines.h
> #define FORMAT_MSH           1
> #define FORMAT_UNV           2
> #define FORMAT_GREF          3
> could  maybe also be done using enums (I know they are hated by some
> people)
> enum Format{MSH, UNV, GREF};
> Possible advantages can be: better compiler warnings with e.g. switch(),
> you cannot call void blabla(enum Format myf) by using blabla(enum
> Elementtyp).
> Finally, I have some ideas for some possible features of gmsh:
> * Import/Export of VTK data-files (The legacy file format is very
> simple, and e.g. Paraview in quite usefull sometimes.) The difference to
> the pos files is that you can have many datasets in one file. However,
> each timestep is a single vtk file. Also, it is necessary to have data
> on all cells in the mesh, opposed to pos files. But the user interaction
> of cut-planes is solved quite beautifully, I think. If you want to play
> around with paraview, I can provide you with sample files.
> * right-clicking of the X/Y/Z fields in the bottom of the OpenGL could
> have the same effect as shift-clicking.
> * Doxygen documentation in some cases would be really nice.
> * For the meshing itself, I find Gambit still superior, mainly because
> of size-functions, or the ability to mesh lines e.g. with
> exponentialy-varying characterisic lengths. Also, the handling of
> hexahedral/mixed meshes is still a drawback of Gmsh. I know its unfair
> to compare gmsh to commercial software, but I believe that there are
> many companies out there, who would pay to see features implemented into
> an open-source meshing tool, or contribute code, or would pay for some
> support/training. Especially since the market for meshing software ,as
> well as FEM-Software, is quite monopolized, there is urgent need for
> alternatives. The same goes for GetDP, if not even more.
> So once again, thank you very much for the new version,
> very nice greetings,
>  bernhard
> On Mon, 2007-02-05 at 14:27 +0100, Christophe Geuzaine wrote:
>> Kubicek Bernhard wrote:
>> > Hello!
>> > Yesterday, I took time to fool around even more with the source-code.
>> >
>> Hello Bernhard,
>> > * One very minor inconvinience is that if one tries to position the
>> > Value-Scale via the GUI, one cannot exceed pixel-positions larger than
>> > +-1024. As windows meanwhile can possibly be larger, I added a const
>> int
>> > so this can be increased by one single variable.
>> Indeed. I've increased it to 2000.
>> >
>> > * A much more handy feature could be this: I added the ability to
>> > saturate vector views, meaning that vectors whose length are out of
>> > range get trimmed instead of being ignored. As well, I modified the
>> > proportional-vector-logartihmic display, so that it works on my local
>> > machine (before, it could be misused as a very sophisticated
>> psychedelic
>> > art generator e.g. logerror.png).
>> >
>> > Attached are two diff-files which are hopefully usefull to visualize
>> the
>> > source-code difference.
>> Are you still happy with this patch? If you think this is the way to go,
>> could you generalize it so that it works for both COG- and vertex-drawn
>> arrows? Then I'll merge it into the trunk.
>> >
>> > However, there are two strange things that were found by my collegue
>> > yesterday:
>> > * Our (1/2D) geometry is not visible in PNGs created with Print
>> > Sprintf("... .png") from within in a geo script. However, in the gl
>> > window the geometry is displayed, but only  _after_ the Sprintf
>> command.
>> >
>> > * Loading an old gmsh-1* geometry file (which for some reason re-uses
>> > IDs for different Objects, e.g. Point(1) and Line(1) ) many elements
>> are
>> > missing in the visibility-window's list. However, the geometry appears
>> > to be 100% correct in the opengl window.
>> Can you you send the file?
>> Thanks,
>> Christophe
>> >
>> > I have to admit that we did not have time yet to check with a
>> different
>> > geometry file.
>> >
>> > Hopefully this is helpful,
>> > nice greetings,
>> >  bernhard
>> >
>> > /------
>> > | freelancer at Arsenal Research, Vienna, Austria
>> http://arsenal.ac.at/
>> > | PhD at Vienna University of Technology, Austria
>> > | http://www.phdcomics.com/comics/archive.php?comicid=97
>> > \------
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > gmsh mailing list
>> > gmsh at geuz.org
>> > http://www.geuz.org/mailman/listinfo/gmsh
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh