[bigphil]

Hi Danny,

Originally Posted by danny261083

I was wondering whether the solid solvers support meshes of all shapes particularly tetrahedral.

The solver should work with any mesh, but obviously a very poor mesh will give poor results.
The accuracy for these solid solvers is essentially determined by the accuracy of the gradient operator, so use extendedLeastSquares gradScheme.
And also make sure you use the included boundary conditions which have boundary non-orthogonal correction, which is imperative for unstructured meshes with these solvers.

Originally Posted by danny261083

I was also unsure whether the total lagrangian solver is for a specific material model like StVk, Mooney Rivlin, Neo-Hookean, etc.

At the moment, the TL solver is essentially for a Neo-Hookean material, but it should be straight-forward to extend it to other constitutive models (unless you want incompressibility, then you need to include the pressure equation).

Best regards,
Philip

[Daniel_Khazaei]

@ bigphil

I am trying to use icoFsiElasticNonLinULSolidFoam in parallel.
I am running the tutorial case you have provided.
but I get the following error after some time:

Time = 0.065, iteration: 3
Current fsi under-relaxation factor (Aitken): 0.362946
Maximal accumulated displacement of interface points: 0.00876687
[0] [1] 
[1] 
[1] --> FOAM FATAL ERROR: 
[1] face 41 area does not match neighbour by 0.0103705% -- possible face ordering problem.
patch: procBoundary1to0 my area:0.000239418 neighbour area: 0.000239443 matching tolerance: 0.0001
Mesh face: 42054 vertices: 4((0.574801 0.214706 0.025334) (0.574801 0.214706 -0.025334) (0.574854 0.209981 -0.025334) (0.574854 0.209981 0.025334))
Rerun with processor debug flag set for more information.
[1] 
[1]     From function processorPolyPatch::calcGeometry()
[1]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 216.
[1] 
FOAM parallel run exiting
[1] 

[0] 
[0] --> FOAM FATAL ERROR: 
[0] face 41 area does not match neighbour by 0.0103705% -- possible face ordering problem.
patch: procBoundary0to1 my area:0.000239443 neighbour area: 0.000239418 matching tolerance: 0.0001
Mesh face: 42167 vertices: 4((0.574801 0.214706 0.025334) (0.574854 0.20998 0.025334) (0.574854 0.20998 -0.025334) (0.574801 0.214706 -0.025334))
Rerun with processor debug flag set for more information.
[0] 
[0]     From function processorPolyPatch::calcGeometry()
[0]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 216.
[0] 
FOAM parallel run exiting
[0]

I have attached the complete log file:

http://www.rodfile.com/tgp64725opo7

[bigphil]

Hi Daniel,

I have a question about FSI solver which is included in your solvers. does it use strongly coupled Method?
Can I use it for flow simulation in deformable pipes?

Yes, the solver uses a so called strongly-coupled partitioned method, where outer FSI iterations are performed (NOT a monolithic approach).
So yes the solver should work with flow inside a deformable pipe.

Do you have any documentation on this particular solver?

Željko Tukovic developed this solver, as detailed in the following:
http://powerlab.fsb.hr/ped/kturbo/Op...Zagreb2007.pdf
http://www.tfd.chalmers.se/~hani/kur.../FSIslides.pdf

The partitioned FSI procedure is described in a number of references, for example in Aleksandar Karac's thesis:
http://powerlab.fsb.hr/ped/kturbo/Op...arKaracPhD.pdf

For your error above, I am not entirely sure of the reason, people have previously mentioned this issue.
Is the model converging to the defined tolerance?

Also you are correct that the IQN-ILS scheme coupling scheme is not currently implemented, even though it is given as an option.

Philip

[Daniel_Khazaei]

Originally Posted by bigphil

Hi Daniel,

For your error above, I am not entirely sure of the reason, people have previously mentioned this issue.
Is the model converging to the defined tolerance?

Philip

Thanks Philip

everything is just fine till t=0.065 sec..
before this time the solution was converging just like the serial run.
I was simulating the provided case without any changes.

[davidsblom]

Hi Philip,

Just a small question, could you post the blockMeshDict and an easy way to generate the faceZones file for the FSI test case? This would be of great help.

I'm currently developing a FSI solver with space mapping and multi level acceleration, so I need an easy way to generate new grids.

Looking forward hearing from you!

Best regards,

David Blom

[bigphil]

Originally Posted by davidsblom

Just a small question, could you post the blockMeshDict and an easy way to generate the faceZones file for the FSI test case? This would be of great help.

I'm currently developing a FSI solver with space mapping and multi level acceleration, so I need an easy way to generate new grids.

Hi David,

Unfortunately the mesh for the FSI test case was created (not by me) using Gambit, so there is no blockMeshDict.
If you are familiar with blockMesh, it should be relatively straight-forward to create the blockMeshDict for this case, albeit time consuming.

Originally Posted by Daniel_Khazaei

everything is just fine till t=0.065 sec..
before this time the solution was converging just like the serial run.
I was simulating the provided case without any changes.

Hi Daniel,

I have had a look at this processor faces error: could you try out the attached "moveSolidMeshLeastSquares.H" (place this in the solver directory and execute "wmake").
I have added a few lines that should make sure that the processor boundaries are exactly the same.

Let me know if it works for you.

Best regards,
Philip

[Daniel_Khazaei]

Originally Posted by bigphil

Hi David,

Hi Daniel,

I have had a look at this processor faces error: could you try out the attached "moveSolidMeshLeastSquares.H" (place this in the solver directory and execute "wmake").
I have added a few lines that should make sure that the processor boundaries are exactly the same.

Let me know if it works for you.

Best regards,
Philip

