Montage 050: a sky made of workflows

The stars in the opening image are the output of a scientific computation. Before the color mosaic existed, individual observations had to be reprojected, their overlaps compared, their backgrounds reconciled, and their pixels combined. AkôFlow coordinates those steps as a workflow and keeps the execution evidence alongside the result.

This field note follows Montage 050, a 58-activity astronomy workflow. We will look at what the activities do, how to reproduce the local example, and what an existing completed experiment tells us about planning and execution.

Start with the image—and its provenance

The cover is the actual 1800 × 1800 color preview from run montage-docker-image-real-20261010-v2. It is a recorded product of a completed hybrid GCP/HPC experiment. Click it to enlarge the image, or open the original PNG.

That experiment and the local reproduction described below use different execution environments. The cover and historical timings establish what the completed hybrid run produced; they are not a claim that the two-slot local example finished in the same time.

The preserved PNG is 4,920,451 bytes. Its SHA-256 is:

63fa4d8447274bdb8a44f6be8cf5a23c0a2f0baa479bd2ae1ec3b541df4e19f2

The image copied into this site matches that checksum. You can download the observed result summary to connect the picture to the run, activity counts, timings, and audit checks.

What Montage does for astronomy

A sky survey records many images rather than a single photograph of an entire region. Those images may use different pixel grids and have different background levels. Simply placing them next to each other would leave misalignment and visible seams.

Montage, developed at IPAC, combines astronomical images while preserving positional and calibration fidelity. Its building blocks operate on FITS files, the scientific image products in this workflow. The color PNG is a visualization of the resulting mosaics; retain the FITS products for scientific analysis.

Three operations explain much of the computation:

• Reprojection: map observations onto a common output grid. The mProject documentation describes the input image, header template, reprojected image, and accompanying area image.
• Background matching: measure overlap differences and solve for consistent corrections. mBgModel uses the fitted differences to estimate a global set of adjustments.
• Coaddition: combine corrected observations into mosaics. The Montage module guide describes the tools for metadata generation, reprojection, background correction, and mosaicking.

Here, twelve input FITS observations feed three image-band branches. Each branch produces a FITS mosaic and a monochrome preview; a final activity combines the three mosaics into the color preview.

Which Montage example and which public data?

This example is Montage 050, preserved in the original image as 050d. The identifier names the workload configuration; it does not mean that the graph contains 50 activities. Section 4.1 and Table 1 of the AkôFlow paper, SBBD 2024, describe the smaller “0.5” configuration with the same inventory used here: 12 projections, 18 overlap fits, and 58 activity executions in total. The paper also evaluates a larger “1.0” configuration with 472 executions. This walkthrough uses the smaller one. The bundled FITS header templates define its actual output footprint and pixel grid.

The inputs are real, publicly accessible astronomical survey images, rather than generated test pictures. Their names identify the POSS2/UKSTU survey products distributed through the Digitized Sky Survey (DSS) archive at IRSA. DSS digitizes photographic survey plates from the Palomar and UK Schmidt telescopes; IRSA provides image access and links to the originating STScI archive. The IRSA dataset summary documents that survey lineage. Public access does not remove the archive's attribution and copyright requirements; retain the DSS/STScI and original survey acknowledgments when reusing the images.

The pinned bundle contains four input tiles in each of three survey bands:

Branch	Source filename family	Source band	FITS mosaic	Display channel in the final PNG
1	poss2ukstu_blue_*.fits	Blue	1-mosaic.fits	Blue
2	poss2ukstu_red_*.fits	Red	2-mosaic.fits	Green
3	poss2ukstu_ir_*.fits	Near infrared	3-mosaic.fits	Red

That is 12 FITS inputs, approximately 87 MiB in the image's input seed. The RGB assignment is a visualization choice: the red survey band is displayed in green, and the infrared band in red. Read the scientific FITS products and their headers when interpreting measurements; PNG colors alone do not identify an observing wavelength.

The exact command and file inventory is available in the pinned workflow.yaml. Keeping that revision and the container digest identifies the packaged input set used for reproduction. Acquiring a fresh cutout from the public archive may select different pixels or preprocessing, so it is a new input set to record explicitly.

Inside the 58-activity graph

The local bundle preserves the original commands, activity names, and 138 named file handoffs. Its activity inventory is:

Native command	Activities	Responsibility
mProject	12	Reproject the input observations
mDiffFit	18	Compare overlaps and fit their differences
mConcatFit	3	Assemble fit results for each band
mBgModel	3	Solve each band's background corrections
mBackground	12	Apply corrections to the projected observations
mImgtbl	3	Build metadata tables for corrected images
mAdd	3	Coadd the three FITS mosaics
mViewer	4	Produce three monochrome previews and one color preview
Total	58

The diagram below comes from the local example's activity and dependency contract. Enlarge it to follow individual edges.

Montage 050 locally. Nodes in the same column can run in parallel once their dependencies complete.

Independent projections and overlap operations can run concurrently after their own inputs are ready. Background modeling introduces a convergence point within each band. The final color preview waits for its three mosaic inputs. There is no extra global barrier forcing an unrelated band to wait at every stage.

This is why the DAG matters: it encodes scientific dependencies. A scheduler can choose where ready work runs, but cannot skip an input merely to make the graph appear more parallel. The Montage parallelization guide explains the relationship between independent image operations and background-model convergence.

What each activity does, and what its parameters mean

The scientific design follows Jacob et al., Montage: a grid portal and software toolkit for science-grade astronomical image mosaicking, especially its toolkit components and workflow discussion. Reprojection aligns the pixel grids; overlap fitting supplies evidence for background adjustments; corrected images are then coadded. The sections below combine that explanation with the module manuals and the actual arguments in this example.

An activity type, such as mProject, can have several executions in the graph. Here, the same processing chain repeats for three bands. The examples below show the first band unless noted otherwise. They run inside an activity workspace after AkôFlow has staged the declared inputs; copying one command into an empty directory is not a complete reproduction.

mProject: put one observation on the common sky grid

mProject -X poss2ukstu_blue_001_001.fits pposs2ukstu_blue_001_001.fits region-oversized.hdr

Each of the 12 executions reprojects one observation. It maps input pixels through sky coordinates onto the requested output grid, accounting for pixel overlap rather than merely resizing a picture. Its outputs include the projected FITS image and an accompanying _area.fits coverage image.

Parameter	Meaning in this example
-X	Expand the template region as necessary to retain the input image's extent.
poss2ukstu_blue_001_001.fits	Input observation.
pposs2ukstu_blue_001_001.fits	Projected output; the p prefix is this workflow's naming convention.
region-oversized.hdr	FITS header template defining the working grid, coordinate projection, reference coordinates, and pixel scale. It is used before the final mosaic footprint is applied.

These tasks have no predecessor activities and can start independently when execution slots are available. See the official mProject manual.

mDiffFit: measure how two projected images disagree

mDiffFit -d -s 1-fit.000001.000002.txt pposs2ukstu_blue_001_001.fits pposs2ukstu_blue_001_002.fits 1-diff.000001.000002.fits region-oversized.hdr

The 18 executions compare overlapping pairs: six pairs among the four images in each band. mDiffFit combines image differencing (mDiff) with a plane fit (mFitplane). It measures relative background offsets and gradients that the next stages need.

Parameter	Meaning in this example
-d	Enable diagnostic output.
-s 1-fit.000001.000002.txt	Write the structured fit/status result for this pair to a named file.
The two pposs2ukstu_…fits arguments	Projected images to compare; both projection tasks must finish first.
1-diff.000001.000002.fits	Difference-image path used by the combined operation.
region-oversized.hdr	Shared working-grid template.

Different pairs can run concurrently after their respective inputs arrive. See the Montage grid-tool description and mDiffFit implementation and command interface.

mConcatFit: gather the pairwise measurements

mConcatFit 1-stat.tbl 1-fits.tbl .

There are three executions, one per band. Each gathers the individual overlap-fit records into the table required by background modeling. It combines fit parameters, not image pixels.

Parameter	Meaning in this example
1-stat.tbl	Input table identifying the fit-result files to collect.
1-fits.tbl	Output table of pairwise fit measurements.
.	Directory containing those staged fit-result files: the current workspace.

This task waits for the band's six mDiffFit executions. The grid-tool guide explains why independently generated fit records need this merge; the mConcatFit source documents its three positional arguments.

mBgModel: solve a consistent background model for the band

mBgModel -i 100000 1-images.tbl 1-fits.tbl 1-corrections.tbl

The three executions use the overlap measurements together to find per-image background corrections. A global solution within each band avoids treating each seam as an unrelated adjustment. The result is a correction table; the image pixels are changed by the following activity.

Parameter	Meaning in this example
-i 100000	Iteration count requested by this versioned workload's modeling command; it is not a timeout or CPU allocation. Preserve it when reproducing the pinned example.
1-images.tbl	Input image metadata and identifiers.
1-fits.tbl	Aggregated measurements from mConcatFit.
1-corrections.tbl	Output coefficients for correcting each image's background.

This is a convergence point for each band. Other bands can progress independently. The official mBgModel manual explains the solver and its arguments; documented iteration limits can differ from the packaged command, so the pinned image remains the reference for this reproduction.

mBackground: apply the correction to one projected image

mBackground -t pposs2ukstu_blue_001_001.fits cposs2ukstu_blue_001_001.fits 1-projected.tbl 1-corrections.tbl

Each of the 12 executions subtracts the fitted background plane from one projected image. In the module's model, the plane has the form A*x + B*y + C. This matches relative backgrounds while retaining the image for coaddition; it is not a command to remove every astronomical source or all diffuse emission.

Parameter	Meaning in this example
-t	Table mode: obtain the image's correction coefficients from the supplied tables rather than three explicit coefficient arguments.
pposs2ukstu_blue_001_001.fits	Projected input image.
cposs2ukstu_blue_001_001.fits	Background-corrected output; c is the workflow's naming convention.
1-projected.tbl	Metadata table used to identify the projected image.
1-corrections.tbl	Per-image corrections produced by mBgModel.

Corrections for different images can run concurrently once their band model and projected inputs are ready. See the official mBackground manual.

mImgtbl: describe the corrected files for the coaddition step

mImgtbl . -t 1-corrected.tbl 1-updated-corrected.tbl

The three executions read FITS headers and create metadata tables. Those tables describe image geometry and file identity so that coaddition can place the corrected inputs correctly. This stage produces metadata, not another mosaic.

Parameter	Meaning in this example
.	Directory in which to read the corrected FITS files.
-t 1-corrected.tbl	Restrict processing to the images named in this input list, rather than every FITS file in the workspace.
1-updated-corrected.tbl	Output table with the corrected files' header metadata.

Each task waits for its band's four corrected images. The official mImgtbl manual documents the table fields and selection option.

mAdd: coadd the corrected observations into one FITS mosaic

mAdd -e 1-updated-corrected.tbl region.hdr 1-mosaic.fits

The three executions create one scientific mosaic per band from the corrected, aligned images. Coaddition combines contributions where pixels overlap; it is not concatenation of files or an RGB operation. Montage also produces an area/coverage mosaic.

Parameter	Meaning in this example
-e	Use the exact dimensions in the final header template instead of shrinking the mosaic to the data's bounding region.
1-updated-corrected.tbl	Metadata table selecting the images to coadd.
region.hdr	Final mosaic template, as distinct from the oversized working template used earlier. The recorded output is 1800 × 1800 pixels.
1-mosaic.fits	Output scientific mosaic for this band.

No averaging-mode override (-a) is supplied in this command. The official mAdd manual describes the coaddition modes and area-image behavior.

mViewer: turn scientific mosaics into viewable PNGs

The first three executions render one preview per band:

mViewer -ct 1 -gray 1-mosaic.fits -1s max gaussian -png 1-mosaic.png

Parameter	Meaning in this example
-ct 1	Select color-table index 1 for the single-band display.
-gray 1-mosaic.fits	Read one FITS image for single-band rendering.
-1s max	Set the display range using a sigma-based lower bound and the maximum as the upper bound.
gaussian	Use Gaussian histogram-based stretching for display.
-png 1-mosaic.png	Write the rendered PNG.

The fourth execution builds the color preview after all three mAdd tasks finish:

mViewer -red 3-mosaic.fits -0.5s max gaussian-log -green 2-mosaic.fits -0.5s max gaussian-log -blue 1-mosaic.fits -0.5s max gaussian-log -png mosaic-color.png

Here, -red, -green, and -blue assign FITS mosaics to display channels. Each receives its own -0.5s max range and gaussian-log stretch. -png names the final output. These choices control visualization, not the calibrated FITS pixel values.

The official mViewer examples describe these interfaces. Berriman and Good's visualization paper explains the scientific visualization context. The three single-band previews and the color preview are sibling consumers of the FITS mosaics: the color task does not need to wait for the preview PNGs.

Scientific parameters and execution settings are different

The command arguments above determine image processing and file products. The YAML also supplies AkôFlow settings such as cpuLimit: 1000m (one CPU), memoryLimit: 1Gi, the selected runtime, and dependsOn. Those govern execution placement, limits, and readiness; they are not flags passed to Montage. workspaceSeedPath identifies the packaged seed, while historical simulation.durationSeconds values support planning and do not measure a new real execution.

Reproduce the workload locally

If this is your first AkôFlow experiment, begin with the Desktop walkthrough. It teaches definitions, environments, scopes, plans, and runs with a tiny local workload.

The full Montage bundle adds a command-line preparation and execution path. Have Git, Go 1.23 or newer, and Docker with linux/amd64 support available. Keep at least 15 GiB of free disk for the image and intermediate workspaces. Retention and concurrency affect the peak requirement. Apple Silicon runs this amd64 workload through emulation and may take substantially longer.

1. Get the versioned example

git clone https://github.com/UFFeScience/akoflow-examples.git
cd akoflow-examples
git checkout --detach d890c3171e3661890305b763b8fc3ede48bb61b4
cd scientific-workflows/montage-050

Pinning the checkout makes this walkthrough refer to a specific example revision. The bundle README documents its requirements and commands.

The bundle contains workflow.yaml, environment.yaml, scope.yaml, and topology.yaml, plus preparation, execution, and validation scripts. The workflow retains historical simulation durations as model inputs. Use the provided runner or daemon helper for the real workload; importing that source YAML alone is not the complete real-execution setup.

2. Prepare the image and inputs

./prepare.sh

Preparation obtains the pinned image and Go dependencies, and checks the command/input contract. The image includes approximately 87 MiB of source FITS data, region headers, lookup tables, and the native Montage tools. There is no need to locate twelve observations manually.

The upstream image is pinned by digest:

ovvesley/akoflow-wf-montage@sha256:26b060b83b990557ea86ab40503cc8f17ab6016b5973e7e6f9201100a96440c9

Preparation success establishes that the inputs and commands are available. It does not mean all scientific activities have executed.

3. Execute the complete local DAG

./run.sh

The standalone runner uses two CPU slots by default. Each activity becomes eligible once its dependencies finish and a slot is available. It copies the bundled input seed, executes the native commands with network access disabled, and writes activity observations under outputs/.

This path provisions no cloud machines and needs no remote HPC account. It is a substantial scientific workload: allow it to finish rather than interpreting a slow projection as a completed run.

4. Validate and open the products

./validate.sh

Inspect the final files in outputs/:

Product	What it gives you
1-mosaic.fits, 2-mosaic.fits, 3-mosaic.fits	Three 1800 × 1800 scientific mosaics
1-mosaic.png, 2-mosaic.png, 3-mosaic.png	Monochrome visual previews
mosaic-color.png	Combined color preview
manifest.json	Generated artifacts and SHA-256 digests
dag-validation.json	Dependency-wave validation
stage-<activity>.json	Per-activity observations

