Ramping Courant Number

screech1987 · April 22, 2011, 13:49

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

f-w · April 22, 2011, 14:59

See attached image ...

screech1987 · April 23, 2011, 09:06

Cheers! I did wonder about that.

rwryne · April 25, 2011, 12:06

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.

abdul099 · April 28, 2011, 18:38

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.

rwryne · April 29, 2011, 10:54

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?

abdul099 · May 1, 2011, 07:22

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?

rwryne · May 2, 2011, 09: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)

April 22, 2011, 13:49	Ramping Courant Number	#1
screech1987 New Member Martin Join Date: Nov 2010 Posts: 23 Rep Power: 16	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

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[mesh manipulation] Mesh Refinement	Luiz Eduardo Bittencourt Sampaio (Sampaio)	OpenFOAM Meshing & Mesh Conversion	42	January 8, 2017 13:55
DecomposePar unequal number of shared faces	maka	OpenFOAM Pre-Processing	6	August 12, 2010 10:01
Unaligned accesses on IA64	andre	OpenFOAM	5	June 23, 2008 11:37
Could anybody help me see this error and give help	liugx212	OpenFOAM Running, Solving & CFD	3	January 4, 2006 19:07
[Commercial meshers] Trimmed cell and embedded refinement mesh conversion issues	michele	OpenFOAM Meshing & Mesh Conversion	2	July 15, 2005 05:15

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

April 28, 2011, 18:38		#5
abdul099 Senior Member Join Date: Oct 2009 Location: Germany Posts: 636 Rep Power: 22	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.

May 1, 2011, 07:22		#7
abdul099 Senior Member Join Date: Oct 2009 Location: Germany Posts: 636 Rep Power: 22	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?