Add ADflow component about mphys HOT 11 CLOSED

Updated results with 'L2convergence' = 1e-12. With and without OpenMDAO are identical:
CL = 0.4176802775988083
CD = 0.01680860053911218

from mphys.

Since the flow solver is tightly connected to the warping, the first implementation will have a single solver component that does the warping and flow solver.

There will be a 4 total components:

1. AdflowMesh (ExplicitComponent) - gets the partitioned aerodynamic surface mesh to pass to the transfer schemes and potentially a shape parameterization component.
2. AdflowSolver (ImplicitComponent) - does the warping then solves the flow
3. AdflowForces(ExplicitComponent) - integrates the forces on the aerodynamic surface
4. AdflowFunctions (ExplicitComponent)- should be able to use the adflow function evaluator from the adflow repo.

from mphys.

This work being done on the 'adflow_comp' branch

from mphys.

• Run the aero machtutorial wing case with the OpenMDAO components
• Run the aerostructural mach tutorial case with the OpenMDAO components
• Verify sensitivities

from mphys.

Since all the pieces for a warper component appear to be accessible in the python apart from setting the volume coordinates into the solver, I'm going to go ahead and split the warping component out from the solver. The set of components is then:

1. AdflowMesh (ExplicitComponent) - gets the partitioned aerodynamic surface mesh to pass to the transfer schemes and potentially a shape parameterization component.
2. AdflowWarper(ExplicitComponent - mesh warping given a new surface
3. AdflowSolver (ImplicitComponent) - flow solve given a volume mesh
4. AdflowForces(ExplicitComponent) - integrates the forces on the aerodynamic surface
5. AdflowFunctions (ExplicitComponent)- should be able to use the adflow function evaluator from the adflow repo.

For now it will be assumed that the volume coordinates are not changed between calls to the warper and flow solver.

from mphys.

Commit 04b3537:

aero_run.py with 8 procs and use_openmdao = False:
{'wing_cl': 0.4176863998629372, 'wing_cd': 0.01681025059103742}

aero_run.py with 8 procs and use_openmdao = True:
cl = [0.4176864] cd = [0.01681025]

from mphys.

Aerostructural mach tutorial with commit 6db2199. Run with 24 procs:

TACS: max(v0) = 0.391799
ADflow: cl = [0.34983174] cd = [0.01405941]

Coupled problem not fully converge but first 5 digits of cl remain constant over final 80 of 100 iterations.

Edit: This example is located at OMFSI/examples/mach_tutorials/aerostruct/ on the adflow_comp branch

from mphys.

I ran the aero and aerostructural cases and got the following results:

Aero:
'wing_cl': '0.41769439414361414'
'wing_cd': '0.01680817039694992'

Aerostruct (with RLT):
'wing_cd': 0.019027053809616334,
'wing_cl': 0.342365355345908

from mphys.

With 'L2convergence' = 1e-12, I get the following results for aero_opt on 4 procs:
'wing_cl': 0.4176802774726952
'wing_cd': 0.01680860054180563

I made a pull request with this change.

from mphys.

Sensitivity verification

Some of the TACS and FUNtoFEM components do not have forward mode matrix vector products implemented. Currently the ADflow volume mesh only changes through the warping component affecting the FD results for x_g derivatives.

Most of the derivatives seem okay apart from the adflow forces and d(lift or drag)/d(mach).

Notes from examples/check_partials_adflow_funtofem_tacs/as_openmdao.py with e76afd6:

• disp_xfer - good agreement between rev and FD

• geo_disps - good agreement

• adflow deformer - good agreement

• adflow solver - matching forward and rev but finite difference has some discrepancies. Likely do to real-valued FD and large sensitivity of extremely small mesh.

• adflow forces - all values are zero on rev side. Also have zeros for design variables: alpha and mach. Alpha seems like it should be zero, but I think the dimensionalization should be affected by Mach number.

• load_xfer - good agreement between rev and FD

• tacs - not really good agreement. Maybe due to 4 element mesh sensitivity because the tacs sensitivities have been verified against complex step of tacs outside of OpenMDAO.

• tacs struct_funcs - pretty good agreement. Also verified with complex step outside of OpenMDAO.

• adflow aero_funcs - agreement between forward and reverse. Mach number derivatives are zero.

from mphys.

Fbar had a bug in ADflow. There is a fix posted as a pull request that fixes it.

from mphys.