Campaign for Real ElectricCharge

[damerell]

I'm back after a few years away and wondering about something that's been bugging me for a while. The apparent value of a unit of ElectricCharge varies wildly depending on what kind of part one looks at. I was thinking of doing a mod with a ModuleManager rune that would adjust (eg) all parts' energy storage by a like factor so if they were balanced relative to stock parts, they would remain balanced in that way. (Then, presumably, it would turn out to break some specific mod parts which would need special treatment).

So, we ask ourselves, how much is a unit of ElectricCharge? (In particular, I bet there is at least one hilarious error in what follows - point it out to me?)

Solar energy flux near Earth (and hence near Kerbin?) is circa 1400W/m^2; 30% efficiency would give us 400W/m^2. However, the ISS's arrays produce 100W/m^2 when it is not eclipsed. An OX-STAT is 0.3*0.5m and puts out 0.35 EC/s; that would make a unit of EC between circa 40J and 170J.

This implies that probe cores draw somewhere between 1 and 5 W (not counting torque). This doesn't seem implausible - it's in Raspberry Pi territory, say. Presumably most of the volume is reaction wheels and leftover Snacks wrappers.

Let's pretend a unit of EC is 100J, somewhere in the middle. But round batteries have an energy density of 4 EC/kg. That's... 2kJ/kg. This is quite low compared to, say, a Tesla 85kWh (sigh units) battery which holds 560kJ/kg! (Lithium thionyl chloride batteries, actually used in aerospace, do better, but it's not a rechargable chemistry). Let's be generous and say kerbals engineer really superb solar panels and so a unit of EC on the solar scale is _200J_; now round batteries do 4kJ/kg. We would need to multiply up battery capacities by a hundred to get them into the same general efficency range as solar. Conversely, battery weights want one EC to be around 20kJ... but then that probe core draws 500W!

Aerospace fuel cells provide c. 500 W/kg. A KSP fuel cell array (different chemistry, mind) provides 0.075 EC/s/kg. This would make an EC around 6.6 kJ - closer to the battery scale.

A SNAP-27 RTG as used on the Apollo missions provided about 3.3 W/kg (and this is not an atypical figure). A PB-NUK provides about 0.01 EC/s/kg, suggesting an EC is about 3kJ. Not a bad deal compared to the fuel cells, especially given you never have to refuel it.

A USILS kerbal uses 0.01 EC/s for their life support needs. On the solar scale, that's 2W - pretty generous for an astronaut. On the battery scale, it's a perhaps more plausible 200W. (TACLS used 1 EC = 1kJ and on that scale a kerbal uses circa 20W with TACLS consumption, 10W with USILS). Humans are bigger than kerbals, and Skylab seems to have used circa 400W per astronaut over and above its uncrewed power consumption, so that's at least in the right ballpark.

So, any errors in that, and any thoughts on which direction the adjustment should be done? There is something to be said for adjusting everything towards the 1kJ = 1EC convention which at least some modders have used.

[damerell]

It struck me on the way home that for many purposes, the power to mass ratio of a solar panel is what matters, even if the area looks funny. It is also quite hard to find figures on the mass of solar panels, but each ISS "wing" is around 1,100kg (and is 1/8 of the overall output) for 27 W/kg. A Gigantor produces 0.08 EC/s/kg. This would make an EC around 340J. However, I think I'm willing to say that the ISS solar array (which also has a low output compared to what you'd expect from a naive assessment of its size, solar flux, and typical efficiency) is more robust than a Gigantor (which, after all, shatters into a million pieces if you look at it funny) and the power/mass ratio isn't a total outlier compared to the power/area ratio.

[Nertea]

As someone who does probably the most electric stuff with KSP... yeah it's totally out to lunch in stock. One data point you did miss out on is the Dawn engine, which uses about 8.5 Ec/s, and supposedly maps to the NSTAR engine which runs at 2.1 kW (it's named Dawn after all). That gives you a 1 EC = ~250J number. 

No single part category really maps logically to another category. Pick a standard, easy number (1 kJ = 1 EC is the obvious choice in my mind) and rebalance around that. 

 

[damerell]

I forgot about ion engines, yes, thanks.

