yade-users team mailing list archive

[Robert Caulk <question660585@xxxxxxxxxxxxxxxxxxxxx>]

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

Robert Caulk posted a new comment:
Dear Bruno,

Thank you so much for taking the time to respond to this thread.
Luckily, my original question has been more than answered and we can all
now agree that updatePositions needs to be set to True if we want a true
two way coupling. So that is good.  But the remesh frequency instability
is odd, and may require some more thought on my side. Anyways, after
going through and trying to reply to your replies to my replies (LOL), I
started to feel that these discussions are becoming too unwieldy for
launchpad :-(. I guess we could try to set up a skype call or something
if we felt the need to discuss this in depth. But here are my answers
anyways.

>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.

Hmmm, so the idea that we are asking a single A matrix to accept a total
perturbation that amounts to N*dt is not a problem? Well, perhaps it is
an issue with the permeability tricking? If we increase pressure in our
fracture, and many bonds break but the permeability is not tricked
(because our remesh step is high), pore pressures will continue to
increase as if the fracture has not propagated. Then, as soon as we do
trick the permeability, we get a pressure gradient that is so high it
requires a smaller time step to maintain stability. Maybe I am grabbing
at straws now. I am not sure how else to explain the instability.

>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 guess it depends entirely on the simulation. I've had some success
with the method, it is currently an option in yade with
flow.breakControlledRemesh=True.  But if I have a few thousand broken
bonds for a simulation that lasts 30000 steps, I would be refactorizing
every 10 steps. That would be prohibitively expensive. I've thought
about adding some logic to the current breakControlledRemesh so that it
waits for 3-10 broken bonds before remeshing instead of 1.

>I was speaking of _not_ remeshing. :)
>Just update cells volumes. It should happen if "defTolerance<0,
>meshUpdateInterval=1e20, updatePos=True".
>Could you try that?

Oh I see, you are suggesting I try this as a way of narrowing down the
source of the instability? I suppose I could, but I would need to turn
off the injection flow rate, or else it would blow up. Without injection
on, the model will be unconditionally stable. Maybe I do not understand.

>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 was just talking about using a separately stored buffer for
triangulation only, and then everything else (volume changes and total
volumes) is computed using the updatedbuffer.

If I am reading the code correctly, in the situation where
updatePostions=True, the RHS reflects volume changes at every timestep
[1] but the total mechanical volume updates are only reflected in the A
matrix every N flow.meshUpdateInterval steps [2]. This is where I
thought the remesh frequency instability was originating when I was
talking about the total perturbation timestep for the A matrix, but it
seems that may not be the case.

Cheers,

Robert

[1]https://github.com/yade/trunk/blob/master/lib/triangulation/FlowBoundingSphereLinSolv.ipp#L328
[2]https://github.com/yade/trunk/blob/master/lib/triangulation/FlowBoundingSphereLinSolv.ipp#L218

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