> Date: Thu, 30 May 2013 09:47:27 +0200
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> Subject: Re: [FEniCS] FEM LIBRARY WITH OCTAVE
>
> On Thu, May 30, 2013 at 09:42:12AM +0200, Martin Sandve Alnæs wrote:
> > On 30 May 2013 09:34, Johan Hake <[1][email protected]> wrote:
> >
> > Hi Marco!
> > DOLFIN use SWIG to create Python wrappers. SWIG provides Octave
> > wrappers
> > too. Are you going to use those?
> > [2]http://www.swig.org/Doc2.0/SWIGDocumentation.html#Octave
> > SWIG use a flat namespace for the generated wrapper code, so you
> > would
> > still have nameclashes for the Array class. However it will
> > internally
> > keep all original C++ type information. SWIG also allows you to
> > rename
> > any C++ entity, classes, functions, variables, methods, aso, to
> > whatever
> > in the target language. You can then just tell SWIG to rename the
> > dolfin::Array to, let say, dolfin::ArrayDolfin.
> > Another challenge you might consider before you invest too much is
> > to
> > figure out how you should integrate the code generation part of
> > FEniCS.
> > For now that is handled by the Python packages of FFC, FIAT, UFL,
> > and
> > parts of UFC. Because these are all in Python we have been able to
> > integrate these seamlessly (but not without bumps) with the Python
> > interface of DOLFIN.
> >
> >
> > Doing this within octave will be challenging.
> >
> > To say the least... I'd say it's close to impossible to get the same
> > level of integration with just in time compilation as we have in
> > python.
> > However if it's possible to wrap pregenerated forms (i.e. header files
> > generated by running ffc on the commandline) it could be useful to
> > assemble matrices directly in octave for analysing eigenvalues etc. In
> > some older internal code here at Simula we had the concept of a "matrix
> > factory" which could assemble common matrices from a number of
> > pregenerated form files, e.g. mass, stiffness, convection etc.
>
> A matrix factory approach sounds like a very good fit for Octave. I
> suggest using that approach and implementing an extensive list of
> "finite element matrices" for various degrees of polynomials and
> possibly different element families.
>
That sounds really good to me, I start with this idea.
> An alternative, if you can live with calling Python from within the
> internals of your Octave package, would be to work with strings that
> are passed to Python. So you could do something like
>
> mesh = <some Octave data structure for a mesh like (p, e, t)>
> A = fem_matrix("dot(grad(u), grad(v))*dx, mesh, "P1")
>
Yeah, it will be nice to allow the user defining some new
variational forms.
I solved my first problem (the conflict between the "Array" class of Octave
and Fenics) simply including the dolfin header (which hopefully has a
namespace as you said) before the octave header.
So now with
#include < dolfin.h>
#include < oct.h>
the code works, while using
#include < dolfin.h>
#include < oct.h>
code crashes (Octave hasn't a namespace)
Marco
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
