codecov[bot]
commented
11 months ago 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 :warning: |
Additional details and impacted files
```diff @@ 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 ```:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
anilyil
sseraj
Purpose
This PR contains several changes to the overset cutting algorithm. These can be grouped as:
Surface Callback Tracking: In https://github.com/mdolab/adflow/pull/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.
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.
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.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: https://github.com/mdolab/adflow/commit/fe9a0159e8d1d46519b662c2cf79f2ca3baad4b7 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
Testing
Checklist
flake8andblackto make sure the Python code adheres to PEP-8 and is consistently formattedfprettifyor C/C++ code withclang-formatas applicable