[bigphil]

The post below is from an extract from an email conversation I recently had that some may find useful. The questions are in quotes followed by my replies.

I based the case on the impactBar tutorial in the elastoplasticity folder.
However, to get the simulation going I limited the ncorr to 100, so the solution did not converge to a "proper value". I mainly did it because the computation time was quite high and the average residuals were about 1e-3/1e-4.

OK. It is hard to say how much the results will be affected by this. What you can do is run the model twice, once with nCorr = 100 and once with it equal to 200 or 500 or 1000 and see if the predictions change much. If they do, then you probably need more correctors.

I would like to know how do you set the fvSchemes for your tutorials. For instance, in the impactBar tutorial, the schemes are the following:


How do you set the gradSchemes, divSchemes, snGradSchemes and interpolationSchemes?
Are they based on experience? Are these, generically speaking, good schemes for impact simulations?

d2dt and ddt:

If steady-state or quasi-static, set to "steadyState"
If transient where inertia effects are not negligible then set to “Euler”. In my experience, “backward” is not good. Note: if conservation of kinetic energy is important, you need to make sure to perform a time-step sensitivity analysis.
If you are not sure, then use “Euler”
gradSchemes:
always use “extendedLeastSquares 0”: it is the same as leastSquares but correctly accounts for boundary non-orthogonal corrections; extendedLeastSquares gives seconds order accuracy for all meshes
"Gauss linear” is OK on perfect structured grids but is poor on unstructured meshes so just stick with extendedLeastSquares

divSchemes:
this has less effects on the accuracy so "Gauss linear” is mostly fine
if you do notice some strange stresses related to the mesh then "Gauss skewCorrected linear” is a bit more accurate.

laplacianSchemes:
“Gauss linear corrected” is normally fine
if you do notice some strange stresses related to the mesh then "Gauss linear newSkewCorrected 1” is a bit more accurate.

snGradSchemes:
“corrected” is normally fine
if you do notice some strange stresses related to the mesh then "newSkewCorrected 1” is a bit more accurate.
interpolationSchemss:
linear is fine for all
for multi-material cases including a bi-material interface (i.e. where two different materials share an internal face) then “interpolate(impK) harmonic;” may improve convergence (it should not affect the answer though) but "interpolate(impK) linear;” is often fine.

So you can see there are not many choices to be made, compared with "div(phi, U)" ins fluids for example.

Currently I am creating a dummy case, where I have something similar to a toecap.
In this case I am using ncorr =1000 but the residuals at of the same order (1e-3/1e-4) and do not appear to converge to a smaller value. Can you tell me alternative discretization methods for impact simulation to see if I get better results? I tried several methods for the grad and div schemes but to be honest I do not really know when to use which method.

If convergence is a problem, then normally I do the following:
try a lower value for the D (or DD depending on the solidModel) under-relaxation factor in fvSolution:
first try change the fields value e.g. 0.7 or 0.5 or even 0.1. Setting it less than 0.1 will result in very slow convergence.
if that doesn’t work, try change the equation value e.g. 0.999 or 0.99. Values less than 0.99 can result in very slow convergence (or wrong answers): be careful with equation relaxation as the solution is very sensitive to it.
if you are using “solidContact" boundary conditions, these can cause convergence issues; in the solidContact boundary condition, try lower values for the “penaltyScale” e.g try 0.1 or 0.01 or 0.001. This controls the stiffness of springs between the master and slave surfaces. Smaller penaltyScale values will allow more overlap of the two surfaces but will improve convergence. The ideal value will give good convergence but with "small enough” overlap
you can also try smaller time-steps

Additionally, I intend to use this setup for a multi-material analysis (a composite of metal and a polymer). Do I need to have special attention to any of the discretization methods? In the tutorials some of the interpolation methods are different, specially the impk that is set to harmonic.

Yep, answered above.

Philip

[HPE]

Hi bigphil,

Is there any chance for you to consider to release your software as a submodule in OpenFOAM? Which would be win-win for users and your software?

Recently OpenQBMM seems to be released as a submodule there.

[bigphil]

Originally Posted by HPE

Hi bigphil,

Is there any chance for you to consider to release your software as a submodule in OpenFOAM? Which would be win-win for users and your software?

Recently OpenQBMM seems to be released as a submodule there.

Thanks for the suggestion,

I would be happy to. From a very quick browse through the OpenQBMM website I can't seem to find a reference to the submodule installation appropriate. Is there a link or instructions you can provide?

Thanks!

[HPE]

Hi,

I think the easiest way is to create a `feature request` in GitLab.

For example, OpenQBMM was added through a ticket: GitLab-1522.

[bigphil]

Originally Posted by HPE

Hi,

I think the easiest way is to create a `feature request` in GitLab.

For example, OpenQBMM was added through a ticket: GitLab-1522.

Thank you, very nice idea.

Before doing this, I need to merge the OpenFOAM ESI and Foundation ports into the master branch of solids4foam, but this is definitely a nice idea.

[HPE]

Thank you for your interest.

I would nevertheless create a feature request like this one made for sedFOAM: https://develop.openfoam.com/Develop...am/issues/1601

I believe the main OF maintainers would do their best to give a hand for your rebasing, and share the pain, if need be (albeit a slow-paced help).

Again thank you very much for your contributions to the community.

[hoehnp]

Hi Philip,

do you have some insights why "backward" is "not good"?

Originally Posted by bigphil

d2dt and ddt:

If steady-state or quasi-static, set to "steadyState"
If transient where inertia effects are not negligible then set to “Euler”. In my experience, “backward” is not good. Note: if conservation of kinetic energy is important, you need to make sure to perform a time-step sensitivity analysis.

Philip

[bigphil]

Originally Posted by hoehnp

Hi Philip,

do you have some insights why "backward" is "not good"?

Hi Patrick,

Actually, based on my more recent experience (and results of others), this statement about "backward" being "not good" is not true.

So, if you want greater temporal accuracy, backward will produce far less diffusion (energy loss) than Euler for the same time-step (in general).
In my presentation at OFW17 "Implementing a block-coupled implicit vertex-centred finite volume approach for solid mechanics in OpenFOAM", I compared 1st order Euler, 2nd order backward and 2nd order Newmark-beta (for the chosen parameters, this is equivalent to Trapezoidal rule and Crank-Nicolson); you can see the comparison on slide 53.

One note of caution, be careful that the old and old-old displacement fields are correctly initialised (e.g. to zero), otherwise the backward scheme may blow up at the start. Or, even better, use 1st order Euler for the first step.