[Tobi]

Hey everybody,

at the moment I am trying to calculate a transient heat treatment of a complex aluminum alloy while estimating the displacement and stresses in the material. The combination is done in order to regulate the energy insertion based on the stresses because plastic deformation is not allowed. In order to fulfill this condition, the equilibrium stress (Von Mises) have to be lower than the yield strength of the material (yield strength is assumed to be constant during the heat treatment). However, I focus a few problems for the stress calculation:

• I read a few publications about the stress calculation in FV
• Also read the great PhD thesis from Philip Cardiff
• I derived the equation + BC and implemented it to my own solver
• I made a thermal validation and a 3D traction validation of my code - very good results as also given in the thesis of Philip

However, the main problem that I focus on is the following:

• In my geometry I have a heat-treatment that creates thermal deformations and therefore stresses. If you are familiar with the calculation, we are calculating the displacement vector with a lot of outer loops (so many explicit terms).
• Thus, the stress calculation of each time step is going to almost infinite outer loops. Okay, after 10.000 it will hopefully converge to 1e-6 but still it is too much for each time step.

What I did and checked out:

• I made a simple test geometry given in the attachment.
• I solved it with the solidEquilibriumDisplacementFoam, solidDisplacementFoam
• Result, solidDisplacementFoam is having a lot of problems to solve it (I mean the time to solve it) while the equilibrium solver does not converge but after 1000 Iterations, the solution will also not change anymore.
• In addition I compared it with my solver

Result of the simple geometry

• The equilibrium solver works very fast and the maximum Von Mises Stress was ~10.9 MPa
• The transient solver works extremely slow but finally went to the solution of the equilibrium solver ~

However, I realized (which is understandable) that the residual control (to leave the outer loops) are a main key in the accuracy of the transient stress calculation. E.g.: setting the outer loops to 5000 while changing the residual controls lead to the following output after the simulation ended (steady-state); used solver was my own one:

• 1e-3 ---- 4.7 MPa
• 1e-4 ---- 4.7 MPa
• 1e-5 ---- 9.0 MPa
• 1e-6 ---- 11.2 MPa
• 1e-7 ---- 11.4 MPa
• 1e-8 ---- 11.5 MPa

The calculation was performed for 1s while dt = 0.1s. If the 5000 outer loops were not sufficient in the first time step, the solver tried to get the convergence criterion during the next time steps (till it reaches it). After the convergence is reached at a specific time step, there was no change in the fields anymore (of course understandable). The outcome is as follows; at least for me:

• If the residual control will not be reached within the time step, the time step can be really bad predicted. E.g. if the initial residual of the displacement vector after 5000 outer loops is still somewhere around 0.0424, the solution in time is not accurate.
• However, even after 30.000 outer loops, the first time step will not converge (in my particular case)
• The more outer loops I make the sloper is the calculation per outer loop (more about that below)
• Finally, having a lot of outer loops within a particular time step will just cost a lot of computational time. Especially based on the slowing down of the outer loops (I don't know why).

Strange behavior during long outer loop correction

I focused a strange problem if we do a lot of outer loop corrections. The calculation time for each outer loop will significantly increase. The increase can be analyzed to behave like an exponential function (see picture). It is like using the following thing:

for(int i=0; i < 1e9; i++)
{
    test.append(i);
}

You may know that append is going through the existing array searching for the end and put the new value right after the last one which is extremely expensive if the array is very large. An example of my case: The first 1000 outer loops are really fast calculated (5.5s) while for example 1000 further outer loops betweenthe outer loops 4000 - 5000 take almost a minute or longer. Just imagine the time after 28.000 outer loops there is almost nothing going on (see graphic) Any idea about that? The solver itself does not make more iterations (maxIter 100) and I can really feel the decrease in calculation during the outer loops which I proofed with the output of the cpu time after each 50 outer loops. I expect to have a linear behavior or, if we go to lower residuals an increase of the iterations which I limit to 100.

Graphic explanation:

• The image shows the domain (1184 hex cells) and where I analyzed the equivalent stress for 4 different residual controls (exit the outer loop)
• Two figures show the dependency of the accuracy based on the residual control
• The calculation time image shows the increase of the calculation time during the outer loops. The line which is named expected has the slop of the first 100 outer loops (~ done in 0.29s). Expecting that the outer loop will not need more computational time, we should have an linear increase which is in fact not what we get
• The simulations are performed with my solver - however the solidDisplacementFoam behaves similar but will not converge at all :P; the schemes may be not the best - just used that one from the equilibrium solver because I wanted to check out if the transient solver can handle the beamEndLoadcase - but it failed (maybe I am doing something really bad or wront)

Summing up

• I made validation of 2d thermal and 3d stress which fits almost perfect
• However, I don 't trust what I did
• The transient calculation of one time step is almost not finishing
• If the displacement equation is converged and the system does only have fixed boundary conditions (no load change during time), the solver will run through the end
• If I have a time depended source (like thermal displacements), each time step (at least the first few one) are taking infinite long time - even if I increase my temperature just about 0.03K :/
• The longer I loop (outer loops) the slower the loop calculation get (I don't know whats going on here
• I am afraid that the solidDisplacementFoam cannot solve the 12 cell large case that is given in the equilibrium solver

My questions:

• Did anybody came across the outer loop problem?
• Did anybody solved transient complex stress calculation with FOAM?
• Does anybody know if there are thermal - load validation cases in 3D available?

In addition. I am using total Lagrange - Total Strain / Stress approach. I have no idea if an incremental approach would be better for transient problems. There are also other solver in the extend version available that accounts for plasticity and much more, but I am not interested in that. As I said - plasticity should be avoided.



Crazy stresses!
Finally, I hope someone can give an advice and that everything is clear mentioned.

[Tobi]

Hi everybody,... I have no Idea why there is only one picture. Therefore, the pictures I wanted to sent are attached now.

[Tobi]

Hey everybody,

a short update to the problems I focused above:

• Using lower time step (I am an idiot) is a very good choice to converge the system with a few outer correctors. However, now I have the problem to get a formula for adjusting the time step (1e-7) somehow. Does anybody know any relation for stress calculation like Courant for convection and or Fourier for thermal diffusion? Maybe I could also use the Fourier number - I will check it.

• Strange behavior of the outer loops. I made further checks and even in the pimpleFoam solver I get the linear increase of cpu time for the outer loops if we make more and more. I already made a tweak report. If someone is interested: https://bugs.openfoam.org/view.php?id=2516

[Tobi]

Just an info. Henry Weller just closed my bug report. So he is not really interested about that problem. Nice.

[Tobi]

An update to the monologue:

• During the weekend/yesterday and today I made a profiling of OpenFOAM with an large amount of outer loops.
• Based on the profiling results I figured out that the setSize(int) functions is slowing down the whole simulation in combination of ~List() destructor.
• With the profiling results I was able to find the code parts very fast and easily.
• Problem was that for each iteration we store the solver performance into a list, which will increase with the amount of outer loops or nonOrthogonal loops.
• The normal compilation of FOAM does not use the MEMCPY function and therefore the setSize(int) function is really limiting (really really).
• Recompiling FOAM with the necessary USEMEMCPY flag lead to the results that I would expect. Each outer loop is now similar

Okay, for normal fluid dynamics, the outer loops will not increase to 1000 or 10.000 but in my case it is necessary. However, after 200 outer loops we will see a speed up with the USEMEMCPY function.

I checked it with pimpleFoam and the calculation time for one time step and 10.000 outer loops was:


- standard compilation: 1922 s

- additional flag compilation: 317s


One additional graphic is attached.

Maybe someone can use it too.

[salachnaj]

Hi Tobi!
I know this reply is quite late, but I encounter similar problem while using solids4Foam solver for FSI simulations.

Can you explain how to recompile FOAM with the necessary USEMEMCPY flag ?

Regards,

[Tobi]

Hey, its okay that the thread is so old - that's why its there - to support others. During that time, I encountered two possible options:

• Compile with the flag
• Change the corresponding code

In order to compile with the USEMEMCPY flag, if I remember correctly, you need to modify the cOpt and c++Opt flags inside the

cd $WM_PROJECT_DIR/wmake/rules/linux-WHATEVERYOURCOMPILER/
cOpt
c++Opt
---------------------------------------

c++DBUG     =                                                                   
c++OPT      = -O3 -DUSEMEMCPY=1                                                
                                                                                
ROUNDING_MATH = -frounding-math

Re-source OpenFOAM and recompile. You should now see the flag -DUSEMEMCPY=1 within each compiled library/application.

Probably its enough to recompile the List class:

shorty@OpenFOAM-9: grep -rni -e "USEMEMCPY"
src/OpenFOAM/containers/Lists/List/List.C:111:        #ifdef USEMEMCPY
src/OpenFOAM/containers/Lists/List/List.C:170:        #ifdef USEMEMCPY
src/OpenFOAM/containers/Lists/List/List.C:300:                #ifdef USEMEMCPY
src/OpenFOAM/containers/Lists/List/List.C:382:        #ifdef USEMEMCPY
src/OpenFOAM/containers/Lists/UList/UList.C:47:        #ifdef USEMEMCPY
shorty@OpenFOAM-9:

You can also modify these files and comment the lines you don't need and recompile again (without any special flag). As you can see, the List class is the only class anymore which uses this flag.