Jump to content

[1.1.3] JDiminishingRTG v1.4.0 : Realistic, configurable radioisotope decay! [8 Jul 2016]


KwirkyJ

Recommended Posts

im not sure about using this, for a couple of facts.... like, what would i use for long-term power? i guess solar panels and batterys, big ones would work.... but one mod, SSTU labs, has a lander fuel tank part that can have a RTG as one of its configurations, and because of how its implimented, might not get picked up by the recently posted MM config... and i know this is a slight bump, but, hey. also, LLL adds in a salt reactor that generates EC out of nothing, and that would probably get detected by the MM patch. does the MM patch tune the output of converted-rtgs based on there original output? i might use it, but im not sure what repercussions it would have on how i play..

The patch I posted should hit exactly parts that have a Module Generator that produces electric charge and has not inputs. If the salt generator is using a custom module, or is using the stock module generator and has any input [ie it is consuming the molten salt], then my patch will not touch it.

The volume of radioactive material the DiminishingRTG config will have is based in the mass of the part, basically it assumes the stock RTG's DiminishingRTG config as a baseline, and scales that by the ratio of the part-being-modified's mass as compared to the stock RTG.

The efficiency is calculated in the same way, by comparing the output of the stock Module Generator in the target part to the Stock RTG, and then scaling the stock RTG's DiminishingRTG module's efficiency by that.

Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...

Hello,

Ok...lots of tekky talk here...kool !

I never expected to have to modify cfg files in KSP when I started; then getting into resources and realism...gads...there is a rabbit hole here, and more than one it seems !

I like the concept of an RTG.

I do not use DRE why should I if the game already implements it?

Hopefully some functions can be manipulated to get upgraded parts further down the Tech Tree; I have to make multiple parts to do it; I think there is a way to avoid that in the cfg files; I am not sure how to do upgrade parts to keep from ahving multiple texture files; another to do list of mine.

Is the 10x fixed?

I am looking into overheat checking but that is on my backburner as my processes stop if an input is not present (I use seperate heating and coolant units whenever I get those MODS working again ugh).

Commander Zeta

Link to comment
Share on other sites

  • 4 weeks later...
  • 2 months later...
  • 1 month later...
  • 4 weeks later...
On Friday, July 08, 2016 at 10:58 AM, KwirkyJ said:

Update to KSP 1.1.3 compatibility (version 1.4.0). Should be stable, but feedback would be appreciated. Known bug regarding symmetry parts resetting when detaching/reattaching.

 

Download HERE

you just made my weekend!

Link to comment
Share on other sites

  • 2 weeks later...
On 08/07/2016 at 2:58 PM, KwirkyJ said:

Update to KSP 1.1.3 compatibility (version 1.4.0). Should be stable, but feedback would be appreciated. Known bug regarding symmetry parts resetting when detaching/reattaching.

About the feedback you asked, so far so good! Thanks, once again!

I have a doubt though: I started using Modular Rocket Systems and its RTG, converted to decaying mode by @ABZB's MM patch, got a bit unrealistic, as far as I can tell: I think its generating too much power. Is that MM patch correctly balanced? If not, what changes should I do to your MM patches to do balance them to it?

EDIT: I've made some calculations (I considered the mass of both RTG as the parameter for comparison) and I think pwer generation is actually quite equivalent. My biggest concerns are related to the MaxAmount of generated power. JDiminishingRTG sets Squad's RTG MaxAmount to 1, while ABZB's MM patch changes MRS RTG to 6250!

Which one is correct? I mean, should the MaxAmount power be limited to 1 (since the RTG is not a battery) or should it be increased since 1 is for smaller generation and on a bigger RTG would mean lost of generated power?

 

Edited by jlcarneiro
Link to comment
Share on other sites

  • 2 weeks later...

@jlcarneiro:

Not to speak out of turn, but my guess is that you want the RTG to have EC capacity equivalent to what it generates over a single physics/resource calculation tick.  Then the EC it generates will be moved to the real batteries before it starts 'spilling over the side' or whatever it is that excess EC does.  For most purposes, 1 EC is more than enough for this.

 

 

On a completely unrelated note, because it was something that people have been bringing up in this thread, I thought to break out the slide rule and look at the relative power generation for each of these fuels, as well as consider the mission viability cases for RTGs given their ultimate mortality.  I'd like to share what I've learned so far.

