IC2 Experimental Reactor Planner

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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"?

Quote from MauveCloud

I 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.

Display More

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?

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

Quote from MauveCloud

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.

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.

Quote from MauveCloud

I 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.

Display More

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.

Quote from MauveCloud

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

Hello,
Can anyone recommend passive Thorium reacto. (which produces exactly "408 EU/t")
erp=XOtKmioS/Gf0Pc+ZvM2yeBhH2kVjEF6tEOxlI9/elchegErSFrAG6ZgEmHR2z5JcAQ==

I'm trying to change the reactor so it doesn't not explode

Hi There,

I saw some strange behavior, when using coolant cells for cooling on different heat levels..

on the Example reactors listed in the code field, (the reactors are identical, exept for heat) use the same amount of cells on 0% and 25% heat, as well as on 50% and 75% heat.

is that an 'error' in the reactor calc, or is that the way the reactors actually work?

mox 0% heat (29.624 cells)
erp=XOtK6BxR5Vh42pJNuKiLag7Ltf6uAf/BnZdMe9FiTIDNeGJ5fq0l9nn17sNyKZJKAQ==

mox 25% heat (29.624 cells)
erp=XOtK9VQyJ6zbH1QymzsVB0qFmk56Kp++nr6a3kDvrpM2hDx/0cEHv1f17sNyKZJKAQ==

mox 50% heat (59.256 cells)
erp=XOtLAq1UJXew1VoKpSP5T+XQGlYYhznB4pUoSxd7T0CJUpAs45qcf3317sNyKZJKAQ==

Mox 75% heat (59.256 cells)
erp=XOtLD8PyrFWfqNf8YGAoQcH5Yu4Se9+4oQ03oyAKcrgIm/CMd+jLURP17sNyKZJKAQ==

Edit: the number of 'used' cells are generated, when calculated for the full 5.000.000 second run, and exchanged, when the 'damage' exeeds 9000 on the cells.

ok, my mistake..

didn't mouseover long enough for the tooltip to appear, and wasn't aware of the different mechanic, thanks

Hello.

Your reactor planner is excellent, congratulations for your work.

Do you think it'd be possible for you to "remake" Talon's older reactor planners (V2 and V3)? What I mean by remaking is to actually make them work on Linux. They are available at the following "official" links: V3 (Chocohead), V3 (Web Archive) and V2 (Web Archive). I tried using both Oracle Java 7/8 and OpenJDK 8/11 and none of them worked on Linux (the application window is barely visible and there's no way to expand it -- I could post images here about it later). I still enjoy playing on 1.2.5 and 1.6.4 and I think it'd be fun to design a few reactors myself.

In case that's not feasible at the moment, could you tell me what I have to learn in order to update those applications?

Thanks either way.

Edit: there's a slightly updated of V2 stored here.

Quote from Mandla Mwangi

Hello.

Your reactor planner is excellent, congratulations for your work.

Do you think it'd be possible for you to "remake" Talon's older reactor planners (V2 and V3)? What I mean by remaking is to actually make them work on Linux. They are available at the following "official" links: V3 (Chocohead), V3 (Web Archive) and V2 (Web Archive). I tried using both Oracle Java 7/8 and OpenJDK 8/11 and none of them worked on Linux (the application window is barely visible and there's no way to expand it -- I could post images here about it later). I still enjoy playing on 1.2.5 and 1.6.4 and I think it'd be fun to design a few reactors myself.

In case that's not feasible at the moment, could you tell me what I have to learn in order to update those applications?

Thanks either way.

Edit: there's a slightly updated of V2 stored here.

Display More

I ran into the same problem. To fix it, I de-compiled the V3 planner back into Java files using Krakatau (JD-GUI produced java riddled with a thousand errors so I used Krakatau instead), modified the Java files to fix the display issue (in addition to fixing some mistakes made by Krakatau so that it would compile and run without error), and re-compiled it back into a .jar file. I've made the resulting jar file available here.

Edit: Unfortunately, the file will no longer be available through my google drive so someone else will have to re-upload it to here if they have a copy of it or follow my procedure to create it again and post it here. If you choose to recreate the file, it might be better to use a Java byte-code editor as you simply need to change one byte since the problem is that somewhere in there is a function call roughly along the lines of "Window.IsResizable(false)" which needs to be changed to "true" to make it work on Linux.

Well it's been almost exactly a year since my last post, but I decided to edit the bytecode like i suggested last time and the new file is available here on github.