The validator checks all 58 activity records, FITS dimensions, and PNG headers. A successful manifest is published only after the workflow and final-file checks pass. Merely finding one intermediate image is insufficient to declare the experiment complete.

Inspect a daemon-managed run in Desktop

The bundle also supports a daemon helper that registers the local environment, builds the declared image, and submits the 58 activities to the engine. This advanced path requires a daemon whose API address and token you manage; follow API connection setup. The graphical Desktop installation keeps its internal credentials managed by its proxy—do not assume that it exposes a shell token.

From the example directory, with that daemon connection configured:

go run ../../tools/daemon-local -root ../.. -example scientific-workflows/montage-050 -wait=false

The command prints the submitted run ID and returns while execution continues. Connect Desktop to that same instance and open the run. Inspect its activity DAG, file handoffs, logs, and completion status. The daemon owns execution and transfers; the standalone runner's outputs/ directory belongs to the separate standalone path.

What the completed hybrid experiment observed

The following results come from the preserved completion record for montage-docker-image-real-20261010-v2, dated by that run's identity. Its topology comprised ten GCP e2-micro instances, two e2-medium instances, and eight HPC activity assignments. This is a historical experiment, not the local two-slot configuration above.

Evidence	Recorded result
Completed activities	58 / 58
Failed activities	0
Successful runtime handles	58
Missing dependency routes	0
Transfer-barrier violations	0
Unreleased consumer leases	0
Overlapping activities on single-lane micro instances	0
Final PNG dimensions	1800 × 1800

The preserved record also distinguishes three timing scopes:

Timing	Seconds	Approximately
Planned makespan	3,617.94	60.3 min
SimGrid makespan	3,617.50	60.3 min
Real API-reported makespan	6,924.25	115.4 min
Run timestamp wall interval	6,949.00	115.8 min

The real API-reported makespan was about 1.91× the planned estimate. That is an observation from this run, not a general slowdown factor. Close agreement between the plan and simulation did not establish that the real distributed execution would match either prediction.

The accompanying results record identifies whole-workspace traffic and different planned edge volumes as a comparability limit. Summed transfer or compute work can overlap across activities and is not the same as wall-clock makespan. Likewise, a zero reported interference value cannot establish that physical contention was absent.

The recorded cloud compute-and-boot-disk lifecycle estimate was USD 0.3532 at the experiment's list rates. It excludes network egress, public IPv4, reusable image storage, discounts, and tax, and assigns no calibrated monetary tariff to HPC. It is an estimate, not a provider invoice or a current price quote. Other cost fields in the JSON use different task/window scopes and should not be treated as equivalent bills.

Download the result summary and its limitations. The repository preserves the original completion record and detailed results.

What is—and is not—verified for the local bundle

The checked-in local image contract was validated on 2026-10-20: twelve FITS inputs, 58 activities, and 138 named handoffs. That record explicitly states fullExecutionPerformed: false. Its separate daemon snapshot recorded a running workflow with zero completed activities at capture time. These are historical snapshots; neither establishes the current state of another instance.

The completed hybrid run supplies the mosaic and the results in this article. To claim a completed reproduction on your machine, retain your own successful validator output, activity records, and output manifest. The local showcase page links the checked-in contract and daemon evidence.

Keep the experiment with the picture

The mosaic is the visible result, but the research artifact includes more: input identity, native commands, the dependency graph, resource assignments, file transfers, and output digests. Together, they explain how the image was produced and where a later execution differs.

AkôFlow's original paper provides the research context: Ferreira et al., AkôFlow: um Middleware para execução de Workflows científicos em múltiplos ambientes conteinerizados, SBBD 2024, pp. 27–39. Read the publication.

Continue with the complete local example, the Desktop first experiment, or planning alternatives. When comparing placements, preserve the scientific workload and change the execution environment deliberately, so the measurements remain interpretable.