Updates to several overset update routines

[anilyil]

Purpose

This PR contains several changes to the overset cutting algorithm. These can be grouped as:

1. Surface Callback Tracking: In Several features on tecplot io, slices, MG PC, cavitation constraints, and overset hole cutting. #231, I introduced a new way to do the overset hole cutting. This method introduced the use of blanking surfaces that can be used instead of the regular flooding algorithm for difficult cases. In the current PR, I cleaned up that code a bit and enabled "DVGeo tracking" for these surfaces. So as the main CFD mesh is deformed, the blanking surface is deformed consistently. This is useful when we need to re-run the full overset update after geometry changes. The DVGeo embedding is done in an embarrassingly parallel way because this blanking surface is duplicated on all procs.

2. Changes to explicit surface cutting: Again, the feature mentioned above uses an algorithm under the hood to determine which cells are "inside" the closed surface. When these blanking surfaces are thin and they cut large cells relative to their thickness, some cells might slip from the cutting algorithm. To fix this, in this PR, I modified how the cells inside the surface are tagged. I first project the cell centers to the blanking surface. If the projection distance is greater than the max diagonal length of the cell, I end the test for that cell. If the projection distance does not satisfy this condition, we then check if the vector from the cell center to any of its vertices can potentially intersect the surface. If so, this cell is explicitly blanked.
   Compared to the old algorithm, this is a more conservative check; however, based on my experience, this approach produces good results and is not overly-conservative. The cells that are tagged should not be included in the solution anyways.

3. Added 2 new options regarding overset updates:

• updateWallAssociations: Enables updating the wall associations when geometry is updated, even when we are using the approximate wall distance routines. The overset meshes can only use the approximate wall distance routine, but before this PR, it was hard coded to always keep associations. In this PR, this behavior can be controlled by the user.
• recomputeoverlapmatrix: In the full overset update mode, the block overlap matrix was not re-computed. If either the deformations are large, the CGNS block has many blocks, or both, this overlap matrix needs to be re-computed to get a valid hole cutting. In case someone still wants "efficient" full overset updates with small changes, they can use this option to disable the update. The default is set to True because it is somewhat likely for the overlap matrix to change when the mesh has large enough deformations that necessitates a full overset update.

4. Updated how orphan cells are written to the CGNS volume file: Back in 2018, I added the capability to write a -5 for the cells that were considered as orphans in the hole cutting: fe9a015 However, I don't think this check was correct. There are actually two checks in that routine; the first check is for connectivity problems of compute cells. I think this check is triggered sometimes incorrectly for non-regular CGNS domain topologies (3, 5 point singularities etc). This check is where I was tagging the "orphans". However, I don't think this is the right definition.
   The following check is following the same logic in reverse; it starts from cells that are not compute or interpolate, and goes 2 cells in each direction. If a cell within this "radius" is compute, that cell is called an orphan cell.
   In this PR, I changed the orphan cell definition to be consistent with the second check. That check's result is what is printed as "number of orphans", and my old code would write more "orphan" cells in the volume solution than what is printed, causing confusion.

Unfortunately, I don't have tests for these routines. I am still planning to add some overset tests that go through all of these, but that will require some thinking and time. Until then, it would make my life a lot easier if we merge these changes.

Expected time until merged

1-2 months

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (non-backwards-compatible fix or feature)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Documentation update
• Maintenance update
• Other (please describe)

Testing

Checklist

• I have run flake8 and black to make sure the Python code adheres to PEP-8 and is consistently formatted
• I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
• I have run unit and regression tests which pass locally with my changes
• I have added new tests that prove my fix is effective or that my feature works
• I have added necessary documentation

[codecov]

Codecov Report

Attention: Patch coverage is 25.67568% with 55 lines in your changes missing coverage. Please review.

Project coverage is 41.13%. Comparing base (b306045) to head (defb226).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
adflow/pyADflow.py	25.67%	55 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #330      +/-   ##
==========================================
- Coverage   41.42%   41.13%   -0.29%     
==========================================
  Files          13       13              
  Lines        4063     4108      +45     
==========================================
+ Hits         1683     1690       +7     
- Misses       2380     2418      +38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sseraj]

Great changes! I tested the new explicit hole cutting algorithm on my mesh and can confirm that it is more conservative but also more effective. I just have a couple of comments

[eirikurj]

Sorry for the delay on this. Please seem my initial comments. At the moment, I dont have an overset mesh to test these changes right now. I think adding tests, even just some simple regression tests that touch this code, if possible, would be great.

[eirikurj]

Seems like this should be checked before the loop as nothing is done but run the loop otherwise. This should also not be necessary if IDs are checked upfront.

[anilyil]

moved the check to cover the blocks after cellID is computed.

[anilyil]

@eirikurj I addressed your comments. I don't think I can add the overset tests now due to workload and this PR has been waiting for a long time already. I do want to add a series of overset tests but it would be great if we can do it separate from this PR.

[anilyil]

@sseraj can you take a look at this again? I don't think there were many changes since last you checked.

Would it be possible for you to test if your grids initialize? No worries if not.

[sseraj]

Yes, I'll take another look at this and try to run my case as well

[sseraj]

The changes look good, and my case still runs the same as when I approved this PR previously

[sseraj]

Feel free to merge this (I would, but I took myself out of the maintainers group)