tduretz / mdoodz6.0 Goto Github PK

Behavior: Pmax and P on particles always stayed at their initial value
Reason:
In UpdateParticlePressure particle pressure was updated based on mesh->dp; but mesh-dp doesn't seem to ever be used in the current version of the code (its value stays at 0), therefore P and Pmax were never updated.
Fix: I implement a quick fix: InterpGrid2P(particles->p from mesh->p_in). See commit 2814abf (August 20, 2020).

Task: If it is preferable to update using an increment of pressure (as was the case earlier), then a pressure increment must be computed and my fix must be modified.
If it's ok like that, the issue can be closed

The number of particles keeps increasing with inflow BC. The number of particles and as a result the memory footprint and the file size (if writer_markers==1) increases a lot.
It looks like new particles are added and particles that leave the box are not reused.
I'm gonna look into it. I just put the issue here as a reminder.

Sometimes density is negative on the particles. e.g.:

min(ttrans. part) = 0.000000e+00 max(ttrans. part) = 0.000000e+00
min(ttrans0_s) = 0.000000e+00 max(ttrans0_s) = 0.000000e+00
min(ttrans0_n) = 0.000000e+00 max(ttrans0_n) = 0.000000e+00
min(p0_s) = 1.511397e+07 max(p0_s) = 2.711069e+09
min(p0_n) = 1.511397e+07 max(p0_n) = 2.707674e+09
min(rho part ) = -3.103285e+03 max(rho part ) = 6.105800e+03
min(rho0_n ) = -9.485177e+01 max(rho0_n ) = 3.356855e+03
min(rho_s ) = 1.180333e+03 max(rho_s ) = 3.784672e+03
min(rho_n ) = 2.272670e+00 max(rho_n ) = 3.330000e+03
min(sxz0 ) = -6.939200e+08 max(sxz0 ) = 6.031215e+08
min(sxx0 ) = -8.415061e+08 max(sxx0 ) = 3.463778e+08
min(szz0 ) = -3.463885e+08 max(szz0 ) = 8.415060e+08
min(mu_s ) = 5.000000e+09 max(mu_s ) = 1.000000e+10
min(mu_n ) = 5.000000e+09 max(mu_n ) = 1.000000e+10
min(C_s ) = 1.000000e+06 max(C_s ) = 1.000000e+07
min(C_n ) = 1.000000e+06 max(C_n ) = 1.000000e+07
min(fric_s ) = 3.000000e+00 max(fric_s ) = 3.000000e+01
min(fric_n ) = 3.000000e+00 max(fric_n ) = 3.000000e+01
min(strain_s) = -1.742262e-02 max(strain_s) = 2.656891e+01
min(strain_n) = -1.518174e-02 max(strain_n) = 2.662281e+01
min(T ) = 2.954554e+02 max(T ) = 1.568386e+03
min(P ) = 1.511397e+07 max(P ) = 2.707674e+09
min(T part ) = -5.915515e+01 max(T part ) = 1.582395e+03

Although, somehow the output of rho_n looks OK.
But negative density causes the code to explode when using subgrid_diff on temperature
Subgrid diff is defined like that (RheologyDensity.c l1057):
for ( k=0; kNb_part; k++ ) {
if (particles->phase[k] != -1) {
p = particles->phase[k];
dtm = materials->Cv[p] * rho_part[k]/ (materials->k[p] * (1.0/dx/dx + 1.0/dz/dz));
dTms[k] = -( particles->T[k] - Tm0[k] ) * (1.0-exp(-d*model.dt/dtm);
}
}

if rho_part is negative then dtm is negative and the factor of diffusion (1.0-exp(-d*model.dt/dtm) is not bounded between 0 and 1 anymore but 1<=fac<+inf. Therefore, instead of diffusing, the temperature blows up and the code crashes.

A quick fix is to ensure that 0<=dtm<=1, like this:
for ( k=0; kNb_part; k++ ) {
if (particles->phase[k] != -1) {
p = particles->phase[k];
dtm = materials->Cv[p] * rho_part[k]/ (materials->k[p] * (1.0/dx/dx + 1.0/dz/dz));
double fac = fmax((1.0-exp(-d*model.dt/dtm)),.0);
dTms[k] = -( particles->T[k] - Tm0[k] ) * fac;
}
}

I pushed that fix in commit 20ee33e (August, 13, 2020)
That prevents the code from blowing up. But, we should probably fix the negative density in the first place.