first, thanks for your attention Philip

I have recompiled the the code with "moveSolidMeshLeastSquares.H" you've provided.
I get floating point exception in both parallel and serial runs after only one time step.

regards

[Daniel_Khazaei]

I think I got the error fixed.

I have changed the following in the code you've attached:

for newPoints I changed "mesh" to "stressMesh" (solid mesh)

I will test and report if the main error is eliminated or not.


regards

edit: I can confirm the problem has been fixed. I have attached the modification.

thank you very much Philip

[bigphil]

Originally Posted by Daniel_Khazaei

I think I got the error fixed.

I have changed the following in the code you've attached:

for newPoints I changed "mesh" to "stressMesh" (solid mesh)

I will test and report if the main error is eliminated or not.


regards

edit: I can confirm the problem has been fixed. I have attached the modification.

thank you very much Philip

OK great.

Yep, sorry you are correct 'mesh' is meant to be 'stressMesh' - I tried out this code on an UL solid solver which calls the solid mesh 'mesh'.

I will add this change to the git.

Philip

[Daniel_Khazaei]

Originally Posted by bigphil

OK great.

Yep, sorry you are correct 'mesh' is meant to be 'stressMesh' - I tried out this code on an UL solid solver which calls the solid mesh 'mesh'.

I will add this change to the git.

Philip

I want to add IQN-ILS scheme for FSI solver, do you have any paper to describe the algorithm?
does it need huge modification on the base code?

regards

[bigphil]

Originally Posted by Daniel_Khazaei

I want to add IQN-ILS scheme for FSI solver, do you have any paper to describe the algorithm?
does it need huge modification on the base code?

regards

I don't know papers off-hand but if you google "interface quasi Newton inverse Jacobian least squares" or something along those lines, then you should come across a number of papers and theses.

As far as I know, there will be quite a bit of work getting it working, but don't let me deter you

Philip

[soheil nazmdeh]

Hi,
i try to add solid mechanics but this error seen,

I've already download openFoam 1.6 ext from openFoam wiki.

please help me to add solidMechanics


fluidman@fluidman-Aspire-5755G:~/OpenFOAM/OpenFOAM-1.6-ext$ git checkout -b feature/solidMechanics remotes/origin/feature/solidMechanics
fatal: Cannot update paths and switch to branch 'feature/solidMechanics' at the same time.
Did you intend to checkout 'remotes/origin/feature/solidMechanics' which can not be resolved as commit?

[bigphil]

Originally Posted by soheil nazmdeh

Hi,
i try to add solid mechanics but this error seen,

I've already download openFoam 1.6 ext from openFoam wiki.

please help me to add solidMechanics


fluidman@fluidman-Aspire-5755G:~/OpenFOAM/OpenFOAM-1.6-ext$ git checkout -b feature/solidMechanics remotes/origin/feature/solidMechanics
fatal: Cannot update paths and switch to branch 'feature/solidMechanics' at the same time.
Did you intend to checkout 'remotes/origin/feature/solidMechanics' which can not be resolved as commit?

Hi,

I am far from an expert in git, but try the following:

git remote update
git fetch
git checkout -b feature/solidMechanics origin/feature/solidMechanics

Philip

[Daniel_Khazaei]

Originally Posted by bigphil

I don't know papers off-hand but if you google "interface quasi Newton inverse Jacobian least squares" or something along those lines, then you should come across a number of papers and theses.

As far as I know, there will be quite a bit of work getting it working, but don't let me deter you

Philip

The main reason is I want to simulate blood flow and if I know that Aitken underrelaxation method can handle it, I don not need IQN-ILS scheme anymore.
The problem is when I change rhoSolid=1000 and rhoFluid=998 after a few iterations I get floating point exception error on solidSolver for DU.

thanks for the help man

[soheil nazmdeh]

thank you philip.

It does not work...

Can you send me the Solvers ?

Soheil.nazmdeh@gmail.com

thank you

[Daniel_Khazaei]

@ Philip

I am very sorry but I was mistaken, the problem is still there. I was in hurry and entered the parallel command with out noticing that I have drop the main part:

I used "mpirun -np 2 icoFsiE...." instead of "mpirun -np 2 icoFsi... -parallel"

I have noticed that when I got home.


regards

[bigphil]

Originally Posted by soheil nazmdeh

thank you philip.

It does not work...

Can you send me the Solvers ?

Soheil.nazmdeh@gmail.com

thank you

I previously posted a link to a ".tgz" of the code, as detailed in this post.

Philip

[Daniel_Khazaei]

@ bigphil

today I have compiled OpenFOAM-1.6-ext with openmpi-1.5 but the problem is still there.
could something be wrong with the tutorial case setup or you don't have this problem on your own system?


regards

[davidsblom]

Hi Philip,

I noticed another small problem with the mesh deformation code of the structure solver. The fluid-structure interface isn't matching anymore after a couple of time steps at the attachment location to the cylinder. Is it possible that the plateFix patch is not taken into account by the mesh motion algorithm?
Thanks in advance!

Best regards,
David

[sloti]

Hi everyone,

I had a look at Philips FSI solver and am especially excited about the possibility to run it in parallel, as icoFsiFoam is apparently not running in parallel yet.

However, I managed to run the HronTurekFsi case in parallel but I can't reconstruct the data.. the results of the processors are all stored under the fluid/processor*/"time" folder where also the solid results are located within another folder (fluid/processor*/"time"/solid). When I run reconstructPar that folder is ignored and only the fluid data is reconstructed.

Probably I just make a stupid fault.. Any help would be appreciated!

Regards, Anna

Update: problem solved. not sure whether this is the most elegant way, but I wrote a batch sorting things out!