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-
dem
Branch: refs/heads/master
Home: https://github.com/yade/trunk
Commit: 8b5c7a53a9d589eb8663ef028d5b547b392bbafa
https://github.com/yade/trunk/commit/8b5c7a53a9d589eb8663ef028d5b547b392bbafa
Author: Chiara Modenese
Date: 2012-08-18 (Sat, 18 Aug 2012)
Changed paths:
M doc
On 17 Jul 2012, at 08:36, Bruno Chareyre wrote:
> Now I realize this was a merge bubble.
> Chiara made a git commit, hurray! ;)
Well big thank to Anton, I have to say (he was the committer, I only appeared
as the author) :-)
>
> Chiara, have a look at the git page on yade's wiki:
> https://y
core/Scene.hpp
M core/SimulationFlow.cpp
Log Message:
---
Implement stopAtTime parameter.
Commit: f22afe466ee5bc40ca48256d06ace731bd350c6d
https://github.com/yade/trunk/commit/f22afe466ee5bc40ca48256d06ace731bd350c6d
Author: Chiara Modenese
Date: 2012-07-16 (Mon, 16
core/Scene.hpp
M core/SimulationFlow.cpp
Log Message:
---
Implement stopAtTime parameter.
Commit: b6a90d69e8c5cbf63e75835fddc047c251dbe699
https://github.com/yade/trunk/commit/b6a90d69e8c5cbf63e75835fddc047c251dbe699
Author: Chiara Modenese
Date: 2012-07-16 (Mon, 16
On 16 Jul 2012, at 02:00, Chareyre wrote:
> This fix is correct I think.
> If I guess correctly (I didn't check the code), the problem is that calling
> erase(i) on an interaction is not erasing immediatly. Instead it sends a
> message to the collider to erase "i" at next step. If you save, the ne
I found one solution but I think is a temporary fix. The problem is that
somehow interactions are not deleted properly. Below is a modified
version of postLoad__calledFromScene - I am checking whether both bodies
in contact actually exist before the interaction is inserted, otherwise
return - but i
On 15 Jul 2012, at 11:20, Chareyre wrote:
> postLoad is trying to insert interactions with deleted body.
> Did you erase just before saving?
Exactly! How to overcome the problem? I think that Anton's fix was/is not
sufficient to solve it...
Chiara
>
> --
> You received this bug notification be
ack_end=0x7fffbd96d508) at libc-start.c:226
#88 0x004199f9 in _start ()
zsh: abort yade --debug
On 15 Jun 2012, at 10:04, Anton Gladky wrote:
> Hi Chiara,
>
> the fix is here [1]. It checks, whether the body exist before
> clearing its intrs-container.
>
> If you are
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 mailin
On 13 Jul 2012, at 16:53, Chareyre wrote:
> Public bug reported:
>
> (reported by Wenrui Zhu )
> particleSD2 takes a "seed" value in arguments, but the result is always
> random with or wothout seed.
The seed argument is missing when particleSD is returned at the end of
particleSD2 function.
>
OK, I had to do a clean scons but now it works fine so I confirm the fix was
appropriate. Thanks, Anton.
Chiara
On 15 Jun 2012, at 10:37, Anton Gladky wrote:
> 2012/6/15 Chiara Modenese :
>> OK, I see, thank you very much. Is the body deleted then? The length of
>> the contain
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
e problem
>
> Thanks
> Anton
>
> [1]
> https://github.com/yade/trunk/commit/ce52daf69cc7b0d804703a0877ffffec68fafae8
>
>
> 2012/6/15 Chiara Modenese :
>> Hi Anton,
>>
>> I am currently affected by this bug. I am using an older release (but
>>
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
dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~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
_
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.
Chiara
On 13 December 2011 10:35, Klaus Thoeni 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 what is generally
On 29 November 2011 09:14, Chareyre <897...@bugs.launchpad.net> wrote:
> Christian,
> Yes. GSTS is fine after with kn/ks, but there are also junk values comming
> from the contact law itself apparently (after #7), maybe because of the
> other stiffness values.
>
> Chiara,
> Stable = !unstable ;)
>
On 29 November 2011 08:52, Chiara Modenese 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 us
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 "a
On 28 November 2011 16:15, Chareyre <897...@bugs.launchpad.net> wrote:
> >Christian should use a fixed time
>
> I'd say GSTS should work even in that case (provided it is the source of
> the crash), and it is not too difficult to fix.
> I'm not really sure PWave timestep is accurate for Hertz cont
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 sh
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.
https://
e...@launchpad.net wrote:
>
> ----
> revno: 2910
> committer: Chiara Modenese
> 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 equivalen
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 n
July 2011 16:41, Chiara Modenese wrote:
> 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
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
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
(seeIp_Fric
** 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
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,
>
On 8 July 2011 07:12, Christian Jakob <806...@bugs.launchpad.net> wrote:
> Zitat von Chiara Modenese :
>
> > 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
> t
Christian, did you write the model or you are taking the one already
implemented in PFC? In the last case, I can have a look at the manual and
see what sort of viscous damping they implement. Let me know.
Chiara
On 7 July 2011 14:39, Chiara Modenese wrote:
>
>
> On 7 July 2011 13:58,
On 7 July 2011 13:58, Christian Jakob <806...@bugs.launchpad.net> wrote:
> OK, for following results of further calculations the shear modulus is
> always 3e7 and poisson ratio is always 0.3.
> Note also, that viscous damping in shear direction doesnt influence the
> flyback_height.
>
Of course.
the difference comes from.
Chiara
On 7 July 2011 13:11, Chiara Modenese wrote:
> 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 d
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
in
n an answer to yade-dev list
> (or modify the header)...
>
Sure, sorry about that and good to know it.
Cheers. Chiara
>
> ++
> rémi
>
> >
> > Bruno
> >
> >
> > On 17/05/11 14:02, Chiara Modenese wrote:
> >> Bruno,
> >>
> >
, 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.)
&g
Oh sorry guys. I forgot about that :-)
Thanks! Chiara
On 17 May 2011 17:24, Bruno Chareyre 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 wa
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 i
e(
>
> wall_bottom_id=wallIds[2],
> wall_top_id=wallIds[3],
> wall_left_id=wallIds[0],
> wall_right_id=wallIds[1],
> wall_back_id=wallIds[4],
> wall_front_id=wallIds[5],
>
> After 2830, you can skip those lines if you generate boxes first.
>
> Bru
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 wrote:
>
> > does this work to you? You say in th
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
You re right Bruno, just checked. Thanks a lot.
Chiara
On 12 May 2011 17:01, Bruno Chareyre wrote:
>
> >
> > // distance between two contact spheres
> > d=((Body::byId(id1,scene)->state->pos) -
> > (Body::byId(id2,scene)->state->pos) +
> > (scene->cell->hSize*I->cellDist.cast())).norm();
> >
> I
Hi,
am trying to compute the total overlapping volume within a sample but am not
sure am doing it right. I think that perhaps am computing the distance
between two contacting particles in the wrong way. Is the following line of
code correct in case of periodic conditions (Bruno?) ?
// distance be
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/
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 a
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 wrote:
> Hey guys,
>
> I tried to include these three lines in a py script to be run in Yade,
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
On 13 April 2011 10:32, Bruno Chareyre 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 doesn't crash doesn't mea
ht it was a matter 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
s as a solution.
>
> 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
limit if
one wants to update, say frequently, the version in use.
Chiara
On 6 April 2011 13:23, Anton Gladky wrote:
> What you mean "reload"?
>
> Are you saving simulations with O.save()?
>
> Anton
>
>
>
>
> On Wed, Apr 6, 2011 at 3:19 PM, Chiara Modene
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
___
Mailing
>distance between centers
> >2- forces increments are df = dun*kn+dus*ks
> >3- average df's somehow to get a dsigma (they could be averaged using
> >Love Weber stress, but I think there is a different averaging currently)
> >4- derive dsigma/depsilon = stiffnes
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 :
On 21 March 2011 18:46, Bruno Chareyre 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 manages and takes care
d I 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 quest
e
the viscous and the spring force into two distinct vectors and play with
that?
Thanks. Chiara
On 1 March 2011 09:49, Chiara Modenese 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
>
>
>
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 wrote:
> Hi Guys,
>
> small question. I was trying to plot normal force versus overlapping of all
> my interacti
On 1 March 2011 01:24, luc scholtes 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 cohesive assemblies.
Hi Guys,
small question. I was trying to plot normal force versus overlapping of all
my interactions. For the normal force I want to keep the sign and so I
simply project it onto the corresponding normal vector something like:
Fn=i.phys.normalForce.dot(i.geom.normal). The problem is that, without
On 28 February 2011 13:26, Bruno Chareyre wrote:
>
> > Oh thanks Bruno! I will see how it works. Perhaps we do not really
> > need a precise determination, this could be sufficient. Will try.
> >
> Yes, it would precise enough that way I think.
> Note that it still needs to determine the global vi
> 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
>
> _
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 uses
On 25 February 2011 17:28, Bruno Chareyre wrote:
>
> > 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. So, in the end the s
On 25 February 2011 14:51, Bruno Chareyre wrote:
> 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 need first to clearly d
On 25 February 2011 10:20, Sergei D. 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 would be th
On 25 February 2011 08:06, Vincent Richefeu 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) defined the v
15:21, Vincent Richefeu wrote:
> 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,
&
On 23 February 2011 19:26, Bruno Chareyre wrote:
>
> 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
>
> ___
> Mailing list: https://l
r a given integration scheme, let say that the critical time step
> determined for non-viscous contact will be smaller that the effectively
> minimum time step... Not sure it helps!
>
> Vincent
>
> Le 22 févr. 2011 à 18:12, Chiara Modenese a écrit :
>
>
> Hi guy
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
_
hod 1.
>>
> I think that defining 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
>>
>>
>>
>
g 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
>
> 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. Any hint how to do that and where to add it (is Shop the best
> place?)?
> Thanks, Chi
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 : yade-dev@lists.la
> On 08/02/11 12:05, Bruno Chareyre wrote:
>
> In your 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
On 8 February 2011 12:54, Bruno Chareyre 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 forces are posit
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 posi
> 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
2011 14:21, Jerome Duriez 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
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 conta
On 2 February 2011 09:14, Sergei D. 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 did you expect
som
> 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
>
> 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 cha
>
> 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
>
>
> - 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
>
>>
>
>
> > Nothing conclusive from my side whether 1. or 2. should be preferred.
> > Perhaps others can give their opinions?
>
I think that at the moment we have only one approach and it looks good
because:
- refSize is not used anymore (for compatibility only)
- setting trsf=Identity sets the curren
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 instance)
>
> 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
>
>
>
>
>
On 23 January 2011 20:19, Bruno Chareyre 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 setTrsf() does, this
> should
On 23 January 2011 16:35, Bruno Chareyre 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 been possible if I
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 fo
On 14 January 2011 07:55, Bruno Chareyre 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 know if you are intere
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 wrote:
> Hello,
>
> how would you co
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 understanda
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 2
using it at this moment, I
think they should update it too (or I can do it as I soon as we update CFLaw
likewise).
I do not well understand quaternions (I know it is my lack of knowledge,
somehow) but I would appreciate if you could assist.
Question: why cannot we make the same thing we do for the
1 - 100 of 270 matches
Mail list logo
