- Computational Cost
Yes, every instance of implicit coupling repeats the calculation of every solver involved in the implicit coupling. This is the price one pays for implicit coupling. The benefit one receives from implicit coupling is the convergence of the mapped quantities between the solvers at each time window. By definition, if one is performing implicit coupling they will pay a higher computational cost. The only way around this would be to hack the solver into only computing the particle model after other implicitly coupled values had converged, but if one does that they are effectively decoupling the particles from the rest of the fluid for those implicit coupling loops, so who’s to say that the implicit coupling of the other values is accurate anyway. It kind of defeats the purpose of implicit coupling.
- Inconsistency between pimpleFoam and MPPICFoam
As I’m sure you’re away, pimpleFoam and MPPICFoam are set up to handle their interactions with particles in fundamentally different ways. pimpleFoam treats the particles as a point source of momentum and does NOT consider the volume the particles occupy to have any influence on the fluid domain. MPPICFoam, however, considers BOTH the effect of the particle moment and the particle volume on the fluid domain. In addition, any interactions between the particles is not natively handled within pimpleFoam and will have to be handled explicitly within the kinematicCloud model. MPPICFoam, however, uses an implicit method to map the effect of the particles to the Eulerian (fluid) mesh, resulting in a particle-based stress gradient that’s computed on the Eulerian mesh and mapped back to the Lagrangian particles causing them to spread out if bunched. pimpleFoam paired with a kinematicClound Lagrangian particle solve should only be used for VERY LOW particle volume fraction applications (dilute sprays, HVAC dust, etc). MPPICFoam should be used on VERY HIGH particle volume fraction applications (fluidized beds, dense industrial reactors, etc.). There is another solver, DPMFoam that accounts for both momentum and volume effects of the Lagrangian particles on the fluid but still solves for the explicit interaction of the particles. This solver is very expensive for high particle density applications, but would need to be used for situations where precise particle bounding and intra-particle friction forces are of greatest concern (dense particle jets, spray break-up modelling, etc.)
All that is to say that your forces look pretty darn close for being computed from two fundamentally different approaches. I recognize that you’re attempting to run the models in the exact same way (without the presence of particles), so they should be the exact same. Thus, if I were super concerned with the differences, I’d focus in on the parts of the MPPICFoam solve that should be zero when there are no particles to see if they actually are truly zero. I don’t know this solver well enough to tell you where to look, but if you’ve gone far enough to hack this solver to only model particles on the first iteration of any precice implicit coupling loop, I’m sure you could figure out how to write a few custom values related to the particles to the solver registry to see if they are truly zero when you want them to be.
- Particle injection and escaped particles during coupling iterations
Yep, I think of handling the Lagrangian particle model in two ways.
The first is simply caching and restoring the state of the particles that exist in the Lagrangian domain. This can be handled entirely through the precice adapter function object. We simply set up an array that points to the particles we want to cache and store them in memory. At each implicit iteration we delete the particles that moved during that iteration and restore the particles from the beginning of the time window. Once the implicit coupling converges for that time window and we move onto the next window we update the particles that we have in our cache. If one of the particles escapes the domain during one of the implicit coupling iterations it’ll be restored from the cache. Only particles that should escape due to the converged implicit coupling solution will escape.
The second thing to consider is any new particles that are being added because we are injecting during our time window. This cannot be handled by the precice adapter function object because the function object can only affect things that are written to the solver registry, and nothing about the injector model is written to the registry. So, I had to create new injector types. When creating a cloud of particles (a cloud model) in OpenFOAM one has to specific how the particles in the cloud enter the domain. This is the OpenFOAM injection model, and there are different ways / locations one can use to inject particles. One of the most common is to inject particles at a domain boundary. This is the patchInjection type. patchInjection does a couple of things to determine how many and at exactly which locations the particles enter the domain, so I wrote a custom implicitPatchInjection model that users will need to use when they switch to implicit couping of Lagrangian particles using preCICE. This library does very similar things for the injectionModel that the adapter does for the particles – it caches values at the beginning of a time window and restores them if the implicit coupling goes back to the beginning of the time window. One of the things it caches is a fractional volume value that accounts for particle injections during a time step. It also caches a random number generator state that the injector model uses to map initial particle locations to a boundary surface that doesn’t have the same number of cells centers as particles. This means that each restored injection should be EXACTLY the same.
