← Back to team overview

dolfin team mailing list archive

Re: dolfin-convert: bug with conversion from gmsh?

 

Thanks.

/Anders


On Thu, Dec 07, 2006 at 05:46:36PM +0100, Angelo Simone wrote:
> another bundle: I have updated io.tex to reflect the changes in 
> dolfin-convert.
> 
> angelo
> 
> 
> Anders Logg wrote:
> >Looks ok now! Thanks.
> >
> >/Anders
> >
> >
> >On Thu, Dec 07, 2006 at 03:03:34PM +0100, Angelo Simone wrote:
> >  
> >>I have fixed the gmsh2xml conversion.
> >>
> >>angelo
> >>
> >>
> >>    
> >>>I've fixed the xml_old2xml conversion also, so only the gmsh2xml
> >>>conversion remains. I'll leave it as it is for now and wait for
> >>>another patch (bundle) from you.
> >>>
> >>>Make sure you make the bundle against the current dolfin tree (which
> >>>include my updates to mesh2xml and xml_old2xml).
> >>>
> >>>Thanks
> >>>/Anders
> >>>
> >>>
> >>>On Thu, Dec 07, 2006 at 12:03:48PM +0100, Anders Logg wrote:
> >>> 
> >>>      
> >>>>On Thu, Dec 07, 2006 at 01:18:49AM +0100, angelo simone wrote:
> >>>>   
> >>>>        
> >>>>>Here's the bundle. dolfin-convert is now in pure python (i.e. there 
> >>>>>are no calls to grep) and there are no temporary files. Is it ok now?
> >>>>>The script has been tested with the attached mesh files:
> >>>>>gmsh.msh (2d)
> >>>>>old-xml.xml.gz (2d)
> >>>>>tetgen.mesh.gz (3d)
> >>>>>     
> >>>>>          
> >>>>Thanks, but I don't really like the write_output stuff. I have added
> >>>>your changes and modified mesh2xml so it first scans the file for the
> >>>>cell type and then does the conversion. Could you supply a patch that
> >>>>does the same thing for gmsh2xml and xml_old2xml?
> >>>>
> >>>>   
> >>>>        
> >>>>>I have tried the output of the first two conversions with a Dolfin 
> >>>>>example and they worked out fine. The tetgen mesh, which comes from 
> >>>>>the example.poly file distributed with tetgen 1.4.1, has not been 
> >>>>>tested against Dolfin. The output does look ok though.
> >>>>>     
> >>>>>          
> >>>>Thanks. I have added the test meshes and your updated conversion
> >>>>script, but I don't like the write_output stuff
> >>>>
> >>>>   
> >>>>        
> >>>>>As far as I can see from the tetgen web page 
> >>>>>(http://tetgen.berlios.de/), tetgen cannot generate 2d meshes. Is 
> >>>>>there a reason why in the script there is a check on num_dims == 2?
> >>>>>     
> >>>>>          
> >>>>I haven't tested, but presumably the conversion works for meshes
> >>>>generated by Triangle. I think Triangle and TetGen share the same 
> >>>>format.
> >>>>
> >>>>   
> >>>>        
> >>>>>I will soon send a bundle to update section 8.3 of the 
> >>>>>dolfin-user-manual. A bundle on the procedure to create a bundle will 
> >>>>>be ready soon as well.
> >>>>>     
> >>>>>          
> >>>>Very nice.
> >>>>
> >>>>/Anders
> >>>>
> >>>>
> >>>>   
> >>>>        
> >>>>>angelo
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Anders Logg wrote:
> >>>>>     
> >>>>>          
> >>>>>>You could try generating some with tetgen.
> >>>>>>
> >>>>>>When you submit the patch, please also include some (very small) test
> >>>>>>meshes that you have run the code on. We can add these for future
> >>>>>>reference.
> >>>>>>
> >>>>>>Thanks
> >>>>>>/Anders
> >>>>>>
> >>>>>>
> >>>>>>On Tue, Dec 05, 2006 at 01:56:00AM +0100, angelo simone wrote:
> >>>>>>
> >>>>>>       
> >>>>>>            
> >>>>>>>Exactly. Anyway, I got rid of the ugly hack...  ;-)   
> >>>>>>>
> >>>>>>>Before sending a bundle, I would like to test the new version on 2d 
> >>>>>>>and 3d Medit meshes, which I do not have. Does anyone have them? 
> >>>>>>>Thanks!
> >>>>>>>
> >>>>>>>angelo
> >>>>>>>
> >>>>>>>
> >>>>>>>Anders Logg wrote:
> >>>>>>>  
> >>>>>>>         
> >>>>>>>              
> >>>>>>>>I think because the new mesh format requires celltype in the header 
> >>>>>>>>of
> >>>>>>>>mesh, so the mesh needs to be scanned before writing to find out the
> >>>>>>>>celltype.
> >>>>>>>>
> >>>>>>>>Instead of doing this, the patch first generates an illegal xml file
> >>>>>>>>missing the celltype attribute and then scans the generated file to
> >>>>>>>>grep for the cell type and then fixes the header...
> >>>>>>>>
> >>>>>>>>It works but it's not a nice solution. Angelo, please submit an
> >>>>>>>>updated patch that first scans the file for the cell type 
> >>>>>>>>(preferably
> >>>>>>>>not using grep).
> >>>>>>>>
> >>>>>>>>/Anders
> >>>>>>>>
> >>>>>>>>PS: Yes, I know you looked at xml_old2xml() that I wrote and I do 
> >>>>>>>>use
> >>>>>>>>grep, but it's still an ugly hack. :-)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>On Mon, Dec 04, 2006 at 11:06:21AM +0100, Garth N. Wells wrote:
> >>>>>>>>
> >>>>>>>>    
> >>>>>>>>           
> >>>>>>>>                
> >>>>>>>>>Why are temporary files being created? Isn't updating to the new 
> >>>>>>>>>mesh xml format just a case of changing the output formatting?
> >>>>>>>>>
> >>>>>>>>>Garth
> >>>>>>>>>
> >>>>>>>>>angelo simone wrote:
> >>>>>>>>>  
> >>>>>>>>>      
> >>>>>>>>>             
> >>>>>>>>>                  
> >>>>>>>>>>hi,
> >>>>>>>>>>
> >>>>>>>>>>I have fixed dolfin-convert (patch attached). Now the output is 
> >>>>>>>>>>in the current format for both Gmsh and Medit. I have tested 
> >>>>>>>>>>dolfin-convert with triangular Gmsh meshes but is should work 
> >>>>>>>>>>fine with all the remaining combinations as well.
> >>>>>>>>>>
> >>>>>>>>>>Regarding the addition to the user manual, maybe we should just 
> >>>>>>>>>>add that on top of the steps described in the Gmsh mesh 
> >>>>>>>>>>generation tutorial 
> >>>>>>>>>>(http://www.geuz.org/gmsh/doc/gui_tutorial/gui_tutorial.pdf) one 
> >>>>>>>>>>needs to create physical surfaces/volumes as well to generate a 
> >>>>>>>>>>dolfin-friendly mesh -- yesterday I have used Gmsh for the first 
> >>>>>>>>>>time... that's why I did that mistake. Anyway, dolfin-convert 
> >>>>>>>>>>complains if the mesh is not in the correct format.
> >>>>>>>>>>
> >>>>>>>>>>angelo
> 


> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev



References