dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #03938
Re: DOLFIN-stable
> I think so.
>
> I don't think a special --disable-modules will be necessary.
> But we will need the following targets:
>
> make modules
> make modules_install
>
> Then if one likes, one may enter into src/modules/demo and do
>
> make
Sounds good.
> One problem I have is that just moving demo, bench, test for modules
> into src/modules makes a very flat structure, with navierstokes at the
> same level as the demo for navierstokes. Perhaps we could have
>
> src/modules/
> src/modules/solvers
> src/modules/solvers/navierstokes
> src/modules/solvers/elasticity
> src/modules/solvers/plasticity
> src/modules/demo
> src/modules/bench
> src/modules/test
>
> This could open up for creating other kinds of modules that are not
> necessarily solvers.
The modules seem not that specified right now, and naming a module after a
certain equation may not be that good, for example since a typical module
may be multi-physics based, or several methods may be used for solving the
same equation. Also, I do not think the /modules/solvers level is needed,
it should be enough with /modules. And I'm not sure that we need to have a
separate level for classifying the type of modules either (flow, solid,
etc.)
I think we should have src/modules, where we today can put modules that
are maintained (navierstokes, elasticity,...), in a flat structure, and
the naming could be quite free: "fluid-structure-interaction-solver",
"fsi-flash", "heart", or whatever reasonable (where maybe not *-falsh
would qualify...).
/Johan
> /Anders
>
>
> On Tue, Dec 05, 2006 at 01:50:00PM +0100, Garth N. Wells wrote:
>> Did we reach a consensus on moving everything module-related (including
>> module demos) to /src/modules/ and adding a make target "make modules"?
>>
>> Garth
>>
>> Johan Jansson wrote:
>> > I've created a branch of DOLFIN called DOLFIN-stable. Since every
>> > repository (every time you clone for example) is also a branch, this
>> > is nothing dramatic. The only difference is that this branch is
>> > publically available in the same way as DOLFIN is.
>> >
>> > The purpose of this branch is to keep the kernel stable. The only
>> > kernel changes allowed are backports of bugfixes and possibly
>> > important overlooked functionality from the DOLFIN
>> > repository.
>> >
>> > However, module changes are allowed as before. Kernel development is
>> > supposed to happen in the DOLFIN repository (where applications need
>> > to be stable to test the kernel) and application development is
>> > supposed to happen in the DOLFIN-stable repository (where the kernel
>> > needs to be stable to test the application).
>> >
>> > At regular intervals (at least at DOLFIN releases), the DOLFIN and
>> > DOLFIN-stable branches will be merged. Thus the DOLFIN and
>> > DOLFIN-stable branches will be equivalent at the time of every
>> > release.
>> >
>> > If the modules/applications are eventually detached into a separate
>> > repository, then the dual purpose of DOLFIN-stable might not be
>> > necessary any more.
>> >
>> > 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
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
Follow ups
References