How to know why a cell got deleted?

[mojtabaAmiraslanpour]

Hi,

This is a topic that I have been trying to find out for a while now. I understood that a cell gets deleted whenever a particle of that cell has an ID of -1. Here is the relevant code snippet:

int HemoCellParticleField::deleteIncompleteCells(const bool verbose) {
  int deleted = 0;
  const map<int,vector<int>> & particles_per_cell = get_particles_per_cell();
  //Warning, TODO, high complexity, should be rewritten 
  //For now abuse tagging and the remove function
  for ( const auto &lpc_it : particles_per_cell ) {
    int cellid = lpc_it.first;
    bool broken = false;
    for (pluint i = 0; i < particles_per_cell.at(cellid).size() ; i++) {
      if (particles_per_cell.at(cellid)[i] == -1) {
        broken = true;
        break;
      }
      ...

I understand that this part of the code deletes cells if any of their particles have an ID of -1. However, I am having trouble finding where this assignment (ID of -1) actually occurs in the code. My cells are being deleted without an obvious reason, and I'm wondering if it might be due to high velocity or some other factor. Could you help me identify which function is responsible for assigning the ID of -1 to particles?

I appreciate your assistance.
Thank you.

[gzavo]

Hi @mojtabaAmiraslanpour,

Just to check, you are also using the cellsDeletedInfo tag, right?

HemoCell/scripts/ci/config-pipeflow.xml

Lines 4 to 6 in d916987

	<verbose>
	<cellsDeletedInfo>0</cellsDeletedInfo> <!-- Give information about the location of deleted cells, this option impacts performance -->
	</verbose>

This is in the depth of some old code, but as I recall the mechanism:

• particles (vertices of a cell) have a -1 tag by default.

  HemoCell/core/hemoCellParticle.h

  Line 136 in d916987

  tag = -1;

• cells with any particle that has a -1 tag get deleted in:

  HemoCell/core/hemoCellParticleField.cpp

  Line 469 in d916987

  int HemoCellParticleField::deleteIncompleteCells(pluint ctype, bool verbose) {

When a cell is too stretched out (larger than the communication envelope), particle information will not get transferred to outlying particles, leaving the default -1, which will then result in the deletion of the cell.

The most typical reason is too large forces: for numerical stability, force is capped:

HemoCell/core/hemoCellParticleField.cpp

Lines 847 to 852 in d916987

	// Capping force to ensure stability -> NOTE: this can introduce an error if forces are large!
	#ifdef FORCE_LIMIT
	const T force_mag = norm(particle.sv.force);
	if(force_mag > param::f_limit)
	particle.sv.force *= param::f_limit/force_mag;
	#endif

Which means particles will travel with the flow, because the capped material force is not enough to counteract the flow, and they will stretch out and become deleted eventually.

I also recall that this transfer only happens from the fluid domain, so if a particle penetrates a wall it will also get deleted, but I don't see this in the code atm.

Hope this helps somewhat. The bottom line is, don't look for explicit setTag(-1) that mostly exists in legacy code parts.

[mojtabaAmiraslanpour]

cellsDeletedInfo

Thank you for the response @gzavo

Yes, I am using the cellsDeletedInfo tag.

Your response was pretty helpful. I can now see how the cell deletion works. In the case that I am simulating, RBC would experience large deformations which would eventually be larger than the communication envelope and thus get deleted probably by removeParticles_inverse in HemoCellFields::syncEnvelopes(). That is a guess since I haven't tested this.

Can enlarging the particle envelope cause any problems in the simulation? Let's say I expect the RBC to have large deformations. How should I avoid cell deletion in this scenario? Is enlarging the envelope, a solution?

[gzavo]

Enlarging the envelope can help. Just be careful, that if the deformation is high and the arising forces get capped (say at 50 pN), the results might no longer be realistic.
The downside of larger envelopes is slower execution (due to more communication and larger computer volume). If the envelopes are larger than the atomic block size the performance will really suffer, since atomic blocks will need to communicate with not just next neighbors, but next-next neighbors, etc. The cost grows as O(x^3).

[mojtabaAmiraslanpour]

Thank you for the suggestions. I finally got it working! A larger force cap was the solution.