LRR and cyclic conditions

hjasak · July 30, 2007, 12:21

For starters, this is not easy - RSTM models are notoriously tricky to run with cyclics. Your problem will be worse if the geometry is only one cells thick, due to some issues of boosting the off-digaonal rather than matrix diagonal in cyclics. In any case, you will need to play around with the numerics and under-relaxation until you get it to work; once it starts up properly, all will be well.

I remember a bug in cyclics for tensors a long long time ago, but that has been eliminated in about 1999 - hopefully it dodn't come back...

Hrv

make · July 30, 2007, 16:37

Well, my geometry is in fact only one cell thick.
I also had a lot of trouble using CFX with that grid but finally it converged applying local timescaling, which dampens a lot. Of course I don't have this choice in OpenFOAM. Nevertheless the quality of the grid is high considering a 6° grid.
So far I played around with under-relaxation and TVD schemes (Upwind was not beneficial), sadly without success.
Don't you have a hint for example which solver and scheme is most stable for the Reynolds stresses or which relation and range of epsilon and R relaxation is reasonable. I would be very happy about any help on that.

make · August 1, 2007, 12:41

I found the problem.
Neither the geometry nor the numerical setup caused my problems, its the system.

I'm working on a beowulf cluster consisting of SuSE 9.3 systems based on a 2.6.11.4 kernel.
My home system is SuSE 10.2 based on a 2.6.18.2 kernel. The OpenFOAM installation is identical using gcc-4.1.2. On my home system LRR converges without problems, but on our cluster even with the start solution taken from my home system the simulations crashes after the first iteration.

jensi_t · August 5, 2014, 10:47

Hi,

i know that this thread is some years old but for me it seems to be up to date. I can run a dbnsTurbFoam-case with cyclic boundaries and LRR turbulence modeling on my local machine (Suse 13.1) both in serial and in parallel mode, but when I shift the same case to a Centos 6.3 cluster there is a huge increase in Rzz on one cyclic patch and the computation stops after a few timesteps.
Did someone solve that problem?

Thanks in advance!

Jens

jensi_t · August 13, 2014, 12:19

Hi,

I solved the problem by using cyclicGgi boundaries and making them globalFaceZones. Calculation takes longer but at least it works.
I think in my case the problem occurs when the cyclics are split by decomposePar.
Anyway i'm still interested in a more elegant solution.

Jens

July 30, 2007, 12:21	For starters, this is not easy	#1
hjasak Senior Member Hrvoje Jasak Join Date: Mar 2009 Location: London, England Posts: 1,907 Rep Power: 33	For starters, this is not easy - RSTM models are notoriously tricky to run with cyclics. Your problem will be worse if the geometry is only one cells thick, due to some issues of boosting the off-digaonal rather than matrix diagonal in cyclics. In any case, you will need to play around with the numerics and under-relaxation until you get it to work; once it starts up properly, all will be well. I remember a bug in cyclics for tensors a long long time ago, but that has been eliminated in about 1999 - hopefully it dodn't come back... Hrv __________________ Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk

July 30, 2007, 16:37	Well, my geometry is in fact o	#2
make Member Matthias Kern Join Date: Mar 2009 Location: Karlsruhe, Germany Posts: 36 Rep Power: 17	Well, my geometry is in fact only one cell thick. I also had a lot of trouble using CFX with that grid but finally it converged applying local timescaling, which dampens a lot. Of course I don't have this choice in OpenFOAM. Nevertheless the quality of the grid is high considering a 6° grid. So far I played around with under-relaxation and TVD schemes (Upwind was not beneficial), sadly without success. Don't you have a hint for example which solver and scheme is most stable for the Reynolds stresses or which relation and range of epsilon and R relaxation is reasonable. I would be very happy about any help on that.

August 1, 2007, 12:41	I found the problem. Neither	#3
make Member Matthias Kern Join Date: Mar 2009 Location: Karlsruhe, Germany Posts: 36 Rep Power: 17	I found the problem. Neither the geometry nor the numerical setup caused my problems, its the system. I'm working on a beowulf cluster consisting of SuSE 9.3 systems based on a 2.6.11.4 kernel. My home system is SuSE 10.2 based on a 2.6.18.2 kernel. The OpenFOAM installation is identical using gcc-4.1.2. On my home system LRR converges without problems, but on our cluster even with the start solution taken from my home system the simulations crashes after the first iteration.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Cyclic Boundary conditions	johndeas	OpenFOAM Running, Solving & CFD	1	January 4, 2008 21:34
Cyclic boundary conditions	hadi	OpenFOAM Running, Solving & CFD	0	June 29, 2007 11:46
periodic and cyclic boundary conditions	Hadi	Main CFD Forum	2	June 29, 2007 08:19
cyclic conditions	Laurent FERRY	Siemens	0	January 6, 2006 16:11
cyclic boundary conditions..	Zerrin	Siemens	0	June 11, 2005 14:49

August 5, 2014, 10:47		#4
jensi_t New Member Jens Join Date: Apr 2014 Posts: 28 Rep Power: 12	Hi, i know that this thread is some years old but for me it seems to be up to date. I can run a dbnsTurbFoam-case with cyclic boundaries and LRR turbulence modeling on my local machine (Suse 13.1) both in serial and in parallel mode, but when I shift the same case to a Centos 6.3 cluster there is a huge increase in Rzz on one cyclic patch and the computation stops after a few timesteps. Did someone solve that problem? Thanks in advance! Jens

August 13, 2014, 12:19		#5
jensi_t New Member Jens Join Date: Apr 2014 Posts: 28 Rep Power: 12	Hi, I solved the problem by using cyclicGgi boundaries and making them globalFaceZones. Calculation takes longer but at least it works. I think in my case the problem occurs when the cyclics are split by decomposePar. Anyway i'm still interested in a more elegant solution. Jens