I can't know what anyone will build or how much electricity it will consume, so for a cutoff point, I chose the utter minimum of power a probe needs to remain active: the power required by the core itself.  The idea is that as power generation drops off, you can shut off various instruments a la Voyager 1 and still have an active core, but, unlike Voyager 1, use any excess to build up battery charge to use intermittently.  However, once the RTG produces less EC than the core consumes, the probe is running on borrowed time and will die as soon as the batteries run out.

To extend the time, one may always add more RTGs, but just as the EC they produce, this comes with diminishing returns.  It's a wheat-and-chessboard problem:  one extra RTG buys one additional half-life of time.  To get another half-life, you need two RTGs.  To get another, four RTGs.  To extend the time by n half-lives, you need to add 2n RTGs.  This gets irrationally expensive for something with a definite expiration date.

I used five probe cores as example cases and determined the maximum time they could operate on one RTG.  This covers the full range of power requirements (and SAS capabilities) but does not specifically address the RoveMate or the Stayputnik.  I left these out because the RoveMate is a special-service core that also uses exactly half the power of the RC-L01 (so it will always last exactly one half-life longer, regardless of fuel type or number of RTGs), and the Stayputnik is an entry-level core that is quickly surpassed.

Values are reported to the day, rounded down:  in other words, the RTG will last at least that long, plus possibly a few hours.

RC-L01:

This is the biggest core, with the largest power draw at 4.8 EC/min.  It is of special note because it is the default remote-command core to reduce signal delay for RemoteTech, and therefore may well find service out near Eeloo on long-term missions.  It lasted the longest with Kitsunium238, coming in at 7 years, 146 days.  Therefore, it can go to Eeloo (a roughly four-year trip), but it won't come back.  It can return from Jool (only a three-year trip), but that limits the mission time.  By comparison, Kuudite241 clocked out at 6 years, 394 days.  This is the only core where Kuudite241 didn't win, and it has to do with the L01 being so power-hungry:  the superior power density of Kitsunium238 won out over the longer half-life of Kuudite241--but only for a single RTG.  Extra RTGs add time according to half-lives, not years, so a second Kuudite241 adds 6.3 years compared to Kitsunium's 2.3.

HECS2:

This also represents the RC-001S and the Mk. 2 Drone Core.  All of these run at 3.0 EC/min, and these are also the rest of the cores with full SAS capability.  Each lasts 11 years, 92 days on a single Kuudite241 RTG.

OKTO2:

This is the only level 2 SAS (Normal/Radial hold) core; it requires 1.8 EC/min.  It lasts 15 years, 376 days on one Kuudite241.

QBE:

This also represents the HECS; they require 1.5 EC/min and last 17 years, 233 days on one Kuudite241.

OKTO:

This is power-wise the cheapest of all cores to run and requires 1.2 EC/min.  It lasts 19 years, 249 days on a single Kuudite241.  It also has level 1 SAS (Prograde/Retrograde hold), so this may be a reasonable mission choice if there are no complicated astrobatics and your primary concern is long-term power.

 

I've got data on comparisons of fuel types for different applications, some stuff comparing these to different sorts of solar panel, and special use cases for each (for example, there is a compelling reason to send RTGs to Moho!).  But I don't want to drown/comandeer the thread.  If anyone wants to see more, please say so and I'll post the rest.  Otherwise, I'll quietly shrink back into the shadows--but I'll be fine there; I'm taking my RTGs.

Edited by Zhetaan
Editing pass for clarity
Link to comment
Share on other sites

Thanks, @Zhetaan! Nice detailed work!

About, my question, so I should alter @ABZB's MM patch altering the part related to amount and maxAmount keeping them equal to 1, right?

If so, I think it would become something like this (I added the [!launchClamp*] part because the Launch Clamps were being activated automatically):

//hits all parts with module generator that has no inputs and outputs EC. runs on the final pass to avoid parts with specific configs
@PART[!launchClamp*]:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE[ElectricCharge],!INPUT_RESOURCE[*]],!MODULE[ModuleDiminishingRTG]]:FINAL
{
    @description = By exploiting the 'natural' decay of radiological isotopes, electrical power can be generated for prolonged durations—indeed, indefinitely, but the output tends to fall off over time. Accountants have also noted that different 'hot rocks' are hotter or cooler than others and tend to cool down a different rates, with the two aspects not necessarily being related.

    //scale everything according to mass of stock RTG config (0.08)
    MODULE
    {
        name = ModuleDiminishingRTG
        efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge 
        volume = 7 // roughly, in deciliters. ("units")
        @volume /= 0.08
        @volume *= #$../mass$

        //scale efficiency compared to the stock RTG electric output
        @efficiency /= 0.75
        @efficiency *= #$../MODULE[ModuleGenerator]/OUTPUT_RESOURCE[ElectricCharge]/rate$
    }
    //use the replace-if-not-create to avoid duplicate resource node
    %RESOURCE[ElectricCharge]
    {
        %isTweakable = true
        @amount = 1
        @maxAmount = 1
    }
    !MODULE[ModuleGenerator]{}
}

