[sbaffini]

Alternatively, now that you mention your algorithm, you can consider also Nek5000. I am not really that expert in FEM and similars, but maybe you can find a common ground. Nek5000 is a spectral element code using only hexaedra with GLL points and, in practice, has an algorithm very similar to the one you are using (to the best of my memory... few years have passed since the last time i used it). It is probably optimized towards the high order end, but you can go low order as well, and the code is especially known also for its algorithmic performances. So that you know you are comparing with one of the firsts in class.

[FMDenaro]

Originally Posted by HectorRedal

First of all, many thanks for the information you have provided.
Obviously, as you are stating, comparing both algorithms is like comparing apples with oranges. But it gives you a rough estimation about the performance of my code. Other point worth considering is the hardware. When using different hardwarde, different solution times are going to be obtained. The more powerful the processor, the less time it will take. By the way, right now, I am using a Xeon Processor of 4th generation.

Trying to answering your question, I am using CBS algorithm (Characteristics Based Split Scheme), which is more or less similar to a fractional step. It contains three steps, where in each of them a linear system of equations has to be solved (A x = b): 1st step, estimation of the velocity without considering the pressure term. 2nd step, calculation of the pressure, enforcing divergence free of the velocity field. 3rd step, correction of the velocity estimation.
So, trying to compare my results with the figures provided by you, in every time step, my algorithms performs 3 iterations. This mean that every minute I am solving 375 iterations.
As I see, the code I have developed is 25% slower than the code you are using (Taking with all care this statement, as you are stating, we are comparing two algorithms that are quite different and running in different hardware).

One important thing I would like to highlight is that the tolerance I am using for solving the linear system is tol = 10e-8, being tol = norm (Ax - b) /norm (b).
So, I don't know if this is two stringent for a transient simulation.

Without more details I am not sure about your procedure. The first linear sistem is for an implicit time scheme, right? You should get convergence in very few steps and it should count some percent of the total CPU time.
The second step should be the pressure equation that is the core of the computational time.
Why is the third step (correction of the velocity) implicit?

The tolerance you control is correct.

[HectorRedal]

Originally Posted by FMDenaro

Without more details I am not sure about your procedure. The first linear sistem is for an implicit time scheme, right? You should get convergence in very few steps and it should count some percent of the total CPU time.
The second step should be the pressure equation that is the core of the computational time.
Why is the third step (correction of the velocity) implicit?

The tolerance you control is correct.

The first step is explicit, the second term is for the pressure equation, which is implicit. And the third step is explicity.
So, the overall algorithm is semi-explicit, as the authors call it.
Regarding, the computational cost of solving the sparse matrix system, it is not too costly. The only thing I would like to comment is that I am not ordering the identifier of the nodes in the mesh so that my sparse matrix is almost banded. So, I don't know which can be the impact in the overall performance of the algorithm.

[HectorRedal]

Originally Posted by sbaffini

Alternatively, now that you mention your algorithm, you can consider also Nek5000. I am not really that expert in FEM and similars, but maybe you can find a common ground. Nek5000 is a spectral element code using only hexaedra with GLL points and, in practice, has an algorithm very similar to the one you are using (to the best of my memory... few years have passed since the last time i used it). It is probably optimized towards the high order end, but you can go low order as well, and the code is especially known also for its algorithmic performances. So that you know you are comparing with one of the firsts in class.

I will try to assess the alternative you are commenting. I will take a look at it.

[arjun]

Originally Posted by HectorRedal

The first step is explicit, the second term is for the pressure equation, which is implicit. And the third step is explicity.
So, the overall algorithm is semi-explicit, as the authors call it.
Regarding, the computational cost of solving the sparse matrix system, it is not too costly. The only thing I would like to comment is that I am not ordering the identifier of the nodes in the mesh so that my sparse matrix is almost banded. So, I don't know which can be the impact in the overall performance of the algorithm.

The linear solver is your dark horse, it does not scale linearly with problem size increase.
Typically fractional solvers require the pressure equation be solved to very low tolerance and this tight requirement on linear system often then lose the time advantage of fractional solvers.

Nonetheless FVUS/Wildkatze has very interesting strategy you can have a mixed solver that is both implicit and fractional. User can specify the implicit frequency for example default value is 10 that means every 10th time step is implicit one.

It is quite useful in VOF types simulation where I can offer then a hybrid solver that is when delta t required is too small, user specifies min time step size, below this solver will not go and at this min timestep size solver uses implicit version of VOF.