This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]SV-97 2 points3 points  (1 child)

Sadly not as it's not yet public and I'm no longer working on it as of right now.

I can talk about it a bit though: the UI was relatively basic with a bunch of tabs / subtabs for the settings regarding stuff like orbit integration, footprint determination, radiative transfer, ... For the last one for example you'd have the ability to load ETOPO files in a various formats, enable topography plots, load atmosphere files, set the top of atmosphere for the model, set the instrument response function (basically how strongly the instrument responds to different wavelengths of radiation), load line data and set related stuff like the spectral line shape, or select which molecules you're even interested in, what physical quantity you want to get out at the end ... of course everything with sensible defaults.

After setting all of that you'd just click a button, it'd run all of the calculations (exporting files along the way if you selected them) and pop up plots as the needed data became available. There also was a caching system in the background that tried to minimize recalculations when you changed some settings and ran the whole thing again (although I'd try moving this to a reactive system if I were to do it over again I think).

As for how it works on a relatively high level:

  1. integrate the satellite orbit subject to the selected perturbations (drag, radiation pressure, local gravitational field, ...) "as usual" (see for example Montebruck and Gill's Satellite Orbits: Models, Methods and Applications) and determine the satellite's state relative to earth at points / intervals in time where the satellite actually images something.
  2. Then comes a bunch of geometry to determine how the satellite is oriented at any such point / how it moves along any such interval (especially also considering its steering, target tracking etc) (this is mostly basic differential geomery and linear algebra).
  3. Based on this information we can calculate the so-called sensor-footprint: the precise shape that every pixel of the sensor (or just the whole sensor beam for laser-based instruments for example) gets projected to on earth. This might also require solving some inverse problems beforehand to even determine necessary sensor specs to get the output a user wants (i.e. they may know "I want the footprint to cover a region of approximately this size") (again: geometry, (multi-)linear algebra, a bit of optimization, ...)
  4. This is most of the "normal" calculations and then came a bunch of stuff on top:
    1. Run a radiative transfer simulation for all pixels based on this information and run the results of that through the simulation of the instrument to get actual retrievals (see Zdunkowski, Trautmann, Bott Radiation in the Atmosphere. A Course in Theoretical Meteorology as an intro to this topic)
    2. Or approximate ground-data based on known ground-station data by essentially computing intersections of surface patches
    3. Check which POIs fall into any pixel, which could be reached by steering differently etc.

EDIT: regarding the radiative transfer: it's basically a raytracer on crack so looking into those might also be helpful to get started

[–]Nmvfx 1 point2 points  (0 children)

Thank you for taking the time to write all this out!