Aquileo | Recent changes to feature-requestshttps://sourceforge.net/p/sbfc/feature-requests/2021-04-26T23:03:16.968000ZRecent changes to feature-requestsAquileo | Raise warning when trying to convert non-kinetic SBML models to other ODE formats2021-04-26T23:03:16.968000Z2021-04-26T23:03:16.968000ZAnonymoushttps://sourceforge.net/u/userid-None/https://sourceforge.net888718007fd88a500316bc40e73cc0a9e69ef086<div class="markdown_content"><p>For example, the conversion tool converts SBML-qual models to MATLAB and XPP files without any warning. While this conversion is possible, the conversion substantially distorts the meaning of the model. I think a warning would be helpful for people not familiar with these formats who may not be aware the SBML-qual files don't describe ODE simulations.</p></div>Aquileo | Expand Testing for SBML to/from BioPAX2018-10-11T20:24:47.728000Z2018-10-11T20:24:47.728000ZTramy Nguyenhttps://sourceforge.net/u/tramy-nguyen/https://sourceforge.netc2765bab7ab32bd5f59ec884d14cc892efc8d501<div class="markdown_content"><p>The SBML to BioPAX and BioPAX to SBML converter test cases needs to be cleaned and improved. Currently, the test cases in these converteres are limited to testing roundtripping data to ensure data are not lost. However, more test cases must be applied to represent the core data that are being translated between the two standards. </p></div>Aquileo | Support SBML Group Annotation2018-10-09T19:49:10.986000Z2018-10-09T19:49:10.986000ZTramy Nguyenhttps://sourceforge.net/u/tramy-nguyen/https://sourceforge.net55e90a0b9c972418640d825c35907e9636cd6722<div class="markdown_content"><p>The current BioPAX to SBML conversion does not convert duplicate BioPAX entities to it's equivalent SBML SBase object. The decision that was made in the GSoC 2016 project is to make use of the SBML Group Extension package to support these BioPAX information. This feature has yet to be supported in the converter.</p></div>Aquileo | Lost Stoichiometry in SBMLtoBioPAX2018-10-09T18:30:33.227000Z2018-10-09T18:30:33.227000ZTramy Nguyenhttps://sourceforge.net/u/tramy-nguyen/https://sourceforge.net9db1b5eab4f70d06bc09103cd6a5a241e3229132<div class="markdown_content"><p>SBO terms found on SBML Reactions do not all map to the SBO terms that are supported in BioPAX. The discussion that came out of this problem for the GSoC 2016 program was to suggest to have BioPAX annotate the SBO terms that are unable to map from SBML to BioPAX. Currently, the SBML2BioPAX conversion will drop these SBO terms in SBML Reactions that do not directly map over to BioPAX.</p></div>Aquileo | Request MIRIAM Qualifiers for SBML Custom Annotations2018-10-09T17:54:33.421000Z2018-10-09T17:54:33.421000ZTramy Nguyenhttps://sourceforge.net/u/tramy-nguyen/https://sourceforge.net1a6066b735378891252b192316a773376eae7f8d<div class="markdown_content"><p>In the SBML to BioPAX conversion, <a class="" href="http://co.mbine.org/standards/qualifiers" rel="nofollow">MIRIAM Qualifiers</a> are used for SBML elements with CVTerms to annotate BioPAX information.<br/> The MIRIAM qualifiers that are currently available to use are not capable of capturing all information needed for the conversion. Qualifier.BQB_UNKNOWN is currently used in the conversion as a temporary fix. It would be good to update this qualifier with the new terms that were requested for the GSoC 2016 project related to this conversion. </p></div>Aquileo | Custom Annotation in BioPAX to SBML2018-10-09T15:46:25.630000Z2018-10-09T15:46:25.630000ZTramy Nguyenhttps://sourceforge.net/u/tramy-nguyen/https://sourceforge.netf3040b8d18b9e0e2afa30f4d040972b79b181cb0<div class="markdown_content"><p>Not all BioPAX entity’ properties could directly map to an SBML element. We should considere using custom annotations to store information that cannot be mapped directly for both conversion. SBML has a variety of different ways to annotate external models and its property such as using CVTerm annotation using MIRIAM qualifiers or creating a customize annotation. </p></div>Aquileo | Converting SBML with Multiple Levels of Hierarchy 2018-10-09T15:43:46.798000Z2018-10-09T15:43:46.798000ZTramy Nguyenhttps://sourceforge.net/u/tramy-nguyen/https://sourceforge.net9b60d0da22cd462d2839e653a160342ee81ef34d<div class="markdown_content"><p>If an SBML file has more than 2 levels of hierarchy for nested submodules, the current SBML to BioPAX converter will flatten the first two layers of the SBML model the converter encounters and ignore the remaining nested models. It would be great if the conversion can perform flattening of all SBML nested models before conversion is performed from SBML to BioPAX. </p></div>Aquileo | Octave Module's Resulting Code Structure split2017-04-19T10:04:37.172000Z2017-04-19T10:04:37.172000ZAnonymoushttps://sourceforge.net/u/userid-None/https://sourceforge.netc6ea42b0fb7d33f666ccf051ed663ce18ad3533d<div class="markdown_content"><p>Hi,<br/> I think that the Octave Code could be structured in a more useful way:<br/> A function that calculates the reaction fluxes and collects them in the vector "Flux", given an arbitarray parametrisation, which is necessary for parameter estimation:<br/> function Flux=ModelFlux(x,t,p)<br/> A second function calculates the right hand side of the ODE, using those fluxes, and possibly additional parameters, if necessary:<br/> function xdot=ModelRHS(Flux,p)<br/> then define f and use it like this:</p> <p>p=get_model_parameters();<br/> x0=get_model_init();<br/> f=@(x,t) ModelRHS(ModelFlux(x,t,p))<br/> lsode(f,x0,t=linspace(0,T,n));<br/> This will perhaps not be as fast as hard-coding everything but a lot more useful for optimisation purposes.</p> <p>Analytically calculating the jacobian and parameter derivative would be a nice feature as well, as lsode runs better if you supply a jacobain function: </p> <p>lsode({f,J},x0,t);</p> <p>It's generally not great that the fluxes are never collected in a vector I think.<br/> All the Best,<br/> Andrei</p></div>Aquileo | being able to change the output extension2014-11-24T15:32:01.569000Z2014-11-24T15:32:01.569000ZNicolas Rodriguezhttps://sourceforge.net/u/niko-rodrigue/https://sourceforge.netc788ca3b759125911c880d778b272b23c2e390bc<div class="markdown_content"><p>It would be convenient to allow the user to specify which extension he want the resulting file to be saved with.<br /> Even, specifying where the output file should be saved and with which name would be good options.</p></div>Aquileo | octave variable names2011-04-21T02:58:13Z2011-04-21T02:58:13ZLukas Endlerhttps://sourceforge.net/u/luen/https://sourceforge.net3e4a30fbc637111896c809f40c57a3192996f65e<div class="markdown_content"><p>Dear Nico,<br /> It would be great to have a list of names next to the state variables x. Mabe it could be next to the initialisation:</p> <p>#Initial conditions vector<br /> x0=zeros(19,1);<br /> x0(1) = 0.0; # species id: blub name: bla<br /> x0(2) = 0.0; # species id: blob name: bli<br /> x0(3) = 0.0; # parameter id: truc name: troc</p> <p>Also it would be great to include that at the start of the file as a comment.</p> <p>all the best<br /> lukas</p></div>