[Bruce Hartley]

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]

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..

//Rasmus

[Bruce Hartley]

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?

Thanks

Bruce Hartley

[hemph]

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.

//Rasmus

[Kabra]

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.


EDIT:
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/liblagrangianIntermediate.so(_ZNK4Foam13ElectricFo rceINS_14KinematicCloudINS_5CloudINS_15KinematicPa rcelINS_8particleEEEEEEEE14calcNonCoupledERKS5_ddd d+0x4c) [0x7f91077e82ec]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZNK4Foam17P articleForceListINS_14KinematicCloudINS_5CloudINS_ 15KinematicParcelINS_8particleEEEEEEEE14calcNonCou pledERKS5_dddd+0xc6) [0x7f910605d4c6]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZNK4Foam15K inematicParcelINS_8particleEE12calcVelocityINS2_12 TrackingDataINS_14KinematicCloudINS_5CloudIS2_EEEE EEEEKNS_6VectorIdEERT_didddRSC_RSB_Rd+0xbd) [0x7f910606fd0d]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam15Ki nematicParcelINS_8particleEE4calcINS2_12TrackingDa taINS_14KinematicCloudINS_5CloudIS2_EEEEEEEEvRT_di +0x143) [0x7f9106070123]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam15Ki nematicParcelINS_8particleEE4moveINS2_12TrackingDa taINS_14KinematicCloudINS_5CloudIS2_EEEEEEEEbRT_d+ 0x380) [0x7f910607f370]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam14In jectionModelINS_14KinematicCloudINS_5CloudINS_15Ki nematicParcelINS_8particleEEEEEEEE6injectINS5_12Tr ackingDataIS7_EEEEvRT_+0x519) [0x7f910607f9e9]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam14Ki nematicCloudINS_5CloudINS_15KinematicParcelINS_8pa rticleEEEEEE11evolveCloudINS4_12TrackingDataIS6_EE EEvRT_+0x1d7) [0x7f9106089ce7]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam14Ki nematicCloudINS_5CloudINS_15KinematicParcelINS_8pa rticleEEEEEE5solveINS4_12TrackingDataIS6_EEEEvRT_+ 0xb0) [0x7f910608a4a0]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam14Ki nematicCloudINS_5CloudINS_15KinematicParcelINS_8pa rticleEEEEEE6evolveEv+0x226) [0x7f910608a766]
/home/maurer/OpenFOAM/maurer-2.3.0/platforms/linux64GccDPOpt/lib/libsimpleLagrangianFunctionObjects.so(_ZN4Foam25Ev olveCloudFunctionObjectINS_14KinematicCloudINS_5Cl oudINS_15KinematicParcelINS_8particleEEEEEEEE7exec uteEb+0x2a) [0x7f910608a8da]
/software/lsmpool/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7execut eEb+0x59) [0x7f910e2d1f19]
/software/lsmpool/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0xb0) [0x7f910e2df160]
pimpleEFieldFoam() [0x420148]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [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.