The other thing that might be interesting to look at is reaction wheels - now obviously they're a bit magic, and worse yet on larger vessels IRL you have CMGs (but perhaps the way the large wheel uses less EC per unit torque touches on that) - but at a very brief glimpse, IRL reaction wheels pull somewhere between about 10 and 50 W per kg. The small wheel can use 0.75 EC/s, the medium one 1.35 EC/s, and the large one 1.80; between 0.009 and 0.015 EC/s/kg. This gives us anywhere between 660J and 5.5kJ per EC. Given that reaction wheels are magic anyway, I'm inclined to say "this doesn't contradict 1 EC = 1 kJ" and leave dealing with their magical effects to other modders. (In practice, I don't fit reaction wheels and set the ones that come built in to other parts to "SAS only", to require me to use RCS more prototypically).

(Other things to consider: LFO engine alternators. Stock wheels, probably with a view to just reviewing the old Kerbal Foundries configs for them.)

Edited September 12, 2020 by damerell

[Nertea]

If you're curious, the old ion engine used somewhere around 2.2 EC/s, which would map nicely to 1 EC = 1kJ, which is where the original conversion value on my mods came from.

[damerell]

I had the time to have a crack at this tonight, and wrote the wall of text below while writing a ModuleManager file; this takes care of my most immediate need, launching comsats in my current game with plausible solar / RTG performance.

(But no; there's actually a problem with dish performance. A RemoteTech Reflectron GX-128 pulls 2.8 EC/s just to tick over; stock antennae want between 20 and 200 EC/s to transmit data. If these are kW, this looks odd in view of the way that, say, Voyager 1's RTGs only put out 470W at launch and we can still talk to it now. RemoteTech's root range model doesn't help much (stick a powerful antenna on Kerbin and a less powerful one on the ship), both because they cap out at the GX-128 (there isn't a super-powerful antenna to talk to weak ones at Eeloo) and because Kerbin has no ground-based electricity infrastructure other than at the KSC. I might just have to say, well, kerbals are bad at antennae, deal with it.)

A pretty fundamental question here is whether we try and look at the
part's actual mass - but that will break for any two-in-one part like
kerballed command modules, so it's a non-starter; so we have to just
multiply or divide the existing performance. This will, vexingly,
break mods which already have adopted the 1EC = 1kJ convention.
Worse yet will be mods which mix that convention with other parts
with stockalike performance.

Solar - seems like we can scale the lot, factor of 6 selected.

EC capacity
Battery capacities want multiplied up by 20.
Bit of a wrinkle in that for control parts, I might like not to change
their built-in endurance and ability to use reaction wheels; I
intentionally are not going to address RW balance, but giving probe
cores 20x the EC kind of does change it. On the other hand, not
multiplying up risks an inadvertent nerf to parts like the HECS2
which contain a significant mass of battery. I think best to err on the
side of caution (and also before you could just stick on an OX-STAT and
run the wheel forever) which also spares me writing a giant rune about
_which_ part to edit.

Of course there's a gotcha here that fuel switching mods won't know
about this. Mind you, many of them don't increase mass much or at all -
EC doesn't weigh anything, but batteries to put it in certainly do!

RTGs:
We think an RTG is any part with a ModuleGenerator making EC with no
input resource and no other output resource. (This also does the
launch clamp; who cares?)

Fuel cells are a bit more complex because we will want not just a
sensible EC/mass ratio, but a sensible input amount of LF/O. A base
fuel cell uses 0.01875 kg of LF+O every second to make what will be,
once we multiply it up, 9 kW power. It is surprisingly hard to find a
figure for the energy density of RP-1 + LOX, but kerosene is 43 MJ/kg,
which at 2.3 oxidiser to fuel ratio (as in the F-1) gives 13 MJ/kg.

(Of course we are stretching here because KSP's LF/O ratio isn't
anything like that, but we need _a_ real-world analogy. The other
approach would be to use KSP's LF/O ratio, but that would produce
an even bigger adjustment to mass flow!)

Fuel cells are about 50% efficient (the alkaline chemistry ones used
in aerospace are better, but then they're working off H2/O2, not
somehow magicing kerosone into electricity without combustion).
This would warrant a consumption of... huh, 0.0014 kg/s. Fuel cells
are going to be a lot more viable in CAMREC, consuming 1/13 the amount
of fuel.

This also runs me into my first mod compatibility problem - On-Demand
Fuel Cells. Oddly, ODFC _already_ changes fuel cell performance -
quite dramatically, with a LF/O ratio closer to RP-1/LOX than KSP LF/O.
Sigh.

Where the standard fuel cell produces 1.5 EC/s, the ODFC one produces
5 EC/s, consuming 0.104525 kg/s of LFO, 0.02 kg/s monoprop,
9.4 * 10^-5 kg/s hydrogen and 0.0011 kg/s oxygen (and producing 0.00084
kg/s of water), or 0.002 kg/s LF if IntakeAir is available.

These are odd figures to reconcile (for example, the energy density of
monoprop is better than LFO, the energy density of hydrogen is amazing,
about half the mass used in the H2/O2 cycle disappears, for some reason
having IntakeAir available makes your LF go further) so I think they
have to be rewritten.

The LF/O process now produces the same numbers as CAMREC without ODFC.
The monoprop process has reduced efficiency (J/kg) by a factor of about
2, and reduced peak output (which conveniently keeps the 0.5 EC/s ODFC
adds to pods intact if they run on monoprop). The LF/IntakeAir process
is like the LF/O one except it wants more air because air mostly isn't
oxygen. The CRP H2/O2 process is based on the circa 130MJ/kg energy
value of hydrogen and the circa 60% efficiency of aerospace H2/O2 fuel
cells.

1kW output needs circa 1.3 * 10^-5 kg/s hydrogen, and 4x that mass of
oxygen. 90% of the mass emerges as water (there's a reason fuel cells
and electrolysers don't make good long-term energy storage). I'm kind
of curious as to why it uses Hydrogen not LqdHydrogen but presumably
in a RealFuels world there's a way to warm the stuff up before you
use it. 0.143 units /s for 1 kW, and 0.0364 units of oxygen. (Oxygen
is much denser in the CRP than hydrogen).

Also I totally confused myself here with the way resource densities
are shown in _tonnes_ per unit, but I think I have it all right now.
As a brief test I launched a vessel with 2 H2/O2 arrays, an empty
80MJ battery, and Universal Storage hydrogen, oxygen, and (empty)
water tanks. It should take about 6-700 seconds to fill the battery,
and it does; and if I deploy a much larger version of it, the total
vessel mass decreases by 1kg when it's made about 10kg of water,
which is the loss figure I was looking for.

An obvious downside here is that I might have turned electrolysers
into perpetual motion machines, at least until the water runs out.
A brief look at the US Elektron says I haven't, but its output
numbers are funny, perhaps because it doesn't account for the relative
density of H2 and O2.

So what's next? This is enough to let me do the next thing in my
current game, but on the list are the US Elektron (because I know
it's wrong), Kerbal Foundries (which just has a large fudge factor
to make driving on batteries even vaguely possible), Karbelectic
generators, ion drives (since Nertea mentions they are wrong),
USI nuclear reactors (and I think there's one apiece in the Mk2/Mk3
Expansions), and radiators - those being the parts I want to work
plausibly later in the current game.

[damerell]

I've posted a new version of the Module Manager config using some help from the MM thread, and which gives more realistic (high!) power requirements for Kerbal Foundries and stock wheels.

However, I've run into the first real tangle. IRL, the NSTAR uses 2.1kW for 92 mN thrust. The KSP Dawn uses 8.74EC/s for 2kN thrust. If the thrust isn't adjusted, the electricity requirement will be enormous (ie, circa 40 _MW_), but if the thrust is adjusted, first of all I'm stepping outside my remit of just correcting EC usage and not worrying about parts like reaction wheels that do the impossible with it, and secondly ion burns will take weeks. (Indeed, if solar powers that 40MW engine, the burn will take weeks anyway...)

I guess:

1. if Persistent Thrust is installed, give the engine a realistic TMR and EC usage. It will only be useful with Persistent Thrust. No ion-powered aircraft or sticking rovers to Gilly with ions.
2. If Persistent Thrust is not installed, since the Dawn masses almost exactly 10x as much as the NSTAR (with PPU, etc), increase the Dawn's EC draw by 10. This gives the "right" answer in terms of necessary solar/RTG capacity to run it, but gives you a lot of free thrust if you are, say, using a fuel cell to run it (where this is not a remotely practical option IRL).

But I could say, well, even step 1 is outside my remit, and it'll just cause annoyance while eliminating some options which, while unrealistic, aren't unrealistic in terms of EC usage.

[damerell]

I hit on a better approach; rewrite ion engines as multimodes, with "Accelerated" (realistic EC/s, unrealistic thrust) and "Realistic" (realistic EC/s and thrust) modes, with the default being "Accelerated" to minimise user surprise.

[linuxgurugamer]

Why not only work on stock parts for right now, get them working and balanced properly, and then worry about mods.

 Given the way the game has developed and mods have been written, you're not going to have all mods be compatible. But since the commonality of everything is stock parts, I figured it might be better to see get them fully balanced and making sense and then to move on to mods.

Edited October 23, 2020 by linuxgurugamer

[damerell]

2 hours ago, linuxgurugamer said:

Why not only work on stock parts for right now, get them working and balanced properly, and then worry about mods.

I'm not sure if you mean "why are you writing rules for specific mods?" or "why are you writing generic rules which will edit any part with a given function, rather than explicitly naming stock parts for conversion?"

The answer to the first question is I'm writing the mod I want to use; since I use Kerbal Foundries, ODFC, and Universal Storage (for example), I'm writing configuration to handle those parts. The order in which I'm doing things reflects what I'm trying to get done in my current game; I wrote the KSPWheel rebalancing bit before the ion engine bit because I'm building big rovers not tiny high-dV probes. Also, since this is my first nontrivial use of Module Manager, I've been doing things I do know how to do while hoping to get advice on things I don't.

The answer to the second question is that it's less work, and these generic rules naturally work on parts with stockalike balance, which I think the majority of mods out there try for. For example, "Hangar" hangars incorporate EC storage, solar generation, and ex nihilo EC generation representing RTGs, and their mass and cost is intended to partly reflect the mass and cost you'd otherwise have to bring in batteries, panels, and RTGs - saving part count, but nothing else. After CAMREC edits those hangars, they're still balanced relative to bringing CAMREC batteries, panels, and RTGs.

(Also, at least until I think of something else, radiators are the only stock part category I plan to address and haven't yet...)

Edited October 23, 2020 by damerell

[linuxgurugamer]

3 minutes ago, damerell said:

I'm not sure if you mean "why are you writing rules for specific mods?" or "why are you writing generic rules which will edit any part with a given function, rather than explicitly naming stock parts for conversion?"

The answer to the first question is I'm writing the mod I want to use; since I use Kerbal Foundries, ODFC, and Universal Storage (for example), I'm writing configuration to handle those parts. The order in which I'm doing things reflects what I'm trying to get done in my current game; I wrote the KSPWheel rebalancing bit before the ion engine bit because I'm building big rovers not tiny high-dV probes. Also, since this is my first nontrivial use of Module Manager, I've been doing things I do know how to do while hoping to get advice on things I don't.

The answer to the second question is that it's less work, and these generic rules naturally work on parts with stockalike balance, which I think the majority of mods out there try for. For example, "Hangar" hangars incorporate EC storage, solar generation, and ex nihilo EC generation representing RTGs, and their mass and cost is intended to partly reflect the mass and cost you'd otherwise have to bring in batteries, panels, and RTGs - saving part count, but nothing else. After CAMREC edits those hangars, they're still balanced relative to bringing CAMREC batteries, panels, and RTGs.

(Also, at least until I think of something else, radiators are the only stock part category I plan to address and haven't yet...)

Ah, the trouble of answering a post with a phone.

I wasn't critisizing, just suggesting.  Most mods are made because someone want's something which isn't there, and you fit right in that category.

Since you have specific mods you want to work with, of course you should include those.  And generic rules are MUCH better than specific rules.  I meant that write your generic rules against the stock parts, when they work well for the stock parts, they should also work for mod parts.  Since stock parts are in every game, it would have wide appeal to other players.

I am looking forward to seeing what you come up with.

[damerell]

30 minutes ago, linuxgurugamer said:

I wasn't critisizing, just suggesting.  Most mods are made because someone want's something which isn't there, and you fit right in that category

Oh, I didn't read it as criticism, just as a straightforward suggestion.

While I'm here:

Russian RITM-200 icebreaker power plant: 175MW/1100 tonnes = 160 W/kg.

USI 0.625m nuclear power plant: 190 W/kg (@ 1EC = 1 kJ)

USI 3.75m nuclear power plant: 180 W/kg.

I guess I can leave those alone.

 

[GuessingEveryDay]

On 9/11/2020 at 3:20 PM, damerell said:

85kWh (sigh units)

Just use Mark Watney's "pirate-ninjas". 

 

Edited October 24, 2020 by GuessingEveryDay

[damerell]

On 10/24/2020 at 2:10 AM, GuessingEveryDay said:

Just use Mark Watney's "pirate-ninjas". 

I suppose given he's American we should be grateful he doesn't think in BTUs or something. :-/

[xD-FireStriker]

I can’t wait to see where this goes 

[damerell]

On 11/3/2020 at 3:16 PM, xD-FireStriker said:

I can’t wait to see where this goes 

It's kind of you to say so, but I'm not sure there is much left to be done (one or two things) until release and (if anyone else uses it) thinking about mod parts that it doesn't play nice with. Progress is kind of limited by me being too lazy to do anything about it unless my current in-game objectives need a particular kind of part's EC usage looked at.

[damerell]

FWIW, this isn't dead, just resting. I'm likely to get a significantly faster CPU in the next few months, so I'm not playing KSP until it turns up.

[damerell]

Well, after a year here we are again. LFO alternators were one of the things on my list, complicated by the fact that they're something kerbal rocket engines have and ours - by and large - don't. However, the LV-T45 has one of the best electricity/fuel flow ratios, and is putting out 6kW at one EC = 1kJ. It consumes 68 kg/s which at the 13 MJ/kg LF/O energy density back-of-enveloped above is about 900MW, so the alternator is spitting out 1/1500 of the energy the engine is burning up. I think it's fair to say engine alternators aren't implausibly good and can just be left alone. Hooray!

[damerell]

Radiators: it's hard to know what to make of the fixed radiators given they all use the same amount of electricity (and a non-zero amount so they're not completely passive). Also, let's assume the important statistic with stock radiators is Core Heat Transfer since that's 95% of what they get used for; Nertea has mods for a better treatment of heat but fix stock first.

Hence the fixed radiators dissipate between 2000kJ and 8000kJ of heat for each input kJ electricity; the nonfixed ones all do 2000. The corresponding factor for the ISS's old cooling system is around 13 (vexingly, I can't find out what the Pump Modules on the current system pull).

However, something is janky in KSP to begin with (once we have 1 EC = 1kJ) because, eg, the Drill-O-Matic pulls in 15 EC/s to generate 100kW waste heat. (This makes its input-power-to-weight ratio 12 kW/tonne and output-heat-to-weight ratio 80 kW/tonne; it is difficult to know what's a plausible figure here since RL electric mining machines are miner and motive unit combined, but eg a Wirtgen 200M comes in at very roughly 20kW/tonne).

This wants some thought.

 

ETA: much of the trouble here is that stock ISRU (which again is 95% of what radiators _do_) is overall absurdly good; it's quite often possible to power your ISRU by burning what you dug up and refined, which is pretty unlikely to work on planets without a lot of dead dinosaurs lying around. And I made fuel cells _better_. So, conclusion, re-examine own fuel cell numbers just in case, and think again.

Edited March 17, 2022 by damerell

[damerell]

Coming at this from another angle; the stock heat mechanic is a bit of a bodge just to add difficulty to using drills, but is it really true that ISRU can be over-unity?

The maximum Ore concentration is around 15%. The temperature and engineer quality affect output and EC consumption equally, so we can ignore those; so a single Drill-O-Matic might pull up 0.225 Ore/sec for 15 EC/sec. (On an asteroid, it might pull up almost 500 Ore/sec. Sigh.) That's 0.015 Ore/EC; 33 Ore/EC on an asteroid. Take the inverse; it takes 67 EC to get a unit of Ore on the best planet; 0.3 EC to get a unit of Ore on the best asteroid.

That Drill-O-Matic's cooling wants a trivial amount of EC so we won't worry about that right now.

A Convert-O-Tron will turn 1 unit of ore and 60 EC into 0.9 LF (and the corresponding volume of O) or into 2 units of monoprop, so the total cost to mine and convert one unit of Ore is circa 130 EC (planet) or 60 EC (asteroid). (The C-O-T's cooling cost is also trivial).

A stock fuel cell will consume that 0.9 LF in 540 seconds generating 810 EC. Over unity is very definitely possible, even without going near any asteroids, and even without the CAMREC fuel cell buff.

This is going to be a colossal nerf. If, say, the Drill-O-Matic was raised to 150 EC/s and the C-O-T to 250 (so both parts at least consumed as much electricity as their heat output), you'd still only be putting in about one MW to get 60MW of fuel cell output out.

One problem here is that a realistic profile for an ISRU mission is (a la _The Martian_) to drop a lander for years which will then burn up the resulting LF/O in minutes. That's not very like what one does in KSP.

Edited May 2, 2022 by damerell

[damerell]

There's a nerf of a factor of about 1000 to find (810kW out * 6 * 13 (CAMREC fuel cell buff) / 60 kw (minimum EC input for one Ore/sec)), or perhaps 500 if we accept asteroids might be a bit magic. This could be applied in three places; Convert-O-Tron input (but equally it can hardly be pulling in 25MW electricity to put out 250kW heat), to Convert-O-Tron output (good because at the moment you can turn about 10kg of stuff you dug up into 5kg of rocket fuel and oxidiser, which would be pretty amazing even on a planet that _is_ full of dead dinosaurs; arguably bad because it breaks "mine Ore here, move it some distance, convert it there" but that was already a bad plan in stock) or to drill output. Changing drill output would either have a knockon effect on mod production chains that don't involve EC production (bad) or produce a puzzling situation where Ore is somehow enormously harder to dig up than anything else.

Another advantage of adding only a relatively small nerf to input is that solar-powered drill+conversion rigs remain feasible. Difficult (but that's the point of CAMREC) and you'll probably end up TweakScaling up Gigantors, but feasible; instead conversion will just take a really long time, making it more of a tool for long-term operations than a matter of landing somewhere and refuelling by picking up rocks.

Drills also pose a bit of a problem in that their EC input falls with efficiency but their heat output doesn't, but unlike the C-O-T there's no lower limit, so they'll always raise the spectre of a part putting out more heat than the inflow of electricity. I think there comes a point where I shrug my shoulders and say, heat is a bit of a bodge mechanic anyway, particularly since there's no obvious way I can address that short of writing my own replacement for ModuleResourceHarvester.

So, a proposal. Increase the EC requirements of active radiators by a factor of 10. This doesn't really help balance ISRU but it does reduce a seemingly absurdly high number. Passive radiators we can leave alone.

Increase the Drill-O-Matic to 150 EC/s. On a planet you now pay about 666EC for an Ore. Increase the C-O-T to 250 EC/s. You now pay about 500EC to convert that Ore. Decrease C-O-T output per input Ore by a factor of 75. I think this makes over-unity operation on a planet impossible, and on an asteroid a matter of enormous luck in picking your asteroid (and maybe some of them are just big blobs of hydrocarbons, who knows?)

[damerell]

Wheels: a bit of runway testing suggests the KF wheels are suspiciously efficient but we don't actually get more kinetic energy out than electric energy in. Stock wheels are all over the shop (eg I can be cracking along in an Akita rover at top speed and it's barely using any EC at all) and I suspect the answer is to recommend KF and dig up the old KF configs for stock wheels.

There is a bit of a problem here in that kerballed rovers are heavy. The Lunar Rover IRL was 210kg and could carry 490kg of payload, including two human-sized humans, and was an actual recognisable vehicle. If I bolt four Rovemax S2s, a battery, and an external seat to a structural panel, I'm already over 400kg without _any_ payload. An Akita, USI's adorable "small" rover, weighs 650kg by the point you've got four wheels and a seat on it - 490 if you jettison the monoprop, but 714 with a battery and an RTG to make a vehicle you can actually drive anywhere. It seems a bit harsh to have realistic EC usage when you can't build a realistically light rover.