Philip,


Thank you for the response. After recompiling with the Debug option set, and using mpirunDebug to run the case as follows:


I get the following error returned:


By manipulating the decomposeParDict, I have been able to determine that the vector fields f1 and f2 have the same size as the FSI patch assigned to processor0 (i.e, there are 2,842 faces of the FSI patch assigned to processor0 above), and f3 seems to have the same size as the FSI patch assigned to processor1. I'm not sure what operation the solver is trying to do here; do you have any ideas?


Thank you,
Kellis

Hi Kellis,

Try the following command to run the solver in parallel through the gdb debugger:
This will open up four terminals, where each processor is running in a different terminal.

Once gdb opens, you can start each process with the "r" command. You should then be able to see which processor stops and you can find out where it stopped using the "bt" (backtrace command). You may need to add a breakpoint at FieldM.H:84 to find out where.

Best,
Philip

Philip,


Thanks for your continued help. Per your instructions, I ran the program in gdb, and added a break at that location. The output at the break was as follows:


Running the backtrace produced the following output:


Unfortunately I don't have much experience with C++ so most of this is gibberish to me. Are you able to extract anything useful from this info?


Thanks again,
Kellis

Thanks Kellis,

From the last line of the backtrace, we can see that the code is failing in the file "createZoneToZoneInterpolators.H" at line 53: this line of code is:
which is a parallel syncing step (reduce) where the vectorField "fluidZoneFaceCentres" is summed across all processors. The size of the "fluidZoneFaceCentres" field should be the same on all processors (it is based on the fluid interface globalFaceZone); however, from the error you receive, we can see that the size of this field is different on each processor.
On proc0 we can see that it has size "2842" whereas on proc1 it has size "0".

So it looks like the faceZone is not a globalFaceZone; did you include the FSI fluid interface zone name in the globalFaceZones list within decomposePar?

Philip

Philip,

Wow, you are a magician! Indeed I don't currently have globalFaceZones option set in the decomposeParDict. I have tried this before, but it produces the following error while decomposing the fluid fields (full log attached):

Looking into the fluid/processor0/0 directory, I noticed it didn't write the motionU file, so I'm guessing this is where the error lies. I went ahead and ran decomposePar again with gdb, and got the following backtrace:


Looking at the decomposePar.C file at line 746, I see this is where the pointVectorFields get written, which reinforces the idea that there's an issue with the motionU field. However, I'm not sure where decomposePar is getting the size of the field and mesh from. I searched my case directory for the two size values it spit out, but they don't seem to be written in any of the files.

I've attached the full decomposePar log file, as well as the dictionaries for both the fluid and solid meshes. Hopefully these are helpful.

Again, thank you for all of your assistance so far!

Thanks,
Kellis

Hi Kellis,

Yep it looks like it is a problem decomposing the motionU file. To double-check, I suggest you move the motionU file out of the "0" directory and see if decomposePar works in that case.
If it does then we know motionU that is causing the problem. motionU is the mesh motion field for the FE motion solver so I think decomposePar doesn't know what to do with it when there are globalFaceZones. I vaguely remember there being a fix for this in decomposePar (maybe it was a later commit of foam-extend-4.0). Which commit of foam-extend-4.0 are you using? You can check by typing "git log" in the foam-extend-4.0 directory (assuming you downloaded it with git). I am using commit 246a172c9d9ecdbfc8f18b8224467de7f2b7606e dated 21 Sep 2017.

Also, can you share a simple version of your case and I can check if it decomposes with version?

Alternatively, you could also try the FV motion solver in the dynamicMeshDict: it uses pointMotionU instead of motionU.

Philip

Philip,

I will try to get a simplified version of my case put together for you and send it to you via PM. In the mean time, I checked if it will decompose without the motionU or pointMotionU files, and indeed it works perfectly.

I did a little more investigation into the decomposition error. As a reminder, it was throwing the following error while trying to decompose with the motionU files in the 0 directory:

I ran the checkMesh utility in the processor0 directory, and found out the following:

So it appears it is complaining about the discrepancy between the total number of points, and the number of live points. I can't find any documentation on what exactly "live" points are; in the full mesh, the number of live points exactly matches the total number of points.

So I suspect it is probably something with the way the mesh is getting decomposed. I'll send you my case ASAP.

As always, thank you!

