All the different ways to increase the efficiency of a nuclear power plant

[mmmPI]

I made a reactor using only thermal buffer, no steam tanks at all in the design. Well, the heat exchangers and turbines buffer some but can't do anything about that.

thermal-reactor-overview.png (4.32 MiB) Viewed 5528 times

and it doesn't work at 0MW draw, not multiplayer proof yet !

[mrvn]

And yes, ideally I would not want any part of the factory to be idle and drain power. But the people who design their base with tons of power switches so they can turn parts on and of on demand are few and far between. I would say 99.9% of people just let belts backlog and cause assemblers to sit idle when production exceeds demand. Like your smelter in your save.

waves.

I don't bother pre-beacon, but in a post-beacon world I do in fact switch everything. Power only goes in if the output isn't jammed and all the input materials are available.

Doesn't that mean the beacons drain their power when switched of and when you switch them back you get massive power spikes overwhelming your reactor till they are recharged?

Do you have accumulators before every power switch to smooth that out? Letting the part only draw the power needed to work and some extra to refill the buffers? Some logic to only ever switch on a few parts at a time and enough spare capacity to weather that spike?

I imagine if you have a smelter with 1024 electric furnaces you could turn them on/off in increments of 64 without problem. Not turn them all on/off at the same time.

[mrvn]

I made a reactor using only thermal buffer, no steam tanks at all in the design. Well, the heat exchangers and turbines buffer some but can't do anything about that.

thermal-reactor-overview.png

and it doesn't work at 0MW draw, not multiplayer proof yet !

Tell me how to get rid of the steam getting buffered in the heat exchangers and turbines and I will do it. It's a whopping 3.something seconds of power buffer.

And yes, it's not multiplayer safe, yet. Still a work in progress.

Any ideas how to detect a 0MW drain on the reactor? Only things I can think of is to put in something that uses energy to produce something I can measure. But if it uses energy the problem is already solved and I never have 0MW. A radar, a roboport, with some fine tuning adding just a lamp to show the reactor is working is enough drain to make the thermal detector work.

PS: No cheating with measuring steam levels for this design please. Same as your goal.

PPS: What mod is that with the thermal furnaces? Looks like fun.

[mmmPI]

All adding working buffers can do is change out the interval at which you need consistent flow. If your power needs have a structural change -- for example, you increase your solar capacity or you plop down another block of smelters or furnaces -- then you're either going to run out of or overfill your buffer sooner or later. The only long-term fixes are to regulate power consumption or production to make load match demand over whatever interval your buffers cover.

more working buffer means longer interval yes, but it doen't mean the flow need to be consistent. you can in theory average the flow of the previous hour every hour, then you click a power power and read your last hourly consumption from this grid and you set the timer to be in % what is your consumption compared to max output of the plant.

Say your plant can produce and buffer 100MW per hour, if you read that you consumed 80MW last hour, you know your buffer is now 20% of what it was. So you can set your production for the next hour with timer of 5/4 of 200sec, ( 80% being 4/5 you take 5/4).

that's like taking the way an automated power plant function, except you become the regulating factor. In order not to be forced to change timer every 200 sec for example, you set it every 600 but with 3 time the buffer. The more buffer you have the lower the fequency of the update required.

This means when you build another row of smelter you compute how much power it takes, and you modify the timer accordingly, wether on your own, or when the update time arrive, the consumption written one the power GUI clicking a power pole would reflect this increase in consumption.

If you have isolated grid, this allow for example to have a power plant for you science, that you can configure to run 10%, then 20%, then 30% as you duplicate and blueprint more row. While having he possibility to force a lower regime, like you coul give only 20% power to 3 blueprint instead of 30%.

It's more a method than a design, once you get the logic, then you can find plenty of implementation that would automate the process of either 1) changing the timer/ 2) measuring consumption indireclty.

In theory some people like mrvn say it doesn't work because of the imprecision, it will lead to an incontrolable drift to death spiral and whatever. ( also when i showed him a plant that could last 1000 cycle he modified it so it doesn't work and then said it doesn't work so it's not helpful).

In practice you have to update to account for the drift really rarely, sometimes even not at all. and you can do it in smart ways, like having you thermal buffer loose 1° every 20hours, then having an alarm ring when buffer is depleted the "fix" is very easy, just add one more refuel, you could even automate it. This makes it viable to use in game. If you have a timespan of 960 hours for example you could have that emergy alarm once or twice
( that could be automated, but if i do that mrvn would say i modify the plant to make it work in practice because in theory it doesn't work).

i used it and it was functionnal and practical on a 250hours game ( the manual one not the reading on belt thing this one is just quickly patched together because mrnv said it couldn't believe such system could stay stable for at least 1000 cycle ).

I'm not 100% sure what's going on in your picture, it's using mods I don't, but it looks like some kind of thermal furnace being driven by the nuclear reactors directly. In such a system your only measurable point appears to the inputs/outputs of the furnaces and so you would need to use those as your regulator.

But that is a very different beast than the (unmodded) electrical power systems everyone else has been discussing. Electrical generation in vanilla Factorio requires steam (or solar), so if you're talking about a nuclear electric plant it's going to have steam somewhere in the system for you to look at.

the mods in this game add silicon ore, it's mined by the 2 gigantic miners, the silicon ore is processed into silicon somethig in "heat furnaces" that require a temperature of 765° or so to properly function.

This is a special case i described earlier where you use fuel and burn it for heat, that will not get transformed into steam, nor will it be used for electricity, therefore you cannot rely on electricity consumption to read the amount of fuel required to maintain 765°.

Yes it has steam, it doesn't mean you cannot make system that you could use that don't rely on reading steam, i added this one after i asked to op if he counted it as a way to "automate nuclear power plant" as it was the original title of the topic. Thought it'd be more useful/interesting than just showing my personnal version of what op posted.

The mod made me think differently about vanilla power plant, outside the box kinda

[mmmPI]

Tell me how to get rid of the steam getting buffered in the heat exchangers and turbines and I will do it. It's a whopping 3.something seconds of power buffer.

And yes, it's not multiplayer safe, yet. Still a work in progress.

Any ideas how to detect a 0MW drain on the reactor? Only things I can think of is to put in something that uses energy to produce something I can measure. But if it uses energy the problem is already solved and I never have 0MW. A radar, a roboport, with some fine tuning adding just a lamp to show the reactor is working is enough drain to make the thermal detector work.

PS: No cheating with measuring steam levels for this design please. Same as your goal.

PPS: What mod is that with the thermal furnaces? Looks like fun.

i think that was this one https://mods.factorio.com/mod/heat-furnace
but there was another one for the silicon
and plenty for different nuclear fuel and steps to make plutonium out of recycled nuclear cell.

you right click on the tank for 0.25 second or so, it will disappear and go in your inventory, then you try to make without one

the idea is not about not using steam for buffer but not using the item=> steam tank. and not using the item => iron pipe wether it is to measure or to buffer is not taken in consideration.

i have troube seeing how all this circuitry will make a more efficient power plant than a self regulated design with less drain due to combinators, and not requiring a constant power draw to have the consumption measured.

I guess you like your design but i fail to see where it would shine ?

[mrvn]

the mods in this game add silicon ore, it's mined by the 2 gigantic miners, the silicon ore is processed into silicon somethig in "heat furnaces" that require a temperature of 765° or so to properly function.

This is a special case i described earlier where you use fuel and burn it for heat, that will not get transformed into steam, nor will it be used for electricity, therefore you cannot rely on electricity consumption to read the amount of fuel required to maintain 765°.

Yes it has steam, it doesn't mean you cannot make system that you could use that don't rely on reading steam, i added this one after i asked to op if he counted it as a way to "automate nuclear power plant" as it was the original title of the topic. Thought it'd be more useful/interesting than just showing my personnal version of what op posted.

The mod made me think differently about vanilla power plant, outside the box kinda

I think you could use the reverse of the idea i had with the extra heat exchanger with the furnaces for your moded game.

As long as the nuclear reactor is hot enough the furnaces will work. Put enough of them in a row to fully empty the belt and then add one more. If any silicon reaches that last furnace then it's one of 2 cases:

1) The output belt is backlogged

Easy enough to check if the belt has items on it and if they are moving.

2) The reactor is too cold

If it isn't case 1 then it's case 2. So throw in some fuel. That then makes the furnaces work again, including your control furnace. That cleans up the items that got past the normal furnaces and the system resets.

Best if the control furnace is nearest the reactor. That way the low temp detection would trigger faster. And the small gap in output when furnaces stop working should be made up by having an extra furnace working for a while.

[foamy]

And yes, ideally I would not want any part of the factory to be idle and drain power. But the people who design their base with tons of power switches so they can turn parts on and of on demand are few and far between. I would say 99.9% of people just let belts backlog and cause assemblers to sit idle when production exceeds demand. Like your smelter in your save.

waves.

I don't bother pre-beacon, but in a post-beacon world I do in fact switch everything. Power only goes in if the output isn't jammed and all the input materials are available.

Doesn't that mean the beacons drain their power when switched of and when you switch them back you get massive power spikes overwhelming your reactor till they are recharged?

Do you have accumulators before every power switch to smooth that out? Letting the part only draw the power needed to work and some extra to refill the buffers? Some logic to only ever switch on a few parts at a time and enough spare capacity to weather that spike?

I imagine if you have a smelter with 1024 electric furnaces you could turn them on/off in increments of 64 without problem. Not turn them all on/off at the same time.

There's a bit of a buffer refill spike, but it isn't actually that bad in general, since the beacons turning on at any given time are usually a pretty small fraction of the overall plant, even with sync'd launches. I also tend to build a reasonably sized accumulator bank so that I can detect a brownout and prioritize which bits of the factory go dark first. I'd much, much rather have sciences shut down altogether and everything else humming than a global brownout, y'know?

All adding working buffers can do is change out the interval at which you need consistent flow. If your power needs have a structural change -- for example, you increase your solar capacity or you plop down another block of smelters or furnaces -- then you're either going to run out of or overfill your buffer sooner or later. The only long-term fixes are to regulate power consumption or production to make load match demand over whatever interval your buffers cover.

more working buffer means longer interval yes, but it doen't mean the flow need to be consistent. you can in theory average the flow of the previous hour every hour, then you click a power power and read your last hourly consumption from this grid and you set the timer to be in % what is your consumption compared to max output of the plant.

Say your plant can produce and buffer 100MW per hour, if you read that you consumed 80MW last hour, you know your buffer is now 20% of what it was. So you can set your production for the next hour with timer of 5/4 of 200sec, ( 80% being 4/5 you take 5/4).

that's like taking the way an automated power plant function, except you become the regulating factor.

I mean, sure, I guess?

But the whole point of automating a power plant is so that I don't have to do that busywork. You can just make the electronics do it, with far more care and far more precisely than you ever could. I don't understand what advantage this has, particularly when accurately tracking the power used in order to present that information to the player can also just directly control the reactor itself. It seems like it's just making more work for yourself, and not even the fun, problem-solving kind of work. =/

[mmmPI]

I mean, sure, I guess?

But the whole point of automating a power plant is so that I don't have to do that busywork. You can just make the electronics do it, with far more care and far more precisely than you ever could. I don't understand what advantage this has, particularly when accurately tracking the power used in order to present that information to the player can also just directly control the reactor itself. It seems like it's just making more work for yourself, and not even the fun, problem-solving kind of work. =/

for me at the time it has the advantage of being usable on system that can't read steam like the furnaces in the mod, i was to check on mapview occasionnaly the temperature and reduce the timer or increase it over the course of the game to min-max, i felt like homer simpson hohoho i'm pushing button. the system itself wasn't evolving much, but i duplicated it and knew the timer required in advance.

