dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> 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?

I think this is a first priority as well. I can help, I have some time
next week, and possibly some this week.

/Johan


>
>> 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
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>