-Kellis


EDIT: Also, I forgot to mention I am currently using Extend v3.2, commit 56c5fe3e449d4c1c1c1a5f56c9320c56f65785bc, dated 22 Sept 2016. I tried using FE 4.0, but had issues with the solver hanging while setting up the GGI interpolator.

FYI, for others:

For foam-extend-3.2, using decomposeParFsi from the extendBazaar fixes this issue.

For foam-extend-4.0 (and later), this issue has already been fixed in decomposePar.

Philip

Hello all,

Is there any recommended solver for this FSI problem (in attachment)?

I hope me ask in the right thread... :confused:

Many thanks in advance.

-Wu

Hi Wu,

I have been working on this "flexible" dam break case using the solids4foam repository I am working on: PM me your email and I can share.

Philip

Stability Issues with 3D Solver
 

Hello all,

I am back again, unfortunately with more issues. Thanks in advance for any tips or help you may have!

As part of a project I am doing, I need to solve a solid experiencing 3D forces. I have created a simple test case based on the largeStrainCantileverBeam tutorial, but am using the elasticSolidFoam solver because I don't expect large displacements in the project. However, moving to 3-D has caused some stability issues which I can't seem to resolve.

Starting from the tutorial case, several changes were made. The applied force was reduced, but acts in all three directions now (the force vector is (1000 1000 1000) on the right patch). Additionally, I changed the blockMeshDict and boundary files so that there are five cells in the third dimension, and the frontAndBack patch is no longer empty.

Additionally, I changed the "planeStress" keyword to "no," since the case is no longer 2-D. This is where the problems start. After a few iterations, I get the "complex eigenvalues detected" warning, and eventually a floating point exception. Interestingly, changing the planeStress flag back to "yes" prevents this from happening, but the solution still doesn't reach tolerance in 10,000 iterations.

So, obviously there has been work done in 3D with the Foam Extend solvers before. Can anyone help identify where my issue is? Attached is the test case where I am getting the error. Thank you!

PS - The end goal is to add a centrifugal force and solve in an SRF, so if anyone has done that before please let me know!

Hi everybody!


I am working on a FSI problem, where a thin membrane flaps due to sloshing inside a tank. Due to its flexibility the flapping part might have a contact with the tank.
I think I should use FSI in Foam extend 4.0, namely icoFsiElasticNonLinULSolidFoam,
due to large displacement. However, in order to avoid cell excessive distortion or degeneration when the flap approximates to the bottom I should impose a topology change within the dynamic mesh. But I am afraid in order to include a contact model, I also have to compile a new solver.
Can you please give me any hints?



Philip, would be solids4foam useful in this context?


Thanks in advance!!

Reference temperature in elasticThermalSolidFoam
 

Hi all,

I'm working on the thermal stress simulation during cooling process of a solid plate using elasticThermalSolidFoam. But I found an issue with the reference temperature.

When I set the initial temperature of the plate at 800K and started cooling by applying a fixed 300K boundary condition for all the faces, the result of displacement should show contraction. But I found that I always got expansion no matter I tried cooling or heating. The stress, on the other hand, was as expected. I checked the first time step and found that the plate actually got an initial expansion and then started to contract. This expansion should be due to the temperature difference between 800k and 0K. I know I can set T0 in thermalProperties but it did not seem to make any difference after I tried.

Does anyone know how to avoid this problem?

Thanks.

Hi Duo,

The stress and displacement will depend on the applied mechanical boundary conditions i.e. boundary conditions for U/DU (or D/DD depending on your version). Can you give some details on your geometry and displacement boundary conditions? In addition, what values of the reference stress-free temperature T0 did you try?

Philip

Hi Phil,

Thanks for your quick reply.

The geometry is just a 6m * 2m * 1m bar. I'm setting all six faces as displacement free by the following setting:

{
type solidTraction;
traction uniform ( 0 0 0 );
pressure uniform 0;
DT k;
value uniform (0 0 0);
}

As for the reference temperature, I tried to set it the same as the initial temperature of the bar, which is 800K. I assume this could give me a stress free initial state.

About the displacement boundary condition, I know that free surface is not a good condition especially when there are different cooling conditions for different faces. I found that I got unreasonable displacement result (as large as 10^7) when I set top and bottom faces fixed at different temperatures. But the stress results are as expected. Do you have any suggestions on how to set a proper displacement boundary condition that will not introduce rigid body motion and stress concentration?

