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

LinkBack  Thread Tools  Display Modes 
June 19, 2017, 03:24 

#361  
Senior Member
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 643
Rep Power: 23 
Quote:
In foamextend4.0, these lines: Code:
lduMatrix::solverPerformance solverPerfP; lduMatrix::solverPerformance solverPerfDU; Code:
lduSolverPerformance solverPerfP; lduSolverPerformance solverPerfDU; Code:
word correct=word(runTime.controlDic t().lookup("correctPlasticity")); Philip 

June 29, 2017, 16:54 

#362 
New Member
Tom Dylan
Join Date: May 2015
Posts: 20
Rep Power: 4 
Thank you very much for this hint, Philip!
Now the solver is compiled without any errors. And that was the reason for confusion: lduMatrix::solverPerformance > lduSolverPerformance Is there any documentation out there of the syntax changes during the evolution of o30ext  o40ext? Next time I might check the errors myself. The modifications I am trying to implement is to consider the dependence of the fluid (gas & water mixture) stiffness K' (equivalent to the fluid compressibility 1/K') from the actual pore pressure. This of course enhances the nonlinearity since the pore pressure equation is affected by the volumetric strain increment *and* the change of the fluid stiffness K' in response to pore pressure changes. First tests indicate numerous iterations and nonconvergence after a couple of time steps. However, a "lagged scheme" in which K' from the previous time step is considered (instead of simultaneous evaluation of K' within the iteration loop) yields reasonable results. These of course depend on the time step size selection... Strongly non linear systems (e. g. unsaturated flow in porous media) sometimes are addressed through Picarditeration approaches. I wonder if a Picard scheme might improve the convergence of the current problem. Anyway, I succeeded installing o40x in opensuse leap 42.2. thanks again for your support! Tom 

June 30, 2017, 04:35 

#363  
Senior Member
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 643
Rep Power: 23 
Hi Tom,
I am glad the code is now compiling for you. Quote:
Quote:
Underrelaxation of the K field will probably help, or more underrelaxation of the p and U fields (equations and fields). Philip 

July 10, 2017, 04:27 
fsiFoam in extend4.0 / running in parallel

#364 
New Member
Georg Göbel
Join Date: Sep 2016
Location: Karlsruhe
Posts: 3
Rep Power: 3 
Hello fsiFoamers,
is anyone running fsiFoam on ext4.0 in parallel? In the ext3.1 version there was this decomposeParFsitool, which was easy to use and worked fine, but on ext4.0 there is nothing like that. The Allrun skript suggest the use of standard decomposePar, but all my parallel jobs break while calling the first solid solver. It could depend on our machine here so it would be nice, if some of you could give me some short information about your experiences in running the ext4.0 version of fsiFoam in parallel. Thanks a lot in advance Georg BTW: the robinbc approach in the ext4.0 version is much more stable, even for high fluid density! Thanks to everyone who took part in developing, i highly appreciate your work. 

July 10, 2017, 08:24 

#365 
New Member
Iago Lessa
Join Date: May 2015
Posts: 5
Rep Power: 4 
Hello Georg,
I've been using fsiFoam for a couple months now and also used version 3.2 before. While for version 3.2 I was only able to decompose my cases with decomposeParFsi, in version 4.0 decomposePar worked great. There are only two issues I found so far: 1) I was not able to visualize the partitions on ParaView and 2) If I decompose from the latest timestep which is different from zero, the decomposition does not create the directory "processor*/constant" (instead, the utility name it "processor*/0") However, since you say your solid solver is not called properly in run time, did you link the fluid and solid directories? I think this already happened to me, and I remember that I missed the links between fluid and solid. Is there any error message ? Iago iago 

July 11, 2017, 10:24 

#366 
New Member
Georg Göbel
Join Date: Sep 2016
Location: Karlsruhe
Posts: 3
Rep Power: 3 
Hello Iago,
thanks for your reply. Now i know that the problem is somewhere on our machine or local extend installation. I was succesfully viszualizing the partitions with foamToVTK. It works both in 3.1 and 4.0. Georg 

July 12, 2017, 05:57 
implementing spatial heterogeneity of the saturated hydraulic conductivity

#367  
New Member
Tom Dylan
Join Date: May 2015
Posts: 20
Rep Power: 4 
Hi Philip,
Quote:
I played a little bit around trying to implement the pressure dependence of the Kfluidfield (stiffness of the water gas mixture within the pores) and I came to stable results with the fixed point approach (relaxing only p and U): Code:
fvm::ddt(p) == fvm::laplacian(coeff_Dp, p)  fvc::div(fvc::ddt(coeff_Dp2,U)) ); solverPerfP = pEqn.solve(); p.relax(); dp = p  p.oldTime(); dp.correctBoundaryConditions(); Kfluid = 1.0/(Sr/K_ + (1.0Sr)/(p0+psi*gamma+dp)); coeff_Dp = (kSat/gamma*Kfluid/n); coeff_Dp2 = Kfluid/n; Probably relaxing Kfluid (how ?), as you suggest, might enhance convergence. Now I tried to implement heterogeneity of the saturated hydraulic conductivity, which in natural settings is always an issue, by introducing the field kSat. in open water environments it is not uncommon to find conductivity contrasts spanning 4 orders of magnitude: sand 1^04 m/s, silt 1^8 m/s. The coeff_Dp field varies correspondingly over orders of magnitude. First I decided to adapt the laplacian scheme to harmonic, which makes more sense than a linear one from an geohydraulic point of view: Code:
laplacian(Dp,p) Gauss harmonic corrected; From the (very illustrative) convergence analysis in "On finite volume method implementation of poroelasticplasticity soil model" by Tang, Heledal & Cardiff it is clear, that a very large Kfluid (due to almost compressed gas in 20 m below phreatic surface) becomes stiffer than the bulk modulus of the soil and therefore mesh and time step sizes are determined by the bulk modulus, the water unit weight and the hydraulic conductivity! It turned out that a mesh size of approx. 0.2 m is necessary. I reduced the model to 2D (app. 120 m x 20 m) but could not reach convergence yet. I could imagine that my problem is not the first one to exhibit strongly varying laplacian terms. So I would appreciate any hints on strategies to overcome these kind of difficulties. Tom 

