Improved Slices and Inverse Design

[anilyil]

Description of feature

We want to improve slice processing in ADflow and expose the slice-based computations to the Python layer with derivatives so that we can include functions based on the slice data in optimizations. These features will address the following needs:

• The twist and chord distributions in the "lift" file are not very accurate. The twist especially can have noise due to the LE node jumping around.
• It is difficult to access detailed slice data in runtime. We can use these slices to determine a more accurate reference axis for cases with extreme dihedral.
• We want to perform inverse design.
• We want to be able to constrain individual slice coefficients (like CL) instead of the global coefficients.
• We want to be able to constrain pressure gradient over certain sections of the airfoils.

Right now, all slice processing is done in Fortran in ADflow. This makes it very difficult to modify the code to include these advanced features. However, the Fortran layer is very useful to actually perform the slicing over the distributed mesh and communicate across processors.

Planned Solution

I want to modify how slices are processed in ADflow by exposing the raw slice data to Python. Then, we can order and format the slice data. We can also provide a derivative seed routine for the slices so that whatever derived functions computed with the slice data can be propagated back across the fortran code. Finally, we can also perform more accurate geometric postprocessing operations in Python such as detecting the leading edge point, LE radius, etc.

I want to implement an adflow slice class in python that contains all of the computations based on the raw slice data that comes from fortran. Using these adflow slice instances, we can also compute more accurate spanwise distributions. Finally, we can create modified tecplot outputs from the python layer that contains the correct twist distributions, and any of the constraints we may have prescribed over the slice itself.

For now, I say we keep the development in the ADflow repo. If the resulting code is general enough, we can move it elsewhere, and only maintain a basic slice API in ADflow.

Roadmap

I will work with @lucaeros and @bbrelje for the implementation efforts. Also tagging @lamkina because he usually has good ideas about how these things should be implemented. I suggest we use a project board in github to keep track of individual tasks: https://github.com/orgs/mdolab/projects/14/views/1 Regarding development, we can either create a feature branch on mdolab/adflow or we can use a branch in my fork.

[anilyil]

The first thing we should do is add the python class that takes in the raw slice data and sorts it etc. We can assume the raw slice data will be in the same format as the slices in the slice.dat output files. So until I implement the fortran routine that returns the raw slice data, you guys can assume the incoming data will have the same ordering and same variables etc.

Also, do we want to set up a quick discussion call with everyone to get this going? Does Tuesday June 6th 9am work for everyone?

[anilyil]

I created a new branch: https://github.com/mdolab/adflow/tree/slice_mods Everyone involved can create a branch in their fork and we can merge changes with PRs to the mdolab/slice_mods branch

[bbrelje]

@anilyil timing works for me, hmu with details at umich dot edu

[anilyil]

We will want to have developments happening on slice_mods branch in each developers' forks, and we will merge changes through PRs to mdolab/slice_mods branch. Once the feature is ready, we will create the final PR from mdolab/slice_mods to mdolab/main.

Follow these steps to set up a fork with a feature branch that copies mdolab/slice_mods:

1. Fork ADflow if you haven't already. This is done on github.
2. Clone either your fork of ADflow, or mdolab/ADflow locally.
3. Set up your remotes in the local repository; you want to have "origin" pointing to your fork on Github, and a fork called "mdolab" to track mdolab/adflow. See this page for how to do that: https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories
4. Fetch the mdolab fork with git fetch mdolab
5. Checkout the slice_mods branch with: git checkout -b slice_mods mdolab/slice_mods This will create a local branch that tracks mdolab/slice_mods.
6. Set the upstream repo of this local branch to be your origin and push to your fork with: git push --set-upstream origin.

The steps 4-5-6 are not really necessary but it is good practice for someone following along after the fact. This makes sure the development branches on each fork is based on the same development branch in mdolab/adflow.

As you develop the code, keep committing your changes to the slice_mods branch locally, and push to your fork. Once a feature is ready, create a PR to mdolab/slice_mods branch on github.

To merge latest changes from the mdolab/slice_mods branch, first fetch the changes with git fetch mdolab and then merge with git merge mdolab/slice_mods.

I will try to keep this development branch up to date with other developments happening in the mdolab/main branch.

[lucaeros]

I open a PR for the slice_mods. Includes sorting of the connectivity, detection of upper TE, lower TE, TE and LE. Now, need to detect nodes of upper skin and lower skin

[anilyil]

@bbrelje and @lucaeros, I have added the first python and fortran interface to interact with active slices. The PR is up here: https://github.com/mdolab/adflow/pull/296 I also merged 2 of the latest commits in main. My changes are in a single commit in the end if you want to take a look at those alone.

I have attached an example script in the file as well.

I currently return the data as a dictionary but we can just put it in the airfoil class. I suggest the following:

• @lucaeros, can you modify the airfoil class so that the initialization can either be with a file, OR, initialization just initializes the instance w/o any data saved. We would do this when the active slices are added. Then, when the getActiveSliceData is called, we can put the fortran data into the class and run the updates. Basically, separate out the class initialization from the initial computations.
• @bbrelje when you are adding the eval funcs to the slice class, think about how we would call them in pyADflow's evalFunctions. I can take care of this as well, but I have limited time because the string conversion between fortran and python took sooo long.

One important caveat here: The fortran slice data contains 3 coordinates, 3 pressure tractions, and 3 viscous tractions. Then it contains the surface output data, cp, mach, p, etc. This is different than what the slice files have, 3 coordinates, 3 relative coordinates, and surface output. @lucaeros, we need to account for this difference in the slice class. I say you can completely ignore the XoC YoC ZoC from the slice file because you get a more accurate chord computation anyways.

Plus, now that we have all 6 tractions, we can compute lift, drag, and moment for the airfoil from python, and directly constrain it!