[sita]

Hi Philip,

Ah yes, I should have thought of that! I now remember coming across this before, with the Hron-Turek FSI tutorial. And you're right, for my current application just the warp by vector trick should be sufficient. Apologies for my terrible memory...

Sita

[tom_flint2012]

Hi everyone,


I have developed a solver for simulating welding processes, using a volume of fluid approach for the interface between the liquid metal and atmosphere, and a Darcy source term in the momentum equations for the solidification of the material due to an energy transport equation.


Now I would like to extend this by being able to predict the residual stress generation in the solid region of the domain due to temperature dependent thermal expansion. I was hoping to get some pointers from the community here to make sure what I'm thinking is sensible/possible.


Would it be reasonable to couple the functionality of something like the deprecated newstressedfoam (I see the density can vary with position here) with my VOF solver, and make the density and stiffness moduli ($\mu$ and $\lambda$) functions of position (they will also vary with time as the material melts and solidifies). My idea is to make the material have no stiffness as far as the solid mechanics solution goes in the air and liquid metal regions. In my code I store a scalar field for the fluid fraction in the domain so this would be easy to vary the stiffness properties with this variable. I think I'd have to add the plasticity effects and thermal expansion to the newstressedfoam bity, but I think I have seen how to do this in a chalmers report.



I would ideally like to have all the functionality in one solver so I can see how the stresses develop during the process. Does what I am suggesting sound reasonable? I would really appreciate hearing peoples opinions on this.


Also if people are interested in collaborating with me on this that would be really great too. I'd love to create a fully working VOF/ residual stress predicting finite volume tool if that is something that would be of interest to others in the community.


Thanks in advance, I look forward to hearing peoples thoughts.


Tom

[sita]

Hi all,

In a 3D solid simulation I'm getting these warnings: Material linearity enforced for stability! However, the simulation finished without crashing, and according to the log file the momentum equation converged in all time steps. So now I'm wondering:

1. What do these warnings mean? Should I try to avoid them, and if so, how?

2. Could these warnings be (one of) the reason(s) that my results are incorrect (e.g. symmetry BCs violated)?

Some details about my simulation:
- foam-extend 4.0
- solidModel unsNonLinearGeometryTotalLagrangian
- mechanicalProperties: type StVenantKirchhoffElastic
- Equation relaxation for D: 0.99, field relaxation for D|DD: 0.9

Many thanks,
Sita

[bigphil]

Originally Posted by sita

In a 3D solid simulation I'm getting these warnings: Material linearity enforced for stability! However, the simulation finished without crashing, and according to the log file the momentum equation converged in all time steps. So now I'm wondering:

1. What do these warnings mean? Should I try to avoid them, and if so, how?

If the solver is diverging then it reverts to the more simple/stable linear elastic material law to help convergence; it then (ideally) reverts back to the real material law when convergence improves. If these warnings disappear by the end of the time-step then the results are unaffected. If however they are still being printed at the end of the time-step when the solver converges then the solution actually corresponds to linear elasticity.

Originally Posted by sita

2. Could these warnings be (one of) the reason(s) that my results are incorrect (e.g. symmetry BCs violated)?

No material law should violate symmetry BCs so I don't think it is related.

Originally Posted by sita

Some details about my simulation:
- foam-extend 4.0
- solidModel unsNonLinearGeometryTotalLagrangian
- mechanicalProperties: type StVenantKirchhoffElastic
- Equation relaxation for D: 0.99, field relaxation for D|DD: 0.9

I suggest you avoid using equation relaxation entirely (comment it out) as the solution is very sensitive to this value and 0.99 could in fact be quite a lot of relaxation (it may even give wrong results). In my experience, equation under-relaxation is a last resort and is only applicable is a few special cases.

Philip

[sita]

Hi Philip,

Thanks a lot for explaining where these warnings come from, and when to worry about them.

I'll try doing the simulation without equation relaxation, see if that helps.

Sita


EDIT: In the meantime I've tried removing the equation relaxation, but then I'm getting these warnings immediately in the first time step, so that doesn't seem to be the way to go in this case. I'll try some other adaptations now.

[tschenkel]

Hi All,


I had planned to switch to ESI Foam for my teaching (for ease of installation and available documentation), so did a few tests. Results are not favouring other variants of FOAM but foam-extend (which may not be surprising since Phil develops on fe).

