Looking for Solar Panel Math Models in KSP

[Arrowstar]

In KSP, you can see a variety of solar panel parts that sport an "electric charge rate" type of parameter.  This presumably shows the amount of electrical power generated by the panel when it's facing the sun.  However, for many years now, we have known that KSP models its solar panels' output using an inverse square law w.r.t. the distance to the Sun.  What I'm after is how KSP uses this in a config file:

chargeRate = 24.4

to get to the actual EC/s output rate that the panel produces in the game.  What is that mathematical relationship?  Presumably it involves some sort of relationship between distance to the Sun, the angle between the panel's normal vector and vector to the Sun, and a constant which gives the shown charge rate at the reference distance (I think Kerbin's orbit SMA from the Sun).

Can anyone help me?  @NathanKell, you've had some great insight into KSP math models before, any ideas here?

Thanks, all!

EDIT: I don't suppose it works something like this?

ec_rate = ec_rate_ref * 1/(r/r_ref)^2 * cos(theta)

where

ec_rate => actual solar panel charge rate
ec_rate_ref => the reference charging rate in the part's config file
r => the distance from the Sun that the spacecraft is
r_ref => the distance from the Sun at which the ec_rate is equal to the ec_rate_ref; probably Kerbin's orbit SMA
theta => the angle between the solar panel normal vector and the Sun vector

 

Edited July 29, 2020 by Arrowstar

[OhioBob]

11 hours ago, Arrowstar said:

EDIT: I don't suppose it works something like this?

ec_rate = ec_rate_ref * 1/(r/r_ref)^2 * cos(theta)

where

ec_rate => actual solar panel charge rate
ec_rate_ref => the reference charging rate in the part's config file
r => the distance from the Sun that the spacecraft is
r_ref => the distance from the Sun at which the ec_rate is equal to the ec_rate_ref; probably Kerbin's orbit SMA
theta => the angle between the solar panel normal vector and the Sun vector

 

I believe that's correct.  But there seems to be a lot of variability to it that I don't understand.  And, yes, I'm almost certain that r_ref = Kerbin's SMA.  One caveat to your formula, if theta > 90 degrees, ec_rate = 0.

[Arrowstar]

1 hour ago, OhioBob said:

I believe that's correct.  But there seems to be a lot of variability to it that I don't understand.  And, yes, I'm almost certain that r_ref = Kerbin's SMA.  One caveat to your formula, if theta > 90 degrees, ec_rate = 0.

Thanks for the insight!  And yes, your caveat is important, I need to keep that in mind.

[NathanKell]

@Arrowstar  @OhioBob  That...sounds about like what I wrote there, yes.  I have no idea if it's been changed since. It's taking the dot product of the panel's up vector and the ship->Kerbol vector, dividing by (alt/ref_SMA)^2, and that's the output. If the raycast from the panel's suncatcher transform hits any collider on its way to the sun, the panel is counted as "in shadow" and provides no charge.

However there's also two other aspects involved, it's coming back to me now.

First, the panel's temperature. There's a floatcurve in the PART config that determines a multiplier at a given temperature in K. Evaluate it as you would any other floatcurve. EDIT: Uh, if it's not there, you probably have to empirically determine it, I might've set default values in code. Or ask a friendly current dev.

Second (although IIRC stock doesn't use this, only RO) there's a multiplier based on mission time to support panel degradation. If there's no mention in the cfg file, assume it's not used in stock.

Edited August 1, 2020 by NathanKell

[OhioBob]

@NathanKell, hello.  It's been a long time since our last conversion.  I hope everything is going well.

Since you're here, I have a question.  I just happen to be in the middle of working on something with the new Kopernicus devs that you might know something about.  Can you tell me anything about how atmospheric extinction works in KSP?  It's clear that a solar panel produces less power if it's beneath a planet's atmosphere.  It's also clear that the sun angle also has an affect on power output - i.e. less power output when the sun is on the horizon vs. high overhead.  I've been working on my own equations for it, but if there's anything you can tell me about how KSP does it, that would be most helpful.

[R-T-B]

Yes, I could really use the backup there if you have any data.

[OhioBob]

43 minutes ago, NathanKell said:

dividing by (alt/ref_SMA)^2

That explains why I'm always off a little bit when I estimate power output.  I've tried calculating it using either radii or altitudes, but I don't think I ever tried altitude/radius.
 

43 minutes ago, NathanKell said:

First, the panel's temperature. There's a floatcurve in the PART config that determines a multiplier at a given temperature in K. Evaluate it as you would any other floatcurve. EDIT: Uh, if it's not there, you probably have to empirically determine it, I might've set default values in code. Or ask a friendly current dev.

It's not in the PART cfgs, so it must be buried in the code.
 

43 minutes ago, NathanKell said:

Second (although IIRC stock doesn't use this, only RO) there's a multiplier based on mission time to support panel degradation. If there's no mention in the cfg file, assume it's not used in stock.

There's no mention of this in the cfgs.  To my knowledge this is not enabled in stock.

[Arrowstar]

13 hours ago, NathanKell said:

@Arrowstar  @OhioBob  That...sounds about like what I wrote there, yes.  I have no idea if it's been changed since. It's taking the dot product of the panel's up vector and the ship->Kerbol vector, dividing by (alt/ref_SMA)^2, and that's the output. If the raycast from the panel's suncatcher transform hits any collider on its way to the sun, the panel is counted as "in shadow" and provides no charge.

So if I'm understanding you correctly, it's current altitude above the Sun divided by the reference radius?

I have to admit that's really a bizarre way of defining it, since the quantities aren't the same.  Maybe it's changed since then, any idea who I would ask?

[R-T-B]

I'm running into an entirely different issue with "solar panel programming."  Thought I'd stick it here since it's sort of solar math.

Re Kopernicus mulitstar support:  I have the proper ECs calculated.  They even display in the panel output.  But calculating them relies on calling CalculateTracking() in the panel, and everytime I do this, it introduces spurious ECs I can't seemingly purge from the system.  Even reassigning flowRate does not remove them, it seems to add to them and net sum them.  I have no idea how to do the math without CalculateTracking, and I've been chasing my tail on this for days.  What on earth do I do to just set the output of a solar panel to a static number?  I'm currently running my code in FixedUpdate, if it makes any difference.

Edited August 1, 2020 by R-T-B

[OhioBob]

5 hours ago, Arrowstar said:

So if I'm understanding you correctly, it's current altitude above the Sun divided by the reference radius?

I have to admit that's really a bizarre way of defining it, since the quantities aren't the same.  Maybe it's changed since then, any idea who I would ask?

I'm quite certain it hasn't changed.  For instance, Kerbin's semimajor axis is 13600 Mm, which equates to an altitude of 13338 Mm.  One of the small steerable solar arrays has a chargeRate of 1.64.  Using NathanKell's math, it should produce an energy flow at Kerbin of, 1.64 / (13338 / 13600)^2 = 1.705.  That's typically what a see for one of those solar panels around Kerbin.

[NathanKell]

@OhioBob great to see you again as well! I've been pretty much detached from all things Kerbal for the last year and a half, and mostly-detached for a couple years before that. Things are well though! Hope same for you?

So...I went digging a bit and saw this in physics.cfg:  solarLuminosityAtHome = 1360 // Solar flux in W/m^2 at the orbital altitude of the homeworld 

First, I screwed that up, it should be irradiance. But anyway, that reminded me that solar panels actually hijack the flight integrator's thermo code (which has to calculate solar flux at the vessel's current orbital altitude over the sun) and I htink *that* code uses raycasting in scaled space, which is liable to have float precision issues. So that might be the cause of your offset. (I believe I did test this that in orbit of kerbin the solar flux is reported to be 1360W/cm^2 so I don't think there's an alt/sma mixup after all.) That it lines up with alt/SMA I can't explain.

But that allows me to answer your question about extinction. I think I hacked it (hah, surprise). Something like estimate the mass of air light will be traveling through (well, one scale-height's worth, IIRC), and then get a relative factor comparing atmospheric density at sea level on your current body vs on Kerbin,  and multiplying the reciprocal of that with a "how much gets to ground on Earth, cough Kerbin" factor set, like solar luminosity (ehh, irradiance) in physics globals. I don't recall the specific numbers, sorry. It's all about taking straight up to the sun through Kerbin's atmosphere as a baseline and then trying to figure out how much extra air there would be based on solar angle and extra atmospheric density / higher scale height.

Did find something that reminded me of what site I used to set up the temperature curves. The data points I used were:

4k  1.2x; 300k 1x; 1200k 0.134x; 1900k 0.02x; 2500+k 0.01x

 

Edited August 9, 2020 by NathanKell

[OhioBob]

@NathanKell, thanks.  I did something very similar regarding the extinction issue.  Thanks also for the temperature curve data.  The problem that Kopernicus is struggling with right now is getting solar panels to work properly when there are multiple stars.  I'm not real sure what the current status is, but I know it's been a headache for those working on it.  Although I've helped out a little bit with testing and suggestions, I'm not one of the Kopernicus devs.  @R-T-B has been working on it.

[R-T-B]

Indeed, I explained the crux of the problem above.  If you need more details, let me know:

On 8/1/2020 at 2:11 PM, R-T-B said:

I'm running into an entirely different issue with "solar panel programming."  Thought I'd stick it here since it's sort of solar math.

Re Kopernicus mulitstar support:  I have the proper ECs calculated.  They even display in the panel output.  But calculating them relies on calling CalculateTracking() in the panel, and everytime I do this, it introduces spurious ECs I can't seemingly purge from the system.  Even reassigning flowRate does not remove them, it seems to add to them and net sum them.  I have no idea how to do the math without CalculateTracking, and I've been chasing my tail on this for days.  What on earth do I do to just set the output of a solar panel to a static number?  I'm currently running my code in FixedUpdate, if it makes any difference.

 

[NathanKell]

@R-T-B can you subclass from solar panel and then override PostCalculateTracking. Set a flag before you call CalculateTracking, and in PostCalculateTracking() only call base() if the flag isn't set, then after your call, set the flag back to false.

Hacky, but should prevent EC generation when you call CalculateTracking but still do so when the module does its own thing.

(to be clear, EC generation is done in PostCalculateTracking)

[R-T-B]

18 minutes ago, NathanKell said:

@R-T-B can you subclass from solar panel and then override PostCalculateTracking. Set a flag before you call CalculateTracking, and in PostCalculateTracking() only call base() if the flag isn't set, then after your call, set the flag back to false.

Hacky, but should prevent EC generation when you call CalculateTracking but still do so when the module does its own thing.

(to be clear, EC generation is done in PostCalculateTracking)

That might work.  Thanks for the idea!  I'll try it soon here...  would be nice to get another stab at multistar out but first I've got to do *sighs* real life work... lol.

Thanks for getting back to me, I was stumped and didn't know what part was making the ECs.  If it's just PostCaclulateTracking, I think we can work around this.

Edited August 11, 2020 by R-T-B

[NathanKell]

 

@R-T-B Yep the EC generation is all in post. The rest of the calculation is setting the angle and determining LOS (Solar Panel also overrides the LOS step to do some raycasts, but it only establishes what the blocking part is, it doesn't generate EC). Happy to help!

[R-T-B]

You've enabled a major breakthrough on our multistar efforts today in Kopernicus.
The answer was as simple as you stated.  It's amazing sometimes how we can't see the simplest of solutions in our own code.  Many thanks.  The commits are already on my tree, and entering testing with my crew now.