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 00:28:27 +0200
> To: address@hidden
> CC: address@hidden
>
>
> On 7 Jun 2013, at 19:25, Marco Vassallo <address@hidden> wrote:
>
> > or maybe something related to the label of the border ?
> I really don't understand what you mean here, could you please elaborate?

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.
 
>
> > I have also seen that there is a plot option under dolfin.. we could integrate it with something like msh3p_mesh ??
> In Octave-Forge FEM visualization is taken care of by the FPL package, so that function fits better ther than in msh.
>
> Marco,
>
> I think you have done a good job with coding your first function, but now you should stop a bit and think about the bigger picture,
> you don't want to be working at random functions in a messy and disorganic manner.
>
> The reason why I suggested you should start by implementing mesh conversion and refinement functions is to use this simple task as an excercise to learn how to deal
> with Octave-Forge development and how to link with liboctave and dolfin.
>
> A this stage you should focus on learning about Octave-Forge package structure, about Octave coding style and about liboctave and dolfin
> data structures. Adding many feature-rich new functions to the msh package is not crucial at this point.
>
> You prepared a prototype of the functions to read and write xml.gz dolfin mesh files into the msh data format, I pointed out a list of issues you should fix in these
> functions.
>
> You should now be addressing these issues, which I summarize again below for convenience, and work on merging your functions with the rest of the package.
>
> 1: choose meaningful and not misleading names for your functions (xml2oct seems to suggest your function is a general xml parser, which is not the case)
> 2: respect the naming convention of the package that uses "msh" in front of all names (this is a naive way to work around Octave's lack of namespaces)

I'm doing something like

msh2m_oct_to_xml
msh2m_xml_to_oct
msh2m_uniform_refine

and the same for 3D.. I don't want to put some specific reference to dolfin
because xml is more general. I don't know if maybe

msh2m_pet_to_xml

could be better..

> 3: edit your code to follow Octave code formatting guidelines:
> http://www.gnu.org/software/octave/doc/interpreter/C_002b_002b-Sources.html#C_002b_002b-Sources
> this improves the readibility of the code for others who will have to review it and maintain it.

ok..so maybe it could be useful to add comments also inside the code and
not only the general explanation on top of it??

> 4: add proper checks for input consistency as suggested in my previuos mail
> 5: add unit tests and/or demos
> 6: prepare a makefile so that your functions can be built automatically when doing "pkg install msh"

How can I check if dolfin is installed ?

> 7: (this was not mentioned in my previous mail, but is also important) add texinfo doc strings to your functions
> 8: once you are done with the steps above you can apply the same development process to implement "msh2m_refine" and "msh3m_refine",
> following the simplest possible approach.
>
> once you are done with these preliminary excercises you should stop for a while and think about the overall design of your package, before you go on coding.
> I suggest you prepare a draft describing what the user interface of the Octave-dolfin should look like and present it in a talk at OctConf.
>
> keep up with the good work,
> Carlo
>

Thanks a lot for your advices,

Marco