About your offer, I think this thread has been too quiet lately, but I would like to be enlightened, if you don't mind... :wink:

Edited by jlcarneiro
Link to comment
Share on other sites

Cool!  The next part is less formula-driven and written more as an informal technical manual.

 

Choosing a Fuel:

Mission times:

Short-term missions are those shorter than 42.6 days (1/10th of a Kerbin year).  Medium-length missions are those missions from 42.6 days (1/10th of a Kerbin year) to 1278 days (3 Kerbin years).  Long-term missions are anything longer than that.  These definitions would include both round-trip and one-way missions; the important part is that the objectives be completed within the available time.  For this purpose, return to Kerbin can count as an objective--and an important one, if the rest of the mission is shortened to accommodate it.

I defined the mission lengths somewhat arbitrarily, but they correspond well to the possible destinations that you can reach in the allotted time.  Short-term missions cover anything you want to do in the Kerbin sphere of influence, save the most ambitious moon-base and harvesting operations, but allow no time to do much outside Kerbin's sphere of influence.  Medium-length missions cover interplanetary journeys to and from Eve and Duna and the majority of asteroid missions, but nothing farther away.  Long-term missions, naturally, cover everywhere else, but they may appear in longer-term missions that are closer to home.

 

Fuel types:

Kitsunium238:

This is a good high-output fuel for all medium-length missions and the shorter long-term missions.  In terms of numbers, given the same number of RTG units, Kyandere210's output drops below Kitsunium238's output at 69 days, 5 hours.  Kitsunium238 continues as the highest producer until 7 years, 247 days, 3 hours, when Kuudite241 finally overtakes it.

The fact that Kyandere210 is a higher producer for the first twenty days of medium-length missions does not invalidate Kitsunium238's claim to be the better fuel.  Although my mission-length definitions are arbitrary and it is important to note that Kyandere210 does not simply shut off at the 70-day mark, in light of the half-lives (and attendant power curves) involved, any mission much longer than 42 days would benefit from a longer-lasting RTG fuel.  However, nothing prevents you from using whichever RTG fuel you wish.

Kuudite241:

Kuudite241 is the fuel of choice for long-term missions.  For missions longer than twelve years, it is the only single-RTG solution that can keep a probe core alive for that long (for reference, the next-best choice cannot power an OKTO past 11 years, 401 days).  Its low power density (worst of all fuels) keeps it from doing much more than that, so for extreme long-duration missions it is important to plan for intermittent use of your probe.  Expect such missions, whatever their original purpose, to take on later roles as orbital transponders or stationary science platforms in the same vein as Spirit after it became stuck on Mars.

Its half-life is three times longer than the next longest fuel, which is important for what we may call 'stackability'.  The is similar to the problem of payload fraction in rocket design, where to lift an extra tonne to orbit, you usually have to add ten times as much fuel to the stage below, and ten times that much to the next stage down, and so forth.  In this case, because of the exponential decay of RTG fuel, taking more fuel extends mission life, but only to a point:  adding RTGs adds duration in the form of half-life fractions.  To get another half-life of usable power out of your fuel, you have to double the amount of RTG fuel you carry, but if you want to add another half-life after that, you need to double it again:  each time you double your fuel load to get the same amount of time, which is the same thing as saying that each single RTG adds a diminishing amount of mission time.  However, a longer half-life means each fraction represents more time, so selecting a long-lived fuel means more mission duration for each added RTG compared to other, shorter-lived fuels.  For example, a single Kuudite241 RTG powers an OKTO probe core for approximately 19.58 years.  Adding a second RTG adds one additional half-life (6.33 years), for a total of 25.91 years.  By comparison, the shortest half-life fuel (Kyandere210, at 0.113 years) will power an OKTO for 316 days (0.743 years), and because its half-life is so short, it takes five of them to run that OKTO for even one year.

Kyandere210:

