|
[Sponsors] |
March 21, 2022, 11:30 |
lagrangian cloud::SU() returns different
|
#1 |
Member
Rishikesh
Join Date: Apr 2016
Posts: 63
Rep Power: 10 |
Hi all,I noticed the following when coupling lagrangian cloud with eulerian continuum. In the momentum source calculator function, MomentumCloud::SU() (for OF8+, otherwise it would probably be KinematicCloud::SU()), we see the following code:
Code:
if (solution_.semiImplicit("U")) { const volScalarField::Internal Vdt(this->mesh().V()*this->db().time().deltaT()); return UTrans()/Vdt - fvm::Sp(UCoeff()/Vdt, U) + UCoeff()/Vdt*U; } Where UCoeff and UTrans are the self-explanatory fields, derived by adding up the interaction from all member particles of the cloud. The returned object is an fvVectorMatrix, with the first and last are explicit components, and the middle term, the coefficient term. Now, if there is no "semi-implicit" flag, ie the source is purely an explicit term, the code returns: Code:
else { tmp<fvVectorMatrix> tfvm(new fvVectorMatrix(U, dimForce)); fvVectorMatrix& fvm = tfvm.ref(); fvm.source() = -UTrans()/(this->db().time().deltaT()); return tfvm; } Which is quite analogous to the explicit part of semi-implicit source above, but it does not have a division by cell volume. It appears to me that in general, we supply fvVectorMatrix terms on a per unit volume basis. What is then the reason behind difference in the divisor in the two cases. Is the second formulation correct? If it is, can someone help me understand why it is so? I would expect that the two should not even run with the same solver/case, based on dimensional considerations, but they do. However, I cannot find any other point in lagrangian libraries, where the semi-implicit flag is used to change the way in which UTrans is calculated differently depending of the flag. I would appreciate any help in enlightening me about this. Thanks |
|
March 21, 2022, 16:21 |
|
#2 |
Member
Utkan Caliskan
Join Date: Aug 2014
Posts: 42
Rep Power: 12 |
In the explicit formulation, it doesn't construct fvMatrix but assigns the field to the source of the fvMatrix, hence no division by volume.
|
|
March 22, 2022, 02:24 |
|
#3 | |
Member
Rishikesh
Join Date: Apr 2016
Posts: 63
Rep Power: 10 |
Hey,
Thank you for your answer! You say that Quote:
but, in the explicit case's code above doesn't Code:
tmp<fvVectorMatrix> tfvm(new fvVectorMatrix(U, dimForce)); fvVectorMatrix& fvm = tfvm.ref(); Thanks again. Last edited by mrishi; March 22, 2022 at 02:27. Reason: formatting |
||
March 23, 2022, 07:37 |
|
#4 |
Senior Member
|
Hi,
There is the section (3.4.9, P-43) about the source terms in Programmer's Guide. https://sourceforge.net/projects/openfoam/files/v2112/ With the implicit method, the term will be integrated over a control volume. This explanation is about a flow field, not about a lagrangian cloud. However, there may be some relations with your question. |
|
Tags |
lagrangian openfoam, semi-implicit-source |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Lagrangian particle tracking in mechanically agitated mono-dispersed and poly-dispers | anandjjadhaviitr | ANSYS | 0 | September 18, 2020 16:19 |
Pseudo-transient Lagrangian approach | ASimonsen | OpenFOAM Running, Solving & CFD | 0 | May 20, 2020 09:47 |
Compiling Lagrangian in a Lagrangian Particle Tracking Solver | tzaht | OpenFOAM Programming & Development | 3 | February 3, 2020 04:26 |
Aurelia Vallier, MultiScale, Eulerian-Lagrangian Couplling, VOF-LPT, Lagrangian, | saddy | OpenFOAM Programming & Development | 0 | August 9, 2017 15:28 |
converse lagrangian field to eulerian | Jan_B | OpenFOAM Programming & Development | 0 | August 13, 2015 14:11 |