Slightly changed the design posted by vlad[54rus] and I managed to increase the efficiency. Also changed an unnecessary adv heat exchanger into a normal heat exchanger.
1407.67 HU/t, efficiency 14.66, 1 reflector
02230A120D0C0D110A03030C0D0C0D0C0D12020C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D110A110D0C0D110A11|fsn
I get the impression you're not a programmer, otherwise you probably wouldn't have even suggested this:
"3. Simulate my manual calculation (The most complicated but accurate if done correctly)"
Yes, I'm not a programmer, but I have some programming experience.
Details on how to do it:
1.Divide the components into sections (components in separate sections cannot exchange heat directly except through the reactor hull)
2.Calculate usable vent cooling (limited by heat exchanger transfer rates), hull cooling for each section
3.If a section contains components directly heated by fuel rod(s):
3a. Calculate heat generation of the fuel rod(s)
3b. If vent cooling + hull cooling >= heat generation then add vent cooling of this section to output
3c. Else ...
4.Else
4a. If hull cooling <= vent cooling then add hull cooling of this section to output
4b. Else add vent cooling of this section to output
EDIT: My ideas on section division: Make separate sections as lists
Start with the left-top component
.1.If this component can accept/generate/transfer heat (excluding the component heat vent) then
...2.If this component is in current lists then
.....2a.Go to 1 and check for the next component
.....2b.Else create a list and add that into the list
.......2c.If the component next to this one (on all 4 sides) cannot accept/generate/transfer heat (including the component heat vent)
.........2d.Go to 1 and check for the next component
.......2e.Else add that component into the current list
.........2f.Go to 2c and repeat
Display MoreI gave this a bit more thought, and I can show the following details for a simulation (and possibly as predictions):
1. Hull heating (from fuel rods with no heatable neighbors)
2. Component heating (from fuel rods that do have heatable neighbors)
3. Hull cooling (how much the hull is (or can be) cooled down by various components - there are currently 2 types of vents and 3 types of exchangers that can do this) - in some cases, the "used" hull cooling might be less than the "possible" hull cooling.
4. External venting (how much components are (or can be) cooled by vents with the heat transferred to coolant for a fluid reactor, or completely out of the reactor (for an EU reactor)) - this can fluctuate, especially when using exchangers, but for a given reactor tick, 2x this gives the HU/t of a fluid reactor (40x to get it in HU/s).
Of these, my planner currently shows peak external venting (which might not be such a useful metric, but related to 4) out of possible external venting and max total heating (1 and 2 combined).
Here's my idea for calculating predicted values of those, which I'm hoping will match up with your manual calculations (never mind the "reliable" part for now - "reliable prediction" is kind of an oxymoron, right?
) :
1. Calculate hull and component heating.
2. Calculate hull cooling.
3. Calculate best-case exchanger transfers (i.e. ignore the possible fluctuations and take as much as the "component exchange rate" will allow from any neighbors heated during steps 1 and 2, then transfer as much as possible to any neighbors that haven't been heated)
4. Calculate external venting.
erp=N1c9dkJNpnU4/nE6kiX7ayavN00qGbuWTELKGQ20dNFgC6HAQT+3WMJyCo+8to4vnu99U5sA
2302130C000000000000230C0000000000000000000C000C00000000000C0D0C0D0C00000000000C000C000000000000000000000000|esn
This design seems to not work with the ideas too. You might have forgotten the possibility of components heated up by rods directly and then put their heat into the hull, and then cooled by components that pull heat form the hull. This would also have trouble calculating hull cooling. The reactor heat exchanger will pull heat only if its damage percentage is greater than that of the reactor.
0302130C09110D0C0A03010C0D0C0D0C0D12010C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D110D120D120D120D11|esn
For this one, there will be trouble with hull cooling. The heat exchanger at R0C5 cannot pull heat from the hull, because it is heated too much by the vents. That can be seen by replacing it with a component heat exchanger.
Some ideas about calculating “effective” vent cooling:
1. Generate a adjustable amount of heat and test for the stable one with highest possible heat generation
2.Use pulsed controls to determine heat vented (Only possible for unstable reactors unless having a negative off pulse)
3. Simulate my manual calculation (The most complicated but accurate if done correctly)
I’m leaving for now. I’m going to reply in 9 hours.
Because these are details that can be predicted ahead of time by the program (without actually running a simulation).
Then what do you call it after running a simulation? Still calling it "predictions" doesn't make sense.
Seems that example kind of turned the tables on me, though this one runs long enough that average HU/t output of it as a fluid reactor can be used for calculating an estimate of that - also, CSV data claims this design as a fluid reactor will output 360 HU/s very briefly at the moment when the left vent breaks.
That might actually be a bug, but if so, it may be quite difficult to track down, and I want to try the design in-game first (to make sure it really is a bug).Edit: Brief 360 HU/s confirmed in-game.
Since you want "a reliable, universal way to make my program do it", calculating the output of the corresponding fluid reactor won't work because it isn't universal. At the tick the vent broke, the left one vented heat and broke, while the right one kicks in because the left one can't absorb all the heat.
Until the left vent breaks (at 333 seconds), the right vent will be idle, but afterwards it will operate at full speed and give the reactor 2084 more seconds before it explodes.
Key word from my post: more. I said 2084 more seconds, because without the right vent, the reactor will explode at 1582 seconds. 3666 - 1582 = 2084.
In your original post, "afterwards" refers to the time the left vent break, which is at tick 333. Then 333 + 2084 = 2417, not anywhere close to the explosion point (tick 3166) with the right vent. In your original post, I never saw/interpreted the meaning of "without the right vent". Maybe you just forgot to say that.
I don't know what your native language is, but if there is someone else on the forum who speaks the same language, perhaps having them act as an interpreter might work better, because I'm sorry to say that this doesn't clarify anything for me.
There are some that I know of, but they aren't as active as me, and I doubt about their English skills. Having them as interpreters will slow down the conversation a lot. I just want you to be aware of my English skills, not to clarify things.
However, perhaps part of the confusion comes from ambiguity in what is meant by "venting", which the IC2 Wiki may be partly to blame for - see the below taken from https://wiki.industrial-craft.…tle=Overclocked_Heat_Vent
The heat handled by Self Venting and Component Venting is transferred to coolant for a fluid reactor (or just eliminated for an EU reactor), but the heat handled by Hull Venting is stored in the component (at least initially - some of it may be self-vented, component-vented by neighbors, or transferred by exchangers), so I dislike calling that "venting".
I have never seen that before because I go on the FTB wiki to look for component information. As for "Hull Venting", what about calling it as "Hull cooling"?
Display MoreI think I can add a "Predictions" tab with the following details:
1. Heat generated by fuel rods (split into how much is fed to the reactor vs. how much is fed to neighbors).
2. Heat pulled from the reactor by various components.
3. Theoretical maximum venting (potentially into coolant).
Actual used cooling is harder to predict (or at least I haven't thought of a reliable, universal way to make my program do it) - perhaps this example will help to demonstrate:
01000B01000B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000|esn
Until the left vent breaks (at 333 seconds), the right vent will be idle, but afterwards it will operate at full speed and give the reactor 2084 more seconds before it explodes.
Why do you call that "Predictions"?
1. What do you mean "fed to the reactor"? Do you mean raising the hull temperature? Or does it include heat fed to the reactor and then pulled out by components?
The example that you gave is caused by the reactor ticking algorithm. Since the reactor ticks from the left to the right, the left fuel rod dumps 4 heat into the reactor, and then all pulled out by the reactor heat vent. Then, the fuel rod next to it dumps 4 heat into it again, and left the right vent idle. The vent can only vent 5, so heat stacks up by 3/s.
In that case, I would say that actual used cooling is 5, with a probable exception in the tick when the left vent broke.
Also, you might have done the math wrong. "Reactor will explode at 3666 seconds." How did you get 2084 sec?
I'm not sure how it peaked at 1312 HU/t (26240 HU/s) output though (at about reactor tick 315 according to CSV data). Also note that the following components continued to have fluctuating output during the cycle: Advanced Heat Vent (R0C3), Advanced Heat Vent (R0C7), Component Heat Vent (R1C3), Component Heat Vent (R3C1), Component Heat Vent (R3C7), Component Heat Vent (R4C0), Component Heat Vent (R4C4), Component Heat Vent (R4C6), Advanced Heat Vent (R5C0), Advanced Heat Vent (R5C4), Component Heat Vent (R5C7), Advanced Heat Vent (R5C8)
Really? My CSV output didn't show that. I think the fluctuating output is caused by the component heat exchangers.
When I asked for input from "others", I kind of meant besides you.
I am aware of that, but I still replied with these examples so that I can rule out more possibilities of misunderstanding.
If I move things up and place a dual uranium fuel rod below the reactor heat vent (and use pulse configuration to make sure it stops before that vent breaks):
000000000000000000000000000000000000000000000000000000000000000C000000000000000C0B0C000000000000000200000000|epn|n3w|f2z60
The old planner shows 17 (17), matching my planner. Is that what you meant by "changing components"?
Unless you add another component heat vent to the bottom slot, that is what I meant by "changing components". To be exact, I meant that the reactor heat vent should only have passive neighbors that don't exchange/add heat to the reactor heat vent, so the problem of calculating component vent cooling in your planner can be seen better.
The second example shows 0 (148) in the old planner, and remains the same if I remove all the component heat vents, which gives me a clue where to look.
00000C0000000C0000000C0A0C000C0A0C000C0A140D0C0D140A0C000C0A140A140A0C0000000C0A0C0A0C00000000020C020C020001|esn
I believe that is a problem with the planner calculation. When I put the fuel rods in that generates 76 heat/s, the reactor heat increases by 4 heat/s, which means that it should only be able to vent 72 heat/s.
The third example shows 0 (80) in the old planner.
000000000000000000000000000C000000000000000C0D0C01000100000C0D140D0C02000000000C0D0C020002000000000C02000200|esn
That looks like a bug with the logic the old planner used to determine whether the component heat vents should be treated as having 0 vent capacity.
I added the fuel rods in, again. In your planner it showed "Total Vent Cooling (peak usages): 128.00 of 128.00", which is correct. Adding another fuel rod will cause the OC vents to exceed its maximum venting capacity and break.
On the other hand, one could argue that Talonius's planner is obsolete and shouldn't have to be matched exactly. Based on your own words: "I think the key word in Omicron's post is 'capacity'. Here, it should mean the ability of venting heat." and https://wiki.industrial-craft.…title=Component_Heat_Vent a component heat vent can reasonably be considered to have vent capacity of 4 per coolable neighbor (other vent types, exchangers, or coolant cells) - it has the "ability" to vent that much heat, even if it never uses it.
I admit that I don't know much about Talonius's planner and the versions of IC that it worked with or the reactor component behaviors at that time, so I'm not going to argue with that since I started playing IC2 in the summer of 2017. Also, my native language is not English so I am very likely to have some problems trying to explain exactly what I mean without misunderstanding. Therefore, I'm going to clarify again - to my understanding, it means the usable ability of venting heat.
Could you please upload the archived reactor planner? Somehow I can't open (download it from) that website.
Feature request: display the cooling system's total heat removal per second capacity and the fuel rod's total heat per second generation as separate values.
After some discussion in https://github.com/MauveCloud/Ic2ExpReactorPlanner/issues/36 I have realized I don't fully understand what these meant in Talonius's old planner (or maybe I did, and I've forgotten). Do others here (especially those that have looked at the source code) think my planner calculates these values appropriately? If so, how can I clarify what they mean? If not, how should they be calculated instead and why?
I think the key word in Omicron's post is "capacity". Here, it should mean the ability of venting heat.
Some of my ideas here:
000000000000000000000000000000000000000000000000000000000000000000000000000000000C000000000000000C0B0C000000|esn
This design can only vent 5 heat/s, since the reactor heat vent can and only pulls 5 every second and it can vent 5 heat that it pulled. Also, if the reactor heat vent is damaged, which is impossible without automation or changing components, then it can vent 17 heat/s until it got repaired as it is shown in the planner.
00000C0000000C0000000C0A0C000C0A0C000C0A140D0C0D140A0C000C0A140A140A0C0000000C0A0C0A0C00000000000C000C000000|esn
A more extreme example: Do you think that this can vent 260 as it is shown in the planner without changing components? For this one, the capacity of total heat removal per second is limited by its ability to pull heat - it only has 2 OC vents that can pull heat.
000000000000000000000000000C000000000000000C0D0C00000000000C0D140D0C00000000000C0D0C000000000000000C00000000|esn
In this example, the total heat removal per second capacity is limited by its ability of venting heat (not considering OC vent breaking), which (I believe) is correctly calculated at this moment.
Display MoreSo I use a pretty basic reactor setup with LZH Condensers in the 2nd 4th 6th and 8th columns with MOX Rods (Quad) In all of the other slots.
I get the reactor to 50% heat putting in one or two quad fuel rods and then i start the actual working.
It seems stable at first and the heat doesn't go up and produces ~8192 EU/tick
But if I move away from the reactor it explodes.
The same docent happen with normal fuel rods but it produces only 2800 EU/tick
Although your description is enough for me to see the problem, could you please share a screenshot of your design or the reactor code generated by MauveCloud's reactor planner so that others can see it better?
The problem is with the condensators. They can't take in heat forever and need to be repaired with lapis lazuli or with a reactor coolant injector. After the condensators disappear (break), the fuel rod will dump its heat directly into the reactor hull instead of the condensator that was there, causing it to explode.
The MOX rods generate more EU when the core temperature is higher in an EU reactor, so that you see it producing more EU than using Uranium rods.
With normal fuel rods, you just need to wait longer for it to explode since it generates less heat per fuel rod.
Also, the current reactor output is capped at 8192 EU/t. No matter how many fuel rods you put in, it can only generate a maximum of 8192 EU/t. You can measure this with an EU-reader.
I plan to take a few days break from working on the planner, but then this can be the first change to go into the next release. I am starting to see why some developers insist on one bug/feature per issue - having a bunch crammed into one issue makes it too easy to accidentally skip details like this.
Enjoy your break! You did a lot of enhancements recently.
Also, for the 1 bug/feature 1 issue thing, do you really want 20-30 issues being opened in a single day? Although it is easier to track every single one of them, it is more like spamming with good contents and I also need to open that many tabs to reply to every single one of them. I can do that separately if you want it.
Is reactor output added to the CSV output? It seems that I can't find it.
I tentatively agree with the first part of this - in 1.7.10 a simple design with 1 uranium rod and 1 heat vent shows 8 HU/s output (in the reactor gui), but in 1.12.2 is shows 160 HU/s. I was hoping for confirmation from Chocohead, but he has yet to respond in the GitHub issue. Confirmation from someone else who has knowledge of IC2's inner workings for multiple MC versions would be nice - in-game testing doesn't entirely rule out the possibility that the output was buffed while things like HU to EU conversions were nerfed to match.
I tested again in 1.7.10, and in that version 1000 mB of hot coolant generates 10000 EU with stirling generators, which is the same in 1.12.2. It might be due to a display bug that didn't got backported. In 1.12.2, the same design outputs 8 mB hot coolant/sec, so display in 1.7.10 should be wrong. It seems that Chocohead only goes on the forum every day - He has not replied to anything in IC2 bug tracker for about a week.
Display MoreSo I've got 2 reactor designs:
Fluid, 1352Hu/s at 6000+ heat, calcs to about 10,000,000 EU generated
2300120C0A120D0C0A06230C0D0C0D0C0D14230C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C140C0D0C0D0C0D0C140D140C0A120D0C140Drh1770rid01
EU, 560 EU/tick starting at 7500 Heat, shows 112,000,000 EU generated.
002300000C000C11002306230C0D0C0D0C1100230C0D0C0D0C0D0C000C0D0C0D0C0D0C000C0D0C0D0C0D0C0D0C110C000C000C000C11
I would expect 1352 Hu to give more net EU at a 75% steam cycle than a 560 EU reactor, but 1352 Hu/SEC doesn't compute to as much as 560/TICK.
I think both designs should be able to be compared. If both has expected totals, I think this would work well. I also think both should be shown with "Per Tick" or "Per sec", not each being different.
From my testing results the fluid output should be HU/t, not HU/s. I would go with "Per sec", since a tick can refer to a reactor tick (1 sec), a redstone tick (0.1 sec), or a game tick (0.05 sec).
Also, there is a Github page for the planner. Reporting bugs there is also an option.
Display MoreWhat's your max EU based on? Here's numbers for decent reactor designs, from the simulator.
If your numbers are correct and I understand your math, the EU reactor below should have no problem handling your UU regeneration.
I've got a 1-quad EU reactor that does 560 EU/tick, 112,000,000 EU generated.
002300000C000C11002306230C0D0C0D0C1100230C0D0C0D0C0D0C000C0D0C0D0C0D0C000C0D0C0D0C0D0C0D0C110C000C000C000C11
I've got a 1-quad fluid reactor that does 1352 heat/sec, 10,078,504 lifetime EU generated on steam cycle. (something wrong with calcs, this should be more than above?)
2300120C0A120D0C0A06230C0D0C0D0C0D14230C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C140C0D0C0D0C0D0C140D140C0A120D0C140Drh1770rid01
I managed to compress your first design into 4 chambers to make stacking easier, and yes that should have no problem handling UU regen.
00230C0A120D0C00002306230C0D0C0A000000230C0D0C0D120000000C0D0C0D0C0D00000C0D0C0D0C0D0C00000D140A0C0A140D0000
For the second one, I think you might have done the math wrong. The design actually outputs at 1352 * 0.75 * 20 * 10000 = 202,800,000 EU. You might have forgotten to multiply it by 20.
With that ejecting drill bug fixed, it is so much easier to design a cobble generator with miners.
I just designed one that is random tick proof:
There are 2 miners that are next to a recycler. A batbox is enough to power 2 of these combinations. The glass in the picture is optional - I just put it there to prevent fire generated by lava. I put a debug item into the bottom slot of the batbox to make it an infinite EU source.
Since this is most likely be used for scrap production, I only used normal drills and OD scanners to reduce EU cost per scrap. 1 lava source will be enough for 4 miners, but I put 2 there so that there is at least 1 cobble between the miner and the ore. I'm not certain if this is necessary.
002300000000000000230323000000000000002300000000000000002300002300000000230223230123000000002300002300000000
The three fuel rod combinations that I used for calculating its max output (in fluid reactors). I put them into one design so that it is easier to see.
Does reactors in the same chunk/subchunk tick at the same time?
What you could do though is to disable the reactor while you are inserting stuff by cutting its redstone power.
I'm trying to automate the warmup process of a MOX fluid reactor, cutting its redstone power will do the opposite thing. I managed to do that but with some minor problems.
Actually I found a way to detect when a fluid reactor ticks - I used a comparator to detect the coolant output of a fluid reactor and connecting the comparator output to a 1 sec repeater clock.
One thing that I noticed when testing this clock is that the reactor component durability changes 1 tick after the noteblock sounds, and adding a piston for 0.05s extra delay doesn't work either. I'm not sure whether this is a problem with the clock or it is a display problem with the reactor.
One question: does all reactors that are in loaded chunks and in the same dimension of the same world tick at the same time?
The idea is that I want to automate the warmup process of a fluid MOX reactor using this design. My idea is first pull out all the OC vents, then start the reactor, then after a certain amount of time put them back in. Currently the fastest way to put things into the reactor that I know without adding other mods is to use a compact item buffer with ejector upgrades, but that can't be controlled by redstone, so I have to use hoppers. However, they are very slow and I don't want to insert the OC vents in the wrong tick or something bad will probably happen. So that raises the question: how can I detect when a reactor ticks? I tried to detect the EU output of an EU reactor with a detector cable, but it seems that the detector cable lits up after a random amount of time, which is unreliable.
You should not want this
Best way of duping rods is use reactors for Advanced Miners, and even the simplest reactor design is efficient enough for this.
The "duping" way that you mentioned isn't really duping. Natural generated uranium is non-renewable, eventually you will run out of them.
I did some math and found out that it is efficient enough to dupe fuel rods using fluid reactors. I hope that I do this once and for all.
