Hi Andre,
are you planning to go there?
r.
On Mon, 10 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis. Maybe if I can get it done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Hi Andre,
are you planning to go there?
r.
On Mon, 10 Jan 2011, Andre Smit wrote:
FYI: >
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis. Maybe if I can get it done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: Hi Andre,
are you planning to go there?
r.
On Mon, 10 Jan 2011, Andre Smit wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
Robert
I think I have something to share. How would you feel about co-authoring a paper to this conference - mainly to further expose SfePy but also to check that I'm not applying it incorrectly?
Using the strain rate dependency example you provided I recoded an example looking at the failure of a cylindrical specimen under compression. The cylinder is made up of elements that I treat individually or discretely, checking the strain rates in each and using a relationship established in the lab, I calculate the compressive strengths in the elements based on these strain rates. If the stress in an element exceeds its strength then the element fails and I assign a low stiffness to that element. The code I'm using is available here: http://paste.pocoo.org/show/320646/
Would you mind looking and commenting on this code. I'm a bit skeptical about the avgqp function which averages the strains at the quad points. Note that I use a normal distribution to vary the moduli of the elements initially.
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is demonstrate the influence of specimen geometry on strength. For simple compression and tension tests (on cylinders) this is trivial but with indirect tensile tests, for example, there is both compression and tension failure, and I hope to show using FEM that the strengths of materials determined using these tests are significantly influenced by the geometry of the specimen.
The force-displacement curves currently generated by the code look promising. I'm not sure the analysis can be refined by using smaller elements?
Andre
On Fri, Jan 14, 2011 at 3:19 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis. Maybe if I can get it
done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: Hi Andre,
are you planning to go there?
r.
On Mon, 10 Jan 2011, Andre Smit wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
Hi Andre,
(sorry for the delayed response - I'm accommodating in Fribourg again, and have not yet wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert
I think I have something to share. How would you feel about co-authoring a paper to this conference - mainly to further expose SfePy but also to check that I'm not applying it incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency example you provided I recoded an example looking at the failure of a cylindrical specimen under compression. The cylinder is made up of elements that I treat individually or discretely, checking the strain rates in each and using a relationship established in the lab, I calculate the compressive strengths in the elements based on these strain rates. If the stress in an element exceeds its strength then the element fails and I assign a low stiffness to that element. The code I'm using is available here: http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is the deadline, anyway? A few notes straight from my head follow.
What happens with the linear elastic assumption when you reduce stiffness in some elements? The code has some hyperelastic terms, in case they would be needed.
Would you mind looking and commenting on this code. I'm a bit skeptical about the avgqp function which averages the strains at the quad points. Note that I use a normal distribution to vary the moduli of the elements initially. �
To get averaged element values of something defined in quadrature points, one can use either directly de_volume_average_mat term (a fake material definition would then be needed, I can show you), or use directly similar code to the one in the body of that term. �
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is demonstrate the influence of specimen geometry on strength. For simple compression and tension tests (on cylinders) this is trivial but with indirect tensile tests, for example, there is both compression and tension failure, and I hope to show using FEM that the strengths of materials determined using these tests are significantly influenced by the geometry of the specimen.� � �
Interesting!
The force-displacement curves currently generated by the code look promising. I'm not sure the analysis can be refined by using smaller elements?
The mesh is not very fine, yes. Another way to refine the analysis might be to use another material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis.
Maybe if I can get it
done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
� � �Hi Andre,
� � �are you planning to go there?
� � �r.
On Mon, 10 Jan 2011, Andre Smit wrote:
� � �FYI:
� �
�http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � �--
� � �Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
At [1] I have posted the code with "correct" avgqp() function. Yours was ok, as long as all the quadrature point weights were the same.
The new implementation defines an auxiliary material with the quadrature point data, and calls the de_volume_average_mat term. Note that the order of the quadrature has to be the same as the one used for evaluating the strain.
Then it seems to me, that you could avoid all those loops in functions Ft(), Fc(), Ec(), by using numpy vectorized operations, i.e. numpy.exp() instead of math.exp(). Also the failure loops (around line 193) could be IMHO vectorized using numpy.where() and fancy indexing. Try it as a NumPy excercise :) - you get big speed gain by this, and also the code would be shorter and more readable. I can give you a hand if you get stuck, of course.
cheers, r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre,
(sorry for the delayed response - I'm accommodating in Fribourg again, and have not yet wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert
I think I have something to share. How would you feel about co-authoring a paper to this conference - mainly to further expose SfePy but also to check that I'm not applying it incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency example you provided I recoded an example looking at the failure of a cylindrical specimen under compression. The cylinder is made up of elements that I treat individually or discretely, checking the strain rates in each and using a relationship established in the lab, I calculate the compressive strengths in the elements based on these strain rates. If the stress in an element exceeds its strength then the element fails and I assign a low stiffness to that element. The code I'm using is available here: http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is the deadline, anyway? A few notes straight from my head follow.
What happens with the linear elastic assumption when you reduce stiffness in some elements? The code has some hyperelastic terms, in case they would be needed.
Would you mind looking and commenting on this code. I'm a bit skeptical about the avgqp function which averages the strains at the quad points. Note that I use a normal distribution to vary the moduli of the elements initially. �
To get averaged element values of something defined in quadrature points, one can use either directly de_volume_average_mat term (a fake material definition would then be needed, I can show you), or use directly similar code to the one in the body of that term. �
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is demonstrate the influence of specimen geometry on strength. For simple compression and tension tests (on cylinders) this is trivial but with indirect tensile tests, for example, there is both compression and tension failure, and I hope to show using FEM that the strengths of materials determined using these tests are significantly influenced by the geometry of the specimen.� � �
Interesting!
The force-displacement curves currently generated by the code look promising. I'm not sure the analysis can be refined by using smaller elements?
The mesh is not very fine, yes. Another way to refine the analysis might be to use another material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis.
Maybe if I can get it
done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
� � �Hi Andre,
� � �are you planning to go there?
� � �r.
On Mon, 10 Jan 2011, Andre Smit wrote:
� � �FYI:
� �
�http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � �--
� � �Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
Thanks Robert!
I'm working on the revisions and updates and will get back. The abstract is due at the end of January but I hope to get the bulk of the paper done by then as well, which is due in Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
At [1] I have posted the code with "correct" avgqp() function. Yours was ok, as long as all the quadrature point weights were the same.
The new implementation defines an auxiliary material with the quadrature point data, and calls the de_volume_average_mat term. Note that the order of the quadrature has to be the same as the one used for evaluating the strain.
Then it seems to me, that you could avoid all those loops in functions Ft(), Fc(), Ec(), by using numpy vectorized operations, i.e. numpy.exp() instead of math.exp(). Also the failure loops (around line 193) could be IMHO vectorized using numpy.where() and fancy indexing. Try it as a NumPy excercise :) - you get big speed gain by this, and also the code would be shorter and more readable. I can give you a hand if you get stuck, of course.
cheers, r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre, >
(sorry for the delayed response - I'm accommodating in Fribourg again, and have not yet wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert >
I think I have something to share. How would you feel about co-authoring a paper to this conference - mainly to further expose SfePy but also to check that I'm not applying it incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency example you provided I recoded an
example looking at the failure of a cylindrical specimen under compression. The cylinder is made up of elements that I treat individually or discretely, checking the strain rates in each and using a relationship established in the lab, I calculate the compressive strengths in the elements based on these strain rates. If the stress in an element exceeds its strength then the element fails and I assign a low stiffness to that element. The code I'm using is available here: http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is the deadline, anyway? A few notes straight from my head follow.
What happens with the linear elastic assumption when you reduce stiffness in some elements? The code has some hyperelastic terms, in case they would be needed.
Would you mind looking and commenting on this code. I'm a bit skeptical
about the avgqp function which averages the strains at the quad points. Note that I use a normal distribution to vary the moduli of the elements initially.
To get averaged element values of something defined in quadrature points, one can use either directly de_volume_average_mat term (a fake material definition would then be needed, I can show you), or use directly similar code to the one in the body of that term.
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is demonstrate the influence of specimen geometry on strength. For simple compression and tension tests (on cylinders) this is trivial but with indirect tensile tests, for example, there is both compression and tension failure, and I hope to show using FEM that the strengths of materials determined using these tests are significantly influenced by the geometry of the specimen.
Interesting!
The force-displacement curves currently generated by the code look
promising. I'm not sure the analysis can be refined by using smaller elements?
The mesh is not very fine, yes. Another way to refine the analysis might be to use another material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM, Robert Cimrman cimr...@ntc.zcu.cz
wrote: I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis.
Maybe if I can get it
done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning to go there?
r.
On Mon, 10 Jan 2011, Andre Smit wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
Robert
I've revised the code loops as shown in [1]. Seems to work. Yes, I still find myself thinking in FORTRAN :(
I'm looking at the hyperelastic option now. I've also asked Yannis Tassoulashttp://www.ce.utexas.edu/faculty-directory/profiles/john-tassoulas.htmlto consider joining as a co-author. He may have some ideas regarding plasticity options.
[1] http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit freev...@gmail.com wrote:
Thanks Robert!
I'm working on the revisions and updates and will get back. The abstract is due at the end of January but I hope to get the bulk of the paper done by then as well, which is due in Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman cimr...@ntc.zcu.czwrote:
At [1] I have posted the code with "correct" avgqp() function. Yours was ok, as long as all the quadrature point weights were the same.
The new implementation defines an auxiliary material with the quadrature point data, and calls the de_volume_average_mat term. Note that the order of the quadrature has to be the same as the one used for evaluating the strain.
Then it seems to me, that you could avoid all those loops in functions Ft(), Fc(), Ec(), by using numpy vectorized operations, i.e. numpy.exp() instead of math.exp(). Also the failure loops (around line 193) could be IMHO vectorized using numpy.where() and fancy indexing. Try it as a NumPy excercise :) - you get big speed gain by this, and also the code would be shorter and more readable. I can give you a hand if you get stuck, of course.
cheers, r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre, >
(sorry for the delayed response - I'm accommodating in Fribourg again, and have not yet wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert >
I think I have something to share. How would you feel about co-authoring a paper to this conference - mainly to further expose SfePy but also to check that I'm not applying it incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency example you provided I recoded an
example looking at the failure of a cylindrical specimen under compression. The cylinder is made up of elements that I treat individually or discretely, checking the strain rates in each and using a relationship established in the lab, I calculate the compressive strengths in the elements based on these strain rates. If the stress in an element exceeds its strength then the element fails and I assign a low stiffness to that element. The code I'm using is available here: http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is the deadline, anyway? A few notes straight from my head follow.
What happens with the linear elastic assumption when you reduce stiffness in some elements? The code has some hyperelastic terms, in case they would be needed.
Would you mind looking and commenting on this code. I'm a bit skeptical
about the avgqp function which averages the strains at the quad points. Note that I use a normal distribution to vary the moduli of the elements initially.
To get averaged element values of something defined in quadrature points, one can use either directly de_volume_average_mat term (a fake material definition would then be needed, I can show you), or use directly similar code to the one in the body of that term.
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is demonstrate the influence of specimen geometry on strength. For simple compression and tension tests (on cylinders) this is trivial but with indirect tensile tests, for example, there is both compression and tension failure, and I hope to show using FEM that the strengths of materials determined using these tests are significantly influenced by the geometry of the specimen.
Interesting!
The force-displacement curves currently generated by the code look
promising. I'm not sure the analysis can be refined by using smaller elements?
The mesh is not very fine, yes. Another way to refine the analysis might be to use another material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM, Robert Cimrman cimr...@ntc.zcu.cz
wrote: I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit wrote:
No plans currently - still working on an analysis.
Maybe if I can get it
done before the end of the month :)
On Thu, Jan 13, 2011 at 2:43 AM, Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning to go there?
r.
On Mon, 10 Jan 2011, Andre Smit wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
On Tue, 18 Jan 2011, Andre Smit wrote:
Robert
I've revised the code loops as shown in [1]. Seems to work. Yes, I still find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've also asked Yannis Tassoulas to consider joining as a co-author. He may have some ideas regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit freev...@gmail.com wrote: Thanks Robert!
I'm working on the revisions and updates and will get back.
The abstract is due at the end of January but I hope to get
the bulk of the paper done by then as well, which is due in
Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: At [1] I have posted the code with "correct" avgqp() function. Yours was ok, as long as all the quadrature point weights were the same.
The new implementation defines an auxiliary material
with the quadrature point data, and calls the
de_volume_average_mat term. Note that the order of the
quadrature has to be the same as the one used for
evaluating the strain.
Then it seems to me, that you could avoid all those
loops in
functions Ft(), Fc(), Ec(), by using numpy vectorized
operations, i.e. numpy.exp() instead of math.exp().
Also the failure loops (around line 193) could be IMHO
vectorized using numpy.where() and fancy indexing.
Try it as a NumPy excercise :) - you get big speed gain
by this, and also the code would be shorter and more
readable. I can give you a hand if you get stuck, of
course.
cheers,
r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre,
(sorry for the delayed response - I'm
accommodating in Fribourg again, and have not yet
wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert
I think I have something to share.
How would you feel about co-authoring
a paper to this conference - mainly
to further expose SfePy but also to
check that I'm not applying it
incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency
example you provided I recoded an
example looking at the failure of a
cylindrical specimen under
compression. The cylinder is made up
of elements that I treat
individually or discretely, checking
the strain rates in each and using a
relationship established in the lab,
I calculate the compressive
strengths in the elements based on
these strain rates. If the stress in
an element exceeds its strength then
the element fails and I assign a low
stiffness to that element. The code
I'm using is available here:
http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is
the deadline, anyway?
A few notes straight from my head follow.
What happens with the linear elastic assumption
when you reduce stiffness in some elements? The
code has some hyperelastic terms, in case they
would be needed.
Would you mind looking and commenting
on this code. I'm a bit skeptical
about the avgqp function which
averages the strains at the quad
points.
Note that I use a normal distribution
to vary the moduli of the elements
initially. �
To get averaged element values of something
defined in quadrature points, one can use either
directly de_volume_average_mat term (a fake
material definition would then be needed, I can
show you), or use directly similar code to the
one in the body of that term.
�
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is
demonstrate the influence of specimen
geometry on strength. For simple
compression and tension tests (on
cylinders) this is trivial but with
indirect tensile tests, for example,
there is both compression and tension
failure, and I hope to show using
FEM that the strengths of materials
determined using these tests are
significantly influenced by the
geometry of the specimen.� � �
Interesting!
The force-displacement curves
currently generated by the code look
promising. I'm not sure the analysis
can be refined by using smaller
elements?
The mesh is not very fine, yes. Another way to
refine the analysis might be to use another
material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM,
Robert Cimrman <cimr...@ntc.zcu.cz>
wrote:
� � �I see :) Good luck then!
� � �r.
On Thu, 13 Jan 2011, Andre Smit
wrote:
� � �No plans currently - still
working on an analysis.
� � �Maybe if I can get it
� � �done before the end of the month
:)
� � �On Thu, Jan 13, 2011 at 2:43 AM,
Robert Cimrman
� � �<cimr...@ntc.zcu.cz>
� � �wrote:
� � �� � �Hi Andre,
� � �� � �are you planning to go
there?
� � �� � �r.
� � �On Mon, 10 Jan 2011, Andre Smit
wrote:
� � �� � �FYI:
� � �� �
� �
��http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � �� � �--
� � �� � �Andre
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
Robert - I had a good meeting with Yannis this afternoon. He is concerned that the strain condition in the specimen after each time step as currently coded is not stable and suggested that a few iterations be run at each displacement interval to ensure that the element moduli converge before moving onto the next time step or displacement interval. To test his idea I ran a few iterations at a constant displacement and found that the forces do fluctuate quite a bit but appear to converge (somewhat) after about 10 iterations. I presume the moduli of the elements would also stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert Cimrman cimr...@ntc.zcu.czwrote:
On Tue, 18 Jan 2011, Andre Smit wrote:
Robert
I've revised the code loops as shown in [1]. Seems to work. Yes, I still find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've also asked Yannis
Tassoulas to consider joining as a co-author. He may have some ideas regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/ > >
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit freev...@gmail.com wrote: Thanks Robert!
I'm working on the revisions and updates and will get back.
The abstract is due at the end of January but I hope to get
the bulk of the paper done by then as well, which is due in
Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: At [1] I have posted the code with "correct" avgqp() function. Yours was ok, as long as all the quadrature point weights were the same.
The new implementation defines an auxiliary material
with the quadrature point data, and calls the
de_volume_average_mat term. Note that the order of the
quadrature has to be the same as the one used for
evaluating the strain.
Then it seems to me, that you could avoid all those
loops in
functions Ft(), Fc(), Ec(), by using numpy vectorized
operations, i.e. numpy.exp() instead of math.exp().
Also the failure loops (around line 193) could be IMHO
vectorized using numpy.where() and fancy indexing.
Try it as a NumPy excercise :) - you get big speed gain
by this, and also the code would be shorter and more
readable. I can give you a hand if you get stuck, of
course.
cheers,
r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre,
(sorry for the delayed response - I'm
accommodating in Fribourg again, and have not yet
wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert
I think I have something to share.
How would you feel about co-authoring
a paper to this conference - mainly
to further expose SfePy but also to
check that I'm not applying it
incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency
example you provided I recoded an
example looking at the failure of a
cylindrical specimen under
compression. The cylinder is made up
of elements that I treat
individually or discretely, checking
the strain rates in each and using a
relationship established in the lab,
I calculate the compressive
strengths in the elements based on
these strain rates. If the stress in
an element exceeds its strength then
the element fails and I assign a low
stiffness to that element. The code
I'm using is available here:
http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is
the deadline, anyway?
A few notes straight from my head follow.
What happens with the linear elastic assumption
when you reduce stiffness in some elements? The
code has some hyperelastic terms, in case they
would be needed.
Would you mind looking and commenting
on this code. I'm a bit skeptical
about the avgqp function which
averages the strains at the quad
points.
Note that I use a normal distribution
to vary the moduli of the elements
initially.
To get averaged element values of something
defined in quadrature points, one can use either
directly de_volume_average_mat term (a fake
material definition would then be needed, I can
show you), or use directly similar code to the
one in the body of that term.
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is
demonstrate the influence of specimen
geometry on strength. For simple
compression and tension tests (on
cylinders) this is trivial but with
indirect tensile tests, for example,
there is both compression and tension
failure, and I hope to show using
FEM that the strengths of materials
determined using these tests are
significantly influenced by the
geometry of the specimen.
Interesting!
The force-displacement curves
currently generated by the code look
promising. I'm not sure the analysis
can be refined by using smaller
elements?
The mesh is not very fine, yes. Another way to
refine the analysis might be to use another
material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM,
Robert Cimrman <cimr...@ntc.zcu.cz>
wrote:
I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit
wrote:
No plans currently - still
working on an analysis.
Maybe if I can get it
done before the end of the month
:)
On Thu, Jan 13, 2011 at 2:43 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning to go
there?
r.
On Mon, 10 Jan 2011, Andre Smit
wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
Robert
Using simple.py is generating too much output. To have better control over this I decided to convert to a standalone app as shown at [1] using one of the sfepy examples as reference. Something is not working as the forces at each time step are zero. Can you please have a look.
Thanks
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit freev...@gmail.com wrote:
Robert - I had a good meeting with Yannis this afternoon. He is concerned that the strain condition in the specimen after each time step as currently coded is not stable and suggested that a few iterations be run at each displacement interval to ensure that the element moduli converge before moving onto the next time step or displacement interval. To test his idea I ran a few iterations at a constant displacement and found that the forces do fluctuate quite a bit but appear to converge (somewhat) after about 10 iterations. I presume the moduli of the elements would also stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert Cimrman cimr...@ntc.zcu.czwrote:
On Tue, 18 Jan 2011, Andre Smit wrote:
Robert
I've revised the code loops as shown in [1]. Seems to work. Yes, I still find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've also asked Yannis
Tassoulas to consider joining as a co-author. He may have some ideas regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/ > >
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit freev...@gmail.com wrote: Thanks Robert!
I'm working on the revisions and updates and will get back.
The abstract is due at the end of January but I hope to get
the bulk of the paper done by then as well, which is due in
Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: At [1] I have posted the code with "correct" avgqp() function. Yours was ok, as long as all the quadrature point weights were the same.
The new implementation defines an auxiliary material
with the quadrature point data, and calls the
de_volume_average_mat term. Note that the order of the
quadrature has to be the same as the one used for
evaluating the strain.
Then it seems to me, that you could avoid all those
loops in
functions Ft(), Fc(), Ec(), by using numpy vectorized
operations, i.e. numpy.exp() instead of math.exp().
Also the failure loops (around line 193) could be IMHO
vectorized using numpy.where() and fancy indexing.
Try it as a NumPy excercise :) - you get big speed gain
by this, and also the code would be shorter and more
readable. I can give you a hand if you get stuck, of
course.
cheers,
r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre,
(sorry for the delayed response - I'm
accommodating in Fribourg again, and have not yet
wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert
I think I have something to share.
How would you feel about co-authoring
a paper to this conference - mainly
to further expose SfePy but also to
check that I'm not applying it
incorrectly?
That would be great, thanks for proposing it!
Using the strain rate dependency
example you provided I recoded an
example looking at the failure of a
cylindrical specimen under
compression. The cylinder is made up
of elements that I treat
individually or discretely, checking
the strain rates in each and using a
relationship established in the lab,
I calculate the compressive
strengths in the elements based on
these strain rates. If the stress in
an element exceeds its strength then
the element fails and I assign a low
stiffness to that element. The code
I'm using is available here:
http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP. What is
the deadline, anyway?
A few notes straight from my head follow.
What happens with the linear elastic assumption
when you reduce stiffness in some elements? The
code has some hyperelastic terms, in case they
would be needed.
Would you mind looking and commenting
on this code. I'm a bit skeptical
about the avgqp function which
averages the strains at the quad
points.
Note that I use a normal distribution
to vary the moduli of the elements
initially.
To get averaged element values of something
defined in quadrature points, one can use either
directly de_volume_average_mat term (a fake
material definition would then be needed, I can
show you), or use directly similar code to the
one in the body of that term.
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is
demonstrate the influence of specimen
geometry on strength. For simple
compression and tension tests (on
cylinders) this is trivial but with
indirect tensile tests, for example,
there is both compression and tension
failure, and I hope to show using
FEM that the strengths of materials
determined using these tests are
significantly influenced by the
geometry of the specimen.
Interesting!
The force-displacement curves
currently generated by the code look
promising. I'm not sure the analysis
can be refined by using smaller
elements?
The mesh is not very fine, yes. Another way to
refine the analysis might be to use another
material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM,
Robert Cimrman <cimr...@ntc.zcu.cz>
wrote:
I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit
wrote:
No plans currently - still
working on an analysis.
Maybe if I can get it
done before the end of the month
:)
On Thu, Jan 13, 2011 at 2:43 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning to go
there?
r.
On Mon, 10 Jan 2011, Andre Smit
wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
The zero forces are because you have changed the traction() function to the form used by material-defining functions. It should look (like in your previous versions) as:
def traction(ts, coors, bc=None): disp = -(ts.dt*(ts.step+1)) val = nm.empty_like(coors[:,0]) val.fill(disp) return val
i.e. as a bc-defining function.
As for too much output printed, yes, we should address the issue 16 one day in a systematic way. I do not know yet, how to control the output flexibly enough yet unobtrusively.
Right now you can do several things:
- you can use the fact, that all messages that SfePy outputs are printed using the output() function - it's not just a function but an instance of the Output class (see sfepy/base/base.py), and as such can be controlled:
So after adding:
from sfepy.base.base import output
output.set_output(filename='output_log.txt')
to the beginning of your main() function, all the output is redirected into the specified file. At the same time, messages you print using 'print' are still printed.
- Note that you could use an Output instance to log your messages too:
from sfepy.base.base import Output
my_output = Output('strainer:', filename='my_log.txt', combined=True)
my_output('hello!')
I have modified your script in this way, see [2].
- the above method can be used together with using simple.py - you get the standard, and your custom outputs well-split.
Just put:
from sfepy.base.base import output, Output
my_output = Output('strainer:', filename='my_log.txt', combined=True) output.set_output(filename='output_log.txt')
at the top of the file, and run it with simple.py
The example at [2] already has this - it can be run as both standalone and via simple.py...
- the deprecation warnings coming from numpy/scipy can be suppressed by:
import warnings warnings.filterwarnings("ignore")
(also done at [2])
- the Log class in sfepy.base.log can be used to plot and log data, see examples/standalone/live_plot/live_plot.py
As I think of it now, it seems that the issue 16 can be tackled by documenting the above features :)
Does it help?
r. PS: I used the old cylgeo.vtk mesh, as I do not have the new one, so you have to fix the paths and region definitions in the paste [2].
[2] http://paste.pocoo.org/show/323128/
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert
Using simple.py is generating too much output. To have better control over this I decided to convert to a standalone app as shown at [1] using one of the sfepy examples as reference. Something is not working as the forces at each time step are zero. Can you please have a look.
Thanks �
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit freev...@gmail.com wrote: Robert - I had a good meeting with Yannis this afternoon. He is concerned that the strain condition in the specimen after each time step as currently coded is not stable and suggested that a few iterations be run at each displacement interval to ensure that the element moduli converge before moving onto the next time step or displacement interval. To test his idea I ran a few iterations at a constant displacement and found that the forces do fluctuate quite a bit but appear to converge (somewhat) after about 10 iterations. I presume the moduli of the elements would also stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: On Tue, 18 Jan 2011, Andre Smit wrote: Robert
I've revised the code loops as shown in [1].
Seems to work. Yes, I still
find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've
also asked Yannis
Tassoulas to consider joining as a co-author. He
may have some ideas
regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit
<freev...@gmail.com>
wrote:
� � �Thanks Robert!
� � �I'm working on the revisions and updates and
will get back.
� � �The abstract is due at the end of January
but I hope to get
� � �the bulk of the paper done by then as well,
which is due in
� � �Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman
<cimr...@ntc.zcu.cz> wrote:
� � �At [1] I have posted the code with "correct"
avgqp()
� � �function. Yours was ok, as long as all the
quadrature
� � �point weights were the same.
� � �The new implementation defines an auxiliary
material
� � �with the quadrature point data, and calls
the
� � �de_volume_average_mat term. Note that the
order of the
� � �quadrature has to be the same as the one
used for
� � �evaluating the strain.
� � �Then it seems to me, that you could avoid
all those
� � �loops in
� � �functions Ft(), Fc(), Ec(), by using numpy
vectorized
� � �operations, i.e. numpy.exp() instead of
math.exp().
� � �Also the failure loops (around line 193)
could be IMHO
� � �vectorized using numpy.where() and fancy
indexing.
� � �Try it as a NumPy excercise :) - you get big
speed gain
� � �by this, and also the code would be shorter
and more
� � �readable. I can give you a hand if you get
stuck, of
� � �course.
� � �cheers,
� � �r.
� � �[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
� � �Hi Andre,
� � �(sorry for the delayed response - I'm
� � �accommodating in Fribourg again, and have
not yet
� � �wifi at home...)
� � �On Fri, 14 Jan 2011, Andre Smit wrote:
� � � � � �Robert
� � � � � �I think I have something to share.
� � � � � �How would you feel about co-authoring
� � � � � �a paper to this conference - mainly
� � � � � �to further expose SfePy but also to
� � � � � �check that I'm not applying it
� � � � � �incorrectly?
� � �That would be great, thanks for proposing
it!
� � � � � �Using the strain rate dependency
� � � � � �example you provided I recoded an
� � � � � �example looking at the failure of a
� � � � � �cylindrical specimen under
� � � � � �compression. The cylinder is made up
� � � � � �of elements that I treat
� � � � � �individually or discretely, checking
� � � � � �the strain rates in each and using a
� � � � � �relationship established in the lab,
� � � � � �I calculate the compressive
� � � � � �strengths in the elements based on
� � � � � �these strain rates. If the stress in
� � � � � �an element exceeds its strength then
� � � � � �the element fails and I assign a low
� � � � � �stiffness to that element. The code
� � � � � �I'm using is available here:
� � � � � �http://paste.pocoo.org/show/320646/
� � �I will look at the code and try it ASAP.
What is
� � �the deadline, anyway?
� � �A few notes straight from my head follow.
� � �What happens with the linear elastic
assumption
� � �when you reduce stiffness in some elements?
The
� � �code has some hyperelastic terms, in case
they
� � �would be needed.
� � � � � �Would you mind looking and commenting
� � � � � �on this code. I'm a bit skeptical
� � � � � �about the avgqp function which
� � � � � �averages the strains at the quad
� � � � � �points.
� � � � � �Note that I use a normal distribution
� � � � � �to vary the moduli of the elements
� � � � � �initially. �
� � �To get averaged element values of something
� � �defined in quadrature points, one can use
either
� � �directly de_volume_average_mat term (a fake
� � �material definition would then be needed, I
can
� � �show you), or use directly similar code to
the
� � �one in the body of that term.
� � ��
� � � � � �I've attached the mesh: cylgeo.vtk.
� � � � � �What I aim to do with the paper is
� � � � � �demonstrate the influence of specimen
� � � � � �geometry on strength. For simple
� � � � � �compression and tension tests (on
� � � � � �cylinders) this is trivial but with
� � � � � �indirect tensile tests, for example,
� � � � � �there is both compression and tension
� � � � � �failure, and I hope to show using
� � � � � �FEM that the strengths of materials
� � � � � �determined using these tests are
� � � � � �significantly influenced by the
� � � � � �geometry of the specimen.� � �
� � �Interesting!
� � � � � �The force-displacement curves
� � � � � �currently generated by the code look
� � � � � �promising. I'm not sure the analysis
� � � � � �can be refined by using smaller
� � � � � �elements?
� � �The mesh is not very fine, yes. Another way
to
� � �refine the analysis might be to use another
� � �material relation (hyperelastic?).
� � �r.
� � � � � �On Fri, Jan 14, 2011 at 3:19 AM,
� � � � � �Robert Cimrman <cimr...@ntc.zcu.cz>
� � � � � �wrote:
� � � � � �� � �I see :) Good luck then!
� � � � � �� � �r.
� � � � � �On Thu, 13 Jan 2011, Andre Smit
� � � � � �wrote:
� � � � � �� � �No plans currently - still
� � � � � �working on an analysis.
� � � � � �� � �Maybe if I can get it
� � � � � �� � �done before the end of the
month
� � � � � �:)
� � � � � �� � �On Thu, Jan 13, 2011 at
2:43 AM,
� � � � � �Robert Cimrman
� � � � � �� � �<cimr...@ntc.zcu.cz>
� � � � � �� � �wrote:
� � � � � �� � �� � �Hi
Andre,
� � � � � �� � �� � �are you
planning to go
� � � � � �there?
� � � � � �� � �� � �r.
� � � � � �� � �On Mon, 10 Jan 2011, Andre
Smit
� � � � � �wrote:
� � � � � �� � �� � �FYI:
� � � � � �� � �� �
� � � � � �� �
� � � � �
���http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � � � � �� � �� � �--
� � � � � �� � �� � �Andre
� � � � � �--
� � � � � �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...@googlegroups.com.
� � � � � �For more options, visit this group at
� � � � �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �--
� � � � � �Andre
� � � � � �--
� � � � � �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...@googlegroups.com.
� � � � � �For more options, visit this group at
� � � � �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � �--
� � �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...@googlegroups.com.
� � �For more options, visit this group at
� �
�http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
One more thing: there was a bug in the Output() class constructor arguments, so you need the latest sources for the code below.
r.
On Wed, 19 Jan 2011, Robert Cimrman wrote:
The zero forces are because you have changed the traction() function to the form used by material-defining functions. It should look (like in your previous versions) as:
def traction(ts, coors, bc=None): disp = -(ts.dt*(ts.step+1)) val = nm.empty_like(coors[:,0]) val.fill(disp) return val
i.e. as a bc-defining function.
As for too much output printed, yes, we should address the issue 16 one day in a systematic way. I do not know yet, how to control the output flexibly enough yet unobtrusively.
Right now you can do several things:
- you can use the fact, that all messages that SfePy outputs are printed using the output() function - it's not just a function but an instance of the Output class (see sfepy/base/base.py), and as such can be controlled:
So after adding:
from sfepy.base.base import output
output.set_output(filename='output_log.txt')
to the beginning of your main() function, all the output is redirected into the specified file. At the same time, messages you print using 'print' are still printed.
- Note that you could use an Output instance to log your messages too:
from sfepy.base.base import Output
my_output = Output('strainer:', filename='my_log.txt', combined=True)
my_output('hello!')
I have modified your script in this way, see [2].
- the above method can be used together with using simple.py - you get the standard, and your custom outputs well-split.
Just put:
from sfepy.base.base import output, Output
my_output = Output('strainer:', filename='my_log.txt', combined=True) output.set_output(filename='output_log.txt')
at the top of the file, and run it with simple.py
The example at [2] already has this - it can be run as both standalone and via simple.py...
- the deprecation warnings coming from numpy/scipy can be suppressed by:
import warnings warnings.filterwarnings("ignore")
(also done at [2])
- the Log class in sfepy.base.log can be used to plot and log data, see examples/standalone/live_plot/live_plot.py
As I think of it now, it seems that the issue 16 can be tackled by documenting the above features :)
Does it help?
r. PS: I used the old cylgeo.vtk mesh, as I do not have the new one, so you have to fix the paths and region definitions in the paste [2].
[2] http://paste.pocoo.org/show/323128/
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert
Using simple.py is generating too much output. To have better control over this I decided to convert to a standalone app as shown at [1] using one of the sfepy examples as reference. Something is not working as the forces at each time step are zero. Can you please have a look.
Thanks �
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit freev...@gmail.com wrote: Robert - I had a good meeting with Yannis this afternoon. He is concerned that the strain condition in the specimen after each time step as currently coded is not stable and suggested that a few iterations be run at each displacement interval to ensure that the element moduli converge before moving onto the next time step or displacement interval. To test his idea I ran a few iterations at a constant displacement and found that the forces do fluctuate quite a bit but appear to converge (somewhat) after about 10 iterations. I presume the moduli of the elements would also stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: On Tue, 18 Jan 2011, Andre Smit wrote: Robert
I've revised the code loops as shown in [1].
Seems to work. Yes, I still
find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've
also asked Yannis
Tassoulas to consider joining as a co-author. He
may have some ideas
regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit
<freev...@gmail.com>
wrote:
� � �Thanks Robert!
� � �I'm working on the revisions and updates and
will get back.
� � �The abstract is due at the end of January
but I hope to get
� � �the bulk of the paper done by then as well,
which is due in
� � �Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman
<cimr...@ntc.zcu.cz> wrote:
� � �At [1] I have posted the code with "correct"
avgqp()
� � �function. Yours was ok, as long as all the
quadrature
� � �point weights were the same.
� � �The new implementation defines an auxiliary
material
� � �with the quadrature point data, and calls
the
� � �de_volume_average_mat term. Note that the
order of the
� � �quadrature has to be the same as the one
used for
� � �evaluating the strain.
� � �Then it seems to me, that you could avoid
all those
� � �loops in
� � �functions Ft(), Fc(), Ec(), by using numpy
vectorized
� � �operations, i.e. numpy.exp() instead of
math.exp().
� � �Also the failure loops (around line 193)
could be IMHO
� � �vectorized using numpy.where() and fancy
indexing.
� � �Try it as a NumPy excercise :) - you get big
speed gain
� � �by this, and also the code would be shorter
and more
� � �readable. I can give you a hand if you get
stuck, of
� � �course.
� � �cheers,
� � �r.
� � �[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
� � �Hi Andre,
� � �(sorry for the delayed response - I'm
� � �accommodating in Fribourg again, and have
not yet
� � �wifi at home...)
� � �On Fri, 14 Jan 2011, Andre Smit wrote:
� � � � � �Robert
� � � � � �I think I have something to share.
� � � � � �How would you feel about co-authoring
� � � � � �a paper to this conference - mainly
� � � � � �to further expose SfePy but also to
� � � � � �check that I'm not applying it
� � � � � �incorrectly?
� � �That would be great, thanks for proposing
it!
� � � � � �Using the strain rate dependency
� � � � � �example you provided I recoded an
� � � � � �example looking at the failure of a
� � � � � �cylindrical specimen under
� � � � � �compression. The cylinder is made up
� � � � � �of elements that I treat
� � � � � �individually or discretely, checking
� � � � � �the strain rates in each and using a
� � � � � �relationship established in the lab,
� � � � � �I calculate the compressive
� � � � � �strengths in the elements based on
� � � � � �these strain rates. If the stress in
� � � � � �an element exceeds its strength then
� � � � � �the element fails and I assign a low
� � � � � �stiffness to that element. The code
� � � � � �I'm using is available here:
� � � � � �http://paste.pocoo.org/show/320646/
� � �I will look at the code and try it ASAP.
What is
� � �the deadline, anyway?
� � �A few notes straight from my head follow.
� � �What happens with the linear elastic
assumption
� � �when you reduce stiffness in some elements?
The
� � �code has some hyperelastic terms, in case
they
� � �would be needed.
� � � � � �Would you mind looking and commenting
� � � � � �on this code. I'm a bit skeptical
� � � � � �about the avgqp function which
� � � � � �averages the strains at the quad
� � � � � �points.
� � � � � �Note that I use a normal distribution
� � � � � �to vary the moduli of the elements
� � � � � �initially. �
� � �To get averaged element values of something
� � �defined in quadrature points, one can use
either
� � �directly de_volume_average_mat term (a fake
� � �material definition would then be needed, I
can
� � �show you), or use directly similar code to
the
� � �one in the body of that term.
� � ��
� � � � � �I've attached the mesh: cylgeo.vtk.
� � � � � �What I aim to do with the paper is
� � � � � �demonstrate the influence of specimen
� � � � � �geometry on strength. For simple
� � � � � �compression and tension tests (on
� � � � � �cylinders) this is trivial but with
� � � � � �indirect tensile tests, for example,
� � � � � �there is both compression and tension
� � � � � �failure, and I hope to show using
� � � � � �FEM that the strengths of materials
� � � � � �determined using these tests are
� � � � � �significantly influenced by the
� � � � � �geometry of the specimen.� � �
� � �Interesting!
� � � � � �The force-displacement curves
� � � � � �currently generated by the code look
� � � � � �promising. I'm not sure the analysis
� � � � � �can be refined by using smaller
� � � � � �elements?
� � �The mesh is not very fine, yes. Another way
to
� � �refine the analysis might be to use another
� � �material relation (hyperelastic?).
� � �r.
� � � � � �On Fri, Jan 14, 2011 at 3:19 AM,
� � � � � �Robert Cimrman <cimr...@ntc.zcu.cz>
� � � � � �wrote:
� � � � � �� � �I see :) Good luck then!
� � � � � �� � �r.
� � � � � �On Thu, 13 Jan 2011, Andre Smit
� � � � � �wrote:
� � � � � �� � �No plans currently - still
� � � � � �working on an analysis.
� � � � � �� � �Maybe if I can get it
� � � � � �� � �done before the end of the
month
� � � � � �:)
� � � � � �� � �On Thu, Jan 13, 2011 at
2:43 AM,
� � � � � �Robert Cimrman
� � � � � �� � �<cimr...@ntc.zcu.cz>
� � � � � �� � �wrote:
� � � � � �� � �� � �Hi
Andre,
� � � � � �� � �� � �are you
planning to go
� � � � � �there?
� � � � � �� � �� � �r.
� � � � � �� � �On Mon, 10 Jan 2011, Andre
Smit
� � � � � �wrote:
� � � � � �� � �� � �FYI:
� � � � � �� � �� �
� � � � � �� �
� � � � �
���http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � � � � �� � �� � �--
� � � � � �� � �� � �Andre
� � � � � �--
� � � � � �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...@googlegroups.com.
� � � � � �For more options, visit this group at
� � � � �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �--
� � � � � �Andre
� � � � � �--
� � � � � �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...@googlegroups.com.
� � � � � �For more options, visit this group at
� � � � �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � �--
� � �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...@googlegroups.com.
� � �For more options, visit this group at
� �
�http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
Thanks Robert - the code works great. Regarding the output - I was really concerned about the large number of vtk files being generated when running thru simple.py with the extra iterations applied to stabilize the force. Now as a standalone I can suppress this and the script runs faster too! I like the idea of gradually reducing modulus for stabilization.
On Wed, Jan 19, 2011 at 3:09 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
One more thing: there was a bug in the Output() class constructor arguments, so you need the latest sources for the code below.
r.
On Wed, 19 Jan 2011, Robert Cimrman wrote:
The zero forces are because you have changed the traction() function to
the form used by material-defining functions. It should look (like in your previous versions) as:
def traction(ts, coors, bc=None): disp = -(ts.dt*(ts.step+1)) val = nm.empty_like(coors[:,0]) val.fill(disp) return val
i.e. as a bc-defining function.
As for too much output printed, yes, we should address the issue 16 one day in a systematic way. I do not know yet, how to control the output flexibly enough yet unobtrusively.
Right now you can do several things:
- you can use the fact, that all messages that SfePy outputs are printed using the output() function - it's not just a function but an instance of the Output class (see sfepy/base/base.py), and as such can be controlled:
So after adding:
from sfepy.base.base import output
output.set_output(filename='output_log.txt')
to the beginning of your main() function, all the output is redirected into the specified file. At the same time, messages you print using 'print' are still printed.
- Note that you could use an Output instance to log your messages too:
from sfepy.base.base import Output
my_output = Output('strainer:', filename='my_log.txt', combined=True)
my_output('hello!')
I have modified your script in this way, see [2].
- the above method can be used together with using simple.py - you get the standard, and your custom outputs well-split.
Just put:
from sfepy.base.base import output, Output
my_output = Output('strainer:', filename='my_log.txt', combined=True) output.set_output(filename='output_log.txt')
at the top of the file, and run it with simple.py
The example at [2] already has this - it can be run as both standalone and via simple.py...
- the deprecation warnings coming from numpy/scipy can be suppressed by:
import warnings warnings.filterwarnings("ignore")
(also done at [2])
- the Log class in sfepy.base.log can be used to plot and log data, see examples/standalone/live_plot/live_plot.py
As I think of it now, it seems that the issue 16 can be tackled by documenting the above features :)
Does it help?
r. PS: I used the old cylgeo.vtk mesh, as I do not have the new one, so you have to fix the paths and region definitions in the paste [2].
[2] http://paste.pocoo.org/show/323128/
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert >
Using simple.py is generating too much output. To have better control over this I decided to convert to a standalone app as shown at [1] using one of the sfepy examples as reference. Something is not working as the forces at each time step are zero. Can you please have a look.
Thanks
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit freev...@gmail.com wrote: Robert - I had a good meeting with Yannis this afternoon. He is concerned that the strain condition in the specimen after each time step as currently coded is not stable and suggested that a few iterations be run at each displacement interval to ensure that the element moduli converge before moving onto the next time step or displacement interval. To test his idea I ran a few iterations at a constant displacement and found that the forces do fluctuate quite a bit but appear to converge (somewhat) after about 10 iterations. I presume the moduli of the elements would also stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: On Tue, 18 Jan 2011, Andre Smit wrote: Robert
I've revised the code loops as shown in [1].
Seems to work. Yes, I still
find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've
also asked Yannis
Tassoulas to consider joining as a co-author. He
may have some ideas
regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit
<freev...@gmail.com>
wrote:
Thanks Robert!
I'm working on the revisions and updates and
will get back.
The abstract is due at the end of January
but I hope to get
the bulk of the paper done by then as well,
which is due in
Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman
<cimr...@ntc.zcu.cz> wrote:
At [1] I have posted the code with "correct"
avgqp()
function. Yours was ok, as long as all the
quadrature
point weights were the same.
The new implementation defines an auxiliary
material
with the quadrature point data, and calls
the
de_volume_average_mat term. Note that the
order of the
quadrature has to be the same as the one
used for
evaluating the strain.
Then it seems to me, that you could avoid
all those
loops in
functions Ft(), Fc(), Ec(), by using numpy
vectorized
operations, i.e. numpy.exp() instead of
math.exp().
Also the failure loops (around line 193)
could be IMHO
vectorized using numpy.where() and fancy
indexing.
Try it as a NumPy excercise :) - you get big
speed gain
by this, and also the code would be shorter
and more
readable. I can give you a hand if you get
stuck, of
course.
cheers,
r.
[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
Hi Andre,
(sorry for the delayed response - I'm
accommodating in Fribourg again, and have
not yet
wifi at home...)
On Fri, 14 Jan 2011, Andre Smit wrote:
Robert
I think I have something to share.
How would you feel about co-authoring
a paper to this conference - mainly
to further expose SfePy but also to
check that I'm not applying it
incorrectly?
That would be great, thanks for proposing
it!
Using the strain rate dependency
example you provided I recoded an
example looking at the failure of a
cylindrical specimen under
compression. The cylinder is made up
of elements that I treat
individually or discretely, checking
the strain rates in each and using a
relationship established in the lab,
I calculate the compressive
strengths in the elements based on
these strain rates. If the stress in
an element exceeds its strength then
the element fails and I assign a low
stiffness to that element. The code
I'm using is available here:
http://paste.pocoo.org/show/320646/
I will look at the code and try it ASAP.
What is
the deadline, anyway?
A few notes straight from my head follow.
What happens with the linear elastic
assumption
when you reduce stiffness in some elements?
The
code has some hyperelastic terms, in case
they
would be needed.
Would you mind looking and commenting
on this code. I'm a bit skeptical
about the avgqp function which
averages the strains at the quad
points.
Note that I use a normal distribution
to vary the moduli of the elements
initially.
To get averaged element values of something
defined in quadrature points, one can use
either
directly de_volume_average_mat term (a fake
material definition would then be needed, I
can
show you), or use directly similar code to
the
one in the body of that term.
I've attached the mesh: cylgeo.vtk.
What I aim to do with the paper is
demonstrate the influence of specimen
geometry on strength. For simple
compression and tension tests (on
cylinders) this is trivial but with
indirect tensile tests, for example,
there is both compression and tension
failure, and I hope to show using
FEM that the strengths of materials
determined using these tests are
significantly influenced by the
geometry of the specimen.
Interesting!
The force-displacement curves
currently generated by the code look
promising. I'm not sure the analysis
can be refined by using smaller
elements?
The mesh is not very fine, yes. Another way
to
refine the analysis might be to use another
material relation (hyperelastic?).
r.
On Fri, Jan 14, 2011 at 3:19 AM,
Robert Cimrman <cimr...@ntc.zcu.cz>
wrote:
I see :) Good luck then!
r.
On Thu, 13 Jan 2011, Andre Smit
wrote:
No plans currently - still
working on an analysis.
Maybe if I can get it
done before the end of the month
:)
On Thu, Jan 13, 2011 at 2:43 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning to go
there?
r.
On Mon, 10 Jan 2011, Andre Smit
wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
Oh, this output! Then you can try also putting
'output_format' : 'h5',
into the options. All results will then be saved into a single HDF5 file with many time steps.
hth, r.
On Wed, 19 Jan 2011, Andre Smit wrote:
Thanks Robert - the code works great. Regarding the output - I was really concerned about the large number of vtk files being generated when running thru simple.py with the extra iterations applied to stabilize the force. Now as a standalone I can suppress this and the script runs faster too! I like the idea of gradually reducing modulus for stabilization.
On Wed, Jan 19, 2011 at 3:09 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: One more thing: there was a bug in the Output() class constructor arguments, so you need the latest sources for the code below.
r.
On Wed, 19 Jan 2011, Robert Cimrman wrote:
The zero forces are because you have changed the
traction() function to the form used by
material-defining functions. It should look (like in
your previous versions) as:
def traction(ts, coors, bc=None):
� disp = -(ts.dt*(ts.step+1))
� val = nm.empty_like(coors[:,0])
� val.fill(disp)
� return val
i.e. as a bc-defining function.
As for too much output printed, yes, we should address
the issue 16 one day in a systematic way. I do not know
yet, how to control the output flexibly enough yet
unobtrusively.
Right now you can do several things:
- you can use the fact, that all messages that SfePy
outputs are printed using the output() function - it's
not just a function but an instance of the Output class
(see sfepy/base/base.py), and as such can be
controlled:
So after adding:
� from sfepy.base.base import output
� output.set_output(filename='output_log.txt')
to the beginning of your main() function, all the
output is redirected into the specified file. At the
same time, messages you print using 'print' are still
printed.
- Note that you could use an Output instance to log
your messages too:
from sfepy.base.base import Output
my_output = Output('strainer:', filename='my_log.txt',
combined=True)
my_output('hello!')
I have modified your script in this way, see [2].
- the above method can be used together with using
simple.py - you get the standard, and your custom
outputs well-split.
Just put:
from sfepy.base.base import output, Output
my_output = Output('strainer:', filename='my_log.txt',
combined=True)
output.set_output(filename='output_log.txt')
at the top of the file, and run it with simple.py
The example at [2] already has this - it can be run as
both standalone and via simple.py...
- the deprecation warnings coming from numpy/scipy can
be suppressed by:
import warnings
warnings.filterwarnings("ignore")
(also done at [2])
- the Log class in sfepy.base.log can be used to plot
and log data, see
examples/standalone/live_plot/live_plot.py
As I think of it now, it seems that the issue 16 can be
tackled by documenting the above features :)
Does it help?
r.
PS: I used the old cylgeo.vtk mesh, as I do not have
the new one, so you have to fix the paths and region
definitions in the paste [2].
[2] http://paste.pocoo.org/show/323128/
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert
Using simple.py is generating too much
output. To have better control
over this I decided to convert to a
standalone app as shown at [1] using
one of the sfepy examples as reference.
Something is not working as the
forces at each time step are zero. Can you
please have a look.
Thanks �
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit
<freev...@gmail.com>
wrote:
� � �Robert - I had a good meeting with
Yannis this afternoon. He
� � �is concerned that the strain condition
in the specimen after
� � �each time step as currently coded is
not stable and suggested
� � �that a few iterations be run at each
displacement interval to
� � �ensure that the element moduli
converge before moving onto
� � �the next time step or displacement
interval. To test his idea
� � �I ran a few iterations at a constant
displacement and found
� � �that the forces do fluctuate quite a
bit but appear to
� � �converge (somewhat) after about 10
iterations. I presume the
� � �moduli of the elements would also
stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert
Cimrman
<cimr...@ntc.zcu.cz> wrote:
� � �On Tue, 18 Jan 2011, Andre Smit wrote:
� � �Robert
� � �I've revised the code loops as shown
in [1].
� � �Seems to work. Yes, I still
� � �find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter
and readable now).
As a matter of fact, the functions in
sfepy.mechanics.matcoefs could be easily
vectorized as well,
and subsequently your glame() - it's
another EasyToFix issue
topic (new issue 150).
� � �I'm looking at the hyperelastic option
now. I've
� � �also asked Yannis
� � �Tassoulas to consider joining as a
co-author. He
� � �may have some ideas
� � �regarding plasticity options.
OK. Plasticity would come handy - I still
have not got to
implementing it (first, I would have to
study it :]).
r.
� � �[1]
http://paste.pocoo.org/show/322755/
� � �On Tue, Jan 18, 2011 at 8:14 AM, Andre
Smit
� � �<freev...@gmail.com>
� � �wrote:
� � �� � �Thanks Robert!
� � �� � �I'm working on the revisions and
updates and
� � �will get back.
� � �� � �The abstract is due at the end of
January
� � �but I hope to get
� � �� � �the bulk of the paper done by
then as well,
� � �which is due in
� � �� � �Feb sometime i.e. if abstract is
accepted.
� � �On Mon, Jan 17, 2011 at 7:13 AM,
Robert Cimrman
� � �<cimr...@ntc.zcu.cz> wrote:
� � �� � �At [1] I have posted the code
with "correct"
� � �avgqp()
� � �� � �function. Yours was ok, as long
as all the
� � �quadrature
� � �� � �point weights were the same.
� � �� � �The new implementation defines an
auxiliary
� � �material
� � �� � �with the quadrature point data,
and calls
� � �the
� � �� � �de_volume_average_mat term. Note
that the
� � �order of the
� � �� � �quadrature has to be the same as
the one
� � �used for
� � �� � �evaluating the strain.
� � �� � �Then it seems to me, that you
could avoid
� � �all those
� � �� � �loops in
� � �� � �functions Ft(), Fc(), Ec(), by
using numpy
� � �vectorized
� � �� � �operations, i.e. numpy.exp()
instead of
� � �math.exp().
� � �� � �Also the failure loops (around
line 193)
� � �could be IMHO
� � �� � �vectorized using numpy.where()
and fancy
� � �indexing.
� � �� � �Try it as a NumPy excercise :) -
you get big
� � �speed gain
� � �� � �by this, and also the code would
be shorter
� � �and more
� � �� � �readable. I can give you a hand
if you get
� � �stuck, of
� � �� � �course.
� � �� � �cheers,
� � �� � �r.
� � �� � �[1]
http://paste.pocoo.org/show/322183/
� � �On Mon, 17 Jan 2011, Robert Cimrman
wrote:
� � �� � �Hi Andre,
� � �� � �(sorry for the delayed response -
I'm
� � �� � �accommodating in Fribourg again,
and have
� � �not yet
� � �� � �wifi at home...)
� � �� � �On Fri, 14 Jan 2011, Andre Smit
wrote:
� � �� � � � � �Robert
� � �� � � � � �I think I have
something to
share.
� � �� � � � � �How would you feel
about
co-authoring
� � �� � � � � �a paper to this
conference
- mainly
� � �� � � � � �to further expose
SfePy but
also to
� � �� � � � � �check that I'm not
applying
it
� � �� � � � � �incorrectly?
� � �� � �That would be great, thanks for
proposing
� � �it!
� � �� � � � � �Using the strain
rate
dependency
� � �� � � � � �example you provided
I
recoded an
� � �� � � � � �example looking at
the
failure of a
� � �� � � � � �cylindrical specimen
under
� � �� � � � � �compression. The
cylinder
is made up
� � �� � � � � �of elements that I
treat
� � �� � � � � �individually or
discretely,
checking
� � �� � � � � �the strain rates in
each
and using a
� � �� � � � � �relationship
established in
the lab,
� � �� � � � � �I calculate the
compressive
� � �� � � � � �strengths in the
elements
based on
� � �� � � � � �these strain rates.
If the
stress in
� � �� � � � � �an element exceeds
its
strength then
� � �� � � � � �the element fails and
I
assign a low
� � �� � � � � �stiffness to that
element.
The code
� � �� � � � � �I'm using is
available
here:
� � �� � � � �
�http://paste.pocoo.org/show/320646/
� � �� � �I will look at the code and try
it ASAP.
� � �What is
� � �� � �the deadline, anyway?
� � �� � �A few notes straight from my head
follow.
� � �� � �What happens with the linear
elastic
� � �assumption
� � �� � �when you reduce stiffness in some
elements?
� � �The
� � �� � �code has some hyperelastic terms,
in case
� � �they
� � �� � �would be needed.
� � �� � � � � �Would you mind
looking and
commenting
� � �� � � � � �on this code. I'm a
bit
skeptical
� � �� � � � � �about the avgqp
function
which
� � �� � � � � �averages the strains
at the
quad
� � �� � � � � �points.
� � �� � � � � �Note that I use a
normal
distribution
� � �� � � � � �to vary the moduli of
the
elements
� � �� � � � � �initially. �
� � �� � �To get averaged element values of
something
� � �� � �defined in quadrature points, one
can use
� � �either
� � �� � �directly de_volume_average_mat
term (a fake
� � �� � �material definition would then be
needed, I
� � �can
� � �� � �show you), or use directly
similar code to
� � �the
� � �� � �one in the body of that term.
� � �� � ��
� � �� � � � � �I've attached the
mesh:
cylgeo.vtk.
� � �� � � � � �What I aim to do with
the
paper is
� � �� � � � � �demonstrate the
influence
of specimen
� � �� � � � � �geometry on strength.
For
simple
� � �� � � � � �compression and
tension
tests (on
� � �� � � � � �cylinders) this is
trivial
but with
� � �� � � � � �indirect tensile
tests, for
example,
� � �� � � � � �there is both
compression
and tension
� � �� � � � � �failure, and I hope
to show
using
� � �� � � � � �FEM that the
strengths of
materials
� � �� � � � � �determined using
these
tests are
� � �� � � � � �significantly
influenced by
the
� � �� � � � � �geometry of the
specimen.�
� �
� � �� � �Interesting!
� � �� � � � � �The
force-displacement
curves
� � �� � � � � �currently generated
by the
code look
� � �� � � � � �promising. I'm not
sure the
analysis
� � �� � � � � �can be refined by
using
smaller
� � �� � � � � �elements?
� � �� � �The mesh is not very fine, yes.
Another way
� � �to
� � �� � �refine the analysis might be to
use another
� � �� � �material relation
(hyperelastic?).
� � �� � �r.
� � �� � � � � �On Fri, Jan 14, 2011
at
3:19 AM,
� � �� � � � � �Robert Cimrman
<cimr...@ntc.zcu.cz>
� � �� � � � � �wrote:
� � �� � � � � �� � �I
see :) Good luck
then!
� � �� � � � � �� �
�r.
� � �� � � � � �On Thu, 13 Jan 2011,
Andre
Smit
� � �� � � � � �wrote:
� � �� � � � � �� �
�No plans currently -
still
� � �� � � � � �working on an
analysis.
� � �� � � � � �� �
�Maybe if I can get it
� � �� � � � � �� �
�done before the end of
the month
� � �� � � � � �:)
� � �� � � � � �� �
�On Thu, Jan 13, 2011
at 2:43 AM,
� � �� � � � � �Robert Cimrman
� � �� � � � � �� �
�<cimr...@ntc.zcu.cz>
� � �� � � � � �� �
�wrote:
� � �� � � � � �� �
�� � �Hi Andre,
� � �� � � � � �� �
�� � �are you planning
to go
� � �� � � � � �there?
� � �� � � � � �� �
�� � �r.
� � �� � � � � �� �
�On Mon, 10 Jan 2011,
Andre Smit
� � �� � � � � �wrote:
� � �� � � � � �� �
�� � �FYI:
� � �� � � � � �� �
�� �
� � �� � � � � �� �
� � �� � � � �
� �
����http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � �� � � � � �� �
�� � �--
� � �� � � � � �� �
�� � �Andre
� � �� � � � � �--
� � �� � � � � �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...@googlegroups.com.
� � �� � � � � �For more options,
visit
this group at
� � �� � � � �
� �
��http://groups.google.com/group/sfepy-devel?hl=en.
� � �� � � � � �--
� � �� � � � � �Andre
� � �� � � � � �--
� � �� � � � � �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...@googlegroups.com.
� � �� � � � � �For more options,
visit
this group at
� � �� � � � �
� �
��http://groups.google.com/group/sfepy-devel?hl=en.
� � �� � �--
� � �� � �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...@googlegroups.com.
� � �� � �For more options, visit this
group at
� � �� �
� �
��http://groups.google.com/group/sfepy-devel?hl=en.
� � �--
� � �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...@googlegroups.com.
� � �For more options, visit this group at
� �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � �--
� � �Andre
� � �--
� � �Andre
� � �--
� � �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...@googlegroups.com.
� � �For more options, visit this group at
� �
�http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
Robert
See [1] to illustrate the initial instability. I've fixed the displacement and the loading time (the time steps are really just providing the loop). The output shows displacement, force. If you plot the force you see that the load appears to converge after a few steps but then becomes very variable gain.
I've also attached the new abaqus generated mesh.
[1] http://paste.pocoo.org/show/323259/
On Wed, Jan 19, 2011 at 8:04 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Oh, this output! Then you can try also putting
'output_format' : 'h5',
into the options. All results will then be saved into a single HDF5 file with many time steps.
hth, r.
On Wed, 19 Jan 2011, Andre Smit wrote:
Thanks Robert - the code works great. Regarding the output - I was really
concerned about the large number of vtk files being generated when running thru simple.py with the extra iterations applied to stabilize the force. Now as a standalone I can suppress this and the script runs faster too! I like the idea of gradually reducing modulus for stabilization.
On Wed, Jan 19, 2011 at 3:09 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: One more thing: there was a bug in the Output() class constructor arguments, so you need the latest sources for the code below.
r.
On Wed, 19 Jan 2011, Robert Cimrman wrote:
The zero forces are because you have changed the
traction() function to the form used by
material-defining functions. It should look (like in
your previous versions) as:
def traction(ts, coors, bc=None):
disp = -(ts.dt*(ts.step+1))
val = nm.empty_like(coors[:,0])
val.fill(disp)
return val
i.e. as a bc-defining function.
As for too much output printed, yes, we should address
the issue 16 one day in a systematic way. I do not know
yet, how to control the output flexibly enough yet
unobtrusively.
Right now you can do several things:
- you can use the fact, that all messages that SfePy
outputs are printed using the output() function - it's
not just a function but an instance of the Output class
(see sfepy/base/base.py), and as such can be
controlled:
So after adding:
from sfepy.base.base import output
output.set_output(filename='output_log.txt')
to the beginning of your main() function, all the
output is redirected into the specified file. At the
same time, messages you print using 'print' are still
printed.
- Note that you could use an Output instance to log
your messages too:
from sfepy.base.base import Output
my_output = Output('strainer:', filename='my_log.txt',
combined=True)
my_output('hello!')
I have modified your script in this way, see [2].
- the above method can be used together with using
simple.py - you get the standard, and your custom
outputs well-split.
Just put:
from sfepy.base.base import output, Output
my_output = Output('strainer:', filename='my_log.txt',
combined=True)
output.set_output(filename='output_log.txt')
at the top of the file, and run it with simple.py
The example at [2] already has this - it can be run as
both standalone and via simple.py...
- the deprecation warnings coming from numpy/scipy can
be suppressed by:
import warnings
warnings.filterwarnings("ignore")
(also done at [2])
- the Log class in sfepy.base.log can be used to plot
and log data, see
examples/standalone/live_plot/live_plot.py
As I think of it now, it seems that the issue 16 can be
tackled by documenting the above features :)
Does it help?
r.
PS: I used the old cylgeo.vtk mesh, as I do not have
the new one, so you have to fix the paths and region
definitions in the paste [2].
[2] http://paste.pocoo.org/show/323128/
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert
Using simple.py is generating too much
output. To have better control
over this I decided to convert to a
standalone app as shown at [1] using
one of the sfepy examples as reference.
Something is not working as the
forces at each time step are zero. Can you
please have a look.
Thanks
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit
<freev...@gmail.com>
wrote:
Robert - I had a good meeting with
Yannis this afternoon. He
is concerned that the strain condition
in the specimen after
each time step as currently coded is
not stable and suggested
that a few iterations be run at each
displacement interval to
ensure that the element moduli
converge before moving onto
the next time step or displacement
interval. To test his idea
I ran a few iterations at a constant
displacement and found
that the forces do fluctuate quite a
bit but appear to
converge (somewhat) after about 10
iterations. I presume the
moduli of the elements would also
stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert
Cimrman
<cimr...@ntc.zcu.cz> wrote:
On Tue, 18 Jan 2011, Andre Smit wrote:
Robert
I've revised the code loops as shown
in [1].
Seems to work. Yes, I still
find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter
and readable now).
As a matter of fact, the functions in
sfepy.mechanics.matcoefs could be easily
vectorized as well,
and subsequently your glame() - it's
another EasyToFix issue
topic (new issue 150).
I'm looking at the hyperelastic option
now. I've
also asked Yannis
Tassoulas to consider joining as a
co-author. He
may have some ideas
regarding plasticity options.
OK. Plasticity would come handy - I still
have not got to
implementing it (first, I would have to
study it :]).
r.
[1]
http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre
Smit
<freev...@gmail.com>
wrote:
Thanks Robert!
I'm working on the revisions and
updates and
will get back.
The abstract is due at the end of
January
but I hope to get
the bulk of the paper done by
then as well,
which is due in
Feb sometime i.e. if abstract is
accepted.
On Mon, Jan 17, 2011 at 7:13 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz> wrote:
At [1] I have posted the code
with "correct"
avgqp()
function. Yours was ok, as long
as all the
quadrature
point weights were the same.
The new implementation defines an
auxiliary
material
with the quadrature point data,
and calls
the
de_volume_average_mat term. Note
that the
order of the
quadrature has to be the same as
the one
used for
evaluating the strain.
Then it seems to me, that you
could avoid
all those
loops in
functions Ft(), Fc(), Ec(), by
using numpy
vectorized
operations, i.e. numpy.exp()
instead of
math.exp().
Also the failure loops (around
line 193)
could be IMHO
vectorized using numpy.where()
and fancy
indexing.
Try it as a NumPy excercise :) -
you get big
speed gain
by this, and also the code would
be shorter
and more
readable. I can give you a hand
if you get
stuck, of
course.
cheers,
r.
[1]
http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman
wrote:
Hi Andre,
(sorry for the delayed response -
I'm
accommodating in Fribourg again,
and have
not yet
wifi at home...)
On Fri, 14 Jan 2011, Andre Smit
wrote:
Robert
I think I have something to
share.
How would you feel about
co-authoring
a paper to this conference
- mainly
to further expose SfePy but
also to
check that I'm not applying
it
incorrectly?
That would be great, thanks for
proposing
it!
Using the strain rate
dependency
example you provided I
recoded an
example looking at the
failure of a
cylindrical specimen under
compression. The cylinder
is made up
of elements that I treat
individually or discretely,
checking
the strain rates in each
and using a
relationship established in
the lab,
I calculate the compressive
strengths in the elements
based on
these strain rates. If the
stress in
an element exceeds its
strength then
the element fails and I
assign a low
stiffness to that element.
The code
I'm using is available
here:
http://paste.pocoo.org/show/320646/
I will look at the code and try
it ASAP.
What is
the deadline, anyway?
A few notes straight from my head
follow.
What happens with the linear
elastic
assumption
when you reduce stiffness in some
elements?
The
code has some hyperelastic terms,
in case
they
would be needed.
Would you mind looking and
commenting
on this code. I'm a bit
skeptical
about the avgqp function
which
averages the strains at the
quad
points.
Note that I use a normal
distribution
to vary the moduli of the
elements
initially.
To get averaged element values of
something
defined in quadrature points, one
can use
either
directly de_volume_average_mat
term (a fake
material definition would then be
needed, I
can
show you), or use directly
similar code to
the
one in the body of that term.
I've attached the mesh:
cylgeo.vtk.
What I aim to do with the
paper is
demonstrate the influence
of specimen
geometry on strength. For
simple
compression and tension
tests (on
cylinders) this is trivial
but with
indirect tensile tests, for
example,
there is both compression
and tension
failure, and I hope to show
using
FEM that the strengths of
materials
determined using these
tests are
significantly influenced by
the
geometry of the specimen.
Interesting!
The force-displacement
curves
currently generated by the
code look
promising. I'm not sure the
analysis
can be refined by using
smaller
elements?
The mesh is not very fine, yes.
Another way
to
refine the analysis might be to
use another
material relation
(hyperelastic?).
r.
On Fri, Jan 14, 2011 at
3:19 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
I see :) Good luck
then!
r.
On Thu, 13 Jan 2011, Andre
Smit
wrote:
No plans currently -
still
working on an analysis.
Maybe if I can get it
done before the end of
the month
:)
On Thu, Jan 13, 2011
at 2:43 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning
to go
there?
r.
On Mon, 10 Jan 2011,
Andre Smit
wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert
See [1] to illustrate the initial instability. I've fixed the displacement and the loading time (the time steps are really just providing the loop). The output shows displacement, force. If you plot the force you see that the load appears to converge after a few steps but then becomes very variable gain.
Yes, I can see it.
I am not sure how it works, though: how is it possible, that the force can actually grow? I assumed that once an element fails, it's stiffness should be reduced for ever. Then the force should be lower and lower, right?
What is the meaning of 'smix' stiffness, for strain rate zero?
r.
I've also attached the new abaqus generated mesh.
[1] http://paste.pocoo.org/show/323259/
On Wed, Jan 19, 2011 at 8:04 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: Oh, this output! Then you can try also putting
'output_format' : 'h5',
into the options. All results will then be saved into a
single HDF5 file with many time steps.
hth,
r.
On Wed, 19 Jan 2011, Andre Smit wrote:
Thanks Robert - the code works great. Regarding the
output - I was really
concerned about the large number of vtk files being
generated when
running thru simple.py with the extra iterations
applied to stabilize the
force. Now as a standalone I can suppress this and the
script runs faster
too! I like the idea of gradually reducing modulus for
stabilization.
On Wed, Jan 19, 2011 at 3:09 AM, Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
� � �One more thing: there was a bug in the Output()
class
� � �constructor arguments, so you need the latest
sources for the
� � �code below.
� � �r.
On Wed, 19 Jan 2011, Robert Cimrman wrote:
� � �The zero forces are because you have changed the
� � �traction() function to the form used by
� � �material-defining functions. It should look (like
in
� � �your previous versions) as:
� � �def traction(ts, coors, bc=None):
� � �� disp = -(ts.dt*(ts.step+1))
� � �� val = nm.empty_like(coors[:,0])
� � �� val.fill(disp)
� � �� return val
� � �i.e. as a bc-defining function.
� � �As for too much output printed, yes, we should
address
� � �the issue 16 one day in a systematic way. I do not
know
� � �yet, how to control the output flexibly enough yet
� � �unobtrusively.
� � �Right now you can do several things:
� � �- you can use the fact, that all messages that
SfePy
� � �outputs are printed using the output() function -
it's
� � �not just a function but an instance of the Output
class
� � �(see sfepy/base/base.py), and as such can be
� � �controlled:
� � �So after adding:
� � �� from sfepy.base.base import output
� � �� output.set_output(filename='output_log.txt')
� � �to the beginning of your main() function, all the
� � �output is redirected into the specified file. At
the
� � �same time, messages you print using 'print' are
still
� � �printed.
� � �- Note that you could use an Output instance to
log
� � �your messages too:
� � �from sfepy.base.base import Output
� � �my_output = Output('strainer:',
filename='my_log.txt',
� � �combined=True)
� � �my_output('hello!')
� � �I have modified your script in this way, see [2].
� � �- the above method can be used together with using
� � �simple.py - you get the standard, and your custom
� � �outputs well-split.
� � �Just put:
� � �from sfepy.base.base import output, Output
� � �my_output = Output('strainer:',
filename='my_log.txt',
� � �combined=True)
� � �output.set_output(filename='output_log.txt')
� � �at the top of the file, and run it with simple.py
� � �The example at [2] already has this - it can be
run as
� � �both standalone and via simple.py...
� � �- the deprecation warnings coming from numpy/scipy
can
� � �be suppressed by:
� � �import warnings
� � �warnings.filterwarnings("ignore")
� � �(also done at [2])
� � �- the Log class in sfepy.base.log can be used to
plot
� � �and log data, see
� � �examples/standalone/live_plot/live_plot.py
� � �As I think of it now, it seems that the issue 16
can be
� � �tackled by documenting the above features :)
� � �Does it help?
� � �r.
� � �PS: I used the old cylgeo.vtk mesh, as I do not
have
� � �the new one, so you have to fix the paths and
region
� � �definitions in the paste [2].
� � �[2] http://paste.pocoo.org/show/323128/
� � �On Wed, 19 Jan 2011, Andre Smit wrote:
� � � � � �Robert
� � � � � �Using simple.py is generating too much
� � � � � �output. To have better control
� � � � � �over this I decided to convert to a
� � � � � �standalone app as shown at [1] using
� � � � � �one of the sfepy examples as reference.
� � � � � �Something is not working as the
� � � � � �forces at each time step are zero. Can you
� � � � � �please have a look.
� � � � � �Thanks �
� � � � � �[1] http://paste.pocoo.org/show/323091/
� � � � � �On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit
� � � � � �<freev...@gmail.com>
� � � � � �wrote:
� � � � � �� � �Robert - I had a good
meeting with
� � � � � �Yannis this afternoon. He
� � � � � �� � �is concerned that the
strain condition
� � � � � �in the specimen after
� � � � � �� � �each time step as currently
coded is
� � � � � �not stable and suggested
� � � � � �� � �that a few iterations be
run at each
� � � � � �displacement interval to
� � � � � �� � �ensure that the element
moduli
� � � � � �converge before moving onto
� � � � � �� � �the next time step or
displacement
� � � � � �interval. To test his idea
� � � � � �� � �I ran a few iterations at a
constant
� � � � � �displacement and found
� � � � � �� � �that the forces do
fluctuate quite a
� � � � � �bit but appear to
� � � � � �� � �converge (somewhat) after
about 10
� � � � � �iterations. I presume the
� � � � � �� � �moduli of the elements
would also
� � � � � �stabilize.
� � � � � �On Tue, Jan 18, 2011 at 10:48 AM, Robert
� � � � � �Cimrman
� � � � � �<cimr...@ntc.zcu.cz> wrote:
� � � � � �� � �On Tue, 18 Jan 2011, Andre
Smit wrote:
� � � � � �� � �Robert
� � � � � �� � �I've revised the code loops
as shown
� � � � � �in [1].
� � � � � �� � �Seems to work. Yes, I
still
� � � � � �� � �find myself thinking in
FORTRAN :(
� � � � � �You will get used to it :)
� � � � � �The code works for me (and is much shorter
� � � � � �and readable now).
� � � � � �As a matter of fact, the functions in
� � � � � �sfepy.mechanics.matcoefs could be easily
� � � � � �vectorized as well,
� � � � � �and subsequently your glame() - it's
� � � � � �another EasyToFix issue
� � � � � �topic (new issue 150).
� � � � � �� � �I'm looking at the
hyperelastic option
� � � � � �now. I've
� � � � � �� � �also asked Yannis
� � � � � �� � �Tassoulas to consider
joining as a
� � � � � �co-author. He
� � � � � �� � �may have some ideas
� � � � � �� � �regarding plasticity
options.
� � � � � �OK. Plasticity would come handy - I still
� � � � � �have not got to
� � � � � �implementing it (first, I would have to
� � � � � �study it :]).
� � � � � �r.
� � � � � �� � �[1]
� � � � � �http://paste.pocoo.org/show/322755/
� � � � � �� � �On Tue, Jan 18, 2011 at
8:14 AM, Andre
� � � � � �Smit
� � � � � �� � �<freev...@gmail.com>
� � � � � �� � �wrote:
� � � � � �� � �� � �Thanks
Robert!
� � � � � �� � �� � �I'm
working on the revisions and
� � � � � �updates and
� � � � � �� � �will get back.
� � � � � �� � �� � �The
abstract is due at the end of
� � � � � �January
� � � � � �� � �but I hope to get
� � � � � �� � �� � �the
bulk of the paper done by
� � � � � �then as well,
� � � � � �� � �which is due in
� � � � � �� � �� � �Feb
sometime i.e. if abstract is
� � � � � �accepted.
� � � � � �� � �On Mon, Jan 17, 2011 at
7:13 AM,
� � � � � �Robert Cimrman
� � � � � �� � �<cimr...@ntc.zcu.cz>
wrote:
� � � � � �� � �� � �At [1]
I have posted the code
� � � � � �with "correct"
� � � � � �� � �avgqp()
� � � � � �� � �� �
�function. Yours was ok, as long
� � � � � �as all the
� � � � � �� � �quadrature
� � � � � �� � �� � �point
weights were the same.
� � � � � �� � �� � �The new
implementation defines an
� � � � � �auxiliary
� � � � � �� � �material
� � � � � �� � �� � �with
the quadrature point data,
� � � � � �and calls
� � � � � �� � �the
� � � � � �� � �� �
�de_volume_average_mat term. Note
� � � � � �that the
� � � � � �� � �order of the
� � � � � �� � �� �
�quadrature has to be the same as
� � � � � �the one
� � � � � �� � �used for
� � � � � �� � �� �
�evaluating the strain.
� � � � � �� � �� � �Then it
seems to me, that you
� � � � � �could avoid
� � � � � �� � �all those
� � � � � �� � �� � �loops
in
� � � � � �� � �� �
�functions Ft(), Fc(), Ec(), by
� � � � � �using numpy
� � � � � �� � �vectorized
� � � � � �� � �� �
�operations, i.e. numpy.exp()
� � � � � �instead of
� � � � � �� � �math.exp().
� � � � � �� � �� � �Also
the failure loops (around
� � � � � �line 193)
� � � � � �� � �could be IMHO
� � � � � �� � �� �
�vectorized using numpy.where()
� � � � � �and fancy
� � � � � �� � �indexing.
� � � � � �� � �� � �Try it
as a NumPy excercise :) -
� � � � � �you get big
� � � � � �� � �speed gain
� � � � � �� � �� � �by
this, and also the code would
� � � � � �be shorter
� � � � � �� � �and more
� � � � � �� � �� �
�readable. I can give you a hand
� � � � � �if you get
� � � � � �� � �stuck, of
� � � � � �� � �� �
�course.
� � � � � �� � �� �
�cheers,
� � � � � �� � �� � �r.
� � � � � �� � �� � �[1]
� � � � � �http://paste.pocoo.org/show/322183/
� � � � � �� � �On Mon, 17 Jan 2011, Robert
Cimrman
� � � � � �wrote:
� � � � � �� � �� � �Hi
Andre,
� � � � � �� � �� � �(sorry
for the delayed response -
� � � � � �I'm
� � � � � �� � �� �
�accommodating in Fribourg again,
� � � � � �and have
� � � � � �� � �not yet
� � � � � �� � �� � �wifi at
home...)
� � � � � �� � �� � �On Fri,
14 Jan 2011, Andre Smit
� � � � � �wrote:
� � � � � �� � �� � � �
� �Robert
� � � � � �� � �� � � �
� �I think I have something to
� � � � � �share.
� � � � � �� � �� � � �
� �How would you feel about
� � � � � �co-authoring
� � � � � �� � �� � � �
� �a paper to this conference
� � � � � �- mainly
� � � � � �� � �� � � �
� �to further expose SfePy but
� � � � � �also to
� � � � � �� � �� � � �
� �check that I'm not applying
� � � � � �it
� � � � � �� � �� � � �
� �incorrectly?
� � � � � �� � �� � �That
would be great, thanks for
� � � � � �proposing
� � � � � �� � �it!
� � � � � �� � �� � � �
� �Using the strain rate
� � � � � �dependency
� � � � � �� � �� � � �
� �example you provided I
� � � � � �recoded an
� � � � � �� � �� � � �
� �example looking at the
� � � � � �failure of a
� � � � � �� � �� � � �
� �cylindrical specimen under
� � � � � �� � �� � � �
� �compression. The cylinder
� � � � � �is made up
� � � � � �� � �� � � �
� �of elements that I treat
� � � � � �� � �� � � �
� �individually or discretely,
� � � � � �checking
� � � � � �� � �� � � �
� �the strain rates in each
� � � � � �and using a
� � � � � �� � �� � � �
� �relationship established in
� � � � � �the lab,
� � � � � �� � �� � � �
� �I calculate the compressive
� � � � � �� � �� � � �
� �strengths in the elements
� � � � � �based on
� � � � � �� � �� � � �
� �these strain rates. If the
� � � � � �stress in
� � � � � �� � �� � � �
� �an element exceeds its
� � � � � �strength then
� � � � � �� � �� � � �
� �the element fails and I
� � � � � �assign a low
� � � � � �� � �� � � �
� �stiffness to that element.
� � � � � �The code
� � � � � �� � �� � � �
� �I'm using is available
� � � � � �here:
� � � � � �� � �� � � �
�
� � � � � ��http://paste.pocoo.org/show/320646/
� � � � � �� � �� � �I will
look at the code and try
� � � � � �it ASAP.
� � � � � �� � �What is
� � � � � �� � �� � �the
deadline, anyway?
� � � � � �� � �� � �A few
notes straight from my head
� � � � � �follow.
� � � � � �� � �� � �What
happens with the linear
� � � � � �elastic
� � � � � �� � �assumption
� � � � � �� � �� � �when
you reduce stiffness in some
� � � � � �elements?
� � � � � �� � �The
� � � � � �� � �� � �code
has some hyperelastic terms,
� � � � � �in case
� � � � � �� � �they
� � � � � �� � �� � �would
be needed.
� � � � � �� � �� � � �
� �Would you mind looking and
� � � � � �commenting
� � � � � �� � �� � � �
� �on this code. I'm a bit
� � � � � �skeptical
� � � � � �� � �� � � �
� �about the avgqp function
� � � � � �which
� � � � � �� � �� � � �
� �averages the strains at the
� � � � � �quad
� � � � � �� � �� � � �
� �points.
� � � � � �� � �� � � �
� �Note that I use a normal
� � � � � �distribution
� � � � � �� � �� � � �
� �to vary the moduli of the
� � � � � �elements
� � � � � �� � �� � � �
� �initially. �
� � � � � �� � �� � �To get
averaged element values of
� � � � � �something
� � � � � �� � �� � �defined
in quadrature points, one
� � � � � �can use
� � � � � �� � �either
� � � � � �� � �� �
�directly de_volume_average_mat
� � � � � �term (a fake
� � � � � �� � �� �
�material definition would then be
� � � � � �needed, I
� � � � � �� � �can
� � � � � �� � �� � �show
you), or use directly
� � � � � �similar code to
� � � � � �� � �the
� � � � � �� � �� � �one in
the body of that term.
� � � � � �� � �� � ��
� � � � � �� � �� � � �
� �I've attached the mesh:
� � � � � �cylgeo.vtk.
� � � � � �� � �� � � �
� �What I aim to do with the
� � � � � �paper is
� � � � � �� � �� � � �
� �demonstrate the influence
� � � � � �of specimen
� � � � � �� � �� � � �
� �geometry on strength. For
� � � � � �simple
� � � � � �� � �� � � �
� �compression and tension
� � � � � �tests (on
� � � � � �� � �� � � �
� �cylinders) this is trivial
� � � � � �but with
� � � � � �� � �� � � �
� �indirect tensile tests, for
� � � � � �example,
� � � � � �� � �� � � �
� �there is both compression
� � � � � �and tension
� � � � � �� � �� � � �
� �failure, and I hope to show
� � � � � �using
� � � � � �� � �� � � �
� �FEM that the strengths of
� � � � � �materials
� � � � � �� � �� � � �
� �determined using these
� � � � � �tests are
� � � � � �� � �� � � �
� �significantly influenced by
� � � � � �the
� � � � � �� � �� � � �
� �geometry of the specimen.�
� � � � � �� �
� � � � � �� � �� �
�Interesting!
� � � � � �� � �� � � �
� �The force-displacement
� � � � � �curves
� � � � � �� � �� � � �
� �currently generated by the
� � � � � �code look
� � � � � �� � �� � � �
� �promising. I'm not sure the
� � � � � �analysis
� � � � � �� � �� � � �
� �can be refined by using
� � � � � �smaller
� � � � � �� � �� � � �
� �elements?
� � � � � �� � �� � �The
mesh is not very fine, yes.
� � � � � �Another way
� � � � � �� � �to
� � � � � �� � �� � �refine
the analysis might be to
� � � � � �use another
� � � � � �� � �� �
�material relation
� � � � � �(hyperelastic?).
� � � � � �� � �� � �r.
� � � � � �� � �� � � �
� �On Fri, Jan 14, 2011 at
� � � � � �3:19 AM,
� � � � � �� � �� � � �
� �Robert Cimrman
� � � � � �<cimr...@ntc.zcu.cz>
� � � � � �� � �� � � �
� �wrote:
� � � � � �� � �� � � �
� �� � �I see :) Good luck
� � � � � �then!
� � � � � �� � �� � � �
� �� � �r.
� � � � � �� � �� � � �
� �On Thu, 13 Jan 2011, Andre
� � � � � �Smit
� � � � � �� � �� � � �
� �wrote:
� � � � � �� � �� � � �
� �� � �No plans currently -
� � � � � �still
� � � � � �� � �� � � �
� �working on an analysis.
� � � � � �� � �� � � �
� �� � �Maybe if I can get it
� � � � � �� � �� � � �
� �� � �done before the end of
� � � � � �the month
� � � � � �� � �� � � �
� �:)
� � � � � �� � �� � � �
� �� � �On Thu, Jan 13, 2011
� � � � � �at 2:43 AM,
� � � � � �� � �� � � �
� �Robert Cimrman
� � � � � �� � �� � � �
� �� � �<cimr...@ntc.zcu.cz>
� � � � � �� � �� � � �
� �� � �wrote:
� � � � � �� � �� � � �
� �� � �� � �Hi Andre,
� � � � � �� � �� � � �
� �� � �� � �are you planning
� � � � � �to go
� � � � � �� � �� � � �
� �there?
� � � � � �� � �� � � �
� �� � �� � �r.
� � � � � �� � �� � � �
� �� � �On Mon, 10 Jan 2011,
� � � � � �Andre Smit
� � � � � �� � �� � � �
� �wrote:
� � � � � �� � �� � � �
� �� � �� � �FYI:
� � � � � �� � �� � � �
� �� � �� �
� � � � � �� � �� � � �
� �� �
� � � � � �� � �� � � �
�
� � � � � �� �
� � � � �
�����http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � � � � �� � �� � � �
� �� � �� � �--
� � � � � �� � �� � � �
� �� � �� � �Andre
� � � � � �� � �� � � �
� �--
� � � � � �� � �� � � �
� �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...@googlegroups.com.
� � � � � �� � �� � � �
� �For more options, visit
� � � � � �this group at
� � � � � �� � �� � � �
�
� � � � � �� �
� � � � �
���http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �� � �� � � �
� �--
� � � � � �� � �� � � �
� �Andre
� � � � � �� � �� � � �
� �--
� � � � � �� � �� � � �
� �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...@googlegroups.com.
� � � � � �� � �� � � �
� �For more options, visit
� � � � � �this group at
� � � � � �� � �� � � �
�
� � � � � �� �
� � � � �
���http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �� � �� � �--
� � � � � �� � �� � �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...@googlegroups.com.
� � � � � �� � �� � �For
more options, visit this
� � � � � �group at
� � � � � �� � �� �
� � � � � �� �
� � � � �
���http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �� � �--
� � � � � �� � �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...@googlegroups.com.
� � � � � �� � �For more options, visit
this group at
� � � � � �� �
� � � � �
��http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �� � �--
� � � � � �� � �Andre
� � � � � �� � �--
� � � � � �� � �Andre
� � � � � �� � �--
� � � � � �� � �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...@googlegroups.com.
� � � � � �� � �For more options, visit
this group at
� � � � � �� �
� � � � �
��http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �--
� � � � � �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...@googlegroups.com.
� � � � � �For more options, visit this group at
� � � � �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � � � � �--
� � � � � �Andre
� � � � � �--
� � � � � �Andre
� � � � � �--
� � � � � �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...@googlegroups.com.
� � � � � �For more options, visit this group at
� � � � �
�http://groups.google.com/group/sfepy-devel?hl=en.
� � �--
� � �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...@googlegroups.com.
� � �For more options, visit this group at
� � �http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
Robert - I'm trying to change the displacement (disp) in the traction function when the force stabilizes but for some reason the scope of disp within traction() appears different to that within calc_force(), even though disp is defined as global. Any ideas?
old_force = 0 def calc_force(pb, ts, state): global disp,old_force d = state() pb.remove_bcs() f = pb.evaluator.eval_residual(d) pb.time_update() f.shape = (pb.domain.mesh.n_nod, 3) p = [] for n in pb.domain.regions['Top'].vertices[0]: p.append(f[n][2]) p = nm.array(p) if abs(old_force-p.sum()) < fvar: my_output(disp,",",p.sum()) disp -= ddisp old_force=p.sum()
def traction(ts, coors, bc=None): global disp
#disp = -(ts.dt*(ts.step+1))
print "traction disp: ", disp
val = nm.empty_like(coors[:,0])
val.fill(disp)
return val
What is the meaning of 'smix' stiffness, for strain rate zero? >
I'm not sure.
On Wed, Jan 19, 2011 at 8:59 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert >
See [1] to illustrate the initial instability. I've fixed the displacement and the loading time (the time steps are really just providing the loop). The output shows displacement, force. If you plot the force you see that the load appears to converge after a few steps but then becomes very variable gain.
Yes, I can see it.
I am not sure how it works, though: how is it possible, that the force can actually grow? I assumed that once an element fails, it's stiffness should be reduced for ever. Then the force should be lower and lower, right?
What is the meaning of 'smix' stiffness, for strain rate zero?
r.
I've also attached the new abaqus generated mesh. >
[1] http://paste.pocoo.org/show/323259/
On Wed, Jan 19, 2011 at 8:04 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: Oh, this output! Then you can try also putting
'output_format' : 'h5',
into the options. All results will then be saved into a
single HDF5 file with many time steps.
hth,
r.
On Wed, 19 Jan 2011, Andre Smit wrote:
Thanks Robert - the code works great. Regarding the
output - I was really
concerned about the large number of vtk files being
generated when
running thru simple.py with the extra iterations
applied to stabilize the
force. Now as a standalone I can suppress this and the
script runs faster
too! I like the idea of gradually reducing modulus for
stabilization.
On Wed, Jan 19, 2011 at 3:09 AM, Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
One more thing: there was a bug in the Output()
class
constructor arguments, so you need the latest
sources for the
code below.
r.
On Wed, 19 Jan 2011, Robert Cimrman wrote:
The zero forces are because you have changed the
traction() function to the form used by
material-defining functions. It should look (like
in
your previous versions) as:
def traction(ts, coors, bc=None):
disp = -(ts.dt*(ts.step+1))
val = nm.empty_like(coors[:,0])
val.fill(disp)
return val
i.e. as a bc-defining function.
As for too much output printed, yes, we should
address
the issue 16 one day in a systematic way. I do not
know
yet, how to control the output flexibly enough yet
unobtrusively.
Right now you can do several things:
- you can use the fact, that all messages that
SfePy
outputs are printed using the output() function -
it's
not just a function but an instance of the Output
class
(see sfepy/base/base.py), and as such can be
controlled:
So after adding:
from sfepy.base.base import output
output.set_output(filename='output_log.txt')
to the beginning of your main() function, all the
output is redirected into the specified file. At
the
same time, messages you print using 'print' are
still
printed.
- Note that you could use an Output instance to
log
your messages too:
from sfepy.base.base import Output
my_output = Output('strainer:',
filename='my_log.txt',
combined=True)
my_output('hello!')
I have modified your script in this way, see [2].
- the above method can be used together with using
simple.py - you get the standard, and your custom
outputs well-split.
Just put:
from sfepy.base.base import output, Output
my_output = Output('strainer:',
filename='my_log.txt',
combined=True)
output.set_output(filename='output_log.txt')
at the top of the file, and run it with simple.py
The example at [2] already has this - it can be
run as
both standalone and via simple.py...
- the deprecation warnings coming from numpy/scipy
can
be suppressed by:
import warnings
warnings.filterwarnings("ignore")
(also done at [2])
- the Log class in sfepy.base.log can be used to
plot
and log data, see
examples/standalone/live_plot/live_plot.py
As I think of it now, it seems that the issue 16
can be
tackled by documenting the above features :)
Does it help?
r.
PS: I used the old cylgeo.vtk mesh, as I do not
have
the new one, so you have to fix the paths and
region
definitions in the paste [2].
[2] http://paste.pocoo.org/show/323128/
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert
Using simple.py is generating too much
output. To have better control
over this I decided to convert to a
standalone app as shown at [1] using
one of the sfepy examples as reference.
Something is not working as the
forces at each time step are zero. Can you
please have a look.
Thanks
[1] http://paste.pocoo.org/show/323091/
On Tue, Jan 18, 2011 at 3:42 PM, Andre Smit
<freev...@gmail.com>
wrote:
Robert - I had a good meeting with
Yannis this afternoon. He
is concerned that the strain condition
in the specimen after
each time step as currently coded is
not stable and suggested
that a few iterations be run at each
displacement interval to
ensure that the element moduli
converge before moving onto
the next time step or displacement
interval. To test his idea
I ran a few iterations at a constant
displacement and found
that the forces do fluctuate quite a
bit but appear to
converge (somewhat) after about 10
iterations. I presume the
moduli of the elements would also
stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert
Cimrman
<cimr...@ntc.zcu.cz> wrote:
On Tue, 18 Jan 2011, Andre Smit wrote:
Robert
I've revised the code loops as shown
in [1].
Seems to work. Yes, I still
find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter
and readable now).
As a matter of fact, the functions in
sfepy.mechanics.matcoefs could be easily
vectorized as well,
and subsequently your glame() - it's
another EasyToFix issue
topic (new issue 150).
I'm looking at the hyperelastic option
now. I've
also asked Yannis
Tassoulas to consider joining as a
co-author. He
may have some ideas
regarding plasticity options.
OK. Plasticity would come handy - I still
have not got to
implementing it (first, I would have to
study it :]).
r.
[1]
http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre
Smit
<freev...@gmail.com>
wrote:
Thanks Robert!
I'm working on the revisions and
updates and
will get back.
The abstract is due at the end of
January
but I hope to get
the bulk of the paper done by
then as well,
which is due in
Feb sometime i.e. if abstract is
accepted.
On Mon, Jan 17, 2011 at 7:13 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz> wrote:
At [1] I have posted the code
with "correct"
avgqp()
function. Yours was ok, as long
as all the
quadrature
point weights were the same.
The new implementation defines an
auxiliary
material
with the quadrature point data,
and calls
the
de_volume_average_mat term. Note
that the
order of the
quadrature has to be the same as
the one
used for
evaluating the strain.
Then it seems to me, that you
could avoid
all those
loops in
functions Ft(), Fc(), Ec(), by
using numpy
vectorized
operations, i.e. numpy.exp()
instead of
math.exp().
Also the failure loops (around
line 193)
could be IMHO
vectorized using numpy.where()
and fancy
indexing.
Try it as a NumPy excercise :) -
you get big
speed gain
by this, and also the code would
be shorter
and more
readable. I can give you a hand
if you get
stuck, of
course.
cheers,
r.
[1]
http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman
wrote:
Hi Andre,
(sorry for the delayed response -
I'm
accommodating in Fribourg again,
and have
not yet
wifi at home...)
On Fri, 14 Jan 2011, Andre Smit
wrote:
Robert
I think I have something to
share.
How would you feel about
co-authoring
a paper to this conference
- mainly
to further expose SfePy but
also to
check that I'm not applying
it
incorrectly?
That would be great, thanks for
proposing
it!
Using the strain rate
dependency
example you provided I
recoded an
example looking at the
failure of a
cylindrical specimen under
compression. The cylinder
is made up
of elements that I treat
individually or discretely,
checking
the strain rates in each
and using a
relationship established in
the lab,
I calculate the compressive
strengths in the elements
based on
these strain rates. If the
stress in
an element exceeds its
strength then
the element fails and I
assign a low
stiffness to that element.
The code
I'm using is available
here:
http://paste.pocoo.org/show/320646/
I will look at the code and try
it ASAP.
What is
the deadline, anyway?
A few notes straight from my head
follow.
What happens with the linear
elastic
assumption
when you reduce stiffness in some
elements?
The
code has some hyperelastic terms,
in case
they
would be needed.
Would you mind looking and
commenting
on this code. I'm a bit
skeptical
about the avgqp function
which
averages the strains at the
quad
points.
Note that I use a normal
distribution
to vary the moduli of the
elements
initially.
To get averaged element values of
something
defined in quadrature points, one
can use
either
directly de_volume_average_mat
term (a fake
material definition would then be
needed, I
can
show you), or use directly
similar code to
the
one in the body of that term.
I've attached the mesh:
cylgeo.vtk.
What I aim to do with the
paper is
demonstrate the influence
of specimen
geometry on strength. For
simple
compression and tension
tests (on
cylinders) this is trivial
but with
indirect tensile tests, for
example,
there is both compression
and tension
failure, and I hope to show
using
FEM that the strengths of
materials
determined using these
tests are
significantly influenced by
the
geometry of the specimen.
Interesting!
The force-displacement
curves
currently generated by the
code look
promising. I'm not sure the
analysis
can be refined by using
smaller
elements?
The mesh is not very fine, yes.
Another way
to
refine the analysis might be to
use another
material relation
(hyperelastic?).
r.
On Fri, Jan 14, 2011 at
3:19 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
I see :) Good luck
then!
r.
On Thu, 13 Jan 2011, Andre
Smit
wrote:
No plans currently -
still
working on an analysis.
Maybe if I can get it
done before the end of
the month
:)
On Thu, Jan 13, 2011
at 2:43 AM,
Robert Cimrman
<cimr...@ntc.zcu.cz>
wrote:
Hi Andre,
are you planning
to go
there?
r.
On Mon, 10 Jan 2011,
Andre Smit
wrote:
FYI:
http://congress.cimne.com/CFRAC2011/frontal/default.asp
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
--
Andre
--
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...@googlegroups.com<sfepy-devel%...@googlegroups.com>
. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- 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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert - I'm trying to change the displacement (disp) in the traction function when the force stabilizes but for some reason the scope of disp within traction() appears different to that within calc_force(), even though disp is defined as global. Any ideas?
old_force = 0 def calc_force(pb, ts, state): ��� global disp,old_force ��� d = state() ��� pb.remove_bcs() ��� f = pb.evaluator.eval_residual(d) ��� pb.time_update() ��� f.shape = (pb.domain.mesh.n_nod, 3) ��� p = [] ��� for n in pb.domain.regions['Top'].vertices[0]: ������� p.append(f[n][2]) ��� p = nm.array(p) ��� if abs(old_force-p.sum()) < fvar: ������� my_output(disp,",",p.sum()) ������� disp -= ddisp ��� old_force=p.sum()
def traction(ts, coors, bc=None): ��� global disp ��� #disp = -(ts.dt*(ts.step+1)) ��� print "traction disp: ", disp ��� val = nm.empty_like(coors[:,0]) ��� val.fill(disp) ��� return val
I would use brute force:
globals()['disp'] = ...
You cannot really change value of a global that is immutable (IMHO)... A common idiom is to use list instead, like:
disp = [0]
def traction(ts, coors, bc=None): disp[0] = ...
What is the meaning of 'smix' stiffness,
for strain rate
zero?
I'm not sure.
That might be the problem causing the oscillations...
r.
Robert
I believe I've sorted out the oscillation problem, which was a bug in the code. I've pasted the latest version at [1] that now converges tightly after 3 or 4 iterations. I have a few comments.
As you will see:
a) I'm runnng the solver repeatedly with increasing displacements. This was mainly because I'm unable to change the displacement variable (disp) in traction() outside of the function. Globals and lists didn't work for me here. b) To overcome this obstacle, the displacement for each solver/displacement cycle is saved to file and read from disk in traction(). c) I iterate the problem until the force converges and then increment the displacement. d) The element stiffness matrix (Ele) is saved to file and loaded at the start of the subsequent displacement interval.
Comments: 1) I considered adding a variable to ts, say ts.disp and adding the displacement to that, making it available in traction. I'm sure there is a better way though. 2) I also cannot terminate the ts loop and am forced to run through all ts.n_steps. This is a problem since the forces converge at different number of steps at which point I would like the loop to end.
[1] http://paste.pocoo.org/show/324169/
Andre
On Wed, Jan 19, 2011 at 10:22 AM, Robert Cimrman cimr...@ntc.zcu.czwrote:
On Wed, 19 Jan 2011, Andre Smit wrote:
Robert - I'm trying to change the displacement (disp) in the traction
function when the force stabilizes but for some reason the scope of disp within traction() appears different to that within calc_force(), even though disp is defined as global. Any ideas?
old_force = 0 def calc_force(pb, ts, state): global disp,old_force d = state() pb.remove_bcs() f = pb.evaluator.eval_residual(d) pb.time_update() f.shape = (pb.domain.mesh.n_nod, 3) p = [] for n in pb.domain.regions['Top'].vertices[0]: p.append(f[n][2]) p = nm.array(p) if abs(old_force-p.sum()) < fvar: my_output(disp,",",p.sum()) disp -= ddisp old_force=p.sum()
def traction(ts, coors, bc=None): global disp
#disp = -(ts.dt*(ts.step+1))
print "traction disp: ", disp
val = nm.empty_like(coors[:,0])
val.fill(disp)
return val
I would use brute force:
globals()['disp'] = ...
You cannot really change value of a global that is immutable (IMHO)... A common idiom is to use list instead, like:
disp = [0]
def traction(ts, coors, bc=None): disp[0] = ...
What is the meaning of 'smix' stiffness, for strain rate
zero?
I'm not sure.
That might be the problem causing the oscillations...
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...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- Andre
That seems reasonable, yes. I can think of another way of stabilizing the convergence in those sub-iterations: what about decreasing the stiffness in the marked elements not at once to the lowest value, but in more gradual steps? Just an idea, I am no expert in this.
r.
On Tue, 18 Jan 2011, Andre Smit wrote:
Robert - I had a good meeting with Yannis this afternoon. He is concerned that the strain condition in the specimen after each time step as currently coded is not stable and suggested that a few iterations be run at each displacement interval to ensure that the element moduli converge before moving onto the next time step or displacement interval. To test his idea I ran a few iterations at a constant displacement and found that the forces do fluctuate quite a bit but appear to converge (somewhat) after about 10 iterations. I presume the moduli of the elements would also stabilize.
On Tue, Jan 18, 2011 at 10:48 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: On Tue, 18 Jan 2011, Andre Smit wrote: Robert
I've revised the code loops as shown in [1]. Seems to
work. Yes, I still
find myself thinking in FORTRAN :(
You will get used to it :)
The code works for me (and is much shorter and readable now).
As a matter of fact, the functions in sfepy.mechanics.matcoefs could be easily vectorized as well, and subsequently your glame() - it's another EasyToFix issue topic (new issue 150).
I'm looking at the hyperelastic option now. I've also
asked Yannis
Tassoulas to consider joining as a co-author. He may
have some ideas
regarding plasticity options.
OK. Plasticity would come handy - I still have not got to implementing it (first, I would have to study it :]).
r.
[1] http://paste.pocoo.org/show/322755/
On Tue, Jan 18, 2011 at 8:14 AM, Andre Smit
<freev...@gmail.com>
wrote:
� � �Thanks Robert!
� � �I'm working on the revisions and updates and will
get back.
� � �The abstract is due at the end of January but I
hope to get
� � �the bulk of the paper done by then as well, which
is due in
� � �Feb sometime i.e. if abstract is accepted.
On Mon, Jan 17, 2011 at 7:13 AM, Robert Cimrman
<cimr...@ntc.zcu.cz> wrote:
� � �At [1] I have posted the code with "correct"
avgqp()
� � �function. Yours was ok, as long as all the
quadrature
� � �point weights were the same.
� � �The new implementation defines an auxiliary
material
� � �with the quadrature point data, and calls the
� � �de_volume_average_mat term. Note that the order of
the
� � �quadrature has to be the same as the one used for
� � �evaluating the strain.
� � �Then it seems to me, that you could avoid all
those
� � �loops in
� � �functions Ft(), Fc(), Ec(), by using numpy
vectorized
� � �operations, i.e. numpy.exp() instead of
math.exp().
� � �Also the failure loops (around line 193) could be
IMHO
� � �vectorized using numpy.where() and fancy indexing.
� � �Try it as a NumPy excercise :) - you get big speed
gain
� � �by this, and also the code would be shorter and
more
� � �readable. I can give you a hand if you get stuck,
of
� � �course.
� � �cheers,
� � �r.
� � �[1] http://paste.pocoo.org/show/322183/
On Mon, 17 Jan 2011, Robert Cimrman wrote:
� � �Hi Andre,
� � �(sorry for the delayed response - I'm
� � �accommodating in Fribourg again, and have not yet
� � �wifi at home...)
� � �On Fri, 14 Jan 2011, Andre Smit wrote:
� � � � � �Robert
� � � � � �I think I have something to share.
� � � � � �How would you feel about co-authoring
� � � � � �a paper to this conference - mainly
� � � � � �to further expose SfePy but also to
� � � � � �check that I'm not applying it
� � � � � �incorrectly?
� � �That would be great, thanks for proposing it!
� � � � � �Using the strain rate dependency
� � � � � �example you provided I recoded an
� � � � � �example looking at the failure of a
� � � � � �cylindrical specimen under
� � � � � �compression. The cylinder is made up
� � � � � �of elements that I treat
� � � � � �individually or discretely, checking
� � � � � �the strain rates in each and using a
� � � � � �relationship established in the lab,
� � � � � �I calculate the compressive
� � � � � �strengths in the elements based on
� � � � � �these strain rates. If the stress in
� � � � � �an element exceeds its strength then
� � � � � �the element fails and I assign a low
� � � � � �stiffness to that element. The code
� � � � � �I'm using is available here:
� � � � � �http://paste.pocoo.org/show/320646/
� � �I will look at the code and try it ASAP. What is
� � �the deadline, anyway?
� � �A few notes straight from my head follow.
� � �What happens with the linear elastic assumption
� � �when you reduce stiffness in some elements? The
� � �code has some hyperelastic terms, in case they
� � �would be needed.
� � � � � �Would you mind looking and commenting
� � � � � �on this code. I'm a bit skeptical
� � � � � �about the avgqp function which
� � � � � �averages the strains at the quad
� � � � � �points.
� � � � � �Note that I use a normal distribution
� � � � � �to vary the moduli of the elements
� � � � � �initially. �
� � �To get averaged element values of something
� � �defined in quadrature points, one can use either
� � �directly de_volume_average_mat term (a fake
� � �material definition would then be needed, I can
� � �show you), or use directly similar code to the
� � �one in the body of that term.
� � ��
� � � � � �I've attached the mesh: cylgeo.vtk.
� � � � � �What I aim to do with the paper is
� � � � � �demonstrate the influence of specimen
� � � � � �geometry on strength. For simple
� � � � � �compression and tension tests (on
� � � � � �cylinders) this is trivial but with
� � � � � �indirect tensile tests, for example,
� � � � � �there is both compression and tension
� � � � � �failure, and I hope to show using
� � � � � �FEM that the strengths of materials
� � � � � �determined using these tests are
� � � � � �significantly influenced by the
� � � � � �geometry of the specimen.� � �
� � �Interesting!
� � � � � �The force-displacement curves
� � � � � �currently generated by the code look
� � � � � �promising. I'm not sure the analysis
� � � � � �can be refined by using smaller
� � � � � �elements?
� � �The mesh is not very fine, yes. Another way to
� � �refine the analysis might be to use another
� � �material relation (hyperelastic?).
� � �r.
� � � � � �On Fri, Jan 14, 2011 at 3:19 AM,
� � � � � �Robert Cimrman <cimr...@ntc.zcu.cz>
� � � � � �wrote:
� � � � � �� � �I see :) Good luck then!
� � � � � �� � �r.
� � � � � �On Thu, 13 Jan 2011, Andre Smit
� � � � � �wrote:
� � � � � �� � �No plans currently - still
� � � � � �working on an analysis.
� � � � � �� � �Maybe if I can get it
� � � � � �� � �done before the end of the
month
� � � � � �:)
� � � � � �� � �On Thu, Jan 13, 2011 at
2:43 AM,
� � � � � �Robert Cimrman
� � � � � �� � �<cimr...@ntc.zcu.cz>
� � � � � �� � �wrote:
� � � � � �� � �� � �Hi
Andre,
� � � � � �� � �� � �are you
planning to go
� � � � � �there?
� � � � � �� � �� � �r.
� � � � � �� � �On Mon, 10 Jan 2011, Andre
Smit
� � � � � �wrote:
� � � � � �� � �� � �FYI:
� � � � � �� � �� �
� � � � � �� �
� � � � �
���http://congress.cimne.com/CFRAC2011/frontal/default.asp
� � � � � �� � �� � �--
� � � � � �� � �� � �Andre
-
Andre Smit -
Robert Cimrman