|
[Sponsors] |
[solidMechanics] Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend" |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
August 8, 2016, 06:28 |
|
#341 |
Member
Heliana Cardenas
Join Date: Jul 2013
Posts: 30
Rep Power: 13 |
Hi Philip,
Yes I also thought something like that but I was getting a Floating point exception error. I am going to work on it and keep you updated Cheers, Heliana |
|
August 12, 2016, 12:58 |
|
#342 |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,093
Rep Power: 34 |
Hi all,
FYI, a couple of recent papers on solid mechanics in OpenFOAM:
I am in the process of tidying things up and intend to publicly share the main procedures. PDFs of the accepted articles (pre publishing) can be found at my ResearchGate: https://www.researchgate.net/profile/Philip_Cardiff Philip |
|
October 13, 2016, 11:39 |
geomechanics|approach to compute body forces/weight as initial cond.
|
#343 |
New Member
Tom Dylan
Join Date: May 2015
Posts: 20
Rep Power: 11 |
Hello out there,
this seems to be a space where the solid mechanics fraction seems to interchange. However I am not sure if this is the right place. I'd like to apologize if this isn't and I'd appreciate if somebody told me where to post. I have been exploring Tian Tangs implementation for geomechanical problems, which has proved easier than expected due to the excellent documentation. The analysis concerns an (almost) water saturated porous matrix. Coming from geohydraulics I have to adapt myself to the incremental formulation used in the solid mechanic solvers, so my question might sound a bit silly: I wish to assign realistic initial conditions to pore pressure p and stress sigma which stem from gravity. However in the incremental formulation of the solver body forces are neglected. I have no clue as how to assign water and soil a self-weight in order to obtain a realistic initial condition, hydrostatic for the fluid and geostatic for the soil. This seems necessary for the analysis of plastic deformations, which response to the total and not only to the incremental stress changes. I am trying to reproduce the wave-seabed-gravity structure interaction tutorial in which a consolidation is run to provide initial conditions applying a "K0-procedure", which unfortunately is not explained further. Must I apply some kind of operation with the gravity vector in order to assign body forces to matrix and fluid? How should such an approach be implemented? An other option could be to take the z coordinates from constant/polyMesh and try to generate hydrostatic and geostatic fields in octave/excel but his approach seems not too appealing. I could imagine, that this question has been raised by other so any hints appreciated on the "K0 approach" or any other way to compute body forces/weight in order to start the analysis from realistic initial conditions. Tom |
|
October 16, 2016, 18:23 |
|
#344 | |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,093
Rep Power: 34 |
Quote:
It's possible to include an initial stress and initial pore-pressure by writing the conservation equation in total (not incremental) form, but you can still solve for the increment of displacement for convenience i.e. div(totalStress) == 0 div(initialStress + effectiveStress + initialPorePressure + porePressure) == 0 div(initialStress + oldTime_effectiveStress + increment_effectiveStress + initialPorePressure + porePressure) == 0 so for example, in OpenFOAM this could be: Code:
fvVectorMatrix DUEqn ( fvm::laplacian(2*mu + lambda, DU) - fvc::div((2*mu + lambda)*fvc::grad(DU)) + fvc::div ( sigmaEff.oldTime() + DSigmaEff - p0*I + sigma0 - p*I ) ); // Then update DSigmaEff using your choice of material law // Alternatively, you could directly calculate sigmaEff instead of sigmaEff.oldTime() and DSigmaEff Philip |
||
October 18, 2016, 08:58 |
|
#345 | |
Senior Member
ok
Join Date: Oct 2013
Posts: 346
Rep Power: 14 |
Quote:
sorry for late reply, if you still looking for help email me please may78may@hotmail.com. Best, Maimouna |
||
October 20, 2016, 09:14 |
How is traction from fluid applied on solid??
|
#346 |
New Member
Sourabh Supanekar
Join Date: Jun 2015
Location: Stuttgart
Posts: 11
Rep Power: 11 |
Hello all,
I am using the icoFsiElasticNonLinULSolidFoam solver. I cannot understand how the traction force (tForce) calculated in setInterfaceForce.H is applied in the solveSolid.H. The solveSolidEuler.H has the governing equation implemented, but i dont see the force term in the governing equation. Can anyone please explain the steps in which solid is solved? How is that traction force applied? and where? Please guide me on this. Following code is solveSolidEuler.H { # include "readSolidMechanicsControls.H" int iCorr = 0; lduMatrix::solverPerformance solverPerf; scalar initialResidual = 0; lduMatrix::debug = 0; # include "EulerCoeffs.H" do { DU.storePrevIter(); fvVectorMatrix DUEqn ( Cn*rho*fvm::ddt(DU) - Co*rho*DV.oldTime() == fvm::laplacian(2*mu + lambda, DU, "laplacian(DDU,DU)") - fvc::laplacian(mu + lambda, DU, "laplacian(DDU,DU)") + fvc::div ( mu*gradDU.T() + lambda*(I*tr(gradDU)) + mu*(gradDU&gradDU.T()) + 0.5*lambda*(I*tr(gradDU & gradDU.T())) + (sigma & DF.T()) + (DSigma & DF.T()), "div(sigma)" ) ); solverPerf = DUEqn.solve(); DU.relax(); if(iCorr == 0) { initialResidual = solverPerf.initialResidual(); } gradDU = fvc::grad(DU); DF = gradDU.T(); # include "calculateDSigma.H" } while ( solverPerf.initialResidual() > convergenceTolerance && ++iCorr < nCorr ); Info << "Solving for " << DU.name() << ", Initial residual = " << initialResidual << ", Final residual = " << solverPerf.initialResidual() << ", No outer iterations " << iCorr << endl; DV = fvc::ddt(DU); lduMatrix::debug = 1; } |
|
October 26, 2016, 11:11 |
|
#347 |
New Member
Tom Dylan
Join Date: May 2015
Posts: 20
Rep Power: 11 |
Thank you, Philip.
That approach is exactly what I was looking for. I will try to implement that (which might take me a while due to my limited oF experience) and will report the (hopefully successful) result. |
|
October 27, 2016, 09:44 |
|
#348 | |
Senior Member
ok
Join Date: Oct 2013
Posts: 346
Rep Power: 14 |
Quote:
For example: If you installed OpenFOAM- 2.3.0 and foam- extend 3.1 in your machine, you have to start the terminal with of230 --> to start using OpenFOAM- 2.3.0 OR fe31 --> to start foam-extend 3.1. Kind regards Maimouna |
||
March 3, 2017, 10:41 |
|
#349 |
New Member
Iago Lessa de Oliveira
Join Date: May 2015
Posts: 23
Rep Power: 11 |
Hello everyone,
Did anybody have any success with the restarting issue for FSI cases running in parallel, discussed before on this thread? I am currently using foam-extend-4.0 with the bazaar extension to simulate FSI problems, but I am still facing the same errors requiring the V0 file for the solid part (it happened too with the last 3.2 version). I tried the workaround proposed by Needled, but still did not work. Thanks in advance Iago |
|
March 4, 2017, 03:32 |
|
#350 | |
Senior Member
ok
Join Date: Oct 2013
Posts: 346
Rep Power: 14 |
Quote:
I tried to run some cases using fsiFoam solver in parallel, but that wouldn't help me much. I mean in speed up. Also, simulation in parallel gives different results when compared with serial simulation, because of the number of cores. Briefly, I think, foam-extend 4.0 doesn't implement to work in parallel, it still needs some modification. Kind regards Maimouna |
||
March 7, 2017, 08:45 |
|
#351 | |
New Member
Iago Lessa de Oliveira
Join Date: May 2015
Posts: 23
Rep Power: 11 |
Quote:
But were you able to restart a case decomposed in fsiFoam? Always when I try it, I get the error: Code:
[7] [7] [7] --> FOAM FATAL IO ERROR: [7] cannot open file [7] [7] file: /home/iagolessa/foam/iagolessa-4.0/FluidSolidInteraction/run/fsiFoam/case13/fluid/processor7/0.08/solid/V0 at line 0.[0] [0] Regarding the speedup, with all the cases I worked with, it was better to run in parallel. But thanks for pointing out that you were having different results with serial and parallel, I need to compare my results to check it! Regards, Iago |
||
May 22, 2017, 07:17 |
|
#352 | |
New Member
Bartosz Żłobiński
Join Date: Oct 2015
Location: Warsaw
Posts: 11
Rep Power: 11 |
Hello,
There was a question about dynamicTopoFvMesh, but it was left without an answer. I'm working on a case similar to "beamInCrossFlow", but with a more complicated geometry, so I need to add to it the posibility of making topological changes to the fluid mesh. I had some troubles with the parameters, "cacheAgglomeration" in fvSolution, etc., but finally I've stucked on a problem with GGI. Each time after remeshing I'm getting an error: Quote:
I'm using "velocityLaplacian" motion solver, since "mesquite" seems not to be availble with fsiFoam ("Problem with fluid mesh motion solver selection"). Is there any possibility to run fsiFoam with a changing topology? I would be very grateful for any clues. Kind regards, Bartosz Żłobiński |
||
May 23, 2017, 06:20 |
|
#353 | |
New Member
Kristen Rege
Join Date: Mar 2017
Posts: 2
Rep Power: 0 |
Quote:
Have you tried deleting the V0 file from the latest fluid folder in all processor directories? I've found this to work for me. I think you may need to delete the meshPhi files from the latest fluid folders, too. KR |
||
May 23, 2017, 06:50 |
|
#354 |
New Member
Kristen Rege
Join Date: Mar 2017
Posts: 2
Rep Power: 0 |
Hi all,
I've been trying to implement LES to the "beamInCrossFlow" tutorial for the FSI toolkit for foam-extend 4.0. My problem is that a heavily oscillating pressure field appears in the fluid field, eventually causing extreme velocities, causing the simulation to crash. My changes with respect to the original tutorial are as follows: - Rewritten blockMeshDict to a complete 3D domain for both the fluid and structure. - Increased the max speed in setInletVelocity to 10, in order to get turbulence. - Changed the properties of the solid to the following: rho = 8000, E = 4e6, nu = 0.3 - Implemented PISO solver with LES model oneEqEddy, with vanDriest smoothing. - Decreased FSI tolerance to 1e-5 and increased nOuterCorr to 200. - ddtScheme: CrankNicolson 0.8 - div(phi,U) Gauss filteredLinear2 1 0 - fvSolution changed to common settings for LES simulations. - The Courant number has been kept at 0.4-0.5. The ddtScheme was chosen by trying out all the ddtSchemes without FSI. The use of other ddtSchemes, including CrankNicolson 0.7 or 0.9, causes the simulations without FSI to blow up, too. Simulations with CrankNicolson 0.8 run smoothly without FSI however. In all cases, the problem has been that a field of high pressure at the lower edge of the inlet has merged with the field of high pressure in front of the beam. When these two fields of high pressure merge, they start to "pump" the fluid over the beam, resulting in pressure oscillations for the entire field. The pressure typically ends up oscillating from +200 Pa to -200 Pa for 80% of the internal field within 0.05 seconds. I therefore assumed that the inlet was too close to the beam, and increased the length from the inlet by 0.5m. The pressure oscillations did still occur. I have also tried the following adjustments: - Max speed 5 m/s. - Initial internal fields calculated by consistentIcoFluid with FSI, by LES simulation without FSI, and by increasing the velocity from zero with LES and FSI. - Reduced cell lengths to the half in all directions. - Adjusted time step to Co = 0.2 and Co = 0.8. In all these configurations, the pressure oscillations do still occur. The pressure oscillations do not occur when doing a LES simulation of the undeformed geometry without FSI, and neither if the stiffness (E) of the solid is set to be very high in the FSI simulation (causing it to be stationary). Has anyone else tried to implement LES to this case? I would be very grateful for any suggestions. Best regards, KR |
|
May 31, 2017, 12:07 |
|
#355 | |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,093
Rep Power: 34 |
Quote:
The problem is with the globalFaceZones: after a topological change, these get messed up and it is not trivially to fix them; consequently, as you have seen the GGI will complain. In your case, is there a topo change at the patch/faceZone? If so, have you tried a case when the topo change is away from the patch? Just an idea. Similar issue discussed here: https://sourceforge.net/p/openfoam-e...ndrelease/280/ Philip |
||
June 2, 2017, 09:14 |
|
#356 |
New Member
Bartosz Żłobiński
Join Date: Oct 2015
Location: Warsaw
Posts: 11
Rep Power: 11 |
Thank you for your explanation and suggestion, bigphil. I'll try to modify the dynamicMeshDict to force the topo changes to happen only far enough from the interface (e.g. two rows of cells), it should be sufficient for my simulation.
Hi, rege. I was trying to use LES for my case similar to the "beamInCrossFlow" and it seems to work fine. I have also encountered extreme velocities, but they haven't been caused by such pressure oscilations and apeared also for DNS. Kind regards, Bartosz Żłobiński |
|
June 5, 2017, 02:49 |
|
#357 |
New Member
Bartosz Żłobiński
Join Date: Oct 2015
Location: Warsaw
Posts: 11
Rep Power: 11 |
Hello again,
Unfortunately, I still can't make my case working with dynamicTopoFvMesh. I've switched off edgeRefinement and only some swapping occurs on the inlet, outlet and on the internal cells. I'm still getting the same error from GGI, although there are no changes on the interface patch (it's named "granica"). I'm enclosing my dynamicMeshDict. Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | foam-extend: Open Source CFD | | \\ / O peration | Version: 3.1 | | \\ / A nd | Web: http://www.extend-project.de | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; location "constant"; object dynamicMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dynamicFvMeshLibs ("libdynamicTopoFvMesh.so"); dynamicFvMesh dynamicTopoFvMesh; solver velocityLaplacian; diffusivity quadratic inverseDistance (granica); dynamicTopoFvMesh { allOptionsMandatory no; debug 5; threads 1; interval 1; dumpLengthScale true; sliverThreshold 0.35; removeSlivers false; skipMapping false; edgeRefinement no; tetMetric Knupp; noSwapPatches { granica; symetria; sciana; } } // ************************************************************************* // Kind regards, Bartosz Żłobiński |
|
June 5, 2017, 09:35 |
|
#358 | |
New Member
Iago Lessa de Oliveira
Join Date: May 2015
Posts: 23
Rep Power: 11 |
Quote:
Thank you very much for the answer! I tried deleting the all the old time-steps information files from the last time-step folder and didn't work. But deleting them and also the meshPhi file finally worked Regards, Iago |
||
June 18, 2017, 12:23 |
problem with solverPerformance-class in porous media flow/deformation
|
#359 |
New Member
Tom Dylan
Join Date: May 2015
Posts: 20
Rep Power: 11 |
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"; ^ 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 Tom |
|
June 19, 2017, 04:24 |
|
#360 | |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,093
Rep Power: 34 |
Quote:
In foam-extend-4.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 |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |