Geometry does not follow FFD-Points

[radioaktivity]

I have a geometry where I only want the front part to be optimized.
So I created a plot3D-File around my geometry which contains two blocks.
One block covering the front and one covering the back.
For the Design Variable Set-Up I selected only the front block,
but after my simulation was finished the solver did not modify the mesh at all.
Although the FFD-points have moved quite significantly as can be seen in the image below where I displayed them in the first 3 iterations.
I used the Option "writeDeformedFFDs": True, to get the deformed FFD-states and I displayed them in this picture via the Tecplot-Converter which you provide with the docker-image.

[friedenhe]

Are you sure you included both the front and back parts of the geometry in "designSurface" in daOptions? Also, did you load both the geometry and FFD to make sure they make sense? Did you see some folders called 0.0000001, 0.0000002 generated? Did you run your job in parallel? If yes, you need to choose "Decompose" when viewing it in Paraview, otherwise, you won't see the geometry change. Or you can first do reconstruct, then visualize. Check this: https://dafoam.github.io/mydoc_get_started_faq.html#how-to-reduce-the-size-of-parallel-optimization-results

[radioaktivity]

Thanks for the quick response.
Yes I loaded them both and the white and red box cover the geometry as wanted.
After 30 iterations, there is only the 0.0000001 folder which appears and this one is identical to the starting geometry.
During the iteration this message is always displayed:
Solution time 1e-08 less than 1e-6, not moved.
Does this mean DAFoam does not move the mesh in every iteration?

I tried with a simpler mesh but essentially the same setup.
In this case he moved the mesh but not much.
On the other hand the control points moved quite a bit.
I thought FFD-Points and Mesh-cells will move more or less 1:1

[friedenhe]

OK, if you have only one folder generated (0.00000001), it means that the optimization did not have any progress. The possible reasons: 1. The adjoint did not converge. 2. The FFD displacement bounds are too large such that it keeps giving you negative volume mesh. 3. The flow did not converge very well so that the gradient is not accurate anyway. Can you upload the runScript.py and the optimization log for debugging?

[radioaktivity]

Yes actually the limits are pretty high and the geometry is pretty dull so this could be the reason.
But I already did a similar case withe a dull geometry and DAFoam did quite some Iterations.
Is there a definition of "step size" which defines the factor with whom the deformation will follow the gradient?

In following the runscript and the logOpt, from which I could only upload the first part since it is too big.
runScript.txt
logOpt_shorter.txt

[radioaktivity]

I have another small update. Now it does actually create a folder 0.0000002 but there is still no displacement visible.
I tried to vary some parameters to help with the convergence but after a couple of tries the
calculations always finish with an error which does not explain for me what the problem was or it finishes because it reached maximum amount of iterations.
The Log-File:

logOpt.txt

Could this also be a memory issue ?
I have ~1.4 Mio cells in this case with 60 processors and 230 GB of RAM

[friedenhe]

Your flow and adjoint were not converging at all. You prescribed a too large tolerance for the flow (0.01), reduce it to at least 1e-6. For the adjoint convergence, check https://dafoam.github.io/mydoc_get_started_faq.html#why-the-adjoint-equation-is-not-converging

[radioaktivity]

I retried with the suggestions from the FAQ and it works already better.
Thanks a lot.

I still have the problem when I refine the mesh to much
the primal solution will not accede its desired residual threshold. It stays constant around 1e-3.
That's why in, the first place, I increased the tolerance that much actually.

What can I do further?

Do I prescribe more iterations?
Or can I somehow influence the way the solver averages the flow field (over a larger number of iterations for highly unsteady cases) ?

[friedenhe]

If your flow is unsteady and you can not converge the flow tolerance to less than 1e-5 ish, you can not use DASimpleFoam for optimization. We only support steady-state flow or periodic unsteady flow with a known frequency.