CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend"

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

Like Tree27Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   June 19, 2017, 03:24
Default
  #361
Senior Member
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 638
Rep Power: 23
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by tomdylan View Post
Hi outthere,

due to an upgrade (opensuse 13.2 -> leap 42.2) I had to reinstall openFoam. Being working with oF3.0ext I decided to got for oF4.0ext. After installation everything seemed to work well and I could test a couple of tutorials (icoFoam, plateHole etc). However, when I tried to carry on with modifications for elastoPlastoBiotFoam (coupled flow and deformation in prorous media) some compiling errors appeared, not seen before:


Code:
pDependElastPlastBiotFoam.C: In function ‘int main(int, char**)’:
pDependElastPlastBiotFoam.C:77:9: error: ‘solverPerformance’ is not a member of ‘Foam::lduMatrix’
         lduMatrix::solverPerformance solverPerfP;
         ^
pDependElastPlastBiotFoam.C:77:38: error: expected ‘;’ before ‘solverPerfP’
         lduMatrix::solverPerformance solverPerfP;
                                      ^
pDependElastPlastBiotFoam.C:78:9: error: ‘solverPerformance’ is not a member of ‘Foam::lduMatrix’
         lduMatrix::solverPerformance solverPerfDU;
         ^
pDependElastPlastBiotFoam.C:78:38: error: expected ‘;’ before ‘solverPerfDU’
         lduMatrix::solverPerformance solverPerfDU;
                                      ^
pDependElastPlastBiotFoam.C:82:35: error: ‘class Foam::Time’ has no member named ‘controlDic’
         word correct=word(runTime.controlDic t().lookup("correctPlasticity"));
                                   ^
pDependElastPlastBiotFoam.C:98:6: error: ‘solverPerfP’ was not declared in this scope
      solverPerfP = pEqn.solve(); 
      ^
pDependElastPlastBiotFoam.C:101:25: error: no match for ‘operator<<’ (operand types are ‘Foam::Ostream’ and ‘void’)
     Info<< "p_relax = " << p.relax() << " Pa\n";               
                         ^
Apparently the function solverPerf is unknown to the solver. It feels like the =solverPerformance=-class is hidden in =lduMatrix=

I have no idea, why this was never a problem in oF3.0ext and have no clue what is going out. I suppose i should modify the MAKE/options, which actually are set to:

Code:
    EXE_INC = \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude \
    -IincrementTractionDisplacement/lnInclude

EXE_LIBS = \
    -lfiniteVolume \
    -lmeshTools
Any hints on what to do are warmly appreciated!

Tom
Hi,

In foam-extend-4.0, these lines:
Code:
        lduMatrix::solverPerformance solverPerfP;

        lduMatrix::solverPerformance solverPerfDU;
should be replaced by these lines:
Code:
        lduSolverPerformance solverPerfP;

        lduSolverPerformance solverPerfDU;
Separately, you seem to have an erroneous space in this line (in between 'c' and 't' in controlDict) which should be removed:
Code:
        word correct=word(runTime.controlDic t().lookup("correctPlasticity"));
You can move "p.relax();" to a line on its own, no need for the info statement.

Philip
bigphil is offline   Reply With Quote

Old   June 29, 2017, 16:54
Default
  #362
New Member
 
tomdylan's Avatar
 
Tom Dylan
Join Date: May 2015
Posts: 18
Rep Power: 4
tomdylan is on a distinguished road
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 non-linearity 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 non-convergence 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 Picard-iteration 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
tomdylan is offline   Reply With Quote

Old   June 30, 2017, 04:35
Default
  #363
Senior Member
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 638
Rep Power: 23
bigphil will become famous soon enoughbigphil will become famous soon enough
Hi Tom,

I am glad the code is now compiling for you.

Quote:
Is there any documentation out there of the syntax changes during the evolution of o30ext - o40ext?
Not that I know of, apart from the code itself; there is some info here: http://foam-extend.fsb.hr/release-of-foam-extend-4-0/.

Quote:
Originally Posted by tomdylan View Post
First tests indicate numerous iterations and non-convergence 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 Picard-iteration approaches. I wonder if a Picard scheme might improve the convergence of the current problem.
It makes sense that the lagged scheme is more stable; as regards coupling K changes within the time-step, I suppose you are already using Picard/Fixed-point iterations i.e. successive substitution.
Under-relaxation of the K field will probably help, or more under-relaxation of the p and U fields (equations and fields).

Philip
bigphil is offline   Reply With Quote

Old   July 10, 2017, 04:27
Post fsiFoam in extend4.0 / running in parallel
  #364
New Member
 
Georg Göbel
Join Date: Sep 2016
Location: Karlsruhe
Posts: 3
Rep Power: 3
Horst is on a distinguished road
Hello fsiFoamers,

is anyone running fsiFoam on ext-4.0 in parallel? In the ext-3.1 version there was this decomposeParFsi-tool, which was easy to use and worked fine, but on ext-4.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 ext-4.0 version of fsiFoam in parallel.

Thanks a lot in advance
Georg

BTW: the robin-bc approach in the ext-4.0 version is much more stable, even for high fluid density! Thanks to everyone who took part in developing, i highly appreciate your work.
ilhado likes this.
Horst is offline   Reply With Quote

