Comp package: Have a species in one submodel replace a species in another submodel?

Daniel Palm

unread,

Jan 20, 2015, 7:25:54 AM1/20/15

to libsbml-d...@googlegroups.com

Dear all

Suppose I have two external models that I cannot change (well, I can, but it's undesirable for a number of reasons):

model1:

A -> B

model 2:

C -> D

I want to combine these, but B and C are actually the same species and in the same compartments. The final model should look like this

model_combined:

A -> C

C -> D

with A in compartment 1 and C and D in compartment 2.

Am I right that the only way would be to have model1 and model2 as submodels of another model. And make a new compartment that replaces that of B, C, and D, and make a new species C that replaces B and the old C?

It would be nice if I could simply say somehow that C (model2) replaces B (model1) and that the compartment of C replaces the compartment of B. Is this possible?

I would be grateful for any help.

Best regards

Daniel

Lucian Smith

unread,

Jan 20, 2015, 12:33:26 PM1/20/15

to libsbml-d...@googlegroups.com, The SBML L3 Hierarchical Model Composition package discussion list

You are exactly correct: you need to provide local copies of things that can then replace or be replaced by elements in the submodels. To recreate your situation in Antimony:

model model1()

species A in comp1, B in comp2

A -> B;

end

model model2()

species C in comp3, D in comp3

C -> D;

end

model combined()

//Declare the local species and compartment:

species C2 in cMain

//Import the other models as submodels:

M1: model1()

M2: model2()

//Connect the compartments and species

M1.comp2 is cMain

M2.comp3 is cMain

M1.B is C2

M2.C is C2

end

Which in SBML would be the attached model (though presumably with external model definitions instead of local ones).

This version used the 'replacedElement' constructs, but you could also pick one of them and used the 'replacedBy' construct. In that case, any initialConcentration or other attribute value would be taken from the submodel target of that replacedBy, instead of by the parent model.

-Lucian

--
You received this message because you are subscribed to the Google Groups "libsbml-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libsbml-develop...@googlegroups.com.
To post to this group, send email to libsbml-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libsbml-development/4de5441e-6c12-4c35-ab4e-add00670f69e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

palm_example.xml

Daniel Palm

unread,

Jan 21, 2015, 2:51:39 AM1/21/15

to libsbml-d...@googlegroups.com, sbml...@lists.sourceforge.net

Thanks for the detailed reply Lucian.

Would it be possible to give me an example of using replacedBy. My concern with replacedElement is that it violates the DRY principle in that you have to specify the details of the compartments and species again in the parent model. This probably isn't usually a big deal, but with large models it can become a pain.

Moreover, I have initial assignments for everything, which results in warnings about duplicate initial assignments. It is not clear to me how to remove or even replace initial assignments (or other rules) in one of the submodels. Should one rely on metaids there?

Thanks again

Daniel

Lucian Smith

unread,

Jan 21, 2015, 1:29:01 PM1/21/15

to The SBML L3 Hierarchical Model Composition package discussion list, libsbml-d...@googlegroups.com

Sure! Don't forget that the point of the comp format is that it stores the information unambiguously, but it is the point of front ends *to* the comp specification to hide some of these details from the user. So, for example, Antimony takes care of the initial assignments for you, as you guessed, by using metaids. The model:

model mod1()

x1 = 1+y

end

model mod2()

x2 = 1-z

end

model main()

A: mod1()

B: mod2()

A.x1 is xmain

B.x2 is xmain

end

gets translated to SBML as:

<?xml version="1.0" encoding="UTF-8"?>

<comp:listOfReplacedElements>

<comp:replacedElement comp:idRef="x1" comp:submodelRef="A"/>

<comp:replacedElement comp:idRef="x2" comp:submodelRef="B"/>

</comp:listOfReplacedElements>

</parameter>

</listOfParameters>

<comp:listOfSubmodels>

<comp:submodel comp:id="A" comp:modelRef="mod1"/>

<comp:submodel comp:id="B" comp:modelRef="mod2">

<comp:listOfDeletions>

<comp:deletion comp:metaIdRef="mod2__x2__initialAssignment"/>

</comp:listOfDeletions>

</comp:submodel>

</comp:listOfSubmodels>

</model>

<comp:listOfModelDefinitions>

<comp:modelDefinition id="mod1" name="mod1">

</listOfParameters>

<apply>

<plus/>

</apply>

</math>

</initialAssignment>

</listOfInitialAssignments>

</comp:modelDefinition>

<comp:modelDefinition id="mod2" name="mod2">

</listOfParameters>

<apply>

</apply>

</math>

</initialAssignment>

</listOfInitialAssignments>

</comp:modelDefinition>

</comp:listOfModelDefinitions>

</sbml>

which gives the extra initial assignment a metaid, and then uses that metaid in a deletion.

If you can't modify the submodel at all, even to give the initialAssignment a metaid, there's unfortunately nothing in the Hierarchical Composition package that will let you reference that element! This was a sort of compromise position in the end--we could have used the xpath operator to reference these elements, but the complexity of doing so was judged (at least for version 1) to be too much for a situation that, it was believed, would not come up all that often. If this turns out to be a major design barrier to you, however, we can consider adding it back in for version 2!

As far as 'replacedBy', unfortunately, Antimony does not use that construct at the moment in its output (though this could be added in the future). But I can mock you up an example. For simplicity, I'm just using parameters with a 'value' attribute:

<?xml version="1.0" encoding="UTF-8"?>

<comp:listOfReplacedElements>

<comp:replacedElement comp:idRef="x1" comp:submodelRef="A"/>

</comp:listOfReplacedElements>

<comp:replacedBy comp:idRef="x2" comp:submodelRef="B"/>

</parameter>

</listOfParameters>

<comp:listOfSubmodels>

<comp:submodel comp:id="A" comp:modelRef="mod1"/>

<comp:submodel comp:id="B" comp:modelRef="mod2"/>

</comp:listOfSubmodels>

</model>

<comp:listOfModelDefinitions>

<comp:modelDefinition id="mod1" name="mod1">

</listOfParameters>

</comp:modelDefinition>

<comp:modelDefinition id="mod2" name="mod2">

</listOfParameters>

</comp:modelDefinition>

</comp:listOfModelDefinitions>

</sbml>

In the above model, the parameter 'xmain' replaces x1 from submodel A, and is in turn replaced by x2 from submodel B. This means that in the final assessment, that parameter has a value of 2: the '1' and the '3' were both replaced. Note also that both x1 and xmain could have been set 'constant="false"', but the final assessment of the model would give that parameter a constant value of 'true', since that's what x2 had. (Just keep this in mind moving forward--if it's important that the final parameter have a value of '2' but 'constant=false', you'll need to create a new parameter at the top level with those attributes, and have it replace the others. Again, this is something a front end would ideally take care of.)

Is that clearer? Thanks for asking!

-Lucian

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
sbml-comp mailing list
sbml...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbml-comp

Daniel Palm

unread,

Jan 21, 2015, 2:10:00 PM1/21/15

to libsbml-d...@googlegroups.com

Thanks very much! That completes the puzzle for me for now. I'll try it out tomorrow.

--
You received this message because you are subscribed to a topic in the Google Groups "libsbml-development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libsbml-development/f68cZBHWIFk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libsbml-develop...@googlegroups.com.

To post to this group, send email to libsbml-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/libsbml-development/CAHLmBr1b%2BA0YDOg1bV3E4zYGrfZicrf%2BESNg8-BfyUQ6OUS6qw%40mail.gmail.com.

Reply all

Reply to author

Forward