July 18, 2017, 13:52 

#368  
Senior Member
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 643
Rep Power: 23 
Hi Tom,
Quote:
Quote:
Code:
... Kfluid.storePrevIter(); Kfluid = 1.0/(Sr/K_ + (1.0Sr)/(p0+psi*gamma+dp)); Kfluid.relax(); ... Quote:
Philip 

July 31, 2017, 12:36 

#369 
New Member
Iago Lessa
Join Date: May 2015
Posts: 5
Rep Power: 4 
Hello,
In the new version of the FSI toolkit, a great number of new boundary conditions (BC) was implemented for the fluid part. One of them is called outflowPressure, which I suppose is intended for outlets of the flow domain with a specified pressure on it. However, I am trying to understand what exactly this BC performs. I looked in its .C and .H files, but so far I only understood that the BC accounts for a correction/modification of the pressure involving a relation with the face normal velocity gradient through a variable called pp: pp = nu.value()*(n & pU.snGrad()) where pU = patch().lookupPatchField<volVectorField, vector>("U") I could not guess more (my C++ is very limited, unfortunately) and, so far, I did not find any information about this specific implementation of this boundary condition in the forums or even comparing with the implemented BC's in other versions of foamextend. Does anyone knows what exactly this BC implements? Thanks in advance for any help Iago 

November 21, 2017, 06:17 
elasticThermalSolidFoam

#370  
New Member

Hello,
Quote:
What I'm actually trying to do is model steadystate elastic strain in semiconductor structures.[1] There's a "builtin" strain which comes from a "misfit" between two crystals with different atomic spacings. I had been using solidDisplacementFoam for this, and it basically worked, although I was faking the misfit strain with a thermal strain (setting the thermal conductivity to zero). Basically, elasticThermalSolidFoam does not give the expected result (the solidDisplacementFoam result is correct) which is why I'm curious about the status of that !incremental bug, or the outcome of this thread. Ideally I'd like to be able to properly specific a misfit strain somehow, i.e. that two different (orthotropic) materials are obliged to maintain the same lattice spacing at the interface despite having different natural lattice spacings, but for now the fake thermal strain thing would be ok. Thanks! 1. http://aip.scitation.org/doi/abs/10.1063/1.4765009 

December 6, 2017, 03:19 

#371  
Member
Thaw Tar
Join Date: Apr 2013
Location: Yangon, Myanmar
Posts: 32
Rep Power: 6 
Quote:
Hi, could anybody please explain me about this question, too. I also have this very confusion. I cannot figure out how the computed fluid force (traction force) is used in the solid solver. Thaw Tar 

December 7, 2017, 05:45 

#372 
Senior Member
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 643
Rep Power: 23 
Hi Thaw Tar,
The fluid force/traction is applied to the solid as a traction boundary condition in the "setInterfaceForce.H" header file (just before "solveSolid.H" in the "icoFsiElasticNonLinULSolidFoam.C" file). Philip 

December 7, 2017, 22:50 

#373  
Member
Thaw Tar
Join Date: Apr 2013
Location: Yangon, Myanmar
Posts: 32
Rep Power: 6 
Quote:
Now I understood how the fluid force was used as a boundary condition for the solid solver. And also for the advice to increase the solid solver iteration count and to control the convergence with residuals. It worked very well!!! Thaw Tar 

December 8, 2017, 03:07 

#374 
Member
Thaw Tar
Join Date: Apr 2013
Location: Yangon, Myanmar
Posts: 32
Rep Power: 6 
Dear Dr. Cardiff and others,
I am sorry for disturbing again. But I have one problem with the fsiFoam solver. I ran the simulation for some time steps and wrote out the data. But when I restart the simulation from the last time step, it showed this following error: Create extended GGI zonetozone interpolator Checking fluidtosolid face interpolator Fluidtosolid face interpolation error: 0.0126103 Checking solidtofluid point interpolator (GGI) Extended GGI, master point distance, max: 1e+15, avg: 2.30143e+14, min: 0.002 Extended GGI, master point orientation (<0), max: 1, min: 1, nIncorrectPoints: 638/982 > FOAM FATAL ERROR: Master point addressing is not correct From function ExtendedGGIInterpolation::masterToSlavePointInterp olate(const Field<Type> pf) in file ./numerics/ggi/ExtendedGGIInterpolation/ExtendedGGIInterpolation.C at line 703. FOAM aborting Aborted (core dumped) If anyone has the solution and could explain to me how to fix it, I would be very grateful. Thaw Tar 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
GPU Linear Solvers for OpenFOAM  gocarts  OpenFOAM Announcements from Other Sources  36  March 29, 2017 08:05 
ESIOpenCFD Releases OpenFOAM v2.2.0  opencfd  OpenFOAM Announcements from ESIOpenCFD  13  March 30, 2013 17:52 
[Virtualization] OpenFOAM oriented tutorial on using VMware Player  support thread  wyldckat  OpenFOAM Installation  2  July 11, 2012 16:01 
Crosscompiling OpenFOAM 1.7.0 on Linux for Windows 32 and 64bits with Mingww64  wyldckat  OpenFOAM Announcements from Other Sources  3  September 8, 2010 06:25 
OpenFOAM Debian packaging current status problems and TODOs  oseen  OpenFOAM Installation  9  August 26, 2007 13:50 