Although we will be devoting more time to this topic in the blog, many of you are aware that the next generation version of DIRSIG (aka DIRSIG5) has been under development for the past 2 years. This was a ground-up, restart from zero, etc. effort that establishes the DIRSIG modeling toolkit for the next decade.
Around that radiometry core we have built a suite of plugin components that realize the capabilities of the image and data generation model everyone has come to expect from the DIRSIG model. As we describe the DIRSIG5 model in more detail through future posts, we will disclose details regarding how many of the supplied components work. Furthermore, these components utilize application programming interfaces (APIs) that end-users will eventually be able to code against. We strongly believe that this "core + plugin" approach will allow the model to mature without as many growing pains as DIRSIG4 had during it's lifecycle. But the ability for the end-users to develop plugins to more efficiently leverage the software is perhaps the biggest feature of this software design.
Although fidelity is important, the first question on everyones mind is "This sounds exciting ... but how much faster is it?" And this is a question we have struggled to answer concisely during the development because different users have different baselines. In general, we are comfortable stating that the run-time performance is 5x - 20x faster for "non trivial" simulations (DIRSIG4 single-threaded vs. DIRSIG5 single-threaded). And that "non trivial" caveat is because some users configure simulations that disable nearly every radiative transport mechanism that makes DIRSIG a physics-driven, remote sensing image and data model. Therefore, our definition of a "non trivial" simulation includes robust sub-pixel and diffuse illumination sampling. When you factor in parallelization (multi-threading and MPI), the performance increases scale even more.
The short-term limitations reflect that the DIRSIG5 software is still actively under construction. However, these limitations are on the current roadmap to be addressed in future releases.
The long-term limitations reflect use cases that were not implemented in order to focus on a developing a high-performance code for 99% of our active user population.
Key features of the DIRSIG5 model discussed in the paper include:
New core, new approach
Although we have developed a compatibility layer to allow existing DIRSIG4 simulations to run, the DIRSIG5 model is radically different under the hood. The lightweight and highly optimized radiometry core uses a different numerical radiometry (light transport) approach than we used in DIRSIG4. In addition to being faster (less work to get an accurate answer) this algorithm is far better suited for parallelization. As a result, we have implemented micro-scale parallelization (multi-threading on multi-core CPUs) from the start and work on macro-scale parallelization (MPI distribution on cluster-style computing) is getting underway. This radiometry core also has options for GPU acceleration that we are just beginning to explore.Around that radiometry core we have built a suite of plugin components that realize the capabilities of the image and data generation model everyone has come to expect from the DIRSIG model. As we describe the DIRSIG5 model in more detail through future posts, we will disclose details regarding how many of the supplied components work. Furthermore, these components utilize application programming interfaces (APIs) that end-users will eventually be able to code against. We strongly believe that this "core + plugin" approach will allow the model to mature without as many growing pains as DIRSIG4 had during it's lifecycle. But the ability for the end-users to develop plugins to more efficiently leverage the software is perhaps the biggest feature of this software design.
Fidelity and Performance
Although computational performance was an important guide star in this development effort, it was just as important for us simplify the ease of use. DIRSIG4 was very modular, but that modularity also introduced a level of complexity that made it difficult for end-users to correctly apply the model to their problems. In contrast, DIRSIG5 doesn't have the complexity of per-material radiometry solver models or pixel capture methods, etc. to tune. This removes the concerns associated with users poorly configuring the model either do to inexperience or in an misguided effort to manipulate the run time. As a benefit of this unified approach the fidelity of the model output is directly correlated to run-time. If you need a higher quality result, a single knob can be turned on the whole simulation and the run-time will change proportionally.Although fidelity is important, the first question on everyones mind is "This sounds exciting ... but how much faster is it?" And this is a question we have struggled to answer concisely during the development because different users have different baselines. In general, we are comfortable stating that the run-time performance is 5x - 20x faster for "non trivial" simulations (DIRSIG4 single-threaded vs. DIRSIG5 single-threaded). And that "non trivial" caveat is because some users configure simulations that disable nearly every radiative transport mechanism that makes DIRSIG a physics-driven, remote sensing image and data model. Therefore, our definition of a "non trivial" simulation includes robust sub-pixel and diffuse illumination sampling. When you factor in parallelization (multi-threading and MPI), the performance increases scale even more.
Limitations
The DIRSIG5 model has some short-term and long-term limitations compared to DIRSIG4.The short-term limitations reflect that the DIRSIG5 software is still actively under construction. However, these limitations are on the current roadmap to be addressed in future releases.
- Run-time predicted temperatures (THERM) are not supported (yet).
- LADAR/LIDAR modality is not supported (yet).
- Space situational awareness (SSA) type scenarios are not supported (yet).
The long-term limitations reflect use cases that were not implemented in order to focus on a developing a high-performance code for 99% of our active user population.
- The current radiometry core does not track polarization. This was a conscious (and potentially controversial) decision to avoid the computational complexities that would impact performance when modeling unpolarized systems. Although a key feature of DIRSIG4, polarization was only utilized by a small fraction of the user population.
- The current radiometry core does not model real and synthetic aperture radar systems. Although this feature was introduced in DIRSIG4, it was never a mainstream feature. Despite the interest and inquires over the years, RIT was never able to get traction with this modality.
Release timeline
The software has been available to a select set of users for the past year during the development. This user community has helped us steer the development so that a large segment of the user population will find value in the software. And that value will only increase as those missing components of the model are completed. Although the software will still be considered "beta", we will be opening up the access to the software in early 2018. In the meantime, DIRSIG4 is still being maintained, updated and distributed.A journal paper
Over the past year, we have worked to get a new journal paper completed and accepted that will serve as the primary reference for the DIRSIG5 model. And we are happy to announce that this paper is appearing in the November 2017 issue of the IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing (J-STARS, Vol 10, Issue 11). This issue is a "Special Issue on Modeling and Simulation of Remote Sensing Data". The paper is titled "DIRSIG5: Next-Generation Remote Sensing Data and Image Simulation Framework", and it is free to download from the IEEE website.Key features of the DIRSIG5 model discussed in the paper include:
- An introduction to the path tracing radiometry engine.
- A new scene data model that enables significantly faster scene loading.
- The description of a new bi-directional optical property that allows for measured or user-defined BRDF, BTDF or BSDF models.
- Some demonstrations of new features in the provided sensor model plugin, which provides backward support to the DIRSIG4 platform, motion and task files.
Comments
Is anyone out there working with the SAR simulator for DIRSIG. I have some specific questions to ask about the model and if any simulations have been completed for the the Warehouse Scene for stripmap and spotlight modes. Also, in the new release are there any other demos being introduced for the SAR simulation system.
Thank You
Richard L. Tutwiler, Ph.D.
Professor Emeritus
Graduate Faculty
Applied Research Laboratory
The Pennsylvania State University
Phone: 814-360-6675
Email: rlt1@psu.edu
As I noted in the post, the SAR stuff has seen no development in several years. For nearly a decade we fielded frequent requests to add that modality, and yet when we finally invested some time into developing our prorotype capability, that interest vanished. As a result it never really got past the experimental phase. We would need to find some significant funding source and a research partner to make that capability a first-tier capability in DIRSIG. From a research perspective, we felt that the ability to simulate multi-modal datasets (EO/IR and SAR) of the same site, activities, etc. would have great value for data fusion research. If you have ideas on avenues to pursue this modality, please let us know.
I think it's essential to have this capability and I agree on the multi-modal data set capability. I will try to see if I can come up with some ideas on how to collaborate here. Did you guys get this SAR code to image the warehouse scene. If so can you let me know what the results looked like.
Thanks Again
Richard L. Tutwiler, Ph.D.
Professor Emeritus
Graduate Faculty
Applied Research Laboratory
The Pennsylvania State University
Phone: 814-360-6675
Email: rlt1@psu.edu