Ramping Courant Number

 Register Blogs Members List Search Today's Posts Mark Forums Read

 April 22, 2011, 12:49 Ramping Courant Number #1 New Member   Martin Join Date: Nov 2010 Posts: 23 Rep Power: 15 A quick query about the 'ramping' of values in StarCCM+. As I am running a highly hypersonic case the starting Courant number had to be small, but I have put a rampping function in to gradually increase the value over a number of iterations. The set up in Star is straight forwards with a start and end iteration, and a initial Courant number defined. But what I could not gather from the UG was a what value does the Courant number reach or plateau out at, or is this just dependednt on the solution and applies the maximum value it can? Cheers, Martin

April 22, 2011, 13:59
#2
Senior Member

Join Date: Apr 2009
Posts: 154
Rep Power: 16
See attached image ...
Attached Images
 final_CFL.jpg (77.6 KB, 178 views)

 April 23, 2011, 08:06 #3 New Member   Martin Join Date: Nov 2010 Posts: 23 Rep Power: 15 Cheers! I did wonder about that.

April 25, 2011, 11:06
#4
Senior Member

Ryne Whitehill
Join Date: Aug 2009
Posts: 312
Rep Power: 18
Quote:
 Originally Posted by screech1987 Cheers! I did wonder about that.
It is a bit cryptic, the way they have the final number seperated from the initial number.

 April 28, 2011, 17:38 #5 Senior Member   Join Date: Oct 2009 Location: Germany Posts: 636 Rep Power: 21 Not necessarily cryptic. The ramp just has its own definition. Imagine, you want to change the CFL number much after the end of the ramp. Why should you search for the CFL number by looking in the ramp? There's no reason and some guy might complain about a cryptic way they have hidden the CFL number in the ramp node. So to keep it seperate from the ramp (and its initial value) is just as much cryptic as it might be in another case when you have put it together.

April 29, 2011, 09:54
#6
Senior Member

Ryne Whitehill
Join Date: Aug 2009
Posts: 312
Rep Power: 18
Quote:
 Originally Posted by abdul099 Not necessarily cryptic. The ramp just has its own definition. Imagine, you want to change the CFL number much after the end of the ramp. Why should you search for the CFL number by looking in the ramp? There's no reason and some guy might complain about a cryptic way they have hidden the CFL number in the ramp node. So to keep it seperate from the ramp (and its initial value) is just as much cryptic as it might be in another case when you have put it together.
I understand why they have it how they do, but still think it is a bit cryptic not to have the start value and end value next to eachother. Maybe the placement of the variable should be moved when ramp is turned on?

 May 1, 2011, 06:22 #7 Senior Member   Join Date: Oct 2009 Location: Germany Posts: 636 Rep Power: 21 That would be an option, but that would affect the Java API as well, so most likely that will not be changed. An to be honest, it's no big issue as long as you know where you can find it, isn't it?

May 2, 2011, 08:18
#8
Senior Member

Ryne Whitehill
Join Date: Aug 2009
Posts: 312
Rep Power: 18
Quote:
 Originally Posted by abdul099 That would be an option, but that would affect the Java API as well, so most likely that will not be changed. An to be honest, it's no big issue as long as you know where you can find it, isn't it?

It is not an issue to me, but I think it does confuse people new to the software (which is why we have a thread here)