MATLAB Answers

0

Can I force Matlab to wait 'til it finishes one command to run another?

Asked by Jim Bosley on 19 Sep 2019
Latest activity Commented on by Walter Roberson
on 5 Oct 2019
I have a script that loads a SimBiology model using the simbiology() command. Then I try to get a handle for the model
simbiology('mymodel.sbproj'); % There are reasons why I use simbiology and not sbioloadproject
sbr = sbioroot;
mdls = sbr.models;
nmdls = numel(mdls);
mc = mdls(nmdls);
The problem is when I first try to get mdls. I get an empty array. Apparently, the model is still loading when the sbr=sbioroot and mdls = sbr.models commands run.
In windows command line files, you can use
START /WAIT myprogram.exe
to force myprogram.exe to finish running before going on the next line. Is there a similar artifice in Matab/Simbiology? Something like
finish('simbiology('mymodel.sbproj')' ;
% or
whilerunning
simbiology('mymodel.sbproj');
end
I keep thinking that there's an easy way that I've forgotten...
The above is a general case. Of course, if simbiology() were re-written to return the model handle, and when the handle was requested, would not allow the script to proceed until the model was loaded, it would be great. Logical, too, because generally when you're loading a model you want to do something with that model before proceeding.
mc = simbiology('mymodel.sbproj'); % This solves the specific problem!
% or
mc = simbiology('mymodel.sbproj','WaitToComplete'); % or this

  10 Comments

If you
simbiology('mymodel.sbproj');
then that would start to load the position information, but might not completely finish before it returns. Would the
sbioloadproject('mymodel.sbproj');
discard the position information ?
If so, then you will probably need to open a support request.
Walter,
I think that Pax and the team know about this - we've had several email discussions. On the other hand, they're putting a lot of cool stuff into new versions - this may not be high priority.
But there is a disconnect between the dashboard, and using the model loaded in memory by sbioloadproject. My workflow is
1) Create model structure graphically. Discuss with biologists and MDs (esp. client biologists and MDs). Requires good graphical model.
2) Develop. Open model via simbiology(). Run and fit using tasks (initially) and scripts.
One key element is the ability to plot state_subplots. This is a trellis plot of all states in a matrix. If you set sampling to once per day (or hour, or whatever, depending upon your model) this gives you an amazingly sensitive test for stability. Great for when your model has complexities or periodicities that preclude a steady-state solution.
Another key element in this workflow is live plots, allowing for plotting data from datasets. I can mod a parameter, kick off a liveplot, and what as the plot develops. If its a long simulation (simulating a 100 state model for a year), I can see trends develop early and can terminate the simulation and modify the model. With scripts I have to wait til the sim ends and the plotting script runs to see this.
Because I open the model with simbiology() when I save the positional stuff, and all datasets and tasks are stored as well.
3) Develop scripts for cases and virtual persons/patients (VPs). Inludes validation plots showing whole-body and subsystem agreement with data. Also key is to show that dynamics (time frame of up- and down-regulation) agree with data. Automate VP creation and vetting if you'd like (see Youngan Cheng et als. et al. QSP Toolbox Paper in the AAPS journal).
4) Develop scripts for use-cases (simulations that answer client questions or that predict stuff the client wants to know).
I'd love to be able to write scripts that exploit the dashboard live plots, or that could use (or load) datasets to the model. Or that could create simulation tasks in the model. Right now, can't do that with scripting. Scripting this would allow a validatable way to create sim tasks and data in the sbproj structure for use in the dashboard. But right now, I don't think you can do this.
Ok. Guillame, as much as I liked your proposed solution, it didn't work. The first instance of mdls = sbr.Models does not return an empy object [], it returns a 0x1 Model object structure. So the while/end loop terminates before the model has loaded.
I suspect that I may have an insoluable problem here. Because I think that while the script is running, the Simbiology desktop stops running. At least the simbiology('myproj.sbproj') comman doesn't complete. So if I run this the code below
pstate = pause('on'); % Capture pause state and turn pause on
sbr = sbioroot; % Get sbioroot handle
simbiology('mymodel.sbproj') % Tell SimBiology to open file
mdls = sbr.Models; % Get original model state (numel should == 0)
i = 0; % Safety counter
while numel(mdls)==0
pause(1); % Don't chew up CPU with a tight, do-nothing loop
sbr=sbioroot; % Doesn't work with this line, or without this line.
mdls = sbr.Models; % To force mdls to be current
i = i + 1;
nmdls=numel(mdls); % Get the number of models
disp(['Time is ' num2str(i) ' Number is: ' num2str(nmdls)]);
if i>120
break;
end
end
mdls = sbr.Models;
pause(pstate); % back to original state
clear pstate;
I get a output with the value of i increasing to 120, and the value of nmlds constant at 0. If I then see what it returned in mdls by typing mdls, I get:
mdls =
0×1 Model array with properties:
And the model doesn't complete loading til the script ends. So after the script ends if I wait a few seconds and let the model load, I can type mdls=sbr.models and get:
mdls=sbr.Models
SimBiology Model - REGN TG
Model Components:
Compartments: 7
Events: 0
Parameters: 300
Reactions: 84
Rules: 143
Species: 46
So its pretty clear that the model doesn't load until the script finishes.
I see no sensible reason for not letting the model load while the script runs. This seems like a bug to me.

