View Issue Details

IDProjectCategoryView StatusLast Update
0003749OpenFOAMBugpublic2021-11-02 17:53
ReportermwildAssigned Towill 
PrioritylowSeverityfeatureReproducibilityN/A
Status closedResolutionno change required 
Product Version9 
Fixed in Version 
Summary0003749: Setting particle to arbitrary location
DescriptionPreface: This probably is something more of an "API-bug".

I'm trying to salvage my transported JPDF solver code from OpenFOM 1.7 / 2 days. Some context: In my code I had implemented a second order scheme where I first performed a half step, re-evaluated the mean velocity at the half-step position, applied the Langevin equation to evolve the fluctuating velocity components, perform mixing of the composition vector, apply density correction, etc. For the accuracy of the algorithm, it is very important that all these evaluations related to the JPDF method happen at the half step. All this resulted in the final velocity. I then put the particle back into its original position and then performed the full time step. This involved sending particles back to the original processor if they crossed processor boundaries in the first half step. If the particle had been reflected at a wall, I decayed to first order tracking.

Since then the particle tracking has been upgraded to (the much better) barycentric coordinates method. This came with rather drastic changes in the particle class' API. I am now lacking a way of putting the particle back into its original position at the beginning of the time step. I suppose that particle::locate(...) would do the trick, but it is private. All the particle properties related to its position are read-only or private.

So, I wonder; am I missing something (in which case I apologize)? Or is my use-case something new and would you either consider supporting it or accepting a patch allowing it?
TagsNo tags attached.

Activities

will

2021-11-02 08:40

manager   ~0012262

Predictor corrector schemes like this can be done with the clouds' "storeState" and "restoreState" methods. The sequence would go: Call "storeState", track, generate and distribute new velocities, call "restoreState" to put everything back at the start, apply the new velocities to the particles, then finally track again. It's a bit memory intensive compared to your previous method, but it will also handle other time-evolution behaviour correctly like the topology and relation to a moving mesh.

mwild

2021-11-02 11:22

reporter   ~0012263

Thanks, Will. So, indeed I was missing something. So if I understand correctly, the storeState functions to a full backup, including all the particles? Where would I best store the new quantities? The restoreState function trashes the particles, right? Is there a canonical example I could take inspiration from?

will

2021-11-02 17:53

manager   ~0012265

There is no carnonical example of this method available in the code, no.

My next question would be "what quantities?" and "what lifetime do they have?", but this is not the platform for such discussions. This site is for bug reports, and a bug in OpenFOAM has not been demonstrated, nor has a regression in functionality. This seems to me to be a matter of user support. Closing.

Issue History

Date Modified Username Field Change
2021-10-31 20:40 mwild New Issue
2021-11-02 08:40 will Note Added: 0012262
2021-11-02 11:22 mwild Note Added: 0012263
2021-11-02 17:53 will Assigned To => will
2021-11-02 17:53 will Status new => closed
2021-11-02 17:53 will Resolution open => no change required
2021-11-02 17:53 will Note Added: 0012265