search

ucdavis / cecdss

CEC Decision Support System
MIT License
1 stars 2 forks source link

never gets results for Timber Salvage #159

Closed kaiyanl closed 2 years ago

kaiyanl commented 3 years ago

With the following inputs:

Latitude: 37.874369
Longitude: -120.477336
Treatment: Timber Salvage
Capacity Factor: 80

Spinning at the first year all the time

srkirkland commented 2 years ago

@kaiyanl this is pretty straightforward -- there isn't enough biomass. The app is running through a huge radius and has to do a ton of db calls and OSRM routes -- after allowing 12,708 clusters to be processed we still only have 139K of 373K desired metric tons. We don't really have a good way to handle this but we should come up with some stopping conditions -- perhaps if there are more than N clusters or Y radius then we quit. We have something in now which suggests the thought was 40000m / 3800 clusters was going to be the upper limit, but the way the code was written that statement isn't being utilized.

Additionally, even if we did have a good stopping condition we currently have no way to report it back to the app, so it just spins forever even though the call has failed. That should also be fixed when we determine what to do.

kaiyanl commented 2 years ago

@srkirkland Could it be because the app was overloaded? I recall when running the app on my local PC, I got the feedstock amount very close to the biomass target, but then my PC crashed. I sent an email to the team last month describing the issue

The issue is that the amount of available biomass of a cluster is dependent on the forest treatment, and for some treatments such as timber salvage, the amount of available biomass of a cluster is relatively low, so the app has to expand radius further and accounts for more clusters for one year, which possibly overloads the server or exceeds the memory limit or something else that essentially goes beyond the machine capacity, so the front end never gets back the results of the first year from the backend as nothing is really returned from the backend, and the app would be spinning in the first year forever. As far as I can tell, the cause likely lies in the machine capacity, because when I was testing the app locally on my desktop, it took a long time to get enough biomass for the first year when treatment is timber salvage. The radius was greater than 40k, and when I saw that the amount of available biomass was very close to the annual feedstock requirement, my desktop crashed, and I did not get to see that the process ends and returns any results for the first year.

I think if my PC did not crash, I would get at least the results of the first year, because it was about to get sufficient feedstock. But our app does not return the results of the first year.

Also, I recall you mentioned before that we had a limit on execution time, so could that be another possible cause? like the app stopped execution due to timeout, but it had not produced any results yet for that year.

kaiyanl commented 2 years ago

It is because of too many clusters. I ran the app locally with timber salvage and got the following error:

annualGeneration: 186150000, radius: 36000, # of clusters: 75412
calculating move in distance on 75412 clusters...
rejecting move in...
[Error: std::bad_alloc]
ERROR!
[Error: std::bad_alloc]
std::bad_alloc
(node:16267) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'trips' of undefined
kaiyanl commented 2 years ago

ucdavis/cecdss-backend#109