From: <an...@tn...> - 2004-03-27 03:00:46
|
Hi all About a week ago I promised to send a patch for the correct export of QUAD8 elements to GMV. Now I was looking into doing that, and noted some problems / inconsistencies: o is mesh_gmv_support.C obsolete? There, the elements are handled differently than in gmv_IO (no calls to tecplot_connectivity) o should there be a gmv_connectivity function, which delegates to tecplot_connectivity if there is a special case? Or would a generic get_connectivity(se, type) make more sense? (where type is one of ["gmv", "tecplot", "diva", "vtk"]) o There seems to be quite some code duplication, especially in the tecplot_connectivity and vtk_connectivity methods of the different geom/cell_*. It seems that the only difference is that gmv needs a 1 based node numbering. o Is there a reason for the different calling sequences of the tecplot_connectivity and vtk_connectivity methods methods (return values vs. return arguments)? To me it seems that the renumbering / splitting could be handled more generically. What are your thoughts? Martin |
From: <an...@tn...> - 2004-03-30 01:15:54
|
Benjamin From the methods you suggest, the self-contained one looks best to me, i.e. something along the lines of Benjamin S. Kirk writes: > Perhaps a better option is to have the classes do it internally: for > example, GMVIO would include a private member, > > get_connectivity(const Elem*, std::vector<unsigned int>& conn) > > that does a switch on elem->type() and implements the proper > connectivity for each element type. I kinda prefer this approach in the > interest of keeping proper code in its place. It will also encourage > people to add new formats if they don't have to change a lot of other > classes... Exactly, this would simply be a matter of adapting one file. Looks to me like the way to go. Thanks, Martin |