Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

I then tried to see what happens if I use TranslationEngine. In such case I > can still run the simulation havin non dynamic bodies (and I get the same > result as above). My question is: in this second case, if I set the body I > am forcing to move as dynamic, am I considering twice the applied >

Re: [Yade-users] sphere-box interactions in Ig2_Box_Sphere_ScGeom

On 29 March 2010 12:35, Bruno Chareyre wrote: > Hello all, > > Currently in Ig2_Box_Sphere_ScGeom, sphere-box contacts are seen as > contacts between the sphere and another sphere twice bigger (the big one > representing the box). > I'd like to change that and make the fictious sphere the same si

[Yade-users] python contact laws

Hi Vaclav, I have this problem I would like to solve it in python. I want to run a simulation (say 10 iterations) and then I want to reload the same one but using a different contact law. How can I do that? Should I modify the html file or can I do directly using python? Thanks a lot, Chiara

Re: [Yade-users] python contact laws

On 20 April 2010 15:00, Bruno Chareyre wrote: > I'm not Vaclav, but it doesn't sound like a pure "python©" question. > Modifying the xml or using python raises the same questions : will the new > law accept the old IPhys and IGeom? If yes, you just have to change the > functor in interaction disp

Re: [Yade-users] python contact laws

On 20 April 2010 16:23, Bruno Chareyre wrote: > > Say that the second contact law uses different IPhys and IGeom than the >> previous one, in this case it seems perhaps not possible.. >> > It could be done. For instance, you could loop on all interactions of type > 1, delete them and replace the

[Yade-users] Energy dissipation

Hi all, just a general question. Is there a way to calculate in Yade the energy dissipation in a particle system within a simulation? I mean, in order to get a quasi-static condition we dissipate energy, whether this happen through the local/global damping and/or due to the friction. Can we do thi

Re: [Yade-users] Energy dissipation

2010/4/20 Bruno Chareyre > On the same line : the energy dissipated by Cundall's damping in > quasi-satic conditions is negligeable. You find that the work input from > boundaries equals more or less plastic+elastic work at contacts (tests with > pfc3D, damping~0.2, frictional contacts, ~50k iter

Re: [Yade-users] Energy dissipation

2010/4/20 Bruno Chareyre > On the same line : the energy dissipated by Cundall's damping in > quasi-satic conditions is negligeable. You find that the work input from > boundaries equals more or less plastic+elastic work at contacts (tests with > pfc3D, damping~0.2, frictional contacts, ~50k iter

Re: [Yade-users] Energy dissipation

On 21 April 2010 15:25, Bruno Chareyre wrote: > > >> Doesn't the problem with different plasticity condition come into play >> only if you store shear force instead of strain? That would break for >> non-linear elasticity...? >> >> >> > Not sure it makes a difference. How do you define the plasti

Re: [Yade-users] Energy dissipation

On 21 April 2010 16:18, chiara modenese wrote: > > > On 21 April 2010 15:25, Bruno Chareyre wrote: > >> >> >>> Doesn't the problem with different plasticity condition come into play >>> only if you store shear force instead of strain?

Re: [Yade-users] Energy dissipation

On 21 April 2010 16:40, Bruno Chareyre wrote: > > 2. current "trial" shear strain εT is computed*, with corresponding >> trial stress σT(εT); for admissible state f(σN,|σT(εT)|)<=0, there is no >> dissipation and the contact is done for this timestep. In case of >> non-admissible f(σN,|σT|)>0, s

Re: [Yade-users] Energy dissipation

2010/4/21 chiara modenese > > > On 21 April 2010 16:40, Bruno Chareyre wrote: > >> >> 2. current "trial" shear strain εT is computed*, with corresponding >>> trial stress σT(εT); for admissible state f(σN,|σT(εT)|)<=0, there is no >>> di

Re: [Yade-users] Energy dissipation

On 21 April 2010 17:24, Bruno Chareyre wrote: > > >> BTW, a c++ question. Why are looping here over all the interactions if >> this is done in the interaction dispatcher? Sorry I am still learning :) >> Law2_ScGeom_FrictPhys_Basic is not inheriting from a periodic engine.. >> cheers, Chiara >> >>

Re: [Yade-users] Energy dissipation

BTW, just found this paper that fits very well this discussion.. "Energy monitoring in distinct element models of particle systems" by Asmar, Langston, Matchett and Walters (2003) > > >> >> >> Bruno >> >> ___ >> Mailing list: >> https://launchpad.net/~y

[Yade-users] displacement time history with python

Hi all, how can I impose a force (or better a displacement) changing over time in the simulation (let's say increasing/decreasing)? PyPeriodicRunner? Any examples already done in Yade? cheers, Chiara ___ Mailing list: https://launchpad.net/~yade-users P

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

2010/4/19 Václav Šmilauer > > > > > Yes, I confirm (by myself :-) ) that doing so we account for the > > applied displacement twice. Actually this fact is already documented > > and avoid in JumpChangeSe3 class. Maybe we can add a comment also in > > TranslationEngine so that if one wants to use

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

2010/4/23 Václav Šmilauer > > > Reading JumpChangeSe3 (wouldn't it be better to call it > > StepChangeSe3, > > or rather StepChange... something else?) code, positions are > > updated "by > > hand" > > > > if(!setVelocities || (setVelocities && !b-

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

2010/4/23 Václav Šmilauer > > > > > Using ScGeom, being the bodies Dynamic and using JumpChangeSe3 should > > work? > > Well let's try again.. I will let you know.. > > Make sure you set > > https://www.yade-dem.org/sphinx/yade.wrapper.html#yade.wrapper.JumpChangeSe3.setVelocitiesto > true (it i

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

On 23 April 2010 14:06, Bruno Chareyre wrote: > A logic I found very efficient for this problem (perhaps already possible > in Yade?) is the one of PFC : > You can declare some DOF's fixed for velocities/spins (say, Vx is declared > fixed). > After that, if you set Vx=0, the body doesn't move. If

Re: [Yade-users] displacement time history with python

2010/4/23 Václav Šmilauer > Hi Chia, > > there is > > https://www.yade-dem.org/sphinx/yade.wrapper.html#yade.wrapper.InterpolatingDirectedForceEnginewhich > you might consider. Implementing analogous > InterpolatingTranslationEngine would be trivial, you can try that; or I can > do it if you nee

Re: [Yade-users] displacement time history with python

2010/4/23 Václav Šmilauer > I updated scripts/test/interpolating-force.py so that it shows something > meaningful. > Hi Vaclav, I see that in InterpolatingDirectedForceEngine we define our force as a function of time within _times_ variable range. If the variable _wrap_ is set to true, I see we r

Re: [Yade-users] displacement time history with python

On 23 April 2010 16:12, chiara modenese wrote: > > > 2010/4/23 Václav Šmilauer > >> I updated scripts/test/interpolating-force.py so that it shows something >> meaningful. >> > Hi Vaclav, > I see that in InterpolatingDirectedForceEngine we define our force as

Re: [Yade-users] O.engines.append ?

2010/4/15 Václav Šmilauer > > > I do not succeed, once I defined O.engines=[...], to add other Engines > > with O.engines.append > > Could it be possible or not ? > > you have to say > >O.engines=O.engines+[YourEngine()] > I have tried this way and you insert the engine at the end of the

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

2010/4/23 Václav Šmilauer > > > > > Using ScGeom, being the bodies Dynamic and using JumpChangeSe3 should > > work? > > Well let's try again.. I will let you know.. > > Make sure you set > > https://www.yade-dem.org/sphinx/yade.wrapper.html#yade.wrapper.JumpChangeSe3.setVelocitiesto > true (it i

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

2010/4/25 Václav Šmilauer > > > both TranslationEngine and JumpChangeSe3 work if bodies are dynamic. > > Now I tried a simple sphere-sphere interaction test using the basic > > Law2_ScGeom_FrictPhys_Basic() law. One ball is fixed, the other one is > > moved by using JumpChangeSe3 (setting setVelo

Re: [Yade-users] ImpactForce

On 21 April 2010 15:09, Nasibeh Moradi wrote: > hi, > > I want to plot impact force of a body (this body impact on a plate), > How can I get the forces on it? > Hi Nasibeh, have you tried with O.forces.f()[]? Chiara > > Nasibeh Moradi > > ___ > Maili

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

2010/4/25 Václav Šmilauer > > > both TranslationEngine and JumpChangeSe3 work if bodies are dynamic. > > Now I tried a simple sphere-sphere interaction test using the basic > > Law2_ScGeom_FrictPhys_Basic() law. One ball is fixed, the other one is > > moved by using JumpChangeSe3 (setting setVelo

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

On 26 April 2010 11:49, Bruno Chareyre wrote: > >> Prescribing displacement (even by fixing position of >> support) means that energy might disappear from the system... >> > This is what I was trying to find out, I mean, _why_ that happens.. > >> >> > > By definition, you impose displacement on

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

On 27 April 2010 12:53, Bruno Chareyre wrote: > > Would not just be simply an initial velocity you assign, which might >> change once your body hits another one, isn't it? >> > In that case, you just assign an initial velocity (body.vel=.., no engine, > no blocked DOF). This is not what I call a

Re: [Yade-users] TranslationEngine Vs JumpChangeSe3

On 27 April 2010 17:13, Bruno Chareyre wrote: > > I was only testing a contact law forcing displacements, but now I realize >> that the best way to check that is actually applying a force (constant or >> variable in time) or an initial velocity (in the way you suggest). >> > Ok. For this proble

Re: [Yade-users] UniaxialTest

2010/4/30 Václav Šmilauer > > > > > with this law I can run just compression, > > before I run it and posted its graph to you, in this law there isn't > > any cohesion then Sigma is zero. > Oh, sorry. But you can adapt it easily. > > BTW check how are your interactions generated. Perhaps you don'

Re: [Yade-users] UniaxialTest

On 30 April 2010 07:30, Nasibeh Moradi wrote: > hi Václav, > > I attached 2 graph, compression and tension. > My law is symmetric and I have checked it. > If your law is symmetrical, what is the point to check it both in compression and tension? > it is very simple, and Kn and Ks are computed

Re: [Yade-users] UniaxialTest

2010/4/30 Václav Šmilauer > > > > If your law is symmetrical, what is the point to check it both in > > compression and tension? > > To check whether it is really symmetrical? ;-) of course ;-) > (I gathered the law had > some damage etc, so it will be only symmetrical around zero, in the > ela

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 21 April 2010 18:23, Bruno Chareyre wrote: > It is commited now (r2170). I've put the symmetric IGeom for box-sphere in > this commit as well (removed the "2" factor). > I didn't test energy tracing at all yet. Any feedback is welcome. Hi Bruno, I'd like to monitor the elastic energy of the

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 3 May 2010 18:30, Bruno Chareyre wrote: > > > chiara modenese a écrit : > > >> >> On 21 April 2010 18:23, Bruno Chareyre > bruno.chare...@hmg.inpg.fr>> wrote: >> >>It is commited now (r2170). I've put the symmetric IGeom for >>

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 3 May 2010 18:33, chiara modenese wrote: > > > On 3 May 2010 18:30, Bruno Chareyre wrote: > >> >> >> chiara modenese a écrit : >> >> >>> >>> On 21 April 2010 18:23, Bruno Chareyre >> bruno.chare...@hmg.inpg.fr>> wrote:

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 3 May 2010 17:23, chiara modenese wrote: > > > On 21 April 2010 18:23, Bruno Chareyre wrote: > >> It is commited now (r2170). I've put the symmetric IGeom for box-sphere in >> this commit as well (removed the "2" factor). >> I didn't test

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

2010/5/4 Václav Šmilauer > > > Hi, > > the function is implemented in Shop class, but I cannot say how to > > access it through py atm. In fact it is just not wrapped.. > It is wrapped in yade.utils, > https://www.yade-dem.org/sphinx/yade.utils.html#yade.utils.kineticEnergy > (shame on us, it has

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 3 May 2010 18:30, Bruno Chareyre wrote: > > > chiara modenese a écrit : > > >> >> On 21 April 2010 18:23, Bruno Chareyre > bruno.chare...@hmg.inpg.fr>> wrote: >> >>It is commited now (r2170). I've put the symmetric IGeom for >>

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 5 May 2010 10:10, Bruno Chareyre wrote: > > >> btw, in the triaxial the kinetic energy does not account for angular >> velocities, whereas in Shop class it does >> > Good point. The best is to simply replace kinE calculation in the recorder > by shop::kineticEnergy. I'll try and commit that.

Re: [Yade-users] Energy dissipation + radius of fictious "box" sphere is now =r (not 2*r)

On 5 May 2010 13:25, Bruno Chareyre wrote: > > >> Just for confirmation, is the kinetic energy computed taking into account >> velocities at half time steps, right? Do we also compute velocities at >> integer time steps? >> >> You can consider kinetic energy is defined for times t=(k+0.5)dt. O

Re: [Yade-users] Video File

On 6 May 2010 08:46, Nasibeh Moradi wrote: > Hi Chiara > > Have you yet worked with Paraview? or utils.encodeVideoFromFrames? > I can not work with Paraview :( > for one-one test, I use VTKRecorder and creat .vtu files, when I open them > with Paraview, it is shown only points. > With utils.encod

Re: [Yade-users] Video File

2010/5/6 Václav Šmilauer > > > > > Hi, > > > > I have never worked with Paraview, I downloaded it but never worked > > with. How does it work? What is it for? Can you explain me a little > > bit? so maybe I try something.. > Hi, > > you have to add glyphs to spheres so that they appear as spheres

Re: [Yade-users] Are our systems conservatives?

2010/5/6 Václav Šmilauer > > > I am playing a little bit with the code to understand how thinks work > > in terms of energy. I started with a very simple example of two balls > > in normal contact. > > I am only applying an initial velocity to one particle, hence the > > total energy of the syste

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 12:08, Bruno Chareyre wrote: > > Perhaps I guess that dealing with _quasi-static conditions_, energy >> considerations become superfluous (that is maybe why nobody here has >> approached the problem?). On the other hand, if the problem is _dynamic_ I >> think they matter. >> >> Is

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 13:31, Bruno Chareyre wrote: > >> Ok, can I change something in Shop for the dt/2 shift or should I save >> velocities and accelerations and then interpolate? >> >> > You can change in shop. > I changed in shop the kinetic as ret+=.5*(b->state->mass*(b->state->vel+b->state->accel*d

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 15:51, chiara modenese wrote: > > > On 7 May 2010 13:31, Bruno Chareyre wrote: > >> >>> Ok, can I change something in Shop for the dt/2 shift or should I save >>> velocities and accelerations and then interpolate? >>> >>>

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 16:40, Bruno Chareyre wrote: > > >> I tried the sample example with the two balls and the time step estimated >> by PWave. I attach the figure. >> > Mmmm... It is not "that" better. I expected better matching with corrected > kinetic (as in the simple mass-spring test). > > > Now I

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 16:49, Bruno Chareyre wrote: > > >> So, you need in fact to __substract__ accel*dt/2, and you will get at time >> "t" the energy of time "t-dt". Sorry if I wrote something different in >> previous mails. >> > Not sure it was a good idea, since nobody will understand why kineticEnerg

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 16:40, Bruno Chareyre wrote: > > >> I tried the sample example with the two balls and the time step estimated >> by PWave. I attach the figure. >> > Mmmm... It is not "that" better. I expected better matching with corrected > kinetic (as in the simple mass-spring test). "Shifting"

Re: [Yade-users] Are our systems conservatives?

On 7 May 2010 15:40, Bruno Chareyre wrote: > > >> I tried the sample example with the two balls and the time step estimated >> by PWave. I attach the figure. >> > Mmmm... It is not "that" better. I expected better matching with corrected > kinetic (as in the simple mass-spring test). > > > Now I

Re: [Yade-users] Are our systems conservatives?

On 10 May 2010 17:43, Bruno Chareyre wrote: > > >> Hi Bruno, please see attached file. I am not completely sure but I think >> it would be correct to distinguish between loading and unloading phase. I am >> trying to prove it analytically, I am not yet totally confident.. What do >> you think? >>

Re: [Yade-users] Are our systems conservatives?

On 10 May 2010 18:03, chiara modenese wrote: > > > On 10 May 2010 17:43, Bruno Chareyre wrote: > >> >> >>> Hi Bruno, please see attached file. I am not completely sure but I think >>> it would be correct to distinguish between loading and un

Re: [Yade-users] Are our systems conservatives?

On 10 May 2010 18:23, chiara modenese wrote: > > > On 10 May 2010 18:03, chiara modenese wrote: > >> >> >> On 10 May 2010 17:43, Bruno Chareyre wrote: >> >>> >>> >>>> Hi Bruno, please see attached file. I am not completel

Re: [Yade-users] Are our systems conservatives?

On 11 May 2010 08:55, Bruno Chareyre wrote: > >> >> >>OTOH, us is exactly (trialFs-prevFs)/ks, by definition of >>trialFs, >> >> btw, us as you intend here is actually the total plastic displacement, not >> the incremental one. >> > > No, it is really the increment, includ

Re: [Yade-users] wiki offline

2010/5/12 Václav Šmilauer > > There is currently a power cut in a full building in Grenoble, and > > unfortunatelly this is where the servers are... > > You perhaps noticed that yade wiki was not reachable, sorry for that. > > It should be back on monday, but expect temporary cuts even after mond

[Yade-users] fixedPoroCompaction TT

Hi Bruno, are you using the bool fixedPoroCompaction in the triaxial to get a specific porosity? I can see that is not probably the best method for this purpose. Now that I am finally back to the Triaxial (which is my current interest) I need to vary the porosity of the sample. I vaguely remember

[Yade-users] Initial time step

Hi all, for the triaxial I want to use the PWaveTimeStep() as a first estimate and then going on with the GSTS. But if I include in the python script o.dt=.5*utils.PWaveTimeStep() then it seems it is only using this value although the TT generator file is using GSTS. How is that I give an initial

Re: [Yade-users] Initial time step

2010/5/13 chiara modenese > > > It is a "feature" that I recall now. If you set timestep via O.dt, it >> will disable timesteppers (otherwise the change would be only effective >> until the next run of the timestepper). You can re-eanble timesteppers >> wit

Re: [Yade-users] Initial time step

2010/5/13 Václav Šmilauer > > Not very logical, as I see now (and not documented either). I would > > change it as follows: if you set O.dt to a non-positive value, then > > timestepper will be enabled (and exception raised if there not one). If > > you set O.dt to a positive value, timestepper

Re: [Yade-users] Initial time step

2010/5/13 Václav Šmilauer > > > > In fact... I would opt for the option below, still a way to go around > > though. But maybe there are not too many solutions if one wants to use > > both o.dt and TS. > > r2223 & > > http://beta.arcig.cz/~eudoxos/yade/sphinx/yade.wrapper.html#yade.wrapper.Omega.d

[Yade-users] engine append TT

Hi, I am running a script loading the triaxial test something like TriaxialTest().load() I was then trying to append an engine to the simulation like O.engines.append(...) But it seems it is not working. Why? Where am I wrong? Thanks! Chiara ___ Mai

Re: [Yade-users] engine append TT

On 14 May 2010 12:32, chiara modenese wrote: > Hi, > > I am running a script loading the triaxial test something like > > TriaxialTest().load() > > I was then trying to append an engine to the simulation like > > O.engines.append(...) > > But it seems it is n

Re: [Yade-users] O.engines.append ?

2010/4/24 Václav Šmilauer > > > >O.engines=O.engines+[YourEngine()] > > I have tried this way and you insert the engine at the end of the list > > (or vector). What if you want to insert the engine at a specific > > position? If .append does not work I suppose that also .insert do

[Yade-users] sdecGroupMask

Hi all, Could you briefly explain me what is the meaningful of the variable sdecGroupMask? I see that in the current triaxial test is set to a value of 2.. cheers, Chiara ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists

Re: [Yade-users] fixedPoroCompaction TT

On 13 May 2010 14:22, chiara modenese wrote: > Hi Bruno, > > are you using the bool fixedPoroCompaction in the triaxial to get a > specific porosity? I can see that is not probably the best method for this > purpose. Now that I am finally back to the Triaxial (which is my curren

Re: [Yade-users] fixedPoroCompaction TT

> It doesn't need any c++. I've added a function to modify friction recently. > You could just apply it each 100 iterations, reducing friction a little, as > soon as the packing is stable and until you reach the porosity you like. > > You can type this in python : > > TriaxialCompressionEngine().se

[Yade-users] Coordination number

Hi, do we have in python/c++ a function to get the coordination number over time of a packing of spheres? thanks! Chiara ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net

Re: [Yade-users] Coordination number

2010/5/19 Václav Šmilauer > chiara modenese píše v St 19. 05. 2010 v 12:40 +0100: > > Hi, > > > > do we have in python/c++ a function to get the coordination number > > over time of a packing of spheres? > Oh yes, we do: > > https://www

Re: [Yade-users] Coordination number

On 19 May 2010 12:52, Anton Gladky wrote: > What you mean "coordination number"? > Average number of interactions per elements. > > > > 2010/5/19 chiara modenese > >> Hi, >> >> do we have in python/c++ a function to get the coordination number o

Re: [Yade-users] fixedPoroCompaction TT

> It doesn't need any c++. I've added a function to modify friction recently. >> You could just apply it each 100 iterations, reducing friction a little, as >> soon as the packing is stable and until you reach the porosity you like. >> >> You can type this in python : >> >> TriaxialCompressionEngin

[Yade-users] Visualization/Post-processing

Hi all! Just a general question about post-processing and visualization data with Yade. For instance, given a certain simulation, I would like to display the displacement or velocity field (say with arrows) or better the chains of normal contact forces between particles. Which one would be the easi

Re: [Yade-users] Visualization/Post-processing

On 20 May 2010 09:39, Anton Gladky wrote: > Yes, I think paraview would be the best. > You need just to add one more engine: > > VTKRecorder(iterPeriod=100,fileName='youFileOutput'), > > then grab created files by paraview and you can play with colors, types of > visualisations, create videos, ma

Re: [Yade-users] harmonic average of stiffness

On 21 April 2010 14:53, Bruno Chareyre wrote: > > >> My simplest explanation is actually in the documentation of the class, > let me know if it is not clear enough : > > /"The compliance of one sphere under symetric point loads is defined here > as 1/(E.D), with E the stiffness of the sphere and

Re: [Yade-users] Periodic triaxial

2010/5/17 Václav Šmilauer > plus scripts/test/periodic-triax.py for inspiration. Run with -j1 it > will run very slow with such small number of particles otherwise. > Hi, I see periodic scripts tests using functor which only deal with Dem3DofGeom instances. Is the PB also working fine also with

Re: [Yade-users] Periodic triaxial

2010/5/24 Václav Šmilauer Hi Vaclav, just a couple of quick questions about PB. 1) Are you following Cundall's algorithm? 2) I see the variable velGrad being a matrix, why? 3) I understand it is possible to set the variable homotheticCellResize as equal to 0, 1 or 2. I was reading Cundall's pape

Re: [Yade-users] Periodic triaxial

On 24 May 2010 14:32, Bruno Chareyre wrote: > Based on my test, ScGeom doesn't work in PB. It is (I think) because it > needs relative velocity, which is not defined correctly across periods. > I have a few ideas to solve that though, and some uncommited code (see > **)... > It is a pitty that we

Re: [Yade-users] Periodic triaxial

On 24 May 2010 15:02, chiara modenese wrote: > > Thornton, Antony, "Quasi-static shear deformation of a soft particle > system", Powder Technology, 2009, pp. 179-191. > 2000* > > Chiara > >> Bruno >> >> >> ___

Re: [Yade-users] Periodic triaxial

> 1) Are you following Cundall's algorithm? >> > I don't know Cundall's papers on this. Any reference? So if not using the algorithm bys Cundall or Thornton, which is actually your reference? thanks, Chiara > > > > > > ___ > Mailing list: > https://l

Re: [Yade-users] Periodic triaxial

2010/5/24 Václav Šmilauer > > > So if not using the algorithm bys Cundall or Thornton, which is > > actually your reference? > It was somewhat evlutionary. What exactly would you like to know? > Cell.trsf is transformation matrix (from perpendicular cuboid of refSize > size) and Cell.velGrad is t

Re: [Yade-users] Periodic triaxial

On 24 May 2010 17:00, Bruno Chareyre wrote: > And in fact the rate of loading is what you'll find in Thornton and Cundall > when defining the relative velocity across periods, it is my best bet before > reading the papers. > Yes, supposing a strain-controlled test you will find the usage of the s

Re: [Yade-users] Periodic triaxial

2010/5/24 Václav Šmilauer > > > Yes, I insist on defining the rate of loading, which is more important > > that the final state for materials like ours > I was not questioning the fact that it is defined (it is important, I > agree), but the name "velocity gradient" which I still don't get really

Re: [Yade-users] Periodic triaxial

Yes, supposing a strain-controlled test you will find the usage of the >> strain rate of loading to update relative velocities. Maybe is that what we >> need once adopting ScGeom? >> >> > Yes, this is what we need. Note that updating velocity should be done on > bodies themselves to be really corre

Re: [Yade-users] Periodic triaxial

> > > Bruno why do we not define a strain rate instead of velGrad? > Ops, sorry just see you already answered me before :-) cheers, Chiara > >> Cheers. >> >> Bruno >> >> >> >> >> >> >> >> ___ >> Mailing list: >> https://launchpad.net/~yade-users

Re: [Yade-users] Periodic triaxial

On 24 May 2010 21:07, chiara modenese wrote: > >> Bruno why do we not define a strain rate instead of velGrad? >> > In fact, Thornton is using a strain rate tensor user-defined to update particles position. S this is working fine only in the specific case of the triaxial.. &

Re: [Yade-users] Granular ratchetting explained

On 26 May 2010 07:51, Bruno Chareyre wrote: > For those interested, I elaborated the comment a little in ScGeom.cpp > (possible wiki paragraph in the future), as this "granular ratchetting" > needed explanation. > We could put a simple py script to simulate the cycle explained below, and > test a

Re: [Yade-users] Periodic triaxial

On 26 May 2010 09:08, Bruno Chareyre wrote: > Incremental formulation and periodicity are now mixed safely using > Law2_ScGeom_FrictPhys_Basic. > HomotheticResize is now a bool. If true, velocity is updated, no other > choice. > > Chiara, Jerome, and Luc : I got to add one line in your functors,

Re: [Yade-users] Periodic triaxial

> > > If bodies from different periods are in contact, you need to translate at > least one of them to its ghost position in order to define the local > geometry, or (b->pos - contactPoint) can be anything, even larger than the > period itself. Actually, in periodic ScGeom we have no position and n

Re: [Yade-users] Periodic triaxial

> > Hello Bruno, > I am a little bit confused about the periodic. In NewtownIntegrator we > update the velocities and _then_ we integrate the positions. This is exactly > the way of Cundall (I am checking the equations right now) except that he > chooses to update positions and not velocities (defi

Re: [Yade-users] Periodic triaxial

On 28 May 2010 18:47, Bruno Chareyre wrote: > Chiara, > > If you have your noze in papers now, I'll let you think about the code > below (uncommited). The first line is what is in the code already. > Checking with paper and pen, I found that current equation is equivalent > to Cundall/Thornton e

Re: [Yade-users] Periodic triaxial

On 31 May 2010 16:23, Jerome Duriez wrote: > > > Le 26/05/2010 11:08, Bruno Chareyre a écrit : > > >> Chiara, Jerome, and Luc : I got to add one line in your functors, please >> review the change. >> > In which commit ? I did not see any commit (since this 26/05 and r2255 for > example) concernin

Re: [Yade-users] Periodic triaxial

Hi Jerome, > > you are right, there is no change in your files and the commit in question > is supposed to be r2255. The reason is that you are not using functions > contained in ScGeom. I suppose that this choice is linked to the fact you > also handle the MT in your law. __Could not we add the pa

Re: [Yade-users] Periodic triaxial

> > >> I was looking now at your law and actually there is no reason why you >> should not use the function rotateAndGetShear >> > Because I did not know it... Would it change something for the moment > transfer law ? What do you call "pbc" ? > Anyway, I'll try to look at it. > Hi Jerome, no it wou

Re: [Yade-users] Periodic triaxial

> > A body "b" is virtually duplicated in all periods. If the period is > deforming, each duplicate has a different velocity in the global coordinate > system. This is why we have to shift the velocity difference (b1->vel - > b2->vel), in order to define relative velocities as if the bodies were in

Re: [Yade-users] Periodic triaxial

> > Cundall way (as you rightly pointed out) is the following: > > *** update of velocities (he does not, but as you already said this would > be the solution): > vel+=velGrad*vel*dt > *** update of positions: > pos+=(velGrad*vel*dt)*dt > > Currentl

Re: [Yade-users] Periodic triaxial

2010/6/2 Václav Šmilauer > > > One more question. Why do not we move the spheres through the periodic > > boundaries instead of updating their positions? Would this be > > possible? I mean, like treating the periodic boundaries as walls. ATM, > > we use the rule of continuum mechanics to updated

Re: [Yade-users] Periodic triaxial

On 2 June 2010 17:06, Bruno Chareyre wrote: > Hi Chiara, > > I didn't take time to reply as it would need a long discussion. Keep > looking into MD litterature and you should find questions to your answers, > be it in a formalism that is excessively complex. > Ok, sorry I will. > I don't agree w

Re: [Yade-users] Periodic triaxial

On 2 June 2010 17:06, Bruno Chareyre wrote: > Hi Chiara, > > I didn't take time to reply as it would need a long discussion. Keep > looking into MD litterature and you should find questions to your answers, > be it in a formalism that is excessively complex. > I don't agree with your equations be

Re: [Yade-users] Periodic triaxial

> > >> What do you mean as mean field velocity ? >> To report exactly from his paper what he wrote in terms of displacement >> increment : >> >> delta_u = delta_u(real_vel) + gradVel*pos*dt; (1) >> >> >> where : >> delta_u(real_vel) = vel*dt; (vel is from the real particle velocity, hence >> = a*dt

Re: [Yade-users] Periodic triaxial

> delta_u = delta_u(real_vel) + gradVel*pos*dt; (1) >>> >>> delta_v = vel + gradVel*pos; (2) >>> >> >>> >> Heh, no! If you derive (1) vs. time, it will not give (2). >> First, divide (1) by dt to get instantaneous quantities : >> >> du/dt = vel = du_real/dt + gradVel*pos = v_real + gradvel*pos >> >

<    1   2   3   4   5   >