Answered commented questions

This commit is contained in:
William Zunker
2025-01-03 14:29:14 -05:00
parent 629cb9d0d3
commit 534632a598
2 changed files with 16 additions and 1 deletions

View File

@ -139,6 +139,19 @@ void FixGranularMDR::setup_pre_force(int /*vflag*/)
// ANSWER2: So users cannot define 2 MDR models with different moduli? // ANSWER2: So users cannot define 2 MDR models with different moduli?
// Should an error be invoked if two MDR models are therefore defined? // Should an error be invoked if two MDR models are therefore defined?
// Should there be an error if a user uses a non-MDR model with an MDR model? // Should there be an error if a user uses a non-MDR model with an MDR model?
// ANSWER3: So users cannot define 2 MDR models with different moduli?
// -> Correct, as of now it only makes sense to have 1 MDR model with one set of material
// properties defined per simulation.
// Should an error be invoked if two MDR models are therefore defined?
// -> Yes, it would be good to have an error alerting the user that only 1 MDR model
// is allowed to be defined.
// Should there be an error if a user uses a non-MDR model with an MDR model?
// -> It depends, if it is a rolling or tangential model then its okay. We superimpose
// the MDR model with a rolling and tangential model for the tableting simulation.
// However, I don't think we should allow other normal models to be defined. I don't
// really know what it would mean physically if a hooke-particle contacted a mdr-particle.
// The gran/wall/region interaction should also be MDR so that the mean surface displacement
// is correctly calculated.
psi_b_coeff = norm_model->psi_b; psi_b_coeff = norm_model->psi_b;
@ -165,9 +178,10 @@ void FixGranularMDR::pre_force(int)
mean_surf_disp(); mean_surf_disp();
// QUESTION: What about fix wall/gran? // QUESTION: What about fix wall/gran?
// Answer: We never considered interaction between the mdr contact model and fix wall/gran // ANSWER: We never considered interaction between the mdr contact model and fix wall/gran
// ANSWER2: Ideally this would be added, but at least temporarily I added an // ANSWER2: Ideally this would be added, but at least temporarily I added an
// error. This incompatibility should be noted in the docs // error. This incompatibility should be noted in the docs
// ANSWER3: Sounds good.
auto fix_list = modify->get_fix_by_style("wall/gran"); auto fix_list = modify->get_fix_by_style("wall/gran");
for (int i = 0; i < fix_list.size(); i++) { for (int i = 0; i < fix_list.size(); i++) {

View File

@ -627,6 +627,7 @@ double GranSubModNormalMDR::calculate_forces()
// However, this is written in a bit of a strange way now that I am reviewing it, I will give it some more thought. // However, this is written in a bit of a strange way now that I am reviewing it, I will give it some more thought.
// ANSWER2: What if the contact type is WALL, then the iteration over contactSide = 0 will skip // ANSWER2: What if the contact type is WALL, then the iteration over contactSide = 0 will skip
// defining R0 and R1? Is that correct? // defining R0 and R1? Is that correct?
// ANSWER3: Correct, but in that case they are not needed since there is no partitioning of the displacement.
double delta_geo, delta_geo_alt; double delta_geo, delta_geo_alt;
double delta_geoOpt1 = deltamax * (deltamax - 2.0 * R1) / (2.0 * (deltamax - R0 - R1)); double delta_geoOpt1 = deltamax * (deltamax - 2.0 * R1) / (2.0 * (deltamax - R0 - R1));