Ideas required from programmers

For questions or suggestions related to the source code.

Re: Ideas required from programmers

Postby rotaxmatt on Sat, 17th Jan 2009, 14:25

Michelle,

I think the oscillation is unavoidable. The way to stop it is to set a tolerance such that when the algorithm solves to your tolerance criteria it stops and distributes the error in a manner to equalise the pressure. I am unfamiliar with whether that is possible in the programming language that you are using.

Regarding the constant:

The equation for flow though a restricting device such as a control valve takes the form:

C = Q * sqrt (P1-P2)/G))

Q = flow
C = constant which defines the flow characteristics of the valve at constant opening. ie. it is different if the valve is full open or half open etc.
G = specific gravity of the fluid
P1 = upstream pressure
P2 = downstream pressure.

In our case the fluid is air and I have assumed constant density which is not true as the pressure is constantly changing. We can go into more complexity in the algorithm if needed as strictly we should be using the equation for compressible flow. This party explains for you why my constant is not unitless.

C = Q * sqrt(2*G*T/(P1-P2)*(P1+P2))

T = temperature

This only holds for ranges of P2 up to 50% of P1 - but i depends on the accuracy we need.

Changing the "constant" with the car length is entirely acceptable (it is not a true constant) as the equation describes a specific system with defined characteristics. A different car is a different system with a different characteristic. For simple piping systems of known diameter, roughness and length and knowing the number of fittings etc we can effectively derive the constant from known tables of "fricton factors". For the control valve equation we are using here, the manufacturers probably determine the "constant" for each valve by direct measurement - maybe nowadays there are complex fluid dynamic models that can predict this?

As stated before though this constant is highly unlikely to be proportional to car length - a simple wide open valve in a line would be equivalent to many time its actual length of normal straight pipe. Each bend would contribute many factors of length. So I think the effect of length of the car within the normal range of rail vehicles can be neglected for your purposes. Would you like more information in this subject so that you feel more comfortable with this situation?
rotaxmatt
 
Posts: 5
Joined: Fri, 16th Jan 2009, 22:42

Re: Ideas required from programmers

Postby michelle on Sat, 17th Jan 2009, 14:47

rotaxmatt wrote:Would you like more information in this subject so that you feel more comfortable with this situation?
Not really. The current situation is already beyond what I understand. If you say that the length of the train is irrelevant compared to the influence all of the pipe bends, hoses, etc., have, then I believe you to keep it simple for me. The only thing I need to prevent is oscillation and negative pressures. Once that is achieved, I can run a simulation and test whether the algorithm is usable. Without that, currently, and with the low flow rate that I have set for the demo program, you can see that with 20 cars, it already takes ages for the pressure to distribute properly, which is very similar to the algorithms I used previously and was the main reason why I removed them from openBVE.
User avatar
michelle
Site Admin
 
Posts: 1147
Joined: Mon, 14th Apr 2008, 20:36

Re: Ideas required from programmers

Postby rotaxmatt on Sun, 18th Jan 2009, 12:41

I have sent you a further enhancement.....

have expanded my spreadsheet to 8 cars and I discovered the convergence problems were worse than expected and didn't really show themselves with 3 cars. Using the formula to correct the overflow errors for negative numbers seems to introduce bad oscillations. The best way I could think of correcting this was to introduce if statements which basically halt the convergence if the pressure differential is 0 or lower. A you can see this now works very well.

The issue of time to convergence in my sheet is solved simply be increasing the "constant" to a desired value.

Hope this helps,

Matt

ps the little program you sent out does not seem to work robustly. For example if I change the flowrate it does not seem to execute anymore.
rotaxmatt
 
Posts: 5
Joined: Fri, 16th Jan 2009, 22:42

Re: Ideas required from programmers

Postby rotaxmatt on Sun, 18th Jan 2009, 14:56

I think that I am getting close now - the latest version is now capable of taking both increases and decreases of pressure given any state of the pressures in the cars at the time of the pressure change. I have added a convergence tolerance of 0.5 units or pressure to the algorithm which helps prevent any oscillations.

However, where the algorithm breaks down is if you pick a very high value of the flow constant. If the first iteration gives a pressure change between cars of greater than about 10%, the problem will not satisfactorily solve. This excludes the initial pressure change caused by the brake application in the first place. Given my values, this seems to solve very well in times which would seem to be reasonable.

The critical thing is to make sure that the execution cycle of the algorithm is frequent enough that the maximum iteration step in pressures remains a smaller enough fraction of the previous pressure.

Latest version sent by email.

Matt
rotaxmatt
 
Posts: 5
Joined: Fri, 16th Jan 2009, 22:42

Previous

Return to Source code

Who is online

Users browsing this forum: No registered users and 0 guests