[Maimouna]

Dear OpenFOAM users,

I'm trying to follow the same tutorial given in fsiFoam solver in foam-extend3.1. This tutorial named HronTurekFsi3 (attached). I tried to implement one the same as that original case. The difference between the original case and my one could summarise in the information given in http://www.sciencedirect.com/science/article/pii/S0045782505005177. My one is square cylinder instead of circular cylinder given in the original one. All boundary conditions and geometries are given in page 5767 and 5768 in the attached paper.

My case named HronTurekFsi3-New that I implemented are shown in the attached folder.

Q: What changes I did to the original case?
I generated the mesh using blockMesh utility the same as in the original case. In my case, it's square cylinder but in the original one it's circular. Also, the boundaries are different, my one are shown in the attached paper.
I kept transportProperties in fluid folder and rhyologyProperties in the solid folder the same as in the original case and also U in 0 folder it's given 51.3 m/s in the paper but 0 m/s in the original one. When I used paper value 51.3 m/s it's given me error, so I kept it 0 m/s. I don't know why

Q: What steps I do for generating the mesh, running the simulation and post-processing.
* for mesh generation: blockMesh utility
* for running the simulation
cd FluidStructureInteraction/run/fsiFoam/HronTurekFsi3-New
chmod 755 *
sed -i s/tcsh/sh/g *Links
./removeSerialLinks fluid solid
./makeSerialLinks fluid solid
cd fluid
./Allclean
./Allrun
* for postProcessing: paraview

The case was running fine, but the simulation doesn't show beam movement, I think that because of fluid/solid interface mesh problem., am I right? Could you please help me regarding this case and solve its problem.

Lots of thanks in advanced and kind regards

Maimouna

[wyldckat]

Hi Maimouna,

When using OpenFOAM or foam-extend, the usual rule of thumb is to almost never go directly to the final simulation you're planning on doing.

It took me a while to get a working environment. So much that I had to update considerably the wiki page for the toolkit you're using: http://openfoamwiki.net/index.php/Ex...re_interaction
Now you can find there a lot of instructions and documentation that was missing a few hours ago
And thank you for the detailed steps on how to run the case as well! It made it a lot easier to run these cases, as well as document them in the wiki!


Going back to what I wrote at the beginning of this post: I can't say for certain, but one of the problems seems to be related to the mesh being too refined. It took my machine nearly 2900s to reach the point where your case "HronTurekFsi3-New" crashed, in part due to the mesh being so refined . My first suspicion is that this overly refined mesh is the reason why the solver crashed.

My advice is to reduce the refinement to something more similar to the mesh in the "HronTurekFsi3" case. Afterwards it should be easier to diagnose the first problem.

Best regards,
Bruno

[Maimouna]

Dear Bruno,

many thanks for the last post. I tried to refine the mesh as one in the original case HronTurekFsi3, the new mesh was attached.

The case HronTurekFsi3-New works fine, I just changed some files U, blockMeshDict, transportProperties, and rheologyProperties to the value given in the paper attached in post#1.

Note that: all changes were saved in the attached folder named AllChanges.

I'm still couldn't see any movement in the beam. How could I make such motion in the beam the same as one given in the tutorial case. Could you please check my case and what's wrong on it?

Many thanks in advanced and regards.

Maimouna

[Maimouna]

Finally, the beam is moving now but the animation shows something wrong. I tried to post avi file to show the animation but unfortunately invalid file. What accepted files for animation?

The case started to work then it is blown up at 4.92s. I'm working in the same case that I posted in #1, the only changes in U inlet BC is (1 0 0) instead of (0 0 0) and I choose nu for fluid 0.01 for 100 Reynolds number.

Sorry, I got attached problem, I couldn't reattach my case. I need your help to check my case and let me know why running blown up and from the animation are there any wrong in the BCs, check that for me please.

Kind regards

Maimouna

[wyldckat]

Hi Maimouna,

I'm unable to use the "AllChanges" package you provided on the previous post. The "blockMeshDict" for the solid region is missing.

Either way, before you can package the case folder "HronTurekFsi3-New", you need to run the script "./Allclean" from within the folder "fluid", so that it will clean up the case.
But be careful to first make a copy of the folder, in case you want to keep the results you've gotten.

Best regards,
Bruno

[Maimouna]

Dear Bruno,

I already tried what you suggested but still the folder size is very large, that's why I just attached you fluid and solid folders in the attached one. The last changes in that two folders only what I added no more. I'm still looking to know why case is blown up after some time and the flow motion in the simulation is wrong comparing with the original one, I think it's BCs problem, am I right? If yes, what's wrong? and If not, what's problem?

I'm really need help to show the correct result. Have a look of my case again with that the last changes in fluid and solid.

Kind regards

Maimouna

[wyldckat]

Hi Maimouna,

Sorry, it's taking too long to run and I stopped running it after 1h30m.

My advice is to look at the results. You can see the two meshes (fluid and solid regions) by running paraFoam like this:

paraFoam -nativeReader

My guess is that the solid region is being stressed too much and the amplitude of the deformation is so big that the solver crashes with non-physical calculations. I say this because at 2.72s of simulation time, the amplitude is already pretty big and the "log.fsiFoam" log file is occasionally pointing out forces in the order of... well, this:

Total force (fluid) = (-10862.8 -950231 -2.06598e-13)
Total force (solid) = (10831.4 950116 2.07796e-13)

although this seems like a result related to an internal iteration while solving the solid stage... I'm not familiar with the inner workings of the fsiFoam solver, so I don't know how exactly it operates.

Best regards,
Bruno

[Maimouna]

Dear Bruno,

I run

 paraFoam -nativeReader

but wouldn't be able to see any mesh regions.. What is the problem?

And how could you know fluid and solid total forces values?

Total force (fluid) = (-10862.8 -950231 -2.06598e-13)
Total force (solid) = (10831.4 950116 2.07796e-13)

Many thanks.

Maimouna

[wyldckat]

Quick answer: The "fluid" folder is the main case folder, since the script "Allrun" is meant to be executed within that folder.
Therefore, after running "Allrun", you should:

1. Check the contents of the file "log.fsiFoam" inside that folder, which is the one that has the forces I pointed out.
2. Run paraFoam from this folder.

[Maimouna]

Dear Bruno,

I already checked that .. thank you. I'm still trying to find the solution. I did some changes again and I'll let you know by then if could get the answer.

Another question please: what is ''refHistoryPoint'' in fluid/system/controlDict state for? What does it mean?

Kind regards

[wyldckat]

Originally Posted by Maimouna

Another question please: what is ''refHistoryPoint'' in fluid/system/controlDict state for? What does it mean?

You're referring to this:

   pointHistory
   {
       type pointHistory;
       functionObjectLibs
       (
         "libpointHistory.so"
       );

       region solid;

       refHistoryPoint (0.6 0.2 0.025334);
   }

It seems to be a reporting feature. This point "refHistoryPoint" is monitored regarding how much it's distorted during the simulation. The result is placed in the file "history/0/point.dat".

[Maimouna]

Dear Bruno and others,

after lots and lots of trying and changing, I couldn't find the solution of my case problem. I'm really disappointed. I ended up with the two attached cases for the same boundaries, parameters and conditions given in http://www.sciencedirect.com/science/article/pii/S0045782505005177. As I posted in #1. Now, what I did, lets explain my both trying:

1. myCylinderCase: this case is the same as the original case flappingConsoleSmall in foam/foam-extend-3.1/tutorials/solidMechanics/deprecatedTutorials/icoFsiFoam. I did changes regarding my case given in the same problem. This case didn't work, it gives the waning showing in the attached screenshot. I think it is not very serious warning but the running is sttoped with core damped. How could solve?

2. myCylinderCase-Fsi: this case follows the same tutorial given in fsiFoam solver in foam-extend3.1. This tutorial named HronTurekFsi3 (as explained before). I tried to implement one the same as that original case as posted from #1. This case is running without any blown up as before, but the problem is, it doesn't show any movement in the beam. Why? Any problem in the boundary conditions, I tried to check them with lots of changes but I couldn't notice the problem. Or is it Reynolds number problem?
I tried with 333 Reynolds number as given in the paper, with U = 51.3 m/s, nu = 1.5424e-1 (fluid mu = 1.82e-4 and fluid rho = 1.18e-3) [ all other fluid and solid parametres given in the attached paper p.5767]. Or is that problem because of the ratio of solid and fluid rho (rho solid/ rho fluid). Here, rho solid = 0.1. Moreover, the point.pdf document shows no distortion..that because no rod movement, all values in X, Y, and Z in all times is 0.
And finally, one more question please shall I set internalFiled and inlet to (51.3 0 0) in U file or inlet only?

Check my cases please, have free for any changes. Which of them shall confirm?

Lots of thanks for your help.

Maimouna

[Maimouna]

Sorry, here are all attachments.

Regards

[wyldckat]

Hi Maimouna,

I've taken look into these two cases that you provided. Here's what I can figure out.

The first case "myCylinderCase" crashes because the time step "deltaT" is too huge. If you check the contents of the file "fluid/log.icoFsiFoam", you'll find the following at the start of the last time step:

Courant Number mean: 5.81528e+35 max: 2.23024e+39 velocity magnitude: 1.71347e+41
Time = 0.024

Setting pressure
Total pressure force = (-2.49141e+46 3.72101e+46 9.51795e+29)

The maximum Courant Number (aka CFL) is at 2.23024e+39, when it should be at maximum 0.5 for a stable transient simulation. This is also why all other values for forces are monstrous.

How to avoid this problem? Well, the first way is usually to reduce the time step. At the very first time step in the log it gives you this:

Courant Number mean: 0.980629 max: 4.55615 velocity magnitude: 51.3
Time = 0.003

So, it's already at 4.55615, which means that the time step needs to be dramatically smaller. If we change the time step to be 10x smaller, namely 0.0003, the maximum Courant Number will become ten times smaller as well.
In theory, this solves the first problem. I say in theory, because these cases take a very long time to run and I haven't seen yet if it crashes or not.

Next, still regarding the first case, there is a very important detail that is clear when I see the mesh you have for the first case, as shown in the first attached image "mesh_overview_first_case.png": this does not look like a good mesh for this kind of simulation.

I've been pretty busy the past few months, so apparently I didn't give this enough thought and I was expecting your teacher to guide you through this, but I guess that didn't happen. You're missing a very important step in your approach in how to solve this problem: you need to take a few steps back and first have 2 types of fully working and studied simulations:

1. Flow around a static circular cylinder. At least 3 simulations at different Reynold numbers. This is one of those cases that has a lot of available information about it and validation data for it. You should first gain experience with this case, because you seriously need it before you can solve the problems you're currently dealing with. You can find a lot of information about this by searching with Google for:
   

   openfoam cylinder flow

2. Flow around a static cube (square). This is theoretically similar to the circular cylinder, but the results are a lot different, because there are 4 blunt corners which create a lot more intense vortexes than those in the circular cylinder, if you compare for the same inlet velocities.
   • Furthermore, if you have trouble setting up this case, you should then take another step back, by simulating the two other simpler cases that are related to this: the forward step case and the backward step. These two are really simple and can give you the confidence and experience you need for solving the more complicated cases.

I say you need this, because from what I can see from the mesh on the first case, you seriously need to gain more experience in how mesh affects your results and how to configure transient cases such as the one you're trying to simulate. Keep in mind that OpenFOAM gives you the necessary tools so that you can check how things work, therefore you should always have simple, validated tested cases that you're familiar with, so that you can base your work on those cases that you know that work. In other words: you can freely do "trial and error" experiments for checking how each detail affects your results.


And do keep in mind even if you were lucky enough to be able to configure your current FSI cases to reproduce the results from the paper, this does not mean that the people evaluating your work would accept your results, if you do not have proof that you based your results on previous validation cases that you did for simpler cases, such as the flow around a stationary cylinder.


Furthermore, I suggest that you study again the first 3 tutorials in the OpenFOAM User Guide, since the information about the Courant Number is explained in the very first tutorial!



Now, regarding what should be the initial velocity and where it should be defined: you would be able to answer this yourself, after you've gained experience with the test cases I described above. For example, there are at least 4 ways you could initialize the fields:

1. Everything (both inlet and inside the domain) defined with the target speed.
   • This can result in some crazy pressure-effects around the square shape, for example because at the back of the square the flow speed will have to drop from 50 m/s to something like 1m/s in the recirculation region, which means that some massive pressure differences can occur and could potentially make it hard to simulate the first few seconds, because the flow could be very unstable.
2. Inlet set to the target speed and the interior domain defined as 0.0 m/s.
   • The problem with this one is that a rather large shock-wave is sent from the inlet into the domain. You're sending fluid at roughly 50 m/s (180 km/h) into a region where everything was standing still, so it's going to be almost like an explosion happened. So you're going to have some issues in the first second(s) of simulation, because the flow is rather unstable and very intense (imagine a 1m diameter cylinder being on a beach somewhere and a 50m high tsunami is coming onto the beach...).
3. You can use potentialFoam to initialize the flow field. This assumes perfect flow, so the are no vortexes generated by this calculation. In OpenFOAM and foam-extend you can find the tutorial "basic/potentialFoam/cylinder", which has this demonstration.
   • In OpenFOAM 2.1.x you can find the tutorial "incompressible/simpleFoam/motorBike", which demonstrates how the flow field can be initialized with potentialFoam: https://github.com/OpenFOAM/OpenFOAM...torBike/Allrun
4. Last but not least, you can start everything with 0.0 m/s and use a boundary condition in the inlet that gradually increases the velocity from 0.0 to 51.3 m/s. This will make the flow gradually and smoothly develop into the domain.

Another thing I'm finding strange is that in the case "myCylinderCase-Fsi" you are using in the inlet the boundary condition "transitionalParabolicVelocity". Did you first test this in a simpler test case, to verify if this boundary condition does what you need?
You should methodically test each feature that you want to use. You should not simply throw possibilities into your current main case, because that way you are simply trying to play with luck... in trying to solve 10 or 50 problems/errors all at once, which isn't very scientific, because you can easily have millions of possible permutations for possible solutions... which means that even if you try 100 different things in the same case, there are still "millions minus 100" of possible solutions


Right now I don't what is the solution for the second case. The first case have been running for almost an hour and is still at time 0.41982 s, with the following CFL:

Courant Number mean: 0.100955 max: 0.52274 velocity magnitude: 71.6824

but at least it's running without problems and the solid object is changing position. The maximum Courant number is a bit high, since it's above 0.5, but it isn't too bad.

The second case is running for almost an hour as well and it's at time 0.506 s. It does have some forces applied onto the solid, but it's only 0.002 N, so I doubt this is enough to deform the solid, which is why the point doesn't change... Oh, no, wait, I see now what's the problem. You're trying to monitor the wrong location. In the attached image "mesh_and_point.png" is shown in ParaView the mesh of the case and I use the Source "Sphere" to show the location of the point you have defined in the file "system/controlDict":

functions
(
   pointHistory
   {
       type pointHistory;
       functionObjectLibs
       (
         "libpointHistory.so"
       );

       region solid;

       refHistoryPoint   (0.6 0.2 0.025334);//( 5.5 5.97 0.05 );
   }

   hronTurekReport
   {
       type hronTurekReport;
       functionObjectLibs
       (
         "libhronTurekReport.so"
       );
   }
);

As you can see in the image, the location "(0.6 0.2 0.025334)" is near the lower left corner of the mesh.

I believe that after you've studied better the topics I've written about, you should be able to answer the other questions you've asked

Best regards,
Bruno

PS: If you're willing to read a bit more, here's a wiki page that might give you a few more basis on how to handle OpenFOAM and foam-extend: http://openfoamwiki.net/index.php/Tu...etting_Started

[Maimouna]

Dear Bruno,

many thanks for that well explanation in the last post.

As a good news after some changes in the last case ''myCylinderCase-Fsi'' the beam is moving as shown in the attached screenshot. (I tried to attach animation but I don't know which extension is accepted .avi not accepted). The new case with new changes is attached too to have a look.

My inquiries are
1. lift coefficients as shown in the attached screenshot show very large values, are that make sense for U=51.3 m/s, D = 1 m , nu = 0.513 for Reynolds number 100, the fluid density is stated as 1 and solid density is 1000? I now that sometimes I asked stupid questions, because I need to understand some small tips.

2. Beam is moving, but the file points.pdf shows no distortion for all times? Is that regarding the value refHistoryPoint? Here, it is (5 6 0.05), is it ok? If no, any suggestion please?

Any other important points would help me, welcomed.

If you tried to run the case, running will take some hours, feel free to change time steps and what ever you want.

I'm looking forward to get your help, I think that I'm very close to the correct results.

Kind regards

Maimouna


2.

[wyldckat]

Quick answers:

Originally Posted by Maimouna

1. lift coefficients as shown in the attached screenshot show very large values, are that make sense for U=51.3 m/s, D = 1 m , nu = 0.513 for Reynolds number 100, the fluid density is stated as 1 and solid density is 1000? I now that sometimes I asked stupid questions, because I need to understand some small tips.

Sorry, but I'm confused about your question here. Let me check the contents of the files...

• fluid/constant/transportProperties:
  

  nu              nu [0 2 -1 0 0 0 0]  0.513; //1.5424e-1; //1e-3; // for Reynolds number 333 (0.513 for Re = 100)
  
  rho             rho [1 -3 0 0 0 0 0] 1; //1000; //1.18e-3;

  OK, rho is defined as 1 kg/m³.
• solid/constant/rheologyProperties:
  

  planeStress no;
  
  rheology
  {
      type linearElastic;
      rho rho [1 -3 0 0 0 0 0] 1000; //1; //0.1;
      E E [1 -1 -2 0 0 0 0]   2.5e6; //5.6e6; //Young's modulus
      nu nu [0 0 0 0 0 0 0]  0.35; //0.4; //Poisson's ratio
  }

  rho is 1000 kg/m³

The force values in "forces.dat" are probably in Newton, so 3000N is roughly 300 kgf (3000N / 9.81 m/s²). The attached image "Screenshot from 2015-10-17 16:31:34.jpg" shows that the beam is 4m long. Therefore, 300 kgf makes some sense.

Originally Posted by Maimouna

2. Beam is moving, but the file points.pdf shows no distortion for all times? Is that regarding the value refHistoryPoint? Here, it is (5 6 0.05), is it ok? If no, any suggestion please?

If the mesh dimensions didn't change, then this location is very wrong, as shown in the attached image "Screenshot from 2015-10-17 16:18:12.jpg". The measuring point is inside the empty square... which means that there is nothing to measure.

The other attached image "Screenshot from 2015-10-17 16:31:34.jpg" shows that you can use the "Ruler" source (menu -> Source -> Ruler) for seeing where things are.

[Maimouna]

Dea Bruo,

could you please make more clarification in this point, how?

The force values in "forces.dat" are probably in Newton, so 3000N is roughly 300 kgf (3000N / 9.81 m/s²). The attached image "Screenshot from 2015-10-17 16:31:34.jpg" shows that the beam is 4m long. Therefore, 300 kgf makes some sense.

With lot of thanks.

[wyldckat]

Originally Posted by Maimouna

could you please make more clarification in this point, how?

Uhm... that's a somewhat vague question...

I guess you're wondering how does this make sense? Well, a car is usually 3 to 4 metre long, and weights between 1000 to 2000kg. The car can withstand its own weight because its skeleton has a lot of beams and cross-connections. Now imagine that the longest contorted beam is taken out from the skeleton and stretched to it's full length. That beam alone would probably not be able to handle 300kg at one end if the other end is fixed in position.

My advise, get a mechanical project engineering book, study the relevant chapter and do the math. One that comes to mind is "Shigley's Mechanical Engineering Design".

[Maimouna]

Dear Bruno,

since icoFsiElasticNonLinSolidFoam was replaced by fsiFoam, so is fsiFoam solver is for both linear and non-linear elastic materials?

Regards

Maimouna

[wyldckat]

Originally Posted by Maimouna

since icoFsiElasticNonLinSolidFoam was replaced by fsiFoam, so is fsiFoam solver is for both linear and non-linear elastic materials?

Quick answer: I can only guess that it is able to simulate both types of materials. The closest I've found on this topic is what Philip wrote here: http://www.cfd-online.com/Forums/ope...tml#post547754 - post #14