Implement CalculateBidPrice() functionality in Enrichment, Fuel_fab, and Source - #656
Implement CalculateBidPrice() functionality in Enrichment, Fuel_fab, and Source#656dean-krueger wants to merge 3 commits into
Conversation
Build Status Report - dc03eb6 - 2025-07-22 20:37:39 +0000Build
|
|
Fairly certain these tests are failing because this needs cyclus/cyclus#1884 |
gonuke
left a comment
gonuke
left a comment
There was a problem hiding this comment.
Some design thoughts for moving forward.
|
|
||
| **Added:** | ||
|
|
||
| * Added CalculateBidPrice() functionality from facility_cost.cycpp.h to Enrichment, Source, and Fuel_Fab (#656) |
There was a problem hiding this comment.
| * Added CalculateBidPrice() functionality from facility_cost.cycpp.h to Enrichment, Source, and Fuel_Fab (#656) | |
| * Added CalculateUnitPrice() functionality from facility_cost.cycpp.h to Enrichment, Source, and Fuel_Fab (#656) |
There was a problem hiding this comment.
Dang, I thought I got them all.
| double prev_weighted_cost = 0.0; | ||
| double prev_qty = 0.0; |
There was a problem hiding this comment.
I don't think it's a good idea to put an ad-hoc solution into cycamore like this, particularly when we imagine a more cyclus-wide solution. Best to just assume 0 for the cost of material for now until we tackle that more seriously.
There was a problem hiding this comment.
That makes sense to me, I'll change it like that and then spend some time trying to implement a material/resource cost.
| Material::CreateUntracked(*bit, context()->GetRecipe(outrecipe)); | ||
| port->AddBid(req, m, this); | ||
|
|
||
| double pref = 1.0 /CalculateUnitPrice(throughput, target->quantity()); |
There was a problem hiding this comment.
Many components of this price are constants over time for any given facility. I wonder if we can break it down and only calculate those parts once. Maybe all the "process costs" are constants and the "input costs" are not? So we make 2 functions, one that we call once at initialization to calculate the constant part and store it, and then add in the input costs which each bid?
There was a problem hiding this comment.
There could be a way to update the "constant" costs if/as necessary, but not with every bid
|
I'm thinking more and more that this should maybe not go in Cycamore, but its own repo for financial modeling, and I think we should maybe discuss that at the NEUP Project Meeting we're having tomorrow. |
|
We may now be going in a different direction entirely. Converting to a Draft for now... |
|
I think this gets closed now that we've rethought how this all works. |
2 participants
Summary of Changes
The functionality added by the CalculateBidCost()/CalculateBidPrice() functions was added to a few Cycamore facilities to open a wider conversation about the best way to implement this.
Related CEPs and Issues
This PR is related to:
Associated Developers
None.
Design Notes
There are a few areas where I think this COULD be improved by some cleverness, but there are also some areas where I think a wider discussion about the way this is implemented generally could be good, so I didn't spend too long trying to make the code that may need to be changed anyway super slick.
Testing and Validation
Built and tested Cyclus on my local machine. No tests were added, but I imagine some will be necessary.
Checklist
Reviewers, please refer to the Cyclus Guide for Reviewers.