Thanks so much for your help. I'm new to this area. These solid mechanics solvers are really helpful!

Hi Duo,

Yes it's important to restrain all rigid body motion; to do this you could:

• create a patch with one face and set it to zero displacement: this will remove rigid translation (rigid rotation could still be an issue);
• set the displacement of one internal cell to be zero; once again this will remove rigid translation (rigid rotation could still be an issue); I have included this feature in soldis4foam (PM me if you want to try it out);
• if there are any symmetry planes, make sure to take advantage of them: these remove rigid translation in the direction normal to the symmetry plane.

If rigid rotation is an issue (it may not be) then you could create 2 or 3 small one-face patches and fix their normal displacement with the fixedDisplacementZeroShear boundary condition.

Philip

Hi Phil,

Yes, rigid body motion can be restrained if proper displacement boundary is applied, but the problem with the reference temperature for stress free state can actually cause some trouble.

I tried one case where all faces of the bar are constrained by zero displacement. The boundary condition for T is fixed low temperature for all faces to simulate cooling. Due to the contraction after cooling, the surface should be in tension. But the result showed compression instead.

So, how to eliminate the initial expansion is still a problem. This also happens when I tried the solidDisplacementFoam in Openfoam. I found that T0 can be changed in elasticThermalSolidFoam, but changing it makes no differences. If T0 can not be used to set the stress free state, what's the point of changing it?

Thanks,
Duo

Hi Duo,

Yes, of course, the T0 field should have an effect. Can you share your case here?

Philip

Hi Phil,

Sorry for the late reply. Here are some of the settings of the case.

