[Daniel_Khazaei]

Originally Posted by sita

Hi Daniel,

Thanks a lot for your suggestions! I initially set coupled to yes, and disabled couplingStartTime, just like you did now, but I didn't yet try playing with this transition period of the inlet velocity. With the transition period kept at 0, even the case without gravity (i.e. the original Hron-Turek FSI 1 benchmark) wouldn't run, so I'm definitely going to try playing with this transition period.

Cheers,
Sita

Well in FSI cases, most of the time bad initial condition at start time causes the simulation to collapse.
This is the result after 1.8sec and everything is still stable.

Edit: added result for 4.1 sec and still stable.
The only issue that I noticed is a small interface gap at the tip. Although, the fsi implicit loop converged within 10 iterations, due the fact that FSI residual2 norm reached the convergence target, relative fsi residual is still pretty high.

Time = 4.037, iteration: 10
Maximal accumulated displacement of interface 0: 2.84777e-06
Evolving fluid model: icoFluid
Courant Number mean: 0.00632674 max: 0.0718039 velocity magnitude: 0.54181
DILUPBiCG:  Solving for Ux, Initial residual = 3.77018e-08, Final residual = 6.16616e-11, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 8.63068e-08, Final residual = 8.68231e-11, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.00134423, Final residual = 8.13287e-07, No Iterations 54
GAMG:  Solving for p, Initial residual = 0.00128165, Final residual = 9.74279e-07, No Iterations 26
time step continuity errors : sum local = 2.99208e-12, global = -5.47319e-13, cumulative = 4.25085e-08
GAMG:  Solving for p, Initial residual = 0.000250223, Final residual = 9.41756e-07, No Iterations 24
GAMG:  Solving for p, Initial residual = 5.73513e-05, Final residual = 9.30874e-07, No Iterations 6
time step continuity errors : sum local = 2.85823e-12, global = 6.65465e-13, cumulative = 4.25092e-08
GAMG:  Solving for p, Initial residual = 1.84019e-05, Final residual = 9.69782e-07, No Iterations 6
GAMG:  Solving for p, Initial residual = 4.20156e-06, Final residual = 7.93278e-07, No Iterations 2
time step continuity errors : sum local = 2.43573e-12, global = 4.26684e-13, cumulative = 4.25096e-08
Setting traction on solid interfaces
Interpolating face values using GGI
Total force on fluid interface 0: (-0.0444829 -0.546845 9.54719e-16)
Total force on solid interface 0: (0.0444829 0.546845 -9.54719e-16)

Evolving solid solver
Corr 0, relative residual = 0.184884
Corr 102, relative residual = 0
PCG: Solving for D, Initial residual = 1.94804e-06, Final residual = 9.85649e-10, No outer iterations = 102
 Max relative residual = 0.184884, Relative residual = 0, enforceLinear = false
Interpolating point values using GGI
Interpolating point values using GGI
FSI relative residual1 norm for interface 0: 0.00161201
FSI residual2 norm for interface 0: 1.76992e-07
ExecutionTime = 22561.8 s  ClockTime = 22572 s

@Dr. Cardiff, is there any reason that we choose to return the minimum instead of the maximum here?

// For this interface, the residual is defined as the minimum of
// residualNorm1 and residualNorm2
const scalar residualInterfaceI = min(residualNorm1, residualNorm2);

Regards,
D. Khazaei

[sita]

Hi all,

Following up on my earlier posts on the RBFMeshMotionSolver (see below), I added an Info-statement to RBFMeshMotionSolver.C, to see what exactly is causing the error I'm getting. It turns out that whenever I use RBFMeshMotionSolver (e.g. with the beamInCrossFlow/linearGeometryElasticBeam tutorial), the index that is used between lines 651 and 678 ends up having a value of 1 lower than nbGlobalStaticFaceCenters, which it should equal according to the assert-statements used in lines 662 and 678.

The thing is that RBFMeshMotion solver apparently works fine for others (it does for Philip Cardiff anyway), so I don't know what's causing this error on my system (foam-extend-4.1 on Ubuntu 18.04 LTS). Does this look familiar to anyone?

Many thanks,
Sita

Originally Posted by sita

Hi Philip,

Great, that worked, the error "Problem with fluid mesh motion solver selection" is gone now. Unfortunately a new error popped up:

Time = 0.001, iteration: 1
Modes before clean-up (plate): 0, modes after clean-up (plate): 0
Current fsi under-relaxation factor (plate): 0.05
Maximal accumulated displacement of interface 0: 2.40967e-05
solids4Foam: fluidModels/finiteVolume/RBFMeshMotionSolver/RBFMeshMotionSolver.C:662: virtual void Fo
am::RBFMeshMotionSolver::solve(): Assertion `index == nbGlobalStaticFaceCenters[Pstream::myProcNo()]
' failed.
Aborted (core dumped)

Does this look familiar to you?

I'll try to run this beamInCrossFlow/linearGeometryElasticBeam tutorial first, see if I can work out how things work from there.

Thanks,
Sita


EDIT: Woops, the beamInCrossFlow/linearGeometryElasticBeam tutorial gives me the exact same error...
EDIT 2: Strange, the line of code that failed (the one with Pstream::myProcNo() ) should only be used in a parallel case (if ( Pstream::nProcs() > 1 ) ). I'm fairly sure I'm running the case in serial mode, as I haven't decomposed anything etc.

[Hgholami]

Hi all,
I have some problem with the solids4Foam. First with Hron-Turek FSI 3 benchmark, the tutorial simulation is stable, but results is seen increase in each time step. For example y-direction of tip displacment in below figure

Also, the comparing this results with Hron-Turek FSI 3 benchmark have 10% relative error in time 20s.
Second, when I use finner mesh (blockMeshDict.first) to simulation Hron-Turek FSI 3, the amplitude of displacement is reduces 10 time lesser than coarser mesh. I thought this may due to temporal error, so I reduce time step to make Courant number less that 0.2, but still the amplitude of displacement is very low. I think the fsiFoam have similar results for Hron-Turek FSI 3.
Third, by decreasing Elastic module (E) of solid from 5.6e6 to 1.4e6 and change density to 10000 as Soti et. al. article, the simulation diverged in only first 0.2 s with similar configuration of FSI3. Instead in fsiFoam, the simulation of Soti et. al. is stable. Now, I use recommend of Daniel (use coupled fsi and trasitionperiod) to see that does the problem comes from initial condition or any other reasons make diverges.
Do you have similar problem?

[sita]

Ahhh... now that's disappointing! Even with the settings Daniel suggested my run crashed after 0.8 s.

Daniel, did you change anything else in the case I attached? Are you using foam-extend-4.1, or 4.0?

Thanks,
Sita

Originally Posted by Daniel_Khazaei

Well in FSI cases, most of the time bad initial condition at start time causes the simulation to collapse.
This is the result after 1.8sec and everything is still stable.

Edit: added result for 4.1 sec and still stable.
The only issue that I noticed is a small interface gap at the tip. Although, the fsi implicit loop converged within 10 iterations, due the fact that FSI residual2 norm reached the convergence target, relative fsi residual is still pretty high.

Time = 4.037, iteration: 10
Maximal accumulated displacement of interface 0: 2.84777e-06
Evolving fluid model: icoFluid
Courant Number mean: 0.00632674 max: 0.0718039 velocity magnitude: 0.54181
DILUPBiCG:  Solving for Ux, Initial residual = 3.77018e-08, Final residual = 6.16616e-11, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 8.63068e-08, Final residual = 8.68231e-11, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.00134423, Final residual = 8.13287e-07, No Iterations 54
GAMG:  Solving for p, Initial residual = 0.00128165, Final residual = 9.74279e-07, No Iterations 26
time step continuity errors : sum local = 2.99208e-12, global = -5.47319e-13, cumulative = 4.25085e-08
GAMG:  Solving for p, Initial residual = 0.000250223, Final residual = 9.41756e-07, No Iterations 24
GAMG:  Solving for p, Initial residual = 5.73513e-05, Final residual = 9.30874e-07, No Iterations 6
time step continuity errors : sum local = 2.85823e-12, global = 6.65465e-13, cumulative = 4.25092e-08
GAMG:  Solving for p, Initial residual = 1.84019e-05, Final residual = 9.69782e-07, No Iterations 6
GAMG:  Solving for p, Initial residual = 4.20156e-06, Final residual = 7.93278e-07, No Iterations 2
time step continuity errors : sum local = 2.43573e-12, global = 4.26684e-13, cumulative = 4.25096e-08
Setting traction on solid interfaces
Interpolating face values using GGI
Total force on fluid interface 0: (-0.0444829 -0.546845 9.54719e-16)
Total force on solid interface 0: (0.0444829 0.546845 -9.54719e-16)

Evolving solid solver
Corr 0, relative residual = 0.184884
Corr 102, relative residual = 0
PCG: Solving for D, Initial residual = 1.94804e-06, Final residual = 9.85649e-10, No outer iterations = 102
 Max relative residual = 0.184884, Relative residual = 0, enforceLinear = false
Interpolating point values using GGI
Interpolating point values using GGI
FSI relative residual1 norm for interface 0: 0.00161201
FSI residual2 norm for interface 0: 1.76992e-07
ExecutionTime = 22561.8 s  ClockTime = 22572 s

@Dr. Cardiff, is there any reason that we choose to return the minimum instead of the maximum here?

// For this interface, the residual is defined as the minimum of
// residualNorm1 and residualNorm2
const scalar residualInterfaceI = min(residualNorm1, residualNorm2);

Regards,
D. Khazaei

[Daniel_Khazaei]

Originally Posted by sita

Ahhh... now that's disappointing! Even with the settings Daniel suggested my run crashed after 0.8 s.

Daniel, did you change anything else in the case I attached? Are you using foam-extend-4.1, or 4.0?

Thanks,
Sita

Hi,

I'm using foam-extend-4.0 and OpenFOAM-7 for now.
I did not change anything else and the simulation finished normally.

Which version of foam-extend are you using?
It seems that something is wrong with your foam-extend installation.

The final result at t = 6sec is also attached.

Regards,
D. Khazaei

[Daniel_Khazaei]

Originally Posted by Hgholami

Hi all,
I have some problem with the solids4Foam. First with Hron-Turek FSI 3 benchmark, the tutorial simulation is stable, but results is seen increase in each time step. For example y-direction of tip displacment in below figure

Hello,

Would you please explain how did you plot the y-displacement?
Because there is a gnuplot script provided with the tutorial which is supposed to plot y and x displacement of the tip.

By looking at the attached image, the displacement seems reasonable to me.

Originally Posted by Hgholami

Also, the comparing this results with Hron-Turek FSI 3 benchmark have 10% relative error in time 20s.

Originally Posted by Hgholami

Second, when I use finner mesh (blockMeshDict.first) to simulation Hron-Turek FSI 3, the amplitude of displacement is reduces 10 time lesser than coarser mesh. I thought this may due to temporal error, so I reduce time step to make Courant number less that 0.2, but still the amplitude of displacement is very low. I think the fsiFoam in this problem have better results for Hron-Turek FSI 3.

Originally Posted by Hgholami

Third, by decreasing Elastic module (E) of solid from 5.6e6 to 1.4e6 and change density to 10000 as Soti et. al. article, the simulation diverged in only first 0.2 s with similar configuration of FSI3. Instead in fsiFoam, the simulation of Soti et. al. is stable. Now, I use recommend of Daniel (use coupled fsi and trasitionperiod) to see that does the problem comes from initial condition or any other reasons make diverges.
Do you have similar problem?

I will run a case based on HronTurek FSI3 and report the result here.
Can you provide the title of the paper that you are referring to?

Regards,
D. Khazaei

[sita]

Hi Daniel,

Thanks for getting back. I'm using foam-extend-4.1 (installed that for its overset mesh capabilities), and yes, I'm suspecting something's wrong there. I'm now building foam-extend-4.0, see how that goes.

Thanks for all your help!
Sita

Originally Posted by Daniel_Khazaei

Hi,

I'm using foam-extend-4.0 and OpenFOAM-7 for now.
I did not change anything else and the simulation finished normally.

Which version of foam-extend are you using?
It seems that something is wrong with your foam-extend installation.

The final result at t = 6sec is also attached.

Regards,
D. Khazaei

[Hgholami]

Hi Daniel
I plot the result with libreOfficeCalc, using history/0/ folder. It is same as gnuplot script and the result is same. for default mesh size, the error by comparing with Hron-Turek Benchmark in 20s is about 10%. We don't have any Ref for more time, but my question is, why it doesn't reach to periodic?.

Would you please explain how did you plot the y-displacement?
Because there is a gnuplot script provided with the tutorial which is supposed to plot y and x displacement of the tip.

I think, we should use finner mesh to sure about reducing error, but in solids4Foam with finner mesh, the result for only first 4s, by time step 1e-4 and maximum Courant number of fluid = 0.145 is wonderful.

Can you provide the title of the paper that you are referring to?

the Ref. is https://www.sciencedirect.com/scienc...17931015000563

Thanks,
H. Gholami

[Daniel_Khazaei]

Originally Posted by Hgholami

Hi Daniel
I plot the result with libreOfficeCalc, using history/0/ folder. It is same as gnuplot script and the result is same. for default mesh size, the error by comparing with Hron-Turek Benchmark in 20s is about 10%. We don't have any Ref for more time, but my question is, why it doesn't reach to periodic?

First, you do not need to run the case for 20 seconds in order to investigate the validity of the result, just compare one complete cycle after reaching periodic state.
With the default tutorial settings I can confirm that the error is about 10% which is not optimal.

Originally Posted by Hgholami

but my question is, why it doesn't reach to periodic?

I'm attaching the image from my previous post again, how the displacement is not periodic here? Would you please explain how did you interpret the result?

http://uupload.ir/files/1ib8_deflection.jpg

Originally Posted by Hgholami

I think, we should use finner mesh to sure about reducing error, but in solids4Foam with finner mesh, the result for only first 4s, by time step 1e-4 and maximum Courant number of fluid = 0.145 is wonderful.

The solution procedure is implicit and you don't probably need to reduce the time step that much. I'm now running a case using the finer blockMeshDict.first file and will let you know how things are going.

Originally Posted by Hgholami

the Ref. is https://www.sciencedirect.com/scienc...17931015000563

Thank you very much.

Regards,
D. Khazaei

[Hgholami]

Hi,

I'm attaching the image from my previous post again, how the displacement is not periodic here? Would you please explain how did you interpret the result?

about periodic condition, I compare time of 50s with 6s that incrementally amplitude increases. But for limited range, the periodic condition with tolerance is true. Another question, may amplitude of deflection increases with time? is it compatible with real physic?

[sita]

Great, with foam-extend-4.0 I could run my simulation without any trouble! Wish I'd tried that earlier... There must be something in foam-extend-4.1 that doesn't work well with this case.

Thanks again everyone for your help,
Sita


P.S. Cool, the errors I used to get in Paraview, about duplicate entries D0 etc., are gone too now!

Originally Posted by sita

Hi Daniel,

Thanks for getting back. I'm using foam-extend-4.1 (installed that for its overset mesh capabilities), and yes, I'm suspecting something's wrong there. I'm now building foam-extend-4.0, see how that goes.

Thanks for all your help!
Sita

[tschenkel]

Originally Posted by sita

Great, with foam-extend-4.0 I could run my simulation without any trouble! Wish I'd tried that earlier... There must be something in foam-extend-4.1 that doesn't work well with this case.

Thanks again everyone for your help,
Sita

Hi,

I can confirm this. I tried the same case HronTurekFSI3/laminar both with fe40 and fe41 and it works with fe40, but not with fe41.

System setup:

Ubuntu 19.10

fe40:
gcc toolchain 5.5 (backported to 19.10 from 18.04 LTS, so I'd expect the findings to be the same for that one - but will test on my students' VM's)
foam-extend-4.0 (download from git on 07/03/2020), solids4foam (version from first week december 2019, but have confirmed on the CentOS install that the current butbucket version works the same apart from newSkewCorrected now being skewCorrected).

fe41:
gcc toolchain 7.4 (fe41 doesn't seem to like 5).

Question at this point: What are the development toolchains for the respective version? Would like to rule out compiler incompatibilities. None of (gcc 3 to 9) them will compile everything without warnings (or errors), the above seem to be the best fits I found.

Up to the point before it goes wrong everything looks OK (top is fe41, bottom is fe40) - time 3 seconds:

HT_40_41_comp_instab_anim.0148.jpg

But then the fe41 simulation goes wrong - time 3.1 seconds:

HT_40_41_comp_instab.jpg

and just before that, sigma deviates for the 41 simulation:

HT_40_41_comp_just_before_instab.jpg


The first 10000 and last 10000 lines of logfile for the cases are here:

log.solids4Foam40.zip

log.solids4Foam41.zip

So for now I think I'll stick to foam-extend 4.0 for FSI problems (and revert the teaching machines back to it as well).

If I can provide any more info to help track down the problem, let me know.


EDIT: As with Sita, I can also confirm that the D errors in paraview are gone as well. Also decomposePar does not complain about missing files (system/fvSchemes) in the 4.0 version.

In the current solids4Foam version the newSkewCorrected gradient scheme in solids4foam is renamed to skewCorrected (overriding the foam-extend one, I assume), so all tutorials need to be changed to reflect that in fvSchemes.

In the decomposeParDict, there is still a "globalFaceZone" defined, which leads to errors in the new implementation (hangover from the previous zone handling, I assume). This line needs to be commented.

[tschenkel]

Originally Posted by bigphil

Hi Sita,

Can you attach a simple example case to reproduce the problem?

Philip

Hi Philip,

while Sita's case has a few changes that seems to make it less stable, I have tested the laminar HronTurekFSI3 tutorial case, and it shows similar problems on 4.1 as opposed to 4.0, in which it runs nicely. See my recent post at the end of this thread. All I changed were changes required to make it run (comment globalFaceZone in decomposeParDict files, s/newSkewCorrected/skewCorrected in fvSchemes files), and changing the decomposition method to scotch instead of simple (I don't think 4 vs 8 cores makes a difference here on a single node with SMP - openmpi is the one that comes with the respective versions of foam).

Best
T

[sita]

Hi Torsten,

Just to have things clear, this issue doesn't seem to be solely related to solids4Foam. Apparently it's in the foam-extend-4.1 versions of pisoFoam and pimpleFoam, see also the post by Daniel_Khazaei here, and the thread to which he links, here.

So for now I'll stick to foam-extend-4.0.

Cheers,
Sita

[bigphil]

Originally Posted by tschenkel

In the decomposeParDict, there is still a "globalFaceZone" defined, which leads to errors in the new implementation (hangover from the previous zone handling, I assume). This line needs to be commented.

Thanks, I have now pushed a commit to the development branch removing these; I will merge with the master branch once tutorial tests pass.

Thanks,
Philip

[tschenkel]

Originally Posted by sita

Hi Torsten,

Just to have things clear, this issue doesn't seem to be solely related to solids4Foam. Apparently it's in the foam-extend-4.1 versions of pisoFoam and pimpleFoam, see also the post by Daniel_Khazaei here, and the thread to which he links, here.

So for now I'll stick to foam-extend-4.0.

Cheers,
Sita

Hi Sita,

Interesting. I have not noticed these, as I'm using my own code for non-FSI things.

T

[Daniel_Khazaei]

Originally Posted by Hgholami

Hi,

about periodic condition, I compare time of 50s with 6s that incrementally amplitude increases. But for limited range, the periodic condition with tolerance is true. Another question, may amplitude of deflection increases with time? is it compatible with real physic?

I think what we see here is the effect of numerical discretization.
Can you try the case with the following sets of schemes and see what happens?

[serfriz]

Hello Dr. Cardiff and everyone,

I am working on a simulation that involves FSI and crack propagation using the solids4foam library with foam-extend 4.0. I am having some issues when the cells break at the solid-fluid interface and I suspect it's because the fluid dynamicFvMesh is not suitable for fractures, or the fields mapping at the interface can't handle it.

So far my simulation is kind of a mix between the tutorials HronTurekFsi3 and crackingBeams (with my own structured grids). To be able to run the simulation I am geometrically forcing the crack to happen inside the solid mesh, and I let it propagate only restricting the fracture of the cells at the fluid-solid interface. If I let it break the solid's surface (actually forcing it to ensure it's the face I want) I am getting the following error:

There are 1 potential internal crack faces
There are 0 potential coupled boundary crack faces
Writing cohesiveZone field

Max traction fraction: 1.03503
    faceToBreakIndex: 1525
    faceToBreakLocation: (0.17108 0.249236 0.0075)
    faceToBreakEffTracFrac: 1.03503
Breaking internal face : (0.17108 0.249236 0.0075)
Updating field values on newly broken faces
Solving the momentum equation for D
    Corr, res, relRes, matRes, iters
    100, 5.54236e-06, 0.000386495, 0, 11
    200, 8.08764e-07, 6.82882e-05, 0, 11
    300, 1.78722e-07, 1.49448e-05, 0, 11
    The solver residual has converged
    339, 9.90346e-08, 8.27192e-06, 0, 11


There are 0 potential internal crack faces
There are 0 potential coupled boundary crack faces
Writing cohesiveZone field

Max traction fraction: 0
Interpolating point values using GGI


--> FOAM FATAL ERROR: 
fromField is the wrong size!
fromField size: 244, fromZone size: 242

    From function void Foam::interfaceToInterfaceMapping::checkFieldSizes
(
    const label fromFieldSize, const label toFieldSize
) const

    in file fluidSolidInterfaces/fluidSolidInterface/interfaceToInterfaceMapping/interfaceToInterfaceMapping/interfaceToInterfaceMapping.C at line 117.

  FOAM aborting

I attached some pictures of my working simulation (forcing no fracture in the surface layer of cells), and there are a couple more images in this link: https://imgur.com/a/o82gw8a. As a remark, after the last picture the simulation also fails (leaving one of the cells hanging from one side).


Are there any limitations of the fracture/SFI implementation I am running into? Or are these issues derived from my simulation setup?


Thank you!
Sergio

[sita]

Hi everyone,

What would be the correct way to impose a clamp boundary condition on a symmetry plane?

I tried turning my symmetry plane into a plain patch, and then imposing a fixedDisplacement of (0 0 0) (like in some of the tutorials), but this only restricts the displacement, not the curvature. Is there a way to restrict the curvature too?

Many thanks!
Sita


EDIT: Sorry, I was too quick asking my question; in the meantime I found the fixedDisplacementFixedRotation BC, which seems to be what I'm looking for. Now my question is how to use this BC, as that's not quite clear to me from the source file, and I can't find any tutorials using this BC.

[bigphil]

Hi Sita,

Can you provide more details on the type of boundary condition you are looking for?

You are right that fixedDisplacement sets the displacement of each face, but if you have more than one face in the patch then this indirectly restricts any rotations/curvature as well.

Philip