From: Mike Kost <mike@ta...>  20060731 21:02:46
Attachments:
Message as HTML

Hi there, I've been simulating models of analog PWM modulators. I've noticed that if I do not have a sufficient number of points per ms of simulation time, the results will start to diverge (wildly) from the expected result. As I add simulation points, it converges on the expected result. This is not unreasonable since PWM systems have very large transients (depending on how the simulator handles such transients). The downside is that I end up with much more simulation data than is necessary for review/analysis, and qucs gets a little chunky when it has a 1.5 GB memory footprint. I noticed that the transient simulation has a MinStep property that expresses the minimum time step size to be used in simulation, but that there isn't a MaxStep property. My interpretation is that the MaxStep is defined as (Stop  Start)/Points. If this interpretation is correct, is there a way to specify a MaxStep equivalent that's independent of the number of data points captured? If not, any suggestions for better accuracy with fewer points? I've already manipulated the integration method and gotten large improvements over the 2nd order trapezoidal (I'm on a 4th order Gear at the moment). Thanks, Mike mike@... 
From: Stefan Jahn <stefan@gr...>  20060801 07:30:05

Am Mo, 31.07.2006, 23:02, schrieb Mike Kost: > Hi there, Hello Mike, > I've been simulating models of analog PWM modulators. I've noticed that if > I > do not have a sufficient number of points per ms of simulation time, the > results will start to diverge (wildly) from the expected result. As I add > simulation points, it converges on the expected result. This is not > unreasonable since PWM systems have very large transients (depending on > how > the simulator handles such transients). The downside is that I end up with > much more simulation data than is necessary for review/analysis, and qucs > gets a little chunky when it has a 1.5 GB memory footprint. I noticed that > the transient simulation has a MinStep property that expresses the minimum > time step size to be used in simulation, but that there isn't a MaxStep > property. My interpretation is that the MaxStep is defined as (Stop  > Start)/Points. If this interpretation is correct, is there a way to > specify > a MaxStep equivalent that's independent of the number of data points > captured? Yep. Your interpretation is right. > If not, any suggestions for better accuracy with fewer points? > I've already manipulated the integration method and gotten large > improvements over the 2nd order trapezoidal (I'm on a 4th order Gear at > the > moment). In your case you would like to limit the "maxstep" to a smaller value to get better accuracy, but few points only. Did I understand you correctly? Stefan. 
From: Mike Kost <mike@ta...>  20060801 12:49:37
Attachments:
Message as HTML

Stephan, > If not, any suggestions for better accuracy with fewer points? > > I've already manipulated the integration method and gotten large > > improvements over the 2nd order trapezoidal (I'm on a 4th order Gear at > > the > > moment). > > In your case you would like to limit the "maxstep" to a smaller value to > get better accuracy, but few points only. Did I understand you correctly? Yes. That was the immediate solution that sprang to mind. I do not know enough about the simultaor internals to do more than speculate, but I suspect my problem originates from the fact that I'm using ideal relays. I am guessing that large maxstep values result in the simulator missing the actual close/open time and instead uses the nearest maxstep that is near the close/open event, but that the discrepency does not cause convergence problems so the simulator does not drop to a smaller step value. If this theory is correct, a better solution to the problem would be for the simulator to attempt to locate the actual relay / switch open/close time. This would be done as follows 1. Note current time 2. Calculate next timestep 3. If a relay / switch changes state during the timestep, use a binary search to get more accuracy on the switching point It's possible that the simulator is doing some form of this, but if it is, I do not understand why I seem to need a smaller "maxstep" value. Thanks for your time Stefan, Mike 
From: Stefan Jahn <stefan@gr...>  20060802 05:47:35

Am Di, 1.08.2006, 14:49, schrieb Mike Kost: > Stephan, Hello Mike, > I do not know enough about the simultaor internals to do more than > speculate, but I suspect my problem originates from the fact that I'm > using > ideal relays. I am guessing that large maxstep values result in the > simulator missing the actual close/open time and instead uses the nearest > maxstep that is near the close/open event, but that the discrepency does > not > cause convergence problems so the simulator does not drop to a smaller > step > value. That is exactly what the algorithm relies on. It limits the dv/dt and di/dt of transients and thus gets smaller timesteps. Actually this should work... > If this theory is correct, a better solution to the problem would > be > for the simulator to attempt to locate the actual relay / switch > open/close > time. This would be done as follows > 1. Note current time > 2. Calculate next timestep > 3. If a relay / switch changes state during the timestep, use a binary > search to get more accuracy on the switching point This concept is done with the requested timepoints. Please note the relaxTSR property of the transient analysis. Anyway. Can you send me the schematic + dpl which shows the problem? Thanks in advance, Stefan. 
From: Mike Kost <mike@ta...>  20060802 21:26:36
Attachments:
Message as HTML
bug_points.tar.gz

From: Stefan Jahn <stefan@gr...>  20060822 08:59:48

Am Mi, 2.08.2006, 23:26, schrieb Mike Kost: Hello Mike, >> That is exactly what the algorithm relies on. It limits the dv/dt and >> di/dt of transients and thus gets smaller timesteps. Actually this >> should work... > > I suspect it may be because the relays are not causing a dramatic dv/dt or > di/dt. The system effectively contains integrators, so smaller errors > spread > over a large time period can swing the results. What nodes or components > does the simulator use to check dv/dt or di/dt discontinuities? It uses Milne's estimate. Please refer to the 'technical.pdf' in the transient analysis chapter. Stefan. 
From: Stefan Jahn <stefan@gr...>  20060922 10:28:36
Attachments:
less_points.sch

Am Di, 19.09.2006, 15:45, schrieb Mike Kost: Hello there! >> Ok.. I just had a look at your mail which you send to me. There were >> two schematics: >> >> 1) main.sch  050ms, 5e6 points >> 2) less_points.sch  010ms, 1e5 points >> >> Which of them do you consider to be correct? And why do the endtimes >> differ? >> > > I must've tarred it up at the wrong time. Oops. The main.sch should have > start=0, stop=10ms, 5e6 points and less_points.sch should have start=0, > stop=10ms, 1e6 points. Under these conditions, main.sch has the expected > behavior (Vout goes to the 5v area and then decays to 0v). I just > confirmed > that my current simulations use these stop, start, and points. Ok, I check the schematics once again. In the attachment you find a modified version which is probably what you want. I played with the initial conditions of the L/C's in the circuit. Due to the large L/C values you have also large time constants. And on the other hand you have small time steps due to the current excitations. This is the problem. Now I also see why you request a MaxStep property for the transient analysis. In your case the builtin algorithm to determine a max. step somehow fails due to the above problem. Locally I already implemented the property. It's going into CVS as soon as possible and will be available in the next release. Cheers and thanks for your patience, Stefan. 
From: Mike Kost <mike@ta...>  20060922 15:28:02
Attachments:
Message as HTML

> > > I must've tarred it up at the wrong time. Oops. The main.sch should have > > start=0, stop=10ms, 5e6 points and less_points.sch should have start=0, > > stop=10ms, 1e6 points. Under these conditions, main.sch has the expected > > behavior (Vout goes to the 5v area and then decays to 0v). I just > > confirmed > > that my current simulations use these stop, start, and points. > > Ok, I check the schematics once again. > > In the attachment you find a modified version which is probably what > you want. I played with the initial conditions of the L/C's in the > circuit. Due to the large L/C values you have also large time constants. > And on the other hand you have small time steps due to the current > excitations. This is the problem. Very good! Now I also see why you request a MaxStep property for the transient > analysis. In your case the builtin algorithm to determine a max. step > somehow fails due to the above problem. Locally I already implemented > the property. It's going into CVS as soon as possible and will be > available in the next release. I'll be watching for the next release! I am still curious to understand how the timestep control handles a state change in a relay (transition from closed>open or vise versa). In our previous emails, you mentioned that the timestep control took it into account, but I don't understand how it responds. Cheers and thanks for your patience, > All the thanks should be to you, Stefan, for working on this great simulator. Mike 
From: Stefan Jahn <stefan@gr...>  20060925 08:16:16

Am Fr, 22.09.2006, 17:27, schrieb Mike Kost: Hi Mike, >> > I must've tarred it up at the wrong time. Oops. The main.sch should >> have >> > start=0, stop=10ms, 5e6 points and less_points.sch should have >> start=0, >> > stop=10ms, 1e6 points. Under these conditions, main.sch has the >> expected >> > behavior (Vout goes to the 5v area and then decays to 0v). I just >> > confirmed >> > that my current simulations use these stop, start, and points. >> >> Ok, I check the schematics once again. >> >> In the attachment you find a modified version which is probably what >> you want. I played with the initial conditions of the L/C's in the >> circuit. Due to the large L/C values you have also large time >> constants. >> And on the other hand you have small time steps due to the current >> excitations. This is the problem. > > > Very good! > > Now I also see why you request a MaxStep property for the transient >> analysis. In your case the builtin algorithm to determine a max. step >> somehow fails due to the above problem. Locally I already implemented >> the property. It's going into CVS as soon as possible and will be >> available in the next release. > > > I'll be watching for the next release! It's now in CVS... > I am still curious to understand how the timestep control handles a state > change in a relay (transition from closed>open or vise versa). In our > previous emails, you mentioned that the timestep control took it into > account, but I don't understand how it responds. When the relay switches, then the solution (new node voltages and branch currents) changes. Depending on the integration method the transient solver does allow a maximum change in the solution. If this limit is hit the timestep gets reduced until the change is considered sufficiently small. That is basically how timestep control works. Hope this helps, Stefan. 