Update computeGibbsFreeEnergyRanges.m #131
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have added a fix that mostly takes care of the problem. The main issue with the code is that we need to have some estimates (ranges) for DGf_std. Before, I employed a very simple, and seemingly harmless way of computing these ranges. However, for larger models, this resulted to be a bad solution. So, I implemented and solve series of LP problems to determine the max feasible range for these quantities. One of the difficulties of doing so is that some of these quantities remain unbounded, which can have negative consequences when we solve the TMFA. After some trial and errors, I found a reasonable starting range for DGf_std that enables running the subsequent TMFA computations satisfactorily. In the case of Gurobi, if you check the TMFA solution, it shows a couple of discrepancies which are mostly numerical noise (DGr of the order of 1e-6 when it should be zero). However, in the case of linprog, it shows large errors due to the fact that this solver is simply unreliable for larger problems. Ultimately, there is nothing wrong with the problem formulation, but it is an issue of solver robustness.