you can let it drift toward too high ° at the cost of efficiency if you want peace of mind/automated, maybe you'd waste the equivalent of 1° every 5 hours or 50h maybe 100° , that's like a poor wastefull system automation at worse .

it offers the possibility to adjust the energy production to the availability of the fuel: in vanilla i took the example of a very small uranium patch available, no coal, low oil. You need the nuclear power, but you don't have the tech for enrichment. With this you are sure to fix a stable level of consumption, but never eat your buffer/reserve, you'll have intermediate brownout/blackout rather than eating the fuel, which could be a thing who knows , it had more implications with mods where you have several kinds of nuclear cells or reactor.

that's not much it has to offer , but that's still one way to do it, it's "one of the different way to increase the efficiency of a nuclear power plant", the manual-human timer compared to the default no-logic vanilla inserting as much cells as possible.

it's not based on reading steam buffer or flow or accumulator for feedback, instead it's reading electricity consumption on the GUI by cliking a power pole and then adjusting the refuel with a clock, you are part of the machine haha.


You can refine the logic by finding different ways to measure indirectly the consumption of electricity. For example you can count the amount of train that leaves an oupost. If all the trains are filled-up with ore, you have to make things for it to work ofc, but over the course of an hour or 10 minutes you can average the energy cost of a train worth of ore. Then you know if 12 trains leaves full of ore that represent a "debt" of 1 fuel cycle and trigger the refuel for the outpost's local nuclear power plant.

One other way i made a proof of concept is using the number of science flask. you can know in game a pretty good approximation of your hourly production of flask, and your hourly consumption of electricity in a grid that would integrate all what's required to produce science flask. Then you can divide and trigger refuel when 600 flask were produced because you measured/calculated, it would cost 1 fuel load to produce 600 flask.Ofc it requires to have isolate grid and not adding things that would completly change the cost of energy per flask.


To me the 2 later are ways of automating the manual-human timer. That makes it ways to automate power without reading anything in the power plant, but deducing what happens in it and the buffer quantity through indirect means. that's in what they are similar to me.

In order to better manage the energy buffered, you can avoid drain by disconnecting things that do not produce anything, the previous system are little bricks that could be helpful to implement those since they already require isolated grid for different function of the factory. It allow to "freeze" a system to avoid chest getting filled which would represent "grey energy" away out of the buffer, ready to get back in and throw away the calculations. At this point we are taking about efficency of a system, which instead of MW per fuel cell could be "useful goods" per fuel cell, because having tons of MW per fuel cell is good, but you need the MW for something .


at this point it has no longer much visible similarities left with the human-timer thingy.

[mmmPI]

I think you could use the reverse of the idea i had with the extra heat exchanger with the furnaces for your moded game.

that's a game so old i don't have the save anymore sadly

to get rid of the half belt of fuel cell buffer in your power plant you can use the belt carrying the fresh fuel to isolate 1 by 1 the last fuel of a cycle: say 4 are running, you make 1 belt to disable when the X next belt that have something on them. It will make a group of 3 and 1 that lag behind, reapeat the process for each fuel.This means you can unload 4 cells in a chest from 1 swing, and then creates gaps of defined number of belts between them.

Make it so that the gap between each fuel cell is the same amount of belt than the amount of belt that separate each injecting inserter from each other.

Then stop the belts just in front of loading inserter all at the same time to stuck the fuel in position. linking them 4 and disable when fuel =4

could be no chase, no chest, no buffer i think

It doesn't require wiring inserters just the belts in front of them, and some along the way that bring the fuel.

It shouldn't interfere with the existing logic ( at first thought).

[mrvn]

Update on my thermal buffer design:

First I made a little display for the control functions. It shows a green lamp when the temp is low. Which includes when it is burning fuel to raise the temperature. Second is a blue progress bar that shows the fuel being burned. It's full when fuel gets inserted and then shrinks to nothing.

And just for mmmPI I made the input belt not have a ton of fuel cells on it.

thermal-reactor2-display.png (841.79 KiB) Viewed 5483 times

The other and more substantial update was fixing the issues I mentioned in my post:

1. The water tank filling is improved.
2. The 5-tick delay for measuring water usage has been replaced with a memory cell. The memory stores the water level at the end of the pump refilling the water tank. Then the water has 2 inserter swings time to fall by at least 5. Why 5? Because the heat exchanger needs to have enough of a temperature gradient left or it triggers too late when the reactor cools down.
3. I also moved the thermal check setup further from the reactor because extreme swings in power consumption could run into a brownout. This runs the reactor some 5-20°C hotter giving a larger margin of error when the power drain changes at bad times.
4. I've added one radar and 4 lamps as minimal drain for the thermal test. The drain is only activated when the water usage test starts and is stop as soon as water usage is detected. On a busy reactor that is within ticks. On an idle one it takes nearly 2 inserter swings. Now the thermal check always detects excess heat.

The radar switches to solar and keeps running when not used for the thermal check. But if the temperature of the reactor is low during the thermal check then it looses power. Not ideal if the radar should replace a regular one. And idle roboport doesn't drain enough energy. I could use 64 lamps but I hate the blinking "No power" flashes. A beacon would be the least annoying but also totally useless. At least the radar scans chunks over time.

thermal-reactor2-thermal-check.png (5.31 MiB) Viewed 5483 times

You replied while I wrote and somehow the forum doesn't show a quote button on that post, so here comes a manual quote:

to get rid of the half belt of fuel cell buffer in your power plant you can use the belt carrying the fresh fuel to isolate 1 by 1 the last fuel of a cycle: say 4 are running, you make 1 belt to disable when the X next belt that have something on them. It will make a group of 3 and 1 that lag behind, reapeat the process for each fuel.This means you can unload 4 cells in a chest from 1 swing, and then creates gaps of defined number of belts between them.

Make it so that the gap between each fuel cell is the same amount of belt than the amount of belt that separate each injecting inserter from each other.