Sign in to comment.

Tags

Products

1 Answer

Answer by Arthur Goldsipe on 19 Sep 2019
 Accepted Answer

Hi Jim,
The previous responses are correct: The simbiology command returns before the desktop completely loads the project, because the desktop is operating on different threads. So, welcome to the world of multi-threaded / parallel / asynchronous / <insert buzzword> complexity! Believe me, it makes life harder for SimBiology's developers, too. But hopefully you're mostly seeing the benefits of us living in that complexity and hiding it from you as much as possible.
Right now, there's one-line command that does what you want, but I'll suggest a workaround below. But thinking longer term, we hope to eliminate the need to open a project in the desktop just to preserve the diagram. If you can think of other reasons why it's important to know when a project is fully loaded, let us know so we can address those workflows, too.
Anyway, if all you care about is whether the model is accessible from the MATLAB command prompt (and not whether the desktop has completely finished loading the project), I came up with a solution (pasted below) that uses timer objects to periodically check whether the models have been loaded.
Here's the function. It takes the name of a project, the name of a variable to assign models to in the base workspace, and an optional callback that you can use to execute tasks that take the models as input arguments. So here's an example usage that simulates the Lotka demo project as soon as it's loaded (assigning the result to the base workspace variable sd): simbiologyNotify('lotka.sbproj', 'models', @(m) assignin('base', 'sd', sbiosimulate(m)))
function simbiologyNotify(projectName, varName, callback)
if ~exist('callback', 'var')
callback = @(models) [];
end
root = sbioroot;
oldModels = root.Models;
t = timer('ExecutionMode', 'fixedSpacing');
t.TimerFcn = @(t,e) timerFcn(t, root, oldModels, varName, callback);
simbiology(projectName);
start(t);
end
function timerFcn(t, root, oldModels, varName, callback)
models = setdiff(root.Models, oldModels);
if isempty(models)
return
end
beep
fprintf('Models have been loaded. Assigning to base workspace variable "%s".\n', varName);
assignin('base', varName, models);
stop(t);
delete(t);
callback(models);
end
Note that you can't directly call this function from a script or function. If you do, you'll block the MATLAB interpreter, and that will prevent the desktop from loading the project. So you have to start thinking about asynchronous tasks the way we developers do: as a series of callback functions that get called as soon as their preconditions are met.
And one last note: If you really need to know whether the desktop has fully loaded the project into the GUI, I'll see if there's a way to get that information.
-Arthur

  4 Comments

Show 1 older comment
Hi Jim,
In case it helps you understand my example better, here's how you could adapt your "other_stuff" sample code to work with my function:
simbiologyNotify('mymodel.sbproj', 'model', @(model) other_stuff);
So the basic idea is that you put everything that needs to run after the model loads into another function, and that function is only called after the model loads. That avoids the problem you describe (which also occurs if you try to use "pause" to wait).
Arthur,
Great stuff!
I recall having to something similar on a DEC VAXStation when in grad school. I was optimizing a batch distillation process (my PhD involved running a moonshine still) and had a commercial distillation simulator. I wrote an optimization routie using sequential quadratic programming. The metric function created an input file for the batch simulator, started the simulation, and waited for "semaphore" (a flag variable) to indicate simulation was complete. Then the program read the simulator output file and computed a metric which it passed back up to the simulator. Worked pretty well, IIRC.
I also recall having my DEC tape backup (TDK50) jam in mid-restore. The tape had my entire suite of research on it and I was restoring because other tapes had failed. I had to disassemble the tape unit, disassemble the tape cartridge, free up the jab and manually rewind the tape. It was terrifying, but ultimately successful. Good times. Sheesh.
Thx again, Jim
When I sysadmin'd, I was a believer in The Rule Of Three for backups.
The first tape will be scanned by the automatic tape library, noticed that it has "expired", and promptly have its label overwritten because the backups have been sitting waiting for a writable tape to continue writing with.
You then cancel the backups and reconfirm that nothing is waiting to write on the tape drives. Put in the second backup tape, type in appropriate commands... and swear because you accidentally used a tape backup command instead of a tape restore command, so you just scribbled on the tape you were about to restore from.
You unmount that, and this time before putting in the third backup, you make #$@ sure that you enable the write-protect, and proceed to try to restore. Not everything will restore properly. You will start to whimper.
At this point you dig around and dig around, and after panicing a while, find that a three-year old backup got made and overlooked, and you retrieve the rest of the backup from that 4th tape.
Why call it the Rule Of Three? Because next time you remember the write-protect feature on the second tape, and so manage to get through it all in only three tapes.

Sign in to comment.