Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error in calc_edges() #18

Closed
HunterGleason opened this issue Jan 21, 2021 · 14 comments
Closed

Error in calc_edges() #18

HunterGleason opened this issue Jan 21, 2021 · 14 comments

Comments

@HunterGleason
Copy link

Hello,

I have come across an error that I am seeking help with in the calc_edges() function.

I have determined the function fails while looping the 'calcCatchmArea_assignNetID' method. What is strange is the code same code succeeds in a different basin. In the script I follow the correct steps including conditioning the DEM and checking for and correcting complex junctions. I've tried with different digital elevation models for the same region and get the same error.

The error I get is shown below:

> calc_edges()
Calculating reach contributing area (RCA) ...
Calculating upstream catchment areas ...
Error in `[.data.table`(dt, stream == id, `:=`(total_area, a1 + a2 + dt[stream ==  : 
  Supplied 2 items to be assigned to 1 items of column 'total_area'. If you wish to 'recycle' the RHS please use rep() to make this intent clear to readers of your code.
In addition: Warning message:
In if (dt[stream == id, prev_str01, ] == 0) { :
  the condition has length > 1 and only the first element will be used

Hoping to get any insight as to why I might be getting this error, could it simply be an issues with my digital elevation model, or a recent change in the data.table package?

Thanks,
Hunter
@MiKatt
Copy link
Owner

MiKatt commented Jan 26, 2021

Dear Hunter,

my guess is that there is a catchment comprising of two seperated parts that result in two lines in the tables but with the same stream id.
When testing, I never had that case but it would be good to catch such events.
Would it be possible to send me your dem?

Cheers,

Mira

@HunterGleason
Copy link
Author

HunterGleason commented Jan 26, 2021 via email

@MiKatt
Copy link
Owner

MiKatt commented Jan 31, 2021

Dear Hunter
Can you please tell me the settings you use in derive_streams? Do you get the WARNING: Stream network may be too dense in derive_streams?

@oconnorbryce
Copy link

Hello @MiKatt,

I am working with @HunterGleason on this project. Thanks for creating and maintaining the openSTARS package! The call for derive_streams we were using is below...

derive_streams(burn = 2, accum_threshold = 1200, min_stream_length = 0, condition = TRUE, clean = TRUE)

I never saw the warning: WARNING: Stream network may be too dense, just the error Hunter had described above following calc_edges()

Cheers,

Bryce

@HunterGleason
Copy link
Author

HunterGleason commented Feb 1, 2021 via email

@HunterGleason
Copy link
Author

Hi Mira,

Based on your response I ran the workflow with the 'accum_threshold' increased to 2500, and I did not get the WARNING: Stream network may be too dense warning this time. However, after checking and correcting complex junctions, calc_edges() still throws the following error:

Calculating reach contributing area (RCA) ... Calculating upstream catchment areas ... Error in .prepareFastSubset(isub = isub, x = x, enclos = parent.frame(), : RHS of == is length 2 which is not 1 or nrow (25635). For robustness, no recycling is allowed (other than of length 1 RHS). Consider %in% instead. In addition: Warning message: In if (dt[stream == id, prev_str01, ] == 0) { : the condition has length > 1 and only the first element will be used

Seems to be a 'data.table' error?

Hunter

@MiKatt
Copy link
Owner

MiKatt commented Feb 2, 2021 via email

@MiKatt
Copy link
Owner

MiKatt commented Feb 2, 2021 via email

@HunterGleason
Copy link
Author

Hi Mira,

By non-unique streams you are referring to two separate stream networks with the same netID, one with length=0 ? Good catch, I can see how that would cause problems. Would a temporary solution be to make the min_stream_length parameter > 0 ? Thanks for your help with this, was trying to identify what the issue may have been in calc_edges() but was not having much success.

Hunter

@MiKatt
Copy link
Owner

MiKatt commented Feb 2, 2021 via email

@MiKatt
Copy link
Owner

MiKatt commented Feb 2, 2021

I hope to have fixed the problem.
Please install openSTARS from the dev repository (devtools::install_github("MiKatt/openSTARS", ref = "dev")) and check if it works now. See NEWS for a short description.
Please note that I have not done any excessive testing yet.

@HunterGleason
Copy link
Author

HunterGleason commented Feb 2, 2021 via email

@HunterGleason
Copy link
Author

Hi Mira,

I tested the updated openSTARS wiht the DEM I provided you, deriving streams with a threshold of 2000 (the only value I've tested so far) I did get calc_edges() to work. So your update seems to have fixed the issue as far as I can tell!

Thanks,
Hunter

@MiKatt
Copy link
Owner

MiKatt commented Feb 10, 2021

I close this issue for the time being.

@MiKatt MiKatt closed this as completed Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@MiKatt @HunterGleason @oconnorbryce