Hi,
GSoc 2008 is on, see http://code.google.com/soc/2008.
Ondra, you have experience with the last GSoC, do you think we could
succeed? I could be someone's mentor...
I think we could use some support for our development.
r.
Hi,
eigen.py works again, now with the new mesh io stuff. BTW, the
progressbar is great!
r.
ps: friday is ok to go to the pub (http://www.thepub.cz/) :)
Hi,
I put my code at:
http://code.google.com/p/sfepy/issues/detail?id=17
Let's discuss how to best integrate it in sfepy. The main code is in:
geom/meshutils.py
which converts to/from a lot of formats. It's quite long though and
all in one class. My plan was to create a new class for each
output/input format.
So let's create some basic mesh classes, for example based on the code
in sfe/fem/mesh.py. Then I'll just subclass it, implement some
output/input and that's it.
Another problem: how can I select some part of the geometry and assign
a special boundary condition to it? In sfepy, as I understand it, it's
handled by assigning a special number to each
element (tetrahedron), but how can I generate such a mesh? It's not a
business of sfepy. But generally I need to create a geometry (for
example in gmsh), tell gmsh to mark some surface with a number.
Then it is passed to tetgen, that is clever enough to assign this
number to each element in the output. So all I need is to parse the
output of tetgen and print the element numbers to a file for example.
Sometimes, I not only need the element IDs, but I also need the set of
nodes sitting at a surface. All these features are implemented in the
patch attached to the issue 17.
In my older FEM code, I simply read this file and assigned a correct
BC to the elements in this file. How is this handled by sfepy?
I think sfepy can do some things that is in the patch, but probably
cannot do all of them. So let's merge it. I am waiting for your
suggestions and ideas. ;)
Ondrej
Hi,
time dependent problems are now supported by simple.py.
Check input/time_poisson.py and tests/test_input_time_poisson.py.
It is an initial attempt, so expect bugs and no docstrings...
r.
Hi,
I have a question regarding tests - do some of them actually test for
a correctness? It seems to me, that most of them only test, if sfepy
runs for the given input and mesh, but we should also test, that the
result of the calculation is actually correct. For example when I
polish the schrodinger solver, the simple test is to check that all
the energies are correct.
For example this one:
tests/test_quadratures.py
Does it test for a correctness? It seems to me, that this code
def test_problemCreation( self ):
from sfe.solvers.generic import solveStationary
problem, vec, data = solveStationary( self.conf )
ok = True
return ok
Always returns "ok", no matter what was returned in vec and data.
Ondrej
Hi,
To make sfepy work with the latest released scipy, use this patch:
diff --git a/sfe/solvers/ls.py b/sfe/solvers/ls.py
--- a/sfe/solvers/ls.py
+++ b/sfe/solvers/ls.py
@@ -1,7 +1,7 @@ from sfe.base.base import *
from sfe.base.base import *
from sfe.solvers.solvers import LinearSolver
-import scipy.splinalg.dsolve.umfpack as um
+import scipy.linsolve.umfpack as um
um.configure( assumeSortedIndices = True )
##
However, today I discovered problems when using sfepy on amd64 (Debian):
It compiles fine, but:
$ ./schroedinger.py input/schroed.py
warning: other missing: ['functions', 'modules', 'epbc', 'lcbc']
warning: left over: ['funV', 'options']
mesh.read = 0.04
mesh.split = 0.0
t = 0.0
Traceback (most recent call last):
File "./schroedinger.py", line 110, in ?
main()
File "./schroedinger.py", line 107, in main
evp = solveEigenProblem( conf, options )
File "./schroedinger.py", line 24, in solveEigenProblem
pb = ProblemDefinition.fromConf( conf )
File "/home/ondra/sfepy/sfe/fem/problemDef.py", line 40, in fromConf
domain.setupNeighbourLists()
File "/home/ondra/sfepy/sfe/fem/domain.py", line 349, in setupNeighbourLists
mu.sortRows( aux, nm.array( sortCols[mode], nm.int32 ) )
File "/home/ondra/sfepy/sfe/fem/extmods/meshutils.py", line 102, in sortRows
return _meshutils.sortRows(*args)
TypeError: array cannot be safely cast to required type
This is imho related to the fact, that the 64bit system uses integers
of a different default length.
Ondrej
Hi,
I greatly recommend paraview for postprocessing. We should add this to
our wiki too.
I created a Debian package, accessible in my repository:
http://debian.certik.cz/
However, more work is needed, before it can get to the main Debian.
I have a question - do you know how to save the pipeline, so that when
I fix my program, calculate the result again, I don't have to fiddle
with mouse in paraview and simply see the same pipeline as before
but with new data?
Ideally, do you have some example script how to call paraview from
python? Let's add all this information to the wiki. Our first issue:
http://code.google.com/p/sfepy/issues/detail?id=1
And to make things moving, I created some more issues. Now I am
working on incorporating my mesh conversion utilities + automatic mesh
generation using tetgen, will send a patch soon.
Ondrej