All tests done on the development branch as of 28/12/2020.

OF v1812 and v1912: New ESI implementation of AMI does break solids4Foam, only RBF coupling is available. Simulation times are much slower than fe40 (by an order of magnitude): The Hron-Turek FSI3 benchmark takes around 10-12 hours for 6 seconds on fe40 (GGI), v1812 and v1912 (RBF) are at 3.18s after >30h (note that the first 2 seconds are not coupled, so the comparison is 5s in 10h vs 1.18s in 30h).

OF7: AMI does work (it is also easier to compile here, since there are no files to replace). Simulation times are comparable to fe40. GGI is not available in ESI or Foundation Foam, so fsiProperties needs to be edited (Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend")

There is still a difference in the results between fe40 and OF7, though:

OF7vsFE40_HT3-displacement.png

As you can see there seems to be more damping in the OF7 case. All settings are as per the tutorial case. The only changes are done by the solids4Foam scripts.

[tschenkel]

Originally Posted by sita

EDIT: In the meantime I've tried removing the equation relaxation, but then I'm getting these warnings immediately in the first time step, so that doesn't seem to be the way to go in this case. I'll try some other adaptations now.

Not sure that's the right approach here. As I understand it, the warning comes up because the code has too high deformation, which is more likely in the early iterations. As long as it stays (a) stable, and (b) the warnings are gone in the final iterations, these should not be a problem - whereas equation underrelaxation can prevent the code from reaching equilibrium - i.e. deliver a wrong result.

[sita]

Originally Posted by tschenkel

Not sure that's the right approach here. As I understand it, the warning comes up because the code has too high deformation, which is more likely in the early iterations. As long as it stays (a) stable, and (b) the warnings are gone in the final iterations, these should not be a problem - whereas equation underrelaxation can prevent the code from reaching equilibrium - i.e. deliver a wrong result.

Sorry, didn't notice your post at first, thanks for responding! Yes, I'm aware by now that equation underrelaxation isn't a great idea (see also @bigphil's response a few posts back). The "Material linearity enforced for stability!" warnings keep coming in my case though, right until the point where the whole case crashes (and the result looks awfully wrong...). Not sure, might have to do with the solid contact BC that I'm using. I'm now trying to set up my case without solid contact, hopefully that'll work.

Sita

[tschenkel]

Originally Posted by sita

Sorry, didn't notice your post at first, thanks for responding! Yes, I'm aware by now that equation underrelaxation isn't a great idea (see also @bigphil's response a few posts back). The "Material linearity enforced for stability!" warnings keep coming in my case though, right until the point where the whole case crashes (and the result looks awfully wrong...). Not sure, might have to do with the solid contact BC that I'm using. I'm now trying to set up my case without solid contact, hopefully that'll work.

Sita

Hi Sita,

I have just played around with some of the test cases and found something interesting that may help you as well.

There is no doubt that the IQN is more efficient than a classical underrelaxation method like Aitken (with adaptive relaxation).

However I have found that the IQN method can be a bit too aggressive sometimes. You can see that when you follow the forces that are calculated (and output in the logs), in that the forces jump from positive to negative sometimes before they start to settle. We could say the convergence is oscillatory stable here. This is expected behaviour for any Newton method, and usually not a big deal.

Sometimes the big displacements between FSI iterations can make one of the codes unstable though (for me the early warning sign is an increasing Courant number and there is little hope once it starts rising).

In these cases I also see a higher incidence of these "forced linear" messages (which as Phil said, are no problem if they ultimately go away).

I had good success switching to Aitken (with a relatively low initial relaxation factor- I start with 0.05, but some cases require 0.01) in these cases. Ideally I like the Aitken relaxation to increase monotonically, but that is not achievable in most cases, and Aitken is quite good at lowering the relaxation factor for a few iteration and catching a runaway solver (I can see the Co rising for an iteration, but then it comes back down again, as the Aitken algorithm lowers the relaxation factor).

Typically Aitken will take about 1.5 to 2 times as many iterations, so I use IQN where possible, but in difficult cases Aitken is worth a shot.



I may be biased, since we did not have IQN-ILS back in the day and Aitken was a revelation when we implemented our implicit coupling in MpCCI.

Maybe Phil has some insights on relative performance vs stability between IQN-ILS and Aitken.

[sita]

Originally Posted by tschenkel

Hi Sita,