This fuel runs hot and burns out quickly; at a power density of 1.3 watts per kilogram, it is more than three times more energetic than the second-place fuel, but with a half-life of 0.113 years (48 days), the second-place fuel out-powers it in just under 70 days.  To extend the examination, at launch, a single Kyandere210 RTG produces 114.6 EC/min.  After one year, it produces approximately 0.25 EC/min.  After two years, it provides less than a thousandth.  After three years, less than a millionth.  For this reason, Kyandere210 is by far best suited to short-term missions--but in this role it shines, and not just because it is literally glowing hot.  For the first 65 days of its operation, it surpasses the stock RTG's power production.  This is the only fuel to do so.  It is also the second-cheapest and second-lightest fuel available, which makes it quite attractive for short-duration operations on and around Kerbin in places where solar panels are unusable, inadequate, or too likely to break.  One use case would be to power a rover at night or in polar valleys on the Mun; the tiny rover wheels require 60 EC/min to operate, and two Kyandere210 RTGs can power three rover wheels continuously for 16 days.  Though this is obviously a short-duration mission, given that it takes less than a day to reach the Mun, it is also quite doable.

Krontium90:

For each fuel thus far described, I've focused on time as the essential element of utility.  This is because, at least in the case of a continuously decaying fuel supply, time is always of the essence.  Krontium90 is unusual in that it is often a terrible choice of fuel.  It's the worst performer, generally speaking, in terms of its power-generation capabilities.  It begins by producing 14.7 EC/min, only one-half more than Kuudite241, but its short half-life of 1.84 years means that that power drops off quickly; Kuudite241 outperforms it after only 1 year, 149 days.  In fact, as a fuel, it only does better than both Kuudite241 and Kyandere210 for a brief period extending from approximately .5 to 1.5 years--a span firmly in the territory of medium length missions.  But it is not the best choice in those situations, of course:  it is second-best, and always will be because its shorter half-life and lower power density mean that it never, ever catches up to Kitsunium238's performance.  Why, therefore, include it at all?

The reason is because Krontium90 is also unusual in that it is the best choice--often by a large margin--in matters not related to power generation.  It is the cheapest fuel; the next costs three times more.  More useful is the mass of the fuel:  at less than half the density of the next fuel, it could be credibly described as 'fluffy'.  An empty RTG casing masses at 80 kg.  Loaded with Krontium90, it masses 94 kg.  Kitsunium238 (the heaviest fuel) brings its mass up to 123 kg.

Granted, the purchase price of seven units of fuel in a casing that costs over twenty-three thousands of Funds is barely noticeable.  Similarly, a difference in mass of 29 kg is equally barely noticeable.  However, these are limitations imposed by the 'Lego-block' nature of KSP; in real life, an RTG can be built as large or as small as the application--or any other factor--demands, and in these cases, weight and cost are prime concerns.  For KSP, however, it is most likely that you will choose Krontium90 the least often, if at all, over the course of your game, but it does have its place, coincidentally enough, doing the same thing that strontium-90 does on Earth:  it can be used as a cheap and easy power source for Kerbin-based operations, where running out of power is not so much a problem because home is one click of the recovery button away.

 

That's it for fuel choices.  Next will be the comparison to solar panels and a listing of general locations where RTGs work best, when that is true, and why.

Edited by Zhetaan
Editing pass for clarity
Link to comment
Share on other sites

This is a look at best practices and normal applications for these RTGs in the outer system.  I expect to post one more after this, about exotic applications and unusual locations where RTGs show themselves to be surprisingly useful.

 

The first point to understand about these RTGs is that they are, with the limited exception of Kyandere210, very low-power, and that this limits significantly both the practical operating range and the scope of application.  In other words, the very best places to use them are essentially defined as the worst places to use anything else.  Given enough batteries to store the energy for transmissions, an RTG can conceivably power a very robust scientific experiment platform; however, the amount of time needed to recharge for each transmission is long and ever-increasing.  Because there are comparatively few always-on stock parts, mods make this behaviour somewhat more noticeable:  the first fully Jool-capable RemoteTech antenna requires 156 EC/min to maintain a communications link--in addition to whatever else the probe may require.  Kitsunium238 RTGs can power it for nearly 3.5 years ... if you take ten of them.  Also, such a probe will not return.

