fenics team mailing list archive
-
fenics team
-
Mailing list archive
-
Message #00027
Re: Re: FEniCS
-
To:
Anders Logg <logg@xxxxxxxxx>
-
From:
Matthew Knepley <knepley@xxxxxxxxxxx>
-
Date:
Mon, 26 Sep 2005 22:00:37 -0500
-
Cc:
Discussion of FEniCS development <fenics-dev@xxxxxxxxxx>
-
In-reply-to:
<20050927024957.GC835@galerkin> (Anders Logg's message of "Mon, 26 Sep 2005 21:49:57 -0500")
-
User-agent:
Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
Anders Logg <logg@xxxxxxxxx> writes:
> On Mon, Sep 26, 2005 at 08:43:29PM -0500, Matthew Knepley wrote:
>> "tomtzigt" <tomtzigt@xxxxxxxxxxxxxxxx> writes:
>> > Another sobering statistics is that for every line of code in the main
>> > branch there are three lines of code needed in the infrastructure (build
>> > system, regression system, QA, release engineering, etc.). The bigger your
>> > system gets the more inertia the support system exerts on the core. Given
>> > these statistics, and limited resources, you are effectively forced to
>> > concentrate on doing few problems well. But you can expand your world of
>> > influence by 'solving' integration problems with other efforts. This has a
>> > secondary benefit and that is that trying to solve the integration problem
>> > you get a close up view of another 'interpretation' of the same problem:
>> > both in terms of software engineering as well as in mathematics. This
>> > experience is very valuable and is gained in much less time then if you had
>> > to do the whole package yourself. As the saying goes: A fool learns from his
>> > own mistakes, but a genius learns from mistakes other people make.
>>
>> While this might convince a lot of people that configure, build, and packaging
>> are inherently complex, I believe that no real hard thinking has been put into
>> these components. Instead, we see slavish reproduction of what shuold have been
>> throw away ideas and prototypes. Witness the longevity and dominance of make.
>> Hopefully we have the courage to reinvent these broken systems in the same way
>> that we plan to reinvent numerics. To reiterate, I do not believe that WE need
>> to concentrate on a few problems, unless by that you mean first order nonlinear
>> PDEs. We should allow anyone to easy construct and solve these. Its important
>> to motivate ourselves with problems, but not to make them the focus of the system.
>
> I agree, and we should probably give BuildSystem a shot at some point.
>
> Matt, are you pushing it actively (web page, manual etc)?
^^^ I'm too mathy
I do have a partial manual, but of course it would benefit from others work. I
just got back from SciPy '05 and there was a lot of interest. Particularly from
the matplotlib guy John Hunter, who incidentally is at U of C medical. I definitely
will bring this tpoic up at FEniCS '05, and maybe I should give a talk on it.
Barry said he was trying to come, and I am going to talk to Paul Hovland as well.
Matt
--
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness
Follow ups
References