I am really new on Modelica in general but I have a project I need to finish really soon. I apologize if something that I say is really basic. I have tried a few tweaks and searched over the internet but I cannot seem to figure out how to do this to work.
I have created a model. Inside there is a block with a boolean output, lets call this output boolean variable Y1.
Connected to that block I use the Modelica.Blocks.Logical.Change or the Modelica.Blocks.MathBoolean.ChangingEdge blocks. I have tried both since if I understand correctly they do the same thing. Y1 is the input of this block.
So basically the moment when Y1 changes from true to false or from false to true the output of the Change block (lets call it Y2) should be true just for that timestep.
This does not happen. Y2 is constantly on false. I have checked and Y1 is changing over time.
I have also tried to run the example Modelica.Blocks.Examples.BooleanNetwork1 but I see the same thing in there also. The desired output does not change to the example either.
For reference I use the OpenModelica 1.17 with Modelica Standard Library 3.2.3. These are the versions I am obligated to use and I cannot use newer or older ones.
Any tip would be highly appreciated! Thank you.
PS If this does not work I would like to use something different. Is there a way I can access all the previous values (history) of Y1 inside an another block and find these changes with an algorithm there? So lets say I am on timestep N and inside a block I want to access Y1 from 0 to N-1 and find the last timestep that Y1 has changed.
How did you check that the output of the change block doesn't fire at the events? You may not be able to see it on a plot since the impulse is 'infinitely' short (at least, that's my experience with Dymola).
You could latch the impulse from the change block by connecting it's output to an SR flipflop.
Related
bayesopt draws figures like this:
How to access such figures in order to modify title or something? If I use gcf it is not guaranteed I get the correct figure because I could change focus to another figure window during execution.
Apparently bayesopt does not allow you to return a figure handle. So I suggest that on the line directly after your call to bayesopt you call h=gcf;, thus forcing your program to return the figure handle to h, which can then be modified at any desired time, even when moving to other figures.
results = bayesopt(fun,vars,Name,Value); % execute bayesian optimisation
h = gcf; % directly after optimisation grab a figure handle
Now you can modify properties in h, e.g. for the title you'd simply do
h.CurrentAxes.Title.String = 'Your plot title'
The reason this works is that MATLAB does not display figures until the full code has finished running. At least that's the case for my script, where I generate a figure, perform a few minutes of optimisation, then generate another figure. Both figures get displayed at the same time, i.e. when MATLAB has finished running the full program. There's thus no way you can click other figures when the code is running, since they are simply not there. If you happen to have older figures open (from other scripts), focus gets shifted to the latest created figure anyway, the moment it's created in the code (so not when it's displayed), thus you'd need to click a figure in the few milliseconds between the bayesopt call finished and the gcf call, which I'd say is so improbable that it's not worth considering, especially since it requires manual intervention.
As was pointed out in comments by Cris Luengo and Dev-iL, the figures are tagged and can thus be found using findobj:
h1 = findobj(0,'tag','bayesopt.MinObjective')
I have created the following block diagram on Matlab Simulink. It should give OUT1=1 OUT2=0 when INPUT>=0 and OUT1=0 OUT2=1 when INPUT<0. But it does not give the expected results. What is the reason for that. Any advice to make it work correctly would be appreciated.
The behaviour you are seeing can be explained by noting the following:
The output from the If Subsystem acts like an enable signal.
By default, the Output Ports of an If Action Subsystem are set to hold their values when the (sub)system is disabled.
This can be changed by going to the parameters dialog of the Output Port (within the If Action Subsystems) and changing the Output when disabled property to reset. You'll also want to change the default value to zero.
In many cases an IF is translated to a switch. You calculate cases and select the one which is intended. Here you could connect a constant [1 0] and a constant [0 1] to the first and third input and the sign block from your solution to the second input.
This if function block thing didn't work. So I come up with a different approach to get the result I wanted using the sign block. Solution is posted below. Thank you for everyone for trying to help.
I am working on some scripts for which I use several functions from the EEGLAB package for matlab. Most of these functions make it possible to surpress the GUI from showing, for example using f( ... 'gui','off'), or by using a different version of the same function. However, I can not figure out how to do this for the function pop_eegfiltnew(). Two similar functions are eegfilt(), which seems to be an outdated version of the function, and firfilt() however, pop_eegfiltnew() has more arguments than these other two, so they are certainly not the same in functional terms.
Anyone knows how to get around this?
If you supply enough arguments to pop_eegfiltnew it does not pop up a GUI.
For example if you wanted to filter your signal 1 Hz highpass you would:
EEG = pop_eegfiltnew(EEG, 1, 0);
This is because the first argument of pop_eegfilt is EEG structure, the second is locutoff (lower edge of the passband) and the third is hicutoff (higher edge of the passband).
Say I have a function foo that can return three values given an input:
function [a,b,c] = foo(input)
The calculations of variables b and c take a long time, so sometimes I may wish to ignore their calculation within foo. If I want to ignore both calculations, I simply call the function like this:
output1 = foo(input);
and then include nargout within foo:
if nargout == 1
% Code to calculate "a" only
else
% Code to calculate other variables
The problem occurs if I want to calculate the last output, but not the second. In that case my function call would be:
[output1,~,output3] = foo(input);
Now if I use nargout within foo to check how many outputs are in the function-call, it will always return 3 because the tilde operator (~) is considered a valid output. Therefore, I cannot use nargout to determine whether or not to calculate the second output, b, within foo.
Is there any other way to do this? I.e., is it possible to check which outputs of a function-call are discarded from within the function itself?
The commenters are basically right; this is not something that can be totally solved by the user unless The MathWorks adds functionality. However, I wrote a small function, istilde (Wayback Machine Archive), a while back that attempts to do what you ask. It works in many cases, but it's really a bit of hack and not a totally robust solution. For example, I did not attempt to get it to work for functions called from the Command Window directly (this could potentially be added with some work). Also, it relies on parsing the actual M-file, which can have issues. See the included demo file for how one might use istilde.
Feel free to edit my code for your needs – just don't use this in any production code due to the robustness issues. Any improvements would be welcome.
Suppose in matlab the following:
[t, x, te, xe, ie] = ode15s(#myfunc, [tStart tFinal], x0, odeset('Events', #events));
Question 1
1a) The function events is called only after a successful step of the solver. Is this true?
1b) Just after the solver has made a successful step, is it possible that the last call of myfunc not be the call that lead to the successful step?
1c) If the events function contains multiple terminal events and upon a successful step it is detected that two of them (not just one) have occured, what would be the behavior of the solver?
Question 2
Suppose that myfunc contains the following code
if (check(x) > 2)
dx(3) = x(1)*x(2);
else
dx(3) = x(2)^2;
end
where check is some function of x.
One way to solve this problem is not use an events function. In my experience the ode solver can solve such problems that way.
The other way to solve this problem is use an events function to locate check(x) - 2 == 0, one terminal event for direction = 1 and another one for direction = -1. After the solver stops on either of the events a global variable eg myvar is set appropriately to distinguish between the two events, and then the simulation continues from where it stopped. In that case the code in myfunc will be
if (myvar == 1)
dx(3) = x(1)*x(2);
else
dx(3) = x(2)^2;
end
Both way yield correct results in simple cases. However I am trying to solve a very complex problem (additional events than the above and discontinous right-hand parts of the differential equations that are proven to be solvable at some cases) and I am trying to find out if the first way would yield different results than the second one.
One might tell that the ode would either fail to return a solution before tFinal or return a correct solution, but due to the discontinuity of the right-hand part the solver might not return a solution while a solution exists.
So in some sense, the question is: what is the practical-theoretical difference between using the first way and the second way?
Since I've spent some effort on these questions, I'm posting back some feedback.
Question 1
1a) Yes this is true. For reference see for example the ode15s.m matlab solver. However note that before the solver continues solving, the events function may be called several times for the sake of a more accurate te value.
1b) Yes this is also true.
1c) In this case the solver would terminate returning an ie vector containing the two (or even more) indexes of the events that stopped the solver. In that case, the te vector would contain equal elements (te(1) == te(2) will always return true). This is the only way to distiguish "double events" (meaning events that simultaneously stopped the solver after the same successful step) from "fake" events that are recorded when the ode solver continues solving after a terminal event (to understand better what I'm saying also read ode solver event location index in MATLAB ).
Tracing the odezero function will make 1c answer very clear.
Question 2
Now this is a tricky answer. **In general* both ways return correct results. However (and most naturally) they are not bound to return the exact solution points at the exact time points with the exact number of steps.
The notable difference between the two ways is that in the second one, we have a branch change only when a check(x)-2 sign change occurs using only the currently active branch. For example, suppose that the currently active branch is the first one. When the solver notices a sign change in check(x) - 2 after a successful step that was produced using only that branch, only then changes to the second branch. In simple words, both successful and unsuccessful steps are calculated using the very same branch before a use of the other branch can occur. However if we use the first way we may notice a use of the non-active branch during (for example) an unsucessful step.
With these in mind comes the verdict; the most general and strictly correct way to choose is the second one (using events). The first way should also return correct results. HOWEVER, due to the difference between the two ways, the first one could fail in very specific/extreme problems. I'm very tempted to provide information about my case, in which ONLY the second way could be safely used, but it truly is a long way to go.