Several features on tecplot io, slices, MG PC, cavitation constraints, and overset hole cutting.

[anilyil]

Purpose

This branch of ADflow has some features I needed for different projects here and there, and the changes are getting out of hand. I will break down the changes to 3 large groups, and then there are some smaller fixes:

1. TecplotIO and Slices

• TecplotIO is restructured a bit to calculate the sectional moment coefficients about the local slice's quarter chord. This will likely result in garbage numbers when slices contain two or more closed curves (instead of just a single airfoil section), but the code should run regardless. It looks like I defaulted to using quarter chord (xFrac=0.25) for these calculations. I can add this as an option in this PR.
• pyADflow is modified to allow arbitrary slices of the geometry. On top of the default custom family name and direction, users can also provide points and normal vectors that define the planes they want to slice through. An example use case of this involves getting the points and normals out of a pygeo reference axis (the axis's value and tangents evaluated at a range of spanwise locations will give the points and normals, respectively). This approach is useful when users want slices that is not exactly aligned with one coordinate frame, but maybe something that follows the dihedral of the wing.
• pyADflow and TecplotIO is also modified to allow for cylindrical slices. With this approach, we pass another parameter that controls which side of the surface we should be slicing; If you have a rounded but hollow geometry like a nacelle, this approach can be used to define slices that propagate outwards from the center line of the nacelle. The code simply uses the same arbitrary slicing interface (point and normal), but also we need to provide which direction to pick. The surfaces going through the center axis will intersect a closed nacelle in 2 locations, and with the current implementation, only one side is kept, and this is controlled with the range of angles of the cylindrical slice.

These changes are in:

adflow/pyADflow.py
src/f2py/adflow.pyf
src/output/tecplotIO.F90

2. New CpMin Cost Function for Cavitation

I added a new way of do cavitation constraints, that use a KS-based aggregation to compute the minimum Cp over a given surface family. The true min for a surface family is computed by looping over its cells before the surface integration routine, and then the regular integration routine adds up the contributions. Unlike the previous cavitation constraints, this is conservative (i.e. the cpmin outputted will never be less than the true cpmin).

There is a new cost function that is called cpmin that outputs the KS-aggregated minimum Cp over a surface family. Similar to the cavitation cost function, this is only computed when the ADflow option computeCavitation is set to True. The default is false because at least the cpmin computation introduces a global communication right before the surface integrations, which potentially slows the code down slightly.

These changes are in:

adflow/pyADflow.py
doc/options.yaml
src/adjoint/outputForward/surfaceintegrations_d.f90
src/adjoint/outputReverse/surfaceintegrations_b.f90
src/adjoint/outputReverseFast/surfaceintegrations_fast_b.f90
src/f2py/adflow.pyf
src/inputParam/inputParamRoutines.F90
src/modules/constants.F90
src/modules/inputParam.F90
src/solver/surfaceIntegrations.F90
tests/reg_tests/refs/cavitation_tests.json
tests/reg_tests/reg_aeroproblems.py
tests/reg_tests/test_cavitation.py

3. New Overset Blanking Approach

Overset algorithm has a new way to do explicit blanking. With the new approach, users provide a closed surface (or a closed surface except for the symmetry plane) and then a list of the block IDs that we want to blank. Then in fortran, we figure out which cells in these blocks have any nodes that fall inside the provided surface. If any node is within the surface, we explicitly blank the cells. Multiple surfaces with different combinations of block IDs can be used. This approach helps a lot with cases where flooding is practically impossible to prevent due to the unique features on geometries. The "nodes in surface" approach is not exactly how flood seeds are computed; however, it is a good enough surrogate. The remaining cells may contain a handful flood seeds, but in the provided blocks at least, there should not be any more flooding happening since we explicitly blanked cells that are inside the surfaces. Ultimately, we also might want to have the option to disable the flooding in certain blocks, and the new flood seeds can just get tagged as explicitly blanked cells. The benefit of this is explicitly blanked cells force 2 fringe layers, so the algorithm knows which cells to try as interpolate first.

These changes are in:

adflow/pyADflow.py
doc/conf.py
doc/options.yaml
src/f2py/adflow.pyf
src/overset/oversetAPI.F90

Other Changes

• The multigrid preconditioner was missing some calls that prevented its use with coupled ANK. These are fixed now. The PC is not that well tested still and its limitaations are not clear to me, but it does result in speedup with large cases. Coupled ANK variants work with the mgpc now.

In:

src/adjoint/adjointUtils.F90

• The automated PC lagging algorithm was updating the PC too frequently when coupled ANK was used, and especially near the final stages of convergence. To prevent this manually, I added a new option called ANKPCUpdateCutoff.

In:

adflow/pyADflow.py
doc/options.yaml
src/NKSolver/NKSolvers.F90
src/f2py/adflow.pyf

• I also added another option that forces second order ANK to keep using the approximate turb terms called ANKUseApproxSA.

In:

adflow/pyADflow.py
doc/options.yaml
src/NKSolver/NKSolvers.F90
src/f2py/adflow.pyf

• Overset initialization output is changed to have the connectivity errors printed optionally. I usually don't get too much value out of these since we have the cells with missing connectivities written to the volume CGNS. So now, unless the user asks for it, the connectivity errors are not printed.

In:

adflow/pyADflow.py
doc/options.yaml
src/f2py/adflow.pyf
src/modules/inputParam.F90
src/overset/oversetUtilities.F90

• Added an AVX2 version of the intel config file.

In:

config/defaults/config.LINUX_INTEL_AVX2.mk

• Fixed the comments in some fortran and python files.

In:

src/solver/actuatorRegion.F90
tests/reg_tests/test_actuator.py
tests/reg_tests/test_error_estimation.py
tests/reg_tests/test_solve.py
tests/reg_tests/test_solver_combos.py
tests/reg_tests/test_time_accurate_naca0012.py
tests/reg_tests/test_time_spectral_naca64A010.py

• Updated gitignore.

In:

.gitignore

Expected time until merged

Before we merge any of the fortran styling changes.

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

I will try to add tests for individual features but not sure if I can cover them all.

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

[eirikurj]

Very good additions! Just a few minor comments.

[eirikurj]

For consistency and wherever possible, lets try to stick to camelCase here and elsewhere (many other locations)

[anilyil]

Do you mean we need to use camelCase even for variable names? Also, I think the recommendation in some styling guide was to use underscores within variable names and methods, and only camelCase in the class names. Obviously we are not using this convention. If you want me to change the pyADflow variable names to camelCase, I can make that change. Just wanted to confirm that this is what you want me to do.

[eirikurj]

I think you are referring to is the python (or PEP8) style guide. Until we decide something else, we should be as consistent as possible with the current convention, which is camelCase for everything (both python and Fortran). I know its not perfect camelCase throughout, but we should make an effort to keep things consistent.

[anilyil]

okay, I will change the python to camelcase. Fortran is already not perfect and stuff like ANK and NK solvers always start with ANK_ or NK_. I prefer having underscores everywhere, but especially in fortran since it is not case-sensitive. For python, camelcase is fine. I will post and update when I complete the change.

[anilyil]

I have changed all instances of underscore based naming that I could catch. This also requires a small PR on pygeo to be merged: mdolab/pygeo#169 please review and approve soon. I don't want to further delay this PR.

[eirikurj]

Ok, I buy in some case its beneficial of having an underscore for readability. I haven't checked all fortran changes, but I am fine with the ANK_ etc. However, as a general rule, I think we should stick with camelCase.

[eirikurj]

I looked through the code and I think there are still variables that could be changed to camelCase. For consistency, I would prefer that we follow the existing style in files that are updated. Also, with the python interface, the matching the variable name style would be great. Dont want to make this too big of a deal, perhaps others have a different option.

[anilyil]

I addressed the low-hanging fruits @eirikurj. I have left a few questions for you to make sure I got them right. Once you confirm, I will make the remaining changes.

[anilyil]

I created 2 issues that keeps track of the missing documentation/testing from this PR. The overset hole cutting in #251, and slice documentation in #250. These are to address comments by @sseraj and @eirikurj.

[anilyil]

@eirikurj, see this commit: 828f0b1 for the changes regarding to reducing code duplication for slices. At the end of the day, there's not that much code duplicated, so I decided to just gather them in a small preprocessing routine. All 3 slice routines do fairly different stuff, and I would either have if checks all over the place in a common routine, or reduce some functionality from the cylindrical slices. I think what I have right now is a good compromise.

[eirikurj]

@anilyil I am approving now since I think this is functionally very good and I dont want to delay this more. I think the code style could still be improved, but we can address this and others later.

[anilyil]

Sounds good, I created an issue to keep track of the discussion: #252

I will review the code one last time myself and merge.