Summer of Code in Space 2017

From Stellarium Wiki
Jump to: navigation, search

Ideas for the SOCIS 2017 (ESA Summer of Code in Space).

Contents

Common requirements

All of these tasks require knowledge of C/C++, as Stellarium is written in it, and some knowledge of the Qt framework (or willingness to learn the basics very quickly), because Stellarium relies heavily on it, especially for its GUI.

You should also become familiar with Stellarium's merge proposal review guideline, which outlines how your code will be reviewed before it's merged in Stellarium's code.

Suggested workflow

For each task that looks interesting to you:

  • Understand it - read the description and try to imagine what is required
  • Research it - if the description is unclear, you can ask for clarification and/or do some research and come up with your own ideas. Also, look at how Stellarium works with similar tasks
  • Sketch it - Check out Stellarium's code and build it (there are Bzr_checkout instructions on this wiki), look at what can be used and what needs to be done to implement your idea, how it will come together with the rest of Stellarium
  • All of this should prepare you to write a good proposal.

Ideas/projects

Planetary surface nomenclature

Brief explanation: At the moment, Stellarium doesn't support the nomenclature for surface features on bodies of the Solar system. Nomenclature (naming topographical formations on the surface of the planet) should be enabled when a certain value for FOV has been reached, and marking should start with the biggest formations - like lunar maria. When user zooms further in, then labels for objects of first level (biggest formations) should be hidden, to make space for labels for the objects of second level, e.g. big craters and mountains.

This feature should support localization (multilingual translation) and should be enabled/disabled via preferences in case of visible performance degradation on weaker systems.

Knowledge Prerequisite: C++, Basic Astronomy, Geometry.

Mentor: Alexander Wolf (IRC: alexwolf)

Contact


Parallelize computation of planetary positions

Brief explanation: Most positional computation in Stellarium is done in the program's main thread on the central processing unit (CPU). Positions of minor bodies (asteroids, comets) are computed from their orbital elements following few well-known and not overly complex algorithms, which however require a few loops. However, in recent years CPUs come with several cores which allow parallel execution of several computations, and GPU computing became quite popular for SIMD operations.

There are 2 sub-tasks: First, computing the 8 main planet positions (and a few other "computational heavy" objects, like Pluto, the Moon and some other planetary satellites) should be parallelized, e.g. with OpenMP.

Further, it may be possible to compute positions of thousands of minor bodies directly on the GPU if loops can be limited to a fixed (short) number of iterations. This may require to first test a larger number of existing objects and count the typical number of required iterations depending on parts of the algorithms (e.g. trying various iterative solutions to Kepler's equation), and if the number of iterations to reach a certain accuracy can be identified, use this as fixed loop count in the GLSL implementation. Of course, if hardware is not capable of running the GPU implementation, a CPU-based fallback solution is still required.

Should that be too easy, of course the Satellites plugin can also profit from parallelizing the orbit computations.

This is mostly a software engineering task. If you are familiar with parallelizing computations and interested in GPGPU, this would be your place.

Knowledge Prerequisite: C++, OpenMP, GPGPU computing, some astronomical basics of orbital computation (although functions for CPU are already present. Algorithms from books available.)

Mentor: Alexander Wolf (IRC: alexwolf)

Contact


D-Bus Interface

Brief explanation: D-Bus is an interprocess communication protocol which can be used to interface several programs running on the same computer. There is an idea (Wishlist entry) to link the three most popular open-source programs to make optimal use of the best features of each program. D-Bus is usually found on modern Linux systems as regular system component, and can also be installed on MacOS X and Windows.

Note that last year's SoCiS initiated a Remote Control plugin which allows controlling Stellarium via an http interface. This required major changes in the internal communication between Stellarium's modules (how the modules' properties are propagated). The D-Bus communication can make use of much of this new infrastructure, and should use a similar syntax. (The plugin is being finalized in these weeks and will be available around May 2017.)


Knowledge Prerequisite: C++, Qt, a bit of interprocess communication, and some experience with Stellarium, KStars, and maybe Cartes du Ciel.

Mentor: Alexander Wolf (IRC: alexwolf)

Contact

Your idea

You can propose your idea for Stellarium. If it will be great we can approve it.

Contact

Personal tools
Namespaces
Variants
Actions
in this wiki
other languages
Toolbox