You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I thought I fixed the sorting issue by updating the sorting functions as described in #597 (comment).
But this fixed sorting actually exposed as issue fixed in 8bc5895. That now filters the time tables to create contiguous vectors with the timeseries per node. For this access pattern it would be faster to have it first sorted on node_id, and then on time, instead of the other way around.
I initially went for time first since we were reading in time series at runtime, and then loading them in for all nodes. But now we create an interpolation object per node, that takes a vector of the entire timeseries. So it's better to sort by node_id first like all other tables.
I thought I fixed the sorting issue by updating the sorting functions as described in #597 (comment).
But this fixed sorting actually exposed as issue fixed in 8bc5895. That now filters the time tables to create contiguous vectors with the timeseries per node. For this access pattern it would be faster to have it first sorted on node_id, and then on time, instead of the other way around.
I initially went for time first since we were reading in time series at runtime, and then loading them in for all nodes. But now we create an interpolation object per node, that takes a vector of the entire timeseries. So it's better to sort by node_id first like all other tables.
update_basin
, which still relies on time being sorted firstupdate_tabulated_rating_curve!
, which still relies on time being sorted firstThe text was updated successfully, but these errors were encountered: