Github Actions; Preliminary Documentation

.github/workflows/test.yml

@@ -1,15 +1,7 @@
 name: Test Python Script
 
 on:
-  push:
-    branches:
-      - rapid-inflows
-  pull_request:
-    branches:
-      - rapid-inflows  
-  workflow_dispatch:
-    branches:
-      - rapid-inflows  
+  [push, pull_request, workflow_dispatch]
 
 jobs:
   test:
@@ -32,11 +24,11 @@ jobs:
       uses: conda-incubator/setup-miniconda@v2
       with:
         mamba-version: "*"
-        channels: conda-forge,bioconda,defaults
+        channels: conda-forge,defaults
         auto-activate-base: false
         activate-environment: inflows
         environment-file: envs/environment.yml
 
     - name: Run Tests
       run: |
-        python ./tests/test_compare.py
+        python ./tests/test_compare.py

.gitignore

@@ -1,4 +1,4 @@
 *.pyc
 example.py
-test.nc
+test*.nc
 .DS_store

README.md

@@ -1,5 +1,7 @@
 # rapid_inflows
-Rapid Inflows is a python interface for RAPID that assists to prepare inflow data. Gridded runoff data is taken in, along with lists of basins and their area. The runoff for each basin is calculated for every time step, and the resulting flows are written to an output inflow datset, the main dataset used by RAPID. More information about RAPID can be found [here](http://rapid-hub.org).
+Louis R. Rosas, Dr Riley Hales
+
+Rapid Inflows is a python interface for RAPID that assists to prepare inflow data. Gridded runoff data is taken in, along with lists of basins and their area. The runoff for each basin is calculated for every time step, and the resulting flows are written to an output inflow NetCDF file, the main dataset used by RAPID. Inspired by ERDC's [RAPIDpy](https://github.com/erdc/RAPIDpy). More information about RAPID can be found [here](http://rapid-hub.org).
 
 ## Inputs
 The `create_inflow_file` function takes in four parameters: 
@@ -9,7 +11,7 @@ The `create_inflow_file` function takes in four parameters:
     4) an output filename
 
 ### Gridded Runoff Datasets
-The input netcdf datasets should follow the following conventions. It is expected that the datasets have 3 or 4 dimensions, in the following orders: `time, latitude, longitude` or `time, expver, latitude, longitude` (The 4th dimension is often present in the most recent releases of the ECMWF datasets, which has an 'experimentl version' dimension. Internally, this dimension is flattened and the data summed. the name of this dimension does not matter). The runoff, longitude, and latitude variables may be any of the following, respectively: `'ro', 'RO', 'runoff', 'RUNOFF'`, `'lon', 'longitude', 'LONGITUDE', 'LON'`, `'lat', 'latitude', 'LATITUDE', 'LAT'`. Latitude and longitude is expected in even steps, from 90 to -90 degrees and 0 to 360 degrees repectively. Time is expected as `'time'`. The difference in time between each dataset should be equal (typically a time step onf a day is used), and should be an interger.
+The input netcdf datasets should follow the following conventions. It is expected that the datasets have 3 or 4 dimensions, in the following orders: `time, latitude, longitude` or `time, expver, latitude, longitude` (The 4th dimension is often present in the most recent releases of the ECMWF datasets, which has an 'experimental version' dimension. Internally, this dimension is flattened and the data summed. The name of this dimension does not matter). The runoff, longitude, and latitude variables may be any of the following, respectively: `'ro', 'RO', 'runoff', 'RUNOFF'`, `'lon', 'longitude', 'LONGITUDE', 'LON'`, `'lat', 'latitude', 'LATITUDE', 'LAT'`. Latitude and longitude is expected in even steps, from 90 to -90 degrees and 0 to 360 degrees repectively. Time is expected as `'time'`. The difference in time between each dataset should be equal (typically a time step of a day), and should be an interger.
 
 The user may input as many datasets as desired. There is a built in memory check which warns the user if the amount of memory required exceeds 80% of the available RAM and will terminate the process if the amount of memory required exceeds all the available memory. 
 
@@ -28,9 +30,9 @@ This file can be generated using either [these ArcGIS tools](https://github.com/
 An example weight table can be found in `/tests/inputs`.
 
 ### Comid csv
-A csv which has the unique ids (COMIDs, reach ids, LINKNOs, etc.) of the basins/streams modeled in its first column, sorted in the order in which the user wants RAPID to process. This file can be generated using either [these ArcGIS tools](https://github.com/Esri/python-toolbox-for-rapid) or [these python scripts](https://github.com/geoglows/tdxhydro-rapid).
+A csv which has the unique ids (COMIDs, reach ids, LINKNOs, etc.) of the basins/streams modeled in its first column, sorted in the order in which the user wants RAPID to process. Two other columns must be present, labeled `'lat'` and `'lon'`. These columns represent a point related to each river reach. This file can be generated using either [these ArcGIS tools](https://github.com/Esri/python-toolbox-for-rapid) or [these python scripts](https://github.com/geoglows/tdxhydro-rapid).
 
 An example comid csv can be found in `/tests/inputs`.
 
 ## Outputs
-The `create_inflow_file` outputs a new netcdf 3 (classic) dataset.
+The `create_inflow_file` outputs a new netcdf 3 (classic) dataset. It is desgined to be accepted by rapid and pass all of its internal tests. Example output datasets can be found in `/tests/validation`.

envs/environment.yml

@@ -2,14 +2,13 @@ name: inflows
 channels:
   - defaults
   - conda-forge
-  - bioconda
 dependencies:
-  - dask=2023.6.0
-  - netcdf4=1.6.2
-  - numpy=1.25.0
-  - pandas=1.5.3
-  - psutil=5.9.0
-  - pyarrow=11.0.0
-  - pytest=7.4.0
-  - python=3.11.4
-  - xarray=2023.6.0
+  - dask
+  - netcdf4
+  - numpy
+  - pandas
+  - psutil
+  - pyarrow
+  - pytest
+  - python
+  - xarray