Open ShotgunNinja opened 7 years ago
Note on solar wind occlusion by celestial bodies It will be very hard to determine occlusion in the proper way, because the 'parker-spiral-arm' path would have to be walked, and for each step all celestial bodies position at the time would have to be calculated from their orbits, then sun visibility evaluated. This could probably be also done analytically, but it will be even more ugly.
A better solution is to ignore celestial bodies occlusion when evaluating the solar wind intensity at a point, and instead only using it when evaluating the radiation reaching a particular vessel. That is, ignore the real solar wind path and assume a line-of-sight one instead. Some corner cases may be built for which this result will not match the proper one, but in general the two results should be the same.
Interactions between solar wind and magnetospheres The 'radiation fields' representing magnetospheres have negative radiation values, that represent the 'shielding' effect of that particular body magnetic field.
So naturally solar wind radiation will be summed to the total radiation of the fields, leading to magnetospheres protecting from solar wind, de-facto, depending on the intensity of their shielding effect and the intensity of the solar wind at that particular point and time.
Interactions between radiation and communications A 'blackout radiation threshold' will be added in Settings.cfg, with some reasonable default value.
When environment radiation at the vessel position (thus including solar wind contribution) is above that threshold, the transmission rate of a vessel will get penalized in proportion of how much above this threshold the radiation level is. Up to total communication blackout.
Additional consequences will be partial or total loss of communications when crossing particularly strong inner belts.
Solar storms, and their effect on communications What outlined just above doesn't reproduce the current behaviour of communication blackout exclusively inside magnetopauses, during solar storms.
In the new implementation, during intense solar wind episodes, communications will be disrupted (up to total blackout) by the high charged particle intensities, notwithstanding the magnetic field shielding effect. If the intensities are strong enough, or the body magnetic field weak enough.
The current 'storm icon' in Monitor will be re-used to tell the user that strong solar wind is hitting that specific vessel. So, it will become the 'space weather icon'.
Super cool idea! Much more interesting, and less random than current CMEs. I think that having an experiment to measure it is an absolute necessity. If you keep CME as well, an experiment to give some early warning should also be implemented. It would also be cool if the Automation module has events related to space weather, so that it could trigger some action (e.g. if fast solar wind damages solar panels, it would makes sense to use retractable ones that are shielded, and trigger retraction on event.). As for parts, if you need to commission some, I'm willing to chip in couple of GBP.
Another effect of weather might be to reduce the efficiency of solar panels. Some digging/asking someone who knows might be a good idea, but I imagine that charged particles hitting photovoltaics might wreak a bit of havoc. Maybe even permanent decrease of efficiency?
If I had a part suitable to be a solar wind sensor, like the real-life SWEPAM here, I would definitely build some mechanic on top of it.
I'm thinking how the flare/CME warnings may work. With a dedicated part module, I could make it so that it warn the user when intensity is above a threshold. Then the user is supposed to place vessels with this sensor around, to give early warnings. Ideally they could try to replicate the orbits of real-life vessels that have the SWEPAM and are used for this very purpose.
This 'warning' could then be shown as a message to the user, and broadcast to all vessels in the same planetary system, where a new associated script in automation could be triggered.
As for parts, if you need to commission some, I'm willing to chip in couple of GBP.
Thanks a lot for the offer. But I guess that sooner or later I should learn to make simple models in blender. This may be a good one to start with, it seem simple enough. Even the texturing seem dead simple.
Another effect of weather might be to reduce the efficiency of solar panels. Some digging/asking someone who knows might be a good idea, but I imagine that charged particles hitting photovoltaics might wreak a bit of havoc. Maybe even permanent decrease of efficiency?
I'm going to ask to David Hunter, he probably know. But I guess they don't do good to solar panels.
I know that during a CME radio transceivers must be turned off due to the energy build up on the antennas, this makes the power transistors inside the radio equipment overheat and fail if being used when a CME hits them. Even metal cables over a certain length will have energy induced in them by the wideband RF content of the CME and can be enough energy to damage a substation transformer. Maybe this action could be simulated by damaging the antennas when a CME hits if they are powered on, obviously some sort of on/off switch will have to be added to the antennas.
There is a lot of good information on Ben Davidsons Space Weather site http://spaceweathernews.com/
Hi folks.
Thanks for your kind words in the OP, ShotgunNinja.
Regarding CME warnings: this is done using the "EPAM" part of the SWEPAM instrument. I will send you a message via the KSP forums explaining this function in more detail shortly so you can get an idea how exactly it is done.
"Another effect of weather might be to reduce the efficiency of solar panels. Some digging/asking someone who knows might be a good idea, but I imagine that charged particles hitting photovoltaics might wreak a bit of havoc. Maybe even permanent decrease of efficiency?"
"I'm going to ask to David Hunter, he probably know. But I guess they don't do good to solar panels."
Space weather will effect photovoltaics in the same way it effects any other electronic component: it will ionise components and cause degradation of circuitry. There's nothing inherently different about PVs.
"I know that during a CME radio transceivers must be turned off due to the energy build up on the antennas, this makes the power transistors inside the radio equipment overheat and fail if being used when a CME hits them. Even metal cables over a certain length will have energy induced in them by the wideband RF content of the CME and can be enough energy to damage a substation transformer. Maybe this action could be simulated by damaging the antennas when a CME hits if they are powered on, obviously some sort of on/off switch will have to be added to the antennas."
This really depends on the energy of the CME itself. Most CMEs don't cause that much problem and generally spacecraft antennas and electronics are kept online, primarily because most spacecraft are in Earth orbit and are somewhat protected by the Earth's magnetosphere. They're usually only switched off/on if a) it has no magnetic shielding, or b) a very strong CME is expected.
EDIT: just remembered my username on GitHub doesn't have my full name. Derp.
If I may suggest creating CMEs with differing energies?
Have a look at the CME SCORE classification system. This is how CMEs are classified: https://swrc.gsfc.nasa.gov/main/score
If you can create CMEs with different energies/velocities, and classify them using the SCORE system, perhaps you could then also program in e.g. loss of signal to some spacecraft, based on a) whether or not they are protected by a planetary magnetic field, and b) the CME class.
I would recommend the O-, R- and ER-class CMEs would be worthy of causing signal loss when a spacecraft isn't otherwise protected by a magnetosphere.
Side-note: if you go down that route, I would really appreciate it if this would also cause loss of signal with RemoteTech, as I always play with RemoteTech installed, and I like my KSP gaming to be ultra-hard. :P
Want to make it even harder? If a spacecraft is transmitting science data back to KSC when a CME arrives, and if the CME has a high-enough energy to disrupt communications, perhaps only part of the science transmission should arrive at the KSC, and so you would only get a percentage of the total science value. e.g. if it's meant to give 10 science points if transmitted back to KSC, and an R-class CME arrives, then it may only give 5 science points. Obviously a stronger ER-class CME would prevent all communication (so you'd get 0 points).
Perhaps you could add an upgrade to command modules/probe cores that will automatically re-send data if packets are lost during transmission. This upgrade would obviously cost more (much like the shielding costs more if you want to add it to a module).
@DaveTSG awesome info!
About re-sending - the probe still has the data on its drive. It would make more sense in Kerbalism framework, IMO, to have CMEs wipe part of the science from the drive, with the amount dependent on strength of the event and the shielding class adjusted by some random factor.
I also like suggestion about CME class, and think it could be used to simplify the shielding system. Instead of having a numerical value for shield resource, have it show something like Unshielded, O-, -R, or ER-rated.
The emissions from a particular solar spot (so, the emissions of all kind of solar events) could be represented using existing classification (like flare, CME-S, CME-C, etc), but the underlying emission is better implemented with a continuous intensity value. That value would then map to a classification, for representation purpose. This is more generic, and play well with the existing radiation implementation.
Likewise, shielding will still be a continuous value. Its representation to the user (now 'mm of lead-equivalent material') could be extended to also include the emission-level classification mentioned. So the planner/monitor could tell the user that their shielding level is suitable up to CME-C radiation intensity, for example.
About malfunctions and critical failures interaction with radiation: maybe the reliability system module be extended in that regard, with details of the interaction specified per-part. So a part could be made to fail (irreparably or not) when the radiation level is above a threshold. This need more thinking, both on how to implement it as well as the effect on gameplay. Anyway it could be added in a second moment, after the new space weather system is in place.
Electron density Using the same data already required by the simulation (the emission spot time, location and intensity) it is possible to extrapolate the electron density in the solar wind (triggered by X-ray radiation) at any point in the solar system.
If we ignore the time required for the X-ray EM radiation to reach the sampling point (so, if it is assumed to have infinite velocity), it could be implemented very fast and simple:
This new environment value could be used for early but less precise warnings about CME events. The same warning mechanics of the SWEPAM sensor part (described in a previous post) could be extended to make use of this new environment value.
[*] It could also be evalued at a point in the past depending on speed of light and distance from the sun and the sampling point. However, one can think of EM emissions also forming a parker-spiral flow, except with curvature small enough to appear almost purely radial. So to simplify the implementation they can be assumed to be radial, that is the same as to say that we assume light speed to be infinity.
So, I've been away from KSP for a while... did anything ever come of this discussion, @ShotgunNinja?
ShotgunNinja is absent, Kerbalism is being maintained here: https://github.com/ScienceFun/Kerbalism-Continued
Thanks, @lordcirth
This outline a proposed re-implementation of space weather mechanics, based on a simple idea. That idea came out of private discussions with David Hunter, that is knowledgeable on the subject. Thank you David!
At the moment, space weather is only represented by symbolic 'CME events' originating at random from the sun, toward a planetary system. After the CME symbolically hit the planetary system, the whole of it enter what I define as a 'solar storm' state, for some time. In that state, radiation is increased (if you are not inside a magnetopause), and communications are blacked out (if you are inside a magnetopause). This system is okay (if not a bit bland). There is no graphical representation of the CME.
The proposal is to scrap the existing system, and replace it with a new one.
Space weather primer The sun emit charged particles in all directions, usually called 'the solar wind'. The emission is not uniform over the photosphere, nor it is constant over time. At some point in time, areas of the sun photosphere emitting less or more than average are called 'dark spots' or 'bright spots'. These cause 'discernible events' both on the photosphere, above the photosphere, and in the path that the related emissions follow through the solar system. These 'events' have many names, that are beyond the scope of this gentle introduction.
A 11 years cycle has been observed on the level of charged particles emitted from the sun. Therefore, the frequency of dark and bright spots change over the course of this 11 years cycle. Intuitively, dark spots are associated to lower emission levels while bright spots are associated with higher emission levels. Cycles start with low emission level, high number of dark spots and low number of bright spots (the solar minimum), reach an apex of high emission level, high number of bright spots and low number of dark spots (the solar maximum), then return to the starting condition.
The charged particles are emitted radially, and as the sun photosphere rotate the stream emitted from a particular spot will form a spiral as they travel outward from the sun. This is called the 'Parker Spiral'.
The charged particles are emitted with variable velocities. The set of velocities observed seem to cluster around two particular ones. These have been called the 'fast solar wind' and the 'slow solar wind'.
All of this is a simplication. The reasons for the sun cycle and the anisotropy of emission intensity and velocity are irrelevant for our purpose.
The idea For any point in space (in the sun frame of reference), the associated 'parker spiral arm' passing through the point is deduced. Then, the origin of the 'parker spiral arm' is traced back to a specific point on the surface of the sun, at a specific point in the past.
The surface point and the moment in time are then used as coordinates to lookup in a map (in the mathematical sense), that associate all possible ones to a level of charged particle emission.
This map is implemented procedurally, in such a way as to model the dark and bright spots, with a frequency that follow a single cycle. A simple modulo operation on the time coordinate cause the cycle to repeat infinitely. The procedural representation requires no data storage requirements and has infinite resolution.
What gives It is possible to evaluate the solar wind intensity at any point, and these intensities vary with time and are 'parker-spiral-like'. This space weather model is a decent representation of reality, and is fast to evaluate. Now the question arise what to do with this data.
Intuitively, it could map to radiation directly so that increasingly intense emissions cause increasingly intense radiation. What is now the CME 'solar storm' will then be simply a particularly intense emission.
Maybe they should also interfere with communications, in a more generic way than the current 'blackout'. Albeit I didn't explore this aspect at all, at this moment.
It would be nice to add a new experiment part, that act as sensor for solar wind intensity data (like SWEPAM). But this require either me learning how to model and texture in Blender, or somebody else contributing the model.
I'm out of ideas on what else the solar wind intensity could be used for. It is interesting to note that this data will be exposed by the API, so it could be used by other mods (one that add electric sails for example).
Graphical representation of solar wind A lot of particles are rendered (eg: 100k), centered on the sun, using an uniform distribution. The particles are static, that is, they don't move in the sun frame of reference. They are also sparse enough so that the overall 3d field can be seen.
The color of each particle will be determined from the solar wind intensity at that point, at current time. This will happen by re-implementing the algorithm mentioned above inside a shader.
To aid in visualizing the 3d field, depth of each particle will have to be conveyed somehow.
This is only rendered in map-view or tracking-station.
Effect on performance should be trivial.
Graphical representation of sun photosphere and sun corona events Ideally the bright and dark spots should be represented on the photosphere, albeit this is secondary. The simplest way would be to replace the existing sun shader with a custom one, that sample the solar wind 'map' at current time. But this could conflict with custom planet packs and/or light flare effects, logos forbid.
Even more secondary is representing the plasma filaments along very dynamic magnetic field, occurring over bright spots usually, and with intensity proportional to the underlying emission intensity. I have some ideas on this, that involve an ad-hoc physical simulator using verlet integration (nowadays called 'position based dynamics') and using spline attractors for the magnetic lines. So assume this will not happen.