simulation time in hours

Hi Please i need help on how to simulate a model that runs for 120 hours simulation time. I need the x-axis label to be in hours. The most important thing is that the behaviour i want to capture from the model can only be revealed after about 100 hours. I have read several similar contributions but did not answer my query. I know the simulation time in simulink is in seconds unit. If i multiply 120 by 3600 to get seconds, it seems too large. I tried to run it on my system and i could not complete it due to the duration of the simulation. Also, my computer froze when i tried it. Please I want something similar to the x-axis of the attached file.

Thank you.

[dpb]

I don't have and haven't seen Simulink so all I know is what I have read. But--

Simulink time really is unitless -- the timestep is nominal seconds, but if your model is set up where frequency-related quantities are in hours, then you can use hours instead of seconds.

The time required for a simulation to run is dependent upon the complexity of the model and the timestep of the solver. A slow model such as this would appear to be should be able to have a quite long (relatively) timestep as compared to a very quickly-responding system.

Of course, if coded in frequency units of minutes or hours instead of seconds, you've changed by a factor of 60 or 3600 so the absolute magnitude of the timestep may be the same or shorter--it's all relative.

I really "know nuthink!" about the user interface to Simulink, but I'd be certain you can change the horizontal time axis of a graph to whatever time units you wish it to be -- that is, plot in days even if the simulation is running in seconds. At worst, you would plot with a scaled time variable of model time/(24*3600) but surely that wouldn't be necessary.

[KaMATLAB]

Great!! Thank you for the insight. I am curious about it. Actually, my model has quantities that are in seconds or per seconds. Now the there is a particular dynamics that i want to observe. The dynamics in reality takes place after about 40 hours in real life. I am just wondering if it is necessary to consider that in my simulation such that i can make simulink to run the 40 hours simulation time since it is pereicved to be in seconds unit. Just want the clarification because i am writing a manuscript to be published. I have seen in publications like the attached where it is in hours. I want to be sure of what they did! thank you so much

I have attached a file

Thank you so much

[dpb]

If your model dynamics units are in seconds, then you'll need to set the simulation start/stop times in seconds to match--as far as I know that's what makes the connection. One would think MathWorks would have provided a convenience of specifying units optionally to avoid having to enter big values manually, but I don't have Simulink to know.

I presume one can enter a calculated value so instead of the long integer of 14400 for 40 hrs one could enter =40*3600 as a convenience. But, I don't know, I'm guessing.

[KaMATLAB]

Yeah I have tried that but...... I did not even get to 17000s out of 432000 before my system froze barely 2%. Thank you. I really appreciate your insight and time

[dpb]

Well, that's likely owing to the modeling trying to do too much -- as noted, I "know nuthink!" really of Simulink so don't know what you can do about the timestep control in the solver(s).

I see it is reactor dynamics, being an old NE meself, I could see potential there for models to have difficulties in solving the long-term problem owing to the dynamics of the reactor system being modeled finely so that short timesteps are needed to represent the dynamics even though that's not the overall intent of the model.

How have/are you modeling the reactor dynamics here?

Answer 1

[KaMATLAB]

Wow! I am really excited that you an NE urself. I used space-time kinetics to model the reactor. I am trying to suppress xenon oscilation using an adaptive second order sliding mode control. As you know that xenon dynamics occur or beocomes prominent after some hours in a reactor, i am wondering if i just used the seconds unit in simulink, if it oculd be captured. I have been able to control global power. I got a laod following that is power tracking the reference power. However, i need the xenon oscillation plots to show the oscillation. I am not sure if reviwer would not want to ask such questions?

[dpb]

How many spatial nodes do you have?

<GEEZER ALERT> Irrelevent to the problem at hand, before startup reactor physics testing of the Oconee I reactor, the first B&W 177FA to go online I did a 3D PDQ/HARMONY simulation of Xe oscillation which was then replicated as part of physics testing. In those days it took about 45 minutes for initial timestep of our 3D coarse mesh model and about 20-30 for successive timesteps if the perturbation weren't too great on the CDC CYBER 76. For long studies such as this only got runtime priority at night after all the other day's production runs were complete--it took a month of calendar time to get two complete cycles!

My favorite Xe-related story (not provably true!) is a TVA reactor was forced to trip late in core life owing to a switchyard fault and they were unable to successfully accomplish the runback of full-load rejection at 100% power. Unfortunately, was several hours before the fault was cleared by which time Xe had built up to point being near EOL didn't have enough excess reactivity to restart. Is said that Central Dispatch called up and wanted to know why weren't back online yet and were told "We're waiting on xenon." Response was "OK, but have him call as soon as he gets back!" <ENDGEEZERMODE>

[KaMATLAB]

Then it means i am chatting with Enrico Fermi!!! I am using 4 nodes!!! I am happy! I guess I can send you a mail Please my email is [e-mail] I believe I have a lot to learn from you

[dpb]

Hmmm...I wouldn't think only four nodes should be that bad computationally, then. What kind of a time step does Simulink think it needs?

[KaMATLAB]

Exactly what I am seeking clarifications for! The time step I need to be able to capture the dynamics. I appreciate how you are taking it on easy step at a time. I am awake despite already very late in Eastern Europe hoping and waiting eagerly for your replies! Thank you for this! Please I really love to be in touch beyond this place! Nonetheless, how do I solve the present problem? Then how can I further advacne to have more nodes without computational cost? Lol! One step at a time though

[dpb]

I'm afraid I can't help much more with Simulink specifics...I was asking what kind of time step does your simulation show when it is running? I presume you get some indication of time as it runs somewhere, but I have no knowledge whatsoever of the user interface, sorry.

[KaMATLAB]

