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 wrote:
On Wed, 19 Jan 2011, Andre Smit wrote:

Robert

See [1] to illustrate the initial instability. I've fixed the
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

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
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:

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

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

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
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

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
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
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
point weights were the same.

The new implementation defines an
auxiliary
material
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()
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.
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
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
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
which
averages the strains at the
points.
Note that I use a normal
distribution
to vary the moduli of the
elements
initially.

To get averaged element values of
something
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

--
because you
are subscribed to the
Groups "sfepy-devel" group.
To post to this group, send
email to

To unsubscribe from this
group, send
email to

For more options, visit
this group at

--
Andre

--
because you
are subscribed to the
"sfepy-devel" group.
To post to this group, send
email to

To unsubscribe from this
group, send
email to

For more options, visit
this group at

--
you are
"sfepy-devel"
group.
To post to this group, send email
to
To unsubscribe from this group,
send email
to

For more options, visit this
group at

--
You received this message because you
are
subscribed to the
To post to this group, send email to
To unsubscribe from this group, send
email to

For more options, visit this group at

--
Andre

--
Andre

--
You received this message because you
are
"sfepy-devel" group.
To post to this group, send email to
To unsubscribe from this group, send
email to

For more options, visit this group at

--
You received this message because you are
subscribed to the
To post to this group, send email to
To unsubscribe from this group, send email
to
For more options, visit this group at

--
Andre

--
Andre

--
You received this message because you are
"sfepy-devel" group.
To post to this group, send email to
To unsubscribe from this group, send email
to
For more options, visit this group at

--
You received this message because you are
subscribed to
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

--
You received this message because you are subscribed to
Groups "sfepy-devel" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

--
Andre

--
You received this message because you are subscribed to
"sfepy-devel" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

--
Groups "sfepy-devel" group.
To post to this group, send email to sfepy...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at

--
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
For more options, visit this group at

--
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