Re: using sympy for a lightweight FE module
Robert Cimrman
So it seems that several people at the same time feel that sympy would
be good for generating FE bases at least, in terms of either tabulated
data in common sets of quadrature points, or a generated C(++) code, to
be re-used later. Thanks for sending your code. I think we could start a
new project (at googlecode?) using your code as a good start. Are you ok
with a BSD license?
r.
kent...@simula.no wrote:
> Robert Cimrman wrote:
>> Hi Kent,
>>
>> [this message follows your post to sympy list]
>>
>> as you may remember, about a year ago I wanted to use SyFi as a FE
>> engine for my python FE code (SFE). But I had become distracted by other
>> work, implementing into the code the (bio)mechanical models that we
>> develop at our lab. The code, meaning the FE stuff like base function
>> evaluation etc. was 'good enough' for that purpose already and I had not
>> have time to really dig into SyFi and understand it.
>>
>> But now I am starting a revamp of base of the code and thought of
>> writing a lightweight FE module in pure Python using sympy, which would
>> symbolically compute the bases for various approximations and reference
>> elements, their derivatives and evaluated them at quadrature points as
>> needed.
>>
>> Again, I am probably too late :-) and you at your lab already try sympy
>> exactly for that purpose. But I ask you nevertheless: would you be
>> interested in developing/releasing such a module as a stand-alone
>> project, independent of anything but sympy? I would gladly participate
>> in it. I will start using sympy in SFE anyway, but having more hands
>> working together on a common subject would be much better.
>>
>
>
> Hi Robert, nice to hear from you again.
>
> I've been curius about sympy. I am implementing Lagrangian methods now
> in sympy as a simple starting point, but it seems that sympy is to slow
> for many of my purposes. I will post the code to the sympy mailing-list
> in a few
> days. It may be that the sympy developers can address the efficiency. In a
> typical (small) example (for me) GiNaC is of order 100+ more efficient
> than sympy.
>
> At present, I will make a small module with Lagrangian elements. I'll send
> you the code. Other than that I think sympy is to slow.
> But I like sympy, it is nice to use and has lots of good stuff.
>
> Kent
>
>
>
Ondrej Certik
> be good for generating FE bases at least, in terms of either tabulated
> data in common sets of quadrature points, or a generated C(++) code, to
> be re-used later. Thanks for sending your code. I think we could start a
> new project (at googlecode?) using your code as a good start. Are you ok
> with a BSD license?
Yes, let's do that. However, there should be a leader, who will push
things forward and make sure it is coordinated. Is anyone willing to
do it?
Yes, I actually prefer BSD to GPL, especially now with those GPL 2 and
GPL3 incompatibility.
What name to use - SymFEM? It needs to be a name, that is easy to
google, symfem is.
How about calling sympy by default, so that it works in pure python
(easy to install, works on windows/linux/mac os x for free), and
calling swiginac optionally for speed? And also trying to speed sympy
up (my bet is on Cython[1]). This means converging with the interface
of swiginac and sympy. Since I am a coauthor of both, it shouldn't be
that difficult.
But swiginac is now under the hood of Ola Skavhaug, I didn't really
touch it for two years - but I think Ola will also be interested in
that (CCing him)? See related posts to sympy mailinglist[2].
Ondrej
[1] http://cython.org/
[2]
http://groups.google.com/group/sympy/browse_thread/thread/cdf44eebad6c1237
http://groups.google.com/group/sympy/browse_thread/thread/f73b00d1bdf0255a
Kent-Andre Mardal
> > So it seems that several people at the same time feel that sympy would
> > be good for generating FE bases at least, in terms of either tabulated
> > data in common sets of quadrature points, or a generated C(++) code, to
> > be re-used later. Thanks for sending your code. I think we could start a
> > new project (at googlecode?) using your code as a good start. Are you ok
> > with a BSD license?
> Yes, let's do that. However, there should be a leader, who will push
> things forward and make sure it is coordinated. Is anyone willing to
> do it?
>
> Yes, I actually prefer BSD to GPL, especially now with those GPL 2 and
> GPL3 incompatibility.
>
> What name to use - SymFEM? It needs to be a name, that is easy to
> google, symfem is.
>
> How about calling sympy by default, so that it works in pure python
> (easy to install, works on windows/linux/mac os x for free), and
> calling swiginac optionally for speed? And also trying to speed sympy
> up (my bet is on Cython[1]). This means converging with the interface
> of swiginac and sympy. Since I am a coauthor of both, it shouldn't be
> that difficult.
> But swiginac is now under the hood of Ola Skavhaug, I didn't really
> touch it for two years - but I think Ola will also be interested in
> that (CCing him)? See related posts to sympy mailinglist[2].
>
I am happy with the BSD license.
What we do now in the fenics projects ffc, fiat and syfi is that
based on a python description of a finite element method we generate
C++ code. Furthermore, this C++ code is then wrapped by SWIG and then
imported into python again for assembly etc. The compilation happens
behind the scene so the user do not need to case about it. This seems
to be a reasonably efficient approach. What do you do ?
Kent
Robert Cimrman
>> So it seems that several people at the same time feel that sympy would
>> be good for generating FE bases at least, in terms of either tabulated
>> data in common sets of quadrature points, or a generated C(++) code, to
>> be re-used later. Thanks for sending your code. I think we could start a
>> new project (at googlecode?) using your code as a good start. Are you ok
>> with a BSD license?
>
> Yes, let's do that. However, there should be a leader, who will push
> things forward and make sure it is coordinated. Is anyone willing to
> do it?
I have started nagging about making the project, but so far I am not
very familiar neither with sympy nor with swiginac... However I can
setup a project at googlecode, if you want.
> Yes, I actually prefer BSD to GPL, especially now with those GPL 2 and
> GPL3 incompatibility.
Kent agreed, so be it BSD.
> What name to use - SymFEM? It needs to be a name, that is easy to
> google, symfem is.
I like it. Maybe only SymFE?
> How about calling sympy by default, so that it works in pure python
> (easy to install, works on windows/linux/mac os x for free), and
> calling swiginac optionally for speed? And also trying to speed sympy
> up (my bet is on Cython[1]). This means converging with the interface
> of swiginac and sympy. Since I am a coauthor of both, it shouldn't be
> that difficult.
> But swiginac is now under the hood of Ola Skavhaug, I didn't really
> touch it for two years - but I think Ola will also be interested in
> that (CCing him)? See related posts to sympy mailinglist[2].
This would be great, but it should not be too visible to user (=me :-)
The less _required_ dependencies the better.
r.
Ondrej Certik
---------- Forwarded message ----------
From: Ola Skavhaug <skav...@simula.no>
Date: Nov 26, 2007 1:00 PM
Subject: Re: using sympy for a lightweight FE module
To: Ondrej Certik <ond...@certik.cz>
Cc: sy...@googlegroups.com, kent...@simula.no, Ola Skavhaug
<skav...@simula.no>
Ondrej Certik skrev den 26/11-2007 følgende:
> > So it seems that several people at the same time feel that sympy would
> > be good for generating FE bases at least, in terms of either tabulated
> > data in common sets of quadrature points, or a generated C(++) code, to
> > be re-used later. Thanks for sending your code. I think we could start a
> > new project (at googlecode?) using your code as a good start. Are you ok
> > with a BSD license?
>
> Yes, let's do that. However, there should be a leader, who will push
> things forward and make sure it is coordinated. Is anyone willing to
> do it?
>
> Yes, I actually prefer BSD to GPL, especially now with those GPL 2 and
> GPL3 incompatibility.
>
> What name to use - SymFEM? It needs to be a name, that is easy to
> google, symfem is.
>
> How about calling sympy by default, so that it works in pure python
> (easy to install, works on windows/linux/mac os x for free), and
> calling swiginac optionally for speed? And also trying to speed sympy
> up (my bet is on Cython[1]). This means converging with the interface
> of swiginac and sympy. Since I am a coauthor of both, it shouldn't be
> that difficult.
> But swiginac is now under the hood of Ola Skavhaug, I didn't really
> touch it for two years - but I think Ola will also be interested in
> that (CCing him)? See related posts to sympy mailinglist[2].
>
Hi sympy team,
I'm interested in this issue, and as Kent-Andre Mardal sits approx. 150cm
from my office, we are quite synchronized. Actually, since the sympy license
is less restrictive than that of GiNaC, I'm considering using sympy as backend
to some of my software instead of swiginac.
Defaulting to a cross platform backend sounds resonable, although it currently
comes at the price of performance.
Ideally, the only syntax difference in sympy and swiginac should be the import
statement. Today, this is not 100% the case. Perhaps we should have a
discussion regarding this issue? It would be possible to add a wrapper layer
in Python layer a-la Symbolic, but I don't think it makes enough sense to
justify the cost of maintenance. There will always be differences in the set
of provided features, but it would be nice if the intersection in
functionality shared a common syntax (and semantics).
Ola
Ondrej Certik
>
> I'm interested in this issue, and as Kent-Andre Mardal sits approx. 150cm
> from my office, we are quite synchronized. Actually, since the sympy license
> is less restrictive than that of GiNaC, I'm considering using sympy as backend
> to some of my software instead of swiginac.
>
> Defaulting to a cross platform backend sounds resonable, although it currently
> comes at the price of performance.
There is also a sympycore project, done be Pearu and Fredrik, which
tries new approaches to speed SymPy up, still in pure Python.
Is Pearu also sitting 150cm from your office? :)
> Ideally, the only syntax difference in sympy and swiginac should be the import
> statement. Today, this is not 100% the case. Perhaps we should have a
> discussion regarding this issue? It would be possible to add a wrapper layer
Yes.
> in Python layer a-la Symbolic, but I don't think it makes enough sense to
> justify the cost of maintenance. There will always be differences in the set
> of provided features, but it would be nice if the intersection in
> functionality shared a common syntax (and semantics).
Agree, the common syntax should be the same. There is another project,
SAGE, and I also would like to have the same syntax with them, if
possible.
So let's create the SymFE, calling both swiginac and sympy as a
backend, and then we will see exactly which syntax things needs to be
fixed.
> > Yes, let's do that. However, there should be a leader, who will push
> > things forward and make sure it is coordinated. Is anyone willing to
> > do it?
>
> I have started nagging about making the project, but so far I am not
> very familiar neither with sympy nor with swiginac... However I can
> setup a project at googlecode, if you want.
Setting up a project on googlecode is the least thing. :) I meant,
that the leader needs to be motivated for the project to succeed and
push it forward.
But let's just create the project for now and try it. If you do it,
add me as a member please.
> > What name to use - SymFEM? It needs to be a name, that is easy to
> > google, symfem is.
>
> I like it. Maybe only SymFE?
Sounds good to me.
> > How about calling sympy by default, so that it works in pure python
> > (easy to install, works on windows/linux/mac os x for free), and
> > calling swiginac optionally for speed? And also trying to speed sympy
> > up (my bet is on Cython[1]). This means converging with the interface
> > of swiginac and sympy. Since I am a coauthor of both, it shouldn't be
> > that difficult.
> > But swiginac is now under the hood of Ola Skavhaug, I didn't really
> > touch it for two years - but I think Ola will also be interested in
> > that (CCing him)? See related posts to sympy mailinglist[2].
>
> This would be great, but it should not be too visible to user (=me :-)
> The less _required_ dependencies the better.
Yes. The python will be default for sure in SymPy. It's just pain to
compile anything. But optionally it would be nice. I think I am
talking about this too much, talk is cheap. I should try to do some
easy arithmetics stuff in Cython now, to see if it really speeds
things up.
> I am happy with the BSD license.
>
> What we do now in the fenics projects ffc, fiat and syfi is that
> based on a python description of a finite element method we generate
> C++ code. Furthermore, this C++ code is then wrapped by SWIG and then
> imported into python again for assembly etc. The compilation happens
> behind the scene so the user do not need to case about it. This seems
> to be a reasonably efficient approach. What do you do ?
Yes, this seems reasonable. So why is there any need to do it in
SymPy? Is the motivation to be in pure Python? I would like to
understand the motivation better.
As I said, I myself use libmesh for now. Byt the syfi approach is new,
and if you say it speeds things up, well, I am for it. :)
Ondrej
Robert Cimrman
>> from my office, we are quite synchronized. Actually, since the sympy license
>> is less restrictive than that of GiNaC, I'm considering using sympy as backend
>> to some of my software instead of swiginac.
>>
>> Defaulting to a cross platform backend sounds resonable, although it currently
>> comes at the price of performance.
>
> There is also a sympycore project, done be Pearu and Fredrik, which
> tries new approaches to speed SymPy up, still in pure Python.
> Is Pearu also sitting 150cm from your office? :)
Well, I sit probably less than 100km from yours :)
>> Ideally, the only syntax difference in sympy and swiginac should be the import
>> statement. Today, this is not 100% the case. Perhaps we should have a
>> discussion regarding this issue? It would be possible to add a wrapper layer
>
> Yes.
>
>> in Python layer a-la Symbolic, but I don't think it makes enough sense to
>> justify the cost of maintenance. There will always be differences in the set
>> of provided features, but it would be nice if the intersection in
>> functionality shared a common syntax (and semantics).
>
> Agree, the common syntax should be the same. There is another project,
> SAGE, and I also would like to have the same syntax with them, if
> possible.
I like the 'ideally' case, but for the moment having a single layer of
wrapper code using the sympy syntax should be ok.
> So let's create the SymFE, calling both swiginac and sympy as a
> backend, and then we will see exactly which syntax things needs to be
> fixed.
ok, I will create SymFE project. Does anybody have a nice summary?
>>> Yes, let's do that. However, there should be a leader, who will push
>>> things forward and make sure it is coordinated. Is anyone willing to
>>> do it?
>> I have started nagging about making the project, but so far I am not
>> very familiar neither with sympy nor with swiginac... However I can
>> setup a project at googlecode, if you want.
>
> Setting up a project on googlecode is the least thing. :) I meant,
> that the leader needs to be motivated for the project to succeed and
> push it forward.
> But let's just create the project for now and try it. If you do it,
> add me as a member please.
Having a name and a place to work at is half of the success... Anyone
else wants to be added as member?
> As I said, I myself use libmesh for now. Byt the syfi approach is new,
> and if you say it speeds things up, well, I am for it. :)
When I first saw syfi, I was really excited about its approach (and yes,
I still am).
r.