fenics team mailing list archive

[Robert C. Kirby <kirby@xxxxxxxxxxxx>]

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