Old   July 10, 2017, 08:24
Default
  #365
New Member
 
ilhado's Avatar
 
Iago Lessa
Join Date: May 2015
Posts: 5
Rep Power: 4
ilhado is on a distinguished road
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 time-step 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
Horst likes this.
ilhado is offline   Reply With Quote

Old   July 11, 2017, 10:24
Default
  #366
New Member
 
Georg Göbel
Join Date: Sep 2016
Location: Karlsruhe
Posts: 3
Rep Power: 3
Horst is on a distinguished road
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
ilhado likes this.
Horst is offline   Reply With Quote

Old   July 12, 2017, 05:57
Default implementing spatial heterogeneity of the saturated hydraulic conductivity
  #367
New Member
 
tomdylan's Avatar
 
Tom Dylan
Join Date: May 2015
Posts: 18
Rep Power: 4
tomdylan is on a distinguished road
Hi Philip,

Quote:
Originally Posted by bigphil View Post

It makes sense that the lagged scheme is more stable; as regards coupling K changes within the time-step, I suppose you are already using Picard/Fixed-point iterations i.e. successive substitution.
Under-relaxation of the K field will probably help, or more under-relaxation of the p and U fields (equations and fields).

Philip
I found a quite stable Picard approach in suGWFoam, a saturated unsaturated solver by Liu which could serve as template for a future implementation of coupled deformation saturated/unsaturated flow. I tested Liu's solver under quite mean conditions (flow with large gradients into extremely dry soil and it yielded excellent results (even commercial software would not resolve this problem). To be honest I presently do not feel experienced enough to effectively implement the Picard scheme (which is a time adaptive approach) into elastoPlastoBiotFoam. In view of the high non-linearity of the conductivity and storage properties in unsaturated flow considered by the Picard approach a segregated scheme to consider deformation should not represent a big issue.

I played a little bit around trying to implement the pressure dependence of the Kfluid-field (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.0-Sr)/(p0+psi*gamma+dp));       
          coeff_Dp = (kSat/gamma*Kfluid/n);
          coeff_Dp2 = Kfluid/n;
This way the pressure changes dp are considered inside the iteration loop. The absolute pressure consists of the atmospheric (p0) and the hydrostatic (psi=pressure head below phreatic surface) components.

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;
Unfortunately the solver now diverges during the first iterations.

From the (very illustrative) convergence analysis in "On finite volume method implementation of poro-elastic-plasticity 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
tomdylan is offline   Reply With Quote

Old   July 18, 2017, 13:52
Default
  #368
Senior Member
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 638
Rep Power: 23
bigphil will become famous soon enoughbigphil will become famous soon enough
Hi Tom,

Quote:
Originally Posted by tomdylan View Post
I found a quite stable Picard approach in suGWFoam, a saturated unsaturated solver by Liu which could serve as template for a future implementation of coupled deformation saturated/unsaturated flow. I tested Liu's solver under quite mean conditions (flow with large gradients into extremely dry soil and it yielded excellent results (even commercial software would not resolve this problem).
Interesting; is the code shared somewhere?

Quote:
Originally Posted by tomdylan View Post
To be honest I presently do not feel experienced enough to effectively implement the Picard scheme (which is a time adaptive approach) into elastoPlastoBiotFoam. In view of the high non-linearity of the conductivity and storage properties in unsaturated flow considered by the Picard approach a segregated scheme to consider deformation should not represent a big issue.

I played a little bit around trying to implement the pressure dependence of the Kfluid-field (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.0-Sr)/(p0+psi*gamma+dp));       
          coeff_Dp = (kSat/gamma*Kfluid/n);
          coeff_Dp2 = Kfluid/n;
This way the pressure changes dp are considered inside the iteration loop. The absolute pressure consists of the atmospheric (p0) and the hydrostatic (psi=pressure head below phreatic surface) components.

Probably relaxing Kfluid (how ?), as you suggest, might enhance convergence.
You can relax Kfluid just like p:
Code:
...
          Kfluid.storePrevIter();
          Kfluid = 1.0/(Sr/K_ + (1.0-Sr)/(p0+psi*gamma+dp));       
          Kfluid.relax();
...
The add the name of Kfluid to the relaxationFactors dictionary within fvSolution.

Quote:
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;
Unfortunately the solver now diverges during the first iterations.

From the (very illustrative) convergence analysis in "On finite volume method implementation of poro-elastic-plasticity 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.
Hmnn relaxing the p field should help with convergence but you are already doing this; you could try more.

Philip
bigphil is offline   Reply With Quote

Old   July 31, 2017, 12:36
Default
  #369
New Member
 
ilhado's Avatar
 
Iago Lessa
Join Date: May 2015
Posts: 5
Rep Power: 4
ilhado is on a distinguished road
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 foam-extend.
Does anyone knows what exactly this BC implements?

Thanks in advance for any help
Iago
ilhado is offline   Reply With Quote

Reply

Thread Tools
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 On
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 36 March 29, 2017 08:05
ESI-OpenCFD Releases OpenFOAM v2.2.0 opencfd OpenFOAM Announcements from ESI-OpenCFD 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
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 06:25
OpenFOAM Debian packaging current status problems and TODOs oseen OpenFOAM Installation 9 August 26, 2007 13:50


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