UPS friendly, nuclear reactor design?

[eradicator]

I conducted some morally questionable experiments on reactor-based heat spreading. As expected reactors spread heat much faster and much further than heat pipes (at who knows what UPS cost ofc :p). But with really long lines water becomes the bottleneck again. Maybe someone else finds a good usecase for this ;).

heatspread1.png (2.5 MiB) Viewed 3449 times

heatspread2.png (4.76 MiB) Viewed 3449 times

[nuhll]

Lol, thats an interesting experiment, since its less entities i guess its better for UPS, but costs alot more ofc (resources)

[PunPun]

I conducted some morally questionable experiments on reactor-based heat spreading. As expected reactors spread heat much faster and much further than heat pipes (at who knows what UPS cost ofc :p). But with really long lines water becomes the bottleneck again. Maybe someone else finds a good usecase for this .

For heat simulation an inactive reactor is exactly as expensive to simulate as one piece of heatpipe. With this in mind I quess you should not use heatpipes at all and instead use reactors.
For fluidphysics each piece of pipe is just as expensive to simulate as a turbine or a heatexchanger. Each pump however is more expensive as it splits the fluidnetwork into two. A pump is actually more expensive to simulate than a watersourcepump. A pair of undergrounds is as expensive as one pipe. This is why for maximum ups you really need to ditch those pump ponds and just put watersources directly to the heatexchangers.

Also most of the megabases I have seen would get a lot more ups from optimizing their oil processing. I see a lot of unneccessary long pipes everywhere. If you count the number of pipes then reactors are usually less than .1%.

[nuhll]

The "+" about his idea is, that you need less reactors then heatpipes, correct? Doesnt that mean better for UPS?

[eradicator]

@nuhll: Entites have different costs depending on what they do, so the pure count is less helpful than it seems. Some entities like inserters can also go to "sleep" where the engine skips all calculations for them until they "wake up" (called "active" in the modding api), which some megafactories utilize when they want to "switch off" certain production blocks.
______

For heat simulation an inactive reactor is exactly as expensive to simulate as one piece of heatpipe. With this in mind I quess you should not use heatpipes at all and instead use reactors.

From a quick look at the debug overlay the heat-conducting reactors do not go to sleep. So they still have to do work for the fuel-consumption/heat generation logic.
Auxillary Tests

1. Heat transfer isn't affected by the active state of the reactors, so it's possible to set them .active=false and still use them as conductors. (is this what you meant?)
2. I see no way to make the reactor sleep naturally. Even if it's output inventory is blocked after burning through a fuel cell and it therefore can't do any work until the output is unblocked, it stays active nonetheless.

fullrector.png (27.17 KiB) Viewed 3423 times

Buildfacts (By the way: All my build pictures are native resolution so you can zoom in to see the details - in case nobody noticed yet. Link to my screenshot mod is in my signature :p.):

1. The first "one row" build has to use extra heatpipes for spacing because otherwise the exchangers don't align with the reactors, thus it uses (1 reactor + 2 heatpipe) instead of (6 heatpipe) for every two exchangers.
2. The second "city block" style build has 1.9 reactors per exchanger, whereas standard heatpipe builds only have 1.5 heatpipes per exchanger.

For fluidphysics each piece of pipe is just as expensive to simulate as a turbine or a heatexchanger.

But the turbine has to do additional calculations for consumption+power production in addition to transfer. And again doesn't seem to sleep naturally.

This is why for maximum ups you really need to ditch those pump ponds and just put watersources directly to the heatexchangers.

Sure. But for that you'd have to use ocean-optimized map settings in vanilla, or play modded. And if mods are ok then it'd be more effective to just use "Turbine Mk2", "Reactor Mk2", etcpp. Both of these options are for my taste sacrificing too much gameplay to Yuu Peyes.

[PunPun]

From a quick look at the debug overlay the heat-conducting reactors do not go to sleep. So they still have to do work for the fuel-consumption/heat generation logic.
Auxillary Tests

Yes but that logic is less calculation than what is needed for even a single heatpipe to conduct a single tick of heat. So if you can save two heatpipes by placing a reactor then you are saving cpu cycles. The reactors and heatpipes need to be active to conduct heat anyway so you are saving cpu cycles by using reactors instead of heatpipes.

But the turbine has to do additional calculations for consumption+power production in addition to transfer. And again doesn't seem to sleep naturally.

The same applies here. These calculations are less than what you need for fluid to transfer from one pipe segment to the next so If you can save two pipe segments by having not 100% used turbines then you are saving cpu cycles.

[nuhll]

Only one way to find out. do some real life tests

[eradicator]

Yes but that logic is less calculation than what is needed for even a single heatpipe to conduct a single tick of heat.

Can you post a link to where you got that information from? Would be really useful.

The reactors and heatpipes need to be active to conduct heat anyway so you are saving cpu cycles by using reactors instead of heatpipes.

When i tried that yesterday the rector conducted just fine when it's set to active=false.

[PunPun]

Can you post a link to where you got that information from? Would be really useful.

Educated quess based on what has been said in the FFF:s and my own programming experience. Besides if it was the other way around then we would not even be having a conversation about ups friendly reactors as by the time you would have enough assemblers/furnaces to use multiple gigawatts then the reactor would be a drop in a bucket and no one would even notice they were dropping ups.

When i tried that yesterday the rector conducted just fine when it's set to active=false.

What I meant by active was that the objects will need to be accessed every tick.

[eradicator]

Can you post a link to where you got that information from? Would be really useful.

Educated quess based on what has been said in the FFF:s and my own programming experience.

Serveral FFFs also say "never guess about performance". I was just hoping someone had already done some good tests on this. Meh.

Besides if it was the other way around then we would not even be having a conversation about ups friendly reactors as by the time you would have enough assemblers/furnaces to use multiple gigawatts then the reactor would be a drop in a bucket and no one would even notice they were dropping ups.

I don't quite follow that logic. It wouldn't make much of a difference in a normal factory if a reactors fueling logic took slightly longer than updating a single heatpipe, thus making a reactor as expensive as i.e. 2 heatpipes instead of 1.x. And assemblers are likely to be much better optimized than reactors.

When i tried that yesterday the rector conducted just fine when it's set to active=false.

What I meant by active was that the objects will need to be accessed every tick.

I see. The mod api LuaEntity happens to have something actually called "active" (no clue what it's called internally) which is rather relevant to UPS discussions, so seeing that phrase used for something entirely different is rather confusing.

[PunPun]

I don't quite follow that logic. It wouldn't make much of a difference in a normal factory if a reactors fueling logic took slightly longer than updating a single heatpipe, thus making a reactor as expensive as i.e. 2 heatpipes instead of 1.x. And assemblers are likely to be much better optimized than reactors.

But why would they make a new system to handle just the reactors when they already have a generic one that already handles everything from a boiler to a assembler. As far as I know anything that consumes or produces something is the same kind of object doing the same thing with the same code and the difference is in what is being produced/consumed and what sprite is being shown. I remember reading in a FFF that the heat system is actually just a fluid system with heat being the amount of fluid there is.

And if they did make a new system to spesifically handle reactors why do you think they would deliberately make it massivly more cpu intensive than a generic consume/produce object that an assembler is. It literally only has to check if less than fuelduration seconds have passed since fuel was consumed if so then currentheat=min(currentheat+producedheat,maxheat) else check if there is fuel in input if so check there is room in output if so consume fuel. There is zero reason to make it any more complicated. If you think that they somehow made an assembler less complicated than that then please explain how. Optimizing is not magic. It is just figuring out how to make the same outcome happen with less things. You cant optimize turning x,y,z to k to take less work than turn x to y.

And if you compare that to a heatconductor that has to check all its neighbors if they have less heat than it if so move heat from this to all neighbors equally. This requires checking 1+neighbors amount of variables. Calculating how much heat can be transferred which requires addition and division of several variables. At most reactor fuel consumption logic has to access four variables(two if no fuel is ever put into the reactor) that are all inside the reactor object. At minimum a usefull heatconductor has to access two other objects making it three variables and calculate how much heat to transfer to each of them. This is the same for fluid pipes. This gets even worse with intersections where there are more than two neighbors. And if you have a double width pipe then each pipe has to access three other pipes instead of two and there are twice the amount of pipes making it 3x interactions.

And the simulation for heat/fluid is actually even more complicated than I explained to avoid the problem of having placment order changing how heat/fluid moves and preventing higher capacity sections not overfill lower capacity sections. The programmers would have to be seriously incompetent to screw up the reactor/turbine spesific logic to make it take more cpu time than a connected section of pipe.

No matter how much you make your axels and bearings better in a car it will still be easier to push a bicycle.

[eradicator]

And the simulation for heat/fluid is actually even more complicated than I explained to avoid the problem of having placment order changing how heat/fluid moves

Placement order *does* affect fluid flow, but not heat flow. This is trivial to confirm if you just build two very long heat-/pipes from opposite directions. And breaks your speculation that they're the same.

But why would they make a new system to handle just the reactors when they already have a generic one that already handles everything from a boiler to a assembler.
[...]
And if they did make a new system to spesifically handle reactors why do you think they would deliberately make it massivly more cpu intensive than a generic consume/produce object that an assembler is.

They have mentioned several times that entity handling is highly specialized and not component based. A boiler is unlikely to be handled by the same code as an assembler (similar != identical).

You're making speculations based on tiny bits of FFF talk and treat them as solid facts. I don't have any "believe" about how expensive rectors are as heat-conductors. I merely meant to state that there is no data about it, and until such data exists their cost will be $unknown.

[Nefrums]

The metric of how ups efficient a reactor setup is is really simple.
Count number of entities handling fluid or heat. Less is better.
Ups efficiency per W is just
W/(number of entities handling fluid or heat)


Edit: you probarbly need to count heat exangers x3 as they handle 2 types of fluid and heat.

[PunPun]

They have mentioned several times that entity handling is highly specialized and not component based. A boiler is unlikely to be handled by the same code as an assembler (similar != identical).

And yet a furnace, assembler, reactor, turbine and boiler all have a energysource property that can be set to be electric,burner,heat, void or fluid. They all take the exact same parameters and work the exact same way on all of them. They all also have "This is an extension of Prototype/EntityWithHealth". Both a furnace and assembling machine have "Based on Prototype/CraftingMachine.". If this was not some sort of component based system then the developers must be retards implementing the same thing over and over and over again for each different machine.