dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #03857
Re: Modules
Quoting Anders Logg <logg@xxxxxxxxx>:
> This would effectively be the same as having the modules in a separate
> source tree (since we have separate demo, test and bench).
>
> Then it would also make sense to have them in a separate tree, as long
> as someone wants to maintain the separate tree.
>
> The amount of work would increase, so a separate tree only makes sense
> if someone else is willing to do the work.
>
I see putting everything module-related under src/modules as a way to give the
modules a degree of independence without introducing the need to maintain a
separate tree, thus avoiding the work involved. It would also be a good time to
introduce some basic tests for the modules.
> If not, I like the idea of putting everything module-related in
> src/modules/.
>
Is this a positive or a negative reaction :)?
> Should we have make modules modules_install modules_demo modules_bench
> etc or should one enter into src/modules and do make etc from there?
>
Not sure what's best.
Garth
> We would also need to put the swig interface into src/modules.
>
> We could also have modules that are only Python-based.
>
> /Anders
>
>
> On Thu, Nov 30, 2006 at 02:47:03PM +0100, Garth N. Wells wrote:
> > What about moving src/demo/solvers to src/modules/demo, and giving more
> > structure to the module directory and making them more descriptive, e.g.
> >
> > src/modules/flow/incompressible_nse
> > src/modules/flow/compressible_nse
> >
> > src/modules/solid/elasticity
> > src/modules/solid/plasticity
> >
> > src/modules/mesh/. . . .
> > src/modules/misc/. . . .
> > .
> > .
> > src/modules/test/. . . . (tests for modules)
> > src/modules/bench/. . . . (benchmarks for modules)
> >
> > src/modules/demo/. . . .
> >
> > For example, there is a module "navierstokes" (which is working very
> > nicely now), but there are different approaches to solving the Navier
> > Stokes equations depending on the regime of interest.
> >
> > This way the modules are kept together and are relatively self-contained
> > (on top of the kernel) but remain with DOLFIN.
> >
> > Garth
> >
> >
> > Johan Hoffman wrote:
> > >> Then I think we should also have demo, test, bench at the top and just
> > >> keep the library in src (removing kernel).
> > >
> > > Could make sense.
> > >
> > >> Is that a good idea?
> > >
> > > I do not know.
> > >
> > >> I would also not object putting the modules in a separate source tree,
> > >> but then I'd like someone to maintain the modules (anyone from KTH?)
> > >> with an identical release schedule as for DOLFIN and identical version
> > >> numbers.
> > >
> > > Wasn't that what you did not want a month back? I thought we agreed on
> > > that it would not benefit DOLFIN to extract the modules. What Garth
> > > suggests I think is something different, less dramatic.
> > >
> > > /Johan
> > >
> > >
> > >> /Anders
> > >>
> > >>
> > >> On Thu, Nov 30, 2006 at 08:46:39AM +0100, Garth N. Wells wrote:
> > >>> What if we move the modules (and module demos) out of the DOLFIN
> source
> > >>> tree and have
> > >>>
> > >>> src/ . . .
> > >>>
> > >>> and
> > >>>
> > >>> modules/solvers/ . . .
> > >>> modules/demo/ . . .
> > >>>
> > >>> We can give more prominence to the modules (as we've discussed
> before),
> > >>> and encourage people to contribute modules by promoting them more as
> > >>> "attachements" to DOLFIN.
> > >>>
> > >>> Garth
> > >>>
> > >>> Anders Logg wrote:
> > >>>> On Wed, Nov 29, 2006 at 09:58:26PM +0100, Garth N. Wells wrote:
> > >>>>> Sounds good. "make demo" won't necessarily work if the modules
> > >>> haven't
> > >>>>> been built though.
> > >>>>>
> > >>>>> An alternative if a configure flag --enable/disable-modules.
> > >>>> That will have the same effect (not being able to build module
> demos).
> > >>>>
> > >>>> Perhaps we could have a flag make_module_demos, but maybe we should
> > >>>> try to keep the number of targets down?
> > >>>>
> > >>>> /Anders
> > >>>>
> > >>>>
> > >>>>> Garth
> > >>>>>
> > >>>>> Anders Logg wrote:
> > >>>>>> I'm suggesting to add the following new make targets:
> > >>>>>>
> > >>>>>> make modules
> > >>>>>>
> > >>>>>> and
> > >>>>>>
> > >>>>>> make modules_install
> > >>>>>>
> > >>>>>> As it is now, compiling the modules takes a considerable time of
> the
> > >>>>>> build process and we have quite a number of users on Simula that
> > >>>>>> are only interested in building the kernel.
> > >>>>>>
> > >>>>>> Any objections?
> > >>>>>>
> > >>>>>> /Anders
> > >>>>>> _______________________________________________
> > >>>>>> 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
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >
> >
> >
> > _______________________________________________
> > 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