OWP FIM

From: https://github.com/NOAA-OWP/inundation-mapping/wiki/3.-HAND-Methodology

Executive summary

The generation of flood inundation maps is expensive, technically demanding, and heavily dependent on geography and user specified inputs. With the advances of the National Water Model and geospatial approximations to the hydraulic sciences, the ability to generate flood inundation maps via a Height Above Nearest Drainage and Synthetic Rating Curve library was realized. This technique is used in NOAA Office of Water Prediction operational flood forecasting as the FIM4 HAND libraries sheparded by the National Water Center. See the repo and accompanying wiki for more details.

Quick Links

Codebase | NWS Flood Inundation Mapping Services StoryMap | Public FIM | OWP | Data page

Intro

As one of the first methods of tying the National Water Model to a flood map, the once NFIE then CFIM > FIM2 > Cahaba (FIM3) > GMS (FIM4) codebase is the Office of Water Predictions default means of creating FIM libraries. This current iteration of the OWP HAND based FIM repo is written in Python, distributed as a docker’d environment, and is executed in AWS cloud services. This repo performs the steps needed to create a Height Above Nearest Drainage (HAND) Relative Elevation model (REM) and Synthetic Rating Curve (SRC). As both a research and an operational toolchain, this repo furthermore serves as an accessible entry point to some of the more “modern” computational patterns and better practices, a shining example of “open source” development, and can be deployed in a number of ways.

Quickstart for advanced users

The most relevant stearing files are the /src/bash_variables.env You enable HUCS with an inclusion in a list a la /data/inputs_huc_lists/testunit.lst You control what comes out of the run with the /config/deny_*.lst files

While there are “smart defaults” for many of the runtime arguments, this tool is designed primarily for use at OWP and with the goal of generating outputs for the NWS at a continental scale. If you are not that use case, you may need to tweak the inputs intelligently and remember to update config\params_template.env to reflect the data you have available in your environment.

You can look for help with the -h flag: /foss_fim/fim_pipeline.sh -h

Did that not make sense? That’s O.K! See below for more verbose instructions and relevant background.

References:

See data pages for references related to:

The FIM libraries
The National Water Model

Tutorials

Explainers

What is FIM4 doing?

The process of creating the FIM library is a complex one. See this repo workflow broken down in visual form here (also note the beautiful graphic from the wiki; pilfered and pasted at the top of this page as well!)

How-To’s

NWM data

See the NWM data page.

How to “run” the repo from pull to HAND.tif

See How I install and use docker for tips on setting up the environment

Installation

Gather and stage Input data

Grab input data.

```{bash}
# aws config
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/3dep_dems/10m_5070 . --exclude '*' --include 'HUC6_1209**_dem.tif' --request-payer requester --dryrun
aws s3 cp s3://noaa-nws-owp-fim/hand_fim/inputs/3dep_dems/10m_5070/fim_seamless_3dep_dem_10m_5070.vrt . --request-payer requester --dryrun
aws s3 cp s3://noaa-nws-owp-fim/hand_fim/inputs/3dep_dems/10m_5070/HUC6_dem_domain.gpkg . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/ahps_sites . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/bathymetery . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/huc_lists . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/landsea . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/nhdplus_vectors_aggregate . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/nld_vectors . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/nwm_hydrofabric . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/rating_curve . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/usgs_gages . --request-payer requester --dryrun
aws s3 cp --recursive s3://noaa-nws-owp-fim/hand_fim/inputs/wbd . --request-payer requester --dryrun
```

Build the docker image

Open admin powershell

```{powershell}
wsl
```

Get an error? Maybe start docker? systemctl start docker

Pull the repo

```{sh}
> cd /mnt/OWP_FIM/inundation-mapping/
git clone https://github.com/NOAA-OWP/inundation-mapping.git
```

Build the environment

```{sh}
cd ./inundation-mapping/
docker build -f Dockerfile.dev -t owpfim:1.0 /mnt/OWP_FIM/inundation-mapping/inundation-mapping
```

The dev container is for docker, the owp container is for podman. See the changelog for more details.

create the container

```{powershell}
docker run \
    --rm \
    -it \
    --name 'FIM4' \
    -v /.../inundation-mapping/:/foss_fim \
    -v /.../outputs/:/outputs \
    -v /.../FIM4/:/data \
    owpfim:1.0
```

Stage inputs

The pre_clip step significantly reduces processing time off the standard pattern of file > open > clip_to_huc, but it’s implementation is one of the most difficult and inscrutable aspects of the of the operational FIM pipeline.

Run pipeline

The most relevant steering files are the /src/bash_variables.env You enable HUCS with an inclusion in a list a la /data/inputs_huc_lists/testunit.lst

You can always look for help with the -h flag: /foss_fim/fim_pipeline.sh -h

```{sh}
fim_pipeline.sh -u '12090301' -n FIM4 -ud NONE -bd NONE -zd NONE -skipcal
```

Visualize Outputs

Visualizing the outputs:

From a HAND output library branch and unit: