Pipe flow with floating particles - error after dp decrease

RCBE

Dear all,

I created a model (SI units) consisting of two plates (distance 0.005), a fluid and a floating cylinder (relativeweight 1.1, radius=0.0005, position: in the middle). The fluid moves due to a constant external acceleration force (value 0.01). For the first trial dp was set to 0.0002. This worked well. Afterwards I decreased the dp value to 0.0001. This caused the following error immediately after the start (no error without floating particles!):

GPU: 'particle boundary out - type: Floating cause: Speed p:0 id:504 pos:(0.002532, 0.0, 0.001423)'
'particle boundary out - type: Floating cause: Speed p:1 id:503 pos:(0.002664, 0.0, 0.001472)'
'particle boundary out - type: Floating cause: Speed p:2 id:502 pos:(0.002795, 0.0, 0.001521)'
...
Text: A boundary particle was excluded.

CPU: 'particle boundary out - type: Floating cause: Speed p:2093 id:543 pos:(0.001802, 0.0, 0.002784)'
'particle boundary out - type: Floating cause: Speed p:2094 id:532 pos:(0.001802, 0.0, 0.002917)'
'particle boundary out - type: Floating cause: Speed p:2095 id:533 pos:(0.001936, 0.0, 0.002917)'
...
Text: Some floating particle was found outside the domain.

---------------
My settings are:

constantsdef:

gravity x="0" y="0" z="0"
rhop0 value="1000"
hswl value="0" auto="true"
gamma value="7"
speedsystem value="0" auto="true"
coefsound value="30"
speedsound value="0" auto="true"
b value="1.1200e+05" auto="false"
coefh value="1.5"
cflnumber value="0.2"

Parameters:
(rest see CasePeriodicity)

key="ViscoTreatment" value="2"
key="Visco" value="0.000001"
key="ViscoBoundFactor" value="1"
key="#Shifting" value="2"
key="#ShiftTFS" value="0"
key="TimeMax" value="1"
"TimeOut" value="0.01"
key="XPeriodicIncZ" value="0"

----------------

The only difference between the two trials is the dp value. I don't understand this.

Thank you in advance!!


Best regards

RCBE

Here the files:

https://www.dropbox.com/sh/00e03zgg4xzwewb/AACQ2dndZas9Q8a6N-JnYj64a?dl=0

Basti

Hey RCBE,

I stumbled across the same problem. I realized that, when using the 2nd viscosity treatment method (Laminar+SPS), we do sometimes need smaller CFL numbers as well as initial and minimum time steps, especially when dp is decreased. Otherwise, the simulation will crash (particle exploding) like it did in your case. I was not able to figure out a solution for this problem, except decreasing the mentioned time parameters dramatically.

Update 11:00: I noticed, that increasing the b value makes your simulation more stable. But there are still particle exluded. It doesn't crash instantly anymore tho.

Update 15:00: Your case is runing now with very low time steps on a Tesla K80 for 72 hours :P lets see if it runs stable. Please let me know if you find a better solution for your issue

RCBE

Hello Basti,

first of all thank you for your quick response.
CFL number was a good hint. I decreased only this number from 0.2 to 0.05 and the simulation was stable (simulation time: 2h on Nvidia Titan X).

Best regards

Basti

Ah perfect RCBE. It takes 01:48 now on a half K80 (2496 Cuda Cores) with your initial setup and CFL=0.05

Best regards

Alex

The problem comes from the values of the time step "dt".
By default the initial dt is computed as: dt_ini=h/Cs,
then dt is computed following the equations for the variable time step.

The error reads "cause: Speed".
We internally check if one particle can travel more than 2h (or cell size) during one time step in any direction. If this happens we exclude the particle since its speed is not consistent with the value of dt. When we exclude boundary of floating particles the simulation stops.

With a given value of dp, let us say dp1 we obtain h1,
so that dt_ini1=h1/Cs can be ok for the velocity of the particles once they are being accelerated,
however with a smaller value of dp, let us say dp2 we obtain h2,
so that dt_ini2=h2/Cs can not be ok to catch the fast motion of one particle.

That is why the simulation works with one resolution and crushes with finer resolution.

The solution can be to define a smaller DtIni or using different dimensions: note that you are defining a case with:
- domain size: 0.0049 x 0.0058
- cell size (2h): 0.000425
- acceleration: 0.01m/s^2
That is a huge acceleration for that problem so with finer resolution, particles travel too fast trough cell size.

RCBE

Hello Alex,

thank you for your answer. Basically I agree with you, but...

1) If the particles travel too fast through cell size, why do I get the same error for a much smaller acceleration (I decreased even to 1e-12) ?

2) If dt is the main problem, why do I get for really small values (e.g. dt_ini 1e-8, dt_min 1e-9 or even smaller) an error with cause POSITION?

3) Why is the only way to get a proper solution to decrease cflnumber from 0.2 to 0.05?

4) Why is there no problem without floating particles no matter how small dp is (I decreased dp to 0.00001, acc still 0.01)?


Best regards

Alex

Good questions.
When we have time we will look into your points.

To be honest, these cases you are running with those different options are cases we never tested. Since we are more focused on wave tanks and we have less experienced about running cases with floating bodies. We will work on this.
But your experience and questions will help us a lot.

Regards

Alex

In the cases I am checking I have tried:

1) really small values of dt_ini but this only solves the initial steps, then the problem comes out

2) using small cfl_number helps
if you look to the equation of the dt_variable:
dt_new=cfl_number*min(dt_f,dt_cv)
so it seems that dt_f and dt_cv are being computed right but then we need to use a smaller dt for the case of floating+acceleration

What I can not see is when you get the error with cause POSITION?

Regards

RCBE

Thanks for your effort.

I uploaded two files for the 'position'-error. Compared to the initial setup I only changed DtIni to 1e-8 and DtMin to 1e-9.

Run_dtini.out
CasePeriodicity_def_dtini.xml

https://www.dropbox.com/sh/00e03zgg4xzwewb/AACQ2dndZas9Q8a6N-JnYj64a?dl=0

Alex

Other problem is that using gravity=0,0,0
then h_swl (hswl value="0" auto="true" ) is not automatically computed.

In CasePeriodicity.out:
Maximum depth: 0 (automatic)
Speed of system: 0 (automatic)
Speed of sound: max(coefsound*speedsystem,10*sqrt(g*depth))
Speed of sound: 0 max(0,0)
and by default:
DtIni=h/speedsound
DtMin=coefdtmin*h/speedsound

So DtIni & DtMin are not correctly computed which can lead to problems.

Alex

Using gravity=0,0,0 => h_swl does know the direction to be computed.
This means that speedsystem will be always zero.

The SOLUTION here is to specify the value of the speedsound
speedsound value="XXXX" auto="false"

RCBE

The solution is not to specify the value of speedsound. This has no influence. In this case the 'b value' has to be increased.
The simulation starts with a b value > 1.0e+06.

So in summary there are two possibilities:
- increase b value
- decrease CFLnumber (better results)

Nevertheless it is still not 100 % clear and a bit confusing.

Alex

We will definitely check this to avoid confusion for the next release.
Thanks

RCBE

Thank you.
The problem re-occurred. We decreased dp value again (to 0.01e-3). It's not working. We changed b value, cfl number, speed of sound,...
I hope there will be a chance to use your code for microfluidic issues with floating bodies. Looking forward to the next release. Any date for the release available?