I have just played around with some of the test cases and found something interesting that may help you as well.

There is no doubt that the IQN is more efficient than a classical underrelaxation method like Aitken (with adaptive relaxation).

However I have found that the IQN method can be a bit too aggressive sometimes. You can see that when you follow the forces that are calculated (and output in the logs), in that the forces jump from positive to negative sometimes before they start to settle. We could say the convergence is oscillatory stable here. This is expected behaviour for any Newton method, and usually not a big deal.

Sometimes the big displacements between FSI iterations can make one of the codes unstable though (for me the early warning sign is an increasing Courant number and there is little hope once it starts rising).

In these cases I also see a higher incidence of these "forced linear" messages (which as Phil said, are no problem if they ultimately go away).

I had good success switching to Aitken (with a relatively low initial relaxation factor- I start with 0.05, but some cases require 0.01) in these cases. Ideally I like the Aitken relaxation to increase monotonically, but that is not achievable in most cases, and Aitken is quite good at lowering the relaxation factor for a few iteration and catching a runaway solver (I can see the Co rising for an iteration, but then it comes back down again, as the Aitken algorithm lowers the relaxation factor).

Typically Aitken will take about 1.5 to 2 times as many iterations, so I use IQN where possible, but in difficult cases Aitken is worth a shot.



I may be biased, since we did not have IQN-ILS back in the day and Aitken was a revelation when we implemented our implicit coupling in MpCCI.

Maybe Phil has some insights on relative performance vs stability between IQN-ILS and Aitken.

Hi Torsten,

Thanks for all that! At the moment I haven't even gotten as far as FSI yet; I'm still only doing solid mechanics, with linearly increasing internal pressure. But in the end I'm hoping to get to the full FSI case, so I'm definitely going to look into your suggestions.

Sita

[sita]

Originally Posted by sita

Hi Philip,

Thanks a lot for explaining where these warnings come from, and when to worry about them.

I'll try doing the simulation without equation relaxation, see if that helps.

Sita

EDIT: In the meantime I've tried removing the equation relaxation, but then I'm getting these warnings immediately in the first time step, so that doesn't seem to be the way to go in this case. I'll try some other adaptations now.

Hi all,

It looks like I'm doing something fundamentally wrong here: I simplified my geometry, to remove all solidContact BCs, so now I've a fairly simple geometry, representing a quarter of a tube that's pinched at one end (see attached image). My intended simulation looks like this:

• Linearly increasing pressure in tube interior
• solidSymmetry BCs on symmetry planes (axial + front and back plane)
• solidTraction BCs on inside (with pressureSeries) and outside
• fixedDisplacement of (0 0 0) on two tinyPatches in the pinch point, one on the outside and one on the inside (in my previous version I had a little cylinder fixed on the outside to keep the pinch point in place)
• neoHookean material, with unsNonLinearGeometryTotalLagrangian solidModel
• No equation or field under-relaxation
• Parallel computation on 4 processors, using method simple
• Time steps of 0.01 s, total duration of 10 s

The simulation starts alright, but right from the beginning I'm getting these warnings "Material linearity enforced for stability!", and at 0.03 s the simulation crashes on a floating point exception.

Can anyone tell me from the information above whether there's something I might be doing wrong here?

Many thanks,
Sita

P.S. When I tried this with a 2D geometry it seemed to work alright (i.e. no warnings, result looked reasonably realistic)

[Fauster]

Dear foamer,


I have a problem. I would like to use the oscillateDisplacement boundary condition but the solver tells me

Unknown patchField type oscillateDisplacement for patch type wall

I have added in the controlDict file.

libs ("libsolids4FoamModels.so");

I am using

solidModel linearGeometryTotalDisplacement;

The oscillateDisplacement boundary condition is for D field.

What am I doing wrong ?


PS1 : solids4foam is compiled with OpenFOAM 1812
PS2 : the rotation bloc tutorial is not working (same error : unknow patchfield)
PS3 : I have the feeling that compilation error occur... After ./Allwmake, I got lot of message like this :

wmkdepend: could not open 'PrimitivePatchTemplate.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'PrimitivePatchInterpolationTemplate.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'oversetMesh.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'cyclicGgiPolyPatch.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'cyclicGgiFvPatchFields.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'PointPatchFieldMapper.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'globalPointPatchFields.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory
wmkdepend: could not open 'ComponentMixedPointPatchVectorField.H' for source file 'functionObjects/centrifugalBodyForce/centrifugalBodyForce.C': No such file or directory

