From: Lorenzo B. <bot...@gm...> - 2008-03-21 15:09:24
|
Hi all, I have written a vtk writer (it does not read vtk meshes!) that doesn't need to be linked to vtk. I don't know if someone need it but I did :-). Unfortunately I don't have any experience with parallel mesh so it is difficult for me to make it parallel. I know it isn't hard because vtk has a parallel format in witch you write an header and a .vtu file (equal to the serial case) for each processor. So, I have some questions about parallel mesh... Does the global dof indices go from 0 to n_local_dof in each processor? Is a parallel implementation expected for all the IO? And, Do you prefer a vtk writer linked to vtk? Lorenzo |
From: Roy S. <ro...@st...> - 2008-03-21 15:27:12
|
On Fri, 21 Mar 2008, Lorenzo Botti wrote: > I have written a vtk writer (it does not read vtk meshes!) that > doesn't need to be linked to vtk. I don't know if someone need it but > I did :-). VTK is released under a BSD-like license, isn't it? Why did you need to hand-code your own writer rather than using their APIs? > Unfortunately I don't have any experience with parallel mesh so it is > difficult for me to make it parallel. I know it isn't hard because vtk > has a parallel format in witch you write an header and a .vtu file > (equal to the serial case) for each processor. > > So, I have some questions about parallel mesh... > Does the global dof indices go from 0 to n_local_dof in each processor? No; the global DoF indices are still unique globally; each processor has a contiguous range (of it's own DoFs, I mean, not of ghost DoFs), but only processor 0's range starts at 0. > Is a parallel implementation expected for all the IO? Eventually, yes, but there's some leeway in getting there. Even if the user has to serialize the ParallelMesh before writing (i.e. the worst case scenario), that still might be worthwhile in an implicit problem where the mesh can fit on a single processor but the mesh plus distributed sparse matrix can't. For a more practical example, if you do mesh IO by just handing it chunk by chunk to processor 0, that's still a huge memory savings even if it doesn't properly parallelize the I/O workload. When I was writing the ParallelMesh data structures I hoped that eventually we'd be having each processor handle the writing of it's own partition, but my hope has not translated into more effective action than "applaud and keep an eye out for bugs as Ben does all the hard work of coding parallel I/O". > And, > Do you prefer a vtk writer linked to vtk? In the abstract, I do - that way we get any bug fixes and possibly backwards-compatible new feature additions for free when the VTK people add them in newer versions. But I'm open-minded. "Doesn't require the hassle of another third party dependency" has it's benefits too. Are there any other advantages of your standalone code? --- Roy |
From: John P. <jwp...@gm...> - 2008-03-21 15:42:19
|
On Fri, Mar 21, 2008 at 10:26 AM, Roy Stogner <ro...@st...> wrote: > > On Fri, 21 Mar 2008, Lorenzo Botti wrote: > > > I have written a vtk writer (it does not read vtk meshes!) that > > doesn't need to be linked to vtk. I don't know if someone need it but > > I did :-). > > VTK is released under a BSD-like license, isn't it? Why did you need > to hand-code your own writer rather than using their APIs? You might want to write VTK files on a machine where VTK is not installed and you don't have adminstrator access... Lorenzo: have you implemented your code as part of the existing vtk_io.C? For example, as a code path when HAVE_VTK is not defined? This would probably be most helpful. -J |