CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Programming & Development (
-   -   Lagrangian Particle Tracking Initial step (

Bruce Hartley December 16, 2011 00:55

Lagrangian Particle Tracking Initial step
I have modified some particle tracking with OpenFoam to track particles in electromagnetic fields using the standard lagrangian solvers. I find that the first step from T=0 to the next time step is not consistent with the following steps. The particle's move is relatively large for the first time step by a factor of about 100 larger than the following ones and in a direction which is not compatible with the field. It seems to be dependent on the starting positions of the particles so may depend on the wall boundary conditions. Can anyone suggest what might be affecting the first step in the particle tracking and indicate how it might be overcome. Has anyone else noticed such a problem?

hemph December 16, 2011 01:50

Hi Bruce,
If you have done any restarts before, the first time step is governed by the deltaT that is in the uniform/time dictionary. This has tricked by this many times..


Bruce Hartley December 16, 2011 02:40

Lagrangian particle Tracking getting positions and other information
Hi, Rasmus,

Thank you for the reply but I'm afraid that I don't exactly understand what is required. Do I need to do something to the Control Dictionary or do I need to add another dictionary which specifies other time intervals or what? I have looked at wall conditions but can't seem to affect anything through them.

Can you give me an example of what I may need to do?


Bruce Hartley

hemph December 16, 2011 04:06

Sorry if I was not clear enough. If you are in your case-directory and change dir to a timestep other than 0, say 1.0, you will find a directory called uniform. Inside this directory you will find the time-dictionary, where deltaT is specified for this time step.

If you restart from 1.0 instead of 0, the first time step is read from this deltaT instead of the deltaT in system/controlDict.


Kabra September 2, 2015 05:32

Sorry for reviving such an old thread, but I have probably the same problem like described in this thread:
Lagragian particles get the right force but wrong velocity
It is the same factor of ~100 for me, too. it seems like for some reason the particle movement gets called several times under certain conditions which I yet don't understand. I traced my function calls, but there seems to be no difference between a timestep that calls the movement of the particle once and one that does it several times.

In case it's of interest here is the stack of function calls:


Obtained 15 stack frames.
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ rceINS_14KinematicCloudINS_5CloudINS_15KinematicPa rcelINS_8particleEEEEEEEE14calcNonCoupledERKS5_ddd d+0x4c) [0x7f91077e82ec]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ articleForceListINS_14KinematicCloudINS_5CloudINS_ 15KinematicParcelINS_8particleEEEEEEEE14calcNonCou pledERKS5_dddd+0xc6) [0x7f910605d4c6]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ inematicParcelINS_8particleEE12calcVelocityINS2_12 TrackingDataINS_14KinematicCloudINS_5CloudIS2_EEEE EEEEKNS_6VectorIdEERT_didddRSC_RSB_Rd+0xbd) [0x7f910606fd0d]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ nematicParcelINS_8particleEE4calcINS2_12TrackingDa taINS_14KinematicCloudINS_5CloudIS2_EEEEEEEEvRT_di +0x143) [0x7f9106070123]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ nematicParcelINS_8particleEE4moveINS2_12TrackingDa taINS_14KinematicCloudINS_5CloudIS2_EEEEEEEEbRT_d+ 0x380) [0x7f910607f370]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ jectionModelINS_14KinematicCloudINS_5CloudINS_15Ki nematicParcelINS_8particleEEEEEEEE6injectINS5_12Tr ackingDataIS7_EEEEvRT_+0x519) [0x7f910607f9e9]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ nematicCloudINS_5CloudINS_15KinematicParcelINS_8pa rticleEEEEEE11evolveCloudINS4_12TrackingDataIS6_EE EEvRT_+0x1d7) [0x7f9106089ce7]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ nematicCloudINS_5CloudINS_15KinematicParcelINS_8pa rticleEEEEEE5solveINS4_12TrackingDataIS6_EEEEvRT_+ 0xb0) [0x7f910608a4a0]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ nematicCloudINS_5CloudINS_15KinematicParcelINS_8pa rticleEEEEEE6evolveEv+0x226) [0x7f910608a766]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/ olveCloudFunctionObjectINS_14KinematicCloudINS_5Cl oudINS_15KinematicParcelINS_8particleEEEEEEEE7exec uteEb+0x2a) [0x7f910608a8da]
/software/lsmpool/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPOpt/lib/ eEb+0x59) [0x7f910e2d1f19]
/software/lsmpool/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPOpt/lib/ [0x7f910e2df160]
pimpleEFieldFoam() [0x420148]
/lib/x86_64-linux-gnu/ [0x7f910d21976d]
pimpleEFieldFoam() [0x424acd]
Second edit with SOLUTION(?):
Ok, the problem was just that the given density and particle diameter didn't fit to the chosen mass.
OpenFoam does everything correctly. It checks the particle's diameter and with the given density it calculates its mass and uses that and not what is given in the ParticleProperties under massTotal which is not the particles mass but the mass of all particles in the injected parcel.

All times are GMT -4. The time now is 03:38.