Public bug reported:
utils.avgNumInteractions() should be adapted also for clumped particles.
The current implementation only applies to spherical particles. The same
definition should be used but the variables N, N_0 and N_1 in [1] should
consider clumps as single entities.
[1] https://yade-
Branch: refs/heads/master
Home: https://github.com/yade/trunk
Commit: 8b5c7a53a9d589eb8663ef028d5b547b392bbafa
https://github.com/yade/trunk/commit/8b5c7a53a9d589eb8663ef028d5b547b392bbafa
Author: Chiara Modenese c.moden...@gmail.com
Date: 2012-08-18 (Sat, 18 Aug 2012
On 13 Jul 2012, at 21:21, Chareyre wrote:
It is annoying to remove something when it's actually used, because all your
scripts will be broken and you'll have to change the line with particleSD
everywhere.
I agree.
OTOH, half-working functions are generating useless noise on the mailing
exist before
clearing its intrs-container.
If you are still affected by this bug, please, send a short
script, reproducing the problem
Thanks
Anton
[1]
https://github.com/yade/trunk/commit/ce52daf69cc7b0d804703a0877ec68fafae8
2012/6/15 Chiara Modenese c.moden...@gmail.com:
Hi
Hi Anton,
I am currently affected by this bug. I am using an older release (but
not too old) andI updated the code following your fix in r2880. The bug
still occurs though but I have have not rerun the test. I reload the old
test using the code I recompiled after the change, I remove the bodies I
There is no need to post a script. You can (I can, at least) reproduce
the bug just by following instructions that were given below when the
bug was open. I think it is quite essential that we fix this as removing
bodies is a common operation. Can you please try to reproduce the bug
too, Anton (or
/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
Chiara Modenese BSc MSc(Eng)
DPhil(PhD) Candidate in Engineering Science
Department of Engineering Science
University of Oxford
Parks Road, Oxford, OX1 3PJ, UK
___
Mailing list: https
Hi,
I have been using clumps for a while but never found a problem with
that. I am now using a release which is a bit older than the r3009 where
this bug seems to be fixed. I never used gravity engine too. Could you
please tell me how to reproduce the bug with a simple script?
Thank you.
On 13 December 2011 10:35, Klaus Thoeni klaus.tho...@gmail.com wrote:
Everyone on holidays already?
Well I am still wondering why for the calculation of the stiffness of a
sphere
and a facet the radius of the facet is assumed to be twice the radius of
the
sphere.
I can say that this is
On 29 November 2011 08:38, Chareyre 897...@bugs.launchpad.net wrote:
Chiara, it is not too difficult to define a time step resulting in a
stable integration, and as soon as it is stable it is usually time-step
independant.
I agree, it was you to ask the question :-)
What I meant by
On 29 November 2011 08:52, Chiara Modenese c.moden...@gmail.com wrote:
On 29 November 2011 08:38, Chareyre 897...@bugs.launchpad.net wrote:
Chiara, it is not too difficult to define a time step resulting in a
stable integration, and as soon as it is stable it is usually time-step
On 28 November 2011 15:13, Chareyre 897...@bugs.launchpad.net wrote:
Hi,
I suspect the time-step determination fails because kn and ks are not
defined for distant interactions when using Hertz functors (with
neverErase=false, there are no distant interactions).
Correct.
Hertz Ip2 should at
Yes, I agree with that. It would have been nice to have a comparison
with Cundall's way but as it is now it is not consistent and am not sure
if anyone has time to fix it.
--
You received this bug notification because you are a member of Yade
developers, which is the registrant for Yade.
:
revno: 2910
committer: Chiara Modenese c.moden...@gmail.com c.moden...@gmail.com
branch nick: yade
timestamp: Mon 2011-08-29 18:31:34 +
message:
- Fix bug in Periodic Boundary. scene-cell-prevVelGrad was never updated.
It was equivalent to apply
Public bug reported:
Let's remember us that homoDeform=1 of the periodic case is not
correctly implemented. The option would be meaningful if relative
velocity computed in ScGeom was also updated according to the velocity
related to the strain rate of the periodic space (Cundall's way). As it
is
There is NO bug here and no shear force (it is numerically zero). It is
clear to me that PFC computes contact stiffness in a different way. Do you
know how it is computed in PFC then? Do you know which formula they actually
implement? In Yade you can easily check it yourself in the code
You (not PFC at this point) are defining the effective radius in the wrong
way. And well, to my opinion _hn (and _hs) should NOT be user defined as
their values are well established by Hertz (and Mindlin) theory itself.
Please input the same constant coefficients that you find in Yade if you
still
Hi,
can you past and copy here the NUMBERS you get after ONE time step as Bruno
suggested (please, read again his previous comment)? I mean: please print
FORCES, POSITIONS and VELOCITIES.
Regards,
Chiara
On 13 July 2011 13:32, Christian Jakob 806...@bugs.launchpad.net
wrote:
Hello again,
** Changed in: yade
Status: Fix Released = Confirmed
--
You received this bug notification because you are a member of Yade
developers, which is the registrant for Yade.
https://bugs.launchpad.net/bugs/806944
Title:
different behavoir of Hertz model while comparing PFC and YADE
Status
On 8 July 2011 07:12, Christian Jakob 806...@bugs.launchpad.net wrote:
Zitat von Chiara Modenese c.moden...@gmail.com:
So the problem is not the tension on or off. Can you check that the
damping
coefficients are defined in the same way for both codes? That could be
the
cause
Hi,
I see you are including both contact viscous damping as well as global (or
local as called in PFC) damping in your test. First of all, make sure that
everything works without any damping (does it?). Second, check that the
formulations you are comparing are precisely the same when damping is
compiling it, which is really
strange.
Did I miss something?
Bruno
On 17/05/11 14:02, Chiara Modenese wrote:
Bruno,
does this work to you? You say in this commit that: ...(default value
is ok if aabbWalls are appended BEFORE spheres.)
but utils.aabbWalls needs the packing first. Hence
)...
Sure, sorry about that and good to know it.
Cheers. Chiara
++
rémi
Bruno
On 17/05/11 14:02, Chiara Modenese wrote:
Bruno,
does this work to you? You say in this commit that: ...(default value
is ok if aabbWalls are appended BEFORE spheres.)
but utils.aabbWalls needs
Bruno,
does this work to you? You say in this commit that: ...(default value is ok
if aabbWalls are appended BEFORE spheres.)
but utils.aabbWalls needs the packing first. Hence it should not be possible
to append aabbWalls before spheres. Do you agree?
Cheers.
Chiara
On 22 April 2011 09:07,
I was not specifying extrema argument in aabbWalls function. Those were
generally calculated automatically, given a certain packing (generated
first). Otherwise, I have just seen that it works.
Thanks, Chiara
On 17 May 2011 12:20, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
does this
Hi,
I was looking at this function, line 24 of TriaxialStressController.cpp
Vector3r TriaxialStressController::getStress(int boundId) {assert
(boundId=0 boundId=5); return stress[boundId];}
and my question is: how is it possible that typing in python
triax.stress(100) gives a result? What is
Oh sorry guys. I forgot about that :-)
Thanks! Chiara
On 17 May 2011 17:24, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
assert's are disabled in optimized build. Does it answer your question?
:-)
B
On 17/05/11 19:12, Chiara Modenese wrote:
Hi,
I was looking at this function
You re right Bruno, just checked. Thanks a lot.
Chiara
On 12 May 2011 17:01, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
// distance between two contact spheres
d=((Body::byId(id1,scene)-state-pos) -
(Body::byId(id2,scene)-state-pos) +
.
For makeCloud, perhaps add a new 2D version instead of one more parameter
to the existing one? Because there are so many parameters already and we
have to type all of them when we use the function.
Sounds fine to me, thanks for suggestion!
Chiara
Bruno
On 29/04/11 16:28, Chiara Modenese wrote
Hi guys (Bruno?),
I want to do a biaxial test with Yade and I have the following proposal.
Would it be fine if I integrate particle generation (makeCloud) and the
stress controller (the periodic one) to the 2d case? I will be adding a bool
to distinguish the two cases. Let me know if it would be
Hey guys,
I tried to include these three lines in a py script to be run in Yade,
namely:
from numpy import *
import scipy
import scipy.linalg
The third line gives segmentation fault. I am not sure why. I attach below
the output from debug mode. Not sure if anyone can help, but maybe you had
the
Sorry, do not bother guys, I have just seen that using numpy.linalg other
than scipy.linalg works, instead. Just to let you know in case you need it.
On 27 April 2011 17:50, Chiara Modenese c.moden...@gmail.com wrote:
Hey guys,
I tried to include these three lines in a py script to be run
On 13 April 2011 10:32, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
Hi there,
The note:
Let me recall that Dem3Dof is unmaintained and links to many known and
unfixed bugs (see below).
If some of you are using this class without problems, good for them
(still, the fact that Yade
of releases, which are
also different anyway, but only for minimal changes --). Saving in xml
format fixed my problem indeed.
Just to let you know in case you had/have similar troubles.
Chiara
Bruno
On 06/04/11 15:34, Chiara Modenese wrote:
Hi Anton,
I use O.save() to save the simulation
Hi guys,
how is it that is not possible in Yade to reload simulations using different
releases? I mean, can we do something with that? I have samples which I need
to reload and, as am using different versions, am struggling with that.
Chiara
___
. This is a limit if
one wants to update, say frequently, the version in use.
Chiara
On 6 April 2011 13:23, Anton Gladky gladky.an...@gmail.com wrote:
What you mean reload?
Are you saving simulations with O.save()?
Anton
On Wed, Apr 6, 2011 at 3:19 PM, Chiara Modenese c.moden...@gmail.com
wrote
.
Bruno
On 06/04/11 15:34, Chiara Modenese wrote:
Hi Anton,
I use O.save() to save the simulation and I use O.load() to load (or
re-load, is the same) to continue with the test or make a change from the
point I saved. In Yade one needs to be consistent with the version utilized
to run
Hi there,
Do you have any reference which shows the formula for the stiffness tensor?
I see that in the PeriIsoCompressor.*pp there is a vector called stiff, is
this correct?
Cheers.
Chiara
___
Mailing list: https://launchpad.net/~yade-dev
Post to
16:54, Chiara Modenese wrote:
Hi there,
Do you have any reference which shows the formula for the stiffness
tensor? I see that in the PeriIsoCompressor.*pp there is a vector
called stiff, is this correct?
Cheers.
Chiara
___
Mailing
On 21 March 2011 18:46, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
Hi all,
As we can see there is a general reluctance in taking voice in this
discussion. Probably because not many people want to volunteer to
take the responsibility. A single leader is a good thing, because
he
guess sigma^visc is about 0...)
Thanks for answer, Vincent. I think I am in the second case, though I also
expect little contribution from viscous forces.
Chiara
Vincent
Le 1 mars 2011 à 12:21, Chiara Modenese a écrit :
Ok, then I would have a new question for you. I was thinking to apply
On 1 March 2011 01:24, luc scholtes lscholte...@gmail.com wrote:
Hi there,
I was looking for a way to compute stress in a given subdomain and just
found this thread :-)
My purpose is to have a look at the respective distribution of normal (Sii)
and shear (Sij) stress components in my
Ok, I think I know why now. I mean, since I have viscous forces stored into
normalForce that could be the cause.
Cheers. Chiara
On 28 February 2011 21:02, Chiara Modenese c.moden...@gmail.com wrote:
Hi Guys,
small question. I was trying to plot normal force versus overlapping of all
my
the viscous and the spring force into two distinct vectors and play with
that?
Thanks. Chiara
On 1 March 2011 09:49, Chiara Modenese c.moden...@gmail.com wrote:
Ok, I think I know why now. I mean, since I have viscous forces stored into
normalForce that could be the cause.
Cheers. Chiara
On 28
Oh thanks Bruno! I will see how it works. Perhaps we do not really need a
precise determination, this could be sufficient. Will try.
For time step determination of elastic bodies (so no damping), I think I
will also add a formulation based on the Rayleigh wave speed propagation
which Thornton
I saw that Chiara posted a similar questions last year but I couldn't find
any
implementation for that. So did anyone already implement something similar?
Eh no in the end I did not need to do that so you will be the first. Good
luck with that!
Chiara
Thanks
Klaus
On 25 February 2011 08:06, Vincent Richefeu riche...@gmail.com wrote:
Le 23 févr. 2011 à 17:43, Bruno Chareyre a écrit :
p.s. Vincent, you defined viscosity in order to keep critical time-step
below a given value IIRC. What was the reasoning behind?
No. I (and other people like Sergei)
On 25 February 2011 10:20, Sergei D. dorofee...@icp.ac.ru wrote:
Anyhow, according to the equations cited in PFC manual, the critical time
step would be smaller for viscous contacts even if the solution is
underdamped (at least for the linear dashpot model). Am I overlooking
something? Why
On 25 February 2011 14:51, Bruno Chareyre bruno.chare...@hmg.inpg.frwrote:
They are beside the scope as long as the question is how to define in
general a critical time-step for 2nd order explicit integration of
acceleration-velocity-position=0?.
Well, I have to disagree here. I think we
On 25 February 2011 17:28, Bruno Chareyre bruno.chare...@hmg.inpg.frwrote:
Well, I have to disagree here. I think we need first to clearly define
our equation, is it a linear or non linear one?
It doesn't matter. If it is non-linear, you can linearize it by looking
at tangent stiffness.
15:21, Vincent Richefeu riche...@geo.hmg.inpg.frwrote:
Just a pdf file I found on the web:
http://www.m-hikari.com/ces/ces2009/ces1-4-2009/teufelsbauerCES1-4-2009.pdf
Maybe it helps !?
Ciao
Vincent
Le 23 févr. 2011 à 19:01, Chiara Modenese a écrit :
Hi Bruno and Vincent,
thanks
!
Vincent
Le 22 févr. 2011 à 18:12, Chiara Modenese a écrit :
Hi guys,
I think we should introduce a limit to the time step for contact models using
viscous damping. Would you have a good reference about that apart from PFC
manual? Also would the GlobalStiffnessTimeStepper engine be a good
On 23 February 2011 19:26, Bruno Chareyre bruno.chare...@hmg.inpg.frwrote:
They mention Belytschko (1983) for critical timestep determination, why
not look there first?
Ok, lets have a look then. I will let you know ofc.
Chiara
Bruno
___
Hi guys,
I think we should introduce a limit to the time step for contact models
using viscous damping. Would you have a good reference about that apart from
PFC manual? Also would the GlobalStiffnessTimeStepper engine be a good place
for such an introduction?
Chiara
Hi,
I would like to compute the average stress tensor into subdomains of
periodic cell. Any hint how to do that and where to add it (is Shop the best
place?)?
Thanks, Chiara
___
Mailing list: https://launchpad.net/~yade-dev
Post to :
On 09/02/11 12:03, Chiara Modenese wrote:
Hi,
I would like to compute the average stress tensor into subdomains of
periodic cell. Any hint how to do that and where to add it (is Shop the best
place?)?
Thanks, Chiara
___
Mailing list: https
the subvolume will not be a problem. But what happens
if the branch vector of the interaction crosses the subdomain? Can this be
an issues?
Chiara
Cheers.
Bruno
On 09/02/11 12:03, Chiara Modenese wrote:
Hi,
I would like to compute the average stress tensor into subdomains of
periodic cell
Hi,
I was thinking about the meaning of bools like reversedForces,
compressivePositive and so on.
Recently I was quite confused about that and my point is: say that in our
contact law we decide that compressive forces are positive. Then, why not be
consistent and take compressive stresses also
On 8 February 2011 12:54, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
I was thinking about the meaning of bools like reversedForces,
compressivePositive and so on.
Recently I was quite confused about that and my point is: say that in
our contact law we decide that compressive
paragraph, there should be a link to unknown.jpg. You can replace
it by path/pictureName of the file you uploaded.
The site is offline at the moment unfortunately, I can't tell you more
precisely. Let's wait a moment.
Cheers.
Bruno
On 08/02/11 00:25, Chiara Modenese wrote:
There is some
Hi,
one question (maybe silly, if so please forgive me):
- Recently I added the computation of fabric tensor for the periodic cell. I
see that is quite common to split it into two parts in order to distinguish
between strong and weak contact forces. All I need to do is simply to
compare each
2011 14:21, Jerome Duriez dur...@geo.hmg.inpg.fr wrote:
Hello,
Le 07/02/2011 15:14, Chiara Modenese a écrit :
do I need to account for the sign of the force ?
I do not think so. I would not see the sense of doing so : in a contact
between 1 to 2, (force to 1) = - (force to 2). Why
There is some data missing in the authors page of the wiki. If you are
listed below, could you please update your profile and maybe add a
picture here : https://yade-dem.org/wiki/Authors_and_contributors.
Hi Bruno, thanks for the reminder. I did it and then I tried to upload a
picture but it
Only one change not mentioned in previous mail: setting Hsize is _not_
updating trsf (I added trsf=Id in setBox, it is effectively not modified).
That way, all cross-dependences between trsf, H, refH are removed and
everything is more clear I think.
formulation.rst is updated and is now in
On 2 February 2011 09:14, Sergei D. dorofee...@icp.ac.ru wrote:
Hi (Anton, Chiara?)
Who is working on dynamic problems?
Could not you explain why it occurs (see attached script)?
And do test the configuration with own laws?
Sergei -
may I ask you what was the purpose of your test and why
1. integration with oofem.org (or other FEM code; I mention this
specifically for Jan who might be interested), to have a decent and flexible
FEM interface. That would be for sure full-time work for 3 months which
would be very useful.
2. MPI subdomains and parallelization; highly
- refSize is not used anymore (for compatibility only)
BTW, I would not delete refSize (sorry, I have a few scripts I would not
like to change now). Maybe it could be renamed to something else to be
useful only when an axis-aligned cell is wanted, that would be a good idea
to me.
Chiara
Why temporary, this is the whole question. Currently we have not one but
two methods. It makes documentation twice longer and code 3x more
complicated.
I have to agree with you. I do not like temporary solutions for the same
reasons you mention. Thanks for explanation.
Ciao, Chiara
For mindlin.py, it seemed to me that the crash is due to an attempt to get
a normal force of an interaction which does not exist yet.
Yes, sorry, simply it is wrong the sign of the applied force. I will fix it
in my next commit. Chiara
___
Bruno,
adding the incremental formulation to CFLaw is not a problem if not that
there would be the creep behaviour to consider and am not sure to have time
to see how it works and also test it. Or maybe I could add the incremental
way in any case but specifying (via invalid arguments for
On 23 January 2011 16:35, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
Hi Chiara,
1) Using the (let's say old) method which would start from the
definition of refSize and trsf it is still possible to set
trsf=Identity when a new reference state is needed, right?
I'd say no. It's never
On 23 January 2011 20:19, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
.
I think it is possible, but in my previous post I missed to say that one
should also set the new reference size to the current one (at the moment in
which trsf is set equal to identity). Hence, given what
Bruno,
Side comment on (1) : it will need to change the behaviour of setTrsf
one day if we really want to uncouple trsf and Hsize. For instance, one
could like to type trsf=identity after a deformation process (i.e. after
some iterations) in order to set the current state as the reference for
On 14 January 2011 07:55, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
- Add incremental formulation for the moment rotation (bending only) to HM
law (it is very similar to the code for the shear part as written in ScGeom -
it has been tested but feedbacks are welcome).
PS Let me
Since there was no reply, I did it (r2653) using the relative angular
velocity. For me it was much simpler than what I found in the paper I
attached but let me know had you any comment.
Cheers. Chiara
On 12 January 2011 11:23, Chiara Modenese c.moden...@gmail.com wrote:
Hello,
how would you
Ok! Thanks all for suggestions. I agree that for now it is simpler to code
it in the Law functor. I will do and then test it with before commit. I let
you know if issues arise. Anyway, I will probably not be able to commit it
before Christmas -- in case someone else needed it (btw, Happy Christmas
Hi Bruno,
sorry to bother you but I need a bit of directions. As for the correct
implementation of the plasticity in the rolling behavior, I would choose to
add to ScGeom the incremental formulation as we do for the shear part. Hope
you agree since for me it would much simpler and more
Hi Bruno,
sorry could not you spend two words on this last change? I am referring to
the alpha parameter you introduced when we avoid granular ratcheting. Many
people (I think) are using this formulation so it would be nice to know what
is causing this change.
Cheers, Chia
On 10 December 2010
Hi Bruno!
On a different aspect, there is maybe one thing you are not aware of.
In unloading, you will unload plasticaly (maybe that is what you want? -
honestly I don't
think it makes less sense in the case of rolling friction).
If you want to unload elasticaly, you need to record the
On 10 December 2010 14:06, Chiara Modenese c.moden...@gmail.com wrote:
Hi Bruno!
On a different aspect, there is maybe one thing you are not aware of.
In unloading, you will unload plasticaly (maybe that is what you want? -
honestly I don't
think it makes less sense in the case of rolling
.
Question: why cannot we make the same thing we do for the shear force
(incremental formulation) with the rolling moment? Would not be
easier/cleaner?
Thanks. Chiara
Cheers.
Bruno
On 10/12/10 15:36, Chiara Modenese wrote:
On 10 December 2010 14:06, Chiara Modenese c.moden
On 8 December 2010 08:45, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
Hi,
Ah sorry I got it now. I does apply but I will have to create these
MatchMaker objects into Ip2. Bruno, since it is your code, what do you
prefer? You said you would like to keep only flags in the functor.
By
Bruno,
I just moved the alphas parameters to FrictMat. There is one thing I do not
completely understand. Maybe it is a design issue of the code. Two things
related to CohesiveFrictionalContactLaw:
- AlphasCo are not really physical parameters;
- Ip2_2xCohFrictMat_CohFrictPhys is specific to two
On 8 December 2010 12:26, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
- AlphasCo are not really physical parameters;
Why not?
Do you include alpha=Ks/Kn in AlphasCo?
If so, why?
If not, why would alpha be an acceptable constitutive parameter, but not
alpha_rolling?
For completeness
On 8 December 2010 14:59, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
For completeness I should have included also Ks/Kn. They are all
parameters of the interaction, however do they have a specific
physical-basis? I am not saying that it is wrong to employ them, that is
indeed a
The problem is that I have moved these alphas parameters (not yet in trunk)
to CohFricMat. I guess in such a case what you say would not apply, right?
Chiara
2010/12/6 Václav Šmilauer e...@doxos.eu
can I use the MatchMaker to get the harm average of alphas parameter? I am
not sure to
On 7 December 2010 09:46, Chiara Modenese c.moden...@gmail.com wrote:
The problem is that I have moved these alphas parameters (not yet in trunk)
to CohFricMat. I guess in such a case what you say would not apply, right?
Chiara
Ah sorry I got it now. I does apply but I will have to create
- There used to be some physical parameters (cohesion and others) in
Ip2_2xCohFrictMat_CohFrictPhys, but I recently moved them all to FrictMat.
If you have a
moment, could you please do the same for alphas and etaRoll (and probably
harmonic-average
them in the functor)? Only flags should be
Ok, Bruno. So I will wait for your suggestions.
Thanks for letting me know,
Chiara
On 6 December 2010 16:46, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
Chiara,
There is something ringing in my head now that ktwist!=kroll. There is
something I need to
double-check in the rotations
The less rational reason is I knew my scripts conserve energy, while
everything else I see
on yade lists seem to eat energy somehow. I was a bit afraid to change my
usual
practice...
Bruno, what is this usual practice? Sorry but I am interested in since I
spent so much time on it and could
Sorry it is my fault. I will fix it in a while. Bruno is right, tests
are useful.
Sorry again, Chiara
On 03/12/2010, Anton Gladky gladky.an...@gmail.com wrote:
Bruno, please, no offense!
It is just commented out with corresponding message in the code and comments
in commit.
It can be enabled
Hi Bruno,
On 3 December 2010 12:13, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
Hi Chiara,
(revno 2587)
- I restored Plassiard definition of Kr. Your definition is still optionaly
available
(flag useMeanRad).
Actually, I got to change it because I was following Plassiard's definition.
On 3 December 2010 14:57, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
- I restored Plassiard definition of Kr. Your definition is still
optionaly available
(flag useMeanRad).
Actually, I got to change it because I was following Plassiard's
definition. In his paper
anyway, just we would avoid to use Rmean. Let me
know.
Chiara
On 3 December 2010 15:16, Chiara Modenese c.moden...@gmail.com wrote:
On 3 December 2010 14:57, Bruno Chareyre bruno.chare...@hmg.inpg.frwrote:
- I restored Plassiard definition of Kr. Your definition is still
optionaly
Hi,
two things before I commit the changes on CohesiveFrictionalContactLaw.
- the attribute isBroken in CohFricMat is never used in the code. Shall we
keep it?
- I have limited the value of the maximum plastic moment for the rolling
part (with relative option to not apply it). What about the
On 2 December 2010 13:37, Bruno Chareyre bruno.chare...@hmg.inpg.fr wrote:
- the attribute isBroken in CohFricMat is never used in the code. Shall
we keep it?
It was used for display (giving a different color to spheres with broken
contacts).
It could be used again one day, but we can put
Actually, I think that the interface at launchpad would be the optimum (once
you get used to it). The fact that one can mark questions as answered and so
on is a great advantage. Let all know what you decide.
Chiara
On 26 November 2010 10:26, Jerome Duriez dur...@geo.hmg.inpg.fr wrote:
Bruno is right, if you exclude friction between spheres and wall, energy
will be conserved. Moreover, the same happens if you include boxes rather
than walls and you set friction equal to zero for boxes only (see
http://www.mail-archive.com/yade-us...@lists.launchpad.net/msg02395.html).
In this
Hi Vaclav,
why not trying to calculate the velocities at the right time? I remember I
was doing it and energy was conserved (without damping, either local or
global). We just need to shift them by adding acc*dt/2 (btw, we need to
_subtract_ this term in order to shift in the right way, as
Hi Bruno, actually I was going to send you an email about that (nice
synchronicity). Is it the same then? Could you be so kind to explain me why?
Sorry if I ask, I know it is something we already discussed on the list (see
this whole thread
1 - 100 of 210 matches
Mail list logo
