dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 03, 2006 at 07:00:58PM +0200, Garth N. Wells wrote:
> On Mon, 2006-04-03 at 11:43 -0500, Anders Logg wrote:
> > On Mon, Apr 03, 2006 at 06:19:40PM +0200, Garth N. Wells wrote:
> > > Maybe this is a good time to prioritise future efforts?
> > > 
> > > Things which I'd really like to have (motivated by problems I'm working
> > > on now) are:
> > > 
> > > -more general boundary conditions (starting to work on this now)
> > >    * Neumann bc's
> > >    * u \dot n type Dirichlet bc's
> > 
> > This is high on my priority list as well.
> > 
> > > -non-affine elements
> > 
> > We should do this but it would require more work since FFC is largely
> > based on affine mappings.
> > 
> > Johan J is working on Nedelec and other elements that use the Piola
> > transform. Are you thinking about isoparametric elements?
> >  
> 
> Yes, in particular some benchmark problems with circular domains (hence
> the u \dot n boundary conditions as well).

ok.

> > > -ability to read things into the parameter system from a file (so a
> > > program doesn't have to be recompiled to change a variable)
> > 
> > Good news, this is already implemented:
> > 
> >     File file("parameters.xml");
> >     file >> ParameterSystem::parameters;
> > 
> > Try saving your current parameters to get an initial parameter
> > file to start from:
> > 
> >     File file("parameters.xml");
> >     file << ParameterSystem::parameters;
> > 
> 
> Nice surprise! We should start using this in the demo programs to allow
> users to change parameters without recompiling.

Yes, but one thing to think about is how many parameters we need to
set. If you export the current list of parameters, you will get all
parameters in the data base, even those which have default values. We
probably should just include the ones that differ from the defaults.

> > > -projections onto different meshes.
> > 
> > I discussed this with Johan H last week. I would very much like to be
> > able to do this, which is really necessary to be able to do any kind
> > of adaptivity (at least when the mesh changes from one time step to
> > the next).
> > 
> > The problem with this one is that it connects to the mesh and we are
> > still waiting for Sieve... and then we need to reimplement much of the
> > functionality for the mesh anyway.
> >
> > The following seems to be a list of priorities for the near future (in
> > no particular order):
> > 
> >  1. General boundary conditions including Neumann
> >  2. Reimplement mesh classes based on Sieve
> >  3. Projections between meshes
> >  4. Parallel assembly
> >  5. Non-affine elements
> >  6. Finish up manual
> >  7. Finish up ODE solvers
> >  8. Finish up PyDOLFIN, including JIT compilation
> > 
> > I hope I will be able to finish 7 this week or the next.
> > 
> 
> At the first pass I read "I hope I will be able to finish *up to* 7 this
> week or the next", and was very impressed!

It might be physically possible, but I doubt it... :-)

> > To do 2-3-4, we need to ask Matt and Dmitry what is happening to
> > Sieve and when we might expect the first release.
> > 
> > Let's discuss these points to get a list of priorities. Then we start
> > at the top of the list and get down to work. It would be great if we
> > could get dedicated effort from everyone. I think we should be able to
> > make quick progress.
> > 
> 
> My priorities at the moment are are (1) and (5). This is driven by the
> problems I'm considering at the moment, not any altruistic sentiments.
> 
> I haven't included (2) and (3) because it depends on when Sieve is
> ready, and (4) is largely dependent on (2). Having (4) will be really
> great! Projections between meshes would be great too, but I see this
> being a large undertaking.

It seems that we might want to start with (1) and then do 2-3-4 when
Sieve is released.

I expect implementing (1) on both the FFC and DOLFIN sides would take
me a week to finish if I didn't have anything else on my hands. Who
wants to help?

> What's the best approach with the manual? I get the feeling that the
> code development was (and perhaps still is) moving too fast for the
> manual to keep up. Is it worth spending a lot of time on it yet?
> 
> Garth

I think we are stable enough to write up the chapters on linear
algebra and PDEs. Things may change but changes will probably mostly
be additions of new features, like the new automatic solution of PDEs.
The basic structure will probably remain the same: BilinearForm,
LinearForm, FEM::assemble() etc.

/Anders