Hi there,
I do not know if there is any of you who have already dealt with the illegal geometry error when running a simulation in large mode. One of (if not the only one) of the solutions is to do a remeshing. I know the principles but I have no idea about how to implement the remesh process especially the transfer of informations from the old grid to the new one. Is there any guide or any sharing of some files in case someone has already done this.
Thank you!
Hi sebastien,
your question is very broad, so I’ll only give a couple of pointers first:
Remeshing is relatively hard and to my knowledge there is no built-in remeshing capability directly in FLAC3D. Using Fish/Python it is however (in principle) possible to remesh defective zones and copy/interpolate state informations from the old zones to the new ones, but it is tedious (at least from my personal experience).
For larger remeshings you could in theory also use Griddle to remesh and apply a similar state transformation using Python.
Most importantly, in 90% of the cases of illegal geometry errors I have been asked about, the problem was much more on the user side, so that the large deformation was only the result of bad parameters and/or e.g. carelessly excavating material (leading to unphysically high loads). So therefore - and since you have given no further info - I would also suggest that you make sure, that this is really a “understandable” large-strain error.
Hi Sebastian,
I am actually facing the same thing right now after leaving my model running over night, the “model large-strain” command was off, got that error (snapshot). Re-meshed the solids more and more in Rhino via Griddle nothing seems to change. @markus what could be the issue? my model cycled through until it reached the excavation stage that when it presented that error.
That is indeed odd, since (model-driven) changes to zone geometry should only occur in large-strain mode. Are you absolutely sure, that this is the exact command set used for this error (because I see a lot of commented out stuff)?
Wild guess: I see a (commented) zone geometry-tolerance command with a rather large value. Maybe with that value even your undeformed mesh no longer qualifies as “legal”. Did the error occur immediately at the start of cycling? Can you show that particular zone in a plot?
Maybe this should be a separate topic or a support case for Itasca, if you can e.g. reproduce the problem on a smaller sample model.
PS: Also, the solve command seems a bit short, since it will always terminate after 1000 steps (without regard for the solve ratio), which rarely is enough.
@markus yeah, the commented commands are as they are, not part of the analysis. How does one show that particular zone of error in a plot?
@markus, yeah it occurred after the model reached equilibrium during the excavation stage (cycling) and all the commented out commands were for a different analysis.
Either zone hide and zone hide off range id XXX or by using the ID List Range Item in the Plot.
Hi @markus
This is actually an understandable large-strain error. As a matter of fact I am modeling a penetration inside a soil. This is a large-strain problem and I run it in large mode.
And as it is in the context of an intership, I don’t have time to really tackle the problem of remeshing. Moreover I a new user of FLAC, remeshing is tougher for me than for an experienced user.
HI @RockEugieK
It is weird to error this out with the large strain mode being off. Usually it happens in large mode on, when a tetrahedron inside a hexahedron is so distorted that it approaches a flat surface.
FLAC (the 2D version) has automatic remeshing as far as I know, so maybe that would be an alternative if you can reduce your problem to 2D. Sometimes a numerical code is just not suitable for a particular class of problems. So maybe use PFC / Discontinuum mechanics if your soil is so “soft”?
Actually I cannot reduce it to 2D; I’d already do it.
Also, I am using a soil right now just as a test, to get used to the software. But the project is about a rock actually.
At the end of the day, I am in hot water.
Hi @RockEugieK,
The error you get is indeed strange, it should not appear in the small strain calculations, unless there is initially degenerate mesh (in FLAC3D sense). Maybe some elements in your mesh are really close to being degenerate and the error appear randomly due to machine/round-off errors. You mentioned that you tried various meshes from Griddle, does this error appear for any/specific of the meshes?
Also, looking at the datafile, limiting cycling at 1000 step is a bit strange for real/big model. Also, how big is the excavation region? Maybe it is better to use zone relax excavate command?
If the erorr persists, consider submitting support request.
@apyatigorets thank you. Will try that, the only thing is when I use the “zone relax excavate range group” it doesn’t usually excavate the region in the model, that’s the reason i use the “assign null range group”.
@apyatigorets …yeah, the "zone relax excavate " removed that huddle. But, the simulation failed to create voids in the excavations.
The zone relax excavate gradually reduces stiffnesses, stresses and densities in zones and sets the zones to null model when the reduction has reached zero. Apparently that has not happened yet in your simulation, probably because your are still not cycling enough steps. You can further specify within how many steps that excavation shall occur. Please refer to the manual on that command.
What was the exact command you have given?
I had similar experience and found the solution. You might find it useful.
It once happened to me for the small strain case and I realized there was unattached zones with duplicate gridpoints in the geometry. The issue was from the mesh generated in the third party program. I used the following commands to force program to merge the gridpoints and attach the coplanar faces.
zone gridpoint merge
zone attach by-face
I think the zone gridpoint merge could be a good trial. I will try it and hope it works. Thank you @roozbeh!
Also make sure “zone attach” command is also executed to make sure the faces between two zones with discontinuities are rigidly attached. Like location pointed at with arrows in previous figure.
@apyatigorets might have to submit a support request 
