fenics team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxxx>]

I agree that there will always this "now & then" paradox to live with.
There will also be various constraints on all people involved, naturally
resulting in different focus for the different participants in FEniCS, and
therefore I think it is very important to keep the format of FEniCS open.
Users of DE solvers will benefit from the (hopefully) inventive components
avaliable, and the developers of new components will also benefit from
having a "reasonably complete" system with a common interface to use as
front- and backends of there components.

It seems reasonable that the various FEniCS components avaliable for
download at the homepage (today: DOLFIN,FFC,FIAT,Ko,Puffin) are compatible
in terms of interfaces, which is the case today. Apart from that, together
with compatible licenses of some form, I think further restrictions should
be kept to a minimum.

I do not think that we today should worry too much about "selling" FEniCS,
or the different components of FEniCS.

/Johan


> Let me clarify a couple of things about what I said:
>
>> 2.) research/new ideas.  For me, FEniCS is about new ideas about
>> finite element computation rather than a big development push.   It's
>> not just about getting code, it's about figuring out the mathematics
>> of the code (not the mathematics of the numerical method).
>
> Of course we need code -- maybe "get the ideas right first, then do a
> push to implement them," would be better.  This relates to another
> paradox which I present:
>
> "now & then"
>
> "Now":
> There are people relying on certain codes to produce results today.
> Implications: 1.) reuse everything you can because time you spend
> redeveloping is time you don't spend getting results. 2.) teaming up on
> a code that gets results gets more results sooner.  3.) One must
> present a clear and compelling reason for redevelopment of existing
> pieces (even if they have certain quirks and undesirable features).
>
> The danger is in being short-sided and stifling innovation.
>
> "Then":
> What will be the "next big thing"?  How are we going to (perhaps both
> and) improve Sundance/DOLFIN/etc and design a (code OR collection of
> codes) that will be vastly superior in terms of user interface,
> extensibility, algorithmic elegance and efficiency, etc.
> Implications: 1.) results today don't matter as long as we'll get the
> next big thing eventually.  2.) Reuse of existing code is deemphasized.
> 3.) You get to do just what you want and form everything just the way
> you would have it.
>
> The danger is in thinking "I can do it better" repeating quality work
> other people have done from slightly different perspectives.  You also
> will have to convince people that what you have done really *is* better
> although other things that were quicker to the punch have become
> ingrained standards that people are hesitant to stray from because they
> work.
>
>
>
>> getting data from FFC, etc.  But unless I have a new mathematical
>> theory of log systems that follows from the Masur Separation Theorem,
>
> Log systems are very important and useful, but we have ones existing.
> I have no ideas on how to make them any better and therefore will not
> write one.  I would say similar things about build systems, although I
> know some of us have very strong opinions (and implementations) about
> how they can be better.  I encourage such research.
>
>
>> 3.) My disposition in research anyway seems to be to come up with
>> elegant formulations of "little" problems (e.g. FIAT, FErari) that
>> seem very important.  Hopefully these little pieces can make bigger
>> projects better.
>
> I see this as a way to have a foot in both "now" and "then".  Research
> is a long process.  I can't do everything -- it's good to have results
> that are making present impacts.  It's good to have ideas that might
> pan out in the future.
>
> Rob
>
> _______________________________________________
> fenics-dev mailing list
> fenics-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/fenics-dev
>


-- 
Johan Hoffman, PhD
Assistant Professor
School of Computer Science and Communication
Royal Institute of Technology KTH
SE-100 44 Stockholm
Sweden

Email: jhoffman@xxxxxxxxxxx
URL: www.nada.kth.se/~jhoffman