Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faces become deformed and can overlap #269

Closed
Lepinja666 opened this issue Apr 18, 2023 · 3 comments
Closed

Faces become deformed and can overlap #269

Lepinja666 opened this issue Apr 18, 2023 · 3 comments

Comments

@Lepinja666
Copy link

I've noticed that sometimes when running a simulation, faces can become weirdly shaped and start overlapping with one another. This doesn't happen often so it's hard to debug it and I'm not sure whether it is a consequence of a cell division, cell death or T1 transition. The resulting tiling looks like this (a couple of examples):

problematic

Has anyone ever encountered this and managed to debug it?
Thank you in advance!

@btbest
Copy link
Contributor

btbest commented Apr 20, 2023

I had the same thing happening in my simulations, but never dug deeper since I took it as an indication that I have an underlying problem with the sanity of the conditions I'm simulating.

I remember getting import warnings about the collision detection, so it sounded to me like there is some functionality of that kind in tyssue. Although judging by the warnings, it wouldn't have worked for me because I was on Windows and I would've had to figure out how to compile that module for my OS.

Without collision detection, there's nothing constraining your vertices in space besides the energy or force function that you've put on your edges. Sometimes the energy minimiser can drop into a local minimum that doesn't make a lot of sense, even if it is mathematically correct. Since you mention T1 transitions, I take it you modify the graph during the simulation, in which case indeed this could also be a bug due to nonsensical edges coming out of the rearrangements.

In terms of debugging, I never found any other way than to manually identify the ID of the perpetrating face and then backtracing what happened with it throughout the iterations...

@sophietheis
Copy link
Collaborator

When I encounter this kind of thing, I tend to reduce the values of my parameters to "slow down" the movements. Also, regarding T1 transition, you can try to increase a bit the threshold_length parameter. If I remember correctly the default value is 1e-3, which can be too small and increase the probability to obtain this weird shape.

I think what happens to get this result is shown in the issue #184. It also proposes a solution but it has not yet been implemented.

Regarding the collision detection module, warnings during the installation are probably related to CGAL and/or C++. Collision detection was used to avoid collisions in 3D. I have no idea how it would react in such cases in 2D, as I never tested it. However, we found recently that it does not always work as expected in 3D, as we found some problems... So, I will not focus on this solution. :)

@Lepinja666
Copy link
Author

Thank you both for the extensive answers :)
The threshold_length really does make a big difference. If it is about a third of the average edge length the problem occurs very rarely and if it is about a fifth of the average edge length it occurs in almost every simulation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants