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

[Christophe Geuzaine]

Colignon David wrote:
>> 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
> 


Just to add a couple of thing to Dave's comments:

- changing the characteristic lengths and defining physical groups are
the only two "modifications" we can perform on STEP/IGES/BRep models for
now. We plan to add more advanced stuff later (delete, create "mixed"
surfaces and volumes, export to .geo, etc.), but it will take a while.

- don't use "--enable-parallel": it's just for running post-processing
plugins in parallel.


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

Not that I know of...


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


Sorry: "COG" == center of gravity == barycenter. We draw arrows either
at the COG of the element, or at the vertices. We compute the average
when we draw at the COG, hence the two code paths.


>> 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(?).

Yes, all the point, line or arrow sizes in the GUI are specified in
pixels. This way they are independent of the zoom level.


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

Very nice!


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

All the new code is written in terms of the standard library
(std::vector, std::map, etc.). The old code still uses the old "home
made" structures in places, but we are slowly replacing those.


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

Not sure if it's faster--it's just historical.


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

Sure, this would be cleaner. Again, this is just how it was written a
loooong time ago ;-)


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


Agreed: adding support for VTK files would be nice.

One idea floating around over here is that we might want to rewrite the
post-processing module in a way similar to the way we rewrote the
geometry module and the mesh module. If that happens, all the internal
data structures for the post-processor will change... So adding new I/O
routines for the post-processor might be better left off until we decide
if we do rewrite the whole thing or not.


>> * right-clicking of the X/Y/Z fields in the bottom of the OpenGL could
>> have the same effect as shift-clicking.

OK.


>> * Doxygen documentation in some cases would be really nice.

Not sure about this one: I hate reading Doxygen docs myself :-)


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


Agreed. Now that our mesh interface is "clean", it would be nice to
implement pyramids to couple tets and hexas.

Cheers,

Christophe




>> 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
>>
> 
> 
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
> 
> 


-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine