[philippose]

Hi there,
A Good day to you :-)!

The force based solver was dormant for some time due to other more urgent matters, and because the only software I have access to for meshing is "netgen". I have realised, that tetrahedral meshes are not so good when it comes to mesh motion (and topological changes are more or less not even possible) :-)!

Nevertheless, just yesterday I pulled out the code again, to implement the ability to choose the solution cycle time (delta T) for the mechanical part of the solver.

Currently, in the dictionary, I can put in either a fixed deltaT, or, if I give a "0.0" for the deltaT in the dictionary, the solver calculates the deltaT to be used, as 1/5 of the time period defined by the natural frequency of the system (if a spring exists), etc..etc...

I had coded in the wall shear stresses bit long time ago, though, I havent had the opportunity to test that part of it.... I think it should work fine.

As for the ability to save the velocity and position, to allow simulations to be restarted... thats something I havent yet dug my teeth into :-)! I think thats the next thing on my priority list, after which I should see how I can convert the system so that it works as a parallel solver too.

Anyway, here is the latest version.... it would be really helpful if you could give me feedback regarding the wall shear forces part of it, and also, what you think could be improved on the deltaT bit.

turbForceFoam.tar.gz

Have a nice day!

Philippose

[msrinath80]

Thanks for the prompt response. Are you using Prof. Jasak's dev sources or the native OF 1.3 ones? I'm having problems linking in the final stages of the build:

/usr/bin/ld: cannot find -ltetDecompositionMotionSolver
collect2: ld returned 1 exit status
make: *** [/home/madhavan/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxAMD64Gcc4DPOpt/turbF orceFoam] Error 1

[msrinath80]

OK. Looks like you are using the dev sources. There seems to be a difference in naming between OF 1.3 and the dev sources. In OF 1.3 the library is called tetDecompositionMotionSolvers whereas in the dev sources it is called tetDecompositionMotionSolver.

[msrinath80]

Hi Philippose,

I finally got the build to work with OF 1.3. Not sure how correct it is to change ltetDecompositionMotionSolvers in Make/options to -ltetDecompositionMotionSolver.

Anyways, can I have a sample case with all the dictionaries in it so I can give it a raw test first?

Thanks!

[hjasak]

Just change it - the name was inconsistent with the other libraries and I have changed it.

Hrv

[philippose]

Haaalllt :-)

My suggestion is that you dont use the stock OpenFOAM 1.3 release, because in the original release, as Hrv has repeatedly pointed and as I have experienced, the moving mesh bits are broken.

If you try running moving mesh cases in the original OpenFOAM 1.3, you will have problems with the results.

Use the development version available from Frank Bos' site (unless Hrv has another more recent one.... in which case I would like to have a copy of that too :-)!)

Enjoy!

Philippose

[hjasak]

We are still working out the details of public version access, which should come on-line soon (to be discussed/finalised at the Workshop in Zagreb this June). In the meantime, I have uploaded a snapshot on the FSB web site.

http://powerlab.fsb.hr/ped/kturbo/OpenFOAM/release/

I haven't been this happy with OF for a while, so some binary packs will be added in the next day or two.

Enjoy,

Hrv

[msrinath80]

Thanks Hrv.

Philippose, can I have a sample case? Thanks!

[msrinath80]

Boy Hrv you are fast! Thanks for the pre-compiled binaries

[lr103476]

Nice! I like new versions (of things) a lot :-) Hrv, How did you compile, with cellDecomposition or faceDecomposition?
Could you briefly explain the major changes to the fsi solver?

Thanks,
Frank

[philippose]

Hey Hrv,

You should see my face now... the grin really cant get wider :-)! Thanks a lot for allowing a sneak peek into the new version, and since you are happy with it, I assume us users should be jumping around :-)!?

Shall download and test it out at home today....!

And Srinath, as for test cases... I shall put together some as soon as possible... hopefully later today once I get back.

Its a lovely day, and things seem to be getting better :-)!

Have a nice day!

Philippose

[msrinath80]

Hi Philippose,

Just a quick reminder. Apologies for bothering you so much

[philippose]

Hi :-)

A Good day to you!

I apologise for the delay.... sudden and extreme pressure at work over the last two days have prevented me from doing anything on the OpenFOAM front.

Well... must say... CFD is only a small part of my work (but the biggest part of my free time :-)!), and I cant afford to put it high on the priority list when other things pop up unexpectedly. Was across the border in Switzerland the whole day today getting a prototype electronically controlled valve block up and running at a customer's place for the first field tests.

Shall try my best to come up with an example case which runs the full simulation length without aborting due to mesh errors (something I havent succeeded in yet :-)!)... maybe I should use blockMesh to create a simple case rather than netgen.

The problem is, that most of the time, when the mesh changes its direction of motion (i.e., velocity goes from for example +ve... to zero and then -ve), the epsilon values and the courant number blows up.... havent found the reason for that yet (maybe Hrv knows why ??).

Shall post as soon as I have something....

Sorry again, and enjoy the weekend :-)!

Philippose

[msrinath80]

Oh don't worry about the case not working. That's my job. I have some time on my hands.I can fool around a bit. Just tar the case with the dictionaries and post it. I'll muck around for some time

[philippose]

Hello,

As suggested by Bernhard Gschaider earlier on in this post, I am trying to use an IOdictionary as a container to store the calculated velocity and position data from the force based solver.

The IOdictionary needs to be written to disk each time the other fields are written, so I created the IOdictionary the following way:

IOdictionary forceSolverData
(
IOobject
(
"forceSolverData",
runTime.timeName(),
mesh,
IOobject::READ_IF_PRESENT,
IOobject::AUTO_WRITE
)
);

Now, once I create the dictionary, I need to add entries to it (when the dictionary does not already exist on disk). For this, just after declaring the IOdictionary as shown above, I use:

if(!(forceSolverData.found("previousCalcTime")))
{
forceSolverData.add("previousCalcTime",previousCal cTime);
forceSolverData.add("calcVelocity",calcVelocity);
forceSolverData.add("calcDistance",calcDistance);
}

The above piece of code is only called once during initialisation of the simulation before entering the runTime loop.

When I compile and run the solver, it automatically writes an IOdictionary called "forceSolverData" in each time directory, but the only problem is, that even though the variables "previousCalcTime", "calcVelocity" and "calcDistance" are not zero, the data written to disk is always zero.

Do I need to somehow update the dictionary entries each time? Doesnt it take the latest value of each variable during the write operation? Or do I need to create a pointer to the variables when I "add" an entry rather than the variable itself?

In the file "TimeIO.C", I found that the entries for the "timeDict" are "added" each time before writing to disk... do I need to put in the same check (runTime.outputTime()) in my code, and "add" the entries?

Have a nice day!

Philippose

[philippose]

Hello again,

Here I am again :-)! Back with yet another new version. The system is now capable of being restarted, because it saves the cumulative variables (velocity and position) each time when the system writes to disk.

turbForceFoam.tar.gz

So... as a summary... here are the main features as of now:

0. ***Does not work with the original OpenFOAM version 1.3 (use any development version more recent than October 2006)***
1. Rigid body dynamics in one dimension (second order spring mass system equation)
2. Accounts for pressure forces (As of now assumes pressures lower than zero as zero... will add a switch in the dictionary to enable or disable that if its required)
3. Accounts for wall flow shear forces (as of now untested by me)
4. Can handle a virtual spring with a given spring constant and pretension
5. Virtual damping (proportional to velocity) specified via a damping constant
6. Saves the important state variables during each simlation write (enables the simulation to be halted and restarted)
7. The simulation period of the mechanical system can be specified via the dictionary (usually the mechanical system is much slower than changes in the fluid system)
8. The maximum acceleration of the moving part can be limited via the dictionary
9. Handles acceleration due to gravity if specified
10. the direction vector for gravity and for the motion can be specified by the user
11. Currently supports only one moving body, though the moving body can consist of any number of patches (specified via the dictionary)
12. The top level fluid solver is based on turbFoam, and hence uses the PISO algorithm


I have put together an example case which consists of a simple conical body moving in to reduce the effective flow area of an orifice, settling at a position based on the pressure built up, and the spring used (Basically a simple pressure relief valve kind of thing).

The only problem is, that the example is 1.9MB (tar.gz), which is too big to post here... Let me know if someone wants it, and I can send it via email, or is there some other way I can make it available? (The Wiki? or via Hrv's FTP ?)

Thats it for now :-)!

Have a nice day!

Philippose

[msrinath80]

Wow Philippose! That was quite fast. Thanks very much for the update. Can you email me the sample case (msrinath80@yahoo.com). I can put it up on my public ftp space in my university for the others.

[philippose]

Hi,
Mail successfully sent :-)! So now it all depends on how fast the servers on each side are!

Philippose

[msrinath80]

And done!

Many thanks!!

http://www.ualberta.ca/~madhavan/for...nceTest.tar.gz

[philippose]

Hello :-)!

The test case failed with the settings I used initially, because I assumed too high an area for the surface on which the high pressure acts, due to which I gave too high a spring pre-tension.... the system moves almost till contact, causing the mesh to go crazy :-)!

I have currently re-run the simulation with a smaller pre-tension value for the sping (0.0092)... this should work out fine (though I can say for sure only tomorrow morning!)

Other than that... the solver itself seems to be working fine... the numbers, and the change in pressure with time and with more closing of the orifice all seem to be reasonable. The residuals for the fluid solver and convergence all seem to be quite good (till the mesh failure ofcourse).

One other thing you need to do is to open up the limit on the acceleration.... 600 m/s^2 is too small a number... something like 1000 m/s^2 should speed things up.

Enjoy!

Philippose