CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions > OpenFOAM CC Toolkits for Fluid-Structure Interaction

[solidMechanics] Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend"

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree134Likes

Closed Thread
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 4, 2020, 14:18
Default Linear vs non-linear elastic solid simulation
  #581
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
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
bigphil likes this.
sita is offline  

Old   December 11, 2020, 13:09
Smile welding residual stress - coupled volume of fluid approach??
  #582
Member
 
Thomas Flint
Join Date: Jan 2016
Posts: 60
Rep Power: 10
tom_flint2012 is on a distinguished road
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
tom_flint2012 is offline  

Old   December 14, 2020, 03:11
Default Material linearity enforced for stability!
  #583
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
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
sita is offline  

Old   December 16, 2020, 10:50
Default
  #584
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,086
Rep Power: 34
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by sita View Post
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.

Quote:
Originally Posted by sita View Post
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.

Quote:
Originally Posted by sita View Post
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
bigphil is offline  

Old   December 16, 2020, 10:57
Default Material linearity enforced for stability!
  #585
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
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.

Last edited by sita; December 22, 2020 at 04:07. Reason: New information
sita is offline  

Old   December 29, 2020, 08:15
Default Different results and runtimes between fe, ESI foam and Foundation foam
  #586
Member
 
Torsten Schenkel
Join Date: Jan 2014
Posts: 69
Rep Power: 12
tschenkel is on a distinguished road
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.
bigphil likes this.
tschenkel is offline  

Old   December 29, 2020, 10:26
Default
  #587
Member
 
Torsten Schenkel
Join Date: Jan 2014
Posts: 69
Rep Power: 12
tschenkel is on a distinguished road
Quote:
Originally Posted by sita View Post
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.
tschenkel is offline  

Old   December 31, 2020, 08:48
Default Material linearity enforced for stability
  #588
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
Quote:
Originally Posted by tschenkel View Post
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

Last edited by sita; December 31, 2020 at 08:51. Reason: not yet finished, pressed enter too early...
sita is offline  

Old   December 31, 2020, 12:53
Default Aitken more stable than IQN-ILS?
  #589
Member
 
Torsten Schenkel
Join Date: Jan 2014
Posts: 69
Rep Power: 12
tschenkel is on a distinguished road
Quote:
Originally Posted by sita View Post
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.
bigphil and kcavatar like this.
tschenkel is offline  

Old   January 1, 2021, 14:50
Default
  #590
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
Quote:
Originally Posted by tschenkel View Post
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 is offline  

Old   January 7, 2021, 09:07
Default Warning: Material linearity enforced for stability!
  #591
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
Quote:
Originally Posted by sita View Post
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)
Attached Images
File Type: png geometry.png (106.1 KB, 21 views)

Last edited by sita; January 8, 2021 at 11:28. Reason: Additional info
sita is offline  

Old   January 8, 2021, 10:17
Default solids4foam and oscillateDisplacement
  #592
Member
 
Paul Palladium
Join Date: Jan 2016
Posts: 93
Rep Power: 10
Fauster is on a distinguished road
Dear foamer,


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

Quote:
Unknown patchField type oscillateDisplacement for patch type wall
I have added in the controlDict file.

Quote:
libs ("libsolids4FoamModels.so");
I am using
Quote:
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 :


Quote:
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

Last edited by Fauster; January 10, 2021 at 16:08. Reason: more info
Fauster is offline  

Old   January 12, 2021, 16:44
Default
  #593
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,086
Rep Power: 34
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by sita View Post
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
kcavatar likes this.
bigphil is offline  

Old   January 13, 2021, 02:47
Default Warning: Material linearity enforced for stability!
  #594
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 227
Rep Power: 18
sita is on a distinguished road
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.
Attached Images
File Type: png Cut50.png (40.6 KB, 23 views)
File Type: png Geo75_axial.png (63.1 KB, 18 views)
File Type: png Geo75_iso.png (132.8 KB, 24 views)
File Type: png Geo100_axial1.png (87.1 KB, 20 views)
File Type: png Geo100_iso.png (59.0 KB, 22 views)

Last edited by sita; January 13, 2021 at 03:42. Reason: Additional information
sita is offline  

Old   January 21, 2021, 11:21
Default Problems with multi-material/solidsubmeshes
  #595
New Member
 
Denis Maier
Join Date: Aug 2019
Posts: 17
Rep Power: 6
DOMaier is on a distinguished road
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
bigphil likes this.

Last edited by DOMaier; January 22, 2021 at 09:01.
DOMaier is offline  

Old   January 22, 2021, 10:49
Default
  #596
Member
 
Torsten Schenkel
Join Date: Jan 2014
Posts: 69
Rep Power: 12
tschenkel is on a distinguished road
Quote:
Originally Posted by Fauster View Post
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 is offline  

Old   January 22, 2021, 10:58
Default
  #597
Member
 
Torsten Schenkel
Join Date: Jan 2014
Posts: 69
Rep Power: 12
tschenkel is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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?
tschenkel is offline  

Old   January 28, 2021, 17:41
Default
  #598
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,086
Rep Power: 34
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by tschenkel View Post
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:
Code:
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 is offline  

Old   January 28, 2021, 17:46
Default
  #599
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,086
Rep Power: 34
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by tschenkel View Post
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 is offline  

Old   January 28, 2021, 17:58
Default
  #600
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,086
Rep Power: 34
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by DOMaier View Post
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.
DOMaier likes this.
bigphil is offline  

Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
GPU Linear Solvers for OpenFOAM gocarts OpenFOAM Announcements from Other Sources 37 August 17, 2022 15:22
[Virtualization] OpenFOAM oriented tutorial on using VMware Player - support thread wyldckat OpenFOAM Installation 2 July 11, 2012 17:01
New OpenFOAM Forum Structure jola OpenFOAM 2 October 19, 2011 07:55
Cross-compiling OpenFOAM 1.7.0 on Linux for Windows 32 and 64bits with Mingw-w64 wyldckat OpenFOAM Announcements from Other Sources 3 September 8, 2010 07:25
OpenFOAM Debian packaging current status problems and TODOs oseen OpenFOAM Installation 9 August 26, 2007 14:50


All times are GMT -4. The time now is 04:15.