So, I am taking my first steps in using SfePy. I have two questions, one about mesh generation and one about the results I am getting.
First, about mesh generation. I am trying to understand the workflow. What is actually necessary? What is the easiest way to create a mesh for a really simple part, like a cube or cylinder? I have tinkered with TetGen and have generated a mesh that way. I was reading through convert.py and trying to understand what it wants as an input. In the end, I didn't use convert.py and simply set
fileName_mesh = 'input/first_mesh.1.node'
in my input file. Is this correct? Is it best? Does it actually read all the other files about by TetGen (.face and .ele), or is it only using the .node file?
First_mesh.poly is my input to TetGen and the others are the output. I think it worked.
For my second question, I used the attached mesh files along with the input script from_Robert.py (something he sent me a while back) and simply.py and got the following output:
In [1]: run simple.py input/from_Robert.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs', 'options'] sfe: warning: left over: ['tractionLoad'] sfe: reading mesh... nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 sfe: ...done in 0.04 s sfe: setting up domain edges... sfe: ...done in 0.00 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Top region_2 sfe: leaf Omega region_1000 sfe: leaf Bottom region_1 sfe: ...done in 0.04 s sfe: equation "balance_of_forces": sfe: dw_lin_elastic_iso.i1.Omega( solid.lame, v, u ) = dw_surface_ltr.isurf.Top( traction.val, v ) sfe: describing geometries... sfe: ...done in 0.01 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls sfe: matrix shape: (156, 156) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 4248 (1.75e-01% fill) sfe: updating materials... sfe: solid sfe: traction TimeStepper nDigit: 1 t0: 0.0 t1: 1.0 step: 0 time: 0.0 dt: 1.0 times: [ 0.] nt: 0.0 nStep: 1 input/from_Robert.py, 69: tractionLoad(), 76 sfe: ...done in 0.00 s sfe: nls: iter: 0, residual: 0.000000e+00 (rel: 0.000000e+00)
and the attached vtk file. The vtk file seems to say that the force at each node is 0. That doesn't seem right.
Am I doing something wrong? Are these results actually valid? How should I proceed?
I was thinking that in terms of material modeling, I would start with a static compressive load applied to the foam specimen, then a load that ramps up and watch the displacement and stress in each case. Start with small stresses and strains and then talk about how to handle large strains. Does that make sense?
Thanks for your help.
Ryan
On Mon, Jul 7, 2008 at 11:21 PM, Ryan Krauss ryan...@gmail.com wrote:
So, I am taking my first steps in using SfePy. I have two questions, one about mesh generation and one about the results I am getting.
First, about mesh generation. I am trying to understand the workflow. What is actually necessary? What is the easiest way to create a mesh for a really simple part, like a cube or cylinder? I have tinkered with TetGen and have generated a mesh that way. I was reading through convert.py and trying to understand what it wants as an input. In the end, I didn't use convert.py and simply set
convert.py is used to convert the geometry from gmsh to tetgen, so if you use tetgen directly, you don't need this.
fileName_mesh = 'input/first_mesh.1.node'
in my input file. Is this correct?
I think so.
Is it best?
The best is not to use tetgen, because it is not free. There is no other working alternative though for 3D mesh generation. Maybe netgen, but that is not so robust in my experience.
If we get some free time, maybe we'll manage to write something free ourselves.
Does it actually read all the other files about by TetGen (.face and .ele), or is it only using the .node file?
It should.
First_mesh.poly is my input to TetGen and the others are the output. I think it worked.
For my second question, I used the attached mesh files along with the input script from_Robert.py (something he sent me a while back) and simply.py and got the following output:
In [1]: run simple.py input/from_Robert.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs', 'options'] sfe: warning: left over: ['tractionLoad'] sfe: reading mesh... nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 sfe: ...done in 0.04 s sfe: setting up domain edges... sfe: ...done in 0.00 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Top region_2 sfe: leaf Omega region_1000 sfe: leaf Bottom region_1 sfe: ...done in 0.04 s sfe: equation "balance_of_forces": sfe: dw_lin_elastic_iso.i1.Omega( solid.lame, v, u ) = dw_surface_ltr.isurf.Top( traction.val, v ) sfe: describing geometries... sfe: ...done in 0.01 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls sfe: matrix shape: (156, 156) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 4248 (1.75e-01% fill) sfe: updating materials... sfe: solid sfe: traction TimeStepper nDigit: 1 t0: 0.0 t1: 1.0 step: 0 time: 0.0 dt: 1.0 times: [ 0.] nt: 0.0 nStep: 1 input/from_Robert.py, 69: tractionLoad(), 76 sfe: ...done in 0.00 s sfe: nls: iter: 0, residual: 0.000000e+00 (rel: 0.000000e+00)
and the attached vtk file. The vtk file seems to say that the force at each node is 0. That doesn't seem right.
Am I doing something wrong? Are these results actually valid? How should I proceed?
Robert will answer those.
I was thinking that in terms of material modeling, I would start with a static compressive load applied to the foam specimen, then a load that ramps up and watch the displacement and stress in each case. Start with small stresses and strains and then talk about how to handle large strains. Does that make sense?
Thanks for your help.
Thanks for using sfepy.
Ondrej
Ryan Krauss wrote:
So, I am taking my first steps in using SfePy. I have two questions, one about mesh generation and one about the results I am getting.
First, about mesh generation. I am trying to understand the workflow. What is actually necessary? What is the easiest way to create a mesh for a really simple part, like a cube or cylinder? I have tinkered with TetGen and have generated a mesh that way. I was reading through convert.py and trying to understand what it wants as an input. In the end, I didn't use convert.py and simply set
fileName_mesh = 'input/first_mesh.1.node'
in my input file. Is this correct? Is it best? Does it actually read all the other files about by TetGen (.face and .ele), or is it only using the .node file?
If you just need a mesh of a block, or cube, se below. Otherwise we have no free alternative to tetgen, as Ondrej wrote.
First_mesh.poly is my input to TetGen and the others are the output. I think it worked.
For realy simple - block - meshes you can use also:
$ ./script/blockgen.py --help usage: blockgen.py [options]
Block mesh generator.
options: --version show program's version number and exit -h, --help show this help message and exit -o fileName output file name [default: out.vtk] -d dims, --dims=dims dimension of the block [default: [1.0, 1.0, 1.0]] -s shape, --shape=shape shape (counts of nodes in x, y, z) of the block [default: [11, 11, 11]] -c centre, --centre=centre centre of the block [default: [0.0, 0.0, 0.0]]
For my second question, I used the attached mesh files along with the input script from_Robert.py (something he sent me a while back) and simply.py and got the following output:
In [1]: run simple.py input/from_Robert.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs', 'options'] sfe: warning: left over: ['tractionLoad'] sfe: reading mesh... nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 sfe: ...done in 0.04 s sfe: setting up domain edges... sfe: ...done in 0.00 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Top region_2 sfe: leaf Omega region_1000 sfe: leaf Bottom region_1 sfe: ...done in 0.04 s sfe: equation "balance_of_forces": sfe: dw_lin_elastic_iso.i1.Omega( solid.lame, v, u ) = dw_surface_ltr.isurf.Top( traction.val, v ) sfe: describing geometries... sfe: ...done in 0.01 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls sfe: matrix shape: (156, 156) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 4248 (1.75e-01% fill) sfe: updating materials... sfe: solid sfe: traction TimeStepper nDigit: 1 t0: 0.0 t1: 1.0 step: 0 time: 0.0 dt: 1.0 times: [ 0.] nt: 0.0 nStep: 1 input/from_Robert.py, 69: tractionLoad(), 76 sfe: ...done in 0.00 s sfe: nls: iter: 0, residual: 0.000000e+00 (rel: 0.000000e+00)
and the attached vtk file. The vtk file seems to say that the force at each node is 0. That doesn't seem right.
Am I doing something wrong? Are these results actually valid? How should I proceed?
You are missing the time stepping solver, see input/time_poisson.py the user had not specified it.
- that is why you solve only the time step 0, where the loading force is zero... The TimeStepper you see is the default one, that is created when
I am sending you an updated input file that should work. Also try a finer mesh, as the one you test with is really coarse (generate it via blockgen).
Changes I have made:
- added 'solver_2' (time stepping info)
- added 'options' saying which solvers to use. This is obligatory - 'solver_2' would be ignored without it.
- fixed tractionLoad() to return not only zeros.
I have also fixed the time stepping solver for missing variableHistory option (see again input/time_poisson.py) as you solve a quasi-static problem for the moment -> you should pull the fresh version from our repository (see http://code.google.com/p/sfepy/wiki/MercurialHowTo)
I was thinking that in terms of material modeling, I would start with a static compressive load applied to the foam specimen, then a load that ramps up and watch the displacement and stress in each case. Start with small stresses and strains and then talk about how to handle large strains. Does that make sense?
Sure. The static test you describe is in fact just the file I am sending now. You only need to implement (or tell us) the constitutive relation of the foam material - the example uses just a linear elastic solid.
Thanks for your help.
Some inspiration: http://xkcd.com/323/ :-)
Having some trouble with the Makefile of the most recent hg version. I am strating to dig into it, but here is the output of my first run:
ryan@am2:~/svn/sfepy$ make ls: sfepy/fem/extmods/*_wrap.c: No such file or directory ls: sfepy/terms/extmods/*_wrap.c: No such file or directory echo 00.46.02-3aebc32f697a > 'VERSION' sed "s|^\(#define VERSION\) \".*\"|\1 \"00.46.02-3aebc32f697a\"|;" sfepy/fem/extmods/version.h.in > sfepy/fem/extmods/version.h gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/geomtrans.c -o sfepy/fem/extmods/geomtrans.o gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/meshutils.c -o sfepy/fem/extmods/meshutils.o swig -python -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -DISRELEASE -o sfepy/fem/extmods/meshutils_wrap.c sfepy/fem/extmods/meshutils.i gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/meshutils_wrap.c -o sfepy/fem/extmods/meshutils_wrap.o sfepy/fem/extmods/meshutils_wrap.c:2776:31: error: numpy/arrayobject.h: No such file or directory sfepy/fem/extmods/meshutils_wrap.c:2788: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sfepy/fem/extmods/meshutils_wrap.c:2815: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_sortRows': sfepy/fem/extmods/meshutils_wrap.c:3143: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3143: error: (Each undeclared identifier is reported only once sfepy/fem/extmods/meshutils_wrap.c:3143: error: for each function it appears in.) sfepy/fem/extmods/meshutils_wrap.c:3143: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3145: warning: implicit declaration of function 'helper_getCArrayObject' sfepy/fem/extmods/meshutils_wrap.c:3145: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3148: warning: implicit declaration of function 'PyArray_DATA' sfepy/fem/extmods/meshutils_wrap.c:3149: warning: implicit declaration of function 'PyArray_DIM' sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_createList': sfepy/fem/extmods/meshutils_wrap.c:3217: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3217: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3219: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_neighbourListPtr': sfepy/fem/extmods/meshutils_wrap.c:3304: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3304: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3306: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_neighbourList': sfepy/fem/extmods/meshutils_wrap.c:3418: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3418: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3420: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_orientEdges': sfepy/fem/extmods/meshutils_wrap.c:3560: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3560: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3562: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_assignEdgeNodes': sfepy/fem/extmods/meshutils_wrap.c:3653: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3653: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3655: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_interpVertexData': sfepy/fem/extmods/meshutils_wrap.c:3788: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3788: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3790: error: 'PyArray_FLOAT64' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3801: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_orientElements': sfepy/fem/extmods/meshutils_wrap.c:3892: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3892: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3894: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3915: error: 'PyArray_FLOAT64' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_graphComponents': sfepy/fem/extmods/meshutils_wrap.c:4002: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:4002: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:4004: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function 'init_meshutils': sfepy/fem/extmods/meshutils_wrap.c:4668: warning: implicit declaration of function 'import_array' make: *** [sfepy/fem/extmods/meshutils_wrap.o] Error 1
On Tue, Jul 8, 2008 at 5:28 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
So, I am taking my first steps in using SfePy. I have two questions, one about mesh generation and one about the results I am getting.
First, about mesh generation. I am trying to understand the workflow. What is actually necessary? What is the easiest way to create a mesh for a really simple part, like a cube or cylinder? I have tinkered with TetGen and have generated a mesh that way. I was reading through convert.py and trying to understand what it wants as an input. In the end, I didn't use convert.py and simply set
fileName_mesh = 'input/first_mesh.1.node'
in my input file. Is this correct? Is it best? Does it actually read all the other files about by TetGen (.face and .ele), or is it only using the .node file?
If you just need a mesh of a block, or cube, se below. Otherwise we have no free alternative to tetgen, as Ondrej wrote.
First_mesh.poly is my input to TetGen and the others are the output. I think it worked.
For realy simple - block - meshes you can use also:
$ ./script/blockgen.py --help usage: blockgen.py [options]
Block mesh generator.
options: --version show program's version number and exit -h, --help show this help message and exit -o fileName output file name [default: out.vtk] -d dims, --dims=dims dimension of the block [default: [1.0, 1.0, 1.0]] -s shape, --shape=shape shape (counts of nodes in x, y, z) of the block [default: [11, 11, 11]] -c centre, --centre=centre centre of the block [default: [0.0, 0.0, 0.0]]
For my second question, I used the attached mesh files along with the input script from_Robert.py (something he sent me a while back) and simply.py and got the following output:
In [1]: run simple.py input/from_Robert.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs', 'options'] sfe: warning: left over: ['tractionLoad'] sfe: reading mesh... nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 sfe: ...done in 0.04 s sfe: setting up domain edges... sfe: ...done in 0.00 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Top region_2 sfe: leaf Omega region_1000 sfe: leaf Bottom region_1 sfe: ...done in 0.04 s sfe: equation "balance_of_forces": sfe: dw_lin_elastic_iso.i1.Omega( solid.lame, v, u ) = dw_surface_ltr.isurf.Top( traction.val, v ) sfe: describing geometries... sfe: ...done in 0.01 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls sfe: matrix shape: (156, 156) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 4248 (1.75e-01% fill) sfe: updating materials... sfe: solid sfe: traction TimeStepper nDigit: 1 t0: 0.0 t1: 1.0 step: 0 time: 0.0 dt: 1.0 times: [ 0.] nt: 0.0 nStep: 1 input/from_Robert.py, 69: tractionLoad(), 76 sfe: ...done in 0.00 s sfe: nls: iter: 0, residual: 0.000000e+00 (rel: 0.000000e+00)
and the attached vtk file. The vtk file seems to say that the force at each node is 0. That doesn't seem right.
Am I doing something wrong? Are these results actually valid? How should I proceed?
You are missing the time stepping solver, see input/time_poisson.py the user had not specified it.
- that is why you solve only the time step 0, where the loading force is zero... The TimeStepper you see is the default one, that is created when
I am sending you an updated input file that should work. Also try a finer mesh, as the one you test with is really coarse (generate it via blockgen).
Changes I have made:
- added 'solver_2' (time stepping info)
- added 'options' saying which solvers to use. This is obligatory - 'solver_2' would be ignored without it.
- fixed tractionLoad() to return not only zeros.
I have also fixed the time stepping solver for missing variableHistory option (see again input/time_poisson.py) as you solve a quasi-static problem for the moment -> you should pull the fresh version from our repository (see http://code.google.com/p/sfepy/wiki/MercurialHowTo)
I was thinking that in terms of material modeling, I would start with a static compressive load applied to the foam specimen, then a load that ramps up and watch the displacement and stress in each case. Start with small stresses and strains and then talk about how to handle large strains. Does that make sense?
Sure. The static test you describe is in fact just the file I am sending now. You only need to implement (or tell us) the constitutive relation of the foam material - the example uses just a linear elastic solid.
Thanks for your help.
Some inspiration: http://xkcd.com/323/ :-)
Solved:
I have several numpy directories on my computer (I downloaded a release but normally run svn). But none of those are on my PYTHONPATH. So, I hard coded this change:
#NUMPYPREFIX := $(shell script/config.py numpy_prefix)
PYTHON_INCL := -I/usr/include/python$(PYVER) -I/usr/$(ARCHLIB)/python$(PYVER)/site-packages/numpy/core/include
and everything compiles fine and all tests pass.
I thing trying to do the auto-configuration is a great idea. For me, the right path could be found in ipython using import numpy reload(numpy)
I don't know how to do that in a script though. Searching sys.path doesn't seem revealing.
Ryan
On Tue, Jul 8, 2008 at 9:21 AM, Ryan Krauss ryan...@gmail.com wrote:
Having some trouble with the Makefile of the most recent hg version. I am strating to dig into it, but here is the output of my first run:
ryan@am2:~/svn/sfepy$ make ls: sfepy/fem/extmods/*_wrap.c: No such file or directory ls: sfepy/terms/extmods/*_wrap.c: No such file or directory echo 00.46.02-3aebc32f697a > 'VERSION' sed "s|^\(#define VERSION\) \".*\"|\1 \"00.46.02-3aebc32f697a\"|;" sfepy/fem/extmods/version.h.in > sfepy/fem/extmods/version.h gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/geomtrans.c -o sfepy/fem/extmods/geomtrans.o gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/meshutils.c -o sfepy/fem/extmods/meshutils.o swig -python -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -DISRELEASE -o sfepy/fem/extmods/meshutils_wrap.c sfepy/fem/extmods/meshutils.i gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/meshutils_wrap.c -o sfepy/fem/extmods/meshutils_wrap.o sfepy/fem/extmods/meshutils_wrap.c:2776:31: error: numpy/arrayobject.h: No such file or directory sfepy/fem/extmods/meshutils_wrap.c:2788: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sfepy/fem/extmods/meshutils_wrap.c:2815: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_sortRows': sfepy/fem/extmods/meshutils_wrap.c:3143: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3143: error: (Each undeclared identifier is reported only once sfepy/fem/extmods/meshutils_wrap.c:3143: error: for each function it appears in.) sfepy/fem/extmods/meshutils_wrap.c:3143: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3145: warning: implicit declaration of function 'helper_getCArrayObject' sfepy/fem/extmods/meshutils_wrap.c:3145: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3148: warning: implicit declaration of function 'PyArray_DATA' sfepy/fem/extmods/meshutils_wrap.c:3149: warning: implicit declaration of function 'PyArray_DIM' sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_createList': sfepy/fem/extmods/meshutils_wrap.c:3217: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3217: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3219: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_neighbourListPtr': sfepy/fem/extmods/meshutils_wrap.c:3304: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3304: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3306: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_neighbourList': sfepy/fem/extmods/meshutils_wrap.c:3418: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3418: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3420: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_orientEdges': sfepy/fem/extmods/meshutils_wrap.c:3560: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3560: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3562: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_assignEdgeNodes': sfepy/fem/extmods/meshutils_wrap.c:3653: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3653: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3655: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_interpVertexData': sfepy/fem/extmods/meshutils_wrap.c:3788: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3788: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3790: error: 'PyArray_FLOAT64' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3801: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_orientElements': sfepy/fem/extmods/meshutils_wrap.c:3892: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3892: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3894: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3915: error: 'PyArray_FLOAT64' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_graphComponents': sfepy/fem/extmods/meshutils_wrap.c:4002: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:4002: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:4004: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function 'init_meshutils': sfepy/fem/extmods/meshutils_wrap.c:4668: warning: implicit declaration of function 'import_array' make: *** [sfepy/fem/extmods/meshutils_wrap.o] Error 1
On Tue, Jul 8, 2008 at 5:28 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
So, I am taking my first steps in using SfePy. I have two questions, one about mesh generation and one about the results I am getting.
First, about mesh generation. I am trying to understand the workflow. What is actually necessary? What is the easiest way to create a mesh for a really simple part, like a cube or cylinder? I have tinkered with TetGen and have generated a mesh that way. I was reading through convert.py and trying to understand what it wants as an input. In the end, I didn't use convert.py and simply set
fileName_mesh = 'input/first_mesh.1.node'
in my input file. Is this correct? Is it best? Does it actually read all the other files about by TetGen (.face and .ele), or is it only using the .node file?
If you just need a mesh of a block, or cube, se below. Otherwise we have no free alternative to tetgen, as Ondrej wrote.
First_mesh.poly is my input to TetGen and the others are the output. I think it worked.
For realy simple - block - meshes you can use also:
$ ./script/blockgen.py --help usage: blockgen.py [options]
Block mesh generator.
options: --version show program's version number and exit -h, --help show this help message and exit -o fileName output file name [default: out.vtk] -d dims, --dims=dims dimension of the block [default: [1.0, 1.0, 1.0]] -s shape, --shape=shape shape (counts of nodes in x, y, z) of the block [default: [11, 11, 11]] -c centre, --centre=centre centre of the block [default: [0.0, 0.0, 0.0]]
For my second question, I used the attached mesh files along with the input script from_Robert.py (something he sent me a while back) and simply.py and got the following output:
In [1]: run simple.py input/from_Robert.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs', 'options'] sfe: warning: left over: ['tractionLoad'] sfe: reading mesh... nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 sfe: ...done in 0.04 s sfe: setting up domain edges... sfe: ...done in 0.00 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Top region_2 sfe: leaf Omega region_1000 sfe: leaf Bottom region_1 sfe: ...done in 0.04 s sfe: equation "balance_of_forces": sfe: dw_lin_elastic_iso.i1.Omega( solid.lame, v, u ) = dw_surface_ltr.isurf.Top( traction.val, v ) sfe: describing geometries... sfe: ...done in 0.01 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls sfe: matrix shape: (156, 156) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 4248 (1.75e-01% fill) sfe: updating materials... sfe: solid sfe: traction TimeStepper nDigit: 1 t0: 0.0 t1: 1.0 step: 0 time: 0.0 dt: 1.0 times: [ 0.] nt: 0.0 nStep: 1 input/from_Robert.py, 69: tractionLoad(), 76 sfe: ...done in 0.00 s sfe: nls: iter: 0, residual: 0.000000e+00 (rel: 0.000000e+00)
and the attached vtk file. The vtk file seems to say that the force at each node is 0. That doesn't seem right.
Am I doing something wrong? Are these results actually valid? How should I proceed?
You are missing the time stepping solver, see input/time_poisson.py the user had not specified it.
- that is why you solve only the time step 0, where the loading force is zero... The TimeStepper you see is the default one, that is created when
I am sending you an updated input file that should work. Also try a finer mesh, as the one you test with is really coarse (generate it via blockgen).
Changes I have made:
- added 'solver_2' (time stepping info)
- added 'options' saying which solvers to use. This is obligatory - 'solver_2' would be ignored without it.
- fixed tractionLoad() to return not only zeros.
I have also fixed the time stepping solver for missing variableHistory option (see again input/time_poisson.py) as you solve a quasi-static problem for the moment -> you should pull the fresh version from our repository (see http://code.google.com/p/sfepy/wiki/MercurialHowTo)
I was thinking that in terms of material modeling, I would start with a static compressive load applied to the foam specimen, then a load that ramps up and watch the displacement and stress in each case. Start with small stresses and strains and then talk about how to handle large strains. Does that make sense?
Sure. The static test you describe is in fact just the file I am sending now. You only need to implement (or tell us) the constitutive relation of the foam material - the example uses just a linear elastic solid.
Thanks for your help.
Some inspiration: http://xkcd.com/323/ :-)
Thanks Robert.
I am now able to run the modified file and get 10 vtk files out. (I now have to re-learn enough mayavi(2) or learn enough paraview to visualize the results).
You are missing the time stepping solver Is this an installation problem, or do you mean I was missing specifying it in the configuration file (i.e. from_Robert.py).?
Thanks again,
Ryan
On Tue, Jul 8, 2008 at 9:35 AM, Ryan Krauss ryan...@gmail.com wrote:
Solved:
I have several numpy directories on my computer (I downloaded a release but normally run svn). But none of those are on my PYTHONPATH. So, I hard coded this change:
#NUMPYPREFIX := $(shell script/config.py numpy_prefix)
PYTHON_INCL := -I/usr/include/python$(PYVER) -I/usr/$(ARCHLIB)/python$(PYVER)/site-packages/numpy/core/include
and everything compiles fine and all tests pass.
I thing trying to do the auto-configuration is a great idea. For me, the right path could be found in ipython using import numpy reload(numpy)
I don't know how to do that in a script though. Searching sys.path doesn't seem revealing.
Ryan
On Tue, Jul 8, 2008 at 9:21 AM, Ryan Krauss ryan...@gmail.com wrote:
Having some trouble with the Makefile of the most recent hg version. I am strating to dig into it, but here is the output of my first run:
ryan@am2:~/svn/sfepy$ make ls: sfepy/fem/extmods/*_wrap.c: No such file or directory ls: sfepy/terms/extmods/*_wrap.c: No such file or directory echo 00.46.02-3aebc32f697a > 'VERSION' sed "s|^\(#define VERSION\) \".*\"|\1 \"00.46.02-3aebc32f697a\"|;" sfepy/fem/extmods/version.h.in > sfepy/fem/extmods/version.h gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/geomtrans.c -o sfepy/fem/extmods/geomtrans.o gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/meshutils.c -o sfepy/fem/extmods/meshutils.o swig -python -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -DISRELEASE -o sfepy/fem/extmods/meshutils_wrap.c sfepy/fem/extmods/meshutils.i gcc -g -O2 -fPIC -DPIC -D__SDIR__='"tests"' -Ieldesc -Iexamples -Iinput -Isfepy -Isfepy/base -Isfepy/fem -Isfepy/fem/extmods -Isfepy/homogenization -Isfepy/solvers -Isfepy/terms -Isfepy/terms/extmods -Isfepy/physics -Isfepy/physics/extmods -Itests -I/usr/include/python2.5 -I/home/share/software/usr/lib/python2.5/site-packages/numpy/core/include -Wall -c -DISRELEASE sfepy/fem/extmods/meshutils_wrap.c -o sfepy/fem/extmods/meshutils_wrap.o sfepy/fem/extmods/meshutils_wrap.c:2776:31: error: numpy/arrayobject.h: No such file or directory sfepy/fem/extmods/meshutils_wrap.c:2788: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sfepy/fem/extmods/meshutils_wrap.c:2815: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_sortRows': sfepy/fem/extmods/meshutils_wrap.c:3143: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3143: error: (Each undeclared identifier is reported only once sfepy/fem/extmods/meshutils_wrap.c:3143: error: for each function it appears in.) sfepy/fem/extmods/meshutils_wrap.c:3143: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3145: warning: implicit declaration of function 'helper_getCArrayObject' sfepy/fem/extmods/meshutils_wrap.c:3145: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3148: warning: implicit declaration of function 'PyArray_DATA' sfepy/fem/extmods/meshutils_wrap.c:3149: warning: implicit declaration of function 'PyArray_DIM' sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_createList': sfepy/fem/extmods/meshutils_wrap.c:3217: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3217: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3219: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_neighbourListPtr': sfepy/fem/extmods/meshutils_wrap.c:3304: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3304: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3306: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_neighbourList': sfepy/fem/extmods/meshutils_wrap.c:3418: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3418: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3420: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_orientEdges': sfepy/fem/extmods/meshutils_wrap.c:3560: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3560: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3562: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_assignEdgeNodes': sfepy/fem/extmods/meshutils_wrap.c:3653: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3653: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3655: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_interpVertexData': sfepy/fem/extmods/meshutils_wrap.c:3788: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3788: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3790: error: 'PyArray_FLOAT64' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3801: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_orientElements': sfepy/fem/extmods/meshutils_wrap.c:3892: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3892: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3894: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:3915: error: 'PyArray_FLOAT64' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function '_wrap_graphComponents': sfepy/fem/extmods/meshutils_wrap.c:4002: error: 'PyArrayObject' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:4002: error: 'obj' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c:4004: error: 'PyArray_INT32' undeclared (first use in this function) sfepy/fem/extmods/meshutils_wrap.c: In function 'init_meshutils': sfepy/fem/extmods/meshutils_wrap.c:4668: warning: implicit declaration of function 'import_array' make: *** [sfepy/fem/extmods/meshutils_wrap.o] Error 1
On Tue, Jul 8, 2008 at 5:28 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
So, I am taking my first steps in using SfePy. I have two questions, one about mesh generation and one about the results I am getting.
First, about mesh generation. I am trying to understand the workflow. What is actually necessary? What is the easiest way to create a mesh for a really simple part, like a cube or cylinder? I have tinkered with TetGen and have generated a mesh that way. I was reading through convert.py and trying to understand what it wants as an input. In the end, I didn't use convert.py and simply set
fileName_mesh = 'input/first_mesh.1.node'
in my input file. Is this correct? Is it best? Does it actually read all the other files about by TetGen (.face and .ele), or is it only using the .node file?
If you just need a mesh of a block, or cube, se below. Otherwise we have no free alternative to tetgen, as Ondrej wrote.
First_mesh.poly is my input to TetGen and the others are the output. I think it worked.
For realy simple - block - meshes you can use also:
$ ./script/blockgen.py --help usage: blockgen.py [options]
Block mesh generator.
options: --version show program's version number and exit -h, --help show this help message and exit -o fileName output file name [default: out.vtk] -d dims, --dims=dims dimension of the block [default: [1.0, 1.0, 1.0]] -s shape, --shape=shape shape (counts of nodes in x, y, z) of the block [default: [11, 11, 11]] -c centre, --centre=centre centre of the block [default: [0.0, 0.0, 0.0]]
For my second question, I used the attached mesh files along with the input script from_Robert.py (something he sent me a while back) and simply.py and got the following output:
In [1]: run simple.py input/from_Robert.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs', 'options'] sfe: warning: left over: ['tractionLoad'] sfe: reading mesh... nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 sfe: ...done in 0.04 s sfe: setting up domain edges... sfe: ...done in 0.00 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Top region_2 sfe: leaf Omega region_1000 sfe: leaf Bottom region_1 sfe: ...done in 0.04 s sfe: equation "balance_of_forces": sfe: dw_lin_elastic_iso.i1.Omega( solid.lame, v, u ) = dw_surface_ltr.isurf.Top( traction.val, v ) sfe: describing geometries... sfe: ...done in 0.01 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls sfe: matrix shape: (156, 156) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 4248 (1.75e-01% fill) sfe: updating materials... sfe: solid sfe: traction TimeStepper nDigit: 1 t0: 0.0 t1: 1.0 step: 0 time: 0.0 dt: 1.0 times: [ 0.] nt: 0.0 nStep: 1 input/from_Robert.py, 69: tractionLoad(), 76 sfe: ...done in 0.00 s sfe: nls: iter: 0, residual: 0.000000e+00 (rel: 0.000000e+00)
and the attached vtk file. The vtk file seems to say that the force at each node is 0. That doesn't seem right.
Am I doing something wrong? Are these results actually valid? How should I proceed?
You are missing the time stepping solver, see input/time_poisson.py the user had not specified it.
- that is why you solve only the time step 0, where the loading force is zero... The TimeStepper you see is the default one, that is created when
I am sending you an updated input file that should work. Also try a finer mesh, as the one you test with is really coarse (generate it via blockgen).
Changes I have made:
- added 'solver_2' (time stepping info)
- added 'options' saying which solvers to use. This is obligatory - 'solver_2' would be ignored without it.
- fixed tractionLoad() to return not only zeros.
I have also fixed the time stepping solver for missing variableHistory option (see again input/time_poisson.py) as you solve a quasi-static problem for the moment -> you should pull the fresh version from our repository (see http://code.google.com/p/sfepy/wiki/MercurialHowTo)
I was thinking that in terms of material modeling, I would start with a static compressive load applied to the foam specimen, then a load that ramps up and watch the displacement and stress in each case. Start with small stresses and strains and then talk about how to handle large strains. Does that make sense?
Sure. The static test you describe is in fact just the file I am sending now. You only need to implement (or tell us) the constitutive relation of the foam material - the example uses just a linear elastic solid.
Thanks for your help.
Some inspiration: http://xkcd.com/323/ :-)
Ryan Krauss wrote:
Thanks Robert.
I am now able to run the modified file and get 10 vtk files out. (I now have to re-learn enough mayavi(2) or learn enough paraview to visualize the results).
good! with paraview it is trivial - start paraview, open the files (all at once (first_mesh.1_out....vtk), press the green 'apply' button, select 'u' instead of 'solid color' in the drop-down box (top left) and start the animation with the familiar play button (green right arrow).
You are missing the time stepping solver Is this an installation problem, or do you mean I was missing specifying it in the configuration file (i.e. from_Robert.py).?
it is not an installation problem - it was just missing in the configuration (problem description) file.
On Tue, Jul 8, 2008 at 4:35 PM, Ryan Krauss ryan...@gmail.com wrote:
Solved:
I have several numpy directories on my computer (I downloaded a release but normally run svn). But none of those are on my PYTHONPATH. So, I hard coded this change:
Which linux distribution are you running? If Debian/Ubuntu, why don't you just install it from Debian? I do that and it works great.
Ondrej
The next time I upgrade Ubuntu or update numpy, I will try just using the stock version. Numpy is actually running fine right now and I don't want to mess with it. But something about my configuration confuses the SfePy Makefile.
On Tue, Jul 8, 2008 at 9:57 AM, Ondrej Certik ond...@certik.cz wrote:
On Tue, Jul 8, 2008 at 4:35 PM, Ryan Krauss ryan...@gmail.com wrote:
Solved:
I have several numpy directories on my computer (I downloaded a release but normally run svn). But none of those are on my PYTHONPATH. So, I hard coded this change:
Which linux distribution are you running? If Debian/Ubuntu, why don't you just install it from Debian? I do that and it works great.
Ondrej
On Tue, Jul 8, 2008 at 5:03 PM, Ryan Krauss ryan...@gmail.com wrote:
The next time I upgrade Ubuntu or update numpy, I will try just using the stock version. Numpy is actually running fine right now and I don't want to mess with it. But something about my configuration confuses the SfePy Makefile.
Great. I am comaintaining the python-numpy in Debian, so it works fine there. And I make sure the makefile compiles fine in Debian too. So I think it should compile fine in ubuntu as well with a recent stock numpy. If not, please try to figure out a patch so that it does.
Ondrej
I will look into this this afternoon. Just running "script/config.py numpy_prefix" found one of my other (non-installed) numpy directories. It should be a matter of tweaking config.py to find the right numpy. I will look into how config.py does it's searching. I think if you iterated over sys.path in order, the first one to have a numpy dir should be the right one. I wil try this and report back.
Ryan
On Tue, Jul 8, 2008 at 10:06 AM, Ondrej Certik ond...@certik.cz wrote:
On Tue, Jul 8, 2008 at 5:03 PM, Ryan Krauss ryan...@gmail.com wrote:
The next time I upgrade Ubuntu or update numpy, I will try just using the stock version. Numpy is actually running fine right now and I don't want to mess with it. But something about my configuration confuses the SfePy Makefile.
Great. I am comaintaining the python-numpy in Debian, so it works fine there. And I make sure the makefile compiles fine in Debian too. So I think it should compile fine in ubuntu as well with a recent stock numpy. If not, please try to figure out a patch so that it does.
Ondrej
On Tue, Jul 8, 2008 at 5:27 PM, Ryan Krauss ryan...@gmail.com wrote:
I will look into this this afternoon. Just running "script/config.py numpy_prefix" found one of my other (non-installed) numpy directories. It should be a matter of tweaking config.py to find the right numpy. I will look into how config.py does it's searching. I think if you iterated over sys.path in order, the first one to have a numpy dir should be the right one. I wil try this and report back.
Great. The goal is to have sfepy in a state, that you just download it, type "make" and it will do the right thing on any system.
Ondrej
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
I am glad to try and write a more intelligent numpy finder if that is considered valuable. Otherwise, I think a comment in the Makefile to set site_cfg.py correctly should be enough.
Ryan
On Tue, Jul 8, 2008 at 11:01 AM, Ondrej Certik ond...@certik.cz wrote:
On Tue, Jul 8, 2008 at 5:27 PM, Ryan Krauss ryan...@gmail.com wrote:
I will look into this this afternoon. Just running "script/config.py numpy_prefix" found one of my other (non-installed) numpy directories. It should be a matter of tweaking config.py to find the right numpy. I will look into how config.py does it's searching. I think if you iterated over sys.path in order, the first one to have a numpy dir should be the right one. I wil try this and report back.
Great. The goal is to have sfepy in a state, that you just download it, type "make" and it will do the right thing on any system.
Ondrej
Actually, I have this function in one of my utility modules:
def FindinPath(filename): pathlist=sys.path outpath='' for curpath in pathlist: temppath=os.path.join(curpath,filename) if os.path.exists(temppath): outpath=temppath break return outpath
I think it already does most of the work, and it could find tetgen in my PATH as well (since PATH gets put in sys.path).
Ryan
On Tue, Jul 8, 2008 at 11:10 AM, Ryan Krauss ryan...@gmail.com wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
I am glad to try and write a more intelligent numpy finder if that is considered valuable. Otherwise, I think a comment in the Makefile to set site_cfg.py correctly should be enough.
Ryan
On Tue, Jul 8, 2008 at 11:01 AM, Ondrej Certik ond...@certik.cz wrote:
On Tue, Jul 8, 2008 at 5:27 PM, Ryan Krauss ryan...@gmail.com wrote:
I will look into this this afternoon. Just running "script/config.py numpy_prefix" found one of my other (non-installed) numpy directories. It should be a matter of tweaking config.py to find the right numpy. I will look into how config.py does it's searching. I think if you iterated over sys.path in order, the first one to have a numpy dir should be the right one. I wil try this and report back.
Great. The goal is to have sfepy in a state, that you just download it, type "make" and it will do the right thing on any system.
Ondrej
On Tue, Jul 8, 2008 at 6:10 PM, Ryan Krauss ryan...@gmail.com wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
I am glad to try and write a more intelligent numpy finder if that is considered valuable. Otherwise, I think a comment in the Makefile to set site_cfg.py correctly should be enough.
Great. Could you please setup your own hg repo, for example at freehg.org, or http://freehg.sympy.org/, and push there patches that are good and work for you? And we'll pull it from you.
I think that's the easiest way to share things. All improvements to comments and documentation is welcome. You just to "hg push" and I do "hg pull ryan" and that's it. It costs you 1s and it costs me 1s.
Ondrej
Cool. I will try and set that up and become an actual contributor.
On Tue, Jul 8, 2008 at 11:15 AM, Ondrej Certik ond...@certik.cz wrote:
On Tue, Jul 8, 2008 at 6:10 PM, Ryan Krauss ryan...@gmail.com wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
I am glad to try and write a more intelligent numpy finder if that is considered valuable. Otherwise, I think a comment in the Makefile to set site_cfg.py correctly should be enough.
Great. Could you please setup your own hg repo, for example at freehg.org, or http://freehg.sympy.org/, and push there patches that are good and work for you? And we'll pull it from you.
I think that's the easiest way to share things. All improvements to comments and documentation is welcome. You just to "hg push" and I do "hg pull ryan" and that's it. It costs you 1s and it costs me 1s.
Ondrej
On Tue, Jul 8, 2008 at 7:00 PM, Ryan Krauss ryan...@gmail.com wrote:
Cool. I will try and set that up and become an actual contributor.
Great. You can get inspired here:
http://docs.sympy.org/sympy-patches-tutorial.html
e.g. the quick start etc. applies generally. I guess Robert agrees. :)
Ondrej
Ondrej Certik wrote:
On Tue, Jul 8, 2008 at 7:00 PM, Ryan Krauss ryan...@gmail.com wrote:
Cool. I will try and set that up and become an actual contributor.
Great. You can get inspired here:
http://docs.sympy.org/sympy-patches-tutorial.html
e.g. the quick start etc. applies generally. I guess Robert agrees. :)
I always agree with less work for me :)
r.
Nothing is in it yet, but I just created http://freehg.org/u/ryankrauss/sfepy/
On 7/8/08, Ondrej Certik ond...@certik.cz wrote:
On Tue, Jul 8, 2008 at 6:10 PM, Ryan Krauss ryan...@gmail.com wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
I am glad to try and write a more intelligent numpy finder if that is considered valuable. Otherwise, I think a comment in the Makefile to set site_cfg.py correctly should be enough.
Great. Could you please setup your own hg repo, for example at freehg.org, or http://freehg.sympy.org/, and push there patches that are good and work for you? And we'll pull it from you.
I think that's the easiest way to share things. All improvements to comments and documentation is welcome. You just to "hg push" and I do "hg pull ryan" and that's it. It costs you 1s and it costs me 1s.
Ondrej
Ryan Krauss wrote:
Nothing is in it yet, but I just created http://freehg.org/u/ryankrauss/sfepy/
Ryan,
maybe you should consider using http://freehg.sympy.org/, as it is much faster than freehg.org. Speed was the reason why Ondrej had set it up. Anyway, it is ok if freehg.org works well for you.
r.
On Tue, Jul 8, 2008 at 8:44 PM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
Nothing is in it yet, but I just created http://freehg.org/u/ryankrauss/sfepy/
Ryan,
maybe you should consider using http://freehg.sympy.org/, as it is much faster than freehg.org. Speed was the reason why Ondrej had set it up. Anyway, it is ok if freehg.org works well for you.
Yep. Only a disclaimer -- if the freehg.sympy.org crashes, you loose the repo, so use it for publishing but not archiving.
Ondrej
Ryan Krauss wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
the default should be definitely changed to '/'. Does it work if you set it correctly in the created site_cfg.py?
r.
hard coding numpy_prefix = '/' in site_cfg.py works fine. I should have something that auto-detects what numpy_prefix should be for you guys to test in the morning. I think it is working now. This will give me a chance to test our hg.
Ryan
On 7/8/08, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
the default should be definitely changed to '/'. Does it work if you set it correctly in the created site_cfg.py?
r.
I am having trouble creating my hg repository. I created an account on http://freehg.sympy.org/u/ryankrauss/sfepy/
and then tried pushing to http://freehg.sympy.org/u/ryankrauss/sfepy/
this uploaded everything from my local hg directory, but it didn't include my latest changes. In fact, the script/config.py file in the repository isn't the same as the one on my harddrive.
How do I commit my own changes to my repository? Was I supposed to do something to it before I made any changes to my local directory?
Thanks,
Ryan
On Tue, Jul 8, 2008 at 4:10 PM, Ryan Krauss ryan...@gmail.com wrote:
hard coding numpy_prefix = '/' in site_cfg.py works fine. I should have something that auto-detects what numpy_prefix should be for you guys to test in the morning. I think it is working now. This will give me a chance to test our hg.
Ryan
On 7/8/08, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
OK, I think the issue is this:
try: import site_cfg except: try: shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' ) import site_cfg except: site_cfg = None
and site_cfg_template.py defaults to numpy_prefix = '/home/.....'
rather than numpy_prefix = '/'
the default should be definitely changed to '/'. Does it work if you set it correctly in the created site_cfg.py?
r.
Hi Ryan!
On Wed, Jul 9, 2008 at 5:55 AM, Ryan Krauss ryan...@gmail.com wrote:
I am having trouble creating my hg repository. I created an account on http://freehg.sympy.org/u/ryankrauss/sfepy/
and then tried pushing to http://freehg.sympy.org/u/ryankrauss/sfepy/
this uploaded everything from my local hg directory, but it didn't include my latest changes. In fact, the script/config.py file in the repository isn't the same as the one on my harddrive.
How do I commit my own changes to my repository? Was I supposed to do something to it before I made any changes to my local directory?
Did you commit the changes? Follow e.g. the quick-start tutorial:
http://docs.sympy.org/sympy-patches-tutorial.html#quick-start
and type "hg vi" at the end -- this will show the contens of your repository, so you can see what is in and what is not.
Ondrej
Ondrej Certik wrote:
Hi Ryan!
On Wed, Jul 9, 2008 at 5:55 AM, Ryan Krauss ryan...@gmail.com wrote:
I am having trouble creating my hg repository. I created an account on http://freehg.sympy.org/u/ryankrauss/sfepy/
and then tried pushing to http://freehg.sympy.org/u/ryankrauss/sfepy/
this uploaded everything from my local hg directory, but it didn't include my latest changes. In fact, the script/config.py file in the repository isn't the same as the one on my harddrive.
How do I commit my own changes to my repository? Was I supposed to do something to it before I made any changes to my local directory?
Did you commit the changes? Follow e.g. the quick-start tutorial:
http://docs.sympy.org/sympy-patches-tutorial.html#quick-start
I will give here a short summary.
If you make some changes, you can review what files were changed (and not yet committed to your local repository) by: 'hg st'.
Changed files can be reverted to the last committed state by: 'hg revert'
Then you commit the changes by: "hg ci -m 'what have I done...' [list of files, or nothing for all changed files]".
You can review the commit by 'hg log -v | less'.
If something was wrong, use 'hg rollback' to undo the last (only one!) commit.
If all is ok, push yout changes out by: hg push http://freehg.sympy.org/u/ryankrauss/sfepy/
r.
OK, so sorry mercurial is taking me so long to grasp. I don't know what the problem is. It seems quite powerful. I have tried skimming their tutorials. I guess I need to set aside some time and work through their documentation in detail.
But I have successfully pushed changes onto my repo. I screwed up just a bit and didn't and the single quotes to the list of files the first time. So tha this:
hg ci -m script/config.py
also included a change in site_cfg_template.py in my changeset. I think I made the same change as Robert, so hopefully this won't make a big mess.
The only problem is that I pushed onto my repo before locally doing a roll back and then doing: hg ci -m 'script/config.py'
I then forced a push onto the repo and the repo kept the original changeset that included site_cfg_template.py and added a second one with what it calls 0 changes (it looks exacly like the first).
I promise to read through the mercurial docs before I ask any more mercurial related questions (and I really am interested in learning it).
On to the actual content of my change: it might be more hassle than it is worth and Robert's change to the defaul of numpy_prefix probably makes it unnecessary, but I think I have successfully made config.py find the numpy dir that is actually loaded by python. The only way I could see it going wrong is if the user deliberately alters sys.path in their scripts. I don't really have much time invested in this, so it is no big deal if we decide it creates more problems than it solves. It does give us the option of allowing a truly general numpy/core/include location though (i.e. it doesn't have to be of the form /*/usr/$ARCHLIB/ or whatever.
Thanks for your help and especially your patience with Mercurial,
Ryan
On Wed, Jul 9, 2008 at 2:36 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ondrej Certik wrote:
Hi Ryan!
On Wed, Jul 9, 2008 at 5:55 AM, Ryan Krauss ryan...@gmail.com wrote:
I am having trouble creating my hg repository. I created an account on http://freehg.sympy.org/u/ryankrauss/sfepy/
and then tried pushing to http://freehg.sympy.org/u/ryankrauss/sfepy/
this uploaded everything from my local hg directory, but it didn't include my latest changes. In fact, the script/config.py file in the repository isn't the same as the one on my harddrive.
How do I commit my own changes to my repository? Was I supposed to do something to it before I made any changes to my local directory?
Did you commit the changes? Follow e.g. the quick-start tutorial:
http://docs.sympy.org/sympy-patches-tutorial.html#quick-start
I will give here a short summary.
If you make some changes, you can review what files were changed (and not yet committed to your local repository) by: 'hg st'.
Changed files can be reverted to the last committed state by: 'hg revert'
Then you commit the changes by: "hg ci -m 'what have I done...' [list of files, or nothing for all changed files]".
You can review the commit by 'hg log -v | less'.
If something was wrong, use 'hg rollback' to undo the last (only one!) commit.
If all is ok, push yout changes out by: hg push http://freehg.sympy.org/u/ryankrauss/sfepy/
r.
On Wed, Jul 9, 2008 at 2:10 PM, Ryan Krauss ryan...@gmail.com wrote:
OK, so sorry mercurial is taking me so long to grasp. I don't know what the problem is. It seems quite powerful. I have tried skimming their tutorials. I guess I need to set aside some time and work through their documentation in detail.
But I have successfully pushed changes onto my repo. I screwed up just a bit and didn't and the single quotes to the list of files the first time. So tha this:
hg ci -m script/config.py
also included a change in site_cfg_template.py in my changeset. I think I made the same change as Robert, so hopefully this won't make a big mess.
The only problem is that I pushed onto my repo before locally doing a roll back and then doing: hg ci -m 'script/config.py'
I then forced a push onto the repo and the repo kept the original changeset that included site_cfg_template.py and added a second one with what it calls 0 changes (it looks exacly like the first).
I promise to read through the mercurial docs before I ask any more mercurial related questions (and I really am interested in learning it).
You can simply purge delete the repo at freehg and start over.
Please ask mercurial quesitons, it's easy for us to answer. Robert will answer this one.
On to the actual content of my change: it might be more hassle than it is worth and Robert's change to the defaul of numpy_prefix probably makes it unnecessary, but I think I have successfully made config.py find the numpy dir that is actually loaded by python. The only way I could see it going wrong is if the user deliberately alters sys.path in their scripts. I don't really have much time invested in this, so it is no big deal if we decide it creates more problems than it solves. It does give us the option of allowing a truly general numpy/core/include location though (i.e. it doesn't have to be of the form /*/usr/$ARCHLIB/ or whatever.
Thanks for your help and especially your patience with Mercurial,
On Wed, Jul 9, 2008 at 2:14 PM, Ryan Krauss ryan...@gmail.com wrote:
Ondrej's quickstart is very helpful. Thanks for that.
Thanks. I'd appreciate all comments, because I wrote the quick start exactly for people like you so that they can start hacking in 5 minutes.
So tell me your impressions, what was difficult, etc, so that we can improve it.
Ondrej
My only suggestion for now would be to encourage people to read the quick start first. You sort of do that, but the wording makes it sounds like you should only read it if you don't want the whole story. I think the whole story would make more sense after you have read the quick start. But mainly that is me being impatient.
To the beginer, the quick start makes a lot of sense and the long version is much harder to undrstand.
Ryan
On Wed, Jul 9, 2008 at 7:16 AM, Ondrej Certik ond...@certik.cz wrote:
On Wed, Jul 9, 2008 at 2:10 PM, Ryan Krauss ryan...@gmail.com wrote:
OK, so sorry mercurial is taking me so long to grasp. I don't know what the problem is. It seems quite powerful. I have tried skimming their tutorials. I guess I need to set aside some time and work through their documentation in detail.
But I have successfully pushed changes onto my repo. I screwed up just a bit and didn't and the single quotes to the list of files the first time. So tha this:
hg ci -m script/config.py
also included a change in site_cfg_template.py in my changeset. I think I made the same change as Robert, so hopefully this won't make a big mess.
The only problem is that I pushed onto my repo before locally doing a roll back and then doing: hg ci -m 'script/config.py'
I then forced a push onto the repo and the repo kept the original changeset that included site_cfg_template.py and added a second one with what it calls 0 changes (it looks exacly like the first).
I promise to read through the mercurial docs before I ask any more mercurial related questions (and I really am interested in learning it).
You can simply purge delete the repo at freehg and start over.
Please ask mercurial quesitons, it's easy for us to answer. Robert will answer this one.
On to the actual content of my change: it might be more hassle than it is worth and Robert's change to the defaul of numpy_prefix probably makes it unnecessary, but I think I have successfully made config.py find the numpy dir that is actually loaded by python. The only way I could see it going wrong is if the user deliberately alters sys.path in their scripts. I don't really have much time invested in this, so it is no big deal if we decide it creates more problems than it solves. It does give us the option of allowing a truly general numpy/core/include location though (i.e. it doesn't have to be of the form /*/usr/$ARCHLIB/ or whatever.
Thanks for your help and especially your patience with Mercurial,
On Wed, Jul 9, 2008 at 2:14 PM, Ryan Krauss ryan...@gmail.com wrote:
Ondrej's quickstart is very helpful. Thanks for that.
Thanks. I'd appreciate all comments, because I wrote the quick start exactly for people like you so that they can start hacking in 5 minutes.
So tell me your impressions, what was difficult, etc, so that we can improve it.
Ondrej
On Wed, Jul 9, 2008 at 2:20 PM, Ryan Krauss ryan...@gmail.com wrote:
My only suggestion for now would be to encourage people to read the quick start first. You sort of do that, but the wording makes it sounds like you should only read it if you don't want the whole story. I think the whole story would make more sense after you have read the quick start. But mainly that is me being impatient.
To the beginer, the quick start makes a lot of sense and the long version is much harder to undrstand.
Thanks for the feedback. That was my original idea too, but it was rejected in the review:
http://groups.google.com/group/sympy-patches/msg/9e5ef081fd2de438
but I CCed Kirill (the reviewer) now, as I think it should be changed. :)
Ondrej
I can see Kirill's point that if you give me a quickstart I probably won't read the full tutorial, but I don't know if reading a full tutorial I don't yet understand is any better.
On Wed, Jul 9, 2008 at 7:37 AM, Ondrej Certik ond...@certik.cz wrote:
On Wed, Jul 9, 2008 at 2:20 PM, Ryan Krauss ryan...@gmail.com wrote:
My only suggestion for now would be to encourage people to read the quick start first. You sort of do that, but the wording makes it sounds like you should only read it if you don't want the whole story. I think the whole story would make more sense after you have read the quick start. But mainly that is me being impatient.
To the beginer, the quick start makes a lot of sense and the long version is much harder to undrstand.
Thanks for the feedback. That was my original idea too, but it was rejected in the review:
http://groups.google.com/group/sympy-patches/msg/9e5ef081fd2de438
but I CCed Kirill (the reviewer) now, as I think it should be changed. :)
Ondrej
OK, I deleted and recreated my repo now showing only the one intended change.
If you like the FindInPath approach, I think we should just use a full numpy include path instead of a prefix and not assume a certain form for the path. I can easily make that change and the corresponding Makefile change.
Ryan
On Wed, Jul 9, 2008 at 7:42 AM, Ryan Krauss ryan...@gmail.com wrote:
I can see Kirill's point that if you give me a quickstart I probably won't read the full tutorial, but I don't know if reading a full tutorial I don't yet understand is any better.
On Wed, Jul 9, 2008 at 7:37 AM, Ondrej Certik ond...@certik.cz wrote:
On Wed, Jul 9, 2008 at 2:20 PM, Ryan Krauss ryan...@gmail.com wrote:
My only suggestion for now would be to encourage people to read the quick start first. You sort of do that, but the wording makes it sounds like you should only read it if you don't want the whole story. I think the whole story would make more sense after you have read the quick start. But mainly that is me being impatient.
To the beginer, the quick start makes a lot of sense and the long version is much harder to undrstand.
Thanks for the feedback. That was my original idea too, but it was rejected in the review:
http://groups.google.com/group/sympy-patches/msg/9e5ef081fd2de438
but I CCed Kirill (the reviewer) now, as I think it should be changed. :)
Ondrej
Ryan Krauss wrote:
OK, I deleted and recreated my repo now showing only the one intended change.
If you like the FindInPath approach, I think we should just use a full numpy include path instead of a prefix and not assume a certain form for the path. I can easily make that change and the corresponding Makefile change.
Yes, do it please. Just use the attached file as your start - I made a few changes
- the 'shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' )' is necessary for fresh installs to create site_cfg.py.
- I changed the name to find_in_path(), as we are going to follow the Python naming conventions for the next release.
You should then:
- change numpy_prefix to numpy_include everywhere (Makefile...)
- set the template default to None, and if it is None, call your function.
Hope that's all :)
r.
Sounds good. Should just take a few minutes.
On Wed, Jul 9, 2008 at 7:51 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
OK, I deleted and recreated my repo now showing only the one intended change.
If you like the FindInPath approach, I think we should just use a full numpy include path instead of a prefix and not assume a certain form for the path. I can easily make that change and the corresponding Makefile change.
Yes, do it please. Just use the attached file as your start - I made a few changes
- the 'shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' )' is necessary for fresh installs to create site_cfg.py.
- I changed the name to find_in_path(), as we are going to follow the Python naming conventions for the next release.
You should then:
- change numpy_prefix to numpy_include everywhere (Makefile...)
- set the template default to None, and if it is None, call your function.
Hope that's all :)
r.
OK, I think this is working and the changeset is on my repo.
Ryan
On Wed, Jul 9, 2008 at 8:16 AM, Ryan Krauss ryan...@gmail.com wrote:
Sounds good. Should just take a few minutes.
On Wed, Jul 9, 2008 at 7:51 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
OK, I deleted and recreated my repo now showing only the one intended change.
If you like the FindInPath approach, I think we should just use a full numpy include path instead of a prefix and not assume a certain form for the path. I can easily make that change and the corresponding Makefile change.
Yes, do it please. Just use the attached file as your start - I made a few changes
- the 'shutil.copyfile( 'site_cfg_template.py', 'site_cfg.py' )' is necessary for fresh installs to create site_cfg.py.
- I changed the name to find_in_path(), as we are going to follow the Python naming conventions for the next release.
You should then:
- change numpy_prefix to numpy_include everywhere (Makefile...)
- set the template default to None, and if it is None, call your function.
Hope that's all :)
r.
Cool. I debated which email address to use. This is the one I use for most Python stuff. But I don't always check it when I get really busy.
On Wed, Jul 9, 2008 at 8:41 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
OK, I think this is working and the changeset is on my repo.
It works, it is in the main repo now, welcome aboard!
I have also added your email address to 'Project members' at sfepy.org.
r.
Alright, one more mercurial question (for now). How do I purge my repo? I tried: hg purge --print http://freehg.sympy.org/u/ryankrauss/sfepy/
after adding
On Wed, Jul 9, 2008 at 7:16 AM, Ondrej Certik ond...@certik.cz wrote:
[extensions] hgext.purge= #or, if purge.py not in the hgext dir: #purge=/path/to/purge.py
to my .hgrc, but it complains that: http:/freehg.sympy.org/u/ryankrauss/sfepy: No such file or directory
Ryan
On Wed, Jul 9, 2008 at 2:10 PM, Ryan Krauss ryan...@gmail.com wrote:
OK, so sorry mercurial is taking me so long to grasp. I don't know what the problem is. It seems quite powerful. I have tried skimming their tutorials. I guess I need to set aside some time and work through their documentation in detail.
But I have successfully pushed changes onto my repo. I screwed up just a bit and didn't and the single quotes to the list of files the first time. So tha this:
hg ci -m script/config.py
also included a change in site_cfg_template.py in my changeset. I think I made the same change as Robert, so hopefully this won't make a big mess.
The only problem is that I pushed onto my repo before locally doing a roll back and then doing: hg ci -m 'script/config.py'
I then forced a push onto the repo and the repo kept the original changeset that included site_cfg_template.py and added a second one with what it calls 0 changes (it looks exacly like the first).
I promise to read through the mercurial docs before I ask any more mercurial related questions (and I really am interested in learning it).
You can simply purge delete the repo at freehg and start over.
Please ask mercurial quesitons, it's easy for us to answer. Robert will answer this one.
On to the actual content of my change: it might be more hassle than it is worth and Robert's change to the defaul of numpy_prefix probably makes it unnecessary, but I think I have successfully made config.py find the numpy dir that is actually loaded by python. The only way I could see it going wrong is if the user deliberately alters sys.path in their scripts. I don't really have much time invested in this, so it is no big deal if we decide it creates more problems than it solves. It does give us the option of allowing a truly general numpy/core/include location though (i.e. it doesn't have to be of the form /*/usr/$ARCHLIB/ or whatever.
Thanks for your help and especially your patience with Mercurial,
On Wed, Jul 9, 2008 at 2:14 PM, Ryan Krauss ryan...@gmail.com wrote:
Ondrej's quickstart is very helpful. Thanks for that.
Thanks. I'd appreciate all comments, because I wrote the quick start exactly for people like you so that they can start hacking in 5 minutes.
So tell me your impressions, what was difficult, etc, so that we can improve it.
Ondrej
On Wed, Jul 9, 2008 at 2:37 PM, Ryan Krauss ryan...@gmail.com wrote:
Alright, one more mercurial question (for now). How do I purge my repo? I tried: hg purge --print http://freehg.sympy.org/u/ryankrauss/sfepy/
after adding
On Wed, Jul 9, 2008 at 7:16 AM, Ondrej Certik ond...@certik.cz wrote:
[extensions] hgext.purge= #or, if purge.py not in the hgext dir: #purge=/path/to/purge.py
to my .hgrc, but it complains that: http:/freehg.sympy.org/u/ryankrauss/sfepy: No such file or directory
You need to delete it completely using the web interface (edit->delete) and create it again.
Ondrej
Ryan Krauss wrote:
OK, so sorry mercurial is taking me so long to grasp. I don't know what the problem is. It seems quite powerful. I have tried skimming their tutorials. I guess I need to set aside some time and work through their documentation in detail.
But I have successfully pushed changes onto my repo. I screwed up just a bit and didn't and the single quotes to the list of files the first time. So tha this:
hg ci -m script/config.py
also included a change in site_cfg_template.py in my changeset. I think I made the same change as Robert, so hopefully this won't make a big mess.
The only problem is that I pushed onto my repo before locally doing a roll back and then doing: hg ci -m 'script/config.py'
You meant probably something like:
hg ci -m 'added numpy dir search' script/config.py
the text after -m is the log message, then is the list of files you wish to commit.
I then forced a push onto the repo and the repo kept the original changeset that included site_cfg_template.py and added a second one with what it calls 0 changes (it looks exacly like the first).
I promise to read through the mercurial docs before I ask any more mercurial related questions (and I really am interested in learning it).
Well, it took me some time to get used to it, too, don't worry. I will integrate your FindinPath function and, if it works for me, push it into the main repo in a correct way, so then remove your local copy and clone a fresh copy of the main repo. OK?
On to the actual content of my change: it might be more hassle than it is worth and Robert's change to the defaul of numpy_prefix probably makes it unnecessary, but I think I have successfully made config.py find the numpy dir that is actually loaded by python. The only way I could see it going wrong is if the user deliberately alters sys.path in their scripts. I don't really have much time invested in this, so it is no big deal if we decide it creates more problems than it solves. It does give us the option of allowing a truly general numpy/core/include location though (i.e. it doesn't have to be of the form /*/usr/$ARCHLIB/ or whatever.
yes, it simplifies things.
thanks for your contribution! r.
Ondrej's quickstart is very helpful. Thanks for that.
Ryan
On Wed, Jul 9, 2008 at 12:17 AM, Ondrej Certik ond...@certik.cz wrote:
Hi Ryan!
On Wed, Jul 9, 2008 at 5:55 AM, Ryan Krauss ryan...@gmail.com wrote:
I am having trouble creating my hg repository. I created an account on http://freehg.sympy.org/u/ryankrauss/sfepy/
and then tried pushing to http://freehg.sympy.org/u/ryankrauss/sfepy/
this uploaded everything from my local hg directory, but it didn't include my latest changes. In fact, the script/config.py file in the repository isn't the same as the one on my harddrive.
How do I commit my own changes to my repository? Was I supposed to do something to it before I made any changes to my local directory?
Did you commit the changes? Follow e.g. the quick-start tutorial:
http://docs.sympy.org/sympy-patches-tutorial.html#quick-start
and type "hg vi" at the end -- this will show the contens of your repository, so you can see what is in and what is not.
Ondrej
participants (3)
-
Ondrej Certik -
Robert Cimrman -
Ryan Krauss