[Gmsh] versions higher then 1.53 do not work

Christophe Geuzaine christophe.geuzaine at case.edu
Mon Feb 13 23:41:58 CET 2006


Alfonso Medina wrote:
> Well it does work fine but considerably slower than Linux. Where in 
> Linux the vector field looks like real grass moving in a windy day, on 
> windows it looks like time stop clay animation. That and the windows 
> machine is the more powerful, with better processor and memory while the 
> other one is an outdated previous cad station. So it must be the combine 
> step that makes it slow plus the fact that it seems to process graphics 
> slower.
> 
> 
> It got me into thinking. GMSH does not let you change the .pos format 
> until you actually read the data in. Is there anyway I can open files 
> with the "View.VectorType=2 " option as a default or user set option 

Sure: either make the changes you want in the GUI (on View[0]) and click 
"Save", or just add "View.VectorType=2;" in ~/.gmsh-options



> that I can save? That way I don't have to bother when ever I open a .pos 
> for the first time. I always have to go and take the "proportional"  and 
> the "3-d arrow" off because it opens and animates much slower than if 
> you had just a line, and its hard to see direction with "proportional" on.
> 
> Alfonso
> 
> ps:
> 
> By the way, is anyone working on an Openflower GUI that can merge GMSH 
> and OpenFlower into one app? Openflower has a pre-release of a gui that 
> will write their flow setup, boundary conditions, flow characteristics 
> and so on... called a .flw file. Its not very good, but it works to 
> start a .flw anyway. You can however, see that it could be incorporated 
> into GMSH as just another item on a pull down menu.
> 
> 
> Another two things that would be great is to have "volume" in the 
> geometry physical menue and to have an inverted selector. For example, 
> if I know my inle/outlet surfaces, and I have a huge amount of walls, I 
> can just click on the inlet and outlet with inverted selection and so 
> select the rest of the geometry to be walls.
> 
> 
> 
> Christophe Geuzaine wrote:
>> Alfonso Medina wrote:
>>> I just inserted the View.VectorType=2 line in all the .pos files. 
>>> then I open the main file that merges them. On both the regular 
>>> default format and the line format I can see that GMSH opened all the 
>>> .pos files separately. The one with the line format (no 3-d arrow) 
>>> opens much much faster but gets stuck at the lest one. I'll leave it 
>>> open for an hour or so. I'm almost at lunch time so I'll do that .. 
>>> never mind... its done.   It just took a long time. I let it work for 
>>> five minutes and it did it. The same file on my live Linux machine 
>>> opens in seconds, no kidding, I have them both side by side on my desk.
>>>
>>>
>>> The format for the files is as follows:
>>>
>>> main.pos:
>>>
>>> Merge "eqn1.Velocity_0.pos" ;
>>> Merge "eqn1.Velocity_0.18.pos" ;
>>> Merge "eqn1.Velocity_0.233632.pos" ;
>>>
>>> etc...
>>>
>>> Merge "eqn1.Velocity_0.931894.pos" ;
>>> Merge "eqn1.Velocity_0.984138.pos" ;
>>> Merge "eqn1.Velocity_1.pos" ;
>>> Combine TimeSteps;
>>> For num In {0:PostProcessing.NbViews-2}
>>> Delete View[0];
>>> EndFor
>>>
>>
>>
>> I see: it's probably the "Combine TimeSteps" that takes a long time on 
>> cygwin (cygwin is VERY slow for reallocating memory). What happens if 
>> you remove the "Combine TimeSteps", and simply use the "Up" and "Down" 
>> keys to animate all the views (instead of trying to combine all the 
>> views into a single one)?
>>
>>
>>
>>>
>>> .....0.18.pos:
>>>
>>>
>>> $PostFormat
>>> 1.2 0 8
>>> View.VectorType=2
>>> $EndPostFormat
>>> $View
>>> Velocity 1
>>> 0 0 0
>>> 0 0 0
>>> 0 0 0
>>> 0 0 0
>>> 0 0 0
>>> 0 0 0
>>> 0 15500 0
>>> 0 0 0
>>> 0 0 0 0
>>>
>>> 0.18
>>> 64.6077 63.7237 66.3175 64.6077 63.7237 66.3175 49 50.8958 51.1014 49 
>>> 50.8958 51.1014 0 0 0 -0.8 -0.8 -0.8 -2.16479 -0.284308 -2.03184 
>>> -2.30209 -0.0158257 -2.3532 -1.65467 0.227224 -2.39342 -2.92935 
>>> -0.654019 -1.28639 -3.26707 -0.347892 -1.56637 -2.22174 -0.00604365 
>>> -1.9636
>>> 64.6077 63.7237 66.3175 64.6077 63.7237 66.3175 49 50.8958 51.1014 49 
>>> 50.8958 51.1014 -0.8 -0.8 -0.8 -1.6 -1.6 -1.6 -2.92935 -0.654019 
>>> -1.28639 -3.26707 -0.347892 -1.56637 -2.22174 -0.00604365 -1.9636 
>>> -2.98417 -0.600146 -0.78471 -3.24314 -0.284272 -0.985424 -2.31901 
>>> -0.0300575 -1.38174
>>> 64.6077 63.7237 66.3175 64.6077 63.7237 66.3175 49 50.8958 51.1014 49 
>>> 50.8958 51.1014 -1.6 -1.6 -1.6 -2.4 -2.4 -2.4 -2.98417 -0.600146 
>>> -0.78471 -3.24314 -0.284272 -0.985424 -2.31901 -0.0300575 -1.38174 
>>> -2.81127 -0.48989 -0.367549 -3.01361 -0.18419 -0.48448 -2.31387 
>>> -0.0144138 -0.719408
>>>
>>> etc.
>>>
>>>
>>> hristophe Geuzaine wrote:
>>>> Alfonso Medina wrote:
>>>>> When I try a large OpenFlower .pos file it will start to load the 
>>>>> velocity fields one step at a time, then it slows down to the point 
>>>>> where it just hangs. I'm not sure if it just needs more time (hours 
>>>>> on a 3GHZ 2.5gig computer with excellent CAD opengl rated card). 
>>>>
>>>> Is the display (redrawing) really slow, or just the file reading part?
>>>>
>>>> - If it is the display and if you use 3D arrows to represent the
>>>> velocity field, could you try using "simpler" arrows (e.g.
>>>> View.VectorType=2;) and let me know if it makes a  difference?
>>>>
>>>> - If it is the file reading part, then it is probably due to the 
>>>> fact that you are using ASCII files--and cygwin is atrociously slow 
>>>> when reading ASCII files (I have no idea why). Could you retry after 
>>>> converting your .pos file in binary format (you can use "gmsh 
>>>> -convert file_ascii.pos file_binary.pos" to do that)?
>>>>
>>>>
>>>>> In any case, I use the cygwin1.dll that comes with the download. 
>>>>> What is so special about it that you would want to keep an older 
>>>>> version?
>>>>
>>>> Just to see if a newer cygwin is the cause of Milan's problems...
>>>>
>>>>
>>>>
>>>>>
>>>>> Alfonso
>>>>>
>>>>>
>>>>> Christophe Geuzaine wrote:
>>>>>> Alfonso Medina wrote:
>>>>>>> I have gmsh running on an XP machine that recently got the 
>>>>>>> service pack. I use the latest binary version and it works ok. I 
>>>>>>> find that it will hang on large files. Other than that, it works 
>>>>>>> great. What I do is to 
>>>>>> Interesting: could you tell me a bit more about when it hangs? 
>>>>>> (Does it
>>>>>> happen when you load large post-processing files or large meshes? In
>>>>>> binary or ASCII format?)
>>>>>>
>>>>>>
>>>>>>> save GMSH and the  flow solver I use, OpenFlower in  a USB pen 
>>>>>>> drive. I then use a Knoppix CD to run linux on my machine. It 
>>>>>>> works fantastically. Night and day between cygwin and a real 
>>>>>>> linux on CD. Knoppix works. Ubuntu live CD also runs GMSH but not 
>>>>>>> OpenFlower because the CD comes without some deps.
>>>>>>>
>>>>>>> What is your experience between gmsh binary and gmsh compiled? I 
>>>>>>> notice no difference.
>>>>>>>
>>>>>>> Alfonso
>>>>>>>
>>>>>>>
>>>>>>> milan.hokr at email.cz wrote:
>>>>>>>> Me and my colleagues have problems with running GMSH on Windows 
>>>>>>>> XP. If I try to run gmsh.exe, nothing happens (or the 
>>>>>>>> application start and immidiately ends). I guess this problem 
>>>>>>>> arised after installing Service pack 2 in Win XP. And it happens 
>>>>>>>> for version from 1.53 (with cygwin1.dll of larger size 1.1M 
>>>>>>>> instead of 0.9M in older version).
>>>>>>>> I did not find any other cygwin*.dll file in my system.
>>>>>>>>
>>>>>>>> Is there anybody with this problem. How to solve it?
>>>>>>>>
>>>>>>>> Thank you
>>>>>>>> Milan Hokr
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gmsh mailing list
>>>>>>>> gmsh at geuz.org
>>>>>>>> http://www.geuz.org/mailman/listinfo/gmsh
>>>>>>>>
>>>>>>>>
>>>>>>>>   
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 


-- 
Christophe Geuzaine
Assistant Professor, Case Western Reserve University, Mathematics
http://www.case.edu/artsci/math/geuzaine