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: 7 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: 129
Rep Power: 9
See attached image ...
Attached Images
 final_CFL.jpg (77.6 KB, 109 views)

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

April 25, 2011, 11:06
#4
Super Moderator

Ryne Whitehill
Join Date: Aug 2009
Posts: 313
Rep Power: 11
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: 637 Rep Power: 13 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
Super Moderator

Ryne Whitehill
Join Date: Aug 2009
Posts: 313
Rep Power: 11
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: 637 Rep Power: 13 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
Super Moderator

Ryne Whitehill
Join Date: Aug 2009
Posts: 313
Rep Power: 11
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)

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Luiz Eduardo Bittencourt Sampaio (Sampaio) OpenFOAM Mesh Utilities 41 January 17, 2013 03:43 maka OpenFOAM Pre-Processing 6 August 12, 2010 09:01 andre OpenFOAM 5 June 23, 2008 10:37 liugx212 OpenFOAM Running, Solving & CFD 3 January 4, 2006 19:07 michele OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 2 July 15, 2005 04:15

All times are GMT -4. The time now is 23:04.