Adjoint surface sensitivity deteriorates with mesh refinement.

[pedropaulocb]

I have been trying to work with adjoint using Adflow to calculate surface sensitivities.

The direct simulations worked fine for all mesh refinements (coarse, medium, fine, etc.). However, when computing the surface sensitivity to lift or drag, the sensitivity changes significantly with the level of refinement until oscillations start to appear in the results (for more refined meshes).

The direct simulations converged well for L2Convergence<1e-12. All the adjoints also converged with res. norm < 1e-8. I am not using a FDD box, because I am interested in the sensitivity of the entire surface. It is a 2D case.

I have tried the Bump-in-Channel and NACA0012 (2D) cases with Euler and Laminar NS. Still, all the sensitivities get oscillations when we run medium/fine meshes, and different mesh refinement always gives different sensitivity solutions for both solvers.

Have anyone faced this problem before or have any clue about what may be causing these problems?

I am attaching two pictures here (Bump-in-Channel for Mach=0.3) and the script used to run the laminar N

bump_python_script.txt

[joanibal]

I don't believe anyone has experienced this exact problem. @awccopp , was recently investigating the change in adjoint across different mesh values. So he might be able to help.

All the adjoints also converged with res. norm < 1e-8.

Could you provide the norm of the error after the solution. It should look this

Solving ADjoint Transpose with PETSc time (s) =   382.24
 Norm of error = 0.8614E-09    Iterations =  500

I have had trouble with the actual accuracy of the solution being much lower than I specified.

different mesh refinement always gives different sensitivity solutions for both solvers.

This makes sense to me. Moving a node will cause a smaller shape change when there are more nodes. The oscillations, of course, do not look right to me though.

I have tried the Bump-in-Channel and NACA0012 (2D) cases with Euler and Laminar NS.

Just checking that the boundary conditions were correctly changed if needed. As you probably know, the Laminar NS needs an ~NSAdiabiaticWall~ BCWallViscous BC. Otherwise the drag in both cases would be zero due to D'Alembert's paradox. The derivative with respect to drag in such a case would probably be ill conditioned since the net drag is spurious.

[pedropaulocb]

Thanks for the quick reply @joanibal.

Norm of error = 0.6193E-10 Iterations = 263 (Super coarse mesh) Norm of error = 0.9158E-10 Iterations = 902 (Coarse mesh) Norm of error = 0.1311E-09 Iterations = 1105 (Base mesh)

The BC was set to BCWallViscous at the bump wall in the CGNS mesh using ICEM. The order of the Cd was reasonable comparing with validation cases.

[joanibal]

Norm of error = 0.6193E-10 Iterations = 263 (Super coarse mesh) Norm of error = 0.9158E-10 Iterations = 902 (Coarse mesh) Norm of error = 0.1311E-09 Iterations = 1105 (Base mesh)

Those errors all seem good to me. When I was having difficulties the error was closer to 1e-4

The BC was set to BCWallViscous at the bump wall in the CGNS mesh using ICEM.

Ah, yep that is the right BC name, my bad. NSWallAdiabatic is the variable name corresponding to that CGNS BC type in the code.

The order of the Cd was reasonable comparing with validation cases.

Do you have any Cp contours you could share? I'm curious what the solution looks like. If the solution is smooth then the issue is probably deeper in the code unfortunately.

[joanibal]

The next step after checking the solution is probably to start checking the value of the derivatives against finite difference and/or complex step

[awccopp]

Could you post the flight conditions you used for your naca0012 testing? I can try to see if I can recreate this behavior.

[pedropaulocb]

@awccopp For the NACA0012 I have used: Euler; Mach = 0.30; AoA = 0; T=300. The only two BC were Farfield and BCWallInviscid.

In a second moment, using the Meshes available on https://turbmodels.larc.nasa.gov/naca0012_grids.html I changed the Mach to 0.15 and kept the previous conditions the same, still with Euler, for the three intermediate meshes (225x65; 449x129; 897x257) problems emerged in the LE region (oscillations in the sensitivity dZ for the normal direction Z concerning the lift coefficient).

