Does anyone have any idea why two trains would go into a couple block, but there would be a 0 output? They have collided and both inputs have 1 train that go into the couple block, but no trains ever exit that block. I haven't come across this before, any help is appreciated.
Here is a picture of my flowchart logic while I run the simulation
Related
I am trying to simulate a manufacturing process in AnyLogic with the Discrete Event Simulation.
I am using the Queue block as a means to model a warehouse.
My question is: is it possible to set the initial length of the queue? For instance, I would like my process to have in "Warehouse 1" 100 pieces at the very right moment when the simulation starts.
Is it possible to do so?
Thank you
EDIT: The answer from Felipe solved my problem.
As suggested by Felipe hereabove the simplest solution is to add a second source that, at the beginning of the simulation, inputs the agents in the system.
I'm trying to use reinforcement learning to train an agent as a controller of a motor.
After reading this example, I only made some minor modifications:
Replace the watertank model with my motor's transfer function 69.4/(s+69.4), like this: .
Set the sample time Ts and simulation time Tf to 1/8000 and 10, respectively.
However, the result is:
It didn't do training at all :(
The reward is always zero.
Could anybody give me advices on how to deal with this problem?
Very thankful in advance.
You maybe should check the output values that your transfer-function generates.
In the watertank-example you have the "stop simulation"-block, which stops the simulation if your "height"-value exeeds 20 or is lower than 0.
This would explain that your step-per-episode count is 0, because no step was taken due to incompatible values.
I've run into the following error message from Simulink:
The block 'xyz/If Action Normal/In1' has a discrete sample time that does not match the sample time 0 of the If block 'abc' controlling its execution
My solver configuration is variable step/auto, and the environment could be seen at the end of this post.
I tried a few methods:
try to locate the error by replacing/comment out blocks;
try to change the port driving if-action block;
try to remove all discrete blocks;
Any suggestion is highly appreciated.
This error is hidden behind a Matlab known bug. Basically, when I tried to add a rate transition to make the same time consistent. The system crashed.
The crash is because of a known Matlab bug. A zero-holder needs to be added following unit delay blocks. After this, I could add rate transit block without model crashing.
Hi all I am a new SUMO user. I am having simulation iteratively with DUAROUTER and SUMO. The simulation consist of 20000 trips in Singapore network and it's very slow, took one hour and more to complete one simulation.
Anyone knows any way to speed up the process? I need to do 50 iterations. 1 hour per iteration is too slow.
My commands are as follows:
duarouter --net-file sg_left_v1.net.xml --trip-files trips20000_merged.trips.xml --output-file 0.20000.route.xml --ignore-errors true --no-warnings true --repair true
sumo -c simulation_sg_20000.sumocfg --tripinfo-output 0.20000.trip.output.xml --no-warnings true --tripinfo-output.write-unfinished true --vehroute-output 0.20000.individual.output.xml --link-output 0.20000.link-state.output.xml
The number X in X.20000.something.xml is increased on each iteration by my python code.
Thank you all in advance.
There are different things you can do to speed up the process by analyzing the bottlenecks. I would do the following:
Check whether the traffic flow is smooth. If there are big jams piling up the simulation slows down.
Do the vehicles depart at the times you expect them too. Even is there no visible jam, the backlog slows the simulation down. A good indicator is that vehicles which have an intended departure time near the end of the simulation, take much longer to depart (it's also in the tripinfo).
Recheck whether you need all outputs. To get a feeling whether it helps disable them one by one and have a look at the running time.
3a. Extend SUMO to aggregate your data. It is open source after all, so if the outputs are the bottleneck, aggregate inside the simulation.
Think about parallel execution. Maybe you do not need to start the iterations one after another?
Make the scenario smaller.
To accelerate the simulation, you will need to pass a parameter to Sumo called step-length
which a ratio of sumoTime / realWorldtime.
sumo your-other-args-here --step-length 1
It should enable you the get the wanted result
I am trying to run a real-time simulation in Simulink using Real-time Workshop. The target is grt(I have tried rtwin, but my simulation refuses to compile for it). I need the simulation to run in real-time so that one second in simulation lasts one second of real time. Grt ignores realtime and finishes the simulation in shortest time possible. Is there any way to synchronise it?
I have tried http://www.mathworks.com/matlabcentral/fileexchange/3175 but could not get it to work(does not compile).
Thank you for any suggestions.
Looks like it is impossible. I was able to slow down the execution by using Sleep(time in ms) function from WinApi and clock function from time.h, which looked quite good for low sample rates. However, when I increased the sample rate the Sleep function was sleeping for too long, which resulted in errors, with one second in simulation lasting more than one real world second.
The idea was to say that one period of iteration should last, let's say 200ms. Then time how long it takes for one iteration of code to execute using the clock function. Then call Sleep(200 - u), where u is the length of the iteration. The problem is that Sleep function sleeps the process and wakes it up when it wants to, not when you tell it to in the argument.
I know this is not a solution, but post this so that if anyone faces the same problem as me they won't try this dead-end solution. I had to rewrite the simulation for rtwin and now it works fine.
Another idea would be to somehow use interrupts, but I guess it would be quite complicated and not worth the trouble.