Then stop the belts just in front of loading inserter all at the same time to stuck the fuel in position. linking them 4 and disable when fuel =4

It doesn't require wiring inserters just the belts in front of them, and some along the way that bring the fuel.

It shouldn't interfere with the existing logic ( at first thought).

I saw other designs that put just 4 fuel cells on the belt for 4 reactors, count perfect. I generally don't bother with that. Often I have a train stop by and drop fuel. What does the belt matter compared to a cargo wagon full of fuel cells? Whatever fuel gets produced ahead of time will eventually be used up. At some point the uranium ore patch will be exhausted and I will be happy to have a ton of fuel left on the belt and don't have to race to build a new mine or face blackouts. Or I give up the game before that happens and then what does it matter that I produced all that fuel for nothing?

I don't think there is any call to make the belt stop so one fuel cell remains in front of each inserter. Picking fuel up from the belt with a pulse is risky and fails if the fuel is a tick misplaced. So direct belt to reactor insertion is not my thing. And with the buffer chest for 1 fuel cell you can just let the fuel go by and each inserter will pick one up sometime in the 200s the old fuel burns. At least for small reactors where 200s means the fuel goes around a few times.

On larger reactors it's important to have fuel in regular intervals so each chest gets a fuel within 200s. But the fuel spreader I made with just a few wires will do that. You just have to adjust the number of belts you read to get the right interval.

For me the only users of uranium are the nuclear reactor and trains. And trains will use other fuel sources if needed. But same as the reactor I produce so much ahead of time I think I've never had train switch back from nuclear fuel. Each nuclear fuel last ages in trains so I have days and days of fuels buffered. Even if I do use some nukes that's just for fun and doesn't make a dent. I've never used uranium bullets in gun turrets. Always used lasers and flame turrets a that stage in the game.

PS: one can also easily buffer 2 fuel cells per chest allowing for a more random appearance of more fuel. Just as long as the average is fast enough.

[gGeorg]

I made a reactor using only thermal buffer,

That is positive contribution to the thread. Your style of spaming is otherwise somewhat annoying. Thank you that you used the latest version of Perfect cloverleaf as base. Althou your re-implementation to one time clock has issues with proper counting. Also, the loading inserter was filter because of : filter inserter without filter fall into deep sleep immediately. Yellow inserter, you put in ( a bold move to offset time and save min. power) is checked every tick, even in disabled status. So you might consider to use rather original setup.

I was thinking about same idea, to measue the over heat. It ticked in my head by

in my design the reactors were 750° when the furthest exchanger was 510° when under full load for long time

The coldest heat exchanger have to be 501C in stable production. (full consumption) For simple reason, if it goes higher it means there was not enough heat consumption. e.g. not enough water or not enough heat exchangers. In my case fourleaf, with very short heat-pipes, core is about 545C then furthest piece of heatpipe 501C.

Which means, overheat can be measured. It is interesting aproach for brownout supression. Because, heatpipes are so slow now, that buffer to compensate slow heat-pipes have to be massive. So rather than use thermal capacity of buildings as (positive) thermal buffer than fight with heat-pipe delay. Is smart move, make sure plant is always pre-heated. Then you need to only buffer redundant energy for lossless property. e.g. no brownouts, plant can always deliver max power immediately.

I think I can come with far UPC friendly solution for overheat measure than mrv's test bed prototype. :=)

[mmmPI]

I saw other designs that put just 4 fuel cells on the belt for 4 reactors, count perfect. I generally don't bother with that. Often I have a train stop by and drop fuel. What does the belt matter compared to a cargo wagon full of fuel cells? Whatever fuel gets produced ahead of time will eventually be used up. At some point the uranium ore patch will be exhausted and I will be happy to have a ton of fuel left on the belt and don't have to race to build a new mine or face blackouts. Or I give up the game before that happens and then what does it matter that I produced all that fuel for nothing?

I don't think there is any call to make the belt stop so one fuel cell remains in front of each inserter. Picking fuel up from the belt with a pulse is risky and fails if the fuel is a tick misplaced. So direct belt to reactor insertion is not my thing. And with the buffer chest for 1 fuel cell you can just let the fuel go by and each inserter will pick one up sometime in the 200s the old fuel burns. At least for small reactors where 200s means the fuel goes around a few times.

You need 6 ticks to trigger the insertion not just a pulse, if you want to pick from the belt. that's a constant cost mechanism for all reactors, it could be very low drain.

but you can easily have fuel cell stop in front of each inserter without combinators or drain per reactor, perfectly tick placed and synced.

I used another method than the one you ignored after failing one time, this is why i edited my post so many times lol sorry for the shit i posted earlier.

NObuffer.png (244.46 KiB) Viewed 5443 times

realnobuffer3.zip

(2.71 MiB) Downloaded 149 times

Each belt in front of inserter read/hold/disable when fuel cell =1 this means they stop everything that enters right as it enters.
Then you plug the belt 2 tiles before, and you just read/hold.
This means first fuel get stopped by 1rst belt, but when the 2nd one comes 2 tile earliers it let him through.
The contraption at first makes fuel come 1 by 1.
Each next fuel making the previous one move to the next inserter that's very easy to expand.

i still consider it inconsistent to go in deep details to precisely measure the water flow supposedly to be efficient ? And at the same time being so inneficient using 4 unecessary inserter for loading. (i'm not talking about the drain from the fish clock because this one is fun).

sometimes you say things for theory it need to be "this" it need to be "that" but when it's you, you are ok saying, "in practice you don't need this", "in my games i assume load" , "if i give up before why does it matter? "and so on. this is a bit contradictory as an imprecise timer mechanism shouldn't matter to you if the drift is too long for it to be problematic in a game span yet the theoric imprecision the 0.000002° i made up you said it will inevitably creates trouble, "if i give up before it gets problematic why does it matter the imprecision of the measures ?"

if i use an accumulator with <99% for emergency and it triggers only like 3 time in a game causing me a grand total of 12 second or small brownout before the emergency refuel do to voluntary rounding down on measurement, does it matter all that much ? It allows to only have logic/answer for 1 end of the spectrum, not 2, you will always be producing like 99.99% of energy you consume, instead of 100.1% on purpose, to save on circuitry.

i think this is not pleasant attitude but i'm still happy you started to use a refined thermal buffer plant of your own despite your initial aversion to the logic

[mmmPI]

Which means, overheat can be measured. It is interesting aproach for brownout supression. Because, heatpipes are so slow now, that buffer to compensate slow heat-pipes have to be massive. So rather than use thermal capacity of buildings as (positive) thermal buffer than fight with heat-pipe delay. Is smart move, make sure plant is always pre-heated. Then you need to only buffer redundant energy for lossless property. e.g. no brownouts, plant can always deliver max power immediately.

I think I can come with far UPC friendly solution for overheat measure than mrv's test bed prototype. :=)

yes that's one advantage of maitaining a buffer under the form of heat. it's instantly available when you do so, whereas it can delay the restarting of a plant due to their slow speed otherwise.

That's what i wanted to explain when saying it doesn't refill when something is [close to empty] or [close to full] by measuring how close you are. You can aim at maintaining the buffer at 50% at all time.

This is why i think it's not necessary to have 2 different checks, one for too cold, one for too hot. I think you can get rid of the overheating check and instead make your logic so that the buffer drift slowly towards low°. Say 1° per 100 fuel. and you make a correction mechanism that balances the slow drift over time by adding 1 cycle of fuel when detecting the risk of too cold.

less logic, no need for super precision in counting water.

[mrvn]

I made a reactor using only thermal buffer,

That is positive contribution to the thread. Your style of spaming is otherwise somewhat annoying. Thank you that you used the latest version of Perfect cloverleaf as base. Althou your re-implementation to one time clock has issues with proper counting. Also, the loading inserter was filter because of : filter inserter without filter fall into deep sleep immediately. Yellow inserter, you put in ( a bold move to offset time and save min. power) is checked every tick, even in disabled status. So you might consider to use rather original setup.

The clock count being wrong was already noted in the post. (Still have to fix it though, only affects full load and that's not a real use case. You never want to pull exactly 480MW because that would given you constant brownouts for every spike even if the average is 480MW, costs UPS.)

I didn't use the Perfect cloverleaf as base. I just put down 4 reactors from scratch. It's the smallest setup I thing is reasonable and the only truly symetrical one. 2x6 or 2x8 produces less heat in the corners making the heat spread more challenging and harder to test ideas.

The loading/unloading for the fuel I also just dumped in without much care. The challenge was to design the thermal check so I didn't care about the inserters. But I will check out the filter inserter. But I don't see how that would really be true. Unless I understand your comment wrong you want a filter inserter set to "set filter" and then send it a "nuclear fuel" signal when it should refuel, right? Then the filter inserter has to check the circuit network every tick to see if any filter was set.

Is the check if a filter was set cheaper than enable/disable on a yellow inserter or what happens?

I was thinking about same idea, to measue the over heat. It ticked in my head by

in my design the reactors were 750° when the furthest exchanger was 510° when under full load for long time

The coldest heat exchanger have to be 501C in stable production. (full consumption) For simple reason, if it goes higher it means there was not enough heat consumption. e.g. not enough water or not enough heat exchangers. In my case fourleaf, with very short heat-pipes, core is about 545C then furthest piece of heatpipe 501C.

Which means, overheat can be measured. It is interesting aproach for brownout supression. Because, heatpipes are so slow now, that buffer to compensate slow heat-pipes have to be massive. So rather than use thermal capacity of buildings as (positive) thermal buffer than fight with heat-pipe delay. Is smart move, make sure plant is always pre-heated. Then you need to only buffer redundant energy for lossless property. e.g. no brownouts, plant can always deliver max power immediately.

I think I can come with far UPC friendly solution for overheat measure than mrv's test bed prototype. :=)

It's a proof of concept so that won't surprise me. A big improvement should be reducing the number of heat pipes. Spreading heat is expensive.

I've already thought of some changes from the change to a memory cell. The posted design was to aim towards minimal buffering and instant reaction to prevent brownouts. I thought the 5°C difference between the last heat exchanger and the test heat exchangers would alert me 5°C before brownout across the board. But I watched the temperature across the design more closely now.

Heat energy is consumed equally by all heat exchangers with sufficient temperature. It falls gradually when the low temp is reached because not enough heat comes in each tick to produce full steam. But that's a case we need to avoid.

So heat gets used equally by all heat exchangers. So the temperature should fall equally across the design? That is not the case because heat spreading is so slow. Heat spreads until there is a gradient of 1°C. But a greater gradient spreads more heat. While the reactor has fuel a steeper gradient exists until the heat spread == heat produced (- heat not converted to steam, which causes the heat up). When fuel runs out the heat keeps spreading reducing the gradient to 1°C. So the reactor and heat pipes near the reactor cool down more than heat pipes far away.

Then when new fuel is added back to the reactor it first has to heat up and build up the gradient back to full transfer speed. During that time the heat exchanger furthest from the reactor still cools down more. Turns out the 5°C thermal buffer I randomly used as first attempt doesn't always suffice. And that's when the idea that a

plant can always deliver max power immediately.

kind of died, at least one that delivers the max power by throwing in fuel. The heat gradient between reactor and furthest heat exchanger is determined by the power drain. A low drain balances on a low gradient, a high drain balances on a high gradient. To be able to switch from low (or 0) drain to high drain the reactor has to be kept at a temperature high enough that the furthest heat exchanger would still be over 501°C. Which is why I moved my thermal check further away.


In effect you can make a rough temperature detector with this. The minimum gradient is 1°C per tile and there is a max gradient depending on the heat pipe layout and where the heat exchangers are. That gives you a min and max temperature for the reactor. It's slow and inaccurate and can only detect the temp going below min or above max reliably. Use a clock design to insert fuel and 2 detectors at different distances. Detector 1 triggers speed up the clock, detector 2 triggers slow down the clock.

[mrvn]

I saw other designs that put just 4 fuel cells on the belt for 4 reactors, count perfect. I generally don't bother with that. Often I have a train stop by and drop fuel. What does the belt matter compared to a cargo wagon full of fuel cells? Whatever fuel gets produced ahead of time will eventually be used up. At some point the uranium ore patch will be exhausted and I will be happy to have a ton of fuel left on the belt and don't have to race to build a new mine or face blackouts. Or I give up the game before that happens and then what does it matter that I produced all that fuel for nothing?

I don't think there is any call to make the belt stop so one fuel cell remains in front of each inserter. Picking fuel up from the belt with a pulse is risky and fails if the fuel is a tick misplaced. So direct belt to reactor insertion is not my thing. And with the buffer chest for 1 fuel cell you can just let the fuel go by and each inserter will pick one up sometime in the 200s the old fuel burns. At least for small reactors where 200s means the fuel goes around a few times.

You need 6 ticks to trigger the insertion not just a pulse, if you want to pick from the belt. that's a constant cost mechanism for all reactors, it could be very low drain.

but you can easily have fuel cell stop in front of each inserter without combinators or drain per reactor, perfectly tick placed and synced.

I used another method than the one you ignored after failing one time, this is why i edited my post so many times lol sorry for the shit i posted earlier.


NObuffer.pngrealnobuffer3.zip

Each belt in front of inserter read/hold/disable when fuel cell =1 this means they stop everything that enters right as it enters.
Then you plug the belt 2 tiles before, and you just read/hold.
This means first fuel get stopped by 1rst belt, but when the 2nd one comes 2 tile earliers it let him through.
The contraption at first makes fuel come 1 by 1.
Each next fuel making the previous one move to the next inserter that's very easy to expand.

i still consider it inconsistent to go in deep details to precisely measure the water flow supposedly to be efficient ? And at the same time being so inneficient using 4 unecessary inserter for loading. (i'm not talking about the drain from the fish clock because this one is fun).

sometimes you say things for theory it need to be "this" it need to be "that" but when it's you, you are ok saying, "in practice you don't need this", "in my games i assume load" , "if i give up before why does it matter? "and so on. this is a bit contradictory as an imprecise timer mechanism shouldn't matter to you if the drift is too long for it to be problematic in a game span yet the theoric imprecision the 0.000002° i made up you said it will inevitably creates trouble, "if i give up before it gets problematic why does it matter the imprecision of the measures ?"

if i use an accumulator with <99% for emergency and it triggers only like 3 time in a game causing me a grand total of 12 second or small brownout before the emergency refuel do to voluntary rounding down on measurement, does it matter all that much ? It allows to only have logic/answer for 1 end of the spectrum, not 2, you will always be producing like 99.99% of energy you consume, instead of 100.1% on purpose, to save on circuitry.

i think this is not pleasant attitude but i'm still happy you started to use a refined thermal buffer plant of your own despite your initial aversion to the logic

Sorry about switching between theoretical and practical like that. For a perfect plant it matters. For a practical plant it matters no matter how unlikely the case is if it puts the reactor in an unrecoverable state. Because experience has shown that even stuff you say it totally unlikely, like the 0.000002°C drift never going to matter, has a way to do happen if enough people use the design for a long enough time or when people mess with stuff in multiplayer games. So I always prefer a design that is self correcting over one that goes into a dead state.

And no, practical using an accumulator for emergencies doesn't matter. But the case that it does trigger shows that your initial design was flawed, it wasn't perfect. And then my argument is: What happens if you remove your design (or mine or anybody else with a backup) leaving just the emergency accumulator? Doesn't the reactor still work lossless and without brownouts? Why use a method that is flawed and requires a backup if the backup is already flawless? That's just inefficient.

I'm not averse to the logic. I was trying to see and try to fix the flaws. I still maintain that calculating energy consumption can't work perfectly. It will always drift outside of very controlled instances. It can work for your thermal furnace if you control and account all the variables. For example count the number of ticks the furnace works and the number of ticks the furnace is idle. With a setup with just one type of furnace all in the same configuration you can make them all work synchronized. Have all inserters swing at the same time and counting energy becomes easy. You have a fixed amount per tick equal to the drain of everything. And then a fixed amount of energy per inserter swing (the difference between idle and working on recipe). Doing the same for any complex factory? Forget about it.

Note: do the thermal furnaces in your mod even have drain?


Here is an idea for you: Your energy calculations low ball the figures so the reactor rather trends down then up. Because you "can't measure overheating". You use the accumulator to detect brownout. And that's just in time and a dangerous state to be in.

But you can measure overheating with the thermal check. You never want to have a brownout or blackout but overheating just wastes some fuel. So you can high ball the energy calculations and watch for overheating instead. This also gives you more of a buffer as you can detect well below 1000°C while the accumulator fails just short of a brownout/blackout.

Connect one heat exchanger to the reactor with 100-200 heat tiles. Add a steam turbine, a power pole and a beacon as drain. Connect a water tank and fill it with a pump. The pump is your reset switch. If the water level of the tank ever goes below 25000 your reactor is overheating. Stop inserting fuel for a set time and then reset the water tank and your energy calculations will be back in sync.

[mmmPI]

Sorry about switching between theoretical and practical like that. For a perfect plant it matters. For a practical plant it matters no matter how unlikely the case is if it puts the reactor in an unrecoverable state. Because experience has shown that even stuff you say it totally unlikely, like the 0.000002°C drift never going to matter, has a way to do happen if enough people use the design for a long enough time or when people mess with stuff in multiplayer games. So I always prefer a design that is self correcting over one that goes into a dead state.

It doesn't go to dead state, it has 1 automated emergency/correction refuel once in a month or so .

And no, practical using an accumulator for emergencies doesn't matter. But the case that it does trigger shows that your initial design was flawed, it wasn't perfect. And then my argument is: What happens if you remove your design (or mine or anybody else with a backup) leaving just the emergency accumulator? Doesn't the reactor still work lossless and without brownouts? Why use a method that is flawed and requires a backup if the backup is already flawless? That's just inefficient.

The emergency system would function only because it's a thermal buffer. As there is no steam to back up, or very few, as soon as the last heat exchanger receive not enough heat flow, it can triggers the ermergency refuel ( at the end of the fuel cycle, just before planned refuel it's more likely).

With a more classic approach of bufferingsteam, you do not know if the emergency 1 accu<99% will be useful. If it rings when your whole system is 500° it's not enough margin, you need the time for the plant to restart which could cause more severe brownout that the "12 second" i mentionned.

The logic is not flawed, it's just a logic of approximation and correction: let's make all the edge case be dealt with the same way due to altering the theoricly perfect count we may or may not achieve in pratice , all toward the same trend.

I'm not averse to the logic. I was trying to see and try to fix the flaws. I still maintain that calculating energy consumption can't work perfectly. It will always drift outside of very controlled instances. It can work for your thermal furnace if you control and account all the variables. For example count the number of ticks the furnace works and the number of ticks the furnace is idle. With a setup with just one type of furnace all in the same configuration you can make them all work synchronized. Have all inserters swing at the same time and counting energy becomes easy. You have a fixed amount per tick equal to the drain of everything. And then a fixed amount of energy per inserter swing (the difference between idle and working on recipe). Doing the same for any complex factory? Forget about it.

Note: do the thermal furnaces in your mod even have drain?

you see it as a flaw that the calculation is imperfect, but i don't because you can make up for the imperfections with a corrective mechanism.

You don't need to have everything synchronized and all perfect almost the opposite haha, the magic of big numbers is playing for you. the more machnine you have, the easier it is to get a proper average. From 1 to 2 to 3 to 4 to 5 machines it's intuitive. If they have a cycle let say 1 1 1 4 5 1 1. but another is 1 4 5 1 1 1 1 , another one 4 5 1 1 1 1 1, another one 1 1 4 5 1 1 1. i mean if it's random/chaotic, there's more % of chance when adding a 2nd machine that its spike are little offset than exactly the same as the previous. The more machine you add the closer to the average you are at any given moment in time. Like a gaussian distribution ? bell curve ?.

On the one hand computing perfectly things become harder the bigger the factory, on the other hand the sampling+averaging method becomes more accurate.

the "lack of data" is something that prevent statistic and averages to be significant usually, getting more datas and more and more is usually how you make your math and "prediction" more accurate so yeah, give it a bigger factory .

For mining outpost this is particularly true. With 1 miner patch there are big spikes when it's mining or not depending on train cycle. 1 1 1 1 4 5 1 , the 45 being the train at the loading station and soon after consuming more energy to refill the buffer of ore. make it 100 patch. You still in theory need to produce up to 500 electricity at the same time in case they all draw at the same time their max load. But really in a game, you will never have (by accident) all your trains of copper entering they load station at the same time. Even if you recover from something and all train leaves at the same time, due to distance and different mining rate and things like train junctions.

Here is an idea for you: Your energy calculations low ball the figures so the reactor rather trends down then up. Because you "can't measure overheating". You use the accumulator to detect brownout. And that's just in time and a dangerous state to be in.

But you can measure overheating with the thermal check. You never want to have a brownout or blackout but overheating just wastes some fuel. So you can high ball the energy calculations and watch for overheating instead. This also gives you more of a buffer as you can detect well below 1000°C while the accumulator fails just short of a brownout/blackout.

Connect one heat exchanger to the reactor with 100-200 heat tiles. Add a steam turbine, a power pole and a beacon as drain. Connect a water tank and fill it with a pump. The pump is your reset switch. If the water level of the tank ever goes below 25000 your reactor is overheating. Stop inserting fuel for a set time and then reset the water tank and your energy calculations will be back in sync.

I would agree with you for the high ball approximation if the title of the topic was making a super-safe power plant. like fuel checks, auto-init, auto-pause, alert if it measure it is not functionning properly, several back up mechanism in case grids are messed up, belt AND bot fed in case one is disrupted 480.00000 MW or something like that. in case of efficiency, it's better to me to burn a little less than a little more, which is waste. But one can have another ruleset in mind like even 2 ticks of brownout are cheating because otherwise you have a power plant with 99.9% brownout, and the solar pannel for the drain of the feeding inserter is doing all the work 0 fuel needed x)
or if you power your defense perimeter with that power plant, it could be considered differently hehehe.

both could try to reach the theoric perfection from different direction.


But i disagree, it's not really dangerous, the more spacially extended your thermal buffer, the more heat it requires to propagate up to the furthest exchanger as you say. This means that when the furthest exchanger stops functionning, the others still have enough for long time. at this point you enter a phase where the "emergency" refuel can trigger any time provided you ask for full load. Well not really anytime, it would happen just before a refuel, not midway after it when it's burning. ( the local temperature minimum and around that moment). And well not really full load, since as time goes more and more exhanger would start lacking heat lowering the electricity load that could trigger the emergency refuel.

This means there is a "worse time" when it can triggers, it would be after a long period of very low constant draw, ( emergency refuel caused by the closest exchanger lacking heat because the previously mentionned phase has reached the last moment it could reached/the longest).

I think it is funny The emergency refuel worst case is stability. If the consumption has occasionnal spikes, is a tad bit chaotic, it makes it safer, because it triggers the emergency refuel way before than the situation of constant low drain.

AND AGAIN this is very very very very rare situation ahah, if your initial setup is a pretty good approximation it can happen that the equilibrium ° drift toward too cold in 100 or 1000 CYCLE. YES CYCLE OF FUEL, so if you have a very long constant draw, the amount of second it requires for that 1 cycle is hugeee. that's like consuming 24 fuel cells worth of heat buffer with a 10 MW draw for 1 cycle could be 26 hours for this particular fuel cycle depending on the size of the plant. And you'd need one like that to happen after like 1000 cycle ? 55 hours of ingame time.

so after you had 1000 non-problematic cycle to shift the ° equilibrium away, ( minimum 50 hours ingame time or so when 200sec cycle due to fuel load) followed at the exact worse moment by a very low draw of like X hours ( to shift the ° low to the most extreme point it can reach), and then a massive spike in consumption : then yes, it would cause problem because it would take some time for the 2 cells that could be inserted at this moment to burn and start propagating the heat, and refill the thermal buffer up to full power.

During all this time ( 60 hours ?) , you are free to take like 30 second to adjust your timer/calculation so the ° drift is even slower,/more accurate. Since you'd know the amount of drift that occured and roughly the amount of fuel cell burnt/past power production/. you can also just anticipate the emergency refuel and manually trigger a refuel to reset the drifing toward low °. You can "skip" a refuel when drifting toward higher ° as easily by "stealing" manually a fuel load once if you use belts and no buffer

And if you don't oh well, just wait the end of the brownout, it is already recovering, you deserve it haha.

[mrvn]

And no, practical using an accumulator for emergencies doesn't matter. But the case that it does trigger shows that your initial design was flawed, it wasn't perfect. And then my argument is: What happens if you remove your design (or mine or anybody else with a backup) leaving just the emergency accumulator? Doesn't the reactor still work lossless and without brownouts? Why use a method that is flawed and requires a backup if the backup is already flawless? That's just inefficient.

The emergency system would function only because it's a thermal buffer. As there is no steam to back up, or very few, as soon as the last heat exchanger receive not enough heat flow, it can triggers the ermergency refuel ( at the end of the fuel cycle, just before planned refuel it's more likely).

With a more classic approach of bufferingsteam, you do not know if the emergency 1 accu<99% will be useful. If it rings when your whole system is 500° it's not enough margin, you need the time for the plant to restart which could cause more severe brownout that the "12 second" i mentionned.

The accu triggers a few ticks after you run out of steam. So the reactor is already providing less than needed. Throwing in fuel isn't an instant fix but takes time to bring the temp back up, especially if demand goes to full throttle at the same time.

So the question becomes: Will the accumulator run out of power before the reactor is back? One single accumulator will certainly never work. a) not enough charge, b) not enough throughput. But if you have a lot of accumulators they can outlast the reactors dip in power production and you are fine. So it's simply a numbers game.

