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

[c.]

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 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)
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.
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"
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