fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 18, 2010 at 05:17:35AM +0000, Garth N. Wells wrote:
>
>
> On 17/03/10 22:04, Johan Hake wrote:
> >Nice effort!
> >
> >I like the choice of bundle the documentation into one FEniCS documentation,
> >and letting the existing documentation of the sub-projects be Appendices, or
> >just incorporated into the new one.
> >
> >I agree with Marie that we also need a programmers reference, which is more or
> >less the Doxygen generated code we have today (where is this online btw?). As
> >such it is nice but the minimalistic approach to the C++ comments for many
> >member functions makes the documentation a bit sparse. André has taken a more
> >verbose approach when he documented the methods in IntersectionOperator. The
> >code looks a bit cluttered (using /* */ instead of // on each line would
> >probably improve this), but it generates more verbose documentation.
> >
> >If we decides to be more verbose, which I think we should, we need to define a
> >common way to do this. I kind of like how PETSc does it.
> >
>
> Personally, I dislike the (overly) verbose approach in the code
> since I often can't find the actual code amongst all the comments. I
> think that we do a pretty good job in DOLFIN on the C++ side of
> having most functions perform one simple task, which makes the
> function name + argument list + comment enough to describe what's
> going. Python involves more magic and there is no type information,
> so more elaborate doc strings are helpful.

I tend to agree here. I like having just a single line of comment in
the code to not clutter the code, especially if we start to use
special formatting symbols for input / output arguments.

Another reason for avoiding very verbose comments in the code is that
if we should base the documentation on automatic extraction of
comments from the code, then we would need *much more* verbosity, even
more than what Andre has put in the mesh intersection classes. Then we
end up with header files that are 90% comments and 10% code.

Then it seems more efficient to document each function twice: first
very compact as part of the code (as we do now) and then very verbose
in a written manual.

One could also consider some middle ground where we put a semicompact
documentation as part of the code, then somehow automatically append
additional information as part of the generation of the documentation,
but that seems complicated.

> >We have also discussed using a standard format for the Python Docstrings. So
> >nice programmers references can be generated from these. We haven't decided
> >which one we are going to use (epydoc or others). I couldn't find doconce (too
> >close to many other meanings of doc once :P) at the net so I do not know what
> >this software does or how well adapted it is.

Perhaps Hans Petter could say something about doconce?

It might have some good features we can use. But one issue would be
the status of doconce. To be useful, it needs to be actively
maintained and widely available (as in having a Debian package).

> >Can someone(tm) explain what "well documented demos" means? Should the
> >equation the demo solve be explained more?
>
> Firstly, to document better the equation and the solution method.
> Then, to make clear how each 'step' in the solution process can be
> implemented.

deal.II has well documented examples as part of their tutorial that
could serve as a model:

  http://www.dealii.org/6.2.1/doxygen/tutorial/index.html

I think we need to separate demos from tutorial/example programs. The
demos should be as they are now: short, simple and self-explaining.

Then we can have a different set of programs which are explained very
carefully. It would be natural for these to be part of the tutorial
(based on the existing tutorial written by Hans Petter).

--
Anders


> >Should an underlying structure a
> >demo show be explained in more detail (for example: one demo explaining the
> >mixed method, and an other one explaining mesh refining, or the use of JIT
> >compiled expressions in Python?)
> >
>
> Yes, I think that if there is a gap in the sense that we don't have
> a demo to illustrate the use of a particular mainstream feature,
> then we should formulate a demo, preferably something interesting,
> to demonstrate the feature. For more complicated features, we might
> want the demo to focus strongly on a particular feature.
>
> Garth
>
>
> >Johan
> >
> >>As you are all aware, FEniCS is lacking good documentation. The
> >>situation will improve when the FEniCS book comes out, but it will
> >>not replace a comprehensive user manual.
> >>
> >>A very good solution to this problem has just presented itself. I
> >>have some grant money that could go towards creating good
> >>documentation and I have also found an ideal candidate in Kristian
> >>Oelgaard. He should really be finishing up his thesis but has kindly
> >>accepted to work part-time on the manual. :-)
> >>
> >>So, let's hear some opinions on what kind of documentation users need.
> >>
> >>Kristian, Garth, Hans Petter and I have had some initial discussions
> >>and here are some thoughts so far. Let's get the discussion going.
> >>
> >>1. The new documentation will consist of two parts, one called
> >>"FEniCS User Manual" and one called "FEniCS Tutorial". The first one
> >>will be a comprehensive manual and the second will be a tutorial based
> >>on Hans Petter's tutorial chapter for the FEniCS book.
> >>
> >>2. Both the user manual and tutorial will come in two different
> >>flavors, one C++ and Python. With some clever use of LaTex \input, it
> >>should be possible to handle with not too much extra work.
> >>
> >>3. The user manual will replace the current user manuals for DOLFIN,
> >>FFC, UFL and UFC. What we have now in those manuals can be used as
> >>input.
> >>
> >>4. The manual will focus on the user experience and therefore
> >>concentrate on the DOLFIN interface. Specific details for FFC, UFL and
> >>UFC will be made appendices in the new manual.
> >>
> >>5. The manual will be available both as a PDF file and online HTML.
> >>Hans Petter has pointed out a new tool called doconce that might be
> >>useful for generating PDF, HTML and docstrings from a common source.
> >>This is worth investigating as docstrings are also important and it's
> >>extra work to maintain both docstrings and manual.
> >>
> >>6. We need well-documented demos. It's currently unclear what the
> >>relation is between the manual, documented demos, current demos in
> >>DOLFIN and the examples in Hans Petter's tutorial so we need to work
> >>out a model for this.
> >>
> >
> >_______________________________________________
> >Mailing list: https://launchpad.net/~fenics
> >Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> >Unsubscribe : https://launchpad.net/~fenics
> >More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: Digital signature