New GAMS solver interface, writer, and solution loader. #3683
New GAMS solver interface, writer, and solution loader. #3683AnhTran01 wants to merge 96 commits intoPyomo:mainfrom
Conversation
…ittest and coverage test
|
@AnhTran01 - Please make sure to run |
mrmundt
left a comment
There was a problem hiding this comment.
Immediate piece of feedback, recognizing that I have not thoroughly looked over anything - there are no tests anywhere, and there absolutely will need to be some.
Thanks for this, though, I am so excited!!
…riting process. Added WIP unittest for the new solver interface
… and writing to gms.
… constraint). Fixed bug of load_solution that contains constraint id in addition to variable id
…arsing solver_options
jsiirola
left a comment
There was a problem hiding this comment.
(Some initial comments, mostly on configuration)
pyomo/contrib/solver/solvers/gams.py
Outdated
| if config.logfile is not None: | ||
| config.logfile = os.path.abspath(config.logfile) | ||
|
|
||
| config.writer_config.put_results_format = 'gdx' if gdxcc_available else 'dat' |
There was a problem hiding this comment.
This should probably only overwrite the configuration if it is still None (that way users can set / override the interface)
…lable() and version()
…are no longer valid.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3683 +/- ##
==========================================
- Coverage 89.48% 89.46% -0.03%
==========================================
Files 904 907 +3
Lines 105385 106064 +679
==========================================
+ Hits 94299 94885 +586
- Misses 11086 11179 +93
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
seems like codecov is not ideal. most of the missed lines are when |
Oop, sorry, I didn't see this. The coverage is actually fine. 89% is more than okay. |
Sounds good, thanks for the follow up. Is there anything I can do to help with this? |
| self.primals: List[float] = [] | ||
| self.duals: List[float] = [] | ||
| self.var_suffixes: Dict[str, Dict[int, Any]] = {} | ||
| self.con_suffixes: Dict[str, Dict[Any]] = {} | ||
| self.obj_suffixes: Dict[str, Dict[int, Any]] = {} | ||
| self.problem_suffixes: Dict[str, List[Any]] = {} | ||
| self.other: List(str) = [] |
There was a problem hiding this comment.
Do we still need to use typing.Dict and typing.List here or can we use the built-in Python dict and list?
There was a problem hiding this comment.
if you want type hinting to catch that the dict structure should be a str key and a list value, then yes, you will need to keep these as is (same logic for the List) im fixing a typo on the List(str) should be List[str] (w/ brackets)
| else: | ||
| for sym, obj in self._gms_info.var_symbol_map.bySymbol.items(): | ||
| level = self._gdx_data[sym][0] | ||
| if obj.parent_component().ctype is Var: |
There was a problem hiding this comment.
Can var_symbol_map contain Pyomo component types other than Var?
There was a problem hiding this comment.
I will need to let @AnhTran01 give more detail here, but with the simple models that we have in the test library only Var components appear in this dict.
There was a problem hiding this comment.
@blnicho The var_symbol_map only contains Pyomo component type Var (from the internal data of _gms_info below).
There was a problem hiding this comment.
In that case we can probably remove the ctype check on L61.
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
| RangeSet, | ||
| Port, | ||
| }, | ||
| targets={Suffix, SOSConstraint, Objective}, |
There was a problem hiding this comment.
I don't see any code for handling Suffix or SOSConstraint components. I suspect this writer will silently ignore any of these components declared on the model which seems like a bug. We should check for these components and log a warning or throw an error if any are encountered.
@jsiirola would removing Suffix and SOSConstraint from the target argument be sufficient for getting the writer to treat these component types as "unknown" and throw an error?
There was a problem hiding this comment.
throwing an appropriate error seems fine with me. Thank you for the help/guidance in crafting this properly.
Co-authored-by: Bethany Nicholson <blnicho@users.noreply.github.com>
pyomo/contrib/solver/solvers/gams.py
Outdated
| def available( | ||
| self, config: Optional[GAMSConfig] = None, recheck: bool = False | ||
| ) -> Availability: |
There was a problem hiding this comment.
We have been re-working how we want to use / think about available(). For solvers that rely on an external executable, we are caching a dict that maps executable path to the version information. That allows the cache to be a class attribute (so we don't have to keep re-checking), and to be robust to users pointing the solver to a new executable. See ipopt.py for the current reference implementation
There was a problem hiding this comment.
yeah, i see now. good to not keep calling a subprocess if .solve() is in a loop. hopefully fe7b43f fixes this
There was a problem hiding this comment.
apologies... my tests are are now passing locally
Fixes NA
Summary/Motivation:
This PR introduced a new GAMS solver interface that uses the
LinearRepnVisitorto enable coefficient gathering when writing out the scalar GAMS model ingmsformat.Changes proposed in this PR:
pyomo.contrib.solver.solverspyomo.repn.pluginspyomo.contrib.solver.solversLegal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: