yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #02919
Re: [Branch ~yade-dev/yade/trunk] Rev 1932: - merge stiffness/inertia control in PeriTriaxEngine and remove periEngine
Sorry, Bruno, I was a little too fast on the reverts...
> If it causes trouble, just tell me and I'll see how to fix it. It was
> not supposed to change anything for you (especially if you work in small
> strains, you should not see any difference). So why do you need to
> revert this?
>
> This is not geomechanics, just "correct" mechanics. It makes things
> consistent.
> - Take real a steel bar and make a tensile test on it. Plot force vs.
> dL/L, it is not linear (even if it looks linear for small strains). Plot
> force vs. log((L+dL)/L) , it is always linear (provided you didn't enter
> plasticity ofc). The same happen in DEM simulations.
> - volume change : with your definition ev!=(e11+e22+e33), with Log, they
> are always equal.
> - apply a strain rate of -10e-2/sec for 50 seconds. Result with your
> strain 0.393 (not equal to strainRate*time!), result with log : -0.5.
OK, it makes sense with velocity gradient, probably. (In small strains,
the 1e-2/sec rate is against the reference size, so it would work, I
think..)
> - with log, there is no upper limit to strain (except the grain
> size/period size condition), you can compress 100, 200, 300%. With your
> definition, e=100% has no meaning.
e=-100% ;-)
> - most users won't notice any difference if they are in small strain,
> you don't need to adapt anything or "think" about it. When "your" strain
> is 0.01, log(1.01)/1 gives 0.0995 (log is just slightly more
> accurate). And if you don't remove the exponential, target will be
> reached exactly.
That's true, ok.
> I'm not removing refSize at all, and I agree on the clear meaning of it
> (size is different, see #1).
> Did it change something for you?
I see now... You removed refSize at few places, but didn't change the
formulas in commentary, so I wan't really sure what you did and didn't
patiently try to understand it first.
It it actually quite clear now: instead of Δl=(σ₁-σ)l₀(A/K) you compute
Δl/l₀=(σ₁-σ)(A/K). In that case, cellGrow should not be called cellGrow
but something like cellRelGrow.
> The current (reverted) code is doing approximately this :
>
> maxGrow = dt*maxRate*refSize;(in meters)
> Grow = targetStrain*refSize;(in meters)
> compare(Grow,maxGrow);
> velGrad = Grow/refSize;
>
> Does it make sense to multiply THEN divide by refSize?!
> I suggested this, simpler and generalised more easily :
>
> maxGrow = dt*maxRate;(in [-])
> Grow = targetStrain*refSize;( in [-])
> compare(Grow,maxGrow);
> velGrad = Grow/dt;
>
> would have been even better :
>
> Grow = targetStrain*refSize;( in [-])
> velGrad = Grow/dt;
> compare(velGrad,maxRate);
I get your point, sorry again.
For reverting my reverts, I think it is easier to so it by hand; it is
about 4 lines for refSize and 4 for log strain...
Try bzr diff -r1935..1936 (or qdiff instead of diff, if you have the
great qbzr package installed) or
bzr qdiff -r1935..1936 pkg/dem/Engine/GlobalEngine/PeriIsoCompressor.cpp
to get just that file.
> #1. I'm currently working with the polar decomposition of F to define
> proper stretches and rotations. It is the only way to define a "size"
> without rotational artifacts for e.g. simple-shear (note that simple
> shear is the most interesting non-axis-aligned loading, pure shear makes
> no sense since it is just a classical triaxial test performed on rotated
> box).
>
> It almost work, and it allows shearing the cell forever without reaching
> the "2*halfsize>size" limit. It simplifies many parts in the code
> (collider using period of lengths refSize instead of getSize...). Should
> I commit this to trunk without copy/paste? You will not revert it the
> day after? :)
I am quite sure the collider doesn't like that. How does it work?
Currently Cell::_size is (to my knowledge) computed without rotation
artifacts, I checked that with rotating the cell completely around and
it didn't deviate a bit from the original size.
> I'm, looking forward for Anton's guidelines in order to set kdevelop
> indent mode. There should be a way to commit this setting in
> trunk/yade.kdevelop.
I am afraid he will write different things than how I write code and I
will have to quit yade development ;-)
v
Follow ups
References