A new episode of the Our Alien Earth series from NASA was released! It includes planetary analog field research that we did in Hawaii using LiDAR, and a UV lighting system I made, from 2022. See the full episode at: https://plus.nasa.gov/video/our-alien-earth-the-lava-tubes-of-mauna-loa-hawaii/

View this post on Instagram

Introduction

The planetary stereophotogrammetry and high-resolution surface modeling work I do requires compute resources that span traditional workstation, server, and mobile platforms. Large institutional teams can use, or provide access to, shared clusters or centralized HPC environments. Postdoctoral scientists, graduate students, and small-team investigators often have to assemble and optimize their own compute workflows in order to remain productive.

This post examines a practical, multi-system approach to planetary geospatial processing, focusing on the performance of specific software: Ames Stereo Pipeline (ASP), Agisoft Metashape Professional (Pro), and any interactive Geographic Information System (GIS). Rather than benchmarking a single “best” machine, my goal is to understand how different hardware architectures, such as server-class CPUs, GPU-accelerated desktops, and high-end mobile systems, actually perform under real production constraints. How can these systems be combined effectively within a single research workflow without breaking the bank? What is the most cost-effective solution given the task, or more realistically, several overlapping tasks, for researchers like me who usually have a few irons in the fire at once?

This analysis is grounded primarily in theoretical architectural behavior and operational considerations, but it is intended to be backed up with hands-on testing as these systems are brought into regular use. I am deliberately not relying solely on synthetic benchmarks. I pay particular attention to memory bandwidth, CPU core scaling, GPU utilization, and sustained throughput, since these factors tend to dominate wall-clock time for large digital terrain model (DTM) production and dense photogrammetric reconstruction. The goal is to arrive at a framework for matching workloads to hardware in a way that maximizes productivity without assuming access to institutional HPC resources. I also summarize costs, which matters more than usual right now. As of mid-December 2025, memory prices are roughly four times higher than recent norms, driven largely by demand from large data center deployments. This happens at a very inconvenient time when I need to upgrade because my computers are aging, must meet higher demand, and Windows 10 is no longer supported. My “laptop situation” is also dire. I don’t hate new hardware! However, new hardware is expensive. How can I economically meet my computing performance demands? A high powered laptop would give me more clock cycles and portability, but will it stack up?

Systems Comparison

Photogrammetry and stereo pipelines place fundamentally different demands on compute hardware depending on scale, parallelism, and software architecture. I already have a a GPU-accelerated Ryzen desktop that I built earlier this year. I got a 32 GB DDR5 memory kit for only $192. (Ah, the good ol’ days.) I was considering two Linux systems alongside perhaps a copy of my existing desktop and below is a comparison of specs based on what I could find about all the components:

1. A server-class AMD EPYC workstation
2. A GPU-accelerated Ryzen desktop
3. A high-end System76 Oryx Pro laptop

Table 1. Summary of hardware platforms considered in this analysis.

Category	EPYC 7702 Workstation	Ryzen 9 7900X Workstation	System76 Oryx Pro (oryp13)
OS	Ubuntu 24.04.2 LTS	Ubuntu 24.04.2 LTS	Pop!_OS / Ubuntu 24.04
CPU	AMD EPYC 7702	AMD Ryzen 9 7900X	AMD Ryzen AI 9 HX 370
Architecture	Zen 2 (Rome)	Zen 4	Zen 5 (mobile)
Cores / Threads	64 / 128	12 / 24	12 / 24
Base / Boost	2.0 / 3.35 GHz	4.7 / 5.6 GHz	3.0 / 5.1 GHz
L3 Cache	256 MB	64 MB	32 MB
Memory	128 GB DDR4 ECC RDIMM	128 GB DDR5	Up to 96 GB DDR5
Memory Channels	8-channel	2-channel	2-channel
Sustained Memory BW	170–180 GB/s	70–80 GB/s	60–70 GB/s
GPU	None	2× RTX 3090 (24 GB)	RTX 5070 Laptop
PCIe	128× Gen4	24× Gen5	Mobile-limited
NVMe	SlimSAS Gen4	M.2 Gen4/5	2× M.2 Gen4
NVMe topology	Direct CPU lanes	CPU + chipset lanes	– –
Thermal Environment	Server-class sustained	Desktop sustained	Laptop-constrained

I really like the laptops I saw from System76 specifically because of their Linux OS and AMD CPU offerings. I decided spec out the Oryx Pro because it looked about as close as I could get to the performance of a desktop but still maintain the portability characteristics I would want. I liked my Microsoft laptops, but I wanted to try something different and more aligned with my Linux-based workflow. I replaced Windows with Ubuntu on an inexpensive ASUS laptop, and I like where that was going. [Just to get it out of the way, I’m always had a preference for PCs, so I’ve not considering Apple desktops or laptops.] For simplicity, I’m going to lump Metashape and GIS together because I think the interactive performance outcome for both software packages would be effected similarly by the hardware selections. Metashape can be configured to take advantage of multiple GPUs, there is really no contesting the desktop setup above by the other two systems. This is what the overall performance expectation looks like:

Table 2. Expected relative performance of Metashape Pro steps.

Stage	EPYC 7702	Ryzen + 2×3090	Oryx Pro
Image alignment	Slow	Fast	Fast
Depth maps	x	Extremely fast	Fast
Dense cloud	x	Extremely fast	Fast
Mesh	Slow	Fast	Moderate
Texture	Slow	Fast	Moderate
Sustained runs	N/A	Excellent	Thermally throttled
Rank	3rd	1st	2nd

The Oryx Pro would be a solid laptop and a pretty good portable Metashape processing arm, and because of the multi-core CPU, I could multitask while running jobs. With a minimum of 64 GB RAM added to the system, the price would be $3500 and $3750 maxed out at 96 GB. My desktop total cost was kept under control at < $4k. You can still get the Founder’s Edition RTX 3090 GPUs at a good price on eBay (December 2025), but the memory inflates the cost of another desktop build by $2300. Price alone ruled out another Ryzen system, and if Metashape was all I was considering, the server-class AMD EPYC workstation is obviously ruled out. I could order my laptop and wrap up this post, but I’ve been using a completely different tool lately: the Ames Stereo Pipeline (ASP). A combined laptop & “ASP processing mule” isn’t going to cut it.

I’m been using ASP to build digital terrain models (DTMs) using pairs of images from the Mars Reconnaissance Orbiter Context Camera (CTX). This process leverages the multiple cores in the CPU, not GPU, leveraging parallelized computing. ASP is selectively memory-bandwidth intensive. The most memory-intensive process is stereo matching using parallel_stereo. Correlation involves repeatedly sliding a window across left and right rectified images, reading large amounts of pixels, reading and writing tiles, per-pixel caching, and multi-threaded tile processing. For CTX, images can exceed multiple GB, requiring the processing of millions to billions of pixels.

My Ryzen system is only a 2-channel desktop and therefore is memory-bandwidth bound. Other steps that consume memory and bandwidth include SGM/MGM algorithms, filtering and disparity cleanup, and point2dem. The image normalization, key point detection, bundle adjustment and the pc_align don’t stress the system too much as single core, serial processes. Considering full-pipeline performance, the memory-bound stages dominate runtime, especially for large DTMs.

Table 3. ASP stages and their resource demands.

Stage	Memory-bound?	Notes
Correlation (parallel_stereo)	Strongly yes	Main overall performance
SGM/MGM cost aggregation	Strongly yes	One of the most bandwidth-demanding in computer vision
Filtering/subpixel	Moderately yes	Low arithmetic intensity
point2dem	Sometimes yes	– –
bundle_adjust	No	Compute-bound
pc_align	Mostly not	Compute/latency-bound
Preprocessing	No

