|
|
|
|
|
cell edge hangup.png (65,409 bytes) |
|
|
We have also encountered this kind of a problem (also with custom solvers), where parcels occasionally get stuck in a corner/wedge between two walls. I haven't managed to reproduce it in a test case, so I'm not sure what is causing it. However, at least theoretically, if two walls have a rebound boundary condition, a particle can get stuck bouncing between them indefinitely. Also, if some force is driving the particle towards the corner or it is sharp, the time steps can get smaller and smaller as the parcel gets closer and closer to the corner. What kind of boundary conditions you have? Currently we have sidestepped these issues by adding a maxIters counter, which stops the tracking if too many steps are taken. |
|
|
We chose (completely elastic) rebound as a boundary condition and a force pushing it into that direction is certainly possible (a random walk is involved). Judging by the log file, the particle is certainly undergoing periodic motion: $ cat log_hanging.gz | gunzip | grep "End global" [1] End global coordinates = (0.125 0.233763 2.28944e-12) [1] End global coordinates = (0.125 0.233763 1.59718e-12) [1] End global coordinates = (0.125 0.233763 -4.09404e-27) [1] End global coordinates = (0.125 0.233763 -4.09404e-27) [1] End global coordinates = (0.125 0.233763 1.59718e-12) [1] End global coordinates = (0.125 0.233763 2.28944e-12) [1] End global coordinates = (0.125 0.233763 2.28944e-12) [1] End global coordinates = (0.125 0.233763 1.59718e-12) [1] End global coordinates = (0.125 0.233763 -4.09404e-27) [1] End global coordinates = (0.125 0.233763 -4.09404e-27) [1] End global coordinates = (0.125 0.233763 1.59718e-12) [1] End global coordinates = (0.125 0.233763 2.28944e-12) ... Adapting the testcase you provided in "0002282: Lagrangian parcels, small issue in setCellValues" by adding a particle on one of the edges, I wasn't able to reproduce the issue. We will attempt to add an iteration limiter as well, thank you for the suggestion. |
|
|
Yes, with completely elastic walls the infinite loops is actually physically the correct behavior as there is nothing taking away the energy. However, even with non ideal walls the parcel can get stuck taking small steps as only a percentage of energy is taken away at each hit, so the parcel never completely stops. Also, even if the parcel would stop, if there is an external force, it can feed the motion. In any case, your problems probably started after the switch to the new tracking algo? With the old algo the particles would have been likely removed in these cases as it had to rescue stuck parcels anyway. Even though the new algo doesn't need the rescues, some sort of a kill switch (such as the step limit) might be generally useful? |
|
|
The reason we removed the kill switch is because it made the Lagrangian library tolerant to a variety of bugs. I do not want to put it back in, because it will prevent issues like this from being discovered and reported. In the long run, developments will be made that fundamentally depend upon the kill switch; that's the state that we were at with the old tracking algorithm. I would like to investigate what aspect of the tracking or the kinematic modelling is causing an infinite loop like this to form. I need a case which reliably reproduces the issue in order to do this. Without an external force, the particle shouldn't enter an infinite loop, even if the collisions are perfectly elastic. It should bounce out of a corner. In my experience, a body force (e.g., gravity) pushing a particle towards a wall doesn't generate a loop, but a drag force does. If the latter is happening, this probably means that the boundary conditions are wrong; i.e., particles set to rebound from an outlet patch. |
|
|
> The reason we removed the kill switch is because it made the Lagrangian library tolerant to a variety of bugs. I do not want to put it back in, because it will prevent issues like this from being discovered and reported. In the long run, developments will be made that fundamentally depend upon the kill switch; that's the state that we were at with the old tracking algorithm. This is a very valid point and I wouldn't recommend adding the old rescue system. However, we have found the maxIter (with a counter of the aborted parcels printed in log) to be useful also in limiting the maximum execution time of the whole particle update. (steady state reactive parcels with potentially very long lifetimes) > In my experience, a body force (e.g., gravity) pushing a particle towards a wall doesn't generate a loop Yes, it may be so. I have been trying with gravity and various geometries, but with no luck at reproducing. > If the latter is happening, this probably means that the boundary conditions are wrong; i.e., particles set to rebound from an outlet patch. Turbulent dispersion models can create a velocity that is towards a wall. Also non-converged velocity fields and multiphase flows can have such situations. |
|
|
Presumably the iteration count increments within the loop in KinematicParcel::move? The major disadvantage of this is that the count would have to be stored on the particle, so that infinite loops which include the crossing of a processor boundary can also be broken. Maybe it is unavoidable, but given the downsides, I would like a case that proves it is necessary. I hadn't considered dispersion models. I guess that it is only gradient dispersion that is an issue, as stochastic will vary per loop, and is therefore guaranteed to push away from the wall eventually. We could fix the gradient dispersion model so that it doesn't generate into-wall velocities. Do you know if dispersion models are actually to blame? Have you tried turning them off? I don't think convergence or multiphase are an issue. As long as you are using cellPoint interpolation for the velocity field, the (normal) velocity will become zero at any boundary on which a rebound is physical. I suppose we are implicitly disallowing any sort of membrane that the fluid gets through but the particles don't. I'm assuming that this isn't actually what is being modelled. |
|
|
I have, in the past, tested logic along the lines of: "If the particle has just left a wall, but as a result of calc(...) is now heading back to the wall, abandon the track in some manner." The problem with this, as the log file demonstrates, is it only fixes loops which are local to a single face/cell. The particle in this case is changing direction and is moving between at least two faces and across multiple tets. To identify this situation logically is nearly impossible when you consider that there might be a processor boundary that the loop crosses. |
|
|
> Presumably the iteration count increments within the loop in KinematicParcel::move? Yes and with user definable maximum (default off) stored in cloudSolution and a counter of total amount of parcels that reached the limit that is reported in log (usually zero). Currently we don't store the counter in the parcel, so it is only local to a processor. This has been sufficient for us, but of course multiproc loops are possible. (If the loop takes a finite time, max track time will eventually kick in) > I hadn't considered dispersion models. I guess that it is only gradient dispersion that is an issue, as stochastic will vary per loop, and is therefore guaranteed to push away from the wall eventually. We could fix the gradient dispersion model so that it doesn't generate into-wall velocities. Do you know if dispersion models are actually to blame? Have you tried turning them off? In our case it is not probably related to dispersion and more likely due to using cell interpolation with strong drag coupling. Dispersion is just something that is available in the official code that could also potentially cause these kinds of problems in valid use cases. I'm not sure if stochastic helps, because if a parcel is stuck with tiny timesteps, it can take very many iterations to exceed tTurbLoc so that a new random velocity is computed. > I don't think convergence or multiphase are an issue. As long as you are using cellPoint interpolation for the velocity field, the (normal) velocity will become zero at any boundary on which a rebound is physical. Yes, this would probably help. However, I'm actually quite often using cell interpolation. The reason for this is that with cellPoint I have had clearly unphysical velocities with non perfect meshes and the problems went away with cell interpolation. It was quite a while ago though and with the old tracking algo and custom code, so it may not be a general problem. BTW, to give a positive feedback, very good job with the new tracking code and cleanup! Overall I'm very happy with it and it is a relief that we can live without the rescues and such. |
|
|
You are right about the dispersion models. I thought it was adding a new random component on every loop. I agree that this could cause a sustained velocity into the wall. I guess we would have to fix this model, too. I don't recommend using cell interpolation. It can generate hangs even on internal faces. The velocity interpolation needs to be continuous. cellPoint might be a bit better now. Interpolation weights are guaranteed not to go negative, which wasn't the case before. We are falling into the trap of discussing every possible scenario, when what I think we need is evidence. Let's see if @pkieck generates a case, and go from there if so. > BTW, to give a positive feedback, ... Thanks! I hope we have made things better, and it's nice to see it perceived that way, despite the usual niggles. |
|
|
> @will: In our case it is not probably related to dispersion and more likely due to using cell interpolation with strong drag coupling. As long as you are using cellPoint interpolation for the velocity field, the (normal) velocity will become zero at any boundary on which a rebound is physical. You are correct. Switching to cellPoint interpolation AND changing the boundary conditions on the velocity field (it was generated by a different code) from zeroGradient to noSlip solved the problem. > The reason we removed the kill switch is because it made the Lagrangian library tolerant to a variety of bugs. In this case it was certainly a good decision, as we would not have caught the error otherwise. We previously attributed the tracking rescues with OF4x to a messy mesh. > @tniemi: Yes and with user definable maximum (default off) stored in cloudSolution and a counter of total amount of parcels that reached the limit that is reported in log (usually zero). Currently we don't store the counter in the parcel, so it is only local to a processor. This has been sufficient for us, but of course multiproc loops are possible. (If the loop takes a finite time, max track time will eventually kick in). An iteration counter, which would report if some number of iterations is exceeded would certainly come in handy. The current state of affairs led to the following workflow in case of "hangups": 1. kill simulation 2. rerun it, trying to switch the particle DebugSwitch on as soon to the time of the hangup 3. sift through gigabytes of log data > very good job with the new tracking code and cleanup! Overall I'm very happy with it and it is a relief that we can live without the rescues and such. I agree wholeheartedly! The overhaul made my life a lot easier. Thank you very much for your suggestions and the kind help! |
|
|
Ok, well if this was an issue with interpolation and/or boundary conditions then I think this can be closed as "no action required". Naturally if a hang can be generated reliably on a simple case with appropriate interpolation and patch interaction methods, then this bug report could be reopened. There's certainly some merit to saying we need a failure mechanism other than just hanging. I think it needs to be a failure, rather than a warning, otherwise issues like this with the case setup won't be caught. I'm not completely sure how to do it, though. If we put an iteration counter in the KinematicParcel loop, then we miss any processor-spanning hangs, and we have to replicate the logic in solidParticle, DSMCParcel and molecule (there may be others). There probably needs to be another layer of indirection to unify the looping, so that we can add this test in a single place. Then, there needs to be another test at the Cloud level to catch the parallel cases. I'll add these changes to the wish list. |
- Anonymous
