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

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.

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.

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

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

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.

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.

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.

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.

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