channel395 : Using fvOptions to add a momentum source
The problem in channel395
And fvOptions in channel395 is renamed. It was "pressureGradientExplicitSource". It's like pressure induced turbulence ?
Quote:
After a period of searching , I continue my calculation for a much longer time, the velocity at the domain center oscillating around 0.15m/s(the Ubar=0.1335m/s), about 1.1times. So this is exactly what it should be. The first problem is solved.
However, I'm still not quite understand the second problem. How can we initialize the p ,nusgs fields? Or my misunderstanding, just perturbU required for the velocity field?
However, I'm still not quite understand the second problem. How can we initialize the p ,nusgs fields? Or my misunderstanding, just perturbU required for the velocity field?
Quote:
Quick answer: This fvOption was renamed to "meanVelocityForce" some weeks ago in OpenFOAM-dev and it's now part of OpenFOAM 3.0.
The commit in question was this: https://github.com/OpenFOAM/OpenFOAM...898bec5fac74ad
As for why this calculation gives you the pressure gradient, you will have to take a look at the pressure equation in the solvers, because those use "rAU" for those equations. For example, take a look at this wiki page: https://openfoamwiki.net/index.php/IcoFoam
The commit in question was this: https://github.com/OpenFOAM/OpenFOAM...898bec5fac74ad
As for why this calculation gives you the pressure gradient, you will have to take a look at the pressure equation in the solvers, because those use "rAU" for those equations. For example, take a look at this wiki page: https://openfoamwiki.net/index.php/IcoFoam
Quote:
… where the source term depends on the current velocity field. How can I make sure that it converges at each time-step in an unsteady simulation?
I'm using pimpleFoam and I've made a new fvOption which is similar to actuationDiskSource. I understand that it works as follows:
Essentially, the class has a public function AddSup where eqn.source() is used to set the source term, where eqn would appear to reference UEqn when the IOOptionList is created by the solver, simple-/pimpleFoam. Using eqn.psi(), the fvOption class also has access to the current velocity, and mesh_ is a reference to the mesh database provided by the base class option. So it's straightforward to make a momentum source term, which depends on the current velocity field, in my case sampled at different points.
In pimpleFoam, the UEqn is defined with == fvOptions(U) on the r.h.s., and then the solution loop is passed through. I hope I'm wrong, but from pisoFoam.C, I don't get the impression that fvOptions(U) is called again, (and addSup recalculates the source term based on the intermediate velocity field solution), during each time-step.
Perhaps this is a question on how literally to interpret the top-level solver syntax (if you haven't had the time to trace back through everything). I hope I'm not getting terminology wrong here but in
I assume that the l.h.s terms are implicitly included in the matrix, while the r.h.s is explicit. Therefore, for a velocity dependent source term in an unsteady solution, there would need to be an inner loop for each time-step to converge the source term.
Assuming I'm right so far, my next step would be to modify s-/pimpleFoam to repeat the solution loop at each step. On my first attempt (for simplicity, with simpleFoam) I'm confused by the results:
Clearly it's not as simple adding a loop,
ultimately a while loop to be controlled by some measure of convergence of the calculated source term, around the following:
With no source term, I might have expected the second loop to converge immediately, but it appears to do almost as much work as the first loop (same no. of iterations, very similar initial residual).
I guess my questions are more implicit than explicit here
Basically, I'd be glad if someone "in-the-know" could confirm my understanding of the way the fvOptions are adding source terms. I'm quite confident about that part, but then I'm much less sure how they are being dealt with in the solver. As my simpleFoam loop test didn't do what I expected, I'm unsure of how to make a time-step inner loop in pimpleFoam to converge the source term.
I'm using pimpleFoam and I've made a new fvOption which is similar to actuationDiskSource. I understand that it works as follows:
Essentially, the class has a public function AddSup where eqn.source() is used to set the source term, where eqn would appear to reference UEqn when the IOOptionList is created by the solver, simple-/pimpleFoam. Using eqn.psi(), the fvOption class also has access to the current velocity, and mesh_ is a reference to the mesh database provided by the base class option. So it's straightforward to make a momentum source term, which depends on the current velocity field, in my case sampled at different points.
In pimpleFoam, the UEqn is defined with == fvOptions(U) on the r.h.s., and then the solution loop is passed through. I hope I'm wrong, but from pisoFoam.C, I don't get the impression that fvOptions(U) is called again, (and addSup recalculates the source term based on the intermediate velocity field solution), during each time-step.
Perhaps this is a question on how literally to interpret the top-level solver syntax (if you haven't had the time to trace back through everything). I hope I'm not getting terminology wrong here but in
Code:
3 tmp<fvVectorMatrix> UEqn 4 ( 5 fvm::ddt(U) 6 + fvm::div(phi, U) 7 + turbulence->divDevReff(U) 8 == 9 fvOptions(U) 10 );
Assuming I'm right so far, my next step would be to modify s-/pimpleFoam to repeat the solution loop at each step. On my first attempt (for simplicity, with simpleFoam) I'm confused by the results:
Clearly it's not as simple adding a loop,
Code:
for (int i = 0; i < 2; i++){}
Code:
59 // --- Pressure-velocity SIMPLE corrector 60 { 61 #include "UEqn.H" 62 #include "pEqn.H" 63 } 64 65 turbulence->correct(); 66 67 runTime.write();
I guess my questions are more implicit than explicit here
Basically, I'd be glad if someone "in-the-know" could confirm my understanding of the way the fvOptions are adding source terms. I'm quite confident about that part, but then I'm much less sure how they are being dealt with in the solver. As my simpleFoam loop test didn't do what I expected, I'm unsure of how to make a time-step inner loop in pimpleFoam to converge the source term.
Total Comments 0