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

Fri Feb 9 17:48:45 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. 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
> 
> 