The logic is not flawed, it's just a logic of approximation and correction: let's make all the edge case be dealt with the same way due to altering the theoricly perfect count we may or may not achieve in pratice , all toward the same trend.

Not discussing this further. You aren't bringing any new arguments and you aren't going to change my mind repeating the same thing over and over. Other people are already annoyed enough.

[mmmPI]

So the question becomes: Will the accumulator run out of power before the reactor is back? One single accumulator will certainly never work. a) not enough charge, b) not enough throughput. But if you have a lot of accumulators they can outlast the reactors dip in power production and you are fine. So it's simply a numbers game.

one accumulator will definitly not be enough to avoid brownout, but would it occur before the game end ? and if it does, would it be a problem to have a brownout for a few second once on non-critical asset ? If the answer is yes, then make a few accumulator, or even have a 20MW steam engine-back up if it's so critical not to have ever 1 sec of brownout i agree with you on that one .

i'm glad you realise it doesn't have to be a dead state and death spiral of blackout-brownout, you can change your mind sometimes haha.

on a computer the 0 and 1 are not really 0 and 1, sometimes it's 0.002 and 0.7, the physical current, but it's corrected every next cycle of transmission so it doesn't matter

[mmmPI]

Hey i'm going to shamelessly double post to advertise my own personnal power plant : viewtopic.php?p=554978

I made it after this thread it's very related. It has 0 combinator and 0 storage tank ! Even with water in them because that's the same ! Here is a sneak pic :

rail plant.png (520.76 KiB) Viewed 5322 times

It rely on counting how much steam is produced by outputting precise amount of it in trains.

It has no mechanism for detecting overheating or cooling because it is count perfect.

Feed 4 fuel cell, get 988 800 steam.

Feed trains with equal amount of steam.

Count 12 trains.

Refuel.

Account for the rounding every 197 760 trains thanks to a belt-clock.

It is also count-perfect for fuel, it doesn't need some nuclear fuel cell running on a belt, you use 4 you put 4.

It does use a circling belt with material for fuel trains, but it's no-drain as it doesn't use extra inserters.

[mrvn]

Well, it has steam tanks. Tanks on wheels. But you aren't using them as such. There is also a lot of heat pipes. I eyeball it at ~175. Which would buffer one refueling cycle. So 2 questions (plus a bonus):

1) So how do you start this?

A) Do you have the trains sitting in the cold reactor and then manually trigger a refuel till steam starts to fill the trains?
B) Fill the reactors with fuel and when steam comes out the other end remove all fuel and let automatic take over?
C) Drop in exactly N fuel because you know then steam is produced?

I imagine you want the reactor to be a bit hotter than minimum. So when trains aren't leaving because power demand is low and the temperature equalizes the reactor doesn't get cold. But not too hot so you have lots of thermal buffer.

2) Say you have full trains sitting in all the bays. Then one leaves and you pass 12 trains and refuel. No more steam is consumed.

You have 1 empty train so that is 1/12 a fuel cell taken care of as steam. 11/12th of the fuel gets buffered as heat. By my estimate the heat pipes should be enough if the reactor didn't start off too hot.

So how hot and cold does the reactor go?

Bonus Question:

Trains with a fluid wagon at the front (when your trains go backwards) are really slow, bad wind resistance. Do you have an extra stations in the schedule to turn the trains around so they drive forward for the long distance and backward only to turn around?