Hello,

How to calculate CFL number / Courant Number in star-CD?

Xobile

Take a look at the post in the archive by Giovanni on Mon, 19 May 2003, 1:19 a.m.

Hello,

I am trying to find out the CFL number and as suggested by 4xF , I went into archives and got this command to get the CFL number and I tried using it but I have got errors:

The command is::

In PROSTAR

RESDAT,10

write the problem file & run the case

trlo,star.rpo

stor iter 10

getc vis

cset news flui

popt cont $cplo

But when i do the above , i run the case after typing RESDAT,10 but I cannot open the file as it says

Error in opening star.rpo

what to do? and what is the reason??

Xobile

Do you have an .rpo file in your working directory?

It should should be

resd,,"freq to write rpo file"

or you can do this in monitor numeric behaviour | write freq for residuals

then after you run the transient case

trlo,star.rpo !load the rpo file as per a pstt file

stor iter first !or what ever iteration you want to see

if you are using 320 or higher you will see the courant number listed in the scalar data panel or else you can execute the command

getc cnum

note that if you use v315A you need to do a "getc vis"

Steve

I am doing the same thing as suggested by 4xF and steve but there is no star.rpo file created. So I am not able to load any star.rpo file.

can anyone tell me what is the reason? Any problems with settings of my star-CD??

Xobile

Please take a look at what steve wrote. The answer to your problem is there since you *need* to ouput the .rpo file.

C'mon guys! Why dont we try just calculating the CFL number as per it's definition using a normal .pst or .pstt file using the "operate" command?

Or was this a silly suggestion?

Do you know by chance how to define a CFl number on an unstructured mesh which does not have a priory any defined grid directions? Because I don't... So, why would n't we get the CFL number as given back by STAR and use it instead?

Well... lets assume that the CFL-numbers are to be used for engineering purposes, and that we do know the shape of our cells (i.e, tetrahedrals, pyramids or which ever..). Lets then assume that we know how to calculate the volume of the cell, and how to derive a typical cell side length from the volume. Eureka!!! I see a solution to the problem, do you?

How do you think the CFL-calculation is implemented for an unstructured mesh in the code? They sure ain't waving the magick stick, even if they do have access to slightly more info in the solver than what is given in Prostar.

And what if you would not know the shape of your cell? Say, you just need for the solver to know which neighbors you share and what is the face you have in common for calculating fluxes? This is how an unstructured solvers works and you do not need explicitely to know how the cell is shaped.

And now comes the magic stick (which is cell shape independent):

CFL = (Mass_flux)*dt/(rho*cell_volume)

Have fun...