Collaborative Workflows — IGW-NET in the Ecosystem

29.1 The Collaborative Dimension of IGW-NET

Most of this manual covers individual modeling — how one person builds, runs, and analyzes a model. But IGW-NET is also a collaborative platform. Understanding the collaborative dimension changes how you approach your own work.

29.1.1 Why collaborative matters

A model built in isolation has limited value beyond the immediate modeler. A model built with the collaborative ecosystem in mind has:

• Discoverability — others can find it when working on related problems
• Review — regulators and peers can inspect it at the model-file level
• Reusability — future modelers can adapt it as a starting point rather than rebuilding from scratch
• Accumulated value — each published model contributes to an ongoing collective understanding of groundwater systems in its region

The MAGNET4WATER vision — groundwater modeling becoming a shared, learning system rather than an atomistic series of one-off projects — depends on collaborative practices. IGW-NET's features support this vision: structured model files that others can read, integrated publishing workflow, shared data services, cross-platform coordination.

29.1.2 What this chapter covers

Four practical activities:

• Understanding the Observatory — what it is, how to use it, how your work connects to it (§29.2)
• Publishing — the mechanics and best practices for sharing completed models (§29.3)
• Discovering — finding and adapting published models for your own work (§29.4)
• Team and cross-platform workflows — working with collaborators and with the broader MAGNET4WATER ecosystem (§29.5-§29.7)

The chapter closes (§29.8) with a reflection on the foundational principles that span this manual.

29.2 The Observatory — Integrated Information Layer

The MAGNET4WATER Observatory is the ecosystem's integrated information layer. Understanding it helps orient your modeling work within the broader platform.

29.2.1 Scale and scope

The Observatory spans approximately 43 countries and approximately 143 cities, integrating:

• Published models — IGW-NET models shared by other users, organized by region and topic
• Datasets — curated spatial datasets (DEMs, K, recharge, hydrography) accessible through the Data Center (Ch. 23)
• Workflow examples — case studies, tutorials, and published analyses showing how the platform has been used
• Cross-platform context — how IGW-NET work relates to SwaNET, StormNET, ConduitNET, and DataNET activity in the same region

This isn't a passive catalog — it's a live integration. Model publications update the Observatory; new datasets expand the Data Center; new case studies appear as they're completed.

29.2.2 What the Observatory is useful for

Several typical uses:

• Orientation before starting a model. Before building a new model, check the Observatory for your region. Is there an existing published model you can adapt? Are there datasets specific to your area? Has similar work been done nearby?
• Strategic context. Understanding the ecosystem scope — approximately 43 countries, approximately 143 cities — helps communicate the value of individual work. Your model isn't just one model; it's a contribution to a larger collective effort.
• Public engagement. The Observatory is the public face of MAGNET4WATER. For outreach to policymakers, educators, and non-technical stakeholders, the Observatory provides the framing that individual technical work alone cannot.
• Discovery of related work. Browse published models to see what patterns and methods other modelers are using. Learning from peers is often more efficient than learning from reference documentation alone.

29.2.3 Accessing the Observatory

The Observatory is accessible from the main MAGNET4WATER site at https://www.magnet4water.net/observatory. It's also reachable from within the IGW-NET interface — Utilities and Analysis tools include pathways to relevant Observatory content. As you build and publish models, your work becomes part of what others discover through the Observatory.

29.3 Publishing a Model

Model Publishing is IGW-NET's feature for sharing completed models with the Global Model Network. This section covers the mechanics and the practices that make publishing valuable.

29.3.1 The Model Publishing dialog

Access via Utilities → Model Publishing Options. The dialog accepts:

29.3.2 Before you publish — quality checks

The Global Model Network is a shared learning resource. Published models should be ready for inspection. Before publishing, run these checks:

• Structure-first check (Ch. 18 §18.1.3) — is the model structurally sound? BCs placed correctly? Layering appropriate? Features at right scale?
• Mass balance check (Ch. 25 §25.4) — does the water budget close?
• Calibration quality (Ch. 18) — if the model is calibrated, is the fit documented? Are multiple targets used to break non-uniqueness?
• No obvious errors (Ch. 25) — no flooded domains, no unreasonable flow directions, no pattern inconsistent with the site understanding
• Units verified — especially recharge (the 10×-rainfall pitfall, Ch. 14 §14.7)
• Documentation completeness — the model description should cover what the model does, what it's for, what its limitations are

29.3.3 What makes a publication valuable

29.3.4 What the Global Model Network does with your model

After publication:

• Your model becomes searchable by name, description, region, and topic
• Other users can load it as a starting point for their own work
• The model contributes to the Observatory's regional context for your area
• Reviewers (regulators, researchers, students) can inspect the model-file level details
• Feedback and citations accumulate over time, making some published models benchmark references

You retain ownership of the work; publishing adds discoverability without transferring rights. Users who adapt your model typically acknowledge the source.

29.4 Discovering and Reusing Published Models

The flip side of publishing: using what others have published. The Global Model Network becomes more valuable as discoverability and adaptation workflows mature.

29.4.1 When to look for an existing model

Before building a new model, consider whether an existing one would help:

• Same region, different question — another modeler's regional model for your area gives you the domain, grid, layering, and calibration as a starting point; you adapt for your specific question
• Similar problem type, different region — a contaminated site study in a different region shows the pattern and structure you'd use; you transfer the setup approach and populate with your local data
• Teaching or learning — published models are the best examples for seeing how experienced modelers structure specific kinds of problems
• Benchmark or validation — a published model with extensive calibration can serve as a reference that your own work is consistent with

29.4.2 The discovery workflow

Through the IGW-NET interface or the Observatory:

1. Search by region — find models within your geographic area of interest
2. Search by topic — filter by problem type (contamination, water supply, coupled SW-GW, etc.)
3. Inspect candidate models — read descriptions, view preview images, check the scope and approach
4. Load promising models — open the model file to see the full configuration
5. Adapt as starting point — use LoadModel to open; modify for your specific problem; keep or change structural elements as needed

29.4.3 Adaptation practices

When adapting a published model:

• Understand before modifying. Take time to read the original description and inspect the structure before changing anything. Don't randomly tweak inputs on a model you don't understand.
• Preserve the structural skeleton if it fits. Domain, grid, layers, BC placement — these are often well-chosen and worth keeping.
• Refresh the parameters for your setting. K, recharge, observations, feature locations all need to match your specific site, not the source model's.
• Re-calibrate as needed. A calibrated model for one site is a starting point for another, not an answer.
• Acknowledge the source. When you publish adapted work, cite the original model that served as starting point.

29.5 Team Workflows — Multi-User Modeling

Many IGW-NET models are built by teams rather than individuals. Team workflows introduce coordination patterns beyond what single-user modeling requires.

29.5.1 Typical team structures

Some common patterns:

29.5.2 Practical team coordination

Practices that help:

• Single source of truth. One definitive model file at any time; changes tracked with clear attribution. Avoid parallel divergent versions.
• Shared documentation. Model description, assumptions, known issues all written down and accessible to the whole team.
• Structural agreements upfront. Team decides on domain extent, layering, grid resolution, and BC strategy early; these don't change without team consensus.
• Role clarity. Who owns the model state? Who can commit changes? Who reviews before commits?
• Calibration as a team activity (Ch. 18). Target selection, weighting choices, and acceptance criteria benefit from team input, not just primary-modeler decisions.
• Use nested modeling for natural division of labor (Ch. 13). Different team members can own different submodels; the 10-cell buffer rule naturally separates concerns.

29.5.3 When to split into submodels

For large multi-user modeling projects, the nested-model pattern (Ch. 13) is often the cleanest organizational fit:

• Regional lead owns the parent model — domain, regional K, boundary conditions, overall water budget
• Site-specific modelers own submodels for specific features (contaminated sites, well fields, coupled lake-aquifer details)
• Integration checkpoints verify that submodel BCs from the parent remain consistent as the parent evolves

This matches the platform's architecture — nesting is how IGW-NET organizes computational resolution, and it also provides a natural way to organize team responsibilities.

29.6 DataNET for Specialized Data Sharing

DataNET is MAGNET4WATER's data services platform — the fifth platform in the ecosystem, covered briefly in Ch. 23 §23.7 and revisited here for its collaborative role.

29.6.1 What DataNET does

DataNET provides a structured way to share spatial datasets across the ecosystem:

• Publish a dataset — make it discoverable for other modelers
• Transfer into a model — pull a specific dataset into IGW-NET for use
• Track provenance — DataNET imports are tagged in model files (filename prefix dataNetWCS or dataNetmWCS), so reviewers can see exactly what data source was used

This complements the Global Database (bundled defaults curated by the IGW-NET team) with user-driven data contributions. A researcher with a specialized transmissivity dataset for a specific aquifer can publish it through DataNET; other modelers working in the same aquifer can then use it without re-acquiring the raw data.

29.6.2 Typical DataNET use cases

• Regional K compilations — pumping test results compiled across a specific aquifer
• Site-specific borehole lithology — beyond the standard regional databases (Wellogic, etc.)
• Specialized DEMs — LiDAR surveys or proprietary topographic data
• Research-scale dataset integration — bridging published research datasets into IGW-NET-compatible formats

29.6.3 Why the filename prefix matters

When IGW-NET imports a DataNET-sourced raster, the filename begins with dataNetWCS or dataNetmWCS. This prefix is parser-detected and reported in model summaries. Reviewers inspecting a model can see at a glance which inputs came from DataNET transfers versus bundled Global Database defaults versus user-uploaded custom rasters. Data provenance becomes inspectable rather than hidden. See also Ch. 23 §23.7.2.

29.7 Cross-Platform Integration — IGW-NET and the Other Four

IGW-NET is one of five platforms in MAGNET4WATER. Groundwater is one system within the broader water cycle; meaningful water-resource analysis often requires coordination with the surface, stormwater, and piped-flow platforms.

29.7.1 The five platforms

29.7.2 The SwaNET–IGW-NET link

The most common cross-platform link is between IGW-NET and SwaNET — the surface-subsurface water cycle integration.

The handshake: both platforms use the UTM projection, enforced by IGW-NET's UTM Only setting in DomainAttr. Once coordinate systems match, data exchange becomes possible. See Ch. 16 §16.6.3.

The data flow: SwaNET-computed recharge (from overland flow, infiltration, soil moisture) transfers into IGW-NET as spatial recharge input. IGW-NET-simulated groundwater discharge to streams feeds back into SwaNET stream networks as baseflow contribution.

The memorable framing: "SwaNET sees basin; IGW-NET sees aquifer; surface truth meets subsurface truth." Each platform's domain expertise complements the other.

29.7.3 When to keep GW work in IGW-NET alone

Not every IGW-NET project needs cross-platform integration:

• Site-scale contaminant investigations usually work entirely within IGW-NET; the watershed context is background
• Wellhead protection studies are typically groundwater-only
• Regional water budget models may use Data Center recharge rasters directly, without needing SwaNET's dynamic recharge output

Cross-platform integration adds complexity and coordination overhead. Use it when the problem genuinely needs it — when surface water dynamics directly affect groundwater outcomes, or when the groundwater-surface water interface is itself the object of study. See Ch. 16 for a detailed treatment of when IGW-NET's Watershed Solver suffices versus when SwaNET handoff is warranted.

29.7.4 The ecosystem vision

The five platforms together aim to provide an integrated water-modeling environment covering the full cycle — precipitation, overland flow, infiltration, subsurface flow, groundwater discharge, surface water routing, piped flow, stormwater management. No single platform covers the whole cycle; each platform handles its domain well and coordinates with the others through well-defined handshakes.

For individual modelers, the practical implication is that you have choices. You can work entirely within IGW-NET for groundwater-focused problems. You can coordinate with SwaNET when watershed context matters. You can engage with the broader ecosystem for multi-domain problems. The platform scales to the modeling question rather than forcing the modeling question to fit one platform's capabilities.

29.8 Closing — What This Manual Has Tried to Do

The final section of the final chapter. A reflection on what has been built across 29 chapters.

29.8.1 The foundational principles that span the manual

The chapters are organized by workflow, but certain principles show up repeatedly. A closing recap:

29.8.2 The through-line

29.8.3 What the manual is for

This manual has one purpose: help you do good groundwater modeling work with IGW-NET. Good work is more than correct numerics — it's modeling grounded in physical reality, structured for the questions being asked, calibrated with honesty about uncertainty, documented for others to build on, and shared in ways that contribute to the collective understanding.

The chapters approach this from multiple angles: Parts I and II cover the basic workflow to get you productive; Part III covers the advanced features for the hard problems; Part IV catalogs the reference details you'll need during real work; Part V orients you to resources, paths, terminology, and the collaborative dimension. All 29 chapters answer the same question — how do I do good groundwater modeling with IGW-NET — at different levels and for different situations.

29.8.4 An invitation

Reading a manual is one step. The next step is modeling — building models that answer real questions, publishing models that others can learn from, reviewing models that others have built, contributing to the growing collective understanding that the MAGNET4WATER ecosystem supports. This manual ends here; your modeling work begins (or continues) from here.

If something in this manual is unclear, incorrect, or missing, the thumbs-down feedback button on every page tells the documentation team what to improve. If something is missing that should be here, consider writing a concept page or contributing a tutorial. If you publish a model that demonstrates principles in this manual particularly well, it becomes part of the teaching infrastructure for the next generation of IGW-NET users.

The manual is a tool. Your modeling work is what matters. Good modeling.