Overset performance degradation
Hi.
We have been monitoring the performance of the overset solvers hoping in some performance in the new releases but it looks like they actually worsened starting from the v1706 and now further degraded in the latest v1812.
The following results (cloclTime per 2sec of simulated time on 1 core) are based on the twoSimpleRotors test case, run with the fixed time step and using the same fvSolution, fvSchemes and dynamicMeshDict in each case:
v1706: 683 sec v1806: 860 sec v1812: 5024 sec
Note that the v1812 needs about twice the number of iterations per correctors, but doesn't justify such an increase in the total clock time.
Also, when using the v1812 with the original settings, the clock time increases to about 13.000 sec.
Would be nice to have a little bit of feedback and some directions to perform further testing and hopefully improve the usage of overset in general.
## Reattaching the author to the issue ticket: @Ricky-11 ##
Activity
In the past few releases we aimed to improved and prioritize certain issues over others, such as hole searching algorithm for robustness, p-U for smooth pressure evolution and some work in mass conservation. All these efforts were taken following specific customer concerns about these issues. We are aware of the performance issue and we are waiting for suitable fund to help us to improve it. The Main issue being the modification in the hole searching. You are welcome if you want to contribute to its improvement. Thanks Sergio
Hi Sergio.
I'm not among the users who raised such issues, but I can definitely see them as of paramount importance.
That said, do you think the increase in the clock time in the v1812 (6x and 15x respectively using the modified and original setup compared to the v1806) is normal and follows from such improvements on the accuracy/robustness side?
From my experience, the current overset implementation was already barely practical for industrial applications and with such an increase would be definitely not viable using the new release.
In any case, we would be happy to share information and data and perhaps work as testers within our range of applications of interest.
Thanks,
Riccardo
By Riccardo Rossi on 2019-01-25T17:49:04 (imported from GitLab project)
Edited by Admin
## Reattaching the author to the issue ticket: @Ricky-11 ##
Interesting. Are you using 'cellVolumeWeight' as the interpolation method? This is slow (but has interesting properties).
I'm just doing a simple test: inverseDistance in v1706 v.s. trackingInverseDistance (slightly optimised version of inverseDistance) in develop (note: you'll need develop - was not working in v1812). To get to Time = 0.045 takes 160s in v1706, 97s in develop. It would be interesting to see why cellVolumeWeight is that slow. Do you have the log files?
Hi Mattijs.
Yes I do. They are few MB each of size so I've created a folder on Dropbox for download:
https://www.dropbox.com/sh/o2d6cyhbh6os7ur/AAAlI49zWHWhGwK-MjM2Yhi3a?dl=0
I ran four cases in total. The first three of them (run01, run02 and run03) use inverseDistance and share all the same setting in fvSolution, fvSchemes and controlDict, where I've switched to fixed time-step from the original tutorial to make sure they all perform the same number of steps from start time to finish.
The last one (run04) is simply the original tutorial coming with the v1812 using the cellVolumeWeight method where I only made the change of the fixed time step.
Note that the log file from the run 3 and 4 are incomplete as they were killed because they exceeded the time limit on the cluster.
Let me know if you need further info. I'll be happy to help.
Riccardo
By Riccardo Rossi on 2019-01-29T17:42:30 (imported from GitLab project)
Edited by AdminFirst observation:
- run02 v.s. run01 : smoother behaviour - less variation in pressure sweeps.
- run03 : case has 4x number of cells (12008 vs 3213) so will take more pressure sweeps.
My bad.
I've noticed and reported at the beginning of the thread the increased number of sweeps in the v1812 but I gave for granted the tutorial would have had the same number of cells of the old releases.
I ran again the run03 case with the original (coarse) grid and the clockTime is 849 sec (was 683 sec for run01 and 860 sec for run02).
Also, i ran again the run04 (original tutorial) using 2 correctors as in the other cases (was 2 in the original setup) and the projected clockTime is about 2450 sec with increased number of sweeps in the second corrector.
The new logs are available in the dropbox folder.
By Riccardo Rossi on 2019-02-05T08:35:42 (imported from GitLab project)
Edited by Admin@Mattijs I've downloaded the source file for trackingInverseDistance from the develop repository and I can confirm that the twoSimpleRotors tutorials take half the time to complete when compared to the same case in the v1812 with inverseDistance interpolation method.
We are now testing the algorithm with a production case (1.5M cells) and I'll let you know asap how that goes.
By Riccardo Rossi on 2019-02-08T09:17:09 (imported from GitLab project)
@Mattijs I've tried to use the trackinginveseDistance scheme from the development code in the boatAndPropeller tutorial coming with the v1812 release. However, the solver crashes at the first iteration, whereas runs fine when using the inverseDistance scheme.
Would it be possible for you to do the same test?
By Riccardo Rossi on 2019-02-20T00:13:09 (imported from GitLab project)
@Mattijs would it be possible that trackingInverseDistance, even from development code, works in a 2D setup as the twoSimpleRotors tutorial but fails in 3D?
By Riccardo Rossi on 2019-02-20T08:17:58 (imported from GitLab project)
Actually, I just checked the latest time folder from the twoSimpleRotors tutorial run using the trackingInverseDistance scheme compiled from the development code and the solution looks wrong even for this simple case (see attached).
By Riccardo Rossi on 2019-02-20T08:39:47 (imported from GitLab project)
@Mattijs would it be possible for you to share the case from the test you mentioned in the comment below?
"I'm just doing a simple test: inverseDistance in v1706 v.s. trackingInverseDistance (slightly optimised version of inverseDistance) in develop (note: you'll need develop - was not working in v1812). To get to Time = 0.045 takes 160s in v1706, 97s in develop"
By Riccardo Rossi on 2019-02-20T08:41:56 (imported from GitLab project)
It probably was the develop version of the tutorial. trackingInverseDistance.tgz
I have only checked the 'cellTypes' field - not the actual solution though.
I've downloaded the develop version of the tutorial and set the case to use my compiled version of trackingInverseDistance but now run diverges.
Would you mind to share your trackingInverseDistance setup including the solution?
By Riccardo Rossi on 2019-02-20T09:40:13 (imported from GitLab project)
Sorry, overlooked the symbolic links.
@Mattijs any chance to follow up on trackingInverseDistance testing?
By Riccardo Rossi on 2019-03-13T08:18:53 (imported from GitLab project)
I am running a recent develop (08a608302370c838c391c59c48d63268817ff49e) though nothing has changed.
My only change to the tutorial case is the fvSchemes:
Attached also the log file:
