Factorio Forums

Dominik wrote: Sun Sep 16, 2018 7:18 pm

TheYeast wrote: Sat Sep 15, 2018 8:47 pm Physicist here. I happened to bring up the wonky fluid behaviour about a year ago, but it didn’t seem to be a high priority at the time. Back then I came up with some alternative algorithms and ran some simulations in an Android app I hacked together for this purpose (can send APK+source if interested).

Based on what I came up with, the proposed model seems needlessly complicated to me. So I think my findings are worth sharing.

In my simulation I used the Euler equations (assumes zero viscosity) because they are computationally cheap and good enough for our purpose.
...

Hi Yeast,
thanks you for your proposal, so far it seems to be the most reasonable, although I am still unsure about the electricity model which also is interesting.
I admit that my knowledge of physics is rather limited, I had to rely on my common sense. About the “speed kinda models the pressure”, I suppose I could have put more thought into it when writing it. When I think about it, pressure describes it best, it's just that it developed from speed originally and is still called that and I never took the time to rethink what it is.
The model actually is not that dissimilar. The pipe segment has volume (same to level), and the pressure, and connections store the speed - which is just the last step flow. The speed only plays some role in the update and does not control it fully.
From what you propose I really like the idea to push towards only using the last state. I will have to think about it, might steal it. Right now I am thinking about allowing going over the pipe volume limit which would allow this and simplify things a lot.
Your equations are a simplified version of what I currently have. Unfortunately I don't think it would work very well in this form.
The main issue I see is a very low reaction speed. For example - have a straight pipe from source to drain, source is pumping, drain is closed, pipe is full. The drain opens. What I think your model does is that in first tick, only the last segments moves 1/4 of its fluid into the drain (assuming dt=1, which is about what we have) and all the rest stays in place. In next step, one more segments moves a bit, 1/16. Etc. You need "length of pipe" iterations for the wave to reach the source and quite many more to get speed. And then when you get the momentum and you close the pipe, how does the flow stop?
Even so, your ideas are inspiring, I think I will use them, if you don't mind
Thank you, D.

Dominik wrote: Sun Sep 16, 2018 7:18 pm Hi Yeast,
thanks you for your proposal, so far it seems to be the most reasonable, although I am still unsure about the electricity model which also is interesting.
I admit that my knowledge of physics is rather limited, I had to rely on my common sense. About the “speed kinda models the pressure”, I suppose I could have put more thought into it when writing it. When I think about it, pressure describes it best, it's just that it developed from speed originally and is still called that and I never took the time to rethink what it is.
The model actually is not that dissimilar. The pipe segment has volume (same to level), and the pressure, and connections store the speed - which is just the last step flow. The speed only plays some role in the update and does not control it fully.
From what you propose I really like the idea to push towards only using the last state. I will have to think about it, might steal it. Right now I am thinking about allowing going over the pipe volume limit which would allow this and simplify things a lot.
Your equations are a simplified version of what I currently have. Unfortunately I don't think it would work very well in this form.
The main issue I see is a very low reaction speed. For example - have a straight pipe from source to drain, source is pumping, drain is closed, pipe is full. The drain opens. What I think your model does is that in first tick, only the last segments moves 1/4 of its fluid into the drain (assuming dt=1, which is about what we have) and all the rest stays in place. In next step, one more segments moves a bit, 1/16. Etc. You need "length of pipe" iterations for the wave to reach the source and quite many more to get speed. And then when you get the momentum and you close the pipe, how does the flow stop?
Even so, your ideas are inspiring, I think I will use them, if you don't mind
Thank you, D.

u(x,t) = F(x-c*t) + G(x+c*t).

connection.flow += (connection.pipe0.level - connection.pipe1.level) * c^2;

            acceleration   momentum preservation
            
Water:      0.01	   0.999
Steam:      0.2            0.99999
Oil:        0.014          0.9

Factorio:   0.4            0.59

pleegwat wrote: Sun Sep 16, 2018 9:12 pm That's a real thing; If I remember correctly it's related to the speed of sound in the liquid. Looking at the nearest neighbours on the previous tick gives you a speed of 60 tiles per second. Google gives me real speeds of 1000-1500 m/s for common fluids however.

pleegwat wrote: Sun Sep 16, 2018 9:12 pm I'm sure a physicist will be along shortly to tell me how wrong I am.

NexGenration wrote: Sun Sep 16, 2018 9:19 pm So will these changes fix the fact that you practically need a pump literally every 3 pipes just to get enough fluid throughput to feed large fully beaconed setups? I'm currently designing a mega base sized oil processing factory and dealing with putting enough pumps in is just a nightmare. There's no way to avoid the massive amounts of pipe spaghetti.

TheYeast wrote: Mon Sep 17, 2018 12:53 am

Dominik wrote: Sun Sep 16, 2018 7:18 pm Hi Yeast,
thanks you for your proposal, so far it seems to be the most reasonable, although I am still unsure about the electricity model which also is interesting.
I admit that my knowledge of physics is rather limited, I had to rely on my common sense. About the “speed kinda models the pressure”, I suppose I could have put more thought into it when writing it. When I think about it, pressure describes it best, it's just that it developed from speed originally and is still called that and I never took the time to rethink what it is.
The model actually is not that dissimilar. The pipe segment has volume (same to level), and the pressure, and connections store the speed - which is just the last step flow. The speed only plays some role in the update and does not control it fully.
From what you propose I really like the idea to push towards only using the last state. I will have to think about it, might steal it. Right now I am thinking about allowing going over the pipe volume limit which would allow this and simplify things a lot.
Your equations are a simplified version of what I currently have. Unfortunately I don't think it would work very well in this form.
The main issue I see is a very low reaction speed. For example - have a straight pipe from source to drain, source is pumping, drain is closed, pipe is full. The drain opens. What I think your model does is that in first tick, only the last segments moves 1/4 of its fluid into the drain (assuming dt=1, which is about what we have) and all the rest stays in place. In next step, one more segments moves a bit, 1/16. Etc. You need "length of pipe" iterations for the wave to reach the source and quite many more to get speed. And then when you get the momentum and you close the pipe, how does the flow stop?
Even so, your ideas are inspiring, I think I will use them, if you don't mind
Thank you, D.

Thank you for your reply Dominik.

First of all, it would not be stealing. As I said, i wrote my simulation for the purpose of improving Factorio, and I even gave a short demonstration at your office when I visited Prague last year, but back then fluid realism wasn't a top priority Anyway I would be disappointed if you didn't consider using it.

Now about the reaction speed issue. I'm absolutely sure that there is a delay in reaction, and I'm equally sure that this is not a problem. In the situation you describe it indeed takes some time before the source 'becomes aware' that something is draining the pipe. In fact, this awareness will travel even slower than 60 tiles per second!

The general solution for the one-dimensional wave equation is

Code: Select all

u(x,t) = F(x-c*t) + G(x+c*t).

Here u(x,t) is the amount of fluid at time t and position x. F and G can be any two continuous functions. They represent two waves of arbitrary shapes travelling to the right (F) and travelling to the left (G). Their shape is dependant on the circumstances (sources/drains) but because of their arguments ( x+c*t and x-c*t ) they travel exactly at speed c and -c. And c simply depends on the flow update step:

Code: Select all

connection.flow += (connection.pipe0.level - connection.pipe1.level) * c^2;

(This can easily be derived from the wave equation)

As I discussed in response to BlueTemplar, I was using more realistic physical constants than Factorio is:

Code: Select all

            acceleration   momentum preservation
            
Water:      0.01	   0.999
Steam:      0.2            0.99999
Oil:        0.014          0.9

Factorio:   0.4            0.59

With my water acceleration, c^2 = 0.01, giving c = 0.1 but since we update 60 times per second, we get an effective speed of 6. So waves travel at 6 tiles/second. With (presumably) Factorio constants, we get c^2 = 0.4, giving c = 0.6325, and a speed of 38 tiles per second. Yes, that's right. Factorio already seems to have a 'reaction speed issue'. In sixty iterations, changes in supply and demand travel 'only' 38 tiles as it is. But no worries, now comes the 'not a problem' part.

(As an aside: considering a tile is roughly the size of a Factorio engineer, 6 tiles per second is pretty decent for a wave in a liquid)

Please be aware that this fixed speed of waves has nothing to do with throughput. The flow speed and thus throughput can be huge: the speed of the wave just models how long it takes for changes in flow speed to propagate through the system.
To be more precise: the solution to the wave equation, u(x,t) = F(x-c*t) + G(x+c*t), only tells us how much fluid is at a certain time and place, not in which direction the fluid is moving, or how fast. Even though a particular composition of the F and G may give the appearance of a wave travelling left, the actual liquid may flow to the right. The wave is just a manifestation of changes in pressure travelling through a liquid that itself may be moving in the opposite direction. Yet it's exactly these travelling changes in pressure that you mean by 'reaction speed'. The reaction speed however is not so much a result of the 60 UPS, but a direct result of the wave equation.

Now in the case you describe where the pipe is already full and a drain opens: this causes a 'negative' wave (caused by the sudden removal of fluid) to travel towards the source at exactly the speed calculated above (depending on physical constants). For my water constants, the 'gap' would reach the source after 10 seconds for a pipe of 60 tile length. Only then will the source be able to start replenishing the pipe. So yes, there is a reaction speed. And this is completely natural, and not a problem. There is no problem, because the 60 tile pipe acts as a reservoir to supply the drain until the source gets the message. The longer the pipe, the longer it takes the source to realise what's going on, but the bigger the reservoir will be as well.

When the drain is then suddenly closed, the incoming fluid will bounce against the end of the pipe, and send a wave back towards the source. The wave travelling backwards will effectively bring all incoming fluid to a halt as it passes it. The incoming flow plus the bounced wave will indeed rise the level temporarily to at most twice the normal level. When the reflected wave reaches the source, the source will of course stop supplying. When the system settles, the level may be slightly elevated above normal. For short pipes this can be up to twice the normal level, but for longer pipes the effect will be mitigated by friction.


Now I realise that this exact dependence of the speed of waves (or reaction speed as you call it) on a physical constant in the flow update step might be met with disbelief. In fact, it is true that as each tile responds to changes in its neighbours in the previous frame, some minute effect will travel at 60 tiles/second. But this is an approximation error! Were we to use an infinite amount of infinitely small pipe pieces and model at infinitely small time steps, this effect would vanish. Another (more obvious) approximation error is that even very large values for c^2 would not allow us to exceed a wave speed of 60 tiles/second.


I hope I succeeded in bringing this complicated matter across. If anything remains unclear, don't hesitate to ask!


TheYeast

PS. In relation to the above:

pleegwat wrote: Sun Sep 16, 2018 9:12 pm That's a real thing; If I remember correctly it's related to the speed of sound in the liquid. Looking at the nearest neighbours on the previous tick gives you a speed of 60 tiles per second. Google gives me real speeds of 1000-1500 m/s for common fluids however.

The speed of sound would indeed be what you would get if the pipe was completely filled at all times.
In Factorio, the level of fluid in pipes is allowed to rise and fall. This means that adding 25% extra to a pipe at 50% would only raise the pressure in so far that gravity is pulling the additional fluid at the top downwards. The small increase in pressure yields the small value for c^2 above, and thus a low wave speed.
In reality, the fluid content inside a fixed length of pipe hardly changes: there are no 'air holes' to replace drained fluid with a lighter gas. So a pipe is always at 100%. When a pump tries to force in an additional 1%, the only way this can happen is by compressing the fluid. And this causes the pressure to rise very sharply, which translates into a high value for c^2, and thus a high speed of the wave.

pleegwat wrote: Sun Sep 16, 2018 9:12 pm I'm sure a physicist will be along shortly to tell me how wrong I am.

Sorry about that

No really you were not wrong, but that speed of sound thing applies to the case where the pipes are always filled with no air holes. This may be a bit more realistic, but makes the pipes rather boring to watch in the game. Also, high values for c make simulation a bit more fickle, because there are always approximation errors because of the discrete pipe and time slices, and more extreme values tend to bring these out.
Also, it would bring the complication of having to model the transition of being empty to fully filled up. Not worth it in my opinion.

TheYeast wrote: Mon Sep 17, 2018 12:53 am

Dominik wrote: Sun Sep 16, 2018 7:18 pm Hi Yeast,
thanks you for your proposal, so far it seems to be the most reasonable, although I am still unsure about the electricity model which also is interesting.
I admit that my knowledge of physics is rather limited, I had to rely on my common sense. About the “speed kinda models the pressure”, I suppose I could have put more thought into it when writing it. When I think about it, pressure describes it best, it's just that it developed from speed originally and is still called that and I never took the time to rethink what it is.
The model actually is not that dissimilar. The pipe segment has volume (same to level), and the pressure, and connections store the speed - which is just the last step flow. The speed only plays some role in the update and does not control it fully.
From what you propose I really like the idea to push towards only using the last state. I will have to think about it, might steal it. Right now I am thinking about allowing going over the pipe volume limit which would allow this and simplify things a lot.
Your equations are a simplified version of what I currently have. Unfortunately I don't think it would work very well in this form.
The main issue I see is a very low reaction speed. For example - have a straight pipe from source to drain, source is pumping, drain is closed, pipe is full. The drain opens. What I think your model does is that in first tick, only the last segments moves 1/4 of its fluid into the drain (assuming dt=1, which is about what we have) and all the rest stays in place. In next step, one more segments moves a bit, 1/16. Etc. You need "length of pipe" iterations for the wave to reach the source and quite many more to get speed. And then when you get the momentum and you close the pipe, how does the flow stop?
Even so, your ideas are inspiring, I think I will use them, if you don't mind
Thank you, D.

Thank you for your reply Dominik.

First of all, it would not be stealing. As I said, i wrote my simulation for the purpose of improving Factorio, and I even gave a short demonstration at your office when I visited Prague last year, but back then fluid realism wasn't a top priority Anyway I would be disappointed if you didn't consider using it.

Now about the reaction speed issue. I'm absolutely sure that there is a delay in reaction, and I'm equally sure that this is not a problem. In the situation you describe it indeed takes some time before the source 'becomes aware' that something is draining the pipe. In fact, this awareness will travel even slower than 60 tiles per second!

The general solution for the one-dimensional wave equation is

Code: Select all

u(x,t) = F(x-c*t) + G(x+c*t).

Here u(x,t) is the amount of fluid at time t and position x. F and G can be any two continuous functions. They represent two waves of arbitrary shapes travelling to the right (F) and travelling to the left (G). Their shape is dependant on the circumstances (sources/drains) but because of their arguments ( x+c*t and x-c*t ) they travel exactly at speed c and -c. And c simply depends on the flow update step:

Code: Select all

connection.flow += (connection.pipe0.level - connection.pipe1.level) * c^2;

(This can easily be derived from the wave equation)

As I discussed in response to BlueTemplar, I was using more realistic physical constants than Factorio is:

Code: Select all

            acceleration   momentum preservation
            
Water:      0.01	   0.999
Steam:      0.2            0.99999
Oil:        0.014          0.9

Factorio:   0.4            0.59

With my water acceleration, c^2 = 0.01, giving c = 0.1 but since we update 60 times per second, we get an effective speed of 6. So waves travel at 6 tiles/second. With (presumably) Factorio constants, we get c^2 = 0.4, giving c = 0.6325, and a speed of 38 tiles per second. Yes, that's right. Factorio already seems to have a 'reaction speed issue'. In sixty iterations, changes in supply and demand travel 'only' 38 tiles as it is. But no worries, now comes the 'not a problem' part.

(As an aside: considering a tile is roughly the size of a Factorio engineer, 6 tiles per second is pretty decent for a wave in a liquid)

Please be aware that this fixed speed of waves has nothing to do with throughput. The flow speed and thus throughput can be huge: the speed of the wave just models how long it takes for changes in flow speed to propagate through the system.
To be more precise: the solution to the wave equation, u(x,t) = F(x-c*t) + G(x+c*t), only tells us how much fluid is at a certain time and place, not in which direction the fluid is moving, or how fast. Even though a particular composition of the F and G may give the appearance of a wave travelling left, the actual liquid may flow to the right. The wave is just a manifestation of changes in pressure travelling through a liquid that itself may be moving in the opposite direction. Yet it's exactly these travelling changes in pressure that you mean by 'reaction speed'. The reaction speed however is not so much a result of the 60 UPS, but a direct result of the wave equation.

Now in the case you describe where the pipe is already full and a drain opens: this causes a 'negative' wave (caused by the sudden removal of fluid) to travel towards the source at exactly the speed calculated above (depending on physical constants). For my water constants, the 'gap' would reach the source after 10 seconds for a pipe of 60 tile length. Only then will the source be able to start replenishing the pipe. So yes, there is a reaction speed. And this is completely natural, and not a problem. There is no problem, because the 60 tile pipe acts as a reservoir to supply the drain until the source gets the message. The longer the pipe, the longer it takes the source to realise what's going on, but the bigger the reservoir will be as well.

When the drain is then suddenly closed, the incoming fluid will bounce against the end of the pipe, and send a wave back towards the source. The wave travelling backwards will effectively bring all incoming fluid to a halt as it passes it. The incoming flow plus the bounced wave will indeed rise the level temporarily to at most twice the normal level. When the reflected wave reaches the source, the source will of course stop supplying. When the system settles, the level may be slightly elevated above normal. For short pipes this can be up to twice the normal level, but for longer pipes the effect will be mitigated by friction.


Now I realise that this exact dependence of the speed of waves (or reaction speed as you call it) on a physical constant in the flow update step might be met with disbelief. In fact, it is true that as each tile responds to changes in its neighbours in the previous frame, some minute effect will travel at 60 tiles/second. But this is an approximation error! Were we to use an infinite amount of infinitely small pipe pieces and model at infinitely small time steps, this effect would vanish. Another (more obvious) approximation error is that even very large values for c^2 would not allow us to exceed a wave speed of 60 tiles/second.


I hope I succeeded in bringing this complicated matter across. If anything remains unclear, don't hesitate to ask!


TheYeast

PS. In relation to the above:

pleegwat wrote: Sun Sep 16, 2018 9:12 pm That's a real thing; If I remember correctly it's related to the speed of sound in the liquid. Looking at the nearest neighbours on the previous tick gives you a speed of 60 tiles per second. Google gives me real speeds of 1000-1500 m/s for common fluids however.

The speed of sound would indeed be what you would get if the pipe was completely filled at all times.
In Factorio, the level of fluid in pipes is allowed to rise and fall. This means that adding 25% extra to a pipe at 50% would only raise the pressure in so far that gravity is pulling the additional fluid at the top downwards. The small increase in pressure yields the small value for c^2 above, and thus a low wave speed.
In reality, the fluid content inside a fixed length of pipe hardly changes: there are no 'air holes' to replace drained fluid with a lighter gas. So a pipe is always at 100%. When a pump tries to force in an additional 1%, the only way this can happen is by compressing the fluid. And this causes the pressure to rise very sharply, which translates into a high value for c^2, and thus a high speed of the wave.

pleegwat wrote: Sun Sep 16, 2018 9:12 pm I'm sure a physicist will be along shortly to tell me how wrong I am.

Sorry about that

No really you were not wrong, but that speed of sound thing applies to the case where the pipes are always filled with no air holes. This may be a bit more realistic, but makes the pipes rather boring to watch in the game. Also, high values for c make simulation a bit more fickle, because there are always approximation errors because of the discrete pipe and time slices, and more extreme values tend to bring these out.
Also, it would bring the complication of having to model the transition of being empty to fully filled up. Not worth it in my opinion.

Lubricus wrote: Mon Sep 17, 2018 8:30 am If there only is flow between pressure differences and pressure = c*fluid_level.
Could it then be flow between full pipes?

Lubricus wrote: Mon Sep 17, 2018 8:30 am And wouldn't pressure travel at the speed of the liquid?

Lubricus wrote: Mon Sep 17, 2018 8:30 am And then the throughput be to limiting compared to the amount of fluid stored in the pipe?

Dominik wrote: Mon Sep 17, 2018 11:20 am The theory is nice, but the theory is not what your algorithm in fact does. Big C^2 does not fix it if you limit the flow by 0.25.
What I see is that your flow updates incrementally by volume difference -> 1st iter. last segment moves 1/4 to the drain; 2nd iter last segment moves some more and second to last moves 1/16... the negative wave exponentially losing strength. So the pipe will be emptying very slowly into the drain, not really capable to satisfy a large demand, and due to the exponential it would take about infinite number of iteration to get a flow of some 1/2 per tick from a source not even very far away. Changing the constants do not change much about it.

flow += (pipe0.level - pipe1.level) * c^2

flow *= 1 - r;

flow = limit ( flow, pipe0, pipe1 );

	pipe0.level -= flow; 
	pipe1.level += flow;

Lastmerlin wrote: Mon Sep 17, 2018 1:59 pm Fairness/Logic of the system: Perfect fairness is not even soo important in my opinion. What is important is a logical and coherent behaviour. Right now, a large pipe system is a nightmare to debug. Sometimes parallel paths reduce throughput, sometime some paths get huge preference, almost identical layouts create very different results. Factorio is all about finding and fixing flaws, so any system should give the player the information and tools to do exactly this. I believe your current plan is already a very good direction. Any algorithm, that uses global data (like electric current models) could create locally strange and unintuitive results. What the player sees is always local, so I believe the algorithm should operate on local data as well.

Lastmerlin wrote: Mon Sep 17, 2018 1:59 pm Sometimes parallel paths reduce throughput, sometime some paths get huge preference, almost identical layouts create very different results. Factorio is all about finding and fixing flaws, so any system should give the player the information and tools to do exactly this.

mrvn wrote: Mon Sep 17, 2018 2:07 pm I think this problem comes simply from the total design flaw of computing everything in a single step. Every pipe takes it's state, computes the next state and overwrites its own state with it. The order in which pipes are evaluates totally changes the outcome. So not only does fluid in a fork flow unfair. Taking a blueprint and building it somewhere else can totally change the flow.

Zavian wrote: Mon Sep 17, 2018 2:35 pm If you need more throughput than one pipe can provide, then duplicate the design the same way you would for a row of smelters.

mrvn wrote: Mon Sep 17, 2018 2:41 pm

Zavian wrote: Mon Sep 17, 2018 2:35 pm If you need more throughput than one pipe can provide, then duplicate the design the same way you would for a row of smelters.

I needed more throughput than one pipe can provide for the ONE fluid output of ONE washing plant (Angels + Bobs mod) with beacons mk3. Had to add the high pressure pipe mod to get bigger pipes to make it work at full beaconed speed. Vanilla pipes using pipe/pump/pipe/pump/pipe pattern couldn't handle the throughput.

TheYeast wrote: Mon Sep 17, 2018 12:53 am

pleegwat wrote: Sun Sep 16, 2018 9:12 pm I'm sure a physicist will be along shortly to tell me how wrong I am.

Sorry about that

No really you were not wrong, but that speed of sound thing applies to the case where the pipes are always filled with no air holes. This may be a bit more realistic, but makes the pipes rather boring to watch in the game. Also, high values for c make simulation a bit more fickle, because there are always approximation errors because of the discrete pipe and time slices, and more extreme values tend to bring these out.
Also, it would bring the complication of having to model the transition of being empty to fully filled up. Not worth it in my opinion.

TheYeast wrote: Mon Sep 17, 2018 12:21 pm As a recap of the algorithm:

Pass one:
Flow speeds are increased/decreased in with respect to differences in fluid levels:

Code: Select all

flow += (pipe0.level - pipe1.level) * c^2

Therefore, previous flow is maintained ( += ) even if the adjacent pipes are now at equal level! Flow will not be set back to zero at each pass!

Flow speed is slightly decreased to simulate friction:

Code: Select all

flow *= 1 - r;

Since r is very close to zero, this can mostly be ignored when reasoning about the system.
Now apply the sanity limit:

Code: Select all

flow = limit ( flow, pipe0, pipe1 );

Where the limit function limits the flow to 25% of the level in the source (depends on flow sign).

Pass two:
Update content of pipes:

Code: Select all

	pipe0.level -= flow; 
	pipe1.level += flow;

Because throughput seems to be a concern, I will do a separate post about flow rate.

    T1-j-p-j-..-j-p-j-T2

    T1-j1-S-j2-T2

TheYeast wrote: Mon Sep 17, 2018 12:21 pm Because throughput seems to be a concern, I will do a separate post about flow rate.

connection.flow += (connection.pipe0.level - connection.pipe1.level) * c^2;

f += (p0-p1) * c^2;

connection.flow *= (1.0 – liquid.friction);

f *= 1 - r;
or
f = f * (1-r);
or
f = f - r*f;

f += (p0-p1) * c^2;

(p0-p1) * c^2 == r*f
d * c^2 == r*f   	(substitute d)
f == d * c^2 / r  	(move f to the left)

f == d * c^2 / r			(first condition)
d == (100-4*f) / n			(second condition)
f == 100 * c^2 / ( n*r + 4*c^2 )	(solving for f)

fps == 6000 * c^2 / ( n*r + 4*c^2 )