I am trying to create a .mesh file as an input to SfePy, and all the links I can find for it in google are broken, for example: http://www-rocq.inria.fr/gamma/medit
Looking at simple.mesh, the format seems fairly straight forward. After a couple of header lines, it seems to contain coordinates of vertices. I assume this are X Y Z, but I don't understand the 4th column which is always 0. Then there are a bunch of lines describing tetrahedrons. I assume these are being described based on numbers assigned to vertices. But again there is an extra final column I don't understand. One tetrahedron row seems to contain 4 vertices and then the number 6. What does the 6 represent?
So, I am slightly stuck. Can anyone direct me to documentation on .mesh files? Also, are there free utilities or Python scripts for generating them? I don't want to reinvent the wheel and might go a little crazy trying to visualize too many tetrahedra. I don't want to reinvent the wheel.
Ryan
On Fri, Jun 20, 2008 at 11:09 PM, Ryan Krauss <ryan...@gmail.com> wrote:
I am trying to create a .mesh file as an input to SfePy, and all the links I can find for it in google are broken, for example: http://www-rocq.inria.fr/gamma/medit
Looking at simple.mesh, the format seems fairly straight forward. After a couple of header lines, it seems to contain coordinates of vertices. I assume this are X Y Z, but I don't understand the 4th column which is always 0. Then there are a bunch of lines describing tetrahedrons. I assume these are being described based on numbers assigned to vertices. But again there is an extra final column I don't understand. One tetrahedron row seems to contain 4 vertices and then the number 6. What does the 6 represent?
So, I am slightly stuck. Can anyone direct me to documentation on .mesh files? Also, are there free utilities or Python scripts for generating them? I don't want to reinvent the wheel and might go a little crazy trying to visualize too many tetrahedra. I don't want to reinvent the wheel.
Hi,
thanks for your interest. I am at a conference, so just a quick reply:
You can use convert.py, that calls tetgen and outputs the mesh in a tetgen format, that sfepy can read.
You can also use script/blockgen.py, that can output the .mesh format as well. And I think sfepy is able to convert between these formats as well.
Let us know if you still cannot figure it out, we'll help.
Ondrej
Thanks Ondrej. TetGen seems to be well documented and I think I have it and TetView correctly installed already (under 15 minutes).
On Sat, Jun 21, 2008 at 3:48 AM, Ondrej Certik <ond...@certik.cz> wrote:
On Fri, Jun 20, 2008 at 11:09 PM, Ryan Krauss <ryan...@gmail.com> wrote:
I am trying to create a .mesh file as an input to SfePy, and all the links I can find for it in google are broken, for example: http://www-rocq.inria.fr/gamma/medit
Looking at simple.mesh, the format seems fairly straight forward. After a couple of header lines, it seems to contain coordinates of vertices. I assume this are X Y Z, but I don't understand the 4th column which is always 0. Then there are a bunch of lines describing tetrahedrons. I assume these are being described based on numbers assigned to vertices. But again there is an extra final column I don't understand. One tetrahedron row seems to contain 4 vertices and then the number 6. What does the 6 represent?
So, I am slightly stuck. Can anyone direct me to documentation on .mesh files? Also, are there free utilities or Python scripts for generating them? I don't want to reinvent the wheel and might go a little crazy trying to visualize too many tetrahedra. I don't want to reinvent the wheel.
Hi,
thanks for your interest. I am at a conference, so just a quick reply:
You can use convert.py, that calls tetgen and outputs the mesh in a tetgen format, that sfepy can read.
You can also use script/blockgen.py, that can output the .mesh format as well. And I think sfepy is able to convert between these formats as well.
Let us know if you still cannot figure it out, we'll help.
Ondrej
On Sat, Jun 21, 2008 at 3:08 PM, Ryan Krauss <ryan...@gmail.com> wrote:
Thanks Ondrej. TetGen seems to be well documented and I think I have it and TetView correctly installed already (under 15 minutes).
Yes. Unfortunately tetgen is not free, so we are still looking for a truly opensource (preferably BSD) algernative.
Ondrej
I saw that. It meets my current needs for research and non-commercial use, but something free in the BSD sense would be nice.
I assume this is the convert.py you were referring to: http://code.google.com/p/femgeom/source/browse/trunk/examples/grain/convert....
I couldn't find convert.py in the tarball of SfePy itself.
Ryan
On Sat, Jun 21, 2008 at 8:26 AM, Ondrej Certik <ond...@certik.cz> wrote:
On Sat, Jun 21, 2008 at 3:08 PM, Ryan Krauss <ryan...@gmail.com> wrote:
Thanks Ondrej. TetGen seems to be well documented and I think I have it and TetView correctly installed already (under 15 minutes).
Yes. Unfortunately tetgen is not free, so we are still looking for a truly opensource (preferably BSD) algernative.
Ondrej
On Sat, Jun 21, 2008 at 3:52 PM, Ryan Krauss <ryan...@gmail.com> wrote:
I saw that. It meets my current needs for research and non-commercial use, but something free in the BSD sense would be nice.
Yep. Or at least GPL. I also only need it for a research use only, but I am not motivated at all to contribute to the tetgen if I am not allowed to use it freely.
I assume this is the convert.py you were referring to: http://code.google.com/p/femgeom/source/browse/trunk/examples/grain/convert....
that is my old file. Use our hg version, the convert.py is here:
http://hg.sympy.org/sfepy/file/853a1d9e1ab2/convert.py
Ondrej
Thanks for your help and quick replies. I have a stupid question: how do I download convert.py from that link? Do I need to install Mercurial? I can't find a link that will let me display and/or download the code in raw text so I can save it or copy and paste it without extralines and line #'s.
Thanks again,
Ryan
On Sat, Jun 21, 2008 at 8:57 AM, Ondrej Certik <ond...@certik.cz> wrote:
On Sat, Jun 21, 2008 at 3:52 PM, Ryan Krauss <ryan...@gmail.com> wrote:
I saw that. It meets my current needs for research and non-commercial use, but something free in the BSD sense would be nice.
Yep. Or at least GPL. I also only need it for a research use only, but I am not motivated at all to contribute to the tetgen if I am not allowed to use it freely.
I assume this is the convert.py you were referring to: http://code.google.com/p/femgeom/source/browse/trunk/examples/grain/convert....
that is my old file. Use our hg version, the convert.py is here:
http://hg.sympy.org/sfepy/file/853a1d9e1ab2/convert.py
Ondrej
OK, I think I am almost there. Thanks to emacs regexp search and replace, I was able to fairly easily convert my hackish copy and paste of the code of convert.py as displayed on my screen to the attached python file. But it won't run because I don't have the geom module. Is this from sfepy svn or somewhere else?
Oh, I think I see it now. The geom module and gmsh look like they are part of femgeom. Is that right or is svn sfepy the right answer?
Thanks again,
Ryan
On Sat, Jun 21, 2008 at 9:06 AM, Ryan Krauss <ryan...@gmail.com> wrote:
Thanks for your help and quick replies. I have a stupid question: how do I download convert.py from that link? Do I need to install Mercurial? I can't find a link that will let me display and/or download the code in raw text so I can save it or copy and paste it without extralines and line #'s.
Thanks again,
Ryan
On Sat, Jun 21, 2008 at 8:57 AM, Ondrej Certik <ond...@certik.cz> wrote:
On Sat, Jun 21, 2008 at 3:52 PM, Ryan Krauss <ryan...@gmail.com> wrote:
I saw that. It meets my current needs for research and non-commercial use, but something free in the BSD sense would be nice.
Yep. Or at least GPL. I also only need it for a research use only, but I am not motivated at all to contribute to the tetgen if I am not allowed to use it freely.
I assume this is the convert.py you were referring to: http://code.google.com/p/femgeom/source/browse/trunk/examples/grain/convert....
that is my old file. Use our hg version, the convert.py is here:
http://hg.sympy.org/sfepy/file/853a1d9e1ab2/convert.py
Ondrej
On Sat, Jun 21, 2008 at 4:17 PM, Ryan Krauss <ryan...@gmail.com> wrote:
OK, I think I am almost there. Thanks to emacs regexp search and replace, I was able to fairly easily convert my hackish copy and paste of the code of convert.py as displayed on my screen to the attached python file. But it won't run because I don't have the geom module. Is this from sfepy svn or somewhere else?
Oh, I think I see it now. The geom module and gmsh look like they are part of femgeom. Is that right or is svn sfepy the right answer?
To answer your first question, click on the raw link and you get:
http://hg.sympy.org/sfepy/raw-file/853a1d9e1ab2/convert.py
To answer your second question, yes, you need to install mercurial ("apt-get install mercurial" if you use Debian/Ubuntu). This is also needed, so that you can send patches and fixes back to us. :)
Then do
hg clone http://hg.sympy.org/sfepy
and all things will be in there, no external dependencies besides scipy+numpy.
Ondrej
cool. Thanks again. I thought I tried the raw link. I will go the mercurial route.
On Sat, Jun 21, 2008 at 9:50 AM, Ondrej Certik <ond...@certik.cz> wrote:
On Sat, Jun 21, 2008 at 4:17 PM, Ryan Krauss <ryan...@gmail.com> wrote:
OK, I think I am almost there. Thanks to emacs regexp search and replace, I was able to fairly easily convert my hackish copy and paste of the code of convert.py as displayed on my screen to the attached python file. But it won't run because I don't have the geom module. Is this from sfepy svn or somewhere else?
Oh, I think I see it now. The geom module and gmsh look like they are part of femgeom. Is that right or is svn sfepy the right answer?
To answer your first question, click on the raw link and you get:
http://hg.sympy.org/sfepy/raw-file/853a1d9e1ab2/convert.py
To answer your second question, yes, you need to install mercurial ("apt-get install mercurial" if you use Debian/Ubuntu). This is also needed, so that you can send patches and fixes back to us. :)
Then do
hg clone http://hg.sympy.org/sfepy
and all things will be in there, no external dependencies besides scipy+numpy.
Ondrej
I ran into a little trouble with the hg version:
In [1]: run simple.py input/poisson.py _um=<module 'scikits.umfpack._umfpack' from '/usr/lib/python2.5/site-packages/scikits/umfpack/_umfpack.pyc'> sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs'] sfe: reading mesh... sfe: ...done in 0.02 s sfe: setting up domain edges... sfe: ...done in 0.01 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Gamma_Right region_4 sfe: leaf Omega region_1000 sfe: leaf Gamma_Left region_03 sfe: ...done in 0.04 s sfe: equation "Temperature": sfe: dw_laplace.i1.Omega( coef.val, s, t ) = 0 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: (300, 300) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 3538 (3.93e-02% fill) sfe: updating materials... sfe: coef sfe: ...done in 0.00 s just before UMFPACK_CONTROL just after UMFPACK_CONTROL UMFPACK_CONTROL=20 sfe: nls: iter: 0, residual: 1.176265e-01 (rel: 1.000000e+00) sfe: rezidual: 0.00 [s] sfe: solve: 0.00 [s] sfe: matrix: 0.01 [s] sfe: nls: iter: 1, residual: 9.921083e-17 (rel: 8.434392e-16)
<type 'exceptions.AttributeError'> Traceback (most recent call last)
/home/ryan/svn/sfepy/simple.py in <module>() 107 108 if __name__ == '__main__': --> 109 main() 110 111
/home/ryan/svn/sfepy/simple.py in main() 100 setOutputPrefix( opts.outputPrefix ) 101 --> 102 dpb, vecDP, data = solveDirect( conf, options ) 103 104 if hasattr( opts, 'postProcessHookFinal' ): # User postprocessing.
/home/ryan/svn/sfepy/sfe/solvers/generic.py in solveDirect(conf, options) 227 # Stationary problem. 228 state, data = solveStationaryOP( pb, conf, --> 229 postProcessHook = postProcessHook ) 230 231 if options.dump:
/home/ryan/svn/sfepy/sfe/solvers/generic.py in solveStationaryOP(problem, options, saveResults, ts, postProcessHook) 170 171 if saveResults: --> 172 if options.outputFileNameTrunk: 173 ofnTrunk = options.outputFileNameTrunk 174 else:
<type 'exceptions.AttributeError'>: 'ProblemConf' object has no attribute 'outputFileNameTrunk' WARNING: Failure executing file: <simple.py>
It appears that the problem is that these two lines of generic.py don't seem to agree:
/home/ryan/svn/sfepy/sfe/solvers/generic.py(229)solveDirect() 228 state, data = solveStationaryOP( pb, conf, --> 229 postProcessHook = postProcessHook ) 230
ipdb> s --Call--
/home/ryan/svn/sfepy/sfe/solvers/generic.py(165)solveStationaryOP() 164 # c: 13.06.2008, r: 13.06.2008 --> 165 def solveStationaryOP( problem, options, saveResults = True, ts = None, 166 postProcessHook = None ):
The call to solveStationaryOP passes in pb, conf, ... while the function definition expects problem, options, ...
Is this a bug?
Here is the output of runTests.py: In [5]: run runTests.py <<< directory: tests, test files: 22 tests/test_assembling.py +++ test_vector_matrix: ok tests/test_base.py +++ test_structAdd: ok +++ test_structIAdd: ok tests/test_elasticity_small_strain.py +++ test_get_solution: ok +++ test_linear_terms: ok tests/test_input_kostka.py +++ test_input: ok tests/test_input_le.py +++ test_input: ok tests/test_input_navier_stokes.py +++ test_input: ok tests/test_input_octahedron.py nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 +++ test_input: ok tests/test_input_pfdpm_permeability.py +++ test_input: ok tests/test_input_poisson.py +++ test_input: ok tests/test_input_sinbc.py +++ test_input: ok tests/test_input_time_poisson.py +++ test_input: ok tests/test_io.py +++ test_recursiveDictHDF5: ok /usr/lib/python2.5/site-packages/scipy/sparse/compressed.py:28: DeprecationWarning: dims= is deprecated, use shape= instead warn("dims= is deprecated, use shape= instead", DeprecationWarning) +++ test_sparseMatrixHDF5: ok tests/test_lcbc_2d.py +++ test_linearRigidBodyBC: ok tests/test_lcbc_3d.py +++ test_linearRigidBodyBC: ok tests/test_linear_solvers.py --- test_solvers: failed! tests/test_meshio.py nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:01 +++ test_readMeshes: ok +++ test_compareSameMeshes: ok tests/test_msm_laplace.py +++ test_msm_laplace: ok tests/test_parsing.py +++ test_parseEquations: ok +++ test_parseRegions: ok tests/test_periodic_bc_2d.py +++ test_pbc: ok tests/test_periodic_bc_3d.py +++ test_pbc: ok tests/test_quadratures.py +++ test_problemCreation: ok tests/test_term_consistency.py +++ test_consistency_d_dw: ok 22 test file(s) executed in 34.30 s, 1 failure(s) of 27 test(s)
On Sat, Jun 21, 2008 at 10:51 AM, Ryan Krauss <ryan...@gmail.com> wrote:
cool. Thanks again. I thought I tried the raw link. I will go the mercurial route.
On Sat, Jun 21, 2008 at 9:50 AM, Ondrej Certik <ond...@certik.cz> wrote:
On Sat, Jun 21, 2008 at 4:17 PM, Ryan Krauss <ryan...@gmail.com> wrote:
OK, I think I am almost there. Thanks to emacs regexp search and replace, I was able to fairly easily convert my hackish copy and paste of the code of convert.py as displayed on my screen to the attached python file. But it won't run because I don't have the geom module. Is this from sfepy svn or somewhere else?
Oh, I think I see it now. The geom module and gmsh look like they are part of femgeom. Is that right or is svn sfepy the right answer?
To answer your first question, click on the raw link and you get:
http://hg.sympy.org/sfepy/raw-file/853a1d9e1ab2/convert.py
To answer your second question, yes, you need to install mercurial ("apt-get install mercurial" if you use Debian/Ubuntu). This is also needed, so that you can send patches and fixes back to us. :)
Then do
hg clone http://hg.sympy.org/sfepy
and all things will be in there, no external dependencies besides scipy+numpy.
Ondrej
On 6/21/08, Ryan Krauss <ryan...@gmail.com> wrote:
I ran into a little trouble with the hg version:
In [1]: run simple.py input/poisson.py _um=<module 'scikits.umfpack._umfpack' from '/usr/lib/python2.5/site-packages/scikits/umfpack/_umfpack.pyc'> sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs'] sfe: reading mesh... sfe: ...done in 0.02 s sfe: setting up domain edges... sfe: ...done in 0.01 s sfe: setting up domain faces... sfe: ...done in 0.01 s sfe: creating regions... sfe: leaf Gamma_Right region_4 sfe: leaf Omega region_1000 sfe: leaf Gamma_Left region_03 sfe: ...done in 0.04 s sfe: equation "Temperature": sfe: dw_laplace.i1.Omega( coef.val, s, t ) = 0 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: (300, 300) sfe: assembling matrix graph... sfe: ...done in 0.00 s sfe: matrix structural nonzeros: 3538 (3.93e-02% fill) sfe: updating materials... sfe: coef sfe: ...done in 0.00 s just before UMFPACK_CONTROL just after UMFPACK_CONTROL UMFPACK_CONTROL=20 sfe: nls: iter: 0, residual: 1.176265e-01 (rel: 1.000000e+00) sfe: rezidual: 0.00 [s] sfe: solve: 0.00 [s] sfe: matrix: 0.01 [s] sfe: nls: iter: 1, residual: 9.921083e-17 (rel: 8.434392e-16)
<type 'exceptions.AttributeError'> Traceback (most recent call last)
/home/ryan/svn/sfepy/simple.py in <module>() 107 108 if __name__ == '__main__': --> 109 main() 110 111
/home/ryan/svn/sfepy/simple.py in main() 100 setOutputPrefix( opts.outputPrefix ) 101 --> 102 dpb, vecDP, data = solveDirect( conf, options ) 103 104 if hasattr( opts, 'postProcessHookFinal' ): # User postprocessing.
/home/ryan/svn/sfepy/sfe/solvers/generic.py in solveDirect(conf, options) 227 # Stationary problem. 228 state, data = solveStationaryOP( pb, conf, --> 229 postProcessHook = postProcessHook ) 230 231 if options.dump:
/home/ryan/svn/sfepy/sfe/solvers/generic.py in solveStationaryOP(problem, options, saveResults, ts, postProcessHook) 170 171 if saveResults: --> 172 if options.outputFileNameTrunk: 173 ofnTrunk = options.outputFileNameTrunk 174 else:
<type 'exceptions.AttributeError'>: 'ProblemConf' object has no attribute 'outputFileNameTrunk' WARNING: Failure executing file: <simple.py>
It appears that the problem is that these two lines of generic.py don't seem to agree:
/home/ryan/svn/sfepy/sfe/solvers/generic.py(229)solveDirect() 228 state, data = solveStationaryOP( pb, conf, --> 229 postProcessHook = postProcessHook ) 230
ipdb> s --Call--
/home/ryan/svn/sfepy/sfe/solvers/generic.py(165)solveStationaryOP() 164 # c: 13.06.2008, r: 13.06.2008 --> 165 def solveStationaryOP( problem, options, saveResults = True, ts = None, 166 postProcessHook = None ):
The call to solveStationaryOP passes in pb, conf, ... while the function definition expects problem, options, ...
Is this a bug?
Yes, it is definitely a bug. I am sure Robert will answer this one.
Here is the output of runTests.py: In [5]: run runTests.py <<< directory: tests, test files: 22 tests/test_assembling.py +++ test_vector_matrix: ok tests/test_base.py +++ test_structAdd: ok +++ test_structIAdd: ok tests/test_elasticity_small_strain.py +++ test_get_solution: ok +++ test_linear_terms: ok tests/test_input_kostka.py +++ test_input: ok tests/test_input_le.py +++ test_input: ok tests/test_input_navier_stokes.py +++ test_input: ok tests/test_input_octahedron.py nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:00 +++ test_input: ok tests/test_input_pfdpm_permeability.py +++ test_input: ok tests/test_input_poisson.py +++ test_input: ok tests/test_input_sinbc.py +++ test_input: ok tests/test_input_time_poisson.py +++ test_input: ok tests/test_io.py +++ test_recursiveDictHDF5: ok /usr/lib/python2.5/site-packages/scipy/sparse/compressed.py:28: DeprecationWarning: dims= is deprecated, use shape= instead warn("dims= is deprecated, use shape= instead", DeprecationWarning) +++ test_sparseMatrixHDF5: ok tests/test_lcbc_2d.py +++ test_linearRigidBodyBC: ok tests/test_lcbc_3d.py +++ test_linearRigidBodyBC: ok tests/test_linear_solvers.py --- test_solvers: failed! tests/test_meshio.py nodes: 100% |############################################| Time: 00:00:00 elements: 100% |#########################################| Time: 00:00:01 +++ test_readMeshes: ok +++ test_compareSameMeshes: ok tests/test_msm_laplace.py +++ test_msm_laplace: ok tests/test_parsing.py +++ test_parseEquations: ok +++ test_parseRegions: ok tests/test_periodic_bc_2d.py +++ test_pbc: ok tests/test_periodic_bc_3d.py +++ test_pbc: ok tests/test_quadratures.py +++ test_problemCreation: ok tests/test_term_consistency.py +++ test_consistency_d_dw: ok 22 test file(s) executed in 34.30 s, 1 failure(s) of 27 test(s)
There is one failing test. Could you please send the output of
./runTests.py --debug
?
Thanks, Ondrej
Hi Ryan,
Ondrej gave you some answers already, but to clarify more...
Ryan Krauss wrote:
I am trying to create a .mesh file as an input to SfePy, and all the links I can find for it in google are broken, for example: http://www-rocq.inria.fr/gamma/medit
http://www.ann.jussieu.fr/~frey/logiciels/medit.html
Unfortunately it is in French...
Looking at simple.mesh, the format seems fairly straight forward. After a couple of header lines, it seems to contain coordinates of vertices. I assume this are X Y Z, but I don't understand the 4th column which is always 0. Then there are a bunch of lines describing tetrahedrons. I assume these are being described based on numbers assigned to vertices. But again there is an extra final column I don't understand. One tetrahedron row seems to contain 4 vertices and then the number 6. What does the 6 represent?
The extra column after the vertices enables you to assign a vertex to some vertex-related subdomain. In SfePy, it is not used, but medit needs it, so we use zero.
The extra column after the element nodes defines a group to which the element belongs. This is used in SfePy, for example, to define regions for equations, boundary conditions, etc. I use it often to assign different material properties to subdomains.
So, I am slightly stuck. Can anyone direct me to documentation on .mesh files? Also, are there free utilities or Python scripts for generating them? I don't want to reinvent the wheel and might go a little crazy trying to visualize too many tetrahedra. I don't want to reinvent the wheel.
You can use also the text (legacy) VTK files to define your meshes, see www.vtk.org/pdf/file-formats.pdf, page 9.
cheers, r.
Ondrej Certik wrote:
On 6/21/08, Ryan Krauss <ryan...@gmail.com> wrote:
I ran into a little trouble with the hg version:
The call to solveStationaryOP passes in pb, conf, ... while the function definition expects problem, options, ...
Exactly.
Is this a bug?
Yes, it is definitely a bug. I am sure Robert will answer this one.
Yep. It was easy to fix, thanks for reporting it!
Here is the output of runTests.py: In [5]: run runTests.py <<< directory: tests, test files: 22 .. tests/test_lcbc_2d.py +++ test_linearRigidBodyBC: ok tests/test_lcbc_3d.py +++ test_linearRigidBodyBC: ok tests/test_linear_solvers.py --- test_solvers: failed! tests/test_meshio.py ... +++ test_consistency_d_dw: ok 22 test file(s) executed in 34.30 s, 1 failure(s) of 27 test(s)
There is one failing test. Could you please send the output of
./runTests.py --debug
or './runTests.py --debug tests/test_linear_solvers.py' to be more specific. I suspect you do not have some of the solvers installed. If this is the case, I will have to fix the test...
r.
Here is the output of runTests.py --debug tests/test_linear_solvers.py:
In [2]: run runTests.py --debug tests/test_linear_solvers.py <<< tests/test_linear_solvers.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs'] sfe: warning: left over: ['outputName', 'TestCommon'] sfe: reading mesh... sfe: ...done in 0.93 s sfe: setting up domain edges... sfe: ...done in 0.69 s sfe: setting up domain faces... sfe: ...done in 0.52 s sfe: creating regions... sfe: leaf Gamma_Right region__0 sfe: leaf Omega region__1 sfe: leaf Gamma_Left region__2 sfe: ...done in 0.79 s sfe: equation "Temperature": sfe: dw_laplace.i1.Omega( coef.val, s, t ) = 0 sfe: describing geometries... sfe: ...done in 0.05 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls101 sfe: matrix shape: (9511, 9511) sfe: assembling matrix graph... sfe: ...done in 0.09 s sfe: matrix structural nonzeros: 132239 (1.46e-03% fill) sfe: updating materials... sfe: coef sfe: ...done in 0.00 s
test instance prepared (1 test(s)) ... dls100 ls.umfpack ... matrix size: (9511, 9511) ... nnz: 132239 just before UMFPACK_CONTROL just after UMFPACK_CONTROL UMFPACK_CONTROL=20 sfe: nls: iter: 0, residual: 3.587850e+00 (rel: 1.000000e+00) sfe: rezidual: 0.02 [s] sfe: solve: 2.15 [s] sfe: matrix: 0.05 [s] sfe: nls: iter: 1, residual: 4.177710e-15 (rel: 1.164405e-15) ... rezidual: 0.02 [s] ... solve: 2.15 [s] ... matrix: 0.05 [s] ... condition: 0, err0: 3.588e+00, err: 4.178e-15 ... ls101 ls.pyamg ruge_stuben_solver ... matrix size: (9511, 9511) ... nnz: 132239 sfe: cannot import pyamg! ... solver failed: ... No module named pyamg ... ls102 ls.pyamg smoothed_aggregation_solver ... matrix size: (9511, 9511) ... nnz: 132239 sfe: cannot import pyamg! ... solver failed: ... No module named pyamg ... ls110 ls.scipy_iterative cg ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva ... ls111 ls.scipy_iterative bicgstab ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva ... ls112 ls.scipy_iterative qmr ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva ... solution times: ... 2.15 : dls100 ls.umfpack ... 10000000000.00 : ls101 ls.pyamg ruge_stuben_solver ... 10000000000.00 : ls102 ls.pyamg smoothed_aggregation_solver ... 10000000000.00 : ls110 ls.scipy_iterative cg ... 10000000000.00 : ls111 ls.scipy_iterative bicgstab ... 10000000000.00 : ls112 ls.scipy_iterative qmr --- test_solvers: failed! !!! 1 test failed 1 test file executed in 3.14 s, 1 failure(s) of 1 test(s)
Ryan
On Sun, Jun 22, 2008 at 10:51 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ondrej Certik wrote:
On 6/21/08, Ryan Krauss <ryan...@gmail.com> wrote:
I ran into a little trouble with the hg version:
The call to solveStationaryOP passes in pb, conf, ... while the function definition expects problem, options, ...
Exactly.
Is this a bug?
Yes, it is definitely a bug. I am sure Robert will answer this one.
Yep. It was easy to fix, thanks for reporting it!
Here is the output of runTests.py: In [5]: run runTests.py <<< directory: tests, test files: 22 .. tests/test_lcbc_2d.py +++ test_linearRigidBodyBC: ok tests/test_lcbc_3d.py +++ test_linearRigidBodyBC: ok tests/test_linear_solvers.py --- test_solvers: failed! tests/test_meshio.py ... +++ test_consistency_d_dw: ok 22 test file(s) executed in 34.30 s, 1 failure(s) of 27 test(s)
There is one failing test. Could you please send the output of
./runTests.py --debug
or './runTests.py --debug tests/test_linear_solvers.py' to be more specific. I suspect you do not have some of the solvers installed. If this is the case, I will have to fix the test...
r.
On Mon, Jun 23, 2008 at 12:38 AM, Ryan Krauss <ryan...@gmail.com> wrote:
Here is the output of runTests.py --debug tests/test_linear_solvers.py:
In [2]: run runTests.py --debug tests/test_linear_solvers.py <<< tests/test_linear_solvers.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs'] sfe: warning: left over: ['outputName', 'TestCommon'] sfe: reading mesh... sfe: ...done in 0.93 s sfe: setting up domain edges... sfe: ...done in 0.69 s sfe: setting up domain faces... sfe: ...done in 0.52 s sfe: creating regions... sfe: leaf Gamma_Right region__0 sfe: leaf Omega region__1 sfe: leaf Gamma_Left region__2 sfe: ...done in 0.79 s sfe: equation "Temperature": sfe: dw_laplace.i1.Omega( coef.val, s, t ) = 0 sfe: describing geometries... sfe: ...done in 0.05 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls101 sfe: matrix shape: (9511, 9511) sfe: assembling matrix graph... sfe: ...done in 0.09 s sfe: matrix structural nonzeros: 132239 (1.46e-03% fill) sfe: updating materials... sfe: coef sfe: ...done in 0.00 s
test instance prepared (1 test(s)) ... dls100 ls.umfpack ... matrix size: (9511, 9511) ... nnz: 132239 just before UMFPACK_CONTROL just after UMFPACK_CONTROL UMFPACK_CONTROL=20 sfe: nls: iter: 0, residual: 3.587850e+00 (rel: 1.000000e+00) sfe: rezidual: 0.02 [s] sfe: solve: 2.15 [s] sfe: matrix: 0.05 [s] sfe: nls: iter: 1, residual: 4.177710e-15 (rel: 1.164405e-15) ... rezidual: 0.02 [s] ... solve: 2.15 [s] ... matrix: 0.05 [s] ... condition: 0, err0: 3.588e+00, err: 4.178e-15 ... ls101 ls.pyamg ruge_stuben_solver ... matrix size: (9511, 9511) ... nnz: 132239 sfe: cannot import pyamg! ... solver failed: ... No module named pyamg ... ls102 ls.pyamg smoothed_aggregation_solver ... matrix size: (9511, 9511) ... nnz: 132239 sfe: cannot import pyamg! ... solver failed: ... No module named pyamg ... ls110 ls.scipy_iterative cg ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva ... ls111 ls.scipy_iterative bicgstab ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva ... ls112 ls.scipy_iterative qmr ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva ... solution times: ... 2.15 : dls100 ls.umfpack ... 10000000000.00 : ls101 ls.pyamg ruge_stuben_solver ... 10000000000.00 : ls102 ls.pyamg smoothed_aggregation_solver ... 10000000000.00 : ls110 ls.scipy_iterative cg ... 10000000000.00 : ls111 ls.scipy_iterative bicgstab ... 10000000000.00 : ls112 ls.scipy_iterative qmr --- test_solvers: failed! !!! 1 test failed 1 test file executed in 3.14 s, 1 failure(s) of 1 test(s)
Thanks, seems like a bug in sfepy, that it requires svn version of scipy, while it should only require the released version (everything else being only optional). We fixed most of bugs like these, but sometimes something creeps in.
Ondrej
Ryan Krauss wrote:
Here is the output of runTests.py --debug tests/test_linear_solvers.py: ... solver failed: ... No module named splinalg.isolva ... ls111 ls.scipy_iterative bicgstab ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolva
Thanks for the report, I have fixed the typo... isolva -> isolve
Could you retry now, please?
r.
Ondrej Certik wrote:
Thanks, seems like a bug in sfepy, that it requires svn version of scipy, while it should only require the released version (everything else being only optional). We fixed most of bugs like these, but sometimes something creeps in.
Yes, it is good to have people using different scipy versions to test the code. I use the SVN version, so sometimes something slips in.
r.
So, I thought it was a problem with my not using Mercurial correctly. So, I deleted my clone and re-cloned and am still getting the same error: No module named splinalg.isolve. Here is the full output:
In [4]: run runTests.py --debug tests/test_linear_solvers.py <<< tests/test_linear_solvers.py sfe: warning: other missing: ['functions', 'modules', 'epbc_[0-9]+|epbcs', 'lcbc_[0-9]+|lcbcs', 'nbc_[0-9]+|nbcs'] sfe: warning: left over: ['outputName', 'TestCommon'] sfe: reading mesh... sfe: ...done in 1.05 s sfe: setting up domain edges... sfe: ...done in 0.70 s sfe: setting up domain faces... sfe: ...done in 0.52 s sfe: creating regions... sfe: leaf Gamma_Right region__0 sfe: leaf Omega region__1 sfe: leaf Gamma_Left region__2 sfe: ...done in 0.79 s sfe: equation "Temperature": sfe: dw_laplace.i1.Omega( coef.val, s, t ) = 0 sfe: describing geometries... sfe: ...done in 0.05 s sfe: setting up dof connectivities... sfe: ...done in 0.00 s sfe: using solvers: nls: newton ls: ls101 sfe: matrix shape: (9511, 9511) sfe: assembling matrix graph... sfe: ...done in 0.09 s sfe: matrix structural nonzeros: 132239 (1.46e-03% fill) sfe: updating materials... sfe: coef sfe: ...done in 0.00 s
test instance prepared (1 test(s)) ... dls100 ls.umfpack ... matrix size: (9511, 9511) ... nnz: 132239 just before UMFPACK_CONTROL just after UMFPACK_CONTROL UMFPACK_CONTROL=20 sfe: nls: iter: 0, residual: 3.587850e+00 (rel: 1.000000e+00) sfe: rezidual: 0.02 [s] sfe: solve: 2.14 [s] sfe: matrix: 0.06 [s] sfe: nls: iter: 1, residual: 4.177710e-15 (rel: 1.164405e-15) ... rezidual: 0.02 [s] ... solve: 2.14 [s] ... matrix: 0.06 [s] ... condition: 0, err0: 3.588e+00, err: 4.178e-15 ... ls101 ls.pyamg ruge_stuben_solver ... matrix size: (9511, 9511) ... nnz: 132239 sfe: cannot import pyamg! ... solver failed: ... No module named pyamg ... ls102 ls.pyamg smoothed_aggregation_solver ... matrix size: (9511, 9511) ... nnz: 132239 sfe: cannot import pyamg! ... solver failed: ... No module named pyamg ... ls110 ls.scipy_iterative cg ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolve ... ls111 ls.scipy_iterative bicgstab ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolve ... ls112 ls.scipy_iterative qmr ... matrix size: (9511, 9511) ... nnz: 132239 ... solver failed: ... No module named splinalg.isolve ... solution times: ... 2.14 : dls100 ls.umfpack ... 10000000000.00 : ls101 ls.pyamg ruge_stuben_solver ... 10000000000.00 : ls102 ls.pyamg smoothed_aggregation_solver ... 10000000000.00 : ls110 ls.scipy_iterative cg ... 10000000000.00 : ls111 ls.scipy_iterative bicgstab ... 10000000000.00 : ls112 ls.scipy_iterative qmr --- test_solvers: failed! !!! 1 test failed 1 test file executed in 3.17 s, 1 failure(s) of 1 test(s)
I am running scipy svn from a month or so ago. I can easily update or install the previous revision, but I thought it was worth fighting through this to get rid of a bug:
In [5]: scipy.__version__ Out[5]: '0.7.0.dev3851'
Thanks for the on going help,
Ryan
On Mon, Jun 23, 2008 at 3:53 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ondrej Certik wrote:
Thanks, seems like a bug in sfepy, that it requires svn version of scipy, while it should only require the released version (everything else being only optional). We fixed most of bugs like these, but sometimes something creeps in.
Yes, it is good to have people using different scipy versions to test the code. I use the SVN version, so sometimes something slips in.
r.
Ryan Krauss wrote:
... solver failed: ... No module named splinalg.isolve I am running scipy svn from a month or so ago. I can easily update or install the previous revision, but I thought it was worth fighting through this to get rid of a bug:
In [5]: scipy.__version__ Out[5]: '0.7.0.dev3851'
Hum, where do you have iterative.py - in scipy/sparse/linalg/isolve/, or in scipy/splinalg/isolve/ or just in scipy/linalg The condition
if scipy.version.version == "0.6.0":
import scipy.linalg as la
else:
if scipy.version.version < '0.7.0.dev3998':
import scipy.splinalg.isolve as la
else:
import scipy.sparse.linalg.isolve as lain sfe/solvers/ls.py may be wrong...
r.
I can't find isolve anywhere. There is no linalg in scipy/sparse. There is no scipy/splinalg. And there is no isolve in scipy.linalg.
Here is the IPython tab completion of what is in scipy.linalg:
In [1]: scipy.linalg. scipy.linalg.LinAlgError scipy.linalg.expm scipy.linalg.Tester scipy.linalg.expm2 scipy.linalg.__all__ scipy.linalg.expm3 scipy.linalg.__class__ scipy.linalg.fblas scipy.linalg.__delattr__ scipy.linalg.flapack scipy.linalg.__dict__ scipy.linalg.flinalg scipy.linalg.__doc__ scipy.linalg.funm scipy.linalg.__file__ scipy.linalg.get_blas_funcs scipy.linalg.__getattribute__ scipy.linalg.gmres scipy.linalg.__hash__ scipy.linalg.hankel scipy.linalg.__init__ scipy.linalg.hessenberg scipy.linalg.__name__ scipy.linalg.inv scipy.linalg.__new__ scipy.linalg.iterative scipy.linalg.__path__ scipy.linalg.kron scipy.linalg.__reduce__ scipy.linalg.lapack scipy.linalg.__reduce_ex__ scipy.linalg.linalg_version scipy.linalg.__repr__ scipy.linalg.logm scipy.linalg.__setattr__ scipy.linalg.lstsq scipy.linalg.__str__ scipy.linalg.lu scipy.linalg.__version__ scipy.linalg.lu_factor scipy.linalg._flinalg scipy.linalg.lu_solve scipy.linalg._iterative scipy.linalg.matfuncs scipy.linalg.all_mat scipy.linalg.norm scipy.linalg.basic scipy.linalg.orth scipy.linalg.bench scipy.linalg.pinv scipy.linalg.bicg scipy.linalg.pinv2 scipy.linalg.bicgstab scipy.linalg.qmr scipy.linalg.blas scipy.linalg.qr scipy.linalg.calc_lwork scipy.linalg.qr_old scipy.linalg.cblas scipy.linalg.rq scipy.linalg.cg scipy.linalg.rsf2csf scipy.linalg.cgs scipy.linalg.schur scipy.linalg.cho_factor scipy.linalg.signm scipy.linalg.cho_solve scipy.linalg.sinhm scipy.linalg.cholesky scipy.linalg.sinm scipy.linalg.cholesky_banded scipy.linalg.solve scipy.linalg.clapack scipy.linalg.solve_banded scipy.linalg.coshm scipy.linalg.solveh_banded scipy.linalg.cosm scipy.linalg.sqrtm scipy.linalg.decomp scipy.linalg.svd scipy.linalg.det scipy.linalg.svdvals scipy.linalg.diagsvd scipy.linalg.tanhm scipy.linalg.eig scipy.linalg.tanm scipy.linalg.eig_banded scipy.linalg.test scipy.linalg.eigh scipy.linalg.toeplitz scipy.linalg.eigvals scipy.linalg.tri scipy.linalg.eigvals_banded scipy.linalg.tril scipy.linalg.eigvalsh scipy.linalg.triu
Do I have a scipy install problem or just an unanticipated svn revision? I am glad to try reinstalling my current revision of updating to current svn.
Thanks again,
Ryan
On Mon, Jun 23, 2008 at 9:30 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ryan Krauss wrote:
... solver failed: ... No module named splinalg.isolve I am running scipy svn from a month or so ago. I can easily update or install the previous revision, but I thought it was worth fighting through this to get rid of a bug:
In [5]: scipy.__version__ Out[5]: '0.7.0.dev3851'
Hum, where do you have iterative.py - in scipy/sparse/linalg/isolve/, or in scipy/splinalg/isolve/ or just in scipy/linalg The condition
if scipy.version.version == "0.6.0": import scipy.linalg as la else: if scipy.version.version < '0.7.0.dev3998': import scipy.splinalg.isolve as la else: import scipy.sparse.linalg.isolve as lain sfe/solvers/ls.py may be wrong...
r.
Ryan Krauss wrote:
I can't find isolve anywhere. There is no linalg in scipy/sparse. There is no scipy/splinalg. And there is no isolve in scipy.linalg.
Here is the IPython tab completion of what is in scipy.linalg:
In [1]: scipy.linalg. scipy.linalg.__new__ scipy.linalg.iterative
I see, your iterative.py is still in scipy.linalg. Could you, please, try editing sfe/solvers/ls.py: --- a/sfe/solvers/ls.py Mon Jun 23 10:49:07 2008 +0200 +++ b/sfe/solvers/ls.py Mon Jun 23 17:07:51 2008 +0200 @@ -71,7 +71,8 @@ class ScipyIterative( LinearSolver ): ## # c: 22.02.2008, r: 23.06.2008 def __init__( self, conf, **kwargs ): - if scipy.version.version == "0.6.0": + if (scipy.version.version == "0.6.0") or + (scipy.version.version < '0.7.0.dev3861'): import scipy.linalg as la else: if scipy.version.version < '0.7.0.dev3998': isolve appeared in r3861 as I can see now... r.
Cool. Thanks for your perserverance Roboert. I also need to make the same change on line 74 of ls.py: class ScipyIterative( LinearSolver ): name = 'ls.scipy_iterative' ## # c: 22.02.2008, r: 23.06.2008 def __init__( self, conf, **kwargs ): if (scipy.version.version == "0.6.0") or (scipy.version.version < '0.7.0.dev3861'):#<<<< same as in your email import scipy.linalg as la else: if scipy.version.version < '0.7.0.dev3998': import scipy.splinalg.isolve as la else: import scipy.sparse.linalg.isolve as la run runTests.py --debug tests/test_linear_solvers.py ....... 1 test file executed in 7.63 s, 0 failure(s) of 1 test(s) On Mon, Jun 23, 2008 at 10:10 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ryan Krauss wrote:
I can't find isolve anywhere. There is no linalg in scipy/sparse. There is no scipy/splinalg. And there is no isolve in scipy.linalg.
Here is the IPython tab completion of what is in scipy.linalg:
In [1]: scipy.linalg. scipy.linalg.__new__ scipy.linalg.iterative
I see, your iterative.py is still in scipy.linalg.
Could you, please, try editing sfe/solvers/ls.py:
--- a/sfe/solvers/ls.py Mon Jun 23 10:49:07 2008 +0200 +++ b/sfe/solvers/ls.py Mon Jun 23 17:07:51 2008 +0200 @@ -71,7 +71,8 @@ class ScipyIterative( LinearSolver ): ## # c: 22.02.2008, r: 23.06.2008 def __init__( self, conf, **kwargs ): - if scipy.version.version == "0.6.0": + if (scipy.version.version == "0.6.0") or + (scipy.version.version < '0.7.0.dev3861'): import scipy.linalg as la else: if scipy.version.version < '0.7.0.dev3998':
isolve appeared in r3861 as I can see now...
r.
p.s. I can stay with this svn revision of scipy for a while if it is helpful for debugging, or I can update. Ryan On Mon, Jun 23, 2008 at 10:29 AM, Ryan Krauss <ryan...@gmail.com> wrote:
Cool. Thanks for your perserverance Roboert. I also need to make the same change on line 74 of ls.py:
class ScipyIterative( LinearSolver ): name = 'ls.scipy_iterative'
## # c: 22.02.2008, r: 23.06.2008 def __init__( self, conf, **kwargs ): if (scipy.version.version == "0.6.0") or (scipy.version.version < '0.7.0.dev3861'):#<<<< same as in your email import scipy.linalg as la else: if scipy.version.version < '0.7.0.dev3998': import scipy.splinalg.isolve as la else: import scipy.sparse.linalg.isolve as la
run runTests.py --debug tests/test_linear_solvers.py ....... 1 test file executed in 7.63 s, 0 failure(s) of 1 test(s)
On Mon, Jun 23, 2008 at 10:10 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ryan Krauss wrote:
I can't find isolve anywhere. There is no linalg in scipy/sparse. There is no scipy/splinalg. And there is no isolve in scipy.linalg.
Here is the IPython tab completion of what is in scipy.linalg:
In [1]: scipy.linalg. scipy.linalg.__new__ scipy.linalg.iterative
I see, your iterative.py is still in scipy.linalg.
Could you, please, try editing sfe/solvers/ls.py:
--- a/sfe/solvers/ls.py Mon Jun 23 10:49:07 2008 +0200 +++ b/sfe/solvers/ls.py Mon Jun 23 17:07:51 2008 +0200 @@ -71,7 +71,8 @@ class ScipyIterative( LinearSolver ): ## # c: 22.02.2008, r: 23.06.2008 def __init__( self, conf, **kwargs ): - if scipy.version.version == "0.6.0": + if (scipy.version.version == "0.6.0") or + (scipy.version.version < '0.7.0.dev3861'): import scipy.linalg as la else: if scipy.version.version < '0.7.0.dev3998':
isolve appeared in r3861 as I can see now...
r.
Ryan Krauss wrote:
Cool. Thanks for your perserverance Roboert. I also need to make the same change on line 74 of ls.py:
Funny, I fixed the line 74, but missed the top of the file. It should be ok in our repo now.
p.s. I can stay with this svn revision of scipy for a while if it is helpful for debugging, or I can update.
As you wish :) Anyway, debugging help is always welcome, thanks!
r.
So, I still haven't worked through the Mercurial tutorial. You can tell me to RTFM for Mercurial. But I just did;
hg pull http://hg.sympy.org/sfepy hg update
and then this prints to my screen (from the top of ls.py):
from sfe.base.base import * from sfe.solvers.solvers import LinearSolver
import scipy <<<<<<< /home/ryan/svn/sfepy/sfe/solvers/ls.py.orig. if (scipy.version.version == "0.6.0") or (scipy.version.version < '0.7.0.dev3861'): ||||||| /tmp/ls.py~base.M22101 if scipy.version.version == "0.6.0":
if scipy.version.version < '0.7.0.dev3861':
> /tmp/ls.py~other.1P46Qk
So, I think that means the top one is mine, the middle is the old, and the bottom is the repository. I think this means I need to configure the diff tool the Mercurial uses. What do you guys use? And is there an hg update flag to overwrite all my local changes with the repo changes? Right now when I run "hg update", it is just displaying the python file in my terninal with no syntax highlighting and no commands to merge the changes one way or another.
Thanks again,
Ryan
On Mon, Jun 23, 2008 at 10:40 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ryan Krauss wrote:
Cool. Thanks for your perserverance Roboert. I also need to make the same change on line 74 of ls.py:
Funny, I fixed the line 74, but missed the top of the file. It should be ok in our repo now.
p.s. I can stay with this svn revision of scipy for a while if it is helpful for debugging, or I can update.
As you wish :) Anyway, debugging help is always welcome, thanks!
r.
Ryan Krauss wrote:
So, I still haven't worked through the Mercurial tutorial. You can tell me to RTFM for Mercurial. But I just did;
hg pull http://hg.sympy.org/sfepy hg update
and then this prints to my screen (from the top of ls.py):
from sfe.base.base import * from sfe.solvers.solvers import LinearSolver
import scipy <<<<<<< /home/ryan/svn/sfepy/sfe/solvers/ls.py.orig. if (scipy.version.version == "0.6.0") or (scipy.version.version < '0.7.0.dev3861'): ||||||| /tmp/ls.py~base.M22101 if scipy.version.version == "0.6.0":
if scipy.version.version < '0.7.0.dev3861':
>> /tmp/ls.py~other.1P46Qk
This is caused by the fact that I fixed the problem in a slightly different way then I posted here.
So, I think that means the top one is mine, the middle is the old, and the bottom is the repository. I think this means I need to configure the diff tool the Mercurial uses. What do you guys use? And is there an hg update flag to overwrite all my local changes with the repo changes? Right now when I run "hg update", it is just displaying the python file in my terninal with no syntax highlighting and no commands to merge the changes one way or another.
So, this is normal - it occurs whenever your local changes are in conflict with the repository you pull from. In this case just: a) manually remove <<< and |||, === is the upstream version, or b) remove whole ls.py and pull again, or c) clone the whole repo again (just if you can safely remove the directory)
cheers, and sorry for the troubles :) r.
No problem. That is what I was doing (manual editting). I just thought there had to be an easier way.
Thanks again for all your help,
Ryan
On Mon, Jun 23, 2008 at 11:24 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ryan Krauss wrote:
So, I still haven't worked through the Mercurial tutorial. You can tell me to RTFM for Mercurial. But I just did;
hg pull http://hg.sympy.org/sfepy hg update
and then this prints to my screen (from the top of ls.py):
from sfe.base.base import * from sfe.solvers.solvers import LinearSolver
import scipy <<<<<<< /home/ryan/svn/sfepy/sfe/solvers/ls.py.orig. if (scipy.version.version == "0.6.0") or (scipy.version.version < '0.7.0.dev3861'): ||||||| /tmp/ls.py~base.M22101 if scipy.version.version == "0.6.0":
if scipy.version.version < '0.7.0.dev3861':
>>> /tmp/ls.py~other.1P46Qk
This is caused by the fact that I fixed the problem in a slightly different way then I posted here.
So, I think that means the top one is mine, the middle is the old, and the bottom is the repository. I think this means I need to configure the diff tool the Mercurial uses. What do you guys use? And is there an hg update flag to overwrite all my local changes with the repo changes? Right now when I run "hg update", it is just displaying the python file in my terninal with no syntax highlighting and no commands to merge the changes one way or another.
So, this is normal - it occurs whenever your local changes are in conflict with the repository you pull from. In this case just: a) manually remove <<< and |||, === is the upstream version, or b) remove whole ls.py and pull again, or c) clone the whole repo again (just if you can safely remove the directory)
cheers, and sorry for the troubles :) r.
Ryan Krauss wrote:
No problem. That is what I was doing (manual editting). I just thought there had to be an easier way.
Well, IMHO there is not. A conflict means that two people edited the same thing in an incompatible manner - no tool can resolve this automatically. Or you mean that hg just prints the info and does not open a text editor with the offending file? Maybe you should set EDITOR environment variable, like export EDITOR=<path to your favourite text editor> for the bash shell. Then, your editor may know how to move between the conflict marks.
r.
Yeah, I was thinking like emacs ediff mode. I understand that this situation can't automatically be resolved, but something like ediff would be better than what is popping up now. I will try setting my editor and reading the mercurial documentation. I think I saw a section on this.
On Mon, Jun 23, 2008 at 11:35 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ryan Krauss wrote:
No problem. That is what I was doing (manual editting). I just thought there had to be an easier way.
Well, IMHO there is not. A conflict means that two people edited the same thing in an incompatible manner - no tool can resolve this automatically. Or you mean that hg just prints the info and does not open a text editor with the offending file? Maybe you should set EDITOR environment variable, like export EDITOR=<path to your favourite text editor> for the bash shell. Then, your editor may know how to move between the conflict marks.
r.
participants (3)
-
Ondrej Certik -
Robert Cimrman -
Ryan Krauss