From 99d3443d876769ba1b3fe75b95ac23b14d45b555 Mon Sep 17 00:00:00 2001
From: kautlenbachs <98521380+kautlenbachs@users.noreply.github.com>
Date: Mon, 8 Jan 2024 16:29:03 +0200
Subject: [PATCH] Documentation of SUM, ADD and release notes
---
README.md | 12 +-
RELEASE.md | 49 +++++++
doc/add/add_esa.md | 316 +++++++++++++++++++++++++++++++++++++++++++++
doc/sum/sum.md | 193 +++++++++++++++++++++++++++
doc/sum/sum_esa.md | 269 ++++++++++++++++++++++++++++++++++++++
5 files changed, 837 insertions(+), 2 deletions(-)
create mode 100644 doc/add/add_esa.md
create mode 100644 doc/sum/sum.md
create mode 100644 doc/sum/sum_esa.md
diff --git a/README.md b/README.md
index 9016416..365adab 100644
--- a/README.md
+++ b/README.md
@@ -5,10 +5,18 @@ Developed during [IDEAS-QA4EO](https://qa4eo.org/) service operations lead by Te
## Out of the box usage
-Verified releases can be downloaded from - https://github.com/cgi-estonia-space/asar-focus/releases/
+Verified releases can be downloaded from - https://github.com/cgi-estonia-space/asar-focus/releases/. \
One can download docker image with all of the needed dependencies from dockerhub or simply `docker pull cgialus/alus-ootpa-devel`
-# License
+## Usage and requirements
+
+See [software user manual](doc/sum/sum.md)
+
+## Release history
+
+See [RELEASE.md](RELEASE.md)
+
+## License
[Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)](LICENSE.txt)
diff --git a/RELEASE.md b/RELEASE.md
index 2166e89..635d802 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -1,3 +1,52 @@
+# Release 0.2.0
+
+## Breaking changes
+
+## Known Caveats
+* Only IMS product processing
+* Not all the auxiliary files are utilized, currently processor configuration file (CON),
+ instrument characterization file (INS) and external calibration data (XCA) are in use
+* Azimuth compression windowing is yet to be done - https://github.com/cgi-estonia-space/asar-focus/issues/2
+* Processing speed (Vr) and Doppler centroid changes in azimuth direction yet to be done - https://github.com/cgi-estonia-space/asar-focus/issues/2
+* Packets' ISP sensing time handling might not be 100% correct
+ * It is observed for the reference products that it calculates new ISP sensing times based on PRI
+ * Therefore products by this processor differ in sensing start/stop and first/last line times (always inside the specified sensing filter)
+ * Best knowledge/effort basis changes has been implemented - https://github.com/cgi-estonia-space/asar-focus/issues/17 and https://github.com/cgi-estonia-space/asar-focus/issues/16
+* ERS time is not corrected according to PATM/N/C files - https://github.com/cgi-estonia-space/asar-focus/issues/15
+* Various metadata fields needs further work
+* Final results' scaling is yet to be determined, currently it is not matching exactly the reference processor
+ * With the current experience/knowledge there is a "best guess" implemented
+* See more shortcomings at https://cgi-estonia-space.github.io/asar-focus/posts/version-0-2-shortcomings/
+
+## Major Features and Improvements
+
+* Range and azimuth direction edge pixels are cut from the final result, [read more](https://cgi-estonia-space.github.io/asar-focus/posts/range-and-azimuth-window/)
+* CUDA device initialization, properties and check util
+* Storing results made faster with async IMS write and higher GPU utilization -
+ see https://github.com/cgi-estonia-space/asar-focus/pull/26 and https://cgi-estonia-space.github.io/asar-focus/posts/read-and-write-optimizations/
+* Complete refactor of parsing the input files, fetching measurements and processing - almost 3x of processing time
+ gains - https://github.com/cgi-estonia-space/asar-focus/pull/29 See more detailed description - https://cgi-estonia-space.github.io/asar-focus/posts/read-and-write-optimizations/
+* Better handling of missing packets and various fields for handling the missing measurements etc
+* Usage of external calibration file for scaling factor guess - https://github.com/cgi-estonia-space/asar-focus/pull/34
+* Final results without artifacts and 'nodata' pixels - see https://github.com/cgi-estonia-space/asar-focus/pull/33 and https://cgi-estonia-space.github.io/asar-focus/posts/range-and-azimuth-window/
+* Hamming window applied for range compression - https://github.com/cgi-estonia-space/asar-focus/pull/34
+* More metadata fields computed/assembled
+
+## Bug Fixes and Other Changes
+* Invalid read of single additional sample of Envisat measurement fixed - https://github.com/cgi-estonia-space/asar-focus/pull/30
+* Memory leak of the compressed sample block fixed - https://cgi-estonia-space.github.io/asar-focus/posts/read-and-write-optimizations/
+* Additional output for plot (`--plot`) that enables to analyze the geolocation of the scene and basic parameters
+* Fixed azimuth direction artifacts with padded lines for compression -
+ see https://github.com/cgi-estonia-space/asar-focus/pull/33 and https://cgi-estonia-space.github.io/asar-focus/posts/range-and-azimuth-window/
+* Envisat results scene geolocation inaccuracy fixed by applying gate bias/delay in the calculation - https://github.com/cgi-estonia-space/asar-focus/pull/33
+* More modules formed as CMake targets with unit tests
+
+## Thanks to our Contributors
+
+Kajal Haria, Fabiano Costantini from Telespazio UK\
+Sabrina Pinori, Marco Galli from SERCO\
+Andrea Recchia from aresys
+
# Release 0.1.2
## Breaking changes
diff --git a/doc/add/add_esa.md b/doc/add/add_esa.md
new file mode 100644
index 0000000..3811e4f
--- /dev/null
+++ b/doc/add/add_esa.md
@@ -0,0 +1,316 @@
+
+
+
+
ASAR-FOCUS GPU processor
Architecture Design Document
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+CGI Estonia
Jan 8th 2024
Issue/Revision: 1/A
+
+
+Published (including this document) at Github
https://github.com/cgi-estonia-space/asar-focus
+
+
+
+
+CHANGE LOG
+
+
+
+| Issue/Revision | Date | Pages | Description |
+|----------------|------------|-------|------------------------------------|
+| 1/A | 08/01/2024 | All | Initial document for version 0.2.0 |
+
+
+
+
+
+TABLE OF CONTENTS
+
+
+* [1 Introduction](#1-introduction)
+* [1.1 Purpose](#11-purpose)
+* [1.2 Scope](#12-scope)
+* [2 System Overview](#2-system-overview)
+* [3 System Context](#3-system-context)
+* [4 System Design](#4-system-design)
+* [5 Component Description](#5-component-description)
+ * [5.1 DevicePaddedImage](#51-devicepaddedimage)
+ * [5.2 Envisat format module](#52-envisat-format-module)
+ * [5.3 Boost log](#53-boost-log)
+ * [5.4 Boost program arguments](#54-boost-program-arguments)
+ * [5.4 cuFFT](#54-cufft)
+* [6 Feasability and Resource Estimates](#6-feasability-and-resource-estimates)
+ * [6.1 Profiling analyze](#61-profiling-analyze)
+ * [6.2 GPU and RAM memory limit based on the dataset size](#62-gpu-and-ram-memory-limit-based-on-the-dataset-size)
+
+
+
+
+DEFINITIONS, ACRONYMS AND ABBREVIATIONS
+
+
+
+| Acronym/abbreviation | Definition |
+|----------------------|-------------------------------------|
+| CC | CUDA Compute Capability |
+| CLI | Command-line interface |
+| COTS | Component Off-the-Shelf |
+| CUDA | Compute Unified Device Architecture |
+| GPU | Graphics Processing Unit |
+| OS | Operating system |
+| RHEL | Red Hat Enterprise Linux |
+| SDK | Software Development Kit |
+| SNAP | Sentinel Application Platform |
+
+
+
+
+
+# 1 Introduction
+
+# 1.1 Purpose
+
+Using GPUs for earth observation (EO) data processing is a rather undeveloped method. At the same time this is not a
+novel way, because such approaches have been developed for more than 10 years. This was enabled by the
+NVIDIA's CUDA architecture which makes possible to process generic payloads besides graphical textures. The `asar_focus`
+processor is one of the attempts to reproduce the data quality of a legacy CPU based processor while enabling
+processing performance gains.
+
+This document aims to facilitate:
+* further development of the focusser
+* document the principles of efficient EO data processing using parallel processing paradigm
+
+
+# 1.2 Scope
+
+There is a single executable binary produced by the software package. It is built for Red Hat Enterprise Linux version
+8.x. All the other components required are detailed in the [software user manual](https://github.com/cgi-estonia-space/asar-focus/blob/documentation/doc/sum/sum.md).
+The project could be run on other Linux distributions as well, with possible tweaking of the required components.
+
+Current state of the focusser will be able to focus ERS-1/2 and Envisat's synthetic aperture radar (SAR) instrument's
+data for the imaging mode (IM) datasets only. It lacks some functionality in order to match the baseline PF-ASAR
+processor functionality:
+* PATC/PATN support for ERS time synchronization is missing
+* Sections of metadata is not appropriately formed (enough for products to be further processed in ESA SNAP)
+* Focussing quality is not matched (visually good, but histograms of focussed I/Q raster are not so well-formed)
+
+Current state of the developed functionality enables to:
+* Revisit details of the missions' instrument processing and document it properly for further developments
+* Implement all the other acquisition modes' (wave, alternating polarisation etc.)
+ parallel processing pipelines with less effort
+* Re-analyze baseline processor PF-ASAR data quality and develop further enhancements
+* Lower the costs of the instrument data processing facility by faster and more energy efficient processing
+
+# 2 System Overview
+
+The GPU accelerated processors greatly benefit from the parallel computing paradigm. Previous ESA activities developed
+by CGI Estonia together with CGI Italy and industry experts have produced set of GPU accelerated processors available
+on [Github](https://github.com/cgi-estonia-space/ALUs). The processing speed and data quality numbers are given in the
+repository and its [Wiki](https://github.com/cgi-estonia-space/ALUs/wiki). As a general outcome the processing speed
+could be increased from 10 to 100 times while enabling up to 10 times fewer costs than utilising traditional processors
+tha leverage CPU for computing.
+
+In order to achieve fast processing utilising GPU one has to focus on:
+* Minimising data transfers between storage, RAM and GPU
+* Utilise as fast as possible disk or RAM storage mechanisms
+* Utilise GPU as much and often as possible during the execution of the processor
+
+# 3 System Context
+
+This processor's general system has been kept simple which has been validated by the
+[ALUs](https://github.com/cgi-estonia-space/ALUs) processors. This has proven to enable further integration with other
+systems with possibility to add convenient functionality like graphical user interface or data fetching. Below are
+general blocks that define the approach.
+
+![asar_focus system context](https://github.com/kautlenbachs/bulpp_diagrams/blob/main/asar-focus-system-context-a.drawio.png?raw=true)
+
+*Figure 3.0 - General system block scheme*
+
+The OS here facilitates:
+* Execution of binary on a system with the GPU
+* File input/output
+* Memory management
+* CPU threading
+
+The CUDA component enables:
+* Query and check the GPU properties
+* Command GPU
+* Transfer data between GPU and RAM
+
+The `asar_focus` processor:
+* Command line arguments handling
+* Dataset parsing and results formating
+* Focussing pipeline implementation
+* Efficient disk storage read and write strategies
+* Efficient GPU occupation strategies
+* System logs
+* Error checks for dataset and GPU
+
+# 4 System Design
+
+Main focus is on the efficient GPU processing pipeline where the time spent on I/O should be minimized or parallelized
+while processing calculations. Below is the general pipeline of the processor.
+
+![general processing pipeline](https://github.com/kautlenbachs/bulpp_diagrams/blob/main/asar_meta_flow.drawio.png?raw=true)
+
+*Figure 4.0 - General processing pipeline*
+
+The **measurements processing** step is generic focussing pipeline that is represented by the figure below.
+![focussing processing pipeline](https://github.com/kautlenbachs/bulpp_diagrams/blob/main/sar_focussing.drawio.png?raw=true)
+
+*Figure 4.1 - Generic focussing pipeline*
+
+Both of these figures above are tightly coupled. As can be seen on the last figure the "raw file decoding" and
+"processed file" are the steps that are mostly presented on the first figure. Based on current profiling results dataset
+parsing and writing takes 60 and more percent of the overall end to end time, depending heavily on the storage device
+capability.
+
+# 5 Component Description
+
+## 5.1 DevicePaddedImage
+
+SAR focusing requires forward and backwards Fourier transforms in range and azimuth directions, additionally the SAR
+datasets are quite large
+
+DevicePaddedImage is the core abstraction to facilitate efficient SAR transformations by embedding extra padding areas
+in the right and bottom of the image. This allows inplace FFTs in both range and azimuth direction, this alleviates
+the need for extra memory copies to fulfill FFT size requirements. Thus changing from time domain to frequency domain
+and back is done memory efficiently, without needlessly copying multi gigabyte signal data.
+
+Additional design consideration is the fact that GPU onboard memory is less than main board RAM, thus using this
+technique allows to keep the full DSP chain on the GPU memory, avoiding costly CPU <-> GPU transfers.
+Visual representation of the memory layout.
+```
+ RANGE
+ |------------------------|---------|
+ A | | |
+ Z | SAR SIGNAL DATA | RANGE |
+ I | | FFT |
+ M | | PADDING |
+ U | | |
+ T |------------------------|---------|
+ H | AZIMUTH FFT PADDING | |
+ |------------------------|---------|
+```
+
+## 5.2 Envisat format module
+
+The Envisat format support handling and support was implemented during this project. No libraries were used. This includes
+custom structures, little/big-endian conversions and data type handling. All the implementation is contained in
+`envisat_format` folder of the project. It applies to both the ERS and Envisat mission datasets
+
+It contains the following sub-functionality:
+* DORIS orbit file search and parsing
+* Auxiliary files' search and parsing
+* Level 0 imaging mode dataset parsing
+* Level 1 image mode single look complex dataset structure and writing
+* GPU computation kernels to condition the measurements
+
+## 5.3 Boost log
+
+Boost library's submodule implemented in C++ to enable console log handling. This enables structured logs with timestamps
+and different log levels.
+
+An extract of the curren log:
+```
+[2024-01-08 11:43:57.852098] [0x00007fa101e9b000] [debug] Doppler centroid constant term -568.25 and max aperture pixels 543
+[2024-01-08 11:43:57.852121] [0x00007fa101e9b000] [info] Need to remove 543 lines before requested sensing stop
+[2024-01-08 11:43:57.853812] [0x00007fa101e9b000] [debug] Azimuth compression time = 536 ms
+[2024-01-08 11:43:57.854107] [0x00007fa101e9b000] [trace] SWST change at line 19814 from 2024 to 2048
+[2024-01-08 11:43:57.854160] [0x00007fa101e9b000] [debug] Swath = IS2 idx = 1
+```
+
+## 5.4 Boost program arguments
+
+Boost library's submodule implemented in C++. Used to facilitate command line arguments handling. All the setup, help
+messages, validation and parsing is achieved using this module.
+
+Example of the interface built using the module.
+
+```
+asar_focus/0.2.0
+ -h [ --help ] Print help
+ -i [ --input ] arg Level 0 ERS or ENVISAT dataset
+ --aux arg Auxiliary files folder path
+ --orb arg Doris Orbit file or folder path
+ -o [ --output ] arg Destination path for focussed dataset
+ -t [ --type ] arg Focussed product type
+ --sensing_start arg Sensing start time in format '%Y%m%d_%H%M%S%F' e.g.
+ 20040229_212504912000. If "sensing_stop" is not
+ specified, product type based sensing duration is used
+ or until packets last.
+ --sensing_stop arg Sensing stop time in format '%Y%m%d_%H%M%S%F' e.g.
+ 20040229_212504912000. Requires "sensing_start" time
+ to be specified.
+ --log arg (=verbose) Log level, one of the following -
+ verbose|debug|info|warning|error
+```
+
+## 5.4 cuFFT
+
+Submodule of the umbrella CUDA SDK. While other functionality of the CUDA is rather generic and detailed on the NVIDIA
+developer sites, the usage of cuFFT is documented here.
+
+The SAR focussing pipeline uses the Fourier transforms in range and azimuth direction to generate the final focussed
+product. This library can highly perform massively parallelized FFT transforms of the whole signal data in one function
+call.
+
+
+# 6 Feasability and Resource Estimates
+
+## 6.1 Profiling analyze
+
+Example GPU profiling chart is presented below
+![profiling chart](https://sar-focusing.s3.eu-central-1.amazonaws.com/pages/asar-focus_profile_add.png)
+
+*Figure 6.1 - Processor profiling*
+
+Test setup:
+* RTX3060 Laptop GPU<
+* AMD Ryzen 7 5800H CPU
+* Fast NVMe SSD
+
+Test data - Envisat IM -> Envisat IMS. About 16 seconds of signal data. The whole chain is processed in less than 2 seconds.
+Summary of the time spent:
+1. File read, metadata parsing & signal data DISK -> CPU -> GPU (350 ms)
+2. Core SAR DSP chain (700 ms)
+3. Metadata assembly, file writing GPU -> CPU -> disk (750 ms)
+
+Steps 1 & 3 are heavily dependent on the performance of the storage and can be a major bottleneck. Step 2 is mostly done
+on the GPU and the most time-consuming steps are the FFTs calculated by cuFFT. The CPU speed is not relevant as no
+major focussing steps are bottleneck by the CPU.
+
+There still some optimizations that could be done:
+* Forecast level 0 dataset offsets and therefore no need to wait and read all the file
+* Deallocate GPU and RAM buffers earlier
+
+With this there could be nearly 1 second processing time when the RAM disk is a source and target disk storage.
+
+## 6.2 GPU and RAM memory limit based on the dataset size
+
+The baseline GPU memory requirement is estimated to be:\
+`Total memory usage = Range size * Azimuth size * 8 * 1.3 * 2`
+
+Where:
+* Range size is level 0 range size
+* Azimuth size is total number of processed packets
+* 8 is size of the complex float
+* 1.3 is rough estimate of the paddings required for range and azimuth compression and additional metadata
+* 2 is memory used for FFTs and output image generation (that includes back and forth buffer)
+
+On a standard 16 seconds IMS dataset, this results in about 3GB of GPU memory. CPU RAM memory usage is roughly
+the input file size plus the output file size. Other elements take insignificant amount of memory.
diff --git a/doc/sum/sum.md b/doc/sum/sum.md
new file mode 100644
index 0000000..df28ec3
--- /dev/null
+++ b/doc/sum/sum.md
@@ -0,0 +1,193 @@
+# 1 Introduction
+
+Following information describes the usage of the ERS and Envisat focusser utilizing GPU. It is implemented in C/C++/CUDA
+programming languages. Here is described how to install dependencies and build/compile and run the processor. Not all
+steps have to be executed in order to run focussing process. There are prebuilt container images and binaries available.
+The processor contains **hidden** functionality that could be invoked to
+analyze the internals of the processing results. They are described in the chapters below.
+
+Required datasets and auxiliary files are also described. Although for better and more complete overview following
+documents are suggested:
+* QA4EO-SER-REP-REP-4512
+* PO-RS-MDA-GS-2009 Chapter 8
+
+
+
+# 2 Prerequisites
+
+Currently tested target platforms are Ubuntu 22.04 LTS (codename Jammy and its flavours) and Red Hat Enterprise Linux
+version 8 (codename Ootpa). There are 2 set of requirements lists - for development (devel) and for running (runtime).
+Common components are NVIDIA GPU driver and CUDA SDK components that should be installed on the processing environment
+for both scenarios.
+
+The list of packages and installation scripts are available at [ALUS-platform Github repo](https://github.com/cgi-estonia-space/ALUs-platform).
+Based on target platform one can conveniently choose intended scripts. Subchapters consist summary of those.
+
+## 2.1 Common components
+
+| Name | Version | Description | Instructions |
+|---------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Nvidia driver | 525 >= | Component that manages the GPU(s) installed on the system. Also manages low level communication with the device(s). Exposes driver API which is utilized by CUDA Toolkit libraries. | [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/install_nvidia_driver.sh)/[Ootpa manual](https://gist.github.com/kautlenbachs/8c6d7966693668d94aa86085403f4821) \| [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy-aws/install_nvidia_container_base.sh) |
+| Cuda SDK | 11.2 >= 12.0 < | Enables GPU interfacing through the driver API. Also includes GPU tuned libraries for FFT, algebra, etc. | [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/install_cuda_base.sh)/[Ootpa manual](https://gist.github.com/kautlenbachs/8c6d7966693668d94aa86085403f4821#installation-of-cuda-sdk) \| [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy/install_cuda_base.sh) | |
+
+
+### 2.1.1 Enabling containers
+
+There are many options to choose from which are all summarized on Nvidia's official CDI page at https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html.
+The scenario could vary from the type of operating system to orchestration framework used. This means there could be
+different engines used - docker, containerd, CRI-O and podman - which all need customized setup.
+
+Currently utilized and tested approaches within this project are represented below:
+* [podman on Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/install_container_toolkit.sh)
+* [docker on Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy-aws/install_nvidia_container_base.sh)
+
+### 2.1.2 Prebuilt containers
+
+Below are listed published container images on Dockerhub
+
+| Platform | Development | Runtime |
+|----------|----------------------------|------------------------------|
+| Ootpa | `cgialus/alus-ootpa-devel` | `cgialus/alus-ootpa-runtime` |
+| Jammy | `cgialus/alus-devel` | `cgialus/alus-runtime` |
+
+## 2.2 Runtime COTS
+
+| Name | Version | Description |
+|-----------|-----------------|---------------------------------------------------------|
+| libstdc++ | == 6.0 | The GNU C++ standard library |
+| boost | == 1.71 <= 1.78 | Libraries for CLI arguments, date and time and logging |
+| GDAL | == 3.0.4 | Creates GeoTIFF files for analyzing purposes |
+
+Setup scripts:
+* [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/setup_runtime.sh)
+* [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy/setup_runtime.sh)
+
+## 2.3 Development COTS
+
+| Name | Version | Description |
+|-----------|-----------------|---------------------------------------------------------|
+| CMake | \>= 3.20 | Build files generation and build execution |
+| nvcc | \>= 11.2 < 12.0 | Compiler for GPU device code |
+| g++ | \>=8.5 < 12.0 | Compiler for C/C++ host code |
+| libstdc++ | == 6.0 | The GNU C++ standard library |
+| fmt | == 10.1 | String, integer and object text print utility |
+| gtest | == 1.10 | Automated test development - unit and integration tests |
+| boost | == 1.71 <= 1.78 | Libraries for CLI arguments, date and time and logging |
+| Eigen | == 3.4 | Algebra library, header only |
+| GDAL | == 3.0.4 | Creates GeoTIFF files for analyzing purposes |
+
+Setup scripts:
+* [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/setup_devel.sh)
+* [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy/setup_dev.sh)
+
+# 3 Usage
+
+The developed processor called `asar_focus` is a single executable GPU ERS and ENVISAT SAR focussing tool. No graphical
+user interface or any other hidden requirements are present. Below will be described the arguments, formats and input
+datasets/auxiliary files. All the produced files will be written to the location specified by the `output` argument.
+
+If the program has successfully processed the product the return code of the binary execution will be **0**. Any other
+exit code means error during processing which SHALL be accompanied by the message on the console. Unsuccessful
+processing could occur due to the invalid input(s), programming error or host machine's/OS errors/congestion.
+
+There is no distinction between ERS and ENVISAT instrument datasets. When there are modes/types given that are not
+present for given instrument then this is reported. Same goes for datasets - the processor makes decisions
+based on the given input arguments.
+
+## 3.1 CLI arguments
+
+All the processing input is given by the program arguments. No environment variables or configuration files are used.
+Somewhat exceptions are mission and instrument specific auxiliary files which are supplied with the directory from
+which the processor searches for specific files based on input dataset sensing time. For orbit files either directory or
+specific DORIS orbit file path could be given. When not specifying sensing time the processor will process all level 0
+input packets if there is sufficient GPU memory.
+
+```
+asar_focus/0.2.0
+ -h [ --help ] Print help
+ -i [ --input ] arg Level 0 ERS or ENVISAT dataset
+ --aux arg Auxiliary files folder path
+ --orb arg Doris Orbit file or folder path
+ -o [ --output ] arg Destination path for focussed dataset
+ -t [ --type ] arg Focussed product type
+ --sensing_start arg Sensing start time in format '%Y%m%d_%H%M%S%F' e.g.
+ 20040229_212504912000. If "sensing_stop" is not
+ specified, product type based sensing duration is used
+ or until packets last.
+ --sensing_stop arg Sensing stop time in format '%Y%m%d_%H%M%S%F' e.g.
+ 20040229_212504912000. Requires "sensing_start" time
+ to be specified.
+ --log arg (=verbose) Log level, one of the following -
+ verbose|debug|info|warning|error
+```
+
+As of release version 0.2 only single `type` is supported which is `IMS`. Any other value would result in termination
+of processing with accompanying message on console.
+
+### 3.1.1 Hidden CLI features
+
+For debugging and research possibilities couple of 'unofficial' command line arguments are present which are given below.
+* `--plot` - create HTML files consisting graphs of the following processing properties - processing velocity,
+ chirp signal, doppler centroid and scene geolocation properties on earth
+* `--intensity` - create GeoTIFF files of the raw measurements, range compressed results and fully compressed intensity
+
+All the created files would be saved in the same directory as the final product given by the `output` argument. They are
+prefixed with the level 0 dataset name pattern.
+
+### 3.1.3 Examples
+
+During the production and internal tests there are so called test datasets (TDS) packages used. This is not required
+and one could simply have manually assembled the collection of suitable orbit files and auxiliary files downloaded as
+a bundle on online at available ESA sites (see [ERS](https://earth.esa.int/eogateway/instruments/sar-ers/auxiliary-data)
+and [ENVISAT](https://earth.esa.int/eogateway/instruments/asar/auxiliary-data)).
+Both of the scenarios are supported. Below are given examples for both.
+
+**Manually assembled datasets**
+```
+asar_focus --input SAR_IM__0PWDSI19920904_101949_00000018C087_00294_05950_0000.E1
+--aux ers1_aux_dir
+--orb ers1_pds_orbit_dir -o /home/foo/ -t IMS
+```
+
+**TDS**
+```
+asar_focus --input
+TDS09/ASA_IMS_1PNESA20040229_212506_000000152024_00387_10461_0000.N1/
+ASA_IM__0PNPDK20040229_212454_000000492024_00387_10461_2585.N1
+--aux TDS09/ASA_IMS_1PNESA20040229_212506_000000152024_00387_10461_0000.N1
+--orb TDS09/ASA_IMS_1PNESA20040229_212506_000000152024_00387_10461_0000.N1/
+DOR_VOR_AXVF-P20120424_125300_20040228_215528_20040301_002328
+--type IMS --output /home/foo/ --sensing_start 20040229_212504912000
+--sensing_stop 20040229_212523002000
+```
+
+## 3.2 Input datasets
+
+Single level 0 **envisat format** ERS-1/2 and Envisat mission dataset is required. As of version 0.2 only imaging mode
+datasets are supported. The specification is given in document `PO-RS-MDA-GS-2009 4/C`.
+
+## 3.3 Auxiliary files
+
+As of version 0.2 the following auxiliary files are used:
+* DORIS orbit files in envisat format, see [DOR_VOR_AX](https://earth.esa.int/eogateway/catalog/envisat-doris-precise-orbit-state-vectors-dor-vor_ax-)
+* Processor configuration file (ASA_CON_AX/ER_CON_AX)
+* Instrument characterization file (AUX_INS_AX/ER_INS_AX)
+* External calibration data (ASA_XCA_AX/ER_XCA)
+
+For auxiliary file access and documentation please visit [ERS aux](https://earth.esa.int/eogateway/instruments/sar-ers/auxiliary-data)
+and [ENVISAT aux](https://earth.esa.int/eogateway/instruments/asar/auxiliary-data) pages at ESA.
+
+# 4 Requirements
+
+Below are specified minimum requirements for hardware. It is based on the resources needed to focus 16 seconds of
+level 0 imaging mode dataset. Resource like CPU is out of scope, because all modern CPUs are suitable. Disk storage
+resource is dismal, since only level 1 dataset storage is required also no intermediate files are stored
+(except for debugging features discussed in [3.1.1 Hidden CLI features](#311-hidden-cli-features)).
+
+| Property | Value |
+|------------------------|--------|
+| RAM | 4 GB |
+| GPU (V)RAM | 4 GB |
+| NVIDIA CUDA generation | CC 6.0 |
+
+For specific compute capability and NVIDIA GPU models, please see [CUDA wikipedia page](https://en.wikipedia.org/wiki/CUDA#GPUs_supported).
diff --git a/doc/sum/sum_esa.md b/doc/sum/sum_esa.md
new file mode 100644
index 0000000..90b84de
--- /dev/null
+++ b/doc/sum/sum_esa.md
@@ -0,0 +1,269 @@
+
+
+
+ASAR-FOCUS GPU processor
Software User Manual
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+CGI Estonia
Jan 8th 2024
Issue/Revision: 1/A
+
+
+Published (including this document) at Github
https://github.com/cgi-estonia-space/asar-focus
+
+
+
+
+CHANGE LOG
+
+
+
+| Issue/Revision | Date | Pages | Description |
+|----------------|------------|-------|------------------------------------|
+| 1/A | 08/01/2024 | All | Initial document for version 0.2.0 |
+
+
+
+
+
+TABLE OF CONTENTS
+
+
+* [1 Introduction](#1-introduction)
+* [2 Prerequisites](#2-prerequisites)
+ * [2.1 Common components](#21-common-components)
+ * [2.1.1 Enabling containers](#211-enabling-containers)
+ * [2.1.2 Prebuilt containers](#212-prebuilt-containers)
+ * [2.2 Runtime COTS](#22-runtime-cots)
+ * [2.3 Development COTS](#23-development-cots)
+* [3 Usage](#3-usage)
+ * [3.1 CLI arguments](#31-cli-arguments)
+ * [3.2 Input datasets](#32-input-datasets)
+ * [3.3 Auxiliary files](#33-auxiliary-files)
+
+
+
+
+DEFINITIONS, ACRONYMS AND ABBREVIATIONS
+
+
+
+| Acronym/abbreviation | Definition |
+|----------------------|-------------------------------------|
+| CC | CUDA Compute Capability |
+| CLI | Command-line interface |
+| COTS | Component Off-the-Shelf |
+| CUDA | Compute Unified Device Architecture |
+| GPU | Graphics Processing Unit |
+| RHEL | Red Hat Enterprise Linux |
+| SDK | Software Development Kit |
+
+
+
+
+
+# 1 Introduction
+
+Following information describes the usage of the ERS and Envisat focusser utilizing GPU. It is implemented in C/C++/CUDA
+programming languages. Here is described how to install dependencies and build/compile and run the processor. Not all
+steps have to be executed in order to run focussing process. There are prebuilt container images and binaries available.
+The processor contains **hidden** functionality that could be invoked to
+analyze the internals of the processing results. They are described in the chapters below.
+
+Required datasets and auxiliary files are also described. Although for better and more complete overview following
+documents are suggested:
+* QA4EO-SER-REP-REP-4512
+* PO-RS-MDA-GS-2009 Chapter 8
+
+
+
+# 2 Prerequisites
+
+Currently tested target platforms are Ubuntu 22.04 LTS (codename Jammy and its flavours) and Red Hat Enterprise Linux
+version 8 (codename Ootpa). There are 2 set of requirements lists - for development (devel) and for running (runtime).
+Common components are NVIDIA GPU driver and CUDA SDK components that should be installed on the processing environment
+for both scenarios.
+
+The list of packages and installation scripts are available at [ALUS-platform Github repo](https://github.com/cgi-estonia-space/ALUs-platform).
+Based on target platform one can conveniently choose intended scripts. Subchapters consist summary of those.
+
+## 2.1 Common components
+
+| Name | Version | Description | Instructions |
+|---------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Nvidia driver | 525 >= | Component that manages the GPU(s) installed on the system. Also manages low level communication with the device(s). Exposes driver API which is utilized by CUDA Toolkit libraries. | [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/install_nvidia_driver.sh)/[Ootpa manual](https://gist.github.com/kautlenbachs/8c6d7966693668d94aa86085403f4821) \| [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy-aws/install_nvidia_container_base.sh) |
+| Cuda SDK | 11.2 >= 12.0 < | Enables GPU interfacing through the driver API. Also includes GPU tuned libraries for FFT, algebra, etc. | [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/install_cuda_base.sh)/[Ootpa manual](https://gist.github.com/kautlenbachs/8c6d7966693668d94aa86085403f4821#installation-of-cuda-sdk) \| [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy/install_cuda_base.sh) | |
+
+
+### 2.1.1 Enabling containers
+
+There are many options to choose from which are all summarized on Nvidia's official CDI page at https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html.
+The scenario could vary from the type of operating system to orchestration framework used. This means there could be
+different engines used - docker, containerd, CRI-O and podman - which all need customized setup.
+
+Currently utilized and tested approaches within this project are represented below:
+* [podman on Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/install_container_toolkit.sh)
+* [docker on Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy-aws/install_nvidia_container_base.sh)
+
+### 2.1.2 Prebuilt containers
+
+Below are listed published container images on Dockerhub
+
+| Platform | Development | Runtime |
+|----------|----------------------------|------------------------------|
+| Ootpa | `cgialus/alus-ootpa-devel` | `cgialus/alus-ootpa-runtime` |
+| Jammy | `cgialus/alus-devel` | `cgialus/alus-runtime` |
+
+## 2.2 Runtime COTS
+
+| Name | Version | Description |
+|-----------|-----------------|---------------------------------------------------------|
+| libstdc++ | == 6.0 | The GNU C++ standard library |
+| boost | == 1.71 <= 1.78 | Libraries for CLI arguments, date and time and logging |
+| GDAL | == 3.0.4 | Creates GeoTIFF files for analyzing purposes |
+
+Setup scripts:
+* [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/setup_runtime.sh)
+* [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy/setup_runtime.sh)
+
+## 2.3 Development COTS
+
+| Name | Version | Description |
+|-----------|-----------------|---------------------------------------------------------|
+| CMake | \>= 3.20 | Build files generation and build execution |
+| nvcc | \>= 11.2 < 12.0 | Compiler for GPU device code |
+| g++ | \>=8.5 < 12.0 | Compiler for C/C++ host code |
+| libstdc++ | == 6.0 | The GNU C++ standard library |
+| fmt | == 10.1 | String, integer and object text print utility |
+| gtest | == 1.10 | Automated test development - unit and integration tests |
+| boost | == 1.71 <= 1.78 | Libraries for CLI arguments, date and time and logging |
+| Eigen | == 3.4 | Algebra library, header only |
+| GDAL | == 3.0.4 | Creates GeoTIFF files for analyzing purposes |
+
+Setup scripts:
+* [Ootpa](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/rhel/8/ootpa/setup_devel.sh)
+* [Jammy](https://github.com/cgi-estonia-space/ALUs-platform/blob/main/ubuntu/22_04/jammy/setup_dev.sh)
+
+# 3 Usage
+
+The developed processor called `asar_focus` is a single executable GPU ERS and ENVISAT SAR focussing tool. No graphical
+user interface or any other hidden requirements are present. Below will be described the arguments, formats and input
+datasets/auxiliary files. All the produced files will be written to the location specified by the `output` argument.
+
+If the program has successfully processed the product the return code of the binary execution will be **0**. Any other
+exit code means error during processing which SHALL be accompanied by the message on the console. Unsuccessful
+processing could occur due to the invalid input(s), programming error or host machine's/OS errors/congestion.
+
+There is no distinction between ERS and ENVISAT instrument datasets. When there are modes/types given that are not
+present for given instrument then this is reported. Same goes for datasets - the processor makes decisions
+based on the given input arguments.
+
+## 3.1 CLI arguments
+
+All the processing input is given by the program arguments. No environment variables or configuration files are used.
+Somewhat exceptions are mission and instrument specific auxiliary files which are supplied with the directory from
+which the processor searches for specific files based on input dataset sensing time. For orbit files either directory or
+specific DORIS orbit file path could be given. When not specifying sensing time the processor will process all level 0
+input packets if there is sufficient GPU memory.
+
+```
+asar_focus/0.2.0
+ -h [ --help ] Print help
+ -i [ --input ] arg Level 0 ERS or ENVISAT dataset
+ --aux arg Auxiliary files folder path
+ --orb arg Doris Orbit file or folder path
+ -o [ --output ] arg Destination path for focussed dataset
+ -t [ --type ] arg Focussed product type
+ --sensing_start arg Sensing start time in format '%Y%m%d_%H%M%S%F' e.g.
+ 20040229_212504912000. If "sensing_stop" is not
+ specified, product type based sensing duration is used
+ or until packets last.
+ --sensing_stop arg Sensing stop time in format '%Y%m%d_%H%M%S%F' e.g.
+ 20040229_212504912000. Requires "sensing_start" time
+ to be specified.
+ --log arg (=verbose) Log level, one of the following -
+ verbose|debug|info|warning|error
+```
+
+As of release version 0.2 only single `type` is supported which is `IMS`. Any other value would result in termination
+of processing with accompanying message on console.
+
+### 3.1.1 Hidden CLI features
+
+For debugging and research possibilities couple of 'unofficial' command line arguments are present which are given below.
+* `--plot` - create HTML files consisting graphs of the following processing properties - processing velocity,
+chirp signal, doppler centroid and scene geolocation properties on earth
+* `--intensity` - create GeoTIFF files of the raw measurements, range compressed results and fully compressed intensity
+
+All the created files would be saved in the same directory as the final product given by the `output` argument. They are
+prefixed with the level 0 dataset name pattern.
+
+### 3.1.3 Examples
+
+During the production and internal tests there are so called test datasets (TDS) packages used. This is not required
+and one could simply have manually assembled the collection of suitable orbit files and auxiliary files downloaded as
+a bundle on online at available ESA sites (see [ERS](https://earth.esa.int/eogateway/instruments/sar-ers/auxiliary-data)
+and [ENVISAT](https://earth.esa.int/eogateway/instruments/asar/auxiliary-data)).
+Both of the scenarios are supported. Below are given examples for both.
+
+**Manually assembled datasets**
+```
+asar_focus --input SAR_IM__0PWDSI19920904_101949_00000018C087_00294_05950_0000.E1
+--aux ers1_aux_dir
+--orb ers1_pds_orbit_dir -o /home/foo/ -t IMS
+```
+
+**TDS**
+```
+asar_focus --input
+TDS09/ASA_IMS_1PNESA20040229_212506_000000152024_00387_10461_0000.N1/
+ASA_IM__0PNPDK20040229_212454_000000492024_00387_10461_2585.N1
+--aux TDS09/ASA_IMS_1PNESA20040229_212506_000000152024_00387_10461_0000.N1
+--orb TDS09/ASA_IMS_1PNESA20040229_212506_000000152024_00387_10461_0000.N1/
+DOR_VOR_AXVF-P20120424_125300_20040228_215528_20040301_002328
+--type IMS --output /home/foo/ --sensing_start 20040229_212504912000
+--sensing_stop 20040229_212523002000
+```
+
+## 3.2 Input datasets
+
+Single level 0 **envisat format** ERS-1/2 and Envisat mission dataset is required. As of version 0.2 only imaging mode
+datasets are supported. The specification is given in document `PO-RS-MDA-GS-2009 4/C`.
+
+## 3.3 Auxiliary files
+
+As of version 0.2 the following auxiliary files are used:
+* DORIS orbit files in envisat format, see [DOR_VOR_AX](https://earth.esa.int/eogateway/catalog/envisat-doris-precise-orbit-state-vectors-dor-vor_ax-)
+* Processor configuration file (ASA_CON_AX/ER_CON_AX)
+* Instrument characterization file (AUX_INS_AX/ER_INS_AX)
+* External calibration data (ASA_XCA_AX/ER_XCA)
+
+For auxiliary file access and documentation please visit [ERS aux](https://earth.esa.int/eogateway/instruments/sar-ers/auxiliary-data)
+and [ENVISAT aux](https://earth.esa.int/eogateway/instruments/asar/auxiliary-data) pages at ESA.
+
+# 4 Requirements
+
+Below are specified minimum requirements for hardware. It is based on the resources needed to focus 16 seconds of
+level 0 imaging mode dataset. Resource like CPU is out of scope, because all modern CPUs are suitable. Disk storage
+resource is dismal, since only level 1 dataset storage is required also no intermediate files are stored
+(except for debugging features discussed in [3.1.1 Hidden CLI features](#311-hidden-cli-features)).
+
+| Property | Value |
+|------------------------|--------|
+| RAM | 4 GB |
+| GPU (V)RAM | 4 GB |
+| NVIDIA CUDA generation | CC 6.0 |
+
+For specific compute capability and NVIDIA GPU models, please see [CUDA wikipedia page](https://en.wikipedia.org/wiki/CUDA#GPUs_supported).