[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