move data averaging and output to separate file for better readability;
perform averaging for each size group and use mass-based (vs. number-
based) averages for global properties such as overall reduction,
resistance terms etc.
R2 means reduction from magnetite to wüstite and like in Kinaci et al.
(2020) we should assume that reduction from hematite to magnetite is
already completed to avoid mixing the reaction processes;
hence, start the simulation with a negligible hematite layer
only look up solidVolFractionName_ and lambda_ field if calculation of
multisphere drag (in calcForce() method) is requested via the option
'multisphere' - otherwise just set both to null
this way, specifying solidVolFractionName is optional and old case
setups will still work without modifications
I suppose the original author's intention was to print out the forces
from all procs, but Info just prints on master proc. Pout is the proper
alternative here.
add the option 'cartesianOutput' for the couplingProperties dict to
output particle positions as cartesian coordinates + cell index instead
of barycentric coordinates + cell index + tet face index + tet point
index in OF > 4
this format does not require parafoam but works fine with paraview, plus
it avoids the temporary creation of OF particles for writing the output
force construction of face-diagonal decomposition (called from all procs!) before call of particle constructor (potentially not on all procs!) to avoid blocking sync operation, when it looks for tet face index and tet point index.
fix#131
note that Us field is only use by cfdemSolverIBContinuousForcing but not
by cfdemSolverIB, so it may be better to call
cfdemCloudIB::calcForcingTerm(...) from cfdemSolverIBContinuousForcing
instead of cfdemCloudIB::evolve()
refactoring, use same name as the function doing Us field calculations
in cfdemCloudIBContinuousForcing;
note that cfdemCloudIB is considering angular velocities of particles
while cfdemCloudIBContinuousForcing does not
more appropriate naming:
RO (reduced order) referred to the RO model of red blood cells, but the
key difference in this solver is the momentum forcing term in the UEqn
more appropriate naming:
RO (reduced order) referred to the RO model of red blood cells, but the
key difference in this solver is the momentum forcing term in the UEqn
