I am very new to Modelica and mainly have one big problem:
If I use comparisons like e.g. greater as threshold, I don't get the simulation to finish from time to time. The thing is, this doesn't happen always. But if it does, I get the following error message:
"Fix point iteration did not converge at time : xxx"
I already fixed this problem from once with using a hysteresis instead of the "hard" comparison. Do I really have to do this in every case I'll need it? Or does somebody have another idea or solution?
Thanks in advance!
You could encapsulate the hysteresis comparison inside a function and use that everywhere.
Related
I'm using Optaplanner to automatically solve school timetables. After a timetable has been solved the user will manually change some lessons and will get feedback on how this affects the score via the following call:
scoreManager.updateScore(timetable);
This call takes some 200ms and will, I assume, do a complete evaluation. Im trying to optimize this and want to only pass in a Move object so that Optaplanner only has to recalculate the delta, like:
scoreManager.updateScore(previousTimetable,changeMove);
Is there a way to do this?
There really is no way how to do just a single move. You don't do moves - the solver does moves. You can only make external problem changes to the solution. You should look into the ProblemChange interface and its use in the SolverManager.
However, the problem change will likely reset the entire working solution anyway. And after the external change is done, you're not guaranteed that the solution will still make sense. (What if it breaks hard constraints now?) You simply need to expect and account for the fact that, after users submit their changes, the solver will need to run; possibly even for a prolonged period of time.
I’m using Optaplanner to make a schedule and it works quite good.
After reading the documentation I have realised that I should use at least 1 (or more) shadow variables since my drool-file is calling methods that does a lot of calculations based on the value of the planningVariable.
I spent a couple of hours rewriting my code to have a shadow variable, but then I notice that the initial solution was really bad (compared to not having shadow variables) and I had to wait severals of minutes just to get an OK result. Is this normal? It did not look like the initial solution used the shadow variable at all.
The question is very generic, and so my answer will be, too.
Sometimes you can simplify the problem by introducing shadow variables or other forms of caching. If you find the right balance, you can indeed speed up the Drools calculation and - as a result - get to the same solution in a shorter amount of time. And therefore, reach better solutions in the same amount of time.
That said, introducing shadow variables shouldn't really change your scores - only how quickly they're calculated. If you're seeing different scores for the same #PlanningSolution, you have in fact changed your problem and the relative performance is no longer comparable.
Also, you may want to check out environment modes to make sure you haven't inadvertently introduced score corruptions into your problem.
If within a for loop (running say n times ),i make a call to a library function,which i know in the back end runs another loop,does it affect my overall complexity ? Or does it remain O(n) ?
It does affect your overall complexity. Imagine you were to make a call to the function you're writing from within another loop - you can't ignore a function's inherent runtime because it looks like a single statement.
Now, exactly HOW it affects your complexity depends on what you're doing with it, and what it does, but you certainly can't ignore it.
Is there a way to get the current value of a given signal? Or, is this something that I shouldn't want to do when writing idiomatic Elm?
Normal code
You shouldn't want to do that when writing idiomatic Elm.
It's also not possible to get the current value of a signal. This would be a side-effecting function (returning different values at different times in the program execution), which would allow all kinds of nasty bugs to crop up. To do something with the value on a signal, you can map over the signal with Signal.map but I suspect you already know that one.
Testing
If you're asking about this for testing purposes rather than normal code, you can hack around the limitation using the technique that's used in package Apanatshka/elm-signal-extra to write tests for signal-related functions. (Note that although I'm the author of that package, kudos for the testing system should go to rgremple for conceiving of and contributing it)
The way I understand it, the concept of "current value" has no meaning in Elm.
Sure, if you Signal.map a function over a signal, you can say that that function will always receive the "current value" but I don't think that this is what you meant.
The idea of "current value" involves time. It involves the idea of having a "before I ask for the current value" and an "after I ask for the current value". This is something that you might find in an imperative language but Elm is declarative and as such, the concept of before and after have no meaning.
When timing certain processes, is it possible for either "user" or "system" time to be absolutely zero?
That is, the program does not spend time at all either outside or inside the kernel. Does such program exist?
No, there is no way for a program to take Zero Time. Even a one bit change takes a full clock cycle.
I suggest reading Code by Petzold