RE: Dolfin mesh conversion functions [was: Re: Welcome GSoC students!]

[Marco Vassallo]

> Subject: Re: Dolfin mesh conversion functions [was: Re: Welcome GSoC students!]

> From: address@hidden
> Date: Sat, 8 Jun 2013 10:53:20 +0200
> CC: address@hidden
> To: address@hidden
>
> Hi Marco,
>
>
> On 8 Jun 2013, at 09:01, Marco Vassallo <address@hidden> wrote:
>
> > I've seen that a lot of time it could be interesting a refinement around one of the
> > boundaries (e.g. for the boundary layer problem) and so I was thinking about something like
> >
> > mesh_refined = msh2m_refined(mesh, boundary = 3)
> >
> > but as you said below maybe now it is better to move to more general problems.
>
> Now I see what you mean, indeed also gmsh has a nice feature which allows to refine
> near a given geometrical entity (a face or edge of the boundary or a subdomain region)
> and it would be cool to be able to do the same here.
>
> But this is not crucial at this particular time, so, for now, just add a TODO comment in the
> function for later.
>
> > I'm doing something like
> > msh2m_oct_to_xml
> > msh2m_xml_to_oct
>
> there are many xml-based formats for storing meshes, for example:
>
> http://www.vtk.org/Wiki/VTK_XML_Formats
> http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Ogre+meshxml+DTD
>
> using "xml" in the function name is not descriptive and is misleading.
>
> > and the same for 3D.. I don't want to put some specific reference to dolfin
> > because xml is more general.
>
> xml is indeed more general, but your functions can deal only with a very specific type of xml
> files which are those produced by or for dolfin to represent FE meshes, and this should be made
> clear in the function name and in its documentation.
>
> so, if there is no reason to separate 2d and 3d functions I'd rather use something like

Between the 2D and the 3D case there are just two or three if cycle which I should
include or not. I don't know what is the general guidline for this situation.. because
I've seen that msh always make a distinction between 2D and 3D case.

Thanks

Marco
>
> mshm_dolfin_read
> mshm_dolfin_write
>
> if the functions must be implemented separately then
>
> msh2m_dolfin_read
> msh3m_dolfin_read
> msh2m_dolfin_write
> msh3m_dolfin_write
>
> could be a good option
>
> > ok..so maybe it could be useful to add comments also inside the code and
> > not only the general explanation on top of it??
>
>
> the approach I (and some other developers, but not all) like is rather to limit
> comments within the code to cases where you are doing something obscure and/or very non-standard.
>
> Otherwise well written and formatted code should be self explanatory, here is an example
> I often like to show which is taken by a (real but anonymous) student's exam project.
>
> the code below has a very verbose comment, but still this doesn't make it any clearer:
>
> # initialize the value of the variable nds
> # here we choose the value 1
> nds = 1;
>
> this line of code is not commented but it is easy to understand what is going on:
>
> number_of_space_dimensions = 1;
>
> That said, my own code may use a lot of improvement in terms of readibility ;)
>
> > : prepare a makefile so that your functions can be built automatically when doing "pkg install msh"
>
> you could add a configure script to the source directory, if there is one pkg will automatically run it.
>
> Hope this helps,
> c.
>
>
>