Generalized non-hourglass formulation for ULSPH solid dynamics

[Shuaihao-Zhang]

The generalized non-hourglass formulation for ULSPH solid dynamics.

Constitutive models include elasticity and plasticity (with/without hardening) are considered.

Two cases are uploaded for testing: test_2d_oscillating_beam_ULGNOG for elastic dynamics, and test_3d_taylor_bar_UL for plastic dynamics.

Regression tests are added.

[Shuaihao-Zhang]

One error occurs when running particle relaxation for test_3d_taylor_bar_UL . I haven't found the reason.
The CMakeLists.txt is same with other cases required particle relaxation. And the reload data can be generated on my own computer.

[Xiangyu-Hu]

One error occurs when running particle relaxation for test_3d_taylor_bar_UL . I haven't found the reason. The CMakeLists.txt is same with other cases required particle relaxation. And the reload data can be generated on my own computer.

On Github, everything is fresh new from zero. So this error may not happen on your machine as the code can use previously generated files.

[Shuaihao-Zhang]

One error occurs when running particle relaxation for test_3d_taylor_bar_UL . I haven't found the reason. The CMakeLists.txt is same with other cases required particle relaxation. And the reload data can be generated on my own computer.

@Xiangyu-Hu @DongWuTUM All tests passed.
It turns out, we must put system.handleCommandlineOptions(ac, av)->setIOEnvironment(); after system.setReloadParticles(true);.
Otherwise, it will trigger this issue when running CI tests.

[GUT2060]

Dear @Shuaihao-Zhang ,
i have some questions regarding this pull request as it is the implementation of the paper SPH-GNOG .

1- regarding the return mapping algorithm found in ShearStressRelaxationHourglassControlJ2Plasticity::interaction for the
plastic dynamic case test_3d_taylor_bar_UL:
while the paper's first step in the return mapping algorithm (appendixA) is the shear modulus update, there is no shear
modulus update in the code and the final stress is computed using the predefined shear modulus
g = lambda_dot_ * (sqrt(2.0) * G_ * shear_stress / (sqrt(stress_tensor_J2)));
return shear_stress_rate_elastic - g;
2- the scale_penalty force computed in the interaction function of the J2Plasticity

is not present in the appendix and its computation is the same as the retur mapping

i'm a bit confused about this part , could you please give more informations on what is this penalty force is for ? also, why
are we computing the return mapping again and updating the shear stress by multiplying it with the correction term

, the return mapping was already introduced in the constituveRelationShearStress as mentioned in the appendix

3- the ShearStressRelaxationHourglassControlJ2Plasticity has no update of its own and is as far as i understand using the
ShearAccelerationRelaxationHourglassControl update function in which the scale penalty force is used, however this
acceleleration update is different from the one suggested in the paper in the figure of the flow chart where the limiter is used
as in the DecomposedPlasticIntegration1stHalf

if you could please provide a clarifying information regarding why is the ShearStressRelaxationHourglassControlJ2Plasticity
shear_stress_acceleration is updated differently than the flow chart provided in the paper

4- i cannot find the Oobleck octopus case from the paper where a viscoplastic behavior is modeled. could you please direct me
to the case or the model implementation in the code .

thank you for taking the time to check these concerns

[Shuaihao-Zhang]

Dear @Shuaihao-Zhang , i have some questions regarding this pull request as it is the implementation of the paper SPH-GNOG .

@GUT2060 Hi, this pull request is not the code for the paper SPH-GNOG you mentioned.
This is another work using updated Lagrangian SPH.
For the corresponding code for the paper you mentioned, it's already in the main library, i.e., DecomposedPlasticIntegration1stHalf as you showed.

[Xiangyu-Hu]

Dear @Shuaihao-Zhang , i have some questions regarding this pull request as it is the implementation of the paper SPH-GNOG .

@GUT2060 Hi, this pull request is not the code for the paper SPH-GNOG you mentioned. This is another work using updated Lagrangian SPH. For the corresponding code for the paper you mentioned, it's already in the main library, i.e., DecomposedPlasticIntegration1stHalf as you showed.

@GUT2060 Could you initiate the this issue in the issue page? Also, Oobleck octopus case is too large as one of the (more than 150) test cases which will be run and finish at every update of pull request on a Github machine within a limited time.

@DongWuTUM Could you address this issue?

[DongWuTUM]

Dear @Shuaihao-Zhang , i have some questions regarding this pull request as it is the implementation of the paper SPH-GNOG .

@GUT2060 Hi, this pull request is not the code for the paper SPH-GNOG you mentioned. This is another work using updated Lagrangian SPH. For the corresponding code for the paper you mentioned, it's already in the main library, i.e., DecomposedPlasticIntegration1stHalf as you showed.

@GUT2060 Could you initiate the this issue in the issue page? Also, Oobleck octopus case is too large as one of the (more than 150) test cases which will be run and finish at every update of pull request on a Github machine within a limited time.

@DongWuTUM Could you address this issue?

Yes, sure.

[GUT2060]

@Xiangyu-Hu,
i will initiate an issue in the issue page.
@Shuaihao-Zhang,
thank you for pointing that out.

[Shuaihao-Zhang]

@Xiangyu-Hu @DongWuTUM
I have solved the conflicts with the latest version. Please check.

[Xiangyu-Hu]

@Shuaihao-Zhang Thanks. Could you have a self-check on the code quality before I do the review?

[Shuaihao-Zhang]

@Shuaihao-Zhang Thanks. Could you have a self-check on the code quality before I do the review?

Sure.

[Shuaihao-Zhang]

@DongWuTUM @Xiangyu-Hu
The code quality is improved. Please check again.
I put all the variables, which are not directly related to calculation, in the derived variables.
The neighbor searching are removed from initialization and update, only include in interaction.

[Xiangyu-Hu]

@Shuaihao-Zhang One more thing, the old algorithms which will not be used anymore should be deleted, as we will not maintain them anymore.

[Shuaihao-Zhang]

@Shuaihao-Zhang One more thing, the old algorithms which will not be used anymore should be deleted, as we will not maintain them anymore.

The codes related to ULSPH-ENOG are deleted, since the present ULSPH-GNOG is better.