Skip to content
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

[BUG] SED-ML files for native and SBML models have involve different numbers of models (archives are not equivalent) #8

Open
jonrkarr opened this issue Mar 1, 2022 · 3 comments
Assignees

Comments

@jonrkarr
Copy link

jonrkarr commented Mar 1, 2022

Example (12119723):

The SED-ML for native has 1 model, 3 simulations, and 3 tasks.

The SED-ML for SBML has 3 models, 3 simulations, and 3 tasks. The SBML files used by the SED-ML are not identical.

Because the SBML files used by the SED-ML are not identical, the two versions of the COMBINE archives are not equivalent.

@jonrkarr jonrkarr changed the title SED-ML files for native and SBML models have involve different numbers of models (archives are not equivelant) SED-ML files for native and SBML models have involve different numbers of models (archives are not equivalent) Mar 1, 2022
@jonrkarr jonrkarr changed the title SED-ML files for native and SBML models have involve different numbers of models (archives are not equivalent) BUG: SED-ML files for native and SBML models have involve different numbers of models (archives are not equivalent) Mar 1, 2022
@jonrkarr jonrkarr changed the title BUG: SED-ML files for native and SBML models have involve different numbers of models (archives are not equivalent) [BUG] SED-ML files for native and SBML models have involve different numbers of models (archives are not equivalent) Mar 1, 2022
@jonrkarr jonrkarr added the bug Something isn't working label Mar 2, 2022
@moraru moraru removed the bug Something isn't working label Apr 7, 2022
@moraru
Copy link
Member

moraru commented Apr 7, 2022

This is not a bug, it is by design, and is correct. The native format (VCML) encodes one or more variations of a model, each of which needs to be translated into a corresponding SBML model upon export. The tree structure of the VCell BioModel is roughly equivalent to a SEDML file, With the Application being the model and the Simulation being the task.

Therefore there will always be exactly 1 model when creating OMEX with VCML format but 1..n models when creating OMEX with SBML format. The total number of tasks however should always be identical.

@moraru
Copy link
Member

moraru commented Apr 7, 2022

@jonrkarr if you want to check equivalency you need to count the tasks and match the simulation names

@moraru moraru assigned jonrkarr and unassigned moraru and danv61 Apr 7, 2022
@jonrkarr
Copy link
Author

jonrkarr commented Apr 7, 2022

Understand that. The issue is that the VCML vs SBML tasks are different:

  • The VCML OMEX involves 3 tasks for the same model (there are no model changes encoded into SED-ML)
  • The SBML OMEX involves 3 tasks for 3 different models (the SBML files have different parameter values)

If the VCML tasks are intended to simulate different variants of a model, I think this should be encoded using SED-ML model changes, which is not presently the case. It sounds like this is what's happening:

  • Either model changes are encoded into VCML (meaning they are hidden from SED-ML) or they are not correctly encoded into SED-ML
  • Model changes encoded into SED-ML are potentially being ignored

From my perspective, this is unintuitive because it deviates from how SED-ML is intended to be used. In the case of other model languages (SBML-fbc, SBML-qual, BNGL, NeuroML/LEMS, Smoldyn, RBA XML, XPP ODE), I have used SED-ML to capture model changes, including when those languages have capabilities to capture model variants themselves. Encoding model changes into SED-ML is important to enabling us to use SED-ML as an abstraction for specifying changes to models in any format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants