View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002681 | OpenFOAM | Feature | public | 2017-08-30 14:56 | 2017-09-01 17:42 |
| Reporter | armin.shv | Assigned To | will | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
| Product Version | dev | ||||
| Summary | 0002681: Problem with the Lagrangian particle tracking with a transient carrier flow | ||||
| Description | As I said in the following link: https://www.cfd-online.com/Forums/openfoam-solving/191845-lagrangian-particle-tracking-transient-carrier-flow.html , I'm going to run a Lagrangian particle tracking after running a transient simulation for the continuous phase, which means: firstly, the time steps are already produced before the particle tracking and secondly, the carrier flow velocity changes in each time step. On the other hand, it seems that the current particle tracking in OpenFOAM has only been considered for the steady carrier flows (with fixed, i.e. "frozen" velocity). In other words, it reads the data from the start time and overwrites it in each time step during the solving. So it seems that it doesn't consider the changes of the continuous phase flow velocity in the next time steps. | ||||
| Additional Information | I tried to solve this issue by entering the following part into the solver (icoUncoupledKinematicParcelDyMFoam) code: Info<< "Reading field U\n" << endl; volVectorField U ( IOobject ( "U", runTime.timeName(), mesh, IOobject::MUST_READ, IOobject::NO_WRITE ), mesh ); It reads now the velocity in each time step, but apparently still doesn't apply it to the solving equations, because the results are as before. In conclusion, it seems that either it is only a read/write field problem, or one should change the code, where the velocity is applied to the particle tracking equations. | ||||
| Tags | Lagrangian, particle tracking, transient flow | ||||
|
|
You are correct that icoUncoupledKinematicParcelFoam operates using a frozen flow field. That is the intended behaviour at present. If you want unsteady coupling it is assumed that you will run a solver that evolves both the Eulerian and Lagrangian components simultaneously. Re-reading the Eulerian properties from disk during the Lagrangian calculation would require some sort of mapping/interpolation between the times considered in the Lagrangian simulation and the existing Eulerian time directories. That functionality does not exist. Can you contribute or fund this development? |
|
|
Thanks for your reply. I'm just a student and cannot support this development financially. But I'm working on this issue and have already prepared a coupled Eulerian-Lagrangian solver. However, there are two issues with it: 1) I'm still not sure, if it works correctly. Therefore, I'm looking for a way to check the validity of the solver. I'd also appreciate it if you could give me some hints to this purpose. 2) The coupled solver is very time-consuming for the users, who are satisfied with the results of the carrier flow simulation and want only to spend their time on the particle tracking part. The second issue leads also to this conclusion that the development of an "uncoupled" Lagrangian solver might be more convenient. For this purpose I'm running now the Lagrangian solver (icoUncoupledKinematicParcelDyMFoam) for a case with a "dynamic" startTime in controlDict assuming that: 1) the user has already considered and produced all needed time directories for the Lagrangian simulation before during the carrier flow simulation, 2) the change of the startTime "after each time step during the Lagrangian simulation" should entail the "reading and using" the velocity in each time step. It is still running, but up to now I can see the difference between the recent results from the simulation with a dynamic startTime and the old results from the simulation with a fixed startTime in ParaView. |
|
|
Your questions pertain to your own work. We do not provide support via this website. Assuming that all the required Eulerian data exists on disk is not viable. You need a mechanism of mapping between different time sequences for a simulation to utilise existing output. The proposed feature is rejected. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-08-30 14:56 | armin.shv | New Issue | |
| 2017-08-30 14:56 | armin.shv | Tag Attached: Lagrangian | |
| 2017-08-30 14:56 | armin.shv | Tag Attached: particle tracking | |
| 2017-08-30 14:56 | armin.shv | Tag Attached: transient flow | |
| 2017-08-31 15:15 | will | Note Added: 0008650 | |
| 2017-09-01 16:46 | armin.shv | Note Added: 0008655 | |
| 2017-09-01 17:42 | will | Assigned To | => will |
| 2017-09-01 17:42 | will | Status | new => closed |
| 2017-09-01 17:42 | will | Resolution | open => no change required |
| 2017-09-01 17:42 | will | Note Added: 0008659 |
