Build1 publisher2 min readPublished Updated
NASA and IBM's open lunar model trains one set of weights across a 100-fold resolution gap
NASA and IBM's open lunar model ingests 11 instrument modalities across a 20,000-to-1 resolution range. USRA's account of how those observations were aligned is the part that explains the result.
The Engineer · Build desk
What happened
- NASA and IBM released the NASA-IBM Lunar Foundation Model as an open model on September 10, built for crater mapping, volcanic-feature analysis and research into possible polar ice.
- Pretraining ran from scratch on nearly two million geographically partitioned data bundles spanning 11 modalities, including camera imagery, topography, radar, mineralogy, gravity and illumination geometry.
- USRA's September 18 account credits planetary scientist Rachel Slank with aligning observations from instruments running 1 meter to 20 kilometers per pixel while keeping their physical context.
- For the SomBench evaluation suite, Slank manually identified more than 49,000 craters in Narrow Angle Camera imagery and paired the images with co-registered terrain models.
- The pretrained model matched or beat comparison systems initialized with ImageNet weights and an identical architecture started from random weights, according to the September 8 technical paper.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- contradiction The SomBench paper counts more than 30 co-registered layers from ten instruments across four missions; IBM's release counts nine instruments across the same missions. A team reusing the corpus has to settle which list the published weights actually saw.
- constraint Because the model consumes solar angles and tile coordinates directly, an adopter needs that geometry recorded alongside their own tiles. Imagery without it supplies the network less than it was trained on.
- cost At about 1,100 H100 GPU-hours, the training bill is the easy part to reproduce. The expense sits in cross-instrument alignment and expert annotation, and those hours are labour.
- precedent Shipping a hand-checked crater benchmark next to the weights sets an expectation for the next domain model: on the hardest task, the ground truth is something someone verified by eye, and a held-out slice of the same scrape will not do.
Shadows can dominate a lunar image even when the terrain underneath changes little [6]. The model therefore takes acquisition geometry as an explicit input, including solar angles and tile coordinates, all of it information already recorded with the observation [7]. Of everything in this release, I would copy that first.
The pretraining corpus comes in two pools: 963,609 Wide Angle Camera bundles at roughly 100 meters per pixel, and 1,000,113 Narrow Angle Camera bundles at roughly 1 meter per pixel [9][10]. Add them and the total is 1,963,722 bundles, with the meter-scale pool at 50.9 percent [1][2]. Both scales go through one set of weights [8]. Each bundle can carry surface imagery, terrain measurements and contextual data such as illumination [11]. The instrument suite Slank had to reconcile spans 20,000 to 1 in resolution [5].
Divide the model card's compute figure by eight GPUs and the run is 137.5 hours of wall clock on a single node, under six days [3]. Across the corpus that is about two GPU-seconds per bundle [4]. The scarce input was the label set. At meter scale, small differences in lighting, slope or image resolution can resemble geological boundaries [13], so somebody had to decide where each rim was, and hand annotation does not scale with GPU count. The person drawing them had used Lunar Reconnaissance Orbiter thermal-inertia data during her master's work to investigate possible lunar cavities and lava tubes [20].
The September 8 technical paper evaluates three task families: crater detection at regional and meter scales, segmentation of irregular mare patches, and regression of lunar polar ice prospectivity [17]. The useful control there is the identical architecture trained from random weights, since it separates what pretraining bought from what the architecture bought [18]. For the scores to say anything about another workload, the tiles have to come from the same instruments and be co-registered the same way.
runtimewire reports that the pretraining code is missing and that this limits full reproducibility [19]. That constraint bites harder here than it would on a frontier-scale training run. A group wanting to retrain with a different modality mix or a different tiling scheme is not blocked by hardware, because the published run fits inside a week on one eight-GPU node [3].
What to watch
- Whether IBM publishes the pretraining code, so an outside team can rerun the path from bundles to weights.
- Whether the model card's instrument list is reconciled with the SomBench paper's count of ten instruments.
- Meter-scale crater detection results reported on imagery from outside the Lunar Reconnaissance Orbiter Camera.