Output forces on surface

[trilbytim]

Very odd! I don't get the same result. Smooth wall on the wing surface, k-epsilon turbulence (what do you mean by "default wall law"?) and I get the attached lift and drag file (I've also attached the setup.xml file). This gives a final lift of 408.24N (which matches the Paraview calculated value for total drag almost exactly) and a final drag of 29.79N (which matches the Paraview value for pressure drag NOT including viscous component almost exactly*), but not matching your figures at all.

Also, I don't see where there the size of the surface area of the cell is corrected for. Otherwise we will be over counting the effect of small cells and under counting the effect of large cells. Or am I missing somewhere this is taken into account? Maybe this is this included in the value for 'cell normal'? I.e. is the magnitude of this vector scaled with the size of the cell?

* I think this is because in line 121 of your code you write to the text file:

Code: Select all

forces[1], forces[2], forces[3], forces[2]);

I think this should be:

Code: Select all

forces[1], forces[0], forces[3], forces[2]);

to take account of the viscous component?

[Yvan Fournier]

Hello,

Yes, there was a mixup in 2 indices in the forces array.

Also, yes, the surface is accounted for in the face_normal.

So what I do not understand is why you get so different results ? As I said, using your original file, I got divergence, which you did not observe. The difference between having a runaway computation or not can sometimes hang on a thread and occur or not due to small differences such as the different truncation errors which can change slightly depending on the mesh partitioning. But since you have very high CFL numbers, at least in a few places, there might be an issue (ideally, we should not diverge with high CFL numbers, just activate upwinding locally, and so we could optimize of the mean and not max CFL number, but although this is what occurs on very simple test cases, things get more complicated on large caes).

Could you try using a local time step (pseudo-steady algorithm), and use a smaller initial time step, to see how this influences your results.

Also, could you post a run_solver.log file, so I can compare with mine ?

Best regards,

Yvan

[trilbytim]

OK, so I have tried again using Steady (local time step),, with the reference time step set to 0.01, everything else left default (Maximal CFL number 1.0, Maximal Fourier number 10.0, Minimal time step factor 0.1, Maximal time step factor 1000, Time step maximal variation 0.1).

Now I do get better results., lift of 461N, drag of 29N, L/D 15.8. So still a bit off the other methods, but getting closer. I'll try running again with an even smaller reference time step.

It's still a bit of a mystery why we don't seem to be getting the same results from running the same files though. I've attached the run_solver.log files for the latest run with the Steady (local time step) method and also the one from the Constant time step (set to 0.1s) that diverged for you but not for me.

[Yvan Fournier]

Hello,

The fact that I get divergence while you do not needs to be investigated, though doing so on a smaller mesh would be easier... I may try some options reducing the influence of the mesh partitioning (such as replacing the multigrid preconditioner for the pressure correction with a simple Jacobi preconditioner), as you have run on a smaller number of ranks.

In any case, for your steady case, the mean CFL number is very high, which is not recommended, and might explain the lower quality results. I assume you would get better results with a smaller time step.

Best regards,

Yvan

[trilbytim]

I have tried reducing the reference time step to 0.001 (in Steady Local Time Step mode), but this made almost no difference to the final result. I also tried reducing the Maximal CFL number to 0.1, but then it failed to solve. If you have any more cases you want me to run then I'd be happy to.

[Yvan Fournier]

Hello,

Just in case we have a bug there (as it is less tested), could you try to tun in pure MPI mode (for example 12 to 16 MPI ranks, one thread per rank) instead of hybrid mode as you did here ?

Otherwise, I will try to find new ideas for tests to understand this behavior.

Best regards,

Yvan

[trilbytim]

Sorry, I'm not clear what you mean here. I'm on a machine with 4 physical cores and 4 threads per core. So are you saying that in the "Run Simulation" window I should try "Number of processes" to 4 and "Threads per process" to 1?

[Yvan Fournier]

Hello,

You can ser the number of processes to 16 and number of threads to 1.

Best regards,

Yvan

[trilbytim]

Actually if I set the number of processes to 16 and threads to 1 then I get the error "There are not enough slots available in the system to satisfy the 16 slots that were requested by the application:"

However I have run it with 4 processes and 1 thread per process (running the original case with 0.1s Constant time step that diverged for you) and I get the exact same results as when I run 4 processes and 4 threads per process (no divergence and same lift and drag to within 0.1N).

[Yvan Fournier]

Hello,

OK thanks for the feedback. You can probably work around that restriction using an environment variable or forcing the --oversubscribe option in the MPI launch options, but that is OK. I will try to run the case on fewer processes on my side.

Best regards,

Yvan