Material properties dependent on test field variables.
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric resistors. Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and p is the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p) + int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
Kind regards Bjarke Dalslet
Hello Bjarke!
On 10/26/2012 10:35 AM, Bjarke Dalslet wrote:
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric resistors. Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and p is the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p) + int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
I would try 2 first, as the Laplace equation can be very quickly solved by a conjugate gradients solver, so doing a few "time" iterations would not be that demanding. The linear system solution is fast even with the Python implementation from SciPy ('ls.scipy_iterative'), but if you have PETSc and petsc4py installed, it would be even faster ('ls.petsc') - see tests/test_linear_solvers.py file for example configurations of the linear solvers.
As for the artificial time-stepping, look at [1], which is almost exactly what you need, only the equation is the linear elasticity.
Then, if the above approach does not work, we could try adding a new nonlinear term.
If you get stuck, do not hesitate to ask here.
Cheers & thanks for trying SfePy! r.
[1] http://docs.sfepy.org/doc-devel/examples/linear_elasticity/material_nonlinea...
Kind regards Bjarke Dalslet
Thanks a lot for the quick reply and good advice.
I will try the iterative approach then.
I only worry about speed as I am using sfepy to fit measured data. I am using 3 fitting parameters, and thus around 10K steady state simulations are necessary to get a good fit. This takes about a day with my current mesh, but honestly that is much faster than I expected when starting to look into FEM modelling.
In all,I am very happy with the speed, accesibility and flexibility of sfepy.
- Bjarke
On Friday, October 26, 2012 11:26:38 AM UTC+2, Robert Cimrman wrote:
Hello Bjarke!
On 10/26/2012 10:35 AM, Bjarke Dalslet wrote:
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric resistors. Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and p is the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p) + int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
I would try 2 first, as the Laplace equation can be very quickly solved by a conjugate gradients solver, so doing a few "time" iterations would not be that demanding. The linear system solution is fast even with the Python implementation from SciPy ('ls.scipy_iterative'), but if you have PETSc and petsc4py installed, it would be even faster ('ls.petsc') - see tests/test_linear_solvers.py file for example configurations of the linear solvers.
As for the artificial time-stepping, look at [1], which is almost exactly what you need, only the equation is the linear elasticity.
Then, if the above approach does not work, we could try adding a new nonlinear term.
If you get stuck, do not hesitate to ask here.
Cheers & thanks for trying SfePy! r.
[1]
http://docs.sfepy.org/doc-devel/examples/linear_elasticity/material_nonlinea...
Kind regards Bjarke Dalslet
On 10/26/2012 11:51 AM, Bjarke Dalslet wrote:
Thanks a lot for the quick reply and good advice.
I will try the iterative approach then.
Let us know how it goes.
I only worry about speed as I am using sfepy to fit measured data. I am using 3 fitting parameters, and thus around 10K steady state simulations are necessary to get a good fit. This takes about a day with my current mesh, but honestly that is much faster than I expected when starting to look into FEM modelling.
So it's a brute-force approach to fitting? Anyway, a day is not so bad :). If that was using umfpack as a solver, you might get a significant improvement by using CG.
In all,I am very happy with the speed, accesibility and flexibility of sfepy.
Glad to hear that! r.
- Bjarke
On Friday, October 26, 2012 11:26:38 AM UTC+2, Robert Cimrman wrote:
Hello Bjarke!
On 10/26/2012 10:35 AM, Bjarke Dalslet wrote:
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric resistors. Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and p is the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p) + int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
I would try 2 first, as the Laplace equation can be very quickly solved by a conjugate gradients solver, so doing a few "time" iterations would not be that demanding. The linear system solution is fast even with the Python implementation from SciPy ('ls.scipy_iterative'), but if you have PETSc and petsc4py installed, it would be even faster ('ls.petsc') - see tests/test_linear_solvers.py file for example configurations of the linear solvers.
As for the artificial time-stepping, look at [1], which is almost exactly what you need, only the equation is the linear elasticity.
Then, if the above approach does not work, we could try adding a new nonlinear term.
If you get stuck, do not hesitate to ask here.
Cheers & thanks for trying SfePy! r.
[1]
http://docs.sfepy.org/doc-devel/examples/linear_elasticity/material_nonlinea...
Kind regards Bjarke Dalslet
It works - sfepy iterates and the result converges. I have prepared a simple example, as it was difficult (to me at least) to find out how to get the temperature information. It is attached both as a patch and as a python file.
One issue with this implementation is that the deque "equations.variables._objs.find('T')" in the second iteration contains None which causes "equations.variables._objs.find('T').evaluate_at(coors)" to fail - thus the try/except clauses. Maybe there is a better way?
- Bjarke
On Friday, October 26, 2012 12:08:00 PM UTC+2, Robert Cimrman wrote:
On 10/26/2012 11:51 AM, Bjarke Dalslet wrote:
Thanks a lot for the quick reply and good advice.
I will try the iterative approach then.
Let us know how it goes.
I only worry about speed as I am using sfepy to fit measured data. I am using 3 fitting parameters, and thus around 10K steady state simulations are necessary to get a good fit. This takes about a day with my current mesh, but honestly that is much faster than I expected when starting to look into FEM modelling.
So it's a brute-force approach to fitting? Anyway, a day is not so bad :). If that was using umfpack as a solver, you might get a significant improvement by using CG.
In all,I am very happy with the speed, accesibility and flexibility of sfepy.
Glad to hear that! r.
- Bjarke
On Friday, October 26, 2012 11:26:38 AM UTC+2, Robert Cimrman wrote:
Hello Bjarke!
On 10/26/2012 10:35 AM, Bjarke Dalslet wrote:
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric
Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and
is
the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p) + int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
I would try 2 first, as the Laplace equation can be very quickly solved by a conjugate gradients solver, so doing a few "time" iterations would not be that demanding. The linear system solution is fast even with the Python implementation from SciPy ('ls.scipy_iterative'), but if you have PETSc and petsc4py installed, it would be even faster ('ls.petsc') - see tests/test_linear_solvers.py file for example configurations of the
resistors. p linear
solvers.
As for the artificial time-stepping, look at [1], which is almost exactly what you need, only the equation is the linear elasticity.
Then, if the above approach does not work, we could try adding a new nonlinear term.
If you get stuck, do not hesitate to ask here.
Cheers & thanks for trying SfePy! r.
[1]
http://docs.sfepy.org/doc-devel/examples/linear_elasticity/material_nonlinea...
Kind regards Bjarke Dalslet
On 10/31/2012 01:24 PM, Bjarke Dalslet wrote:
It works - sfepy iterates and the result converges. I have prepared a simple example, as it was difficult (to me at least) to find out how to get the temperature information. It is attached both as a patch and as a python file.
Thanks and welcome aboard!
One issue with this implementation is that the deque "equations.variables._objs.find('T')" in the second iteration contains None which causes "equations.variables._objs.find('T').evaluate_at(coors)" to fail - thus the try/except clauses. Maybe there is a better way?
This was caused by setting history attribute of T to 1. It is not needed as the variables hold their values from the previous time step anyway. There was also an issue with the tangent matrix that was not updating in the time steps as c(T) was changing. I fixed that by setting the problem to 'nonlinear'. Then I have made a little clean-up and used the short syntax for all the configuration items. The result is at [1] - I hope you recognize it :) Let me know if the new version works for you - I will then push the changes to the main repository.
Cheers, r. [1] https://github.com/rc/sfepy
- Bjarke
On Friday, October 26, 2012 12:08:00 PM UTC+2, Robert Cimrman wrote:
On 10/26/2012 11:51 AM, Bjarke Dalslet wrote:
Thanks a lot for the quick reply and good advice.
I will try the iterative approach then.
Let us know how it goes.
I only worry about speed as I am using sfepy to fit measured data. I am using 3 fitting parameters, and thus around 10K steady state simulations are necessary to get a good fit. This takes about a day with my current mesh, but honestly that is much faster than I expected when starting to look into FEM modelling.
So it's a brute-force approach to fitting? Anyway, a day is not so bad :). If that was using umfpack as a solver, you might get a significant improvement by using CG.
In all,I am very happy with the speed, accesibility and flexibility of sfepy.
Glad to hear that! r.
- Bjarke
On Friday, October 26, 2012 11:26:38 AM UTC+2, Robert Cimrman wrote:
Hello Bjarke!
On 10/26/2012 10:35 AM, Bjarke Dalslet wrote:
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric
Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and
is
the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p) + int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
I would try 2 first, as the Laplace equation can be very quickly solved by a conjugate gradients solver, so doing a few "time" iterations would not be that demanding. The linear system solution is fast even with the Python implementation from SciPy ('ls.scipy_iterative'), but if you have PETSc and petsc4py installed, it would be even faster ('ls.petsc') - see tests/test_linear_solvers.py file for example configurations of the
resistors. p linear
solvers.
As for the artificial time-stepping, look at [1], which is almost exactly what you need, only the equation is the linear elasticity.
Then, if the above approach does not work, we could try adding a new nonlinear term.
If you get stuck, do not hesitate to ask here.
Cheers & thanks for trying SfePy! r.
[1]
http://docs.sfepy.org/doc-devel/examples/linear_elasticity/material_nonlinea...
Kind regards Bjarke Dalslet
It works very well now.
I did try with problem.evaluate at first, but missed the mode='qp', so I could not make it work. I guess this is the intended way anyway as it is also compatible with the history attribute being 1.
Lots of good stuff in your edit - it will go straight into my own work ;D
I might want to try doing a few other poisson examples involving:
- Periodic boundary conditions using gmsh for meshing
- How to implement a heat source
Are these relevant, or should I just save the effort?
- Bjarke
On Wednesday, October 31, 2012 3:03:44 PM UTC+1, Robert Cimrman wrote:
On 10/31/2012 01:24 PM, Bjarke Dalslet wrote:
It works - sfepy iterates and the result converges. I have prepared a simple example, as it was difficult (to me at least) to find out how to get the temperature information. It is attached both as a patch and as a python file.
Thanks and welcome aboard!
thus the try/except clauses. Maybe there is a better way?
One issue with this implementation is that the deque "equations.variables._objs.find('T')" in the second iteration contains None which causes "equations.variables._objs.find('T').evaluate_at(coors)" to fail
This was caused by setting history attribute of T to 1. It is not needed as the variables hold their values from the previous time step anyway. There was also an issue with the tangent matrix that was not updating in the time steps as c(T) was changing. I fixed that by setting the problem to 'nonlinear'. Then I have made a little clean-up and used the short syntax for all the configuration items. The result is at [1] - I hope you recognize it :) Let me know if the new version works for you - I will then push the changes to the main repository.
Cheers, r. [1] https://github.com/rc/sfepy
- Bjarke
On Friday, October 26, 2012 12:08:00 PM UTC+2, Robert Cimrman wrote:
On 10/26/2012 11:51 AM, Bjarke Dalslet wrote:
Thanks a lot for the quick reply and good advice.
I will try the iterative approach then.
Let us know how it goes.
I only worry about speed as I am using sfepy to fit measured data. I
am
using 3 fitting parameters, and thus around 10K steady state simulations are necessary to get a good fit. This takes about a day with my current mesh, but honestly that is much faster than I expected when starting to look into FEM modelling.
So it's a brute-force approach to fitting? Anyway, a day is not so bad :). If that was using umfpack as a solver, you might get a significant improvement by using CG.
In all,I am very happy with the speed, accesibility and flexibility of sfepy.
Glad to hear that! r.
- Bjarke
On Friday, October 26, 2012 11:26:38 AM UTC+2, Robert Cimrman wrote:
Hello Bjarke!
On 10/26/2012 10:35 AM, Bjarke Dalslet wrote:
Hello sfepy users!
I am using sfepy to do thermal simulations of (BIG!) electric
Nothing fancy, but i would like to be able to use temperature dependent thermal conductivities as my system gets very hot.
At the moment I am employing the Laplace weak term: int(s * \nabla q *\nabla p) where s is the thermal conductivity, q is the test field parameter and
resistors. p
is
the temperature field
What i want is for s to depend on the temperature. I wonder which strategy to use: 1: To limit myself to a linear s, i.e. s(q)=s0+\alpha * q. In that case i guess i can do this: int(s(q) * \nabla q *\nabla p) = int(s0 * \nabla q *\nabla p)
int(\alpha * q * \nabla q *\nabla p) Unfortunately the second term is not implemented. Looking at the source, this would be some work to implement. 2: To iterate and after each iteration assign new values of s at each point. This would not be a big deal when doing time dependent simulations, but steady-state would be much slower to calculate I guess? An added plus would be that arbitrary c(q) could be used. 3: Ask for help here, and go "Ahhh! Of course!", when you state the obvious, easily implementable and fantastic solution.
I have only used sfepy for about a week, and this is the first time i am messing around with weak formulation FEM, so this question might be really silly, but I ask anyway: Is the strategy above completely crazy or am I on the right track?
I would try 2 first, as the Laplace equation can be very quickly solved by a conjugate gradients solver, so doing a few "time" iterations would not be that demanding. The linear system solution is fast even with the Python implementation from SciPy ('ls.scipy_iterative'), but if you have PETSc and petsc4py installed, it would be even faster ('ls.petsc') - see tests/test_linear_solvers.py file for example configurations of the linear solvers.
As for the artificial time-stepping, look at [1], which is almost exactly what you need, only the equation is the linear elasticity.
Then, if the above approach does not work, we could try adding a new nonlinear term.
If you get stuck, do not hesitate to ask here.
Cheers & thanks for trying SfePy! r.
[1]
http://docs.sfepy.org/doc-devel/examples/linear_elasticity/material_nonlinea...
Kind regards Bjarke Dalslet
On 10/31/2012 04:07 PM, Bjarke Dalslet wrote:
It works very well now.
I did try with problem.evaluate at first, but missed the mode='qp', so I could not make it work. I guess this is the intended way anyway as it is also compatible with the history attribute being 1.
Lots of good stuff in your edit - it will go straight into my own work ;D
Hth!
I might want to try doing a few other poisson examples involving:
- Periodic boundary conditions using gmsh for meshing
That would be interesting, especially the meshing part, as the periodic regions must have matching nodes.
- How to implement a heat source
This is probably already covered by examples/diffusion/poisson_functions.py and examples/diffusion/poisson_parametric_study.py, no?
Are these relevant, or should I just save the effort?
- Bjarke
r.
Ah yes, the power source is the same one as in examples/diffusion/poisson_parametric_study.py. BTW, is there a mistake in that files header? I believe the strong form should be $c\nabla^2 t=f$ and not $c\nabla t=f$.
I put it in the periodic boundary example anyway as it was a good way to visualize the periodic boundary condition. I have attached the files (.geo, .mesh and .py) and a patch.
- Bjarke
On 31 October 2012 16:48, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 10/31/2012 04:07 PM, Bjarke Dalslet wrote:
It works very well now.
I did try with problem.evaluate at first, but missed the mode='qp', so I could not make it work. I guess this is the intended way anyway as it is also compatible with the history attribute being 1.
Lots of good stuff in your edit - it will go straight into my own work ;D
Hth!
I might want to try doing a few other poisson examples involving:
- Periodic boundary conditions using gmsh for meshing
That would be interesting, especially the meshing part, as the periodic regions must have matching nodes.
- How to implement a heat source
This is probably already covered by examples/diffusion/poisson_**functions.py and examples/diffusion/poisson_**parametric_study.py, no?
Are these relevant, or should I just save the effort?
- Bjarke
r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel+unsubscribe@** googlegroups.com sfepy-devel%...@googlegroups.com. For more options, visit this group at http://groups.google.com/** group/sfepy-devel?hl=en http://groups.google.com/group/sfepy-devel?hl=en .
On 11/01/2012 04:19 PM, Bjarke Dalslet wrote:
Ah yes, the power source is the same one as in examples/diffusion/poisson_parametric_study.py. BTW, is there a mistake in that files header? I believe the strong form should be $c\nabla^2 t=f$ and not $c\nabla t=f$.
Yes, there is a typo, thanks for spotting that! It is fixed now.
I put it in the periodic boundary example anyway as it was a good way to visualize the periodic boundary condition. I have attached the files (.geo, .mesh and .py) and a patch.
Wow, I wish I mastered gmsh in such a way :)
IMHO this example should have the 'quasistatic' time solver option set to False. When it is True, an equilibrium is computed already for t = 0, so the next few time steps do nothing until you set the power off. With False, a nice time evolution is obtained, as can be seen when the color range is fixed by running:
./postproc.py cylinder_in_box.??.vtk -b --ranges=T,0,4.3
Then I have some few recommendations (do not get scared :)):
- Replace the periodic boundary condition definition by the short syntax version, so that all keywords use the same:
epbcs = { # In the y-direction 'periodic_y' : (['y+', 'y-'], {'T.0' : 'T.0'}, 'match_y_plane'), # and in the z-direction. Due to the symmetry of the problem, this periodic # boundary condition is actually not necessary, but we include it anyway. 'periodic_z' : (['z+', 'z-'], {'T.0' : 'T.0'}, 'match_z_plane'), }
Try to follow our coding style [1], which is basically what PEP-0008 says (lines max. 79 characters, spaces around '=' in assignment except keyword arguments, spaces behing commas...). The code should look like poisson_field_dependent_material.py does now. It really improves the readability for others. [2] might help here, with small tweaks mentioned below. It's not perfect, but gets most things right.
Instead of np.ones(len(coors[:,0]))*0, use np.zeros(), or np.zeros_like().
Also, in SfePy, we use nm for numpy abbreviation, as it started before np was declared standard by numpy guys. So, please, use nm for the moment. We may some day mass-replace all occurrences of nm. to np., but...
That's about it - I could have made the above changes myself, but by doing it yourself you might get it into your ways :) It's a nice example btw.
Cheers & thanks for contributing! r.
[1] http://docs.sfepy.org/doc-devel/developer_guide.html#coding-style [2] http://pypi.python.org/pypi/PythonTidy/
tweaks for [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
- Bjarke
On 31 October 2012 16:48, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 10/31/2012 04:07 PM, Bjarke Dalslet wrote:
It works very well now.
I did try with problem.evaluate at first, but missed the mode='qp', so I could not make it work. I guess this is the intended way anyway as it is also compatible with the history attribute being 1.
Lots of good stuff in your edit - it will go straight into my own work ;D
Hth!
I might want to try doing a few other poisson examples involving:
- Periodic boundary conditions using gmsh for meshing
That would be interesting, especially the meshing part, as the periodic regions must have matching nodes.
- How to implement a heat source
This is probably already covered by examples/diffusion/poisson_**functions.py and examples/diffusion/poisson_**parametric_study.py, no?
Are these relevant, or should I just save the effort?
- Bjarke
Ok, I think I fixed the style.
Have a nice weekend!
-Bjarke
On 1 November 2012 17:46, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 11/01/2012 04:19 PM, Bjarke Dalslet wrote:
Ah yes, the power source is the same one as in examples/diffusion/poisson_**parametric_study.py. BTW, is there a mistake in that files header? I believe the strong form should be $c\nabla^2 t=f$ and not $c\nabla t=f$.
Yes, there is a typo, thanks for spotting that! It is fixed now.
I put it in the periodic boundary example anyway as it was a good way to
visualize the periodic boundary condition. I have attached the files (.geo, .mesh and .py) and a patch.
Wow, I wish I mastered gmsh in such a way :)
IMHO this example should have the 'quasistatic' time solver option set to False. When it is True, an equilibrium is computed already for t = 0, so the next few time steps do nothing until you set the power off. With False, a nice time evolution is obtained, as can be seen when the color range is fixed by running:
./postproc.py cylinder_in_box.??.vtk -b --ranges=T,0,4.3
Then I have some few recommendations (do not get scared :)):
- Replace the periodic boundary condition definition by the short syntax version, so that all keywords use the same:
epbcs = { # In the y-direction 'periodic_y' : (['y+', 'y-'], {'T.0' : 'T.0'}, 'match_y_plane'), # and in the z-direction. Due to the symmetry of the problem, this periodic # boundary condition is actually not necessary, but we include it anyway. 'periodic_z' : (['z+', 'z-'], {'T.0' : 'T.0'}, 'match_z_plane'), }
Try to follow our coding style [1], which is basically what PEP-0008 says (lines max. 79 characters, spaces around '=' in assignment except keyword arguments, spaces behing commas...). The code should look like poisson_field_dependent_**material.py does now. It really improves the readability for others. [2] might help here, with small tweaks mentioned below. It's not perfect, but gets most things right.
Instead of np.ones(len(coors[:,0]))*0, use np.zeros(), or np.zeros_like().
Also, in SfePy, we use nm for numpy abbreviation, as it started before np was declared standard by numpy guys. So, please, use nm for the moment. We may some day mass-replace all occurrences of nm. to np., but...
That's about it - I could have made the above changes myself, but by doing it yourself you might get it into your ways :) It's a nice example btw.
Cheers & thanks for contributing! r.
[1] http://docs.sfepy.org/doc-**devel/developer_guide.html#**coding-stylehttp://docs.sfepy.org/doc-devel/developer_guide.html#coding-style [2] http://pypi.python.org/pypi/**PythonTidy/http://pypi.python.org/pypi/PythonTidy/
tweaks for [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
- Bjarke
On 31 October 2012 16:48, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 10/31/2012 04:07 PM, Bjarke Dalslet wrote:
It works very well now.
I did try with problem.evaluate at first, but missed the mode='qp', so I could not make it work. I guess this is the intended way anyway as it is also compatible with the history attribute being 1.
Lots of good stuff in your edit - it will go straight into my own work ;D
Hth!
I might want to try doing a few other poisson examples involving:
- Periodic boundary conditions using gmsh for meshing
That would be interesting, especially the meshing part, as the periodic regions must have matching nodes.
- How to implement a heat source
This is probably already covered by examples/diffusion/poisson_**** functions.py and examples/diffusion/poisson_****parametric_study.py, no?
Are these relevant, or should I just save the effort?
- Bjarke
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel+unsubscribe@** googlegroups.com sfepy-devel%...@googlegroups.com. For more options, visit this group at http://groups.google.com/** group/sfepy-devel?hl=en http://groups.google.com/group/sfepy-devel?hl=en .
Thank you! It's in (only slightly updated). I have also added tests for the two new diffusion examples.
Cheers, r.
On 11/02/2012 03:57 PM, Bjarke Dalslet wrote:
Ok, I think I fixed the style.
Have a nice weekend!
-Bjarke
On 1 November 2012 17:46, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 11/01/2012 04:19 PM, Bjarke Dalslet wrote:
Ah yes, the power source is the same one as in examples/diffusion/poisson_**parametric_study.py. BTW, is there a mistake in that files header? I believe the strong form should be $c\nabla^2 t=f$ and not $c\nabla t=f$.
Yes, there is a typo, thanks for spotting that! It is fixed now.
I put it in the periodic boundary example anyway as it was a good way to
visualize the periodic boundary condition. I have attached the files (.geo, .mesh and .py) and a patch.
Wow, I wish I mastered gmsh in such a way :)
IMHO this example should have the 'quasistatic' time solver option set to False. When it is True, an equilibrium is computed already for t = 0, so the next few time steps do nothing until you set the power off. With False, a nice time evolution is obtained, as can be seen when the color range is fixed by running:
./postproc.py cylinder_in_box.??.vtk -b --ranges=T,0,4.3
Then I have some few recommendations (do not get scared :)):
- Replace the periodic boundary condition definition by the short syntax version, so that all keywords use the same:
epbcs = { # In the y-direction 'periodic_y' : (['y+', 'y-'], {'T.0' : 'T.0'}, 'match_y_plane'), # and in the z-direction. Due to the symmetry of the problem, this periodic # boundary condition is actually not necessary, but we include it anyway. 'periodic_z' : (['z+', 'z-'], {'T.0' : 'T.0'}, 'match_z_plane'), }
Try to follow our coding style [1], which is basically what PEP-0008 says (lines max. 79 characters, spaces around '=' in assignment except keyword arguments, spaces behing commas...). The code should look like poisson_field_dependent_**material.py does now. It really improves the readability for others. [2] might help here, with small tweaks mentioned below. It's not perfect, but gets most things right.
Instead of np.ones(len(coors[:,0]))*0, use np.zeros(), or np.zeros_like().
Also, in SfePy, we use nm for numpy abbreviation, as it started before np was declared standard by numpy guys. So, please, use nm for the moment. We may some day mass-replace all occurrences of nm. to np., but...
That's about it - I could have made the above changes myself, but by doing it yourself you might get it into your ways :) It's a nice example btw.
Cheers & thanks for contributing! r.
[1] http://docs.sfepy.org/doc-**devel/developer_guide.html#**coding-stylehttp://docs.sfepy.org/doc-devel/developer_guide.html#coding-style [2] http://pypi.python.org/pypi/**PythonTidy/http://pypi.python.org/pypi/PythonTidy/
tweaks for [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
- Bjarke
participants (2)
-
Bjarke Dalslet -
Robert Cimrman