Any simulation speed differences between models loaded with SimBiology() vs sbioloadproject?

The question is in the title. I haven't seen much difference in numerical efficiency between the same model opened in sbioloadproject versus using simbiology('mymodel.sbproj). Is this your experience? Am I missing something?

Some background: [Note: I'm using v2019b to remain in sync with one of my clients, so this may have changed in new releases]. In response to earlier questions I've learned that sbioloadproject does not load the graphical layout of the model, and that sbiosaveproject doesn't save this positional notation. The upshot is that a model that is loaded with simbiology or with sbioloadproject and then saved using sbiosaveproject will lose all positional notation. A very carefully laid out model subjected to this load and save sequence goes from well-organized and understandable to ... a bowl of spaghetti (with Species being meatballs, I suppose). In my opinion, graphical layout is exceptionally important in discussing a model with non-modelers. As in "make or break" in terms of credibility. For this reason, I cannot envision any use for the sbiosaveproject command.

The workaround is to open the model interactively with Simbiology('mymodel.sbproj' for example), then run scripts, then save interactively using "Save as" from the SB dashboard. One other point that I've been coached on by the excellent technical support from Mathworks is that the simbiology() command to open a model is not useful "as is" in scripts now because it returns control of the program to the script before opening the model. So a script

mc = simbiology('mymodel.sbproj');
sbiosimulate(mc);

throws an error that the handle mc doens't point to a model. So the simbiology() and "Save As" commands must be interactive. If you want to preserve positional notation and add to or change the model with scripts you cannot run batch files exclusively.

The question above pertains to scripts that open the model and use it but just generate output data which can be saved in batch files as .mat files and such. That is, how much of a numerical penalty am I incurring opening the model in simbiology() vs sbioloadproject?

If there is little difference in speed of model execution, then some cool workarounds would be

simbiology('mymodel.sbproj','ExecuteBeforeReturn',true); % True would force simbiology to open the model before returning control to a script.
                                                                                             % default is false. This would allow simbiology in scripts

or

sbioloadproject('mymodel.sbproj','LoadPositional', true);    % This would load the same positional stuff that simbiology() loads.

Default would be true to avoid inadvertently losing positional info. A false flag could be set if, for example, this would result in much faster execution.

One or the other of the above would allow a script to open a model without information loss. To complement this a change in sbiosaveproject would allow the use of models with meaningful graphical layouts to be modified in scripts and saved without information loss. So sbiosaveproject('mymodel.sbproj') should check to see if the positional stuff is loaded, and if so, should save it in the sbproj file.

If there is a significant loss of computational speed when simbiology() is used to load the model, then the workaround is just to use sbioloadproject, do the calculations, save the results, and then exit without saving.

If one is just using scripts to create models and the graphical layout is immaterial, then sbioloadproject and sbiosaveproject would seem to work "as is". But then one must figure out how to explain matlab script code to biologists and physicians and scientists who may be, to put it mildly, "math averse". :>D

As always, thanks!

Answer 1

[Arthur Goldsipe]

I don't expect you to see any noticeable performance impact when simulating a model from the command line, while the same model is open in the SimBiology app. When you modify a model from the command line, there is some overhead in communicating model changes to the model to the app. I can imagine some rare cases where that overhead could be noticeable.

So, until MathWorks gives you a better option (which is definitely on our radar), I suggest you do what you propose: Keep the model open in the app while working with it from the command line.

[Jim Bosley]

Thanks once again, Arthur. In my workflow, I typically craft the model interactively. If I have alternative hypotheses that require additional structure (compartments/species/reactions/rules/doses/variaints) I suppose I could put those in using add_____ commands, but the time to create the structure is very short - minutes or seconds - compared to running 25,000 (or more!) virtual patients through a simulated two-year oncology trial. Plus if I use add____ commands the model components show up in a psuedo-random pattern overlaying my "MTA map" model with a Rorschach test.

That said, I will be cognizant of the potential for a time lag between a CLI or script command that modifies the model object.

BTW, loading the model with simbiology() also allows one to see any changes made by the script. So given little numerical penalty in opening the model with simbiology(), there's some benefit