Hi Michael,
With respect to the first part of your question:
The problem here is with the normalization ('one'), which, after
solving the original problem, also solves a secondary problem
(absolute flux minimisation).
Since the problem solves a secondary problem with a different
objective, reduced costs and shadow prices, would either have to
be referring to the secondary problem (which is not representing
the actual objective, so your properties correspond to a different
objective than the maximisation), or they would be invalid, as the
provided solution is no longer the solution returned from the
initial solving.
Therefore we decided not to return anything in these instances. If
you want to get shadow prices/reduced costs for those objectives I
would suggest to build the LPs yourself (the initial one is simply
created by running 'buildLPproblemFromModel' for the second one I
would suggest following the code in optimizeCbModel) and get the
individual reduced Cost / shadow Prices, or modify the
optimizeCbModel function to not delete those values but rather
provide them (for whichever problem you want them from).
For your second part:
solution.obj is the objective of the actual solved problem (in
case of quadratic regularization, this is sol.x' * model.c +
sol.x' * minNorm*speye(numel(model.rxns))*sol.x) while sol.f is
the objective value as defined in the model structure. Admittedly,
this is confusing and not well documented, so if you want, feel
free to update the documentation here.
Best
Thomas
Unsubscribe
It appears that you have subscribed to commercial messages from this sender. To stop receiving such messages from this sender, please unsubscribe
--
---
You received this message because you are subscribed to the Google Groups "COBRA Toolbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cobra-toolbo...@googlegroups.com.
For more options, visit http://secure-web.cisco.com/1B6Sn3swokKZt-OIiAybzawKcQ3L5Zw6G5VgtsUXbDVZDnQj3ikTvbHgC1orm3rtiHRnrOSuTHuc2D-MmwWP6VPFe_SGYVPS17ETw3DZm1kFl0Vtni80oCuvMMQaJFP9rM7i_QEVKynsnokKEqdkD9f8MnAGsK5XftlRkkUObUqvIvuEhmqPAVVb9PurbNJAE8fzXbgWodKLIfRnTlG_NmiiiIFULciydbUCHaA1SqnpKVHIjy_cJTBdoMlQJhm5iN9wgLeQcE92fodNzHQNgCh1Y1Et2fyvLXOe9sySRdNWq1Biu9hU2b2xUGmMTI4O8v0F3P4sqq9Ny7AJgL_ofVzxYJMkK3aftOFfsc31A_QP3XoYMGAnmCYgZrdPBjtf9msLoUvtOq82SI_w1yk9t-HM3NlxSGTVVVcfAC2DCypa90a6dJEf43ko97y1v-JS5/l34%3Ahttps%3A%2F%2Fgroups.google.com%2Fd%2Foptoute.
-- Université du Luxembourg Faculté des Sciences, de la Technologie et de la Communication Campus Belval, Biotech II 115 6 avenue du Swing L-4367 Belvaux Tel: (+352) 46 66 44 5309 Email: thoma...@uni.lu
Hi Michael,
With respect to the first part of your question:
The problem here is with the normalization ('one'), which, after solving the original problem, also solves a secondary problem (absolute flux minimisation).
Since the problem solves a secondary problem with a different objective, reduced costs and shadow prices, would either have to be referring to the secondary problem (which is not representing the actual objective, so your properties correspond to a different objective than the maximisation), or they would be invalid, as the provided solution is no longer the solution returned from the initial solving.
Therefore we decided not to return anything in these instances. If you want to get shadow prices/reduced costs for those objectives I would suggest to build the LPs yourself (the initial one is simply created by running 'buildLPproblemFromModel' for the second one I would suggest following the code in optimizeCbModel) and get the individual reduced Cost / shadow Prices, or modify the optimizeCbModel function to not delete those values but rather provide them (for whichever problem you want them from).For your second part:
solution.obj is the objective of the actual solved problem (in case of quadratic regularization, this is sol.x' * model.c + sol.x' * minNorm*speye(numel(model.rxns))*sol.x) while sol.f is the objective value as defined in the model structure. Admittedly, this is confusing and not well documented, so if you want, feel free to update the documentation here.
Best
Thomas
On 18.11.18 22:03, 'Michel_Lavoie' via COBRA Toolbox wrote:
Unsubscribe
It appears that you have subscribed to commercial messages from this sender. To stop receiving such messages from this sender, please unsubscribe
Hello all,--I computed steady-state fluxes in a genome-scale model using a FBA with quadratic minimization with the command optimizeCbModel(model1, 'max', 'one'): . However, The vectors .y or .dual representing shadow prices of each metabolites are empty. The vectors .w and .rcost representing the reduced cost for each reaction are also empty. By contrast, when I compute a standard FBA with the command optimizeCbModel(model1, 'max') ., I can find full .y and .w vectors and it works well. I can also model the same growth rate (field .f = 0.11) with both types of FBA. However, with the FBA with quadratic minmization the field .obj gives 538.43. By contrast, in the standard FBA, the field .obj gives the correct growth rate (i.e., 0.11) of the .f field. Are reduced costs and shadow prices computed for FBA with quadratic minimization ? Does anyone have any idea why I cannot compute reduced costs and shadow prices when using one type of FBA? Why do I find a difference between the .obj and the .f field for one type of FBA, but not the other?
Thank you very much for your help,Michel
---
You received this message because you are subscribed to the Google Groups "COBRA Toolbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cobra-toolbox+unsubscribe@googlegroups.com.
Hi Michel,
If you want to see the robustnes to reaction deletion, than yes,
I would suggest that. However, I would actually suggest to rather
get a pure FBA solution and the corresponding reduced costs/shadow
prices and try to interpret those, as singleRxnDeletion is much
more strict in that essential reactions will be associated with a
0 value, while other reactions might actually have a higher cost
if they get reduced. Maybe a combination of both approaches would
be something to consider.
As for obj vs f:
obj is the objective value as returned by solveCobraLP for the
actual LP problem solved, while f is the value returned for the
objective in the model.
For backward compatability reasons we keep a lot of values from
the solveCobraLP call in the returned solution, like e.g. the obj
field but their meaning can be off (if subproblems are solved
these fields are not adapted).
This might be changed in the future but for now, they will stay in
the solution
Best
Thomas
To unsubscribe from this group and stop receiving emails from it, send an email to cobra-toolbo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.