channel width - enable support for modelling any watershed about bcfishpass HOT 13 CLOSED

LNIC added with 2ecd4e1

Renaming and leaving open for now - we will want to be able to support modelling channel width in other watersheds

from bcfishpass.

been playing around with this a bit and would like to get all the MAP data in one place and assign a source for measured widths to differentiate between PSCIS and FISS widths. For running rasterstats on the MAP data, I think I run out of memory if I try to do all the watershed groups at once. Not totally sure though.

I have sucessfully done a run with all the skeena watersheds but thought I would check in with you on thoughts of the best way to run the whole province. Seems a shame that bc-major-basins is a multi-line geometry rather than polygons (is whse_basemapping.fwa_basins_poly derived from this?). I thought about looking into transforming it to polygons...

I was thinking one way or the other I could maybe break the whse_basemapping.fwa_watershed_groups_poly into 10 chunks or so then bind the resulting tables with MAP values together after... I wouldn't want to duplicate effort, miss a simpler solution or maybe be missing something in terms of why I hit an error running the whole province at once in the first place though so I thought I would check in. Thoughts?

from bcfishpass.

Clearly you just need to buy more memory 😆

There are lots of ways to tile up the province. Looping through all the watershed groups is probably easiest, there doesn't seem to be any need to group them together?

The major basins layer might work but there is no link between it and FWA.

fwa_basins_poly is not complete - I created that to somewhat mirror the major basins layer using fwa linework but haven't yet needed to complete it - https://github.com/smnorris/fwapg/blob/main/sql/data_load/create_fwa_basins_poly.sql

If you have a PR that runs the province I can probably run it, my machine has lots of memory.

from bcfishpass.

Actually, the zonalstats is done per watershed group already, but it is in parallel.
If you're running out of memory, adjust parallel to use fewer processes, it looks like I defaulted to all cores.
It looks like this might be the switch https://www.gnu.org/software/parallel/parallel_tutorial.html#Number-of-simultaneous-jobs

from bcfishpass.

currently the script only runs it for the 5 watershed groups "of interest" correct? I modified the mean_annual_precip.sh by eliminating lines 26 and 100. Does that make sense? I freed up a bit of space and now have 138GB (of 475GB) of my SSD free. Maybe I'll try again if that mod and my available space seems reasonable to you... (provided I am understanding correctly how the memory thing works 🤣 )

from bcfishpass.

i'll look at the parallel thing too. Thanks for that

from bcfishpass.

Yes - remove the selection of the watershed groups in those lines.
It isn't a disk intensive process, your ssd should be fine.
I thought you were running out of RAM - if you have lots of cores and not much memory that does seem maybe possible.

from bcfishpass.

to get channel_width_modelled.sql to run I needed to add watershed_group_code to the UNIQUE constraint for the bcfishpass.channel_width_modelled table. Does that make sense?

Line 13: UNIQUE (wscode_ltree, localcode_ltree, watershed_group_code)

Before the mod it was throwing the error:

psql:sql/channel_width_modelled.sql:67: ERROR: duplicate key value violates unique constraint "channel_width_modelled_wscode_ltree_localcode_ltree_key"

from bcfishpass.

I guess that makes sense. A stream could cross watershed groups without changing local code - the watershed groups can be very arbitrary.

from bcfishpass.

Can you confirm that this is the formula to use for provincial channel width modelling?

  -- The formula for predicting channel width based on Thorley and Irvine 2021
  -- in R we have eWidth[i] = exp(b0 + bArea * log(area[i])  + bPrecipitation * log(precipitation[i]))
  -- the OLD equation we used that is referenced in porter translated to postgresql was
  --OLD -- 0.042 * power((s.upstream_area_ha/100),0.48) * power((p.map_upstream/10),0.74) -- OLD do not use
  round(
      (EXP(-2.2383120 + 0.3121556 * ln(s.upstream_area_ha/100) + 0.6546995 * ln(p.map_upstream/10))
    )::numeric, 2
  )

https://github.com/NewGraphEnvironment/bcfishpass/blob/newgraph/01_prep/04_channel_width/sql/channel_width_modelled.sql

from bcfishpass.

Yes, it is a first crack at it and seems quite reasonable on prelimnary review.

Methods to derive are here - channel-width-21.pdf and the script to generate the dataset analyzed is currently kept in this fork/branch

As @joethorley has stated, "In short we can predict the expected channel width for a typical site quite well (CIs) but there is still substantial variation among individual sites (PIs) which mean for a particular site there is still quite a lot of uncertainty."

We are planning to push ahead by adding more variables (ex. %land cover type, % watershed above 1500m, monthly precip, etc) to get a better indication of channel width or potentially even discharge.

Tying it all to fish density data from historic sampling data is another goal.

from bcfishpass.

Perfect, thanks.

@nickw-CWF - with CWF WCRP expected to receive discharge for LNIC shortly I am going to replace the existing channel width model formulas (BULK/HORS/LNIC) with this one so I don't have to manage two channel width models. I am not sure what (if any) model may be used for ELKR?

from bcfishpass.

closing in favour of #118

from bcfishpass.