I’ve been playing with UDEC bonded triangular (trigon) blocks to investigate how robbing pillars from a coal mine beneath a 200m high cliff might promote progressive brittle fracture and eventually large-scale toppling. However, I’m running into contact overlap issues.
One the one hand, setting a small tolerance for contact overlap causes cycling to halt before large scale displacements can develop. On the other hand, setting a very large contact overlap tolerance seems to allow many blocks to interpenetrate each other and “fall through” the model.
Anybody have any tips to get around this issue? Or even relevant citations that I could refer to? I note Itasca’s bonded block rock slope example from Checkerboard Creek is executed using rigid blocks; I’d like to use deformable blocks if possible.
I have not used the trigon blocks, but at least for me a typical reason for those contact overlaps is when the contact stiffnesses are much too low (or the stiffnesses for newly found contacts are not assigned at all).
Or sometimes a deformable zone fails rather miserably and explodes into another one, in that case I would check that corresponding plasticity model.
Thanks Markus. In this case the trigon contacts are assigned high normal and shear stiffness based on the old familiar equation relating to block/zone size; attached image shows the values; upper green layer is better quality; jkn = 7.2e10 and jks 1.44e10; lower layer is siltstone/claystone, worse quality, jkn 3.6e10 jks 7.2e9. Also, all trigon blocks are elastic in this model.
Hi Zack, its good to hear from you. Its hard to tell exactly what’s going on based on the figures. My initial thought would be to change the stiffness values, however they seem reasonable to me. How significant are the overlap issues (what magnitude)? You can increase the tolerance (block contact tolerance overlap …) if the overlap is relatively small. Are the overlap issues only where you have excavated the underground mine? Have you set default properties for new contacts (e.g. block contact cmodel default area …)? Regards, David
it would be helpful to see, where the overlap actually occurs. In the old UDEC (version 6 and lower) this could be done with the “plot overlap” command. I’m not sure about UDEC7 but there is probably a plot item or equivalent command.
Other than that I would concur with David and check, whether new contacts have nonzero default properties.
Thanks Markus and David. Attached image shows some of the blocks ‘falling through’ the model, in red, near the base of the model. I had previously set default for new contacts at jkn = 10GPa/m and jks 1 GPa/m, but have now modified and run with a higher stiffness, based on the bonded trigon blocks:
Still, overlap issues appear to be happening. I start with overlap tolerance at 1m. When it halts cycling, I try to delete blocks that have ‘fallen through’ the model for a great distance (block delete range displacement 10,999999999999999999 for example tends to do it). But eventually the overlap occurs in blocks that do not have these huge displacement. I then increase the overlap tolerance; in the attached image, I have increased overlap tolerance to 10m.
It seems like the old option to “plot overlap” is gone now. I looked in the support material, but I don’t see a way that I can conveniently either plot blocks that exceed overlap tolerance, or flag them for deletion with a fish function. If it were possible to flag them with a fish function, then maybe I could delete the offending blocks.
It might be worth mentioning, that - oddly enough - blocks falling through the model sometimes are not even the ones causing the overlap error, since these blocks apparently have not even found a contact with the block they are falling through. And since you mentioned that the problem later occurs in blocks without large displacements I would still suspect some other problem behind it.
there used to be an alternate contact logic in UDEC6 which was invoked by “config cell”, which handled such contact detection problems better. Might be worth a shot, if it still exists in UDEC7
try a comparatively small overlap tolerance (maybe 1 cm or so) and then try to find the error. The model should still be fairly intact by then and it could be easier to detect the problem. Then analyze the contact properties etc. of the offending contact. Maybe this will give you a clue as to why these problems occur.
try deleting based on “extreme” velocities. I don’t know the default update intervals of the contact logic, but maybe some blocks are falling so fast, that the overlap occurs in between updates of block position etc., so that the model can’t react to it in time UDEC7 (just a wild guess)
at last, try to replicate your problem in a extemely simplified version of your model. If you can reduce and reproduce it in a simple test model, it might be worthwile to send it to the Itasca support for inspection.
Can you tell me about the ‘plot overlap’ command? I am using UDEC 6 and I sometimes get the problem of contact stiffness too low when I apply load on a voronoi assembled block. Thank you.
There is not much to it, it simply highlights the overlap region of blocks (console version) and helped me several times in the past. Should be documented in the old manual. Haven’t used UDEC in a while, though.
The contact overlap and the block dropping through the model are two different issues.
The contact overlap is controlled by the contact normal stress and the contact normal stiffness. You can list the contact stresses and displacements and calculate the amount of overlap (stress/stiffness). You can increase the stiffness to decrease the overlap and you can also change the overlap tolerance (though this may lead to more blocks popping through).
The blocks dropping through the model is a result of the contact detection scheme that you are using. The default detection scheme is referred to as domain detection. This logic is intended for closely packed blocks and is not designed to handle the case where a block separates and drops to another group of blocks. Once a block separates from its original domain, it will not ever make contact with another block. The domain separation is difficult to predict and the blocks may stay in the domain over short distances. In that case it may make contact with other blocks in the same domain.
The other logic is the cell logic. This logic is designed for loose blocks moving large distances and forming new contacts.
The plot of block overlaps is a selectable parameter in the block plot item. You just open a block plot and check the overlap error box.
How to remove the block dropping problem in 3DEC 7? Is there any specific command or any way to remove it? Not overlapping, I already increase the stiffness and overlap tolerance. Thank you
Thanks very much for this. I am now looking into running with the cell logic for contact detection and see what happens; also super helpful for the tip to select block overlaps in the plot, I hadn’t noticed that before! Cheers
Please note that the cell contact detection logic does not support fluid logic. So, if you have fluid pressures in your model, the cell contact logic cannot be used.
Thanks very much again all. I just wanted to report that using the alternate “config cell” contact detection scheme seems to have solved my overlap issues (mostly) and blocks falling through the model (entirely), so I’m having fun playing with different permutations of the model and am keen to see what kind of large strain failures can develop! Cheers.
