[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
command

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

Cheers,

Dave


>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
>