View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003749 | OpenFOAM | Bug | public | 2021-10-31 20:40 | 2021-11-02 17:53 |
Reporter | mwild | Assigned To | will | ||
Priority | low | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | no change required | ||
Product Version | 9 | ||||
Summary | 0003749: Setting particle to arbitrary location | ||||
Description | Preface: 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? | ||||
Tags | No tags attached. | ||||
|
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. |
|
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? |
|
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. |
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 |