[heliana60]

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

[bigphil]

Hi all,

FYI, a couple of recent papers on solid mechanics in OpenFOAM:

• P. Cardiff, Ž. Tuković, H. Jasak, A. Ivanković, A block-coupled Finite Volume methodology for linear elasticity and unstructured meshes, Computers & Structures, Volume 175, 15 October 2016, Pages 100-122, ISSN 0045-7949, http://dx.doi.org/10.1016/j.compstruc.2016.07.004.
  (http://www.sciencedirect.com/science...45794916306046)
  
• P. Cardiff, Ž. Tuković, P. De Jaeger, M. Clancy, A. Ivanković, A Lagrangian Cell-Centred Finite Volume Method for Metal Forming Simulation, International Journal for Numerical Methods in Engineering, 2016, http://dx.doi.org/10.1002/nme.5345, (http://onlinelibrary.wiley.com/doi/1....5345/abstract)
  

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

[tomdylan]

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

[bigphil]

Originally Posted by tomdylan

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

Hi Tom,

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:

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

Hopefully that is somewhat helpful,

Philip

[Maimouna]

Originally Posted by May Z

http://pan.baidu.com/s/1nvjc2MX
Hi Maimouna, here's my case, the data of the geometry comes from a benchmark case, but the solid part deforms little.
Thanks,

Hi May,

sorry for late reply, if you still looking for help email me please may78may@hotmail.com.

Best,
Maimouna

[Sourabhsup]

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;
}

[tomdylan]

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.

[Maimouna]

Originally Posted by trananha91

Can I install both OpenFOAM 171 and OpenFOAM-ext in same machine?

Sure, you could. After installation more than one OF versions in the same machine, you need to launch which version you are going to use.

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

[ilhado]

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

[Maimouna]

Originally Posted by ilhado

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

Hi Iago,

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

[ilhado]

Originally Posted by Maimouna

Hi Iago,

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

Hello Maimouna, thanks for the answer!

But were you able to restart a case decomposed in fsiFoam? Always when I try it, I get the error:

[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]

Which also happened with version 3.2 of the FSI toolkit, as posted before on this thread.

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

[Bartosz Żłobiński]

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:

Setting traction on solid patch


--> FOAM FATAL ERROR:
given field does not correspond to patch. Patch size: 297 field size: 28

From function GGIInterpolation::masterToSlave(const Field<Type> ff)
in file /home/bartosz/foam/foam-extend-4.0/src/foam/lnInclude/GGIInterpolate.C at line 175.

FOAM aborting

Aborted (core dumped)

It looks like GGI couldn't handle with changes made by dynamicTopoFvMesh. The same for both foam-ext3.1 and 4.0 with solver fsiFoam.
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

[rege]

Originally Posted by ilhado

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

Hi Iago,

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

[rege]

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

[bigphil]

Originally Posted by Bartosz Żłobiński

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:



It looks like GGI couldn't handle with changes made by dynamicTopoFvMesh. The same for both foam-ext3.1 and 4.0 with solver fsiFoam.
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

Hi Bartosz,

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

[Bartosz Żłobiński]

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

[Bartosz Żłobiński]

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.

/*--------------------------------*- 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;
   	 }
}

// ************************************************************************* //

I was trying almost all the other parameters, but I wasn't able to run the simulation if any changes happened anywhere.

Kind regards,
Bartosz Żłobiński

[ilhado]

Originally Posted by rege

Hi Iago,

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

Hello Kristen,

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

[tomdylan]

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:

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:

    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

[bigphil]

Originally Posted by tomdylan

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:

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:

    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:

        lduMatrix::solverPerformance solverPerfP;

        lduMatrix::solverPerformance solverPerfDU;

should be replaced by these lines:

        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:

        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