← Back to team overview

yade-dev team mailing list archive

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