the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Choosing an operational inference pipeline for internal solitary wave detection in Sentinel-1 SAR imagery: EVA02-Large+XGBoost versus SAR_CNN v2 (Lux.jl)
Abstract. This paper presents a systematic comparative evaluation of two machine learning inference pipelines developed for the Internal Waves Service (IWS), an operational platform for the continuous automated detection of oceanic internal solitary waves (ISWs) in Sentinel-1 synthetic aperture radar (SAR) Wave mode imagery. The IWS ingests imagery from the live Sentinel-1 feed — scaling to approximately 4,000 images per day as the constellation reaches full operational capacity — and is systematically acquiring a historical archive estimated at up to 17 million images back to 2014. The two pipelines compared are a Python pipeline pairing EVA02, a 305-million-parameter pretrained vision transformer, with an XGBoost classifier; and a Julia pipeline built around a 283,329-parameter convolutional neural network implemented in Lux.jl and trained from scratch on domain-specific SAR imagery. Both pipelines were benchmarked across four deployment configurations (each on GPU and CPU) on the service's production server hardware, measuring classification accuracy, inference throughput, GPU energy consumption, and memory footprint. The Python pipeline achieves higher classification accuracy (F1 96.26 % versus 95.00 %; AUC-ROC 99.29 % versus 98.90 %), attributable to the representational capacity of the pretrained vision transformer. The Julia pipeline is 132 times faster on GPU (3,396 versus 25.6 images per second) and consumes 267 times less energy per image (43.7 versus 11,690 mJ), completing a full archive reprocessing pass in 1.4 hours versus 7.7 days. Classification is bit-for-bit identical across GPU and CPU for the Julia pipeline, confirming that the deployment target can be chosen on operational grounds without accuracy trade-offs. Per-image metrics are projected to operational volumes, quantifying annual GPU occupation (2.9 versus 384 hours at the current reprocessing cadence) and throughput headroom for future constellation expansion. Based on these findings, the IWS deploys the Julia pipeline on GPU for all inference, accepting the 1.26-percentage-point accuracy trade-off in exchange for same-day archive reclassification and minimal contention on shared institutional GPU infrastructure. The evaluation methodology — benchmarking on production hardware and projecting to operational volumes — is directly transferable to other Earth observation services evaluating inference pipeline options.
- Preprint
(2044 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 02 Oct 2026)
-
CEC1: 'Comment on egusphere-2026-1798', Astrid Kerkweg, 03 Jul 2026
reply
-
AC1: 'Reply on CEC1', Joao Pinelo, 06 Jul 2026
reply
Dear Astrid,
Thank you for the note. The requested dataset has been deposited in Zenodo:
https://doi.org/10.5281/zenodo.21216576
The Data availability section of the manuscript will be updated to reference this DOI at the next revision, alongside the existing Zenodo record for the code, model weights, and benchmark outputs (https://doi.org/10.5281/zenodo.19322369).
Please let us know if any further action is required from our side.
With best regards,
João Pinelo
on behalf of the co-authorsCitation: https://doi.org/10.5194/egusphere-2026-1798-AC1
-
AC1: 'Reply on CEC1', Joao Pinelo, 06 Jul 2026
reply
-
RC1: 'Comment on egusphere-2026-1798', Anonymous Referee #1, 04 Sep 2026
reply
General comments (an initial paragraph or section evaluating the overall quality of the preprint ):
The article compares two vastly different pipelines (Python EVA02+XGBoost and Julia Lux CNN) in terms of performance, resource usage, and energy efficiency. This is both timely and important for the field, particularly given the growing focus on "Green AI" and sustainable solutions. The article provides a thorough evaluation of performance metrics such as F1-score, AUC-ROC, throughput (images per second), VRAM and RAM usage, and energy consumption. This offers readers a comprehensive data basis for assessing the advantages and disadvantages of each pipeline. The study is firmly grounded in a practical problem: detecting internal solitary waves (ISWs) in Sentinel-1 SAR imagery. This makes the work relevant to applied research and operational systems, rather than merely a theoretical exercise. Pipeline B (Julia CNN) demonstrates impressive energy efficiency and throughput, achieving speeds 132 times faster and energy consumption 267 times lower than Pipeline A (Python EVA02). This illustrates how lightweight models can be extremely efficient for specific tasks.
I have only a few comments/suggestions:
Specific comments (a section addressing individual scientific questions/issues):
The evaluation methodology appears to rely only on a balanced dataset, which may not reflect the actual class distribution in operation settings. In practical scenarios, there is often a heavy imbalance between positive and negative cases, which can give a totally different end result. Has this been tested? Since many decisions in the article are based upon that it should be as close to operational as possible.
Line 342-343 states that each pipeline was profiled over five independent runs and that the results are reported as mean +- std across these runs. However, std values are missing throughout the article, which is important for assessing the variability and robustness of the results. If std is negligible and omitted intentionally, this should be stated in the text.
Limited discussion on what will happen when the number of images increases dramatically in the future regarding the VRAM usage in Julia (correctly if I’m wrong). Will it become a limitation/bottleneck?
Figure 1. It took way too long to decouple everything and get a greater understanding from it.
Technical corrections, typing errors, etc. (compact listing of purely technical corrections ):
Line 293: TTA must be defined.
Please change the order in Table 2 (A-A-B-B) to the same order as written in the text (line 327-337) and Table 3 (A-B-A-B).
Line 474: Explain the abbreviations IW and EW or provide a definition in the text.
Line 512: Provide more context about which pipeline “1.4h” refers to. Would improve the reading flow.
Line 607: EO should be defined
Go over abbreviations on a general basis.
Tables: referred back to the std comment above. Ensure all tables/results clearly state whether the results are averages of multiple runs, and include std where appropriate.
Citation: https://doi.org/10.5194/egusphere-2026-1798-RC1 -
AC2: 'Reply on RC1', Joao Pinelo, 08 Sep 2026
reply
We thank the referee for a careful and constructive report, and for the assessment of the general contribution. We respond to each specific and technical point below, quoting the comment before each response, and indicate the changes we will make in a revised manuscript.Specific comments1. Balanced evaluation versus the operational class distributionThe evaluation methodology appears to rely only on a balanced dataset, which may not reflect the actual class distribution in operation settings. In practical scenarios, there is often a heavy imbalance between positive and negative cases, which can give a totally different end result. Has this been tested? Since many decisions in the article are based upon that it should be as close to operational as possible.The balanced test set was chosen so that the two pipelines are compared under identical conditions: the rankings on throughput, memory and energy are independent of class prior,and the accuracy comparison is measured on the same data for both pipelines. The pipeline selection conclusions therefore stand. A 1:1 partition also makes accuracy directly interpretable without class-weighted metrics, as stated in the description of the test set. And when the paper was submitted the validated archive was in any case too small to fix an operational prior with any confidence, so no defensible rate was available to evaluate against.This has not been tested in the present paper - the prior was not knowable then, and the issue is a real question, important enough to warrant a study of its own. That studyexists: a follow-up paper is a preprint on arXiv (arXiv:2607.07146) and under review at this journal. It quantifies the operational rate - roughly one scene in twenty - shows that a balanced-test score substantially overstates the precision an expert validator actually meets, establishes that the mismatch is an evaluation problem rather than a training one, and answers it with a prior-matched reporting method.In revision we will add a single sentence where the test set is described, noting that the 1:1 partition is not the operational prior and citing the follow-up study, so that areader of this paper alone can find the work that addresses it.2. Missing standard deviationsLine 342-343 states that each pipeline was profiled over five independent runs and that the results are reported as mean +- std across these runs. However, std values are missing throughout the article, which is important for assessing the variability and robustness of the results. If std is negligible and omitted intentionally, this should be stated in the text.Our omission, and we will correct it. The per-run records were retained for every profiled configuration, so the dispersion is recoverable and will be added to all tables reporting timing, throughput and energy.3. VRAM under future growth in image volumeLimited discussion on what will happen when the number of images increases dramatically in the future regarding the VRAM usage in Julia (correctly if I'm wrong). Will it become a limitation/bottleneck?During inference, device memory is determined by model size and batch size, not by the number of images processed, so VRAM does not grow as the archive grows. Host memory in the reported benchmarks does scale with dataset size, because the harness preloads the test set into RAM so that timing is reproducible across runs — 0.25 MB per 256×256 image, giving the 1.5 GB figure for 5,860 images. That preload is a property of the benchmark, not of the pipeline: the operational service classifies vignettes in batches as they arrive. At archive scale the binding constraints are wall-clock throughput and the ingest and I/O path, not memory.4. Figure 1Figure 1. It took way too long to decouple everything and get a greater understanding from it.We accept that it carries too much at once. It will be redrawn - decomposed so that the data path, the two pipelines and the evaluation stage are separable at a glance, with acaption that states what the reader should take from it.Technical correctionsAll accepted.Line 293: TTA must be defined.Will be defined at first use.Please change the order in Table 2 (A-A-B-B) to the same order as written in the text (line 327-337) and Table 3 (A-B-A-B).Table 2 will be reordered to A-B-A-B.Line 474: Explain the abbreviations IW and EW or provide a definition in the text.Both will be defined in the text.Line 512: Provide more context about which pipeline "1.4h" refers to. Would improve the reading flow.It will be attributed to its pipeline explicitly.Line 607: EO should be defined.It will be defined at first use.Go over abbreviations on a general basis.We will make a full pass, each abbreviation defined at first use, with a table of abbreviations if the editor considers it useful.Tables: referred back to the std comment above. Ensure all tables/results clearly state whether the results are averages of multiple runs, and include std where appropriate.Tables will state the number of runs and carry standard deviations, as set out in response to specific comment 2.Citation: https://doi.org/
10.5194/egusphere-2026-1798-AC2
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 90 | 31 | 11 | 132 | 7 | 2 |
- HTML: 90
- PDF: 31
- XML: 11
- Total: 132
- BibTeX: 7
- EndNote: 2
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Dear authors,
w.r.t. the data availability, we can unfortunately not accept the repository where you stored the validation data set (Sentinel-1). Data needs also to be made permanently accessible and therefore needs to be stored in an archive, that provides a doi and guarantees access for at least 10 years.
Therefore please deposit this data (simplest) in an archive that complies with that rules, simplest zenodo.
Best regards, Astrid Kerkweg (GMD executive editor)