From my experience using an array of decent laptops and desktops, I could only expect a system to process one DTM at a time using stereophotogrammetry software, whether that is a multi-view stereo job in Metashape Pro or a planetary image correlation using ASP. Even with my highly spec’d 12-core/24-thread Ryzen desktop, I have found that I’m really only productive doing less intensive tasks (GIS, coding, writing, etc) while running ASP or Metashape in the background. Even if I had a second Ryzen desktop-class CPU (I’d love a Threadripper), I could really only manage ASP to process a second DTM synchronously, maybe a third. How do I get the biggest bang for the buck?

Why EPYC for ASP?

More cores; more threads.

The AMD EPYC 7702 is a powerful 2nd Gen “Rome” 64-core, 128-thread server processor that was first introduced in 2019. If found it at an extremely attractive $500, originally retailing for $7k and still goes for $725 online. It’s been used for data centers needing massive core counts and bandwidth and is known for excellent multi-threaded performance in AI or HPC setups. The EPYC goes in a SP3 socket, so it won’t just slip into a consumer-grade motherboard. If my Ryzen 9 7900X is a baseline with dual-channel DDR5 memory, the high throughput of the EPYC 7002’s eight memory channels is expected to perform 2-3 times faster for a single ASP run and 4-5 times faster processing multiple pairs at once. The next step up might be an EPYC 7742, but this is only 10-15% faster for twice the price.

To make budget, I made use of second hand markets. Like a racing car in an F1 race, CPUs, memory, motherboards, and more are swapped out of server farms and data centers to keep their edge and everyone’s online orders rolling. I really didn’t like what I was seeing online and I was nervous about buying from anyone on eBay. I learned a lot. Did you ever hear of someone opening up an SSD only to find it “light” and a thumb drive wired up in its shell? For example, many cheap second hand chips on the market are engineering or quality control samples (ES/QS) and won’t boot in some boards. Others might be OEM-locked and will only boot in the manufacturer’s server board. Counterfeit labels, polished and repackaged dies, untested, and no meaningful return policy. Although eBay has a good guarantee and return policy, I really didn’t want to deal with a chip DOA. Some of these chips have been running at peak for 3-5 years in a server. That’s a lot of risk, some of which I can’t avoid. I wanted a reputable U.S.-based seller/refurbisher with fair pricing, at least a 30-day warranty, verified production listings, and no OEM-locks.

Motherboard selection was a tougher task. I wanted a Supermicro H11SSL-i, but everything I found was sold overseas. Although the country of origin might not be an issue, I wasn’t going to pay $230 for shipping. The list of motherboards to avoid was LONG. I finally converged on the Asrock ROMED4ID2T Desktop Motherboard; hopefully at build time, I come out on top. This board is rare delivering full EPYC Rome memory bandwidth in a very small desktop form factor. It only has a VGA output, but I’m not planning on using it as a desktop. The Mini-ITX server-class motherboard specs look awesome:

• AMD EPYC 7702 (Rome) processor support
• 8-channel DDR4 RDIMM
• PCIe Gen4
• Dual 10Gb Ethernet
• 6× SATA ports
• 1× PCIe Gen4 ×16 slot
• Slimline connectors for high-bandwidth storage using NVMe drives

More caveats included the right size case, proper cooling, and supporting memory or registered (RDIMM). Memory availability and pricing were a real constraint. I ended up getting RAM from a reseller that didn’t even have it advertised. As soon as it’s visible online, it gets snatched up. I settled on less RAM than I would a year ago, but that’s fine. Theoretically, DDR4 RDIMM is a liquidation commodity as DDR5 steps in. The large supply of DDR4 supply should be pulling price downs, but demand and resulting shortage of DDR5 keep the DDR4 price high and a “premium” in the market. It’s also Christmas. I decided to drop to 16 GB per stick for this platform. It was more important to me to maximize all 8 memory lanes to get maximum bandwidth, which still yields 128 GB. Oh darn.

On a EPYC workstation, everyday uses (application launches, web browsing, python single-thread processing, GIS tools, Blender, etc) might feel slower than the Ryzen desktop. However, the EPYC’s function will be a dedicated ASP production server. This is the build of materials:

• Seasonic Focus GX-750 – $119
• ASRock Rack ROMED4ID-2T – $607
• AMD EPYC 7702 – $500
• Samsung 16GB 1Rx4 PC4-3200A RDIMM ×8 = 128GB – $1,160
• Fractal Design Node 804 – $164
• Noctua NH-U9 TR4-SP3 CPU air cooler – $139
• Micro SATA Cables SlimSAS 4i to M.2 NVMe Adapter – $73 ×2
• Micro SATA Cables SFF-8654 4i → 4i, Gen4, 50cm – $41 ×2
• Samsung 990 EVO 2TB – $177 ×2

Because ASP is CPU-dominated, it should scale with cores and memory bandwidth and perform best as my primary production machine for processing CTX DTMs of large regions and batch processing. The laptop option would produce a DTM at a moderate speed, but it doesn’t fit my use case. Here is a side-by-side comparison of the server and desktop options in terms of expected ASP performance.

Table 4. Expected ASP relative performance comparison.

Aspect	EPYC 7702 server	Ryzen 7900X desktop
Optimal threads per DTM	24-32	12-16
Memory stalls	Low	Moderate-high
Correlation efficiency	Sustained	Drops early
L3 cache stress	Low	Moderate
Single-thread steps	Slower	Much faster
Multi-thread steps	Much faster	Slower
Memory-bound stages	Massively faster	Bottle necked
Large DTMs	Excellent	Struggles earlier
Wall-clock time (large DTM)	Shorter	Longer
Stability at scale	Very high	Moderate
1 DTM	Fast	Fast
2 DTMs	Very efficient	Slows sharply
3 DTMs	Still efficient	High RAM and virtual memory swapping high
4+ DTMs	Stable	Unusable
parallel_stereo, SGM/MGM	Better, 2-3x faster	Fewer cores & 2-channel RAM
Tile-based DEM generation	Better, 2x faster	High throughput requirement
point2dem	Better, 2x faster	parallel & memory heavy
pc_align (large point clouds)	Good thread scaling	– –
Bundle adjust (large DTMs)	Thread + cache advantage	– –
Bundle adjust (small DTMs)	– –	High single-core boost
Aggregate throughput / rank	1st	2nd

Everything about the EPYC server looks amazing, except the relative single-thread performance due to its lower clock speed. I had to realize that a single thread doesn’t mean a single job. A single DTM job in ASP involves 10s of worker threads spawned by parallel_stereo, and each thread is doing memory intensive correlation steps, heavy cache reuse, sustained memory bandwidth, and run times could be are hours to days. CPU clock speed is simply not the limiting factor.

Summary and Conclusion

If I step back from individual components and benchmarks, the main lesson I learned from this exercise is that no single system is well suited to every stage of planetary geospatial processing. ASP, Metashape, and interactive GIS place fundamentally different demands on hardware, and attempting to force all of those workloads into a single box inevitably leads to compromise. In my case, those compromises would have shown up as long ASP runtimes, idle GPUs, or a laptop pushed far beyond what it can reasonably sustain.

What will ultimately make the EPYC system compelling is not peak clock speed or theoretical performance, but the ability to sustain throughput across memory-intensive workloads and to scale efficiently when running more than one DTM at a time. For ASP, the limiting factor is not a single fast core, but the ability to keep many worker threads supplied with memory bandwidth for hours or days at a time. Once I framed the problem that way, the appeal of a server-class CPU with eight memory channels became obvious, even if it might feel slower for everyday desktop tasks.

My Ryzen desktop remains the clear choice for GPU-accelerated work and interactive analysis. Metashape Professional, GIS workflows, debugging, and exploratory processing benefit from high single-thread performance and powerful GPUs, and that system already does those jobs extremely well. A laptop would fill a different role entirely. It is not a replacement for either desktop or server hardware, but it provides portability and flexibility when work has to move out of the office or when smaller jobs need to run without tying up primary systems.

The broader takeaway is that optimization, at least for an independent researcher, is less about finding the fastest machine and more about matching the right hardware to the right task. I should have probably learned this a long time ago from a fellow graduate student in my lab. He was a computer science expert, and he would get his work done on a budget laptop. By separating throughput-heavy processing from GPU-heavy and interactive work, it is possible to get more total productivity out of a collection of modestly priced systems than out of a single, expensive all-purpose machine. This approach is not unique to planetary science, but it is particularly relevant as datasets grow, budgets tighten, and access to shared HPC resources remains uneven.

This analysis represents a starting point rather than a final answer. As my new server comes online and sees real-world use, measured runtimes and practical bottlenecks will refine or challenge some of these expectations. Still, the architectural principles discussed here are unlikely to change. Memory bandwidth will continue to matter for stereo correlation. GPUs will continue to dominate dense reconstruction and AI infrastructure. And thoughtful division of labor across systems will continue to beat one-size-fits-all solutions.

Status and Future Work

At the time of writing, the EPYC-based system described here has been fully specified and components have been acquired, but the system has not yet been assembled and benchmarked. The performance comparisons and expectations discussed in this post are therefore based on architectural analysis, documented software behavior, and prior experience with similar systems rather than direct wall-clock measurements on this specific build.

A follow-up post will document the build process, configuration choices, and measured performance for representative ASP workflows once the system is operational. Those results will either validate or challenge the assumptions outlined here, and will help refine this multi-system approach based on real usage rather than expectation alone.

Note for early-career researchers: This analysis reflects how I am thinking through hardware choices under real constraints, not a finished benchmark study. The EPYC system described here has not yet been built or tested, and performance expectations are based on architectural reasoning and prior experience. A future post will share measured results once the system is operational.

I’ve been making trips to do fieldwork for RISE projects at Kilbourne Hole since the summer of 2017. My contribution has been to provide high resolution topography data to the team using stereophotogrammetry or structure from motion (SfM) methods. Although you can collected more direct measurements of the terrain using LiDAR, I use a methodology that utilizes camera images and differential GPS. The images can be collected from any camera, and the physical dimensions of the subject can be retrieved as long as the parameters of the cameras (positions and angles) meet the requirements for SfM.

What’s the subject in the images? Our primary target is the geology, but at what scale are we interested? What features? And what is the science question we want to answer once we have all of the geometric and morphometric data? The answer is different for every person who goes out to study Kilbourne Hole. The very smallest scale of observations is of interest, such as the grain size of ash particles from the eruptions that created Kilbourne Hole. For others, it’s the layers of ash or stratigraphy of the deposits. My most recent interest is the layers of lava that the eruptions blasted through and time has covered up by thousands of years of sedimentary deposition. Others care about the general large-scale similarity of the terrain to a lunar crater, making it a unique planetary analog for testing the procedures of exploration in an unfamiliar environment on another planet or the Moon. My attempts have been to provide data at all of these scales, but this has resulted in various levels of ‘meh’ and success.

My most successful pursuit was the collection of image data from small unmanned aerial vehicles (sUAS) and the subsequent creation of digital elevation models (DEMs) and orthomosaics (simply geometrically well-constrained overhead imagery) at very high spatial resolution. My high resolution, I mean small cm-scale pixel size or ground sampling distance (GSD). In this case, every pixel is between 3 and 8 cm, depending on sUAS altitude. The large scale topography of Kilbourne Hole is already available from the USGS 3D Elevation Program, and it’s a great dataset with sub-meter detail available for large parts of the United States. When the RISE project started, we hadn’t yet discovered the 3DEP data or it might not yet have been available. So, our methodology was to pursue the use of sUAS and terrestrial LiDAR scanning (TLS) to provide the data. TLS is ‘bonkers’ high resolution, generally sub-cm resolution depending on the range distance. I can produce data of similar quality as TLS using SfM for limited areas, but certainly not at the speed, efficiency, and accuracy as TLS. The 3DEP LiDAR datasets are collected from an airplane, so the range from the target is substantially larger than TLS or SfM, and the efficiency and cost-effectiveness are fantastic. All of these datasets have exceptional advantages or qualities, but between the scales of 3DEP and ground-based TLS operations, sUAS fills a gap ideal for answering several science questions.

As I explain in my abstract for the upcoming presentation for the NASA Exploration Science Forum this summer, broader mapping was originally a goal in earlier stages of the RISE projects, but it was nearly phased out due to the large size of Kilbourne and the scope of the actual field activities was smaller. The utility of sUAS-derived data products was demonstrated during the 2023 RISE2 deployment, especially for derived map products for navigation and emerging science questions and themes, such as an analysis of block distribution and Afton basalt thickness. In the field, we realized not only was the entire circumference of Kilbourne Hole needed, but it was possible to obtain given a perfected sUAS concept of operations (CONOP). [You can tell where someone might work based on their use of acronyms.] One of the really cool things about the RISE projects has been meeting new people and graduate students, especially folks from the University of Texas El Paso. In this last field campaign in February 2024, my co-authors from UTEP and I “completed the circle,” acquiring high resolution sUAS imagery of the entire circumference of Kilbourne Hole.

The region of interest that sUAS data covers is specifically for key science questions we have about the margins of Kilbourne Hole. The middle is mainly fluvial and lacustrine deposits, and the other parts are thickly mantled lava flows. Stay tuned for more details and progress reports on this work.

It was amazing to see everyone in person again this year at LPSC 2023. It was the first time I had been to a conference in person since the pandemic. Even though people wore masks and everything appeared to be relatively safe, still a number of people came down with a COVID infection. (To my knowledge, must cases were mild. Although I didn’t hear about anything serious, that doesn’t mean there wasn’t.)

I put a lot of work into two poster presentations of my own and contributed to others as well. Fieldwork in Hawaii yielded some pretty impressive results from an experiment that I designed, built and tested. Here’s a link to the abstract and some cool 360 degree panospheres inside the lava tubes at Mauna Loa!

Ultraviolet-Induced Fluorescence (UVIF) Imaging Experiment Results

Work on mapping fluvial systems on Alba Mons has progressed well and is probably coming to a close. I presented results from that study and preliminary results from Amphitrites Patera. Here’s a link to our abstract and a nice write up on PSI’s website.

Augmented reality could help scientists find microscopic signs of life in the most extreme environments.

Meet Dr. Stephen Scheidt and Dr. Zachary Morse, two scientists putting new field work technology to the test inside Hawaii’s lava caves. pic.twitter.com/hKOpvo2wRN

— NASA Astrobiology: Exploring Life in the Universe (@NASAAstrobio) November 7, 2022

Kilbourne Hole is not a round crater. Its irregular shape could mean that it formed from a series of volcanic steam explosions centered at different locations. This week we’ll use laser ranging tech + other tools to scour ancient layers of ash for evidence. pic.twitter.com/R3VAkE9Q89

— NASA Expeditions (@NASAExpeditions) April 21, 2022

KNaCK combines three different data streams to make detailed maps in real time. Here's how a drone landing looks in all three views: pic.twitter.com/NszzD11quR

— NASA Expeditions (@NASAExpeditions) April 24, 2022

Good morning from Potrillo Volcanic Field! Today team RISE2 is tackling science and exploration objectives at 3 different worksites. Before heading home this morning, these teammates acted as stand-in lunar explorers & made a trip around the crater rim for a science gear handoff. pic.twitter.com/TK1MJpVKOD

— NASA Expeditions (@NASAExpeditions) April 24, 2022

Update: made it through the cattle traffic! Here's part of the team getting ready for a UAV flight at the north rim of the crater. The data they collect will help us to understand the big picture at this worksite. pic.twitter.com/xWKiOda4IW

— NASA Expeditions (@NASAExpeditions) April 21, 2022

It’s a face-off! Who will laugh first? In this battle of the scientists, Uncrewed Aerial Vehicle team lead Stephen Scheidt holds a dGPS camera, and Chemistry/Mineralogy team lead Cherie Achilles holds a spectrometer. pic.twitter.com/zcpjKpMRGO

— NASA Expeditions (@NASAExpeditions) February 2, 2022