Sorry I slept off. Just woke up. While the simulink runs, averagely it seems the time jump is 2 seconds. However, the timestep from the simulation parameter tab of simulink I have not checked. I feel it will be very small which account for a very long duration and freezing of my computer

Answer 2

[Jonas]

I am not particularly certain how your model behaves dynamically, and if it is made in the discrete time space or continuous time space, but you should investigate and try out the Solver settings.

If you have a model where you want high accuracy for moments where the model state changes quickly, but want low accuracy on times where little is happening in your model and you want to progress more quickly, you should use a Variable Step Solver. Try out various error tolerance settings

If your model contains parameters with a unit in seconds, you can leave the model simulating in seconds. If you want the model to simulate quicker you should increase the discrete step time, this is mostly related to having a Fixed Step Solver.

Choosing a solver in Simulink is actually a very important aspect so it may be good to learn about it regardless.

If your model is highly dynamic but you still want to simulate long simulation times, the only solution is to upscale your processing power.

[KaMATLAB]

Thank @Jonas for th explanation! I have explored it. In fact I am using continous variable solver in automatic mode so that simulink can actualy select the most suitable solver for my model. My model has continous states. Thanks

[dpb]

That's likely going to be an issue arising from the neutronics section of the model -- that even though the overall transient you're interested in is slow-moving based on iodine halflife, the neutron absorption in the Xe is a rapid-rate event on its time scale.

The discrete neutron diffusion solution from something like PDQ/HARMONY I alluded to earlier is a steady-state neutron distribution solution for the given geometry including poison distribution like both fission products and movable poisons (control rods). Consequently, it isn't time-step dependent but only solves for the local flux continuity/boundary conditions.

That flux distribution is then considered constant and isotope depletion/creation is calculated for a given timestep based on simple rate equation for the constant flux. The 3D simulation I spoke of earlier used 30-min timesteps if I recall correctly (that's been 40+ year ago now! memories fade) although may have been as much as an hour once removed from the initial perturbation of inserting, holding, and then withdrawing the assymetric control rod pattern (the phyics test used a group of control rods in one upper quadrant to generate both a radial and axial asymmetry in the resulting Xe oscillation).

You may want to reconsider how you're modeling the system to instead do something similar rather than trying to actually solve the neutron dynamics directly.

[KaMATLAB]

@dpb Hmm quite a long time! It is great that you still remembered all these. Thank you for the ride. I enjoyed it. Hope to be in touch with you

[dpb]

I'll go to my grave remembering certain things from back then -- like the 177FA core water volume fraction was 0.580207 while fuel (UO2) was 0.303301 and fuel assembly pitch is 8.587". Even to the point the H number density for the homogenized model was 0.239276-1 atoms/barn-cm at 580F, 2250psia.

I couldn't reconstruct from memory (that was a never could have, given a full model input deck consisted of some 4,500 cards with probably an average of 6-10 values/card). My time began in the days before we even had disk drives or even drum; instead the Philco 2000 had 27(!) 7-track tape drives. The CDC did have disk but we engineers weren't allowed access to them for storage of anything as ordinary as input decks so we had to keep the card decks manually. Eventually, management became at least somewhat enlightened and before I left Babcock & Wilcox we actually did have access to dumb terminals that did at least allow us to save the base input deck on disk.

The code input section was very clever and well written -- cases were run by stacking changes to the base deck only; subsequent card sequence numbers replaced earlier ones of the same sequence so one only had to stack the timestep data and whatever changes occurred at a given time step such as positioning which regions had control rods inserted for that time step, for example.

[KaMATLAB]

This is interesting!!! Considering another modeling method! For now with my little knowledge, I know of space time kinetics which is suited for computational cost management unlike neutron transport or diffusion equation that are costly computationally. Hence may complicate my challenge.

[dpb]

Conversely, the space-time kinetics are apparently an issue in the Simulink formulation in needing very short time steps to successfully integrate in time owing to the stiffness of the equations in time. Yet, you have very little interest in those immediate changes introduced by some change in, say, rod positions for the bulk of the simulation but only in what is the resulting (near) steady-state solution with the resulting I decay resulting in the Xe concentration some hours later.

Hence, it may make sense to separate the two; that's what essentially the diffusion-depletion model route does...and once it has an initial solution for the perturbed flux, then the change with time after the perturbation is removed is small and so the timesteps can be larger.

Now, if your control model is moving rods continuously in sizable steps in an effort to coerce Xe buildup to be redistributed, then it may simply be necessary to have a more detailed model than it seems would need when just consider the end result plots looking like yours do...they don't show much going on, but like the duck in the pond, there's a lot of paddling going on under the surface you can't see from shore.

[KaMATLAB]

Yeah more variables to be show not than the global power shown in the attached file. I want to plot Xenon profile in each node after several hours to indicate that it is actually suppressed. I will show total reactivity in each node is around zero to show criticality. I will indicate other variables but after several hours. Hence the attched file indicates little of what my simulation is about

[dpb]

"I want to plot Xenon profile in each node after several hours to indicate that it is actually suppressed. ..."

Pay particular attention to axial flux redistribution -- I don't know your reactor design or operating limits, but one has to be VERY careful with large PWRs with the part-length axial-power-shaping control rods (APSRs) to ensure don't ever let the core flux peak get ahead of their leading position--either top or bottom. If that were to happen, then moving them in the direction of the peak in an attempt to suppres it will, instead, "push it ahead of them" as they advance with the resultant risk of exceeding allowable operational power-peaking limits and thus DNBR or centerline fuel-melt peaking limits.

Needless to say, such a situation isn't desireable.

[KaMATLAB]

Exactly what I am doing. I am concerned about axial power oscillating to be within design to avoid hogh power peaking factor since both radial and azimuthal are flat or converge except in case of spurious expulsion of control rod which can excite azimuthal osciallation.