Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any
debugging result.
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfepy/terms/extmods");
Am I adding it correctly?
regards.
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result.� mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/ terms/extmods"); mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
On Sunday, 11 August 2013 23:21:13 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result.�
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
It printed the debug results for examples/navier_stokes/navier_stokes2d.py Then I tried running the convective_difffusive.py and it did not print any line containing allocated memory report: .. .. .. convdiff: matrix structural nonzeros: 1747752 (8.65e-04% fill) convdiff: updating materials... convdiff: m convdiff: ...done in 0.01 s convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00) convect_build_vtg(): ERR_Switch Traceback (most recent call last): File "examples/phase_change/convective_diffusive/convective_diffusive.py", line 131, in <module> main() File "examples/phase_change/convective_diffusive/convective_diffusive.py", line 113, in main flow = problem.solve() File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/problemDef.py", line 933, in solve vec = solvers.nls(vec0) File "/usr/local/lib/python2.7/dist-packages/sfepy/solvers/nls.py", line 345, in __call__ mtx_a = fun_grad(vec_x) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/evaluate.py", line 66, in eval_tangent_matrix mtx = pb.equations.eval_tangent_matrices(vec, mtx) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/equations.py", line 640, in eval_tangent_matrices self.evaluate(mode='weak', dw_mode='matrix', asm_obj=tangent_matrix) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/equations.py", line 526, in evaluate asm_obj=asm_obj) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/equations.py", line 766, in evaluate ret_status=True) File "/usr/local/lib/python2.7/dist-packages/sfepy/terms/terms.py", line 1474, in evaluate vals.append(self.sign * val) RuntimeError: ccore error (see above)
r.
Hi R,
Is it possible for you to come on Teamviewer - http://www.teamviewer.com/hi/index.aspx
Regards.
On Monday, 12 August 2013 18:52:29 UTC+5:30, Ankit Mahato wrote:
On Sunday, 11 August 2013 23:21:13 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result.�
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
It printed the debug results for examples/navier_stokes/navier_stokes2d.py Then I tried running the convective_difffusive.py and it did not print any line containing allocated memory report: .. .. .. convdiff: matrix structural nonzeros: 1747752 (8.65e-04% fill) convdiff: updating materials... convdiff: m convdiff: ...done in 0.01 s convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00) convect_build_vtg(): ERR_Switch Traceback (most recent call last): File "examples/phase_change/convective_diffusive/convective_diffusive.py", line 131, in <module> main() File "examples/phase_change/convective_diffusive/convective_diffusive.py", line 113, in main flow = problem.solve() File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/problemDef.py", line 933, in solve vec = solvers.nls(vec0) File "/usr/local/lib/python2.7/dist-packages/sfepy/solvers/nls.py", line 345, in __call__ mtx_a = fun_grad(vec_x) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/evaluate.py", line 66, in eval_tangent_matrix mtx = pb.equations.eval_tangent_matrices(vec, mtx) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/equations.py", line 640, in eval_tangent_matrices self.evaluate(mode='weak', dw_mode='matrix', asm_obj=tangent_matrix) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/equations.py", line 526, in evaluate asm_obj=asm_obj) File "/usr/local/lib/python2.7/dist-packages/sfepy/fem/equations.py", line 766, in evaluate ret_status=True) File "/usr/local/lib/python2.7/dist-packages/sfepy/terms/terms.py", line 1474, in evaluate vals.append(self.sign * val) RuntimeError: ccore error (see above)
r.
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim variable (should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result. mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/ terms/extmods"); mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
yes R the sizes are same.
Something very strange happened, when I used ipython to run it in debug mode ... It completed the simulation and gave me the output.
again when I ran via python command it threw the error.
How is it possible? :O
On Wednesday, 14 August 2013 21:14:40 UTC+5:30, Robert Cimrman wrote:
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim variable (should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result.
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
An interesting problem I tried out to check if the code works with ipython mode for other problems.
Mixing Elbow Problem
On Thursday, 15 August 2013 00:38:40 UTC+5:30, Ankit Mahato wrote:
yes R the sizes are same.
Something very strange happened, when I used ipython to run it in debug mode ... It completed the simulation and gave me the output.
again when I ran via python command it threw the error.
How is it possible? :O
On Wednesday, 14 August 2013 21:14:40 UTC+5:30, Robert Cimrman wrote:
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim variable (should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result.
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
On 08/14/2013 09:08 PM, Ankit Mahato wrote:
yes R the sizes are same.
Something very strange happened, when I used ipython to run it in debug mode ... It completed the simulation and gave me the output.
black magic at work!
again when I ran via python command it threw the error.
How is it possible? :O
no idea... could you run it in gdb, as:
gdb --args python convective_diffusive.py then "run" at the gdb prompt.
Then try printing the sizes in C.
r.
On Wednesday, 14 August 2013 21:14:40 UTC+5:30, Robert Cimrman wrote:
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim variable (should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not printing any debugging result.
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
On Thursday, 15 August 2013 14:32:05 UTC+5:30, Robert Cimrman wrote:
On 08/14/2013 09:08 PM, Ankit Mahato wrote:
yes R the sizes are same.
Something very strange happened, when I used ipython to run it in debug mode ... It completed the simulation and gave me the output.
black magic at work!
again when I ran via python command it threw the error.
How is it possible? :O
no idea... could you run it in gdb, as:
gdb --args python convective_diffusive.py then "run" at the gdb prompt.
Then try printing the sizes in C.
r.
On Wednesday, 14 August 2013 21:14:40 UTC+5:30, Robert Cimrman wrote:
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim variable (should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not
printing
any debugging result.
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of the complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an initial implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote:
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
On Thursday, 15 August 2013 14:32:05 UTC+5:30, Robert Cimrman wrote:
On 08/14/2013 09:08 PM, Ankit Mahato wrote:
yes R the sizes are same.
Something very strange happened, when I used ipython to run it in debug mode ... It completed the simulation and gave me the output.
black magic at work!
again when I ran via python command it threw the error.
How is it possible? :O
no idea... could you run it in gdb, as:
gdb --args python convective_diffusive.py then "run" at the gdb prompt.
Then try printing the sizes in C.
r.
On Wednesday, 14 August 2013 21:14:40 UTC+5:30, Robert Cimrman wrote:
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim variable (should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
Hi R,
I tried mem_checkIntegrity inside the functions but it is not
printing
any debugging result.
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
terms/extmods");
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
y/terms/extmods");
Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
Hi R,
In the weak form: previous file. corrected now.) The H field is (=cT).
- The navier stokes equation will now have a source term.
- The energy equation will also have a source term (slight mistake in my
i need to calculate u,p,H (=cT), gl (liquid fraction) for each element. Iterating the energy equation to obtain convergence in the nodal liquid fraction value (source term) is one the key areas where I was having crisis situation. The momentum and energy equations are coupled through both the buoyancy and the source term (Bu). The B depends on the liquid fraction which represents an extra unknown in the governing equations. Since the liquid fraction is updated such that the corection term becomes zero at the convergence of the enthalpy equation.
I tried searching the internet but could not find any FEM implementation is this field so I started developing a python solver from scratch in order to test the algorithm suggested in those papers using finite volume method, as at least I will have a solver ready to couple it with sfepy.
regards, Ankit On Friday, 6 September 2013 13:21:01 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of the complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an initial implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote:
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
On Thursday, 15 August 2013 14:32:05 UTC+5:30, Robert Cimrman wrote:
On 08/14/2013 09:08 PM, Ankit Mahato wrote:
yes R the sizes are same.
Something very strange happened, when I used ipython to run it in
debug
mode ... It completed the simulation and gave me the output.
black magic at work!
again when I ran via python command it threw the error.
How is it possible? :O
no idea... could you run it in gdb, as:
gdb --args python convective_diffusive.py then "run" at the gdb prompt.
Then try printing the sizes in C.
r.
On Wednesday, 14 August 2013 21:14:40 UTC+5:30, Robert Cimrman wrote:
Any luck?
BTW. does the code work for a 3D mesh? But firstly try the following:
The convect_build_vtg(): ERR_Switch message means that the dim
(should be space dimension) is not 2 or 3, which should not happen.
set a debugger breakpoint in ConvectTerm.get_fargs() just above the return statement. Use "from sfepy.base.base import debug; debug()" for an ipython-based pdb shell.
print shapes as follows: 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode False ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bf vg.bf vg.bfg ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: nls: iter: 0, residual: 2.002082e-02 (rel: 1.000000e+00)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
ipdb> grad.shape (5000, 9, 2, 2) ipdb> val_qp.shape (5000, 9, 2, 1) ipdb> fmode True ipdb> print vg CMapping: mode: volume, n_el 5000, n_qp 9, dim: 2, n_ep: 9 ipdb> print vg.bfg.shape (5000, 9, 2, 9) ipdb> c convdiff: rezidual: 0.14 [s] convdiff: solve: 3.57 [s] convdiff: matrix: 0.60 [s] convdiff: linear system not solved! (err = 3.600155e-03 < 1.000000e-10)
...sfepy-git/sfepy/terms/termsNavierStokes.py(125)get_fargs() 124 from sfepy.base.base import debug; debug() --> 125 return grad, val_qp, vg, fmode 126
Are your sizes same as the above?
r.
On 08/11/2013 07:51 PM, Robert Cimrman wrote:
Hi Ankit,
On Sat, 10 Aug 2013, Ankit Mahato wrote:
> Hi R, > > I tried mem_checkIntegrity inside the functions but it is not
variable printing
> any debugging result. >
mem_checkIntegrity(421,"convect_build_vtg","termsNavierStokes.c","~/sfepy/sfepy/
> terms/extmods"); >
mem_checkIntegrity(546,"term_ns_asm_convect","termsNavierStokes.c","~/sfepy/sfep
> y/terms/extmods"); > > Am I adding it correctly?
Use the macro without arguments (see sfepy/fem/extmods/common.h for definition):
check_memory_integrity();
and do not forget to rebuild the sources.
After adding it to convect_build_vtg()
... default: errput( ErrHead "ERR_Switch\n" ); return( RET_Fail ); } check_memory_integrity(); return( RET_OK ); } ...
and typing "make", I get tons of
checking memory integrity in sfepy/terms/extmods, sfepy/terms/extmods/termsNavierStokes.c, convect_build_vtg(), 476: allocated memory: 8 records, usage: 52032, max: 52032 memory OK.
- trying with the examples/navier_stokes/navier_stokes2d.py
Also try changing the debug flags in site_cfg.py:
debug_flags = '-DDEBUG_FMF'
or even
debug_flags = '-DDEBUG_FMF -DDEBUG_MESH'
r.
On 09/06/2013 03:59 PM, Ankit Mahato wrote:
Hi R,
In the weak form: previous file. corrected now.) The H field is (=cT).
- The navier stokes equation will now have a source term.
- The energy equation will also have a source term (slight mistake in my
i need to calculate u,p,H (=cT), gl (liquid fraction) for each element. Iterating the energy equation to obtain convergence in the nodal liquid fraction value (source term) is one the key areas where I was having crisis situation.
So is it resolved?
If things get too complicated, try some simplifications so that we have some example(s) within SfePy for the GSoC final phase. I will be able to support you fully from 11.9.
The momentum and energy equations are coupled through both the buoyancy and the source term (Bu). The B depends on the liquid fraction which represents an extra unknown in the governing equations. Since the liquid fraction is updated such that the corection term becomes zero at the convergence of the enthalpy equation.
I tried searching the internet but could not find any FEM implementation is this field so I started developing a python solver from scratch in order to test the algorithm suggested in those papers using finite volume method, as at least I will have a solver ready to couple it with sfepy.
Ok, keep up the good work, and let us know about progress or problems. Once that solver works, you will have something to compare a new FEM solution with.
Cheers, r.
regards, Ankit On Friday, 6 September 2013 13:21:01 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of the complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an initial implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote:
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
Hi R,
Sorry to keep you waiting. Here is the much awaited update - http://ankitmahato.blogspot.in/2013/09/python-software-foundation-sfepy-gsoc...
Regards, Ankit
On Friday, 6 September 2013 21:54:32 UTC+5:30, Robert Cimrman wrote:
On 09/06/2013 03:59 PM, Ankit Mahato wrote:
Hi R,
In the weak form: previous file. corrected now.) The H field is (=cT).
- The navier stokes equation will now have a source term.
- The energy equation will also have a source term (slight mistake in my
i need to calculate u,p,H (=cT), gl (liquid fraction) for each element. Iterating the energy equation to obtain convergence in the nodal liquid fraction value (source term) is one the key areas where I was having crisis situation.
So is it resolved?
If things get too complicated, try some simplifications so that we have some example(s) within SfePy for the GSoC final phase. I will be able to support you fully from 11.9.
The momentum and energy equations are coupled through both the buoyancy and the source term (Bu). The B depends on the liquid fraction which represents an extra unknown in the governing equations. Since the liquid fraction is updated such that the corection term becomes zero at the convergence of the enthalpy equation.
I tried searching the internet but could not find any FEM implementation is this field so I started developing a python solver from scratch in order to test the algorithm suggested in those papers using finite volume method, as at least I will have a solver ready to couple it with sfepy.
Ok, keep up the good work, and let us know about progress or problems. Once that solver works, you will have something to compare a new FEM solution with.
Cheers, r.
regards, Ankit On Friday, 6 September 2013 13:21:01 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of the complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an
initial
implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote:
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
Hi Ankit,
thanks for the update. Nice movies!
Now we should think how to integrate this into the sfepy package - using Material for material parameters, Mesh/MeshIO for VTK output, Solver framework for the solver, numpy(-like) docstring standard for docstrings etc. Do you think you will get to some of those before the deadline? As for the finite volumes used - what are the main obstacles of converting that to finite elements?
Cheers, r.
On 09/12/2013 07:32 PM, Ankit Mahato wrote:
Hi R,
Sorry to keep you waiting. Here is the much awaited update - http://ankitmahato.blogspot.in/2013/09/python-software-foundation-sfepy-gsoc...
Regards, Ankit
On Friday, 6 September 2013 21:54:32 UTC+5:30, Robert Cimrman wrote:
On 09/06/2013 03:59 PM, Ankit Mahato wrote:
Hi R,
In the weak form: previous file. corrected now.) The H field is (=cT).
- The navier stokes equation will now have a source term.
- The energy equation will also have a source term (slight mistake in my
i need to calculate u,p,H (=cT), gl (liquid fraction) for each element. Iterating the energy equation to obtain convergence in the nodal liquid fraction value (source term) is one the key areas where I was having crisis situation.
So is it resolved?
If things get too complicated, try some simplifications so that we have some example(s) within SfePy for the GSoC final phase. I will be able to support you fully from 11.9.
The momentum and energy equations are coupled through both the buoyancy and the source term (Bu). The B depends on the liquid fraction which represents an extra unknown in the governing equations. Since the liquid fraction is updated such that the corection term becomes zero at the convergence of the enthalpy equation.
I tried searching the internet but could not find any FEM implementation is this field so I started developing a python solver from scratch in order to test the algorithm suggested in those papers using finite volume method, as at least I will have a solver ready to couple it with sfepy.
Ok, keep up the good work, and let us know about progress or problems. Once that solver works, you will have something to compare a new FEM solution with.
Cheers, r.
regards, Ankit On Friday, 6 September 2013 13:21:01 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of the complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an
initial
implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote:
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
On Friday, 13 September 2013 16:40:43 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
thanks for the update. Nice movies!
:)
Now we should think how to integrate this into the sfepy package - using Material for material parameters,
Okie R.
Mesh/MeshIO for VTK output, Solver framework for the solver, numpy(-like) docstring standard for docstrings etc.
On it R.
Do you think you will get to some of those before the deadline?
Yes R. I will get as far as I can before the deadline.
As for the finite volumes used - what are the main obstacles of converting that to finite elements?
A key component which had to be implemented was the enthalpy update scheme. As stated in my blog post, in research papers it was stated and tested keeping FVM base in mind. Also I am more versed with FVM than FEM so I could implement it in that time frame I had along with the benchmarking without which this code would have had no credibility. There will definitely be a way using FEM, but wish I had more time in this GSoC timeframe. I have already kept it in my mind as a challenge over which I will ponder as I still have 9 months left to complete my thesis.
Cheers.
Cheers, r.
On 09/12/2013 07:32 PM, Ankit Mahato wrote:
Hi R,
Sorry to keep you waiting. Here is the much awaited update -
http://ankitmahato.blogspot.in/2013/09/python-software-foundation-sfepy-gsoc...
Regards, Ankit
On Friday, 6 September 2013 21:54:32 UTC+5:30, Robert Cimrman wrote:
On 09/06/2013 03:59 PM, Ankit Mahato wrote:
Hi R,
In the weak form:
- The navier stokes equation will now have a source term.
- The energy equation will also have a source term (slight mistake in
previous file. corrected now.) The H field is (=cT). i need to calculate u,p,H (=cT), gl (liquid fraction) for each element. Iterating the energy equation to obtain convergence in the nodal
my liquid
fraction value (source term) is one the key areas where I was having crisis situation.
So is it resolved?
If things get too complicated, try some simplifications so that we have some example(s) within SfePy for the GSoC final phase. I will be able to support you fully from 11.9.
The momentum and energy equations are coupled through both the buoyancy and the source term (Bu). The B depends on the liquid fraction which represents an extra unknown in the governing equations. Since the liquid fraction is updated such that the corection term becomes zero at the convergence of the enthalpy equation.
I tried searching the internet but could not find any FEM implementation is this field so I started developing a python solver from scratch in order to test the algorithm suggested in those papers using finite volume method, as at least I will have a solver ready to couple it with sfepy.
Ok, keep up the good work, and let us know about progress or problems. Once that solver works, you will have something to compare a new FEM solution with.
Cheers, r.
regards, Ankit On Friday, 6 September 2013 13:21:01 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of the complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an
initial
implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote:
Hi R,
Here is the final problem statement file containing all details.
regards, Ankit
Hi R,
Here are the new problem description and solver codes https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit On Friday, 13 September 2013 17:14:32 UTC+5:30, Ankit Mahato wrote:
On Friday, 13 September 2013 16:40:43 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
thanks for the update. Nice movies!
:)
Now we should think how to integrate this into the sfepy package - using Material for material parameters,
Okie R.
Mesh/MeshIO for VTK output, Solver framework for the solver, numpy(-like) docstring standard for docstrings etc.
On it R.
Do you think you will get to some of those before the deadline?
Yes R. I will get as far as I can before the deadline.
As for the finite volumes used - what are the main obstacles of converting that to finite elements?
A key component which had to be implemented was the enthalpy update scheme. As stated in my blog post, in research papers it was stated and tested keeping FVM base in mind. Also I am more versed with FVM than FEM so I could implement it in that time frame I had along with the benchmarking without which this code would have had no credibility. There will definitely be a way using FEM, but wish I had more time in this GSoC timeframe. I have already kept it in my mind as a challenge over which I will ponder as I still have 9 months left to complete my thesis.
Cheers.
Cheers, r.
On 09/12/2013 07:32 PM, Ankit Mahato wrote:
Hi R,
Sorry to keep you waiting. Here is the much awaited update -
http://ankitmahato.blogspot.in/2013/09/python-software-foundation-sfepy-gsoc...
Regards, Ankit
On Friday, 6 September 2013 21:54:32 UTC+5:30, Robert Cimrman wrote:
On 09/06/2013 03:59 PM, Ankit Mahato wrote:
Hi R,
In the weak form:
- The navier stokes equation will now have a source term.
- The energy equation will also have a source term (slight mistake in
previous file. corrected now.) The H field is (=cT). i need to calculate u,p,H (=cT), gl (liquid fraction) for each element. Iterating the energy equation to obtain convergence in the nodal
fraction value (source term) is one the key areas where I was having crisis situation.
So is it resolved?
If things get too complicated, try some simplifications so that we have some example(s) within SfePy for the GSoC final phase. I will be able to support you fully from 11.9.
The momentum and energy equations are coupled through both the buoyancy and the source term (Bu). The B depends on the liquid fraction which represents an extra unknown in the governing equations. Since the liquid fraction is updated such that the corection term becomes zero at the convergence of the enthalpy equation.
I tried searching the internet but could not find any FEM implementation is this field so I started developing a python solver from scratch in order to test the algorithm suggested in those papers using finite volume method, as at least I will have a solver ready to couple it with sfepy.
Ok, keep up the good work, and let us know about progress or problems. Once that solver works, you will have something to compare a new FEM solution with.
Cheers, r.
regards, Ankit On Friday, 6 September 2013 13:21:01 UTC+5:30, Robert Cimrman wrote:
Hi Ankit,
it looks very interesting. Do you have also a weak formulation of
my liquid the
complete problem? I would like to see the form
Find u, p, ... such that ... holds for all v, q...
to see if all the terms are available. Or do you have already an initial implementation? I will be offline from 7. to 11.9. but Vladimir should be able to answer your questions. I am available today.
r.
On 09/02/2013 10:53 PM, Ankit Mahato wrote: > Hi R, > > Here is the final problem statement file containing all details. > > regards, > Ankit
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
On it R.
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
I use Sublime Text editor (http://www.sublimetext.com/). Yes i just noticed it yesterday that I need to tidy my code.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
yes 1 commit on Sept 10 went bad. I will use your script.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
Regards
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
R, I used the script. As stated here[http://git-scm.com/docs/git-filter-branch] - Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace * refs/original/*
I can see a file .git/refs/original/refs/heads/phase_change in that location. but no change is reflected if I use gitk --all to view the project. "ankit" is still present as the commiter there.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
R,
Kindly check. Now I have pushed the tidy code along with correct name/email in commits.
Regards.
On Tuesday, 17 September 2013 16:28:08 UTC+5:30, Ankit Mahato wrote:
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
R, I used the script. As stated here[http://git-scm.com/docs/git-filter-branch] - Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace * refs/original/*
I can see a file .git/refs/original/refs/heads/phase_change in that location. but no change is reflected if I use gitk --all to view the project. "ankit" is still present as the commiter there.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
On 09/17/2013 01:39 PM, Ankit Mahato wrote:
R,
Kindly check. Now I have pushed the tidy code along with correct name/email in commits.
Yes, the author/commiter info now seems fine.
r.
Regards.
On Tuesday, 17 September 2013 16:28:08 UTC+5:30, Ankit Mahato wrote:
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
R, I used the script. As stated here[http://git-scm.com/docs/git-filter-branch] - Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace * refs/original/*
I can see a file .git/refs/original/refs/heads/phase_change in that location. but no change is reflected if I use gitk --all to view the project. "ankit" is still present as the commiter there.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
hi R,
Updated : https://github.com/animator/sfepy/tree/phase_change
On Tuesday, 17 September 2013 17:17:11 UTC+5:30, Robert Cimrman wrote:
On 09/17/2013 01:39 PM, Ankit Mahato wrote:
R,
Kindly check. Now I have pushed the tidy code along with correct name/email in commits.
Yes, the author/commiter info now seems fine.
r.
Regards.
On Tuesday, 17 September 2013 16:28:08 UTC+5:30, Ankit Mahato wrote:
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
R, I used the script. As stated here[http://git-scm.com/docs/git-filter-branch] - Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace * refs/original/*
I can see a file .git/refs/original/refs/heads/phase_change in that location. but no change is reflected if I use gitk --all to view the project. "ankit" is still present as the commiter there.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
Good :) It runs for me.
BTW. it might be better to keep the solver in the example directory (examples/phase_change/phase_change_solver/pcsolver.py) - you can use
from sfepy.solvers import register_solver register_solver(PhaseChangeSolver)
to make it available to sfepy.
Could you try rebasing/updating your branch for 2013.3? Or maybe do this later, as the pencils down date is approaching? You will need to publish the code [1] so it better is well documented.
What are your current plans?
Thanks & cheers, r.
[1] http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc201...
On 09/19/2013 05:45 PM, Ankit Mahato wrote:
hi R,
Updated : https://github.com/animator/sfepy/tree/phase_change
On Tuesday, 17 September 2013 17:17:11 UTC+5:30, Robert Cimrman wrote:
On 09/17/2013 01:39 PM, Ankit Mahato wrote:
R,
Kindly check. Now I have pushed the tidy code along with correct name/email in commits.
Yes, the author/commiter info now seems fine.
r.
Regards.
On Tuesday, 17 September 2013 16:28:08 UTC+5:30, Ankit Mahato wrote:
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote:
Hi R,
Here are the new problem description and solver codes
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
- It uses sfepy package for properties,mesh,vtkoutputs, etc. How should I integrate into the Solver framework?
Regards, Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of the repo, as it uses the nuclear weapon of git - the filter-branch command).
R, I used the script. As stated here[http://git-scm.com/docs/git-filter-branch] - Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace * refs/original/*
I can see a file .git/refs/original/refs/heads/phase_change in that location. but no change is reflected if I use gitk --all to view the project. "ankit" is still present as the commiter there.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
On Thursday, 19 September 2013 21:33:08 UTC+5:30, Robert Cimrman wrote:
Good :) It runs for me.
BTW. it might be better to keep the solver in the example directory (examples/phase_change/phase_change_solver/pcsolver.py) - you can use
from sfepy.solvers import register_solver register_solver(PhaseChangeSolver)
to make it available to sfepy.
Okie R
Could you try rebasing/updating your branch for 2013.3? Or maybe do this later, as the pencils down date is approaching? You will need to publish the code [1] so it better is well documented.
What are your current plans?
Firstly, I will fix the docstring. Then I will prepare complete documentation of the entire gsoc work. Also I have an exam on 21st so i will study for it.
Regards, Ankit
Thanks & cheers, r.
[1]
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc201...
hi R,
Updated : https://github.com/animator/sfepy/tree/phase_change
On Tuesday, 17 September 2013 17:17:11 UTC+5:30, Robert Cimrman wrote:
On 09/17/2013 01:39 PM, Ankit Mahato wrote:
R,
Kindly check. Now I have pushed the tidy code along with correct name/email in commits.
Yes, the author/commiter info now seems fine.
r.
Regards.
On Tuesday, 17 September 2013 16:28:08 UTC+5:30, Ankit Mahato wrote:
On Tuesday, 17 September 2013 13:45:00 UTC+5:30, Robert Cimrman
wrote:
On 09/16/2013 10:29 PM, Ankit Mahato wrote: > Hi R, > > Here are the new problem description and solver codes >
https://github.com/animator/sfepy/tree/phase_change/examples/phase_change/ph...
> > - It uses sfepy package for properties,mesh,vtkoutputs, etc. > How should I integrate into the Solver framework? > > Regards, > Ankit
There are several possibilities. First, the solvers have a standard way of passing in/processing options, see .process_conf() of any solver, for example in sfepy.solvers.ls. Then the solution is implemented as .__call__().
I would try:
- use TimeStepper or VariableTimeStepper from sfepy.solvers.ts for time stepping
- make PhaseChangeSolver a Solver subclass and use PhaseChangeSolver.process_conf() for its options
- then we will see :)
r.
PS: I see lots of trailing whitespace, bad indentation and other PEP8 problems in your files - what editor do you use? Some setup might be needed. Or try using [1] with tweaks [2] or [3] (some configuration might be required) - manual inspection then needed.
PPS: Setup correctly you git user name and e-mail on all computers you use. The commits so far can be fixed by the attached script taking two arguments - the start commit and end commit (!!!dangerous!!! - use it on a copy of
On 09/19/2013 05:45 PM, Ankit Mahato wrote: the
repo, as it uses the nuclear weapon of git - the filter-branch command).
R, I used the script. As stated here[http://git-scm.com/docs/git-filter-branch] - Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace * refs/original/*
I can see a file .git/refs/original/refs/heads/phase_change in that location. but no change is reflected if I use gitk --all to view the project. "ankit" is still present as the commiter there.
[1] http://pypi.python.org/pypi/PythonTidy/
[2] COL_LIMIT = 79 DICT_COLON = ' : ' ADD_BLANK_LINES_AROUND_COMMENTS = False MAX_SEPS_FUNC_DEF = 50 # 2007 May 24 PARENTHESIZE_TUPLE_DISPLAY = False # 2010 Mar 10
On 09/19/2013 06:29 PM, Ankit Mahato wrote:
On Thursday, 19 September 2013 21:33:08 UTC+5:30, Robert Cimrman wrote:
Good :) It runs for me.
BTW. it might be better to keep the solver in the example directory (examples/phase_change/phase_change_solver/pcsolver.py) - you can use
from sfepy.solvers import register_solver register_solver(PhaseChangeSolver)
to make it available to sfepy.
Okie R
Could you try rebasing/updating your branch for 2013.3? Or maybe do this later, as the pencils down date is approaching? You will need to publish the code [1] so it better is well documented.
What are your current plans?
Firstly, I will fix the docstring. Then I will prepare complete documentation of the entire gsoc work. Also I have an exam on 21st so i will study for it.
Ok, good luck with the exam!
r.
Regards, Ankit
On Thursday, September 19, 2013 11:15:32 PM UTC+5:30, Robert Cimrman wrote:
On 09/19/2013 06:29 PM, Ankit Mahato wrote:
On Thursday, 19 September 2013 21:33:08 UTC+5:30, Robert Cimrman wrote:
Good :) It runs for me.
BTW. it might be better to keep the solver in the example directory (examples/phase_change/phase_change_solver/pcsolver.py) - you can use
from sfepy.solvers import register_solver register_solver(PhaseChangeSolver)
to make it available to sfepy.
Okie R
Could you try rebasing/updating your branch for 2013.3? Or maybe do
this
later, as the pencils down date is approaching? You will need to publish the code [1] so it better is well documented.
What are your current plans?
Firstly, I will fix the docstring. Then I will prepare complete documentation of the entire gsoc work. Also I have an exam on 21st so i will study for it.
Ok, good luck with the exam!
Thanks R!
r.
Regards, Ankit
participants (2)
-
Ankit Mahato -
Robert Cimrman