yade-users team mailing list archive

[Bruno Chareyre <question660585@xxxxxxxxxxxxxxxxxxxxx>]

Question #660585 on Yade changed:
https://answers.launchpad.net/yade/+question/660585

Bruno Chareyre posted a new comment:

On 11/27/2017 07:32 PM, Robert Caulk wrote:
>
> Trial and error show that there is indeed a stability threshold
> associated with the remesh interval. I suspect that the compressibility
> term in question (the one that is essentially ignored when we
> updatePositions=False), is increasing the maximum eigenvalues of our A
> matrix (since adding a term like this can only increase the distortion
> of the system). Higher eigenvalues means a lower required time step.
updatePositions=False means a one-way coupling, which is indeed more 
stable than updatePositions=True (two-way).
However the stability condition is in terms of timestep, not meshing 
frequency. The origin of the dependency vs. remeshing is unclear to me.

> I do see that Catalano looked at using a parameter based on pore volume
> change to control the retriangulation frequency (Eq. 5.13 of [1]).
Yes, but that is just an accuracy requirement, not related to stability. 
We never found instabilites by not remeshing.
For instance the oedometer.py consolidation will work like a charm if 
you make it run from begin to end with the same mesh.

> I suppose we could use a smaller threshold, but still, I'd
> rather just update as soon as cells perms are tricked.
You are right, "as soon as a crack occurs" is the best option. A problem 
is that in large problems it implies remeshing  virtually at every 
timestep, which is prohibitively expensive.

> I should also mention here that Catalano's max FlowEngine timestep based
> on particle density, diameter, and fluid viscosity (Eq. 4.20 of [1])
> seems to overestimate the time step by a couple orders of magnitude for
> my hydraulic fracture stimulations. Or perhaps I didn't implement it
> right...
In the settings of Catalano I believe the equation is correct, and 
Oedometer.py should confirm that.
I would have to understand your settings in more details. 
Permeable/impermeable matrix? compressible/incompressible fluid? update 
positions or not?
Are you really in a viscosity dominated regime (else the timestep is as 
determined by GlobalStiffnessTimeStepper)?


>
>> There is in fact no need to change the code to achieve "update positions always and re-triangulate never". It should be enough to set defTolerance<0, meshUpdateInterval=1e20 (*), updatePositions=True. Or does it give problems?
> This would not work in the current code, since the remeshing also goes
> through and checks for new cell perms to trick as bonds break
I was speaking of _not_ remeshing. :)
Just update cells volumes. It should happen if "defTolerance<0, 
meshUpdateInterval=1e20, updatePos=True".
Could you try that?

> I spent a good amount of time testing different methods for keeping a 
> special positionsBuffer for triangulation only, and allowing the other 
> positionsBuffers to keep doing their duty for updating volume changes.
It seems we have diverging visions of this question. From now on let's 
assume that we always have  updatePos=True.
In this situation positionsBuffer is updated at every iteration and it 
is used to determine the volume changes at each iteration.
Whether or not remeshing occurs is a completely different question, even 
if it uses the same "bufferized" data. The idea of having two distinct 
buffers is still another independent aspect related to task parallelism, 
and actually it provides only a limited speedup.

> I ran into some multithreading headaches for some methods, and just 
> annoying unexplainable bugs for others. Anyways, the current scheme 
> works if we just updatePositions and remesh at a shorter 
> interval...albeit at the expense of the Delaunay retriangulation only 
> (how much does Delauany triangulation even cost...doesn't seem like 
> much). 
Triangulation is fast compared to Cholesky factorization (CGAL also made 
the triangulation parallel recently, which I did not try to use yet). It 
means that tricking just one permeability without changing the mesh 
(thus implying a full new Cholesky decomposition - unless advanced 
methods enabling factors updates are applied) costs nearly the same as 
remeshing (which also implies one Cholesky pass).

Could you show a basic example script with your typical settings?

Cheers
Bruno

-- 
You received this question notification because your team yade-users is
an answer contact for Yade.