Regarding the asynchrony issue among the .out file, the field file output, and the opt_IPOPT.txt file

[cfddinner]

Recently, when I was running my own case using DAFoam, I encountered an issue: while the .out file has already completed over 30 iterations, only 15 sets of data are recorded in each partitioned "processor" folder, and the opt_IPOPT.txt file has only logged 12 rounds of optimization records.To be specific, I went through dozens of iterations shown in the .out file displayed in the first image, but IPOPT only recorded a dozen iterations. Moreover, the data between the two does not match. Therefore, should we refer to the .out file or the IPOPT output file to check the number of optimization iterations?



I have also noticed that there is a slight discrepancy in the drag calculation results between the one obtained using OpenFOAM's built-in post-processing tool and the one calculated by DAFoam.Additionally, I would like to use drag force as the objective function and configure the daOptions accordingly, but it seems that the drag force value is two orders of magnitude lower than expected.
daOptions = {
"solverName": "DASimpleFoam",
"designSurfaces": ["Fluid.model"],
"primalMinResTol": 1e-8,
"primalMinResTolDiff": 1e3,
"primalBC": {
},
"function": {
"Drag": {
"type": "force",
"source": "patchToFace",
"patches": ["Fluid.model"],
"directionMode": "fixedDirection",
"direction": [1.0, 0.0, 0.0],
"scale": 1.0,
},
},

[cfddinner]

Is it because multiple line searches need to be performed within one optimization iteration cycle, and the sum of "ls" in the last column of the opt_IPOPT.txt file equals the total number of steady-state calculation iterations in the .out file? Also, is the field file written out only after each IPOPT optimization cycle? Could you please confirm if my understanding above is correct?

[friedenhe]

Regarding your questions. Yes, the total number of flow simulations is usually much higher than the number of optimization iterations because of the line search (ls column in the log). IPOPT's log file has the correct number of optimization iterations. In DAFoam, we do not know how many iterations IPOPT has, so DAFoam will save intermediate data, e.g., 0.0001, every time an adjoint solution is called. Therefore, the number of intermediate folders, e.g., 0.0001, can be slightly higher than the IPOPT iterations. This is because the optimizer sometimes calls the adjoint and then does not use it as the major optimization iteration. Regarding your observation about the drag difference, I suspect it is related to how you scale the drag in OpenFOAM's post-processing util. We verified DAFoam's drag vs OpenFOAM's built-in drag computations; they should be the same.

[cfddinner]

Thank you very much for your reply, and I truly appreciate your patient explanation regarding the number of iterations. I’ve finally figured out why there was a discrepancy between the post-processing results of OpenFOAM and DAFoam: it seems that DAFoam defaults to a density of 1, whereas I used a density of 0.998 in my OpenFOAM post-processing. Once I adjusted the density to 1 in OpenFOAM, the results became essentially consistent , but how can I change the density in DAFoam's post-processing.
And I still have a small question to ask. Since my objective function only needs to be set to drag force (rather than drag coefficient), I configured it as follows:
"function": {
"Drag": {
"type": "force",
"source": "patchToFace",
"patches": ["Fluid.model"],
"directionMode": "fixedDirection",
"direction": [1.0, 0.0, 0.0],
"scale": 1.0,
},
}
The issue is that the drag force calculated by DAFOAM (0.8740) is two orders of magnitude smaller than the actual drag force (87.40). I would be extremely grateful if you could spare some time to help clarify this discrepancy. Thank you again for your assistance!

[friedenhe]

The issue is that the drag force calculated by DAFOAM (0.8740) is two orders of magnitude smaller than the actual drag force (87.40).

How did you get the actual drag force? From simpleFoam? Also, for incompressible flow solvers, variables are normalized by rho already, so rho is always 1. You should not set any values other than 1 for the density for incompressible solvers

[cfddinner]

How did you get the actual drag force? From simpleFoam? Also, for incompressible flow solvers, variables are normalized by rho already, so rho is always 1. You should not set any values other than 1 for the density for incompressible solvers

Sorry about the wrong types in the previous talk.the drag force is 3 orders of magnitude samller(0.08740 and 87.4),I guses maybe it's because I type'scale:1.0' in my runscript and DAFoam thought that my rho is 1.
And Yes that I just added these lines in the controldict ,and used simpleFoam for the actural force

functions
{
forces
{
type forces;
libs ("libforces.so");
patches (Fluid.model);
rhoInf 998.8;
rho rhoInf;
writeControl timeStep;
writeInterval 1000;
log true;
CofR (2.178 0 0);
}
}

As for DAFoam, I used the runscript like this

=============================================================================

Input Parameters

=============================================================================

U0 = 3.045
A0 = 5.6593
p0 = 0.0
k0 = 0.013
epsilon0 = 0.00075

Set the parameters for optimization

daOptions = {
"solverName": "DASimpleFoam",
"designSurfaces": ["Fluid.model"],
"primalMinResTol": 1e-8,
"primalMinResTolDiff": 1e3,
"primalBC": {
},
"function": {
"Drag": {
"type": "force",
"source": "patchToFace",
"patches": ["Fluid.model"],
"directionMode": "fixedDirection",
"direction": [1.0, 0.0, 0.0],
"scale": 1.0,
},
},
"normalizeStates": {
"U": U0,
"p": p0,
"k": k0,
"epsilon": epsilon0,
"nut": 1e-3,
"phi": 1.0,
},
"adjEqnOption": {"gmresRelTol": 1.0e-6, "pcFillLevel": 1, "jacMatReOrdering": "rcm"},
"adjPCLag": 1,
# Design variable setup
"inputInfo": {
"aero_vol_coords": {"type": "volCoord", "components": ["solver", "function"]},
},
}
Thanks a lot for your reply!

[friedenhe]

The problem is that you set rhoInf 998.8 in OpenFOAM, which is not quite right. If you are using an incompressible flow solver, like simpleFoam, you should always use rhoInf=1. This is because incompressible flow variables in OpenFOAM have already been normalized by rho.

[cfddinner]

Thank you for your reply. However, I think that in the controlDict, the rhoInf parameter set for OpenFOAM's built-in forces post-processing function is more like a scaling factor. When running calculations with an incompressible solver, the computation should still use the normalized density. Then, during post-processing, the rhoInf value is used to calculate the drag force.

Because when I completely removed this force-calculating post-processing function from the controlDict, the result from DAFoam was still 0.0874 N. It seems that rhoInf does not affect the calculations of DAFoam and simpleFoam, and only acts as a scaling factor in post-processing.

Please point out any mistakes I might have made . Thank you very much.

[friedenhe]

Right, DAFoam does not read rhoInfo from controlDict. If you want to compute the actual force in Newtons, you should set "scale": 998.8 for the force function in runScript.py. Then, the DAFoam and OpenFOAM CD should match.

[cfddinner]

That's right！When I set "scale": 998.8，the results match.Thanks a lot!

[friedenhe]

@cfddinner, We are doing a campaign to collect DAFoam user feedback. Check this page. Are you available for a 30-minute Zoom meeting with our DAFoam team? If yes, please email me at [email protected]. Thanks!

[cfddinner]

Thank you for your invitation. I will reply to your email shortly, and I am honored to participate in this feedback session.