@joanibal I am attaching the Cp distribution for the super coarse Euler and Laminar NS. The BC: Farfield at the front and back surfaces of the domain, Symmetry at the upper and lower domain surfaces before and after reaching the bump wall, and BCWall(Insviscid/Viscous) at the bump wall.

[pedropaulocb]

Hi, Observing the results from the Bump-in-Channel with an Euler solver, the sensitivity values scale precisely with the level of refinement of each mesh (which is equal to 2 in all directions). This is similar to what @joanibal has said in the first comment. Oscillations stars to appear to the medium refinement (See the first figure). However, when I applied a lowpass filter to the medium case and normalized the sensitivity based on the mesh refinement level, all curves got on top of each other (see the second figure).

My question is, are these oscillations normal to the adjoint method? Perhaps this is why in optimization, we use the FFD box. I am assuming the sensitivity is integrated and then transferred to the FFD points, or there is some smoother application in the sensitivity of the entire surface before moving it to the FFD...

For our application, we can not use FFD because we need the sensitivity of the entire surface. So to move on, I would need to know if this oscillatory behavior of the sensitivity is normal, even when using an Euler solver. We have found a paper Filtered Gradients for Adjoint-based Shape Optimisation (Stuck and Rung, 2011) where oscillations in the sensitivity were also obtained, but they attributed to low-Re characteristics:

"The oscillations are more pronounced in the adjoint case. We assume that this is caused by the adjoint sensitivity equation (6), which is a differential expression including the product of primal and adjoint wall shear rates, both of which are not smooth in the low-Re calculation"

Regard, Pedro.

[awccopp]

Have you tried plotting the adjoint variables? You can do this by setting your states to the adjoint vector and calling write solution (you may also want to scale the adjoint variables by 1/Volume of each cell).

[pedropaulocb]

Hi, we found out something. @joanibal In the previous posts, we plotted a smooth Cp distribution obtained using python script and the CFDSolver.addslice('y',[-0.5]) command. However, following the suggestion of @awccopp, I took a look at the adjoint field, and we realized that they were not smooth!

I had a false impression that the solution was smooth because I looked at the data with the addslice function and python scripts. However, when using the volume and surface data in Paraview, oscillations were present for all flow field variables. Here I have attached results for Density and Cp (Euler solver - Bump wall) as an example.

The oscillations in the sensitivity are due to our direct solution (which leads to an oscillatory solution for Adjoints). I should mention that this only happens as we refine the mesh with the same factor in both X and Z direction (In the Y direction, we have only one volume cell in all cases)! For the two lower refinement levels, I did not have this problem (Oscillations).

Here is attached the OneDrive folder with all the files if someone would like to look. https://1drv.ms/u/s!AuCQ841fyvsDgehspp45ACb0I2WOCw?e=3IfFoP

Our satisfied criteria for convergence: L2Convergence: 1e-13 adjointL2Convergence: 1e-9

Could you give us a hint of why are we having these oscillation problems as we refine our mesh?

!

[awccopp]

I believe @akleb ran into issues with refinement causing solution oscillations.

[joanibal]

The issue @akleb had was caused by small bumps in the geometry.

I'd check that the geometry you used for the refined mesh is smooth enough. You may need to use double precision CGNS mesh coordinates.

[akleb]

Yes, I had a problem with lack of precision in my geometry as a result of using quadratic splines rather than cubic splines in my geometry definition. I was doing the following:

1. Start with a a list of ~100 points on an RAE 2822 geometry from UIUC
2. Use spline interpolation to fit a quadratic b-spline to the data
3. Sample an arbitrary number of points from the spline to define my new airfoil surface
4. Create a volume mesh from these newly sampled points (allows me to make arbitrarily fine meshes without having to combine and split cells).

I fixed this problem by switching the interpolating quadratic splines to interpolating cubic splines. The main takeaway for me was that the quadratic splines where not smooth enough in regions where the flow was sensitive to the geometry (airfoil leading edge). I would start by checking that the geometry you are using as enough precision to match the level of precision you would like to see in the outputs.

[joanibal]

Hi @pedropaulocb,

Did your issue get resolved?

[pedropaulocb]

Thanks for asking @joanibal. All the problems we had (oscillations) were tracked to mesh precision problems. We were able to run some successful cases using proper meshes. Regards, Pedro.

[joanibal]

Glad to hear that