how to re-assign parameter value assigned in an active variant in SimBiology?

Hi, I cannot re-assign a value to a parameter, kdeg, defined in the active variant, variant1.

The following code shows the steps I performed (sbproj file attached)

% model
projectVersion = "variantTest.sbproj";
s = sbioloadproject(projectVersion);
modelObj = s.m1; % MAIN

% kdeg = 1 value is shown while the active variant value is 0.3:
componentObj = sbioselect(modelObj,'Name','kdeg','Type','parameter')

% an re-assignment is futile although it shows in 'modelObj.Parameters' below
if numel(componentObj) ~= 1
    disp('error');
else
    set(componentObj,'Value',3)
end
modelObj.Parameters
% 'kdeg' is listed showing new value, 3, but the active variant 
% value is stil 0.3 as the plot shows

% deactivating does not work:
% % variantObj.Active = false
% % modelObj.Parameters

simDataObj = sbiosimulate(modelObj);
simDataObj = selectbyname(simDataObj,'Species1');
sbioplot(simDataObj); grid on;

The question is how to re-assign, overwrite the variant value, and 'activate' a new value of 'kdeg'?

I have tried to inactivate the variant but that without success.

Any hints would be very appreciated! M

Answer 1

[Arthur Goldsipe]

sbiosimulate(modelObj) will simulate using only active variants. If you set all your variants to inactive, then you should simulate the model with the appropriate parameter value of 3. It it possible you're setting Active to false on the wrong variant?

Alternatively, you can ignore the active property and explicitly specify the variants and/or doses you want to simulate with as follows:

sbiosimulate(modelObj, []); % default configset; active variants, active doses
sbiosimulate(modelObj, [],[]) % default configset; no variants; active doses
sbiosimulate(modelObj, [],[],[]) % default configset; no variants; no doses

I added the following lines to the end of your script and confirmed things work as expected (namely that kdeg is 3 during the simulation):

allVariants = getvariant(modelObj);
set(allVariants, 'Active', false);
cs = getconfigset(modelObj, 'active');
% Explicitly log kdeg during simulations
cs.RuntimeOptions.StatesToLog(end+1) = componentObj;
simDataObj2 = sbiosimulate(modelObj)
simDataObj2b = selectbyname(simDataObj2,'kdeg');
simDataObj2b.Data

[Frank Gibbons]

Wow! I just had the exact same question, almost at the same time! I've been away from SimBio for a long time, just getting re-acquainted with features such as variants, and I have to say this is not the behavior I was expecting!

I had imagined that I could use different variants as different "baselines" from which I could then jump off by modifying parameters after "commit"ing the variant. But it seems that attempts to change parameter values appear to silently fail - you do sbioselect(), you change the Value, it doesn't complain, but then in the simulation, it also doesn't reflect the change you just made!

Just to give a specific use case: imagine a PBPK model, where you've got different tissue flow rates and volumes across species, e.g., you might want to keep mouse, non-human primate, and human as separate variants (at least I did!). But then you might want to change certain aspects of the model from there: if you're modeling therapeutic proteins, you could tweak permeability/reflection coefficients, tissue catabolism rates, perhaps internalization/recycling parameters (e.g., for mAb TMDD).

I have a follow-on question: if your variant specifies only a few parameters, can you still tweak those that are defaulting to the model value? (I was being a goody-two-shoes and specifying everything for each variant, thinking that way I could switch back completely if I wanted to. Maybe that's not the way.) That would be useful: I could set up just the PBPK Q's and V's for (species) variants, but leave other (potentially changeable) properties to default to the model. If I could then rely on sbioselect() to change those, it would be a reasonable way forward.

The docs are pretty sparse in terms of behaviors of variants. That wild-type/mutant example is fine, but it's minimal: it would be great to see a bit more detail on how they can be used in "real life". At the very least, a warning from commit() (or sbiosimulate()) that further changes to parameter values will be silently ignored in simulation could save people like me a few hours of hair-pulling!

[Frank Gibbons]

Follow-on question: what is best practice to do the kind of baseline-switching I described above (i.e., I want to change species, and have all the fixed physiological parameters overwritten)?

[emjey]

Right now the way I work with variants is to put things in there which will not be varied, but that's quite limitting and it is not what you are after. Alternatively, you define parameters/species of baseline models in CSV files and load them into a variant-free model (to avoid any confusion) every time you need to work with one of them.

Personally, I find the way described above by Arthur is not practical or even misleading - you get the re-assignment of kdeg to 3 done but loose all other variant1 settings (if I see it correct - tested after extending the variant1 definition, updated sbproj attached)!!

Also ignorring variants/dosing seems easy, but I do define variants not to dectivate them but because I want to work with those specific settings, as decribed by Frank.

In my opinion, to make the variants useful, would be the following. Once you activate a variant, its parameters, initial conditions and all other settings which it describes, become 'the' model object you can manipulate with 'sbioselect', re-assign etc. Is there a way to achieve that?

[Arthur Goldsipe]

Hi emjey and Frank,

First, sorry for the delayed reply. I've been absolutely slammed with deadlines, and this completely fell off my radar. If either of you are going to be at ACoP and want to discuss in person, let me know. :-)

I'm not 100% sure I follow what both of you are saying. But something doesn't sound right. Maybe it will help if I describe what we intend variants to be used for and then describe how they can be used to accomplish this.

First, variants are intended to store alternate sets of initial conditions. You can use variants to vary the initial conditions for simulations without the need to modify the components in your model. So I think it might help to explain the steps that SimBiology takes to determine the initial conditions during a simulation:

1. Copy over the Value property of each QuantityComponent (Species, Parameter, and Compartment) in the model. We sometimes call these the "baseline" values.
2. Update these values with any information specified in variants used during the simulation. (More on those details later.)
3. Finally, evaluate all initial assignment rules and repeated assignment rules.
4. Log these as the simulation results at time=0 (unless you've specified OutputTimes that don't include 0).
5. If any doses occur at time=0, apply them and log the results after doses.

After following these steps, we have the initial conditions that we are used with the ODE solver.

Here are more details on the variant step.

• The variants used during a simulation can be specified either explicitly or implicitly. You explicitly specify variants by passing them in to sbiosimulate. You implicity specify variants by omitting the relevant argument from sbiosimulate, and SimBiology will select any variants on the model that have their Active property set to true.
• Variants are applied one by one in order. So if multiple variants modify the same component, only one of them wins. At the command line, the variants are applied first to last, so the last one "wins." In the app, variants are applied right to left, to the left one is apply last and "wins."

You can also use the commit method to copy the values in a variant onto the components in a model. This can be useful if you decide that you want to update your "baseline" conditions. That's what I'd suggest to emjey if you want to see these new values on the components themselves when using sbioselect.

[emjey]

Thanks Artur for clarifying, 'commit' was indeed what I was after!

Btw, unfortunately, I will not attend ACoP.