It’s not always easy to get a sense of size and distance from aerial or orbital images, but this photo has humans for scale. Can you find Uncrewed Aerial Vehicle pilot-in-command Stephen Scheidt and visual observer Ben Harte? pic.twitter.com/gHmN70SzC9

— NASA Expeditions (@NASAExpeditions) February 2, 2022

https://twitter.com/NASAExpeditions/status/1488229790561841156?s=20&t=OZ0If0X1UAfLbOgm37J9XA

https://twitter.com/NASAExpeditions/status/1488241041731985408?s=20&t=OZ0If0X1UAfLbOgm37J9XA

Future Moon and Mars crews will need to react quickly + accurately to geologic clues during the limited time they’ll have on extraterrestrial surfaces. On this trip, we’ll work towards combining lots of different data streams to make them easier to interpret in real time. pic.twitter.com/9X7BfX2n5x

— NASA Expeditions (@NASAExpeditions) January 31, 2022

Sunset science. Our Uncrewed Aerial Vehicle Team needed to wait until late in the day (or start early in the morning) to do their mapping, to avoid peak visiting hours in Askja Caldera. pic.twitter.com/1YfOhO9M0e

— NASA Expeditions (@NASAExpeditions) December 9, 2021

Back at camp, UAV Team Lead Stephen Scheidt made sure our charging station ran smoothly, so all of our electronic field instruments were powered up and ready to go when we needed them. pic.twitter.com/JM3Xvhi69f

— NASA Expeditions (@NASAExpeditions) December 7, 2021

The UAV Team also continued long-term investigations of Mars-like processes happening on the ground in Iceland. They're monitoring migrating gravel ripples and nearby rocks shaped by wind abrasion. These observations help us understand how the surface of Mars is changing, too. pic.twitter.com/y5DbNrsSyq

— NASA Expeditions (@NASAExpeditions) December 7, 2021

https://twitter.com/NASAExpeditions/status/1467974709274886144?s=20&t=OZ0If0X1UAfLbOgm37J9XA

Tough trucks – and expert guidance from our field leads – helped us stay safe through challenging driving conditions on the way to our field site. pic.twitter.com/8yBhKefxhZ

— NASA Expeditions (@NASAExpeditions) December 6, 2021

Here’s some UAV footage from last year. Spectacular and informative! An overhead look gives us a similar point of view to our Mars orbiters looking at similar features on the red planet, helps us map the properties of the lava, and contextualizes other data we've gathered. pic.twitter.com/B1l9AWLSKd

— NASA Expeditions (@NASAExpeditions) September 12, 2019

Team Topography uses Light Detection And Ranging (LiDAR) and Unmanned Aerial Vehicles (UAVs) to map the volcanic landscape. The team is observing how a new volcanic vent cools and erodes to better understand ancient features on the Moon and Mars. pic.twitter.com/IfaRjh9Q04

— NASA Expeditions (@NASAExpeditions) September 10, 2019

We’re the Goddard Instrument Field Team. We were in Iceland studying volcanic processes to discover what volcanic landscapes might be like on other planets and to figure out what specialized equipment we should bring when we explore our solar system. Here's a week in our lives. pic.twitter.com/WSmRquXLOu

— NASA Expeditions (@NASAExpeditions) September 9, 2019

My main function: analyze geospatial data on the computer. The data show images looking down at Earth and Mars and are interesting to look at: lava flows, sand dunes, river channels, mountains. These are valuable to science, but the patterns and abstractness have artistic value. Many people recognize this and celebrate this by contributing to The Art of Planetary Science Exhibition in Tucson, AZ. There were many submissions from almost a hundred artists, and I’m happy to be one this year in 2018. I carved a HiRISE DTM, my first completed 3D carve of topography. I’m happy with the way it turned out!

Description of Piece: A place on Mars in miniature Fissure and Channel Southeast of Olympus Mons. Carved by a homemade computer numerical control (CNC) milling machine; surface tone painted by hand. Image data were provided by The High Resolution Imaging Science Experiment (HiRISE) camera in orbit around Mars, which were processed into a digital terrain model by the HiRISE Science Team.