blockMeshDict
T
U
thermalProperties
You can see that I already changed T0 in thermalProperties to 800K.
After running, the displacement results showed expansion in all x,y,z direction. (Sorry, I haven't figure out how to upload images)

Thanks again for your help.

Duo

Hi Duo,

Can you attach your case as a tgz/zip?

Thanks,
Philip

Hi Phil,

The case is attached. Thanks so much for your time.

Duo

Extend Bazaar FSI and RBF
 

Hi All,

I'm using the foam-extend 4.0 bazaar to do FSI on flexible airfoils and I am having some trouble with mesh motion. It seems that the fsiFoam solver has only been implemented with RBF point interpolation and while RBFMeshMotionSolver is in the library, fsiFoam refuses to use it when I patch it into the dynamicMeshDict.

After the first time step's solid predictor I get the following error when the cell motion step occurs:

I am wondering if someone has been able to patch in the RBFMeshMotionSolver for fsiFoam and could give some hints on how to move forward as the .moveFluidMesh() call only allows for fe/fv motionSolvers to be used and is hard coded.

Thanks,

Jon

Hi Duo,

PM me your email address and I will send you the case that works with solids4foam (i.e. the slab contracts when T0 is 800 and expands when T0 is 100).

Philip

hi
i want using of Mooney-Rivlin hyperelastic model.
i can use icoFsiElasticNonLinULSolidFoam for this model?
regards,
nima

Hi nima,

Mooney-Rivlin is not currently implemented but it can be implemented, either directly in icoFsiElasticNonLinULSolidFoam or it may be more convenient in solids4foam (PM me if you want access).

Philip

Edit: compressible neo-Hookean is implemented in solids4foam is that is good enough.

hi Philip,
thanks for your answer,
i want use Mooney-Rivlin assumed to be hyperelastic, isotropic, incompressible and homogeneous. where the strain energy density function assumes the form:‬
w=C1(I1-3)+C2(I2-3)+D1[(e^(D2(I1-3)))-1]
how can i implemented this model in icoFsiElasticNonLinULSolidFoam or in solids4foam.
thanks,
nima
note:i use foam-extend-3.2.

Hi nima,

To implement a new constitutive law, you need to find a procedure/algorithm to calculate the stress tensor (e.g. Cauchy, 1st/2nd Piola Kirchhoff) from the deformation gradient. Once you have this procedure, you can code this into foam e.g. copy and rename the neo-Hookean hyperelastic mechanical law in solids4foam and then insert the new code for calculating the stress tensor in the "correct()" function.

Philip

Hello,

I'm currently trying to simulate a rotating beam with FSI. The rotation is forced on one face of the solid, using timeVaryingFixedRotation while the others are considered as "FSI interface".

The fluid mesh at the interface follows quite well the structure mesh on the FSI interface patches. Yet, I still haven't managed a way to make the fluid mesh follow the solid one on the face where the rotation is forced.

Attachment 68811

On the picture, the red face is where I force the rotation. As you can see, the fluid grid (white wireframe) doesn't follow the solid one on this specific face.

I have some questions:
- Did someone make something similar ?
- Is it possible to force a specific displacement/rotation on a surface patch of the fluid mesh ? And how ?

Any idea or hint is welcomed ! I can provide my case if I wasn't clear enough...

Regards,

Paul

hi Philip,
i use Cauchy method to calculate the stress tensor.
how can i obtian solid4foam for foam-extend-3.2?
thanks for your answer,
nima

Hi Paul,

It seems like you need a suitable rotation fluid mesh motion boundary condition. I suggest you have a look through the tutorials for the different types of fluid mesh motion (motionU/pointMotionU fields) boundary conditions used.

Philip

Hi nima,

PM me your email address and I can share solids4foam with you; the latest master and development branches compile with foam-extend-4.0 and foam-extend-4.1, though there is also a deprecated foam-extend-3.2 branch.

Philip

Hi Philip,

First of all, thank you for taking time to answer.

I went through tutorials for the different fluid mesh motion, and I have found that I need something like angularOscillatingDisplacement. However, all of the examples are realized with dynamicTopoFvMesh and mesquiteMotionSolver. Is there a way to make it work with dynamicMotionSolverFvMesh and a "more classic" solver such as velocityLaplacian (as I heard mesquiteMotionSolver can be really tricky with FSI simulations) ?

I thing I'm missing something, but for now I haven't managed to make it work. The log.decomposePar sends me this:

Regards,

Paul

Re: paulbr BCs
 

Hi Paul,

There is a way to make what you want working with dynamicMotionSolverFvMesh it just requires a little bit of coding. If you could provide some more context about your case setup regarding the geometry and how you want to move things we can figure it out. Also, if you are using fe32 for your simulations still, I have some old code (including an old rotatingBC written by Dr. Cardiff) that might just solve your problem.

Regards,

Jon

Hi Jonthan,



Thank you for your answer! I’ll have a look at this rotating BC in fe32. I’m currently using fe40.
My case is as follow:

• I’m forcing the rotation on one solid face (red one on Attachment 69006 and Attachment 69007) with timeVaryingFixedRotation. Note that for this case, the plate is fully immersed but it will be embedded in the flume wall.

• The others faces (yellow on Attachment 69006) are freed to deform wrt the hydrodynamic forces. The deformation is taken into account with the implicit FSI algorithm.

For now, the fluid mesh (white wireframe in Attachment 69008) at the fluid structure interface precisely follows the solid mesh (bleu in Attachment 69008) displacement except on the fluid nodes corresponding to the solid red face. They are not moving which is not surprising because they are not marked as “FSI interface”.

To overcome this problem, I think the easiest way is to force the displacement (which is known as it is the same as the solid one) of these nodes.
I can't provide my case here, even with coarse meshes, as my meshes are generated with ICEM... I sent you a private message.

Regards,


Paul

Philip,

You recently provided me a copy of solids4foam that I'm running with foam-extend 4.1 (thanks again, by the way). I'm attempting to run the HronTurekFsi3 tutorial and am repeatedly met by a FOAM Warning that the NeoHookeanElastic model is enforcing material linearity for stability. The first few time steps that this warning occurs it eventually disappears, but at Time = 3.264 I'm seeing my fsi iterations not converging (50 fsi iterations was max). The subsequent time step (Time = 3.265) pops the enforced linearity warning again and by the 17th fsi iteration within Time = 3.265 everything comes to a crashing halt.

My current thinking is that I could start from a previous time step (Time = 3.2, for example) and decrease the time step size such that the burden on the fsi coupling is decreased and maybe Time = 3.264 will converge. I could also play with the fsi under-relaxation factors/algorithms.

Unfortunately, when I attempt to restart this simulation from a previous time step, I'm met with another error:

I've attached the log files from the original solids4Foam solve as well as my attempt at a restart.

Am I interpreting what's happening in the original solids4Foam solve correctly? Is my strategy sound? What am I doing wrong when I'm attempting a restart from Time = 3.2? Do you need any more information to help me realize my mistake?

Any help is appreciated. Thanks!

Rectangular Tank with visco-elastic solid
 

Hi,

I am new to openFoam. I want to compare the shear stress (wall and fluid/solid) that occurs when a rectangular tank undergoes linear oscillation (in vertical or z-direction).

I was able to do that for the case when the fluid is inside the tank using tutorial 'sloshingTank3D' under the section multiphase with little modification.

But when I need to solve for viscoelastic solid inside the tank (collagen in my case), I am not sure where/how to start. I am using openFoam ext 4.0.

The purpose is to calculate the shear stress that occurs when cancer cells inside the cell well are subjected to oscillatory mechanical vibration (20 Hz to 90 Hz) in the vertical direction with substrates like cell medium and collagen. Cell medium is similar to water.

Any input/help is appreciated. Thanks!

(I created a separate thread for it already. Then I saw this is the support thread for solidMechanics. So posting it here also.)

Hi Mike,

For the restart error:
This problem is related to the re-creation of the interpolator (between solid and fluid) on restart, where the deformed position of the solid may not have been taken into account. I have just pushed a fix to the development branch; double-check it works for your case. I will push it to the master once I have performed other checks.

As regards the warning "enforcing material linearity for stability", this indicates that the solid model is struggling to converge. Possibly, under-relaxation (in fvSolution for the D field and/or equation) may help.

Philip

Phil,

I pulled from the development branch and can confirm that restarting now works.

I'll play around with the under-relaxation and/or time step from here. Thanks!

Hi,

I´m doing a FSI on cylinders. Already made it work with one cylinder. Both fluid and solid meshes were created with sHM.

Now I want to simulate it with 4 cylinders. sHM can´t create a solidmesh with unconnected cylinders...I think. Forum. Or at least I didn´t find out how to do it yet. Ironically the simulation in the link is running for some time, even though there is only one meshed solid cylinder out of 4:
https://i.imgur.com/j6234gm.pnghttps://i.imgur.com/7653LfI.png

Anyway my workaround was to create the solid mesh with blockMesh.

So the fluidmesh is created with sHM and a solidmesh with blockMesh only. checkMesh says "ok" and the fluid mesh is running without issue as CFD.

https://i.imgur.com/tnRrEj0.png

But now the simulation stops after:

and my simulation log tells me:
"Speicherzugriffsfehler" is german and has the meaning of memory access error.


Do you have any idea what went wrong? Many thanks for your help in advance. File of the case is attached.
Using extend-4.0 for the simulation with icoFsiElasticNonLinULSolidFoam solver.


Things on my mind about this error:

I already checked if the error is because of the 4 unconnected solid cylinders. But it even crashes when I create a one cylinder case with sHM fluid and blockMesh solid. So maybe there is the problem?
Used 4.0-ext for creating the fluid mesh and 4.x for the solid mesh. Can using different Version of OpenFOAM be the reason for the error? (Had to use 4.x for the solid mesh because with 4.0-ext one of the cylinders had non-ortho..with 4.x all cylinders we´re fine) But the error is the same if I use 4.0-ext for creating fluid and solid mesh. (even if the non-ortho cylinder is left out - then it should at least run for some time steps as before with only 1 out of 4 solid cylinders).
(Edit* used 4.x to create both meshes and still have the same error. So using different versions for mesh creation was not the reason for the error)


Summarizing unconnected patches under one patch could cause issues or unrealistic results. But my predecessor (using blockMesh for fluid and solid in 3.2-ext) had at least a running simulation. Also there is no way I´m allowed to edit the source code of 4.0-ext on the cluster I´m using. (Which is required to implement the changes Phil proposed in 2016)

Hi Goddi,

I am not sure why you are receiving a memory error; if the mesh is valid, then it suggests a problem in the code. Multiple solid unconnected solid meshes should not be a problem.

You may like to try the case in solids4foam (PM me your email and I will share it), to see if the issue is related to some bug that has been fixed.

By the way, you could use snappyHexMesh for four solid meshes by creating four cases, where each case will create a mesh of a different cylinder; then use mergeMeshes to merge all four meshes into one solid mesh.

Philip