ERROR using ftINIT. MipGap too high, trying with a different run.

[ShwetaNagre]

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:

model1 = ftINIT(prepData, data_struct.tissues{1}, [], [], data_struct, {}, getHumanGEMINITSteps('1+0'), false, true);

The error shown after running this is:

ftINIT: Running step 1
MILP detected.
MipGap too high, trying with a different run. MipGap = Inf New MipGap Limit = 0.003
MILP detected.
Error using dispEM
Failed to find good enough solution within the time frame. MIPGap: Inf

Error in ftINIT (line 281)
        dispEM(['Failed to find good enough solution within the time frame. MIPGap: ' num2str(mipGap)]);

Any help would be appreciated. Thank you.

[johan-gson]

@ShwetaNagre Did you get past this issue?

[ShwetaNagre]

Hi @johan-gson, Yes, it was working afterward with the same code.

[johan-gson]

Ok, I'm closing this now.

[manas-kohli]

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

[johan-gson]

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 https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1493057589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHX2AK33RNLVAMRWSHNPD3TW7BTUXANCNFSM6AAAAAAWE6YHOM . You are receiving this because you modified the open/close state.Message ID: @.***>

[johan-gson]

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.

[johan-gson]

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.

[manas-kohli]

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

[johan-gson]

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 https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1493065861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHX2AK6FD7LVKUSLY5TGWCLW7BWJ7ANCNFSM6AAAAAAWE6YHOM . You are receiving this because you modified the open/close state.Message ID: @.***>

[ShwetaNagre]

Sorry for the late reply @manas-kohli, good that you got this cleared. This error was indeed due to the versions of RAVEN/Gurobi. I too updated my RAVEN and then it worked.

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.

[johan-gson]

@ShwetaNagre Sorry, forgot to answer this. Could you clarify - is it with the newer version of RAVEN you get problems?

[mihai-sysbio]

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.

[johan-gson]

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.

[mihai-sysbio]

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]".

[edkerk]

@mihai-sysbio No auto-update, checkInstallation just reports if there is a newer version and nudges the user to update.

[MengJ-bioDyn]

@johan-gson

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."?
I have ran into the same problem with Gurobi 10.0.1 and RAVEN 2.8.1, Matlab R2019b, and i am confused with the other's solutions. ftINIT: Running step 1 MILP detected. MipGap too high, trying with a different run. MipGap = Inf New MipGap Limit = 0.003 MILP detected. Error using dispEM (line 49) Failed to find good enough solution within the time frame. MIPGap: Inf Error in ftINIT (line 281) dispEM(['Failed to find good enough solution within the time frame. MIPGap: ' num2str(mipGap)]);

Thank you very much in advance!!

[johan-gson]

@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.

[johan-gson]

My email address is johan.gson@gmail.com if you are willing to send your data and code.

[johan-gson]

Hi Meng,

Not sure where the data is, could you by any chance share it via google drive?

[johan-gson]

ok, will have a look!

[johan-gson]

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?

[MengJ-bioDyn]

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 https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1595594093, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAI4EECRAA6KX7F6H7ETM3XLUNYRANCNFSM6AAAAAAWE6YHOM . You are receiving this because you were mentioned.Message ID: @.***>

[johan-gson]

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.

[johan-gson]

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 < https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1595772217>,

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 https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1597864803, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHX2AK63W6VVJO5MS6ZSCSLXMDL7VANCNFSM6AAAAAAWE6YHOM . You are receiving this because you were mentioned.Message ID: @.***>

[rsango6]

Hi there, I am here to report the same error:

Error using dispEM
Failed to find good enough solution within the time frame. MIPGap: Inf

Error in ftINIT (line 281)
        dispEM(['Failed to find good enough solution within the time frame. MIPGap: ' num2str(mipGap)]);

I have gone through all the comments, have the most recent RAVEN version (2.8.4) and Gurobi version 10.0.2. My gene names are all in order, i.e. they are ENSEMBL-style like so:

                GeneName        AT_1      AT_2      AT_3      AT_4 
    ______________________    ______    ______    ______    ______

    {'ENSMUSG00000000001'}    81.164    87.099    76.508    86.454
    {'ENSMUSG00000000003'}         0         0         0         0
    {'ENSMUSG00000000028'}    6.3361    17.716    6.8409    3.0719
    {'ENSMUSG00000000037'}    3.8911    9.5444    8.2382    4.5037
    {'ENSMUSG00000000049'}    4.2952    7.6122    1.6615    1.3399

Would appreciate if anyone has any feedback on this! Many thanks

[johan-gson]

Hi @rsango6, I think the solution to you problem is to convert the genes to gene symbols. While Human-GEM is in ensembl format, I think mouse-GEM, which I assume you are using, requires gene symbols. So just test to convert the genes and see if it works! Otherwise, let me know and we can dig further!

[rsango6]

Hi @johan-gson, thanks for your speedy reply.

I forgot that Mouse-GEM has gene symbols instead! I have tried to do the following;

data_struct = 

  struct with fields:

        genes: {29260×1 cell}
        tissues: {1×52 cell}
        levels: [29260×52 double]
        threshold: 1

and the genes are:

>> data_struct.genes(1:5)

ans =

  5×1 cell array

    {'Gnai3'}
    {'Pbsn' }
    {'Cdc45'}
    {'Scml2'}
    {'Apoh' }

but I still get the same error as before. Could it be that the this cell array that contains gene symbols, has to be transformed in some different structure before is fed to ftINIT?

[johan-gson]

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?

[haowang-bioinfo]

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?

[rsango6]

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?

Hello, Yes, the data is in TPM, as obtained from Salmon quantification tool. I have checked both prepData.refModel.grRules and prepData.minModel.grRules.

In prepData.refModel.grRules:

>> prepData.refModel.grRules(1:10)

ans =

  10×1 cell array

    {'Adh1 or Adh4 or Adh5 or Adh6b or Adh7 or Adhfe1'    }
    {'Akr1a1'                                             }
    {'Acss2'                                              }
    {'Acss1 or Acss3'                                     }
    {'Acss2'                                              }
    {'Acss2'                                              }
    {'Ldha or Ldhb'                                       }
    {'Ldha or Ldhal6b or Ldhb or Ldhc'                    }
    {'Aldh1a3 or Aldh3a1 or Aldh3b1 or Aldh3b2 or Aldh3b3'}
    {'Aldh1b1 or Aldh2 or Aldh3a2 or Aldh7a1 or Aldh9a1'  }

As for prepData.minModel.grRules, this is an just an empty array with no grRules. Could this be the reason for the error?

In addition, prepData.minModel.genes is also empty.

[johan-gson]

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?

[rsango6]

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 convertGenes as is, so this flag is false. I also tried just running prepHumanModelForftINIT as shown in tutorial like so:

prepDataHuman = prepHumanModelForftINIT(ihuman, false, ...
    '/path/to/Human-GEM/data/metabolicTasks/metabolicTasks_Essential.txt', ...
    'path/to/Human-GEM/model/reactions.tsv');

Here I also get the same error:

>> prepDataHuman.minModel

ans = 

  struct with fields:

                     id: 'Human-GEM'
            description: 'Generic genome-scale metabolic model of Homo sapiens'
                   rxns: {7079×1 cell}
                   mets: {2798×1 cell}
                      S: [2798×7079 double]
                     lb: [7079×1 double]
                     ub: [7079×1 double]
                    rev: [7079×1 double]
                      c: [7079×1 double]
                      b: [2798×1 double]
                  comps: {9×1 cell}
              compNames: {9×1 cell}
               rxnNames: {7079×1 cell}
                grRules: {7079×1 cell}
             rxnGeneMat: [7079×0 double]
             subSystems: {7079×1 cell}
                eccodes: {7079×1 cell}
               rxnNotes: {7079×1 cell}
                  genes: {}
         geneShortNames: {}

Here the prepDataHuman.minModel.grRules looks like its populated with values, but it's not:

>> prepDataHuman.minModel.grRules(1:5)

ans =

  5×1 cell array

    {0×0 char}
    {0×0 char}
    {0×0 char}
    {0×0 char}
    {0×0 char}

I then looked into how prepData is generated, and realized that at step 4 "Second simplification (~1 hour)" Parallel Computing Toolbox wasn't installed. I installed it, ran prepHumanModelForftINIT and got the same results, so it's not even that. It's weird, because I would be expecting the code to yell because of issues if nothing is detected in prepData.minModel.genes and prepData.minModel.grRules.

I hope I haven't made this super confusing!

[rsango6]

Another update from my side:

I decided to manually impute missing grRules values inside prepData.minModel like so:

common_rxns = intersect(MouseGEM.rxns, prepData.minModel.rxns)
grRules = MouseGEM.grRules(ismember(MouseGEM.rxns, common_rxns))
prepData.minModel.grRules = grRules

and running:

model1 = ftINIT(prepData, data_struct.tissues{1}, [], [], data_struct, {}, getHumanGEMINITSteps('1+0'), false, true)

produces again the same error. maybe it also needs prepData.minModel.genes structure to be populated with values.

[johan-gson]

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 :).

[johan-gson]

See https://github.com/SysBioChalmers/Mouse-GEM/issues/22

[johan-gson]

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.

[rsango6]

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 :).

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 :)

[mihai-sysbio]

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.

[johan-gson]

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 :)

[haowang-bioinfo]

@johan-gson yes I just checked the latest Mouse-GEM, which still has two columns in the b field - fix it now

[johan-gson]

@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.

[johan-gson]

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?

[johan-gson]

I'm using the latest mouse gem

[johan-gson]

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.

[rsango6]

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 am using:

Human-GEM v1.16.0 Mouse-GEM v1.6.0 RAVEN v2.8.4 MATLAB v2019b

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 ftINIT call there is a WARNING: Exchange metabolites are still present in the model. Use simplifyModel if this is not intended. Could that be the reason why? However, I had to use addBoundaryMets() on the mouseGEM otherwise I would get an error at a previous step with prepHumanModelForftINIT:

Step 3: Check tasks (~10 min)
Attempt to grow array along ambiguous dimension.

Error in closeModel (line 50)
        closedModel.b(numel(closedModel.b)+1)=0;

Error in prepINITModel (line 82)
    bModel = closeModel(cModel);

Error in prepHumanModelForftINIT (line 133)
prepDataHumanGEM = prepINITModel(m, taskStruct, spontRxnNames, convertGenes, customRxnsToIgnore, 'e');

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.

[johan-gson]

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?

[rsango6]

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

[johan-gson]

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 https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1682593823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHX2AKZBPFZM7JQAHLH7TWLXVZASDANCNFSM6AAAAAAWE6YHOM . You are receiving this because you were mentioned.Message ID: @.***>

[haowang-bioinfo]

@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.

the fix is now implemented by bb4cc9fb81d3bbae249468b94734c2122030b4fa in #692

[rsango6]

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 https://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1682593823, 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 GitHubhttps://github.com/SysBioChalmers/Human-GEM/issues/511#issuecomment-1682724575, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AWOCBQKEUNPEWNJDDV7JQVTXVZLNFANCNFSM6AAAAAAWE6YHOM. You are receiving this because you were mentioned.Message ID: @.***>