-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERROR using ftINIT. MipGap too high, trying with a different run. #511
Comments
@ShwetaNagre Did you get past this issue? |
Hi @johan-gson, |
Ok, I'm closing this now. |
Hi @ShwetaNagre could I ask how you got past this issue since I've now run into the same problem myself while trying to run ftINIT on windows |
Hi,
Which version of gurobi are you using? I have tested it with 9.5, I know
there are some issues with Gurobi 10 - I have not yet introduced the fixes
for that.
Best,
Johan
…On Sat, Apr 1, 2023 at 1:54 PM manas-kohli ***@***.***> wrote:
Hi @ShwetaNagre <https://github.com/ShwetaNagre> could I ask how you got
past this issue since I've now run into the same problem myself while
trying to run ftINIT on windows
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHX2AK33RNLVAMRWSHNPD3TW7BTUXANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Turns out I had, if you have the latest version. And, I have been running it on Windows during the development, so that should not be an issue. Are you sure you have converted the genes correctly, that may lead to such errors. |
I.e., if you have gene symbols in your RNA-Seq data you need to set the convertGenes to true, if you have ensembl genes you should set it to false. |
Hi johan, I did update gurobi recently but actually realised I just made a stupid mistake and had two versions of RAVEN floating around and so that produced the error. Sometimes it's the simple things but I reckon if others get this error, it probably can be due to conflicting versions of RAVEN/Gurobi. Thanks for the quick response though, I do appreciate it |
Ok, no worries, good that you got it to work! Good luck with your project!
…On Sat, Apr 1, 2023 at 2:17 PM manas-kohli ***@***.***> wrote:
Hi johan, I did update gurobi recently but actually realised I just made a
stupid mistake and had two versions of RAVEN floating around and so that
produced the error. Sometimes it's the simple things but I reckon if others
get this error, it probably can be due to conflicting versions of
RAVEN/Gurobi. Thanks for the quick response though, I do appreciate it
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHX2AK6FD7LVKUSLY5TGWCLW7BWJ7ANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Sorry for the late reply @manas-kohli, good that you got this cleared. Hey @johan-gson can these RAVEN version specifications be mentioned on the HUMAN-GEM guide as well? So, that it would be more helpful to others. Cause when I created some models in Feb'23 it worked well with it and just showed the problem with an updated version of RAVEN. Thank you. |
@ShwetaNagre Sorry, forgot to answer this. Could you clarify - is it with the newer version of RAVEN you get problems? |
I think @edkerk mentioned that RAVEN is going to have an "auto-update" function that will make sure RAVEN is running the latest version, so perhaps this part doesn't need to be added to the guide. A note on Gurobi on the other hand might be useful. |
It should work fine with the new version (10) of Gurobi after a change in one of the parameters, so there should be no need for that either. |
Right, but atm there is nothing specified on the Gurobi version during installation. My suggestion would be to at least add in the word "latest version of the [Gurobi Optimizer]". |
@mihai-sysbio No auto-update, |
Sorry to bring this up again, could you tell me what change did you make in "after a change in one of the parameters, so there should be no need for that either."? Thank you very much in advance!! |
@MengJ-bioDyn If you send me your code and the data I could test to run it and see if I can make it work. It can be multiple things. One thing is to make sure that the genes are the same - if you created the prepData with ENSEMBL, it has to be ENSEMBL etc. Also important to remove the versions of the ENSEMBL genes, i.e., if ENSG0000000001111111.2 then remove .2 from the gene for all genes. I think I should have fixed the Gurobi thing in the code, so if there is still a problem with that it is a new bug. |
My email address is johan.gson@gmail.com if you are willing to send your data and code. |
Hi Meng, Not sure where the data is, could you by any chance share it via google drive? |
ok, will have a look! |
Hi, do you also have the code, I didn't see it? It looks like the data is in log (TPM + 1) and then centered, since you have negative values? Is that so? |
Thank you! Right, the data is log(TPM +1). Can you see the code now?
I tried Gurobi 10.0.0, 10.0.1 and 10.0.2, all have the same problem... I
tried to install 9.5.2, but the current trial license I got doesn't support
9.5.2.
I saw other people have similar problems on the git issues, but somehow
they seemed to be able to solve it. That's why I'm very confused.
Again, I greatly appreciate your help!!
…On Fri, Jun 16, 2023 at 8:10 PM johan-gson ***@***.***> wrote:
Hi, do you also have the code, I didn't see it? It looks like the data is
in log (TPM + 1) and then centered, since you have negative values? Is that
so?
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADAI4EECRAA6KX7F6H7ETM3XLUNYRANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi, I still don't see any code, did you attach a text file or something, I didn't see it? It is not a huge problem, I can use some old code I have. But, there is a problem with the data, there is just no way that is log(TPM + 1) since it contains negative numbers (log(TPM + 1) can never become negative). It doesn't look centered either? Is it log(TPM + x), where the pseudocount x is something smaller than 1? For example this row: ENSG00000000005,ENSG00000000005.5,TNMD,-3.444843513,-3.444843513,-3.444843513,-3.444843513,-3.444843513,-3.444843513,-3.388346749,-3.444843513 |
Hi,
Glad that you could make it work! Just make sure that the transformation is
right, it does sound a bit fishy to me - In RNA-Seq you usually have a lot
of zeros, and those can not be log transformed like you described, will
give NaN or something like that. if you imputed those with a small value
you are fine, but otherwise there is something fishy going on. Just because
it could run doesn't mean that it is correctly run.
Good luck with your project and glad that I could help!
Johan
…On Mon, Jun 19, 2023 at 7:10 PM Meng ***@***.***> wrote:
Hi!
Sorry for the late reply! I was out of town for the last two days. I
attached a .m file in the previous emails, but somehow it didn't show up
on
your side. I pasted it at the end of this email. I double checked the data
process pipeline, the data is log2(TPM), not centered.
Inspired by what you mentioned, I checked to use 2.^(data) (convert to
TPM)
as input for ftINIT, and so glad it worked!!
The command ftINIT(prepDataHumanGEM, new_data_struct.tissues{1}, [], [],
new_data_struct, {}, getHumanGEMINITSteps('1+0'), false, true) finished
without errors. So the issue is not caused by Gurobi 10.0.1 and Raven
2.8.1. I'll update this to github.
Thank you so much! I deeply appreciate your time and your help!!
The tools you and your lab developed are very useful, and they are great
contributions to the whole scientific community!
Thank you and best regards,
Meng
Below is my code:
load('Human-GEM.mat');
model = ihuman;
% changeCobraSolver('glpk')
% setRavenSolver('cobra')
sol = solveLP(model)
% check MouseGEM biomass rxn lb & ub
rxns = [model.rxns];
biomassID_mouse = find(strcmp(rxns, 'MAR00021'))
model.rxns{biomassID_mouse}
[model.lb(biomassID_mouse) model.ub(biomassID_mouse)]
essentialTasksFilePath =
'./data/metabolicTasks/metabolicTasks_Essential.txt';
rxnsFilePath = './model/reactions.tsv';
convertGenes = false;
initial_run = false;
if initial_run
prepDataHumanGEM = prepHumanModelForftINIT(ihuman, convertGenes,
essentialTasksFilePath, rxnsFilePath)
save('prepData.mat', 'prepDataHumanGEM')
else
print('load previously generated prep model');
load('prepData.mat')
end
rnaseq_data = readtable('./data/PANC_TPM_withgenename_avg_14d.csv');
tissueN = 4;
data_struct.tissues = rnaseq_data.Properties.VariableNames(4:end)'; %
sample (tissue) names
data_struct.genes = rnaseq_data.gene_id; % gene names
data_struct.levels = table2array(rnaseq_data(:, 4:end)); % gene TPM values
data_struct.threshold = 1;
%% now this works!
level_test = data_struct.levels;
level_unlog2 = 2.^(level_test);
new_data_struct = data_struct;
new_data_struct.levels = level_unlog2;
new_data_struct.threshold = 1;
model1 = ftINIT(prepDataHumanGEM, new_data_struct.tissues{1}, [], [],
new_data_struct, {}, getHumanGEMINITSteps('1+0'), false, true);
model1.id = new_data_struct.tissues{1};
On Sat, Jun 17, 2023 at 7:17 AM johan-gson ***@***.***> wrote:
> Hi, I still don't see any code, did you attach a text file or something,
I
> didn't see it? It is not a huge problem, I can use some old code I have.
> But, there is a problem with the data, there is just no way that is
log(TPM
> + 1) since it contains negative numbers (log(TPM + 1) can never become
> negative). It doesn't look centered either? Is it log(TPM + x), where
the
> pseudocount x is something smaller than 1? For example this row:
>
ENSG00000000005,ENSG00000000005.5,TNMD,-3.444843513,-3.444843513,-3.444843513,-3.444843513,-3.444843513,-3.444843513,-3.388346749,-3.444843513
> This is something you need to figure out, how the data was transformed.
If
> you produced the data in your lab, that should be easy to do! I'll be
happy
> to help once you figured that out so we can convert it back to TPM.
>
> —
> Reply to this email directly, view it on GitHub
> <
#511 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ADAI4EAXXAWE7AWWDQBAVWTXLW37PANCNFSM6AAAAAAWE6YHOM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHX2AK63W6VVJO5MS6ZSCSLXMDL7VANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi there, I am here to report the same error:
I have gone through all the comments, have the most recent RAVEN version (2.8.4) and Gurobi version 10.0.2.
Would appreciate if anyone has any feedback on this! Many thanks |
Hmm, could you check in prepData.minModel, if the grRules uses gene symbols as well, just to make sure? And the data is in TPM? |
would it be good to have some checks for gene formats? |
Hello, In
As for In addition, |
Yes, this doesn't sound good, that is most likely the error. Did you by any chance set convertGenes to true? That is not a good idea for Mouse-GEM, this should be false. If not, could you set a breakpoint in the code and see where they are cleared? |
Hi, No, I have left
Here I also get the same error:
Here the
I then looked into how I hope I haven't made this super confusing! |
Another update from my side: I decided to manually impute missing grRules values inside prepData.minModel like so:
and running:
produces again the same error. maybe it also needs |
Hi, sorry, I misremembered, the GrRules should be empty in the minModel. Would it be possible for you to send me your code and data, and I can debug and see what is happening? You can send it to johan.gson@gmail.com. I can probably figure this out quickly, although there are no guarantees. One final thing to check: could you check if the b field in the mouse model has two columns? This is a bug that has been haunting mouse-GEM for a long time :). |
In minModel, all linearly dependent reactions are merged, which makes the model smaller and thereby faster to solve. There is no good way to merge grRules, so the field is cleared - this is not used in ftINIT anyways. |
I have removed the second column in MouseGEM.b but to no avail. I am sending you my stuff to your email, thanks a lot for helping me out :) |
Just noting here, however this gets solved, please follow up with a new issue to update either code (ftINIT or wherever else), or perhaps the guide. At least, I think the guide should be updated with some self-debugging code, so that people can self-diagnose some of the more common issues. |
Thanks for the data, I will have a look. I don't see any obvious mistakes by just looking at your code, it looks good. Let me get back once I have debugged this. @haowang-bioinfo Could you take a look at if the b field still has two columns in the latest Mouse-GEM? We have tried to fix this several times now, and it still comes back and bites us :) |
@johan-gson yes I just checked the latest Mouse-GEM, which still has two columns in the b field - fix it now |
@haowang-bioinfo The error must be in the script converting from human to mouse - no point fixing it in the model. But you probably realize that :). Would be good to add a test case that specifically tests this before releases, this problem seems to have a magic ability to come back. |
Hi @rsango6, I tested it on my computer, and it worked, which is a bit confusing. I am using Gurobi 9.5, maybe I have not tested exactly the version you are running. One thing I see in the data is that the TPM doesn't sum to 10^6, so I would rescale it, but it is not what is causing the failure. What versions of Mouse-GEM and Human-GEM are you using? |
I'm using the latest mouse gem |
And, I didn't do any manipulations of the model except fixing the .b field, exactly as you did. I did not run the lines manipulating the grRules, that should not be done. |
I am using: Human-GEM v1.16.0 and now have switched from Gurobi v10.02 to Gurobi v9.5.2. I thought that maybe the reason could be that TPM are loaded not as numeric values, rather as characters. Though still getting the same error. It does tell me at start of the analysis with
It's rather strange that it is working for you and not in my case. By the way, TPM values are all obtained from Salmon as is, haven't manipulated with them in any way so that is also weird that there are also some discrepancies too. I need to think why that would be the case. |
Ok, probably not a Gurobi thing then, which is good, could have been complicated to solve. This is strange. I also used RAVEN 2.8.4. I used the latest mouse-GEM, just downloaded it, I guess that is the same. And, the same MATLAB version. I do have an older Human-GEM though, something from devel in the middle. Does it work with the prepData I emailed you, could you test that? |
I can confirm I have now tried with your Really interesting as to what has gone wrong in my case when generating |
Hmm, yes, weird. Can you see any difference between the prepData objects,
for example number of reactions etc. in the min model? It really should
work on Mac. Would be valuable if you could dig a bit more and debug what
is happening in prepInitData. But I would compare the prepDatas and see
what went wrong first, and then debug and see where that field(s) get their
bad values. Also strange with that warning you got, I didn't. Could be
something with the boundary metabolites. I don't have more advice,
debugging is the key, it should be doable.
…On Thu, Aug 17, 2023 at 12:24 PM Roko Sango ***@***.***> wrote:
Ok, probably not a Gurobi thing then, which is good, could have been
complicated to solve. This is strange. I also used RAVEN 2.8.4. I used the
latest mouse-GEM, just downloaded it, I guess that is the same. And, the
same MATLAB version. I do have an older Human-GEM though, something from
devel in the middle. Does it work with the prepData I emailed you, could
you test that?
I can confirm I have now tried with your prepData object, and for both
getHumanGEMINITSteps('1+0') and getHumanGEMINITSteps('1+1') and within
seconds I have successful generation of the models.
Really interesting as to what has gone wrong in my case when generating
prepData, seeing we are using dependencies with identical versions. Maybe
something to do with the OS -> I am running the whole thing on macOS
Ventura 13.4.1
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHX2AKZBPFZM7JQAHLH7TWLXVZASDANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
- This is to resolve recurring issue reported in #511
|
Hi,
Here are the screenshots from your prepData and mine:
[A screenshot of a computer Description automatically generated] [A screenshot of a computer Description automatically generated]
minModel in each case look identical (also refModel fields look identical):
***@***.*** ***@***.***
In the first pair of screenshots, you can see differences in numbers in essentialRxns, taskStruct, essentialMetsForTasks.
Another difference is in prepData.taskReport.ok field: all of values in your cases are 0’s, in mine all of them are 1’s. Perhaps there is something wrong with the task structures that are part of my prepData? I would need to look closely into this.
Best,
Roko
From: johan-gson ***@***.***>
Date: Thursday, 17. August 2023 at 19:56
To: SysBioChalmers/Human-GEM ***@***.***>
Cc: Roko Sango ***@***.***>, Mention ***@***.***>
Subject: Re: [SysBioChalmers/Human-GEM] ERROR using ftINIT. MipGap too high, trying with a different run. (Issue #511)
Hmm, yes, weird. Can you see any difference between the prepData objects,
for example number of reactions etc. in the min model? It really should
work on Mac. Would be valuable if you could dig a bit more and debug what
is happening in prepInitData. But I would compare the prepDatas and see
what went wrong first, and then debug and see where that field(s) get their
bad values. Also strange with that warning you got, I didn't. Could be
something with the boundary metabolites. I don't have more advice,
debugging is the key, it should be doable.
On Thu, Aug 17, 2023 at 12:24 PM Roko Sango ***@***.***> wrote:
Ok, probably not a Gurobi thing then, which is good, could have been
complicated to solve. This is strange. I also used RAVEN 2.8.4. I used the
latest mouse-GEM, just downloaded it, I guess that is the same. And, the
same MATLAB version. I do have an older Human-GEM though, something from
devel in the middle. Does it work with the prepData I emailed you, could
you test that?
I can confirm I have now tried with your prepData object, and for both
getHumanGEMINITSteps('1+0') and getHumanGEMINITSteps('1+1') and within
seconds I have successful generation of the models.
Really interesting as to what has gone wrong in my case when generating
prepData, seeing we are using dependencies with identical versions. Maybe
something to do with the OS -> I am running the whole thing on macOS
Ventura 13.4.1
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHX2AKZBPFZM7JQAHLH7TWLXVZASDANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
—
Reply to this email directly, view it on GitHub<#511 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWOCBQKEUNPEWNJDDV7JQVTXVZLNFANCNFSM6AAAAAAWE6YHOM>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Ah, sorry, I didn't pay enough attention, the tasks did not pass in my run.
Let me look at this again, your prepdata is probably better than mine. I
will get back to you once I have checked this.
On Sun, Aug 20, 2023 at 11:12 AM Roko Sango ***@***.***>
wrote:
… Hi,
Here are the screenshots from your prepData and mine:
[A screenshot of a computer Description automatically generated] [A
screenshot of a computer Description automatically generated]
minModel in each case look identical (also refModel fields look
identical):
***@***.*** ***@***.***
In the first pair of screenshots, you can see differences in numbers in
essentialRxns, taskStruct, essentialMetsForTasks.
Another difference is in prepData.taskReport.ok field: all of values in
your cases are 0’s, in mine all of them are 1’s. Perhaps there is something
wrong with the task structures that are part of my prepData? I would need
to look closely into this.
Best,
Roko
From: johan-gson ***@***.***>
Date: Thursday, 17. August 2023 at 19:56
To: SysBioChalmers/Human-GEM ***@***.***>
Cc: Roko Sango ***@***.***>, Mention ***@***.***>
Subject: Re: [SysBioChalmers/Human-GEM] ERROR using ftINIT. MipGap too
high, trying with a different run. (Issue #511)
Hmm, yes, weird. Can you see any difference between the prepData objects,
for example number of reactions etc. in the min model? It really should
work on Mac. Would be valuable if you could dig a bit more and debug what
is happening in prepInitData. But I would compare the prepDatas and see
what went wrong first, and then debug and see where that field(s) get
their
bad values. Also strange with that warning you got, I didn't. Could be
something with the boundary metabolites. I don't have more advice,
debugging is the key, it should be doable.
On Thu, Aug 17, 2023 at 12:24 PM Roko Sango ***@***.***>
wrote:
> Ok, probably not a Gurobi thing then, which is good, could have been
> complicated to solve. This is strange. I also used RAVEN 2.8.4. I used
the
> latest mouse-GEM, just downloaded it, I guess that is the same. And, the
> same MATLAB version. I do have an older Human-GEM though, something from
> devel in the middle. Does it work with the prepData I emailed you, could
> you test that?
>
> I can confirm I have now tried with your prepData object, and for both
> getHumanGEMINITSteps('1+0') and getHumanGEMINITSteps('1+1') and within
> seconds I have successful generation of the models.
>
> Really interesting as to what has gone wrong in my case when generating
> prepData, seeing we are using dependencies with identical versions.
Maybe
> something to do with the OS -> I am running the whole thing on macOS
> Ventura 13.4.1
>
> —
> Reply to this email directly, view it on GitHub
> <
#511 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AHX2AKZBPFZM7JQAHLH7TWLXVZASDANCNFSM6AAAAAAWE6YHOM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub<
#511 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AWOCBQKEUNPEWNJDDV7JQVTXVZLNFANCNFSM6AAAAAAWE6YHOM>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHX2AK2ZOB3FAHMQPV3YOATXWISO5ANCNFSM6AAAAAAWE6YHOM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I have rerun it and now get the same problem as you, so at least it is
reproducible. All the tasks pass now. This will take some time for me to
solve, it is not trivial, sorry about that. I will get back to you when I
know more,
On Sun, Aug 20, 2023 at 11:38 AM Johan Gustafsson <
***@***.***> wrote:
… Ah, sorry, I didn't pay enough attention, the tasks did not pass in my
run. Let me look at this again, your prepdata is probably better than mine.
I will get back to you once I have checked this.
On Sun, Aug 20, 2023 at 11:12 AM Roko Sango ***@***.***>
wrote:
> Hi,
> Here are the screenshots from your prepData and mine:
>
> [A screenshot of a computer Description automatically generated] [A
> screenshot of a computer Description automatically generated]
>
> minModel in each case look identical (also refModel fields look
> identical):
>
>
>
> ***@***.*** ***@***.***
>
> In the first pair of screenshots, you can see differences in numbers in
> essentialRxns, taskStruct, essentialMetsForTasks.
> Another difference is in prepData.taskReport.ok field: all of values in
> your cases are 0’s, in mine all of them are 1’s. Perhaps there is something
> wrong with the task structures that are part of my prepData? I would need
> to look closely into this.
>
> Best,
> Roko
>
>
> From: johan-gson ***@***.***>
> Date: Thursday, 17. August 2023 at 19:56
> To: SysBioChalmers/Human-GEM ***@***.***>
> Cc: Roko Sango ***@***.***>, Mention ***@***.***>
> Subject: Re: [SysBioChalmers/Human-GEM] ERROR using ftINIT. MipGap too
> high, trying with a different run. (Issue #511)
> Hmm, yes, weird. Can you see any difference between the prepData objects,
> for example number of reactions etc. in the min model? It really should
> work on Mac. Would be valuable if you could dig a bit more and debug what
> is happening in prepInitData. But I would compare the prepDatas and see
> what went wrong first, and then debug and see where that field(s) get
> their
> bad values. Also strange with that warning you got, I didn't. Could be
> something with the boundary metabolites. I don't have more advice,
> debugging is the key, it should be doable.
>
> On Thu, Aug 17, 2023 at 12:24 PM Roko Sango ***@***.***>
> wrote:
>
> > Ok, probably not a Gurobi thing then, which is good, could have been
> > complicated to solve. This is strange. I also used RAVEN 2.8.4. I used
> the
> > latest mouse-GEM, just downloaded it, I guess that is the same. And,
> the
> > same MATLAB version. I do have an older Human-GEM though, something
> from
> > devel in the middle. Does it work with the prepData I emailed you,
> could
> > you test that?
> >
> > I can confirm I have now tried with your prepData object, and for both
> > getHumanGEMINITSteps('1+0') and getHumanGEMINITSteps('1+1') and within
> > seconds I have successful generation of the models.
> >
> > Really interesting as to what has gone wrong in my case when generating
> > prepData, seeing we are using dependencies with identical versions.
> Maybe
> > something to do with the OS -> I am running the whole thing on macOS
> > Ventura 13.4.1
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <
> #511 (comment)>,
>
> > or unsubscribe
> > <
> https://github.com/notifications/unsubscribe-auth/AHX2AKZBPFZM7JQAHLH7TWLXVZASDANCNFSM6AAAAAAWE6YHOM>
>
> > .
> > You are receiving this because you were mentioned.Message ID:
> > ***@***.***>
> >
>
>
> —
> Reply to this email directly, view it on GitHub<
> #511 (comment)>,
> or unsubscribe<
> https://github.com/notifications/unsubscribe-auth/AWOCBQKEUNPEWNJDDV7JQVTXVZLNFANCNFSM6AAAAAAWE6YHOM>.
>
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
> —
> Reply to this email directly, view it on GitHub
> <#511 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHX2AK2ZOB3FAHMQPV3YOATXWISO5ANCNFSM6AAAAAAWE6YHOM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Hi @johan-gson, did you have any luck finding a solution to this issue? Thanks! |
Sorry I have not. I will try to take another look at this in the coming weeks. Sorry for the delay, I have a pretty heavy workload right now. |
No worries, thanks for your efforts! |
Hello,
I am trying to create context-specific GEM models for my transcriptomic data using the Cobra toolbox and gurobi solver in Matlab. I have created models before using the same Human-GEM guide. Now it's showing me some error due to high MipGap and I feel it is because of the solver.
command for creating model:
The error shown after running this is:
Any help would be appreciated.
Thank you.
The text was updated successfully, but these errors were encountered: