← Back to team overview

dolfin team mailing list archive

Re: Removing modules?

 

> On Mon, Apr 23, 2007 at 02:21:59PM +0200, Johan Jansson wrote:
>> >> On Sat, Apr 21, 2007 at 07:42:39PM +0200, Garth N. Wells wrote:
>> > Yes, maybe this is the natural thing, although I'd say think that it
>> may
>> > be useful to keep one or two simple modules for demo and testing of
>> new
>> > functionality in the dolfin kernel. Although, a simpler structure
>> would be
>> > to put these demo-solver under src/demo, and remove src/modules.
>> >
>> > Then these simple modules could have the double role of demos and test
>> for
>> > new functionality. Or alternatively keep them under src/test.
>>
>> I think the solvers and applications under src/demo are sufficient for
>> testing DOLFIN, and there is no reason to keep the modules structure.
>>
>> >>> In terms of maintenance, most modules are even less likely to be
>> >>> maintained if they are spun off into a separate package. What about
>> >>> just
>> >>> letting individuals make modules available? Module developers
>> closely
>> >>> involved with FEniCS project could publish their modules under
>> >>> http://www.fenics.org/dev/, and others could place them on their own
>> >>> web
>> >>> pages, with links from www.fenics.org.
>> >
>> > To publish ones own modules on ones homepage is of course available
>> for
>> > anyone, and should be encouraged.
>> >
>> > For our group, if the modules are taken out of dolfin I lean towards
>> > publish our flow/fsi modules as a new fenics project under
>> www.fenics.org,
>> > focused on developing a generalized ALE solver for turbulent
>> > incompressible/compressible fluid-structure interaction. These modules
>> are
>> > videly used at KTH and are very well maintained and are developing
>> > rapidly, so this would be a FEniCS project that I expect would
>> generate a
>> > lot of interest and participation also outside KTH, which I got strong
>> > indications of when this was last brought to discussion last fall.
>>
>> Yes, I think it's very important to keep a focus on applications. FEniCS
>> development is primarily driven by applications, and thus it's necessary
>> that FEniCS has strong applications.
>
> I'd say FEniCS development is primarily technology driven (which may
> be good or bad) but we need both (technology + applications).
>
> /Anders

I agree that we need both. But I think the applications angle is missing
in FEniCS today. Therefore our group will take on the responsibility to
launch a new project in this direction, aimed at the FEniCS vision from a
top-down perspective; starting from advanced applications, and identifying
common abstractions.

The project will initially be based on our Dolfin FSI solver, as a
prototype for a general computational continuum mechanics solver. I'll
send out a note on fenics-dev, where I think this discussion belongs.

/Johan


>> If we want to keep a focus on the FEniCS applications, I don't think a
>> page with scattered modules is a very good method. The modules structure
>> has also not been the driver of shared development that was the intent.
>>
>> So I also think the natural step is to create a FEniCS project that
>> develops automated applications. The aim would be to identify common
>> methods that are implemented manually and reformulate the
>> method/implementation in a general setting.
>>
>>   Johan
>>
>>
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>




Follow ups

References