Problem for reconstruction of some targets?

[cfrioux]

I wanted to make some tests with meneco and Ectodata. For a faster computation, I reduced the set of targets to one compound ("ARG" or "GLT"). According to the programme it is not producible but can be reconstructed with the Ectodata metacyc DB. There are no essential reactions associated to the target. There are also no reactions in the optimal solution because no ireactions are found.
It leads to the following output:

meneco -d Ectodata/ectocyc.sbml -s Ectodata/seeds.sbml -t Ectodata/single_target.sbml -r Ectodata/metacyc_16-5.sbml
Reading draft network ...
Draft network file: Ectodata/ectocyc.sbml
Reading seeds ...
Seeds file: Ectodata/seeds.sbml
Reading targets ...
Targets file: Ectodata/single_target.sbml

Checking draftnet for unproducible targets
1 unproducible targets:
	ARG

Reading repair db ...
Repair db file: Ectodata/metacyc_16-5.sbml

Warning: RXN__45__13206 listOfProducts=None
Checking draftnet + repairnet for unproducible targets
Still 0 unreconstructable targets:


1 reconstructable targets:
	ARG

Computing essential reactions for ARG
0 essential reactions for target ARG:


Overall 0 essential reactions found:


Adding essential reactions to network
Computing one minimal completion to produce all targets
/var/folders/76/1vd3yqtd5z1g3rg4t239wrrr0000gp/T/meneco__x018tes.lp
One minimal completion of size 0:


Computing common reactions in all completion with size 0
Intersection of cardinality minimal completions:


Computing union of reactions from all completion with size 0
Union of cardinality minimal completions:

If I test with another target, "CPD__45__8120", I have essential reactions, one solution, an union and an intersection. To be sure I tested very old versions of meneco and the result is alike so this is not brought by the recent changes of meneco.
I will continue to investigate, maybe I am missing something obvious, but I open the issue already in case you understand the behaviour and I don't.

[sthiele]

There are 155 reactions that are irreversible in the draft network but reversible in the repair db. We do not differentiate reversibility regarding to the source. I think this causes the discrepancy.

[sthiele]

In the branch fixreversible I added the network as argument to the reversible predicate.
Now I get the following result for target ARG.

Draft network file: Ectodata/ectocyc.sbml
Seeds file: Ectodata/seeds.sbml
Targets file: Ectodata/target-ARG.sbml

1 unproducible targets:
	ARG

Repair db file: Ectodata/metacyc_16-5.sbml

Still 0 unreconstructable targets:
	

1 reconstructable targets:
	ARG

0 essential reactions for target ARG:
	

Overall 0 essential reactions found:
	

One minimal completion of size 1:
	RIB5PISOM__45__RXN

Intersection of cardinality minimal completions:
	RIB5PISOM__45__RXN

Union of cardinality minimal completions:
	RIB5PISOM__45__RXN

Completion 1:
	RIB5PISOM__45__RXN

[cfrioux]

It seems to be a very good fix, thank you Sven

[sthiele]

It seems to me that fixing the reversibility of reactions is somehow a smaller repair (less costly) than adding a new reaction.
Maybe we should add statistics on which reactions are irreversible in the model but reversible in the database?
But I'm not sure how relevant that is for our application. It's maybe just an edge case. I guess one would maybe check things like that first.

[cfrioux]

I like the idea of uniquely describing a reaction by its identifier and the network it comes from. Only "reversible" atoms missed that network information so far. I think it is relevant in any case because in some databases, reactions are generic and reconstruction tools will implement one version of the reaction depending on the genome. Therefore "reaction_x" in one network can differ (reactants/products) from "reaction_x" from the full DB or from another network.

I am not sure we should make the statistics. Should we on the other hand warn the user that the identifier of the selected reaction(s) already exists in the draft network? Adding the reaction as such would lead to an error with some libraries (libSBML) otherwise (but this is out of scope maybe).

[sthiele]

Ok. I think for now we can merge the fixreversible branch into master and I created a new issue #18 regarding the warning.