Fix storage filling calculations#465
Conversation
👷 Deploy request for prunplanner-preview pending review.Visit the deploys page to approve it
|
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
Hej @lilbit-prun, lets stay with your
So your're right, there is a flaw in how it is currently done. But in the visitation frequency in general, because all you import will be used on a single day to produce the output, so the max of each import/export is relevant. You're however only fixing the Could you make this change there as well, then I'll happily approve and merge! 
|
lilbit-prun
force-pushed
the
storage_filled_calculations
branch
from
4e1774e to
2f5f2d7
Compare
If a base produces 100t and consumes 50t with 1500t of storage, then you can deliver 15 days worth of input mats and 15 days later the base will be full of output mats. So to me that means that filled should be 15 days, not 10 days.
lilbit-prun
force-pushed
the
storage_filled_calculations
branch
from
2f5f2d7 to
240838b
Compare
2 participants
Sorry if I misunderstand, but I'm looking at this plan
It has 6500/6500 storage, so I can bring 30 days of input mats which will completely pack the base, then I can wait 30 days and it will be only 1/3 full and everything is fine. The Filled row implies to me it would take 22.31 days.
I think the 3rd row should be "which is the bottleneck?" and the filled row should be "how many days can this base go between visitations?" I'm not super convinced the 3rd row is useful to show and Filled isn't the right word for it (maybe "Storage Maximum") , but I'll leave those decisions up to you and also because of localization.