LTEQ Demand Constraint #1106
LTEQ Demand Constraint #1106
Conversation
…r LTEQ constraints. Previously, request constraints were assumed to be GTEQ constraints and supply constraints were LTEQ. Requesters could now add LTEQ constraints to the DRE limiting a value (e.g. Pu concentration) given their request. This API has *not* yet been exposed to the higher-level CapacityConstraint class, only to the RequestGroup/ExchangeNodeGroup classes at the ExchangeGraph level.
…to the capacity types
…traints. both clp and greedy fail. greedy failure expected
…traint and it is GTEQ
…. it needs to be a minimum as well. fixed.
…en if the solver-wide exclusive option was turned off
src/capacity_constraint.h
Outdated
| /// @param capacity a capacitating value | ||
| /// @param type the type, e.g., LTEQ or GTEQ | ||
| /// @param converter a conversion function pointer | ||
| // @{ |
| /// greater-than-or-equal-to (GTEQ) are supported | ||
| enum CapType { | ||
| LTEQ = 0, | ||
| GTEQ, |
There was a problem hiding this comment.
I think that the standard abbreviations are GE and LE. That would be more consistent with the same names they are given in the query filters.
| /// @param faux_id a false arc id for surplus supply | ||
| /// @param cap_rows the capacity rows which will be appended to | ||
| /// @param ctx the translation context | ||
| static void XlateCaps(ExchangeNodeGroup* grp, |
There was a problem hiding this comment.
I am still not a huge fan of using X to mean Trans. (GCSG: http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#General_Naming_Rules). However, there is wiggle room here since it is more important to be consistent. I dunno. Your call. My 2 drachmas.
|
Hi @gidden! Thanks for putting this in. It looks very useful. There are a couple of small-ish issues to be dealt with in-line. The only thing I would request is some more detailed developer docs about the method. The implementation of the constraints didn't match exactly the math in my mind originally, but does make a certain amount of sense. A write up of what is being implemented I think would have helped. This can be either a mathematical formulation or an algorithmic one. Thanks! |
|
Hi @scopatz. Thanks for the review! I agree that we should have more developer docs. I made #1107 to that effect, and am fine with it blocking this PR for now. The docs in question will likely come from my thesis and/or DRE publication, so should be relatively easy to generate. I will try to get to them post haste. |
|
Hi @gidden! Ok! Sounds great! |
|
moving to 1.4 |
Hi folks,
This PR adds the ability for consumers to supply a LTEQ constraint. For example, a reactor can now make a demand for fuel with total fission products less than a threshold. Support has been added for both the Greedy and mathematical programming solvers.
I added basic unit tests, a "trivial" integration test (integrating exchange layer to formulation layer and back), and a less trivial integration test.