modsim / fluxml Goto Github PK

All python programs (except setinputs and multiply_fml) as well as the shared flux.py are python2

This will lead to confusing error messages later on about missing files.

The method (fml_method) attribute of a configuration is not part of the official FluxML standard. If it is kept for legacy reasons the value should go somewhere

Parsing failed: cfg "XXX": error parsing measurement element: [unexpected extra content in element "model"]

This occurs if inside <configuration><measurement><model> either a non existing tag is introduced, or the order of tags is switched.

In the first case the error should explicitly mention the wrong element.
The second case should actually not be an error

Hi,
the compilation hits this :

data/Notation.cc:1105:10: fatal error: Notation.inc: No such file or directory
 #include "Notation.inc"

There's no file named like this in the repository. Is it missing ? Or a fie to rename ?
Tks for your help,

For flux/pool (ratio) measurement groups no time stamp is added (getTimeStampSet returns an empty set). It would be better to add -1 to the set, because you can than generically get measurement data by iterating over the set. Right now, this works for all measurements but the parameter measurements.
Also, it does not make sense to even have such a set if it would supposed to be empty in every scenario.

libFluxML has extensive output options for helpful output, as #6 showed, those go nowhere if the user did not specify a destination via PUBLISHLOG(destination). This is essentially a bug in documentation.

• reorder
• sign-compare
• tautological-compare
• unused-variable / unused-but-set-variable
• switch

libFluxML should compile without warnings.The tautological-compares might be hard to fix, as they come from auto generated code

When trying to instantiate the FluxMLDocument class like

flux::xml::FluxMLDocument doc("<Not existing file>"); 

an seg fault accures. GDB says it happens in line 112 of FluxMLDocument.cc when you try to get the document from the DOMReader.

It also happens in your example program when you give it an invalid fluxml path.

We need to update it. I've made this issue to reference in the PR.

Information about multi-isotope tracers are stored by the iso_cfg_ character pointer map for each pool. However, the character pointers used as map keys are not like "N" for nitrogen as expected, but "N"+a string of mishmash characters.

Otherwise an error is raised

FluxML parsing error: input pool "XXX" specified in equality constraint

or

FluxML parsing error: input pool "XXX" specified in inequality constraint

This originates in fluxml/FluxMLInput.cc, where all equality/inequality constraints are checked for input pool names. It should only be equality constraints for pools.

I would argue, that it is bad practice to have fluxes and pools of the same name, nonetheless this should be fixed.

also: In the error the actual constraint should be printed

only reason is the -W flag. We should check for version and set the flag only where supported

A lower bound of 1e-5 is enforced on pool sizes. This does not make sense when using e.g. mumol/gdw as unit

Hey,

FluxML relies on sys/prctl.h and other sys files. These files are not available on linux.
Perhaps we can find a way to replace/remove them for macOS builds.

workaround:
cd symbolicmath
make ExprParser.cc
cd ..
after that make will function normally

I see no reason, why arbitrary precision math is needed anywhere

Hello FluxML dev team,

I read the specifications for FluxML and I have a very naive question: why didn't you choose to make an SBML package instead of creating a stand-alone file format? Did I miss something?

In the paper, you argue that:

1. "[...] the set of common features [between FluxML and SBML] is not that large."
2. another author already made a prototype using (and abusing) SBML's <notes> tag

If anyone would agree with 2/ which is indeed regarded as bad-practice in the SBML community, I guess the 1/ is more subject to interpretation, especially considering that SBML is precisely supposed to be a common ground for all software that deal with... well, systems biology. I was very surprised you didn't mentioned the SBML's packages there. SBML is designed to be enriched by packages, like the classic fbc package that add all the features needed for flux balance constraints and that you can find in every single genome-scale model out there.

So, with that in mind, I was wondering if there was some kind of technical issue that forced you to make you own file format; and if that's not the case, if you are considering creating an SBML package for metabolic flux analysis based on you great work on FluxML?