Thanks a lot for your help


I have tested with foam-extend :


On Centos 7.5 :
- I am able to install foam-extend 4.1 but solids4foam installation fails !

- I am able to install foam-extend 4.0 and solids4foam installation works !

--The tutorial rotating block is working


On Ubuntu 20.04 LTS
- I am able to install foam-extend 4.1 and solids4foam installation works !



F

[bigphil]

Originally Posted by sita

Hi all,

It looks like I'm doing something fundamentally wrong here: I simplified my geometry, to remove all solidContact BCs, so now I've a fairly simple geometry, representing a quarter of a tube that's pinched at one end (see attached image). My intended simulation looks like this:

• Linearly increasing pressure in tube interior
• solidSymmetry BCs on symmetry planes (axial + front and back plane)
• solidTraction BCs on inside (with pressureSeries) and outside
• fixedDisplacement of (0 0 0) on two tinyPatches in the pinch point, one on the outside and one on the inside (in my previous version I had a little cylinder fixed on the outside to keep the pinch point in place)
• neoHookean material, with unsNonLinearGeometryTotalLagrangian solidModel
• No equation or field under-relaxation
• Parallel computation on 4 processors, using method simple
• Time steps of 0.01 s, total duration of 10 s

The simulation starts alright, but right from the beginning I'm getting these warnings "Material linearity enforced for stability!", and at 0.03 s the simulation crashes on a floating point exception.

Can anyone tell me from the information above whether there's something I might be doing wrong here?

Many thanks,
Sita

P.S. When I tried this with a 2D geometry it seemed to work alright (i.e. no warnings, result looked reasonably realistic)

Hi Sita,

If you get any converged time-steps, what does the deformation look like?
If you don't get any converged time-steps, then try your case with a larger E (Young's modulus) value (e.g. 5 times higher) and hopefully that will converge and give you an idea of the deformation.

Hopefully from that it will be possible to see where the model is starting to go wrong.

BTW, Torsten, I believe IQN-ILS should be state of the art and I am suspicious that the solids4foam IQN-ILS implementation is not as robust as it could/should be. For example, preCICE uses IQN-ILS by default and from talking with them it works well; also, the original author of IQN-ILS (Degroote) has very positive experiences with it in general; it is on my to-do list to compare the solids4foam IQN-ILS implementation with the Degroote IQN-ILS implementation: https://github.com/pyfsi/coconut, unless someone else wants to do it

[sita]

Hi Philip,

Thanks for getting back! No, I don't have any converged time steps unfortunately. Increasing E would make sense I suppose; I'm simulating a blood vessel, so the Young's modulus is fairly low. I'll try a higher value, see what any results look like.

Sita


EDIT: Ah wait, sorry, just remembered that I do have some results from an earlier attempt. Differences with my current case:

• I'm using a little cylinder with a solidContact BC to keep the pinched end of the tube in place here
• StVenantKirchhoff instead of neoHookean material
• Equation relaxation = 0.99

So basically everything you recommended not to do... In the attached images you can see that things start looking funny from around (saved) time step 50 (i.e. 5 s), and the geometry starts intersecting itself from just after time step 75, resulting in some spectacular sort of abstract artwork at time step 100.

[DOMaier]

Hello Philip,


in the solver i am developing, i need to get the bulk modulus of the materials to calculate the "fixed-stress" stabilisation term for biot's equations.

This works perfectly fine as long as there is only one material. However, as soon as i try to use the multi-material capabilities of solid4foam, the bulk-moduli i get have wrong dimensions ( [1 -3 0 0 0 0 0] instead of [1 -1 -2 0 0 0 0]). Looks like the bulk-moduli get diveded by an acceleration (probably gavity) when using multi-material.



As far as I was able to follow it, it must happen somewhere during the mapping from the solid submeshes to the basemesh.


Edit/Update: The Bug is in mechanicalModel.C in line 581. The tmp<volScalarField> is initialized with the dimensionSet "dimDensity", however it should be "dimPressure". It stays unnoticed because it is filled with references to the internal- and boundaryfield, which do not contain dimensions.


Best

Denis

[tschenkel]

Originally Posted by Fauster

Dear foamer,

PS1 : solids4foam is compiled with OpenFOAM 1812



I have tested with foam-extend :

On Centos 7.5 :
- I am able to install foam-extend 4.1 but solids4foam installation fails !

- I am able to install foam-extend 4.0 and solids4foam installation works !

On Ubuntu 20.04 LTS
- I am able to install foam-extend 4.1 and solids4foam installation works !

F

Just a few comments on the points above:


OF1812 and solids4Foam:


I did not have good results with ESI OpenFoam and solids4Foam, something seems to be amiss and the code runs around one order of magnitude slower. Not what you want when you do FSI, the one OoM added by the FSI loops is bad enough, if the (solid?) solver adds another one, then that's no good.

AMI in OF1812 also does not work with solids4Foam at the moment.

OF7 works better.



CentOS:

fe40 and solids4Foam compile and work nicely with the stock compiler on CentOS 7.

fe41 and solids4Foam only worked for me with gcc7.


Ubuntu:


It's the other way round, since Ubuntu 20.04 comes with gcc9 (gcc7 available), but fe40 required gcc5.

See the respective guides on:



https://openfoamwiki.net/index.php/I...oam-extend-4.0

https://openfoamwiki.net/index.php/I...oam-extend-4.1



Hope this helps.

[tschenkel]

Originally Posted by bigphil

Hi Sita,
BTW, Torsten, I believe IQN-ILS should be state of the art and I am suspicious that the solids4foam IQN-ILS implementation is not as robust as it could/should be. For example, preCICE uses IQN-ILS by default and from talking with them it works well; also, the original author of IQN-ILS (Degroote) has very positive experiences with it in general; it is on my to-do list to compare the solids4foam IQN-ILS implementation with the Degroote IQN-ILS implementation: https://github.com/pyfsi/coconut, unless someone else wants to do it

Hi Phil,


Thanks for the confirmation. I know DeGroote's work and agree that IQN-ILS should be the bee's knees, so it could be something in the implementation. Although I have played with my Moens-Korteweg case and preCICE and had stability issues as well, so it may simply be that I'm pushing it too hard.

The tests I base the "Aitken seems more stable" comment on is based on the Hron-Turek case, though (see the report draft I posted on bitbucket).



If you don't get round to it earlier I may take it as my summer project ;-) - it may take me a while, though. Which source files is the IQN-ILS defined in?

[bigphil]

Originally Posted by tschenkel

If you don't get round to it earlier I may take it as my summer project ;-) - it may take me a while, though. Which source files is the IQN-ILS defined in?

It is defined in:

solids4foam/src/solids4FoamModels/fluidSolidInterfaces/IQNILSCouplingInterface/IQNILSCouplingInterface.H
solids4foam/src/solids4FoamModels/fluidSolidInterfaces/IQNILSCouplingInterface/IQNILSCouplingInterface.C

In particular have a look at the "evolve()" function in the C file and the "updateDisplacement()" function just after it.

[bigphil]

Originally Posted by tschenkel

Just a few comments on the points above:


OF1812 and solids4Foam:


...

Thanks for the comments Torsten!

Actually I am in the process of setting up an auto-build script which checks solids4foam compiles with fe40/fe41/of1812/of1912/of7 via docker containers. Once setup, it is straight-forward to check other environments/compilers, assuming there is a suitable docker image. Adding in tutorial Alltest checks would be the next step.

[bigphil]

Originally Posted by DOMaier

Hello Philip,


in the solver i am developing, i need to get the bulk modulus of the materials to calculate the "fixed-stress" stabilisation term for biot's equations.

This works perfectly fine as long as there is only one material. However, as soon as i try to use the multi-material capabilities of solid4foam, the bulk-moduli i get have wrong dimensions ( [1 -3 0 0 0 0 0] instead of [1 -1 -2 0 0 0 0]). Looks like the bulk-moduli get diveded by an acceleration (probably gavity) when using multi-material.



As far as I was able to follow it, it must happen somewhere during the mapping from the solid submeshes to the basemesh.


Edit/Update: The Bug is in mechanicalModel.C in line 581. The tmp<volScalarField> is initialized with the dimensionSet "dimDensity", however it should be "dimPressure". It stays unnoticed because it is filled with references to the internal- and boundaryfield, which do not contain dimensions.


Best

Denis

Good catch. I have pushed the fix in commit a89ea8e4 to the development branch.