This highlights the other difficulty of RTGs:  the places where they work best are often far away, so it takes time to get there, but the time taken to travel cuts into the RTG's practical life expectancy.  It takes about three years to reach Jool, and more than four to reach Eeloo, so to plan for such a journey, it may be necessary to double or quadruple the amount of fuel you take simply to allow for the extra to serve as sacrificial fuel mass to leave enough to accomplish the mission objectives.  You can see a real-life example of these sorts of difficulties in the New Horizons probe:  the scientific team deliberately limited the capability of some of the instruments (cameras in particular) because they did not wish to make unreasonable demands on the radio transmitter, given the limited amount of Pu238 to power it.

To that end, let's look at the various power sources in KSP.

Solar panels are almost utterly reliable whenever there is sunlight--almost.  They are also the only power source whose fuel supply is inherently inexhaustible (not uninterruptible!), which means that over a long-enough period of time, the solar panel always wins.  However, their effectiveness drops off with distance from the sun:  a solar panel working at 100% in orbit of Kerbin produces 3.9% of that power around Jool and 2.3% around Eeloo (average).  On the other hand, solar panels are the best power producers out there, so a Gigantor, which produces roughly 1450 EC/min in orbit of Kerbin, still produces 57 EC/min in orbit of Jool and 33 EC/min in orbit of Eeloo.  Kitsunium238 produces only 32 EC/min after the first year--long before it can get to Jool or Eeloo.  Kuudite241 never produces that much, ever.  It is clear that more RTGs are required.

How many more?  Will a stack of RTGs massing the same as a solar panel produce more power than the panel?  Now, it may be instructive to look at the power/mass ratios for the various power sources.  Mass in rocketry is parasitic, so it makes sense to send the most mass-efficient power source, regardless of the cost in Funds.  It's difficult to compare the two because solar panel power decays with distance, whereas RTG power decays with time, but by knowing the minimum travel time to reach distant destinations, it is possible to determine the amount of time that an RTG is the better choice before giving way to the solar panel, as all RTGs must eventually do.

The most mass-efficient solar panel is the non-retractable OX-4L/W (the long and wide versions are the same).  The Gigantor is second best.  The shielded, retractable SP-L/W panels are the worst (shielding takes up mass).  At Eeloo, an OX-4L produces 128.1 EC per minute per tonne, and an SP-L produces 89.6 EC per minute per tonne.

The most mass-efficient RTG depends on both the choice of fuel and the time you observe its output:  however, the minimum time is rather well fixed as the time needed to travel the distance that the solar panel was tested, which is at least four years.  The 4-year output-per-mass for a Kuudite241 RTG is 82.7 EC per minute per tonne, which is just under--but still comparable to--the worst solar panel.  However, a Kitsunium238 RTG at 4 years is 164.34 EC per minute per tonne, which is better than solar panels, and it only falls below solar panels at just after 6 years, giving a two-year window for Eeloo exploration at a bargain over solar panels' mass.

Eeloo Korizons is a go.

 

What of Joolno and Kalileo?

It takes about three years to reach Jool, but Jool is also closer to the sun.  RTGs need to have more power to beat solar panels, but those same higher minimum power thresholds mean that they won't be able to keep their edge for so long.  The OX-4L ratio is about 220 EC per minute per tonne at Jool; the SP-L ratio is about 154 EC per minute per tonne.  Kuudite241 only reaches about two-thirds of the SP ratio, but Kitsunium238 is still viable:  at 3 years, it produces 222 EC per minute per tonne, whereas it drops below the SP ratio at about 4.5 years, leaving a window of a year and one half before all solar panels surpass it.

 

Dres is, in the stock game, the cutoff point where RTGs and solar panels are about equal in power-to-mass values.  Since the stock RTG is a miracle-battery, it didn't matter which you chose to use, excepting that you might spend a lot of time in shadow so the RTG is probably the more practical choice.  With JDiminishingRTG, it's better to take solar panels to Dres.  Only Kitsunium238 starts anywhere close to the stock RTG output but the travel time to Dres takes a half-life, which puts it firmly out of contention.

 

Edited by Zhetaan
Editing pass for clarity
Link to comment
Share on other sites

This is it:  it's the last one.  This part is all about the oddities of power consumption.  Wall of text ahead:  I included some extra information about the Outer Planets Mod.

 

First, an aside:  you may note that in the last section I mentioned discussing the various power sources, but then restricted myself to only solar panels and RTGs.  What of fuel cells?  After careful consideration, I decided that fuel cells fit better in this section because they are truly odd.

In terms of raw output, the fuel cell array is a simple multiple of the small fuel cell.  The cell produces 90 EC/min (about the same as an OX-4L orbiting Kerbin) and the array produces 1080 EC/min (two-thirds of a Gigantor orbiting Kerbin).  In spite of its visual appearance (and the part description), the array produces twelve times the output of the small cell (not six) and consumes twelve times the fuel to do so.  There is no functional difference between taking one array or twelve small cells.  Additionally, because the cells have the same efficiency, a quantity of fuel has a constant conversion ratio:  one unit of proportioned LFO (0.45 LF/0.55 Ox) produces 400 EC.

The fuel cell array does have an advantage over the small cell in power-to-mass ratio:  it is less than twelve times the mass of the small cell.  The small cell produces 1800 EC per minute per tonne, and the array produces 4500 EC per minute per tonne.  This makes the array comparable to the solar panels (its performance is in the middle between the OX-4L and the SP-L) and the smaller cell somewhat less than midway in performance between RTGs and solar panels.

However, this fails to take into account a number of other factors.  First, fuel cells consume fuel, which is finite.  Second, that fuel has significant mass and requires external tankage whose mass also needs to be considered for power-to-mass calculations.  Third, fuel cell production is not limited by time, distance, or any constraints other than availability of their fuel and amount of EC already present on the vessel.

In other words, the amount of time a fuel cell can run is dependent on the amount of fuel you bring and the amount of power your vessel demands:  if you have the fuel and need the power, it runs.  If you do not, it doesn't.  The amount of fuel a cell consumes is dependent upon how much EC you currently carry:  fuel cells throttle back their output to maintain 95% of total battery capacity.  If you have solar panels or RTGs that are capable of maintaining this level, the fuel cells never activate and they last indefinitely.  This property is what makes it so insidiously difficult to compare fuel cells to other power sources:  by throttling back their output when batteries approach capacity, they guarantee that all of the potential charge represented by your fuel stores is used to produce useful EC, meaning that every bit of charge a fuel cell produces will go to power something on the vessel.  If you do not need the EC, it never leaves the fuel tank.  Panels and RTGs, by contrast, continuously produce EC to the best of their ability, and what you do not need is lost.

Do not misunderstand:  this is very intelligent behaviour well-suited to a backup or emergency power supply.  It is also considerate of Squad to program the fuel cells not to waste your fuel.  The cutoff capacity is fully configurable as well, so it is also possible for example to mod a true standby fuel cell whose job is to keep the batteries from falling below 5% instead of 95%.  The only problem is that because of this behaviour, fuel cells are best measured in terms of total producible energy, but RTGs and panels are best rated in terms of power; that is, energy per unit time.  In this context, fuel cells are more like batteries with expandable energy storage modules and really ought to be compared that way.  The comparison works for charge recovery, too:  batteries can recharge via solar panels and RTGs, and fuel cells can 'recharge' via ISRU, the laws of thermodynamics notwithstanding.

(Full disclosure:  I personally dislike the fact that stock ISRU with a fuel cell power plant makes a surplus of energy and fuel, so I mod my fuel cells and ISRU to be a lot less efficient.  This makes asteroids a lot less attractive, but in my case, it makes ISRU itself more attractive, so I'm more likely to use it.  I mention this primarily because this is a more realism-oriented mod, so there may be interest there.)

 

Anyway, let's get back to RTGs.

As I mentioned earlier, a lot of the use cases for RTGs exist in situations where solar panels will not work well.  The RTGs' generally low output also lends them to roles serving as standby power--i.e., keeping the craft powered and radio-linked throughout the night until the solar panels can see sun again; keeping the life support on--but a well-designed craft can make use of high battery capacity and short duty cycles to counter the long recharge time without needing solar panels at all.  For example, even the smallest rover wheel requires 1 EC/second to operate ... at full power.  Typically, my rover designs only have two powered wheels, and those wheels only draw full power when they need a lot of torque, which only happens when just starting out or when climbing a hill.  The rest of the time, they don't need so much EC, so a 'surge battery' to cover the initial spike of power plus an RTG can provide all the power I need to continue moving about the terrain.

 

Shadowed Valleys:

The obvious places where solar panels do not work well would be those where there is much shadow, and it ought to be plainly obvious that the bottoms of valleys, the poles, and such places where the sun is often below the horizon would be poor choices for solar panels.  Since every celestial body in KSP has poles, I will not cover them in detail.

Long Nights:

Another point to consider is the length of day--or, for moons, the revolution about the primary.  The Mun is tidally locked to Kerbin, so its day is the same as its orbit.  Night, therefore, lasts 3 days, 1 hour.  This is part of what makes the Mun a good place to use those high-power Kyandere210 RTGs.  All of Jool's satellites are tidally locked, so their nights grow longer the further out you travel.  This is further complicated by the fact that Jool is not the best place to use solar power to begin with:  landed craft on Jool's moons need to be well-prepared for long nights.  Laythe's night lasts a little over 1 day, 1 hour, but  Pol's night is just under 21 days long.

Moho is an interesting case.  Like Mercury, it rotates in an orbital resonance that, while not tidally locked, nevertheless produces some extremely long nights.  In fact, Moho has the longest night of any body in the stock system, clocking out at about 61 days, four hours.

Intense Heat:

Solar panels lose efficiency as they grow hotter.  Therefore, though a solar panel in Moho's orbit will always produce more EC than one in Kerbin's orbit because of sunlight intensity, the increase will be slightly offset by the higher temperatures at Moho that arise from the higher irradiance so much closer to the sun.  Practically, this is less of an issue with ambient temperatures in space and more of an issue with hot engines, ISRU, or other such parts.  Placing solar panels close to the nuclear engines on an interplanetary tug will cause problems if that tug goes to the outer system.  RTGs do not have this limitation, though it is admittedly an easily-solved problem that owes less to physics and more to bad ship design.

Thick Atmospheres:

Solar panel efficiency accurately accounts for atmospheric attenuation.  This means that it pays attention to the depth and density of the atmosphere when calculating sunlight's path through it.  This means that all solar panels on Kerbin's surface produce less than their rated output, and panels on Kerbin near sunrise or sunset produce even less than that.  Eve has the tallest and thickest atmosphere, so this effect is most pronounced there.  In addition, Eve is also the hottest planet, so the heat problem compounds the issue.

High Gravity:

Eve's atmosphere problems are bad for solar panels, but it is close enough to the sun for the sheer quantity of sunlight available to largely overcome the difficulties.  The real problem for solar panels on Eve is that they tend to break under the crushing gravity.  RTGs are decidedly more solid.

 

A note about Outer Planets Mod:

Take something else.

 

On a more serious note, the approximate average travel times to the outer planets are as follows:

Sarnus:  4.8 years
Urlum:  16.2 years
Neidon:  23.3 years
Plock:  35 - 100 years (the large range is because Plock's orbit is very eccentric)

Sarnus:

Kitsunium238 is useful at Sarnus for the same reasons it is useful at Eeloo and is in fact a little more useful because Sarnus is about one-third further from the sun than stock Eeloo.  This doesn't make a lot of difference in travel time (about one fifth longer), but it cuts solar panel efficiency in half.

Urlum:

Beyond Sarnus, don't bother going if you're not taking Kuudite241.  It takes sixteen years to reach Urlum; that's seven half-lives of Kitsunium238 but only two and a half for Kuudite241.  Kuudite241 at 16 years produces 22.22 EC per minute per tonne, which is a little less than twice what the solar panels can do.  This means that Kuudite241 also has a little less than one half-life, about six years, to work in the Urlum system before solar panels become the better choice.

Neidon:

At Neidon, Kuudite241 produces 10.32 EC per minute per tonne.  OX-4L panels produce 10.60 EC per minute per tonne, making them the better choice if you don't mind the part count of a tonne of OX-4L panels.  This is where available solar power gets to be so low that the mass of the part begins to have an inordinate effect on the power-to-mass ratio:  the other panels have efficiencies ranging between 4.3 and 5.3 EC per minute per tonne.  This gives about four years before Kuudite241 falls below the production of the other solar panels, and that also signifies that we have crossed the midpoint of the solar distance/travel time 'bubble' where RTGs make sense.

Plock:

At Plock's semi-major axis, solar panels produce between 2.7 and 3.7 EC per minute per tonne.  Kuudite241, at 35 years (this is a fast transfer, not necessarily a transfer to Plock's Pe, average distance, or any other specific point on its orbit), produces 2.77 EC per minute per tonne.

At Plock's apoapsis, solar panels produce between 1.6 and 2.2 EC per minute per tonne.  At 100 years, RTGs produce nothing.  That's sixteen half-lives for Kuudite241; to put it in perspective, for you to have the full power of one Kuudite241 RTG at Plock's apoapsis, you'd need to take over 65,000 RTGs to start the trip.

Don't take RTGs to Plock.

In summary, there is a very good reason that the outermost bodies of our own solar system have been visited exactly once.  If you want to do a fast-transfer, no-frills, flyby-only visit a la New Horizons or Voyager 2, RTGs are a great option.  But if you want to do a fuel-efficient transfer and send an expedition, do it with a different power source.  The fact that you need literal tonnes of solar panels could be turned to your advantage:  imagine a giant orbital solar station at Plock, and ships that run on batteries only.

... Or just take some Near-Future Electrical nuclear reactors.  That works, too.

Link to comment
Share on other sites

Thank you very much @Zhetaan!

If I may, I'd like to make two suggestions:

  1. since you mentioned nuclear reactors in your third (last) part, I think you should talk about them too;
  2. you should duplicate these posts of yours on the Tutorials section of the forums (even copy and paste would do), it's very good!
Link to comment
Share on other sites

8 hours ago, blu3wolf said:

Is there a MM patch I can look at to see about applying these RTG configs to a stockish RTG? I have a number of mods installed, and one of them has added an RTG inside a crew module, which Id like to configure through this mod.

Cheers!

@ABZB has already proposed that here. Unfortunately, it seemed to have some problems with the launch clamps and with the maxAmount property (it was scaled turning the RTG into some kind of battery).

After some help from help from Zhetaan (BTW, that's how @Zhetaan started his series of electric analysis), I came to this possible solution:

//hits all parts with module generator that has no inputs and outputs EC. runs on the final pass to avoid parts with specific configs
@PART[!launchClamp*]:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE[ElectricCharge],!INPUT_RESOURCE[*]],!MODULE[ModuleDiminishingRTG]]:FINAL
{
    @description = By exploiting the 'natural' decay of radiological isotopes, electrical power can be generated for prolonged durations—indeed, indefinitely, but the output tends to fall off over time. Accountants have also noted that different 'hot rocks' are hotter or cooler than others and tend to cool down a different rates, with the two aspects not necessarily being related.

    //scale everything according to mass of stock RTG config (0.08)
    MODULE
    {
        name = ModuleDiminishingRTG
        efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge 
        volume = 7 // roughly, in deciliters. ("units")
        @volume /= 0.08
        @volume *= #$../mass$

        //scale efficiency compared to the stock RTG electric output
        @efficiency /= 0.75
        @efficiency *= #$../MODULE[ModuleGenerator]/OUTPUT_RESOURCE[ElectricCharge]/rate$
    }
    //use the replace-if-not-create to avoid duplicate resource node
    %RESOURCE[ElectricCharge]
    {
        %isTweakable = true
        @amount = 1
        @maxAmount = 1
    }
    !MODULE[ModuleGenerator]{}
}

Tell me if you find something wrong, please...

Link to comment
Share on other sites

@blu3wolf:

Is it NearFutureSpacecraft's Itinerant Service Container?  This is what I use:

@PART[utilityCabin]:FOR[JDiminishingRTG]
{
    !MODULE[ModuleGenerator] {}
    MODULE
    {
        name       = ModuleDiminishingRTG
        efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge (Real RTGs are between 5% - 7% efficient)
        volume     = 4.2  // roughly, in deciliters. ("units") (utilityCabin's RTG is smaller than stock; this keeps that proportion)
    }
}

Most of the mod-added RTGs I've encountered copy the stock values, so MM-ing them is easy--assuming you want that performance.  NearFuture is one exception to the rule.  If you want something different from stock performance, you need to find the ModuleGenerator line of the part.cfg and get the OUTPUT_RESOURCE ElectricCharge rate.  It looks like this (this is from Nertea's NearFutureSpacecraft Itinerant Service Container):

	MODULE
	{
		name = ModuleGenerator
		isAlwaysActive = true
		OUTPUT_RESOURCE
		{
		   name = ElectricCharge
		   rate = 0.45
		}	
	}

The stock RTG's rate is 0.75 EC/second, which equals 7 decilitres of Kitsunium238.  Divide 7 by 0.75 and multiply by whatever the output is of the RTG you want to mod (in this case, 0.45) to get the corrected volume for the JDiminishingRTG MM patch.

Link to comment
Share on other sites

1 minute ago, Zhetaan said:

@blu3wolf:

Is it NearFutureSpacecraft's Itinerant Service Container?  This is what I use:

[...]

Oops, ninja'ed!

Zhetaan, can you please, look at the MM patch I proposed (based on ABZB's) and see if it's ok? It has the advantage of being generic...

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...