Hi,

I did not try this yet, but why does your plot look like it ends before 180ms yet the calculation period looks like it is 180ms.
That could be why you got 81w instead of closer to 88w. If you fix that I would bet you get much closer to 88w.

The problem isn't that the simulation ended before 180 ms. The problem is that the period of integration is not an integral number of cycles (or at least half cycles). At 60 Hz, 180 ms is 10.8 cycles, so it would be hard, though not impossible, to get a valid result by averaging over 180 ms.

The period of a 60 Hz waveform is (1/60)s so 180 ms is 10.8 cycles.

The power after the waveform stops does not go to zero, but is rather about midway between 0 W and 30 W. A glance at the current source parameters shows that it is specified to only produce ten cycles. After that, it stays at the DC value of 2 A which, through a 4 Ω load is 16 W, which tracks very nicely.

So the expected average over 180 ms would be the 88 W over the first 166.7 ms and 16 W over the remaining 13.3 ms, would would yield an average of 82.68 W. The displayed result of 81.57 W differs from this by just 1.3%. Looking at the waveform, the sampling artifacts are readily apparent and probably explain the minor discrepancy. The integration control parameters might also play a role.

 

The problem isn't that the simulation ended before 180 ms. The problem is that the period of integration is not an integral number of cycles (or at least half cycles). At 60 Hz, 180 ms is 10.8 cycles, so it would be hard, though not impossible, to get a valid result by averaging over 180 ms.

The period of a 60 Hz waveform is (1/60)s so 180 ms is 10.8 cycles.

The power after the waveform stops does not go to zero, but is rather about midway between 0 W and 30 W. A glance at the current source parameters shows that it is specified to only produce ten cycles. After that, it stays at the DC value of 2 A which, through a 4 Ω load is 16 W, which tracks very nicely.

So the expected average over 180 ms would be the 88 W over the first 166.7 ms and 16 W over the remaining 13.3 ms, would would yield an average of 82.68 W. The displayed result of 81.57 W differs from this by just 1.3%. Looking at the waveform, the sampling artifacts are readily apparent and probably explain the minor discrepancy. The integration control parameters might also play a role.

Hello,

Here is what I had said:
"I did not try this yet, but why does your plot look like it ends before 180ms yet the calculation period looks like it is 180ms.
That could be why you got 81w instead of closer to 88w. If you fix that I would bet you get much closer to 88w."

That's my exact wording, and there is nothing wrong with that. Nothing whatsoever. Your interpretation did not reflect the true logic behind that statement. Also, if one full cycle yields 88 watts how does 80 percent of one cycle come out to only 16 watts? That's like 20 percent of the power of one cycle. Going over a partial cycle we could actually end up with a higher average power not lower. Your 16 watts is due to the DC current alone, but who needs that.

If the plot goes to zero before the end of the integration period, the calculation goes down.
The integration period was 0.180 seconds. The total plot period is 0.1666666 seconds.
What this means is that for that 0.1666666 seconds we are integrating over 10 full cycles, and for 80 percent of the next cycle (0.01333333 seconds) we have zero.
When we average we go over the period, and if we have 10 of some things that are all of value 1 and we average a period of 10, we get of course 1.
Now if we again have 10 of those values of 1 each over a period of 10 and one value of 0 for the same time as each of the 1 values were, then we have to average over a period of 11. Thus 10/11=0.90909
So we went from an average of 1 down to an average of about 0.91 which is nearly 10 percent lower.
To fix this, we just average of the first 10 values because that last one of value 0 is bogus, it does not belong in the set. Since 10/10=1 we get the right average.

That's the basic idea, but there's more to it than that. In that example we did not include any function for the amplitudes and did not assume that that function was valid over the entire averaging period. We assumed that the function gave us a value of 1 always, and then threw in a bogus value of 0 later just to see what would happen.
What this means is that if the function yields a high value we might actually get a value that is higher than the original average of 1 with just 10 samples.

I did this quick so you may want to check this one out...
If we have 10 samples of 88 watts where each period is 1, and 1 sample of 105 watts where the period is 0.8, then the average is about 87.6 watts.
Alternately, 88 watts for 10 seconds and 105.4 watts for 0.8 seconds.
88*10+105.4*0.8=89.29 watts
That's close to 88 watts, but moreover it is correct for the extended period.

It makes sense that if we have 10 cycles of one value and a large fraction of a cycle we might get slightly less than with just the 10 cycles.
Consider 90 percent of one full cycle added to those original 10 cycles. How much less than 88 watts can it really be. Because the amplitude is high and the period is shorter, we end up with a higher local average of around 105.4 watts.

Now consider the average over the original 0.180 second when we include the actual waveform out to 0.180 seconds.
When we use the instantaneous power to compute the average, we end up with:
89.289 watts.
That's sort of close to 88 watts, but over the entire period it is correct.

So the fix is to get rid of the tail end and just use 10 cycles, but if we really have to calculate over the 0.180 period then at least extend the waveform out that far before averaging.

 

That's my exact wording, and there is nothing wrong with that. Nothing whatsoever. Your interpretation did not reflect the true logic behind that statement. Also, if one full cycle yields 88 watts how does 80 percent of one cycle come out to only 16 watts? That's like 20 percent of the power of one cycle. Going over a partial cycle we could actually end up with a higher average power not lower. Your 16 watts is due to the DC current alone, but who needs that.

If the plot goes to zero before the end of the integration period, the calculation goes down.
The integration period was 0.180 seconds. The total plot period is 0.1666666 seconds.
What this means is that for that 0.1666666 seconds we are integrating over 10 full cycles, and for 80 percent of the next cycle (0.01333333 seconds) we have zero.

Have you actually looked at the plot or read my post?

The plot clearly does NOT go to zero after ten cycles. Look at the plot. Where is zero on the y-axis? Does that align with the flat portion at the end of the plot? No. That flat line is midway between 0 W and 30 W. I pointed that out explicitly. So, what is it? I pointed that out explicitly as well. It is the DC component of the current source since the source is configured to only output ten cycles of the sine wave in addition to the 2 A of DC current.

The math is not hard, but let me walk you through it.

180 ms at 60 Hz represents 10.8 cycles. This can be broken into 10 cycles at the average power of the waveform of interest, Let's call it Pavg, and 0.8 cycles at the DC power level associated with a 2 A current flowing in a 4 Ω resistor, which is 16 W, let's call it 16 W. The average power measured over the entire 10.8 cycles, let's call that Ptot, is thus the weighted average of the two.

Ptot = ((10 cycles)*Pavg + (0.8 cycles)*Pdc) / (10.8 cycles)

If we are trying to explain where the measured value of Ptot of 81.569 W, then we use the known correct value of 88 W for Pavg and the 16 W for Pdc and we get an expected value of Ptot of

Ptot = ((10 cycles)*(88 W) + (0.8 cycles)*(16 W)) / (10.8 cycles) = 82.67 W

This differs from the displayed measurement by 1.3%.

If, on the other hand, we want to determine Pavg from the measured result, we simply solve for that.

Pavg = ((10.8 cycles)*Ptot - (0.8 cycles)*Pdc)) / (10 cycles)
Pavg = ((10.8 cycles)(81.569 W) - (0.8 cycles)*(16 W))) / (10 cycles) = 86.81 W

This differs from the expected value of 88 W by that same 1.3%

I also addressed where the discrepancy comes from, since the sampling artifacts in the waveform are readily apparent. If you decrease the minimum time step a couple orders of magnitude, you get a result that is within about 50 ppm.

So, the answer to your question of who needs the 16 W, the answer is that we do -- if we want to get the best results we can.

If we must average over 180 ms, it is far better to have the tail be a known constant value than for it to be a fraction of a complex waveform.


When we average we go over the period, and if we have 10 of some things that are all of value 1 and we average a period of 10, we get of course 1.
Now if we again have 10 of those values of 1 each over a period of 10 and one value of 0 for the same time as each of the 1 values were, then we have to average over a period of 11. Thus 10/11=0.90909
So we went from an average of 1 down to an average of about 0.91 which is nearly 10 percent lower.
To fix this, we just average of the first 10 values because that last one of value 0 is bogus, it does not belong in the set. Since 10/10=1 we get the right average.

That's the basic idea, but there's more to it than that. In that example we did not include any function for the amplitudes and did not assume that that function was valid over the entire averaging period. We assumed that the function gave us a value of 1 always, and then threw in a bogus value of 0 later just to see what would happen.
What this means is that if the function yields a high value we might actually get a value that is higher than the original average of 1 with just 10 samples.

I did this quick so you may want to check this one out...
If we have 10 samples of 88 watts where each period is 1, and 1 sample of 105 watts where the period is 0.8, then the average is about 87.6 watts.
Alternately, 88 watts for 10 seconds and 105.4 watts for 0.8 seconds.
88*10+105.4*0.8=89.29 watts
That's close to 88 watts, but moreover it is correct for the extended period.

It makes sense that if we have 10 cycles of one value and a large fraction of a cycle we might get slightly less than with just the 10 cycles.
Consider 90 percent of one full cycle added to those original 10 cycles. How much less than 88 watts can it really be. Because the amplitude is high and the period is shorter, we end up with a higher local average of around 105.4 watts.

Now consider the average over the original 0.180 second when we include the actual waveform out to 0.180 seconds.
When we use the instantaneous power to compute the average, we end up with:
89.289 watts.
That's sort of close to 88 watts, but over the entire period it is correct.

So the fix is to get rid of the tail end and just use 10 cycles, but if we really have to calculate over the 0.180 period then at least extend the waveform out that far before averaging.
[/QUOTE]

 

Would you have made a similar assertion about zero average power if the component had been a capacitor instead of an inductor?
Think about both of these situations and see if you can give a reasoned and supported answer to each.

For this i am assuming that the circuit will be something like with


\[ I1 = (2 + 6\sin(2\pi60t) )A \]
but due to the DC current of 2A the capacitor voltage will continue raising till saturation and may not be valid analysis.

Would you also have made this assertion if you had been given a periodic inductor voltage that had both an AC and a DC component?

Here also if the inductor has to have a constant DC voltage, then the current signal has to ramp indefinitely.

 

For this i am assuming that the circuit will be something like with
View attachment 362817

\[ I1 = (2 + 6\sin(2\pi60t) )A \]
but due to the DC current of 2A the capacitor voltage will continue raising till saturation and may not be valid analysis.


Here also if the inductor has to have a constant DC voltage, then the current signal has to ramp indefinitely.

Correct reasoning!

 

For this i am assuming that the circuit will be something like with
View attachment 362817

\[ I1 = (2 + 6\sin(2\pi60t) )A \]
but due to the DC current of 2A the capacitor voltage will continue raising till saturation and may not be valid analysis.


Here also if the inductor has to have a constant DC voltage, then the current signal has to ramp indefinitely.

Hi,

Current is the same in a series circuit, so you do not need anything else but the current source and the resistor in order to determine the power in the resistor.
I don't see anything that says we have to shut off the sinusoidal part of the current after exactly 10 cycles and leave the DC part still running up to 0.18 seconds so why did you simulate that.
If you want the average of this circuit in its entirety over a given period, then you need the sine part plus the DC part to remain ON for the entire period.
That goes for both periods of 10 cycles (0.1666666 seconds) or the 10 cycles plus a tail end (0.1800000 seconds).

As you know, the average power over 10 cycles is 88 watts, but over a period of 0.180 seconds it is slightly higher.
It might seem strange how we can average a fraction of a cycle with a lot of full cycles and get an average that is higher. It's because the power function of each cycle has a higher peak.
The average power function is:
P(Tp)=[880*pi*Tp+8-3*sin(240*pi*Tp)-8*cos(120*pi*Tp)]/(10*pi*Tp)
where Tp is the period over which we want to find the average, where the period is from t=0 to t=Tp.
Here are the approximate peaks for the first 11 full cycles noting the time and the average power value for each cycle arranges as
[Tp, Peak watts]:

[0.0060558888888889, 173.1297610515912]
[0.023474185185185, 111.6641131917108]
[0.040340851851852, 101.8440412667505]
[0.057007518518519, 97.79660985579449]
[0.073774185185185, 95.57452745952256]
[0.090440851851852, 94.17867457069561]
[0.10720751851852, 93.20832651432728]
[0.12387418518519, 92.50757161712507]
[0.14054085185185, 91.97302103892065]
[0.15730751851852, 91.54211887356064]
[0.17397418518519, 91.20278511265525]

As we can see, the peaks between cycles goes down as we include more and more cycles. The limiting value is 88 watts.
These values are approximate probably accurate to just 4 significant digits.

Also a little interesting, we can see the structure a little clearer by reducing the P(Tp) function a little:
P(Tp)=88+[8-3*sin(240*pi*Tp)-8*cos(120*pi*Tp)]/[10*pi*Tp]

and from this the '88' average stands clear, while the rest is the 'tail end' part which can include either another full cycle, or a partial cycle.

 

Have you actually looked at the plot or read my post?

The plot clearly does NOT go to zero after ten cycles. Look at the plot. Where is zero on the y-axis? Does that align with the flat portion at the end of the plot? No. That flat line is midway between 0 W and 30 W. I pointed that out explicitly. So, what is it? I pointed that out explicitly as well. It is the DC component of the current source since the source is configured to only output ten cycles of the sine wave in addition to the 2 A of DC current.

The math is not hard, but let me walk you through it.

180 ms at 60 Hz represents 10.8 cycles. This can be broken into 10 cycles at the average power of the waveform of interest, Let's call it Pavg, and 0.8 cycles at the DC power level associated with a 2 A current flowing in a 4 Ω resistor, which is 16 W, let's call it 16 W. The average power measured over the entire 10.8 cycles, let's call that Ptot, is thus the weighted average of the two.

Ptot = ((10 cycles)*Pavg + (0.8 cycles)*Pdc) / (10.8 cycles)

If we are trying to explain where the measured value of Ptot of 81.569 W, then we use the known correct value of 88 W for Pavg and the 16 W for Pdc and we get an expected value of Ptot of

Ptot = ((10 cycles)*(88 W) + (0.8 cycles)*(16 W)) / (10.8 cycles) = 82.67 W

This differs from the displayed measurement by 1.3%.

If, on the other hand, we want to determine Pavg from the measured result, we simply solve for that.

Pavg = ((10.8 cycles)*Ptot - (0.8 cycles)*Pdc)) / (10 cycles)
Pavg = ((10.8 cycles)(81.569 W) - (0.8 cycles)*(16 W))) / (10 cycles) = 86.81 W

This differs from the expected value of 88 W by that same 1.3%

I also addressed where the discrepancy comes from, since the sampling artifacts in the waveform are readily apparent. If you decrease the minimum time step a couple orders of magnitude, you get a result that is within about 50 ppm.

So, the answer to your question of who needs the 16 W, the answer is that we do -- if we want to get the best results we can.

If we must average over 180 ms, it is far better to have the tail be a known constant value than for it to be a fraction of a complex waveform.

MrAL:
When we average we go over the period, and if we have 10 of some things that are all of value 1 and we average a period of 10, we get of course 1.
Now if we again have 10 of those values of 1 each over a period of 10 and one value of 0 for the same time as each of the 1 values were, then we have to average over a period of 11. Thus 10/11=0.90909
So we went from an average of 1 down to an average of about 0.91 which is nearly 10 percent lower.
To fix this, we just average of the first 10 values because that last one of value 0 is bogus, it does not belong in the set. Since 10/10=1 we get the right average.

That's the basic idea, but there's more to it than that. In that example we did not include any function for the amplitudes and did not assume that that function was valid over the entire averaging period. We assumed that the function gave us a value of 1 always, and then threw in a bogus value of 0 later just to see what would happen.
What this means is that if the function yields a high value we might actually get a value that is higher than the original average of 1 with just 10 samples.

I did this quick so you may want to check this one out...
If we have 10 samples of 88 watts where each period is 1, and 1 sample of 105 watts where the period is 0.8, then the average is about 87.6 watts.
Alternately, 88 watts for 10 seconds and 105.4 watts for 0.8 seconds.
88*10+105.4*0.8=89.29 watts
That's close to 88 watts, but moreover it is correct for the extended period.

It makes sense that if we have 10 cycles of one value and a large fraction of a cycle we might get slightly less than with just the 10 cycles.
Consider 90 percent of one full cycle added to those original 10 cycles. How much less than 88 watts can it really be. Because the amplitude is high and the period is shorter, we end up with a higher local average of around 105.4 watts.

Now consider the average over the original 0.180 second when we include the actual waveform out to 0.180 seconds.
When we use the instantaneous power to compute the average, we end up with:
89.289 watts.
That's sort of close to 88 watts, but over the entire period it is correct.

So the fix is to get rid of the tail end and just use 10 cycles, but if we really have to calculate over the 0.180 period then at least extend the waveform out that far before averaging.

Hello again,

Ok, the way I saw it was we want to calculate the average power as the circuit stands, not a modified input, so I calculated the average up to 10 cycles and up to 0.180 seconds. I got 88 for 10 cycles and 89.29 watts over 0.180 seconds.

"If we must average over 180 ms, it is far better to have the tail be a known constant value than for it to be a fraction of a complex waveform."
It's rather easy to calculate over any period from t=0 to t=Tp where Tp is the desired period:
Pavg=88+[8-3*sin(240*pi*Tp)-8*cos(120*pi*Tp)]/[10*pi*Tp] {in watts}
This shows how the 'tail end' affects the outcome, and of course the tail end goes to zero for multiples of 1/60, and the limit as the period is allowed to go toward infinity is zero, so we are left with the 88 watts average. In fact, it looks like we get down to just 0.1 percent of 88 watts with just 18 cycles.

It might also be a little interesting we get 88 watts even for some short tail ends over the full period. That means there is a time between full cycles where we get the same average power of 88 watts even though we went just a little beyond 10 full cycles, but not as far as 11 full cycles.
The extra Tp time is approximately 0.00235 seconds which is roughly 1/7.1 of cycle, and it seems to hold this value (with a little deviation) up to many cycles.

 

Hello again,

Ok, the way I saw it was we want to calculate the average power as the circuit stands, not a modified input, so I calculated the average up to 10 cycles and up to 0.180 seconds. I got 88 for 10 cycles and 89.29 watts over 0.180 seconds.

Okay, I see what you're doing, I just don't see the point in doing it. Your approach only works if you know enough about the waveform to be able to calculate the instantaneous power as a function of time for all time. If you can do that, then there's no point using a simulator in the first place. But we frequently need to determine average power for extremely complicated and highly nonlinear waveforms that are periodic. The normal way to do that is to average the power over an integral number of waveforms. In a simulator, that is always possible (though you may have to dump the waveform data and post-process it, depending on the simulator). I'm talking about "real" simulators, here, not the toys that some places offer.

In the physical world, back before digital scopes and such, you could use a True RMS meter that measured the heat dumped into a calibrated resistor over a period of time long. Sometimes, for a variety of reasons, this couldn't be done continuously with the actual waveform, so you got creative. One technique was to gate the signal so that an integral number of periods were applied to the resistor (often an amplified copy of it) but separated by intervals with no signal. That is what you measured the average power of with your thermal-sensing meter and then you backed out the average power of the waveform of interest based on the reading and the dwell time.

 

Hi,

Current is the same in a series circuit, so you do not need anything else but the current source and the resistor in order to determine the power in the resistor.
I don't see anything that says we have to shut off the sinusoidal part of the current after exactly 10 cycles and leave the DC part still running up to 0.18 seconds so why did you simulate that.
If you want the average of this circuit in its entirety over a given period, then you need the sine part plus the DC part to remain ON for the entire period.

I am new to power calculations using LTSpice but yes i understood the mistake i have done.

 

I am new to power calculations using LTSpice but yes i understood the mistake i have done.

There are some subtleties that are good to keep in mind when using a simulator to do power estimations.

First, they rely on the simulator doing numerical integration of the waveforms, which will always introduce error into the results. These errors are typically small enough to be ignored since there are very few instances where we actually need the answer to be accurate to even 1%. Real world component tolerances will seldom make any discrepancies at that level or less matter. There are exceptions, however, so it's good to be aware of the issues and some of the things that can be done to mitigate them. So let's look at a few that have been mentioned.

Integral Number of Periods
If you are trying to find any kind of average (power, voltage, current, you name it) of a periodic waveform, you need to take that average over an integral number of periods. You will seldom have the information needed to compensate for fractional periods and, even if you do, the effort in doing so is seldom warranted. By default, most simulators use the entire simulation window for operations that span the independent variable (time, in our case). So unless you want to be more sophisticated in your simulation setup and analysis (which is possible and often necessary), run the simulation over an integral number of periods. An easy way to do this is to let the simulator calculate that time for you. For example, if I have a waveform at a frequency F, and I want to simulate it for N cycles, the time needed is simply N/F since (1/F) is the period of one cycle and you can encode that into your simulation command. For 10 cycles at 60 Hz, you can do this as follows:

.tran {10/60}

Expressions in curly braces are evaluated by the simulator and replaced with the result just as if you had entered them explicitly. You can make this more human friendly and self-documenting by using named parameters, such as

.param FREQ_HZ=60 CYCLES=10
.tran {CYCLES/FREQ_HZ}

Notice that if we want to change the number of cycles, we know exactly where to do it. Also note that we can embed units into the parameter names to help us keep those straight, since we can't include them in the expressions directly (which is a shame, but something we have to live with).

Finite Sampling Rate
The simulator is not working with a mathematical function defined over a continuous interval of time and which it is then integrating analytically. It is approximating the function by estimating it's value at specific points in time and then integrating them numerically using some method. Most simulators use trapezoidal integration, or some modified version of it, by default, but often support others, such as GEAR. I'm not going to go into the differences, it's enough at this point to simply know that different methods exist and, if it seems like it might be an issue in a particular task you are working on, you can explore them at that time since you will have a specific context to guide you.

If you look closely at your waveform, you can see the sampling artifacts by noting that the waveform isn't nice and smooth, but rather made up of short, straight line segments:



The above was snipped from your posted simulation results. The following is taken from mine using the default time step setting. Note that the simulator does not use a fixed sampling rate; it dynamically adjusts the simulation time increment at each step based on convergence heursitics so that it can use a large step when things are changing very slowly and small steps when they are changing rapidly. Otherwise you would end up with simulations that were accurate enough, but take forever to run, or that ran quickly, but are so inaccurate as to be useless.



Some of these artifacts are display artifacts and some of them are actual sampling artifacts in the data. Without examining the actual data in detail, it can be difficult to determine which is which.

Using the defaults, we get the following reported power average:



As you can see, it is very close to what we know is the correct answer of 88 W. The difference is only 0.065% and would almost never matter. But sometimes we are looking not for a highly accurate absolute value of a parameter, but for tiny changes in it. One chip I designed was staring straight into a probe laser and looking for variations in the power on the order of 0.1 ppm (due to the presence of combustion products being excited by a transverse laser that was pumping them up), so we needed simulations that were precise enough (as distinguished from accuracy) to see these changes. It was challenging, but doable.

But let's see what happens if we set the maximum timestep that the simulator is allowed to use to 100 ns.



Doesn't look like much has changed, but now the error is just 0.020%, which is less than a third of what it was.

But the simulation took a bit under a minute to run (on my machine). Would changing the time step limit to 10 ns do even better? It's reasonable to think it might, but the simulation would probably take close to ten minutes to run. But do we really need to run it over ten cycles? In the real world, the more cycles we use, the better the estimate we get because random things, like noise, tend to cancel out when they are averaged over longer periods. But is this true for a simulator? Let's keep the same time-step limit but change the number of cycles to just one.



We get the exact same value, but the simulation took just a couple seconds. So let's change the time step to 10 ns and see what happens.



This might look like it got the result exactly correct, but it can be confident it didn't. It just got it so that the result, when rounded to the five sig figs displayed, came out to 88.000 W, so the error could have been right at 0.0005 W, which would place the limit at 0.00057% (6 ppm), compared to 200 ppm for the prior result and 650 ppm for the default time step.

We can get a result to a greater number of sig figs by using a .meas statement:

.meas TRAN Pavg AVG V(B,C)*I(R1)

The results are placed in the log file:

pavg: AVG(v(b,c)*i(r1))=87.9998 FROM 0 TO 0.0166667

So, from this, we can see that the actual error was only about 2.2 ppm.

Now, what if we really needed to see the result to more digits? We can set some options to tell the simulator to use more precision in the calculations using the NUMDGT options, but this won't affect the number of digits displayed in the log file (and we can't change the number of digits changed in the GUI output). For that, we also need to set the MEASDGT option to the desired value. We can go up to about 14 or 15, as this puts us up against the limits of the double-precision floating point representation. Setting both to 12 produced the following:

pavg: AVG(v(b,c)*i(r1))=87.9998203415 FROM 0 TO 0.0166666666667

So decreasing the max time step by a factor of ten reduced the error by a factor of one hundred. That's not bad.

Does decreasing the max time step even more get this even closer? Let's find out and set it to 1 ns.

As expected, this took several minutes to run, but if we need better results, we have to pay for them somehow.

pavg: AVG(v(b,c)*i(r1))=87.9999982027 FROM 0 TO 0.0166666666667

We did, indeed, pick up another two orders of magnitude reduction in the error and are now right at 20 ppb (parts per billion). Essentially, eight sig figs.

Quantization Error
It might seem like we could keep going and get better and better all the way up to the 15 sig fig limit of the floating point representation used by the simulator, but can't because of another effect that comes into play. The numerical integration breaks the time interval up into small slices, estimates the area for each slice, and the adds them all up. The trapezoidal method assumes that the actual function is a straight line between sample points. By breaking it up into small slices, we reduce the error associated with this assumption. But each sample point also has error in the magnitude associated with the fact that values are quantized. This error then gets summed over all of the slices. Usually, the error is sufficiently random that the more slices there are, the less effect the quantization error has on the final result (it averages out to zero). But, sometimes, it can turn out to result in a systematic error that builds up as the number of slices increases and what you discover is that, as you decrease the time step, the error stops decreasing then then starts increasing again. It's usually still very small, but it makes it so that you can't count on results being better just because you used a smaller time step. If you ever think you might be running up against these limits, that is one situation in which exploring the other integration methods might prove beneficial -- but, in all likelihood, you will never run into it.

Transient Response Artifacts
When the input signal to a system changes nature, there is an amount of time that is needed for the output response to settle into its steady state behavior. The simulator does not really care about this at the beginning of the simulation. All it really cares about is finding a set of voltages at every node and currents through every component pin that are sufficiently self-consistent for the simulation to be able to start running. This is known as "operating point convergence". With more complex circuits, getting the operating point to converge can become a challenge and there's no guarantee that the initial operating point bears any resemblance to what an actual circuit would exhibit. But that's fine, provided we let the simulation run long enough for this to die out and settle into the actual behavior. But it also means that we can't just take an average over the first period or even over the entire simulation covering multiple periods blindly, as that average will be corrupted by the transient response. In the simulation for this particular circuit, we got lucky and, because it is so simple, the DC operating point converged at a set of values that are consistent with the steady state response, so there is not initial transient. This is almost never the case with circuits of any practical interest.

For example. consider the case where the inductor and resistor are parallel instead of in series. Now the instantaneous power waveform looks like the following (using a 100 ns min time step).





The initial transient is obvious, but appears to die out (to the eye by the end of the second cycle (33.3 ms). If we do the calculation by hand, we get an average power in steady state of 48 W (47.988753... W). That's a 2.3% error, which may be good enough in most cases. If we want better results, there are basically two ways to deal with this. The chainsaw approach is to run the simulation over enough cycles so that the transient dies out in a small enough number of them so that the average is dominated by the subsequent cycles that have reached steady state.

If we run the simulation over 100 cycles, which takes a few minutes at this min time step:



This is an error of 0.26%, which is about an order of magnitude better, which is about what we would expect.

But, if we wanted to get the error down another order of magnitude into the 200 ppm range that we got before with this min time step, we would have to average over about a thousand cycles, which would take the better part of an hour. Where it really gets absurd if if we wanted to get into the 2 ppm range. This would be expected to require an addition factor of 100 in cycle count AND we need to reduce the time step to 10 ns. The combination would increase our simulation time by another factor of a thousand, so now we are talking needing the simulation, on this trivially simple circuit, to run for over a month to run.

So let's see if we can find a scalpel instead of a chainsaw. What if we calculate our average not over the entire simulation window, but only over a portion of it that starts after the transient has died out sufficiently? We can't do this with the waveform editor, but we can do it very easily with our .meas statement by simply giving it limits. We've already seen that average of a single period is perfectly fine, as long as that period is representative of the steady state behavior. So let's use the last cycle in the simulation, which means that the start time for the integration is then (CYCLES-1)/FREQ_HZ and the end time is CYCLES/FREQ_HZ. Here's what the resulting .meas statement looks like:

.meas TRAN Pavg AVG V(B,C)*I(R1) FROM {(CYCLES-1)/FREQ_HZ} TO {CYCLES/FREQ_HZ}

Let's see the effect of this on the original simulation of 10 cycles at a min time step of 100 ns, but only calculating the average over the last cycle. Of course, the GUI still report 46.889 W, but here's what's in the log file:

pavg: AVG(v(b,c)*i(r1))=47.969580524 FROM 0.15 TO 0.166666666667

Our error by just looking at the last cycle instead of all ten has dropped from 0.26% (2600 ppm) to 0.04% (400 ppm). In improvement by a factor of 7.5. Notice that this error level is in the realm of the 200 ppm we saw with the previous circuit which didn't suffer from a startup transient.

We know that, in theory, a transient response like this never dies completely, but the further out we go, the smaller it gets. So what if we keep the same time step limit but go out 100 cycles? This yields:

pavg: AVG(v(b,c)*i(r1))=47.9694863393 FROM 1.65 TO 1.66666666667

If we get a noticeable improvement, it indicates that the transient was still influencing the result at ten cycles. If we get very little change, it indicates that ten cycles was probably sufficient and that it's time to reduce the time step to get better results.

In this case, we get very little change (it actually went up from 400 ppm to 401.5 ppm), so ten cycles is as good as a hundred. We might go the other way and see if we can use fewer cycles without getting different results, but instead, let's go back to ten cycles but reduce the min time step to 10 ns.

pavg: AVG(v(b,c)*i(r1))=47.9806353395 FROM 0.15 TO 0.166666666667

This is now at 170 ppm. This is an improvement by a factor of two, but not nearly the factor of a hundred we saw with the prior circuit when we decreased the time step, which probably indicates that we are still seeing the influence of the transient. Since this simulation took under a minute (as opposed to a month!), we can afford to push the sim out some to see if it improves. Let's go out to 100 cycles, which we no expect to take about ten minutes, which is tolerable.

pavg: AVG(v(b,c)*i(r1))=47.9806351671 FROM 1.65 TO 1.66666666667

This is virtually unchanged from the prior simulation, which either indicates that we've reached the limits of our ability to improve it by the use of these two levers, or that my calculation of the "correct" answer manually is slightly off. But I don't think it's the latter since I let the Windows calculator (which does 64-bit math) carry everything internally.

 

Remember I told you that not tracking your units properly will come back to bite you sooner or later -- and that I said it would likely be sooner? Well, it bit you right here.

ASIDE: Back when I was a junior and taking Intermediate Electricity and Magnetism, the professor (who eventually became the president of the university) walked into class the first day and started off by saying, "There are two things that separate you and me from Nobel Prize winning physicists. The person walking across the stage in Stockholm religiously does two things. They always, always, always track their units, and they always, always, always ask if the answer makes sense." That is quite possibly the most impactful advice that any professor has ever given me and it has paid huge dividends throughout my career. I made a point of telling him so some ten years later and I've had two of my own students come back after several years to say something similar to me. So, why don't I have a Nobel Prize, you might ask. Simple, as diligent as I am, I'm obviously still not religious enough about it.

So let's consider the "does it make sense" part.

I want to use it in practice and plan to apply for the below circuit, which is part of bigger circuit and few problems in plotting the graphs, if you can guide me that long standing issue it will be great help


\[ Applying KVL \\ V volts = V_L \ volt + V_C \ volt \\ Applying Laplace transform \\ \frac{V volts}{s} = L \ Henry * s*I(s) A +\frac{I(s) A} {C Farad * s} ->1 \\ I(s) A = \frac{V volt * C Farad }{1+L Henry *C Farad * s^2} ->2 \\ Applying\ Inverse \ Laplace \ Transform \\ i(t) A = V volt *\sqrt{\frac{C Farad }{L Henry}}*\sin{(\frac{t sec}{\sqrt{L Henry*C Farad}}}) \\ = V volt *\sqrt{\frac{C \frac{Col}{Volt} }{L \frac{Volt*sec}{A}}}*\sin{(\frac{t sec}{\sqrt{L \frac{Volt*sec}{A}*C \frac{Col}{Volt}}}}) \\ i(t) A = V volt *\sqrt{\frac{C \frac{A * sec}{Volt} }{L \frac{Volt*sec}{A}}}*\sin{(\frac{t sec}{\sqrt{L \frac{Volt*sec}{A}*C \frac{A*sec}{Volt}}}}) \\ \] -> 1
Unit wise it is correct.
Inductance Voltage
\[ V_L(t) Volts = L Henry \frac{dI A} {dt sec} \\ V_L(t) Volt = V Volt \cos{(\frac{t sec}{\sqrt{L \frac{Volt*Sec}{A} * C \frac{A*sec}{Volt}}})} -> 2 \\ \]
Cos is a number and hence it is unit wise correct.
Finding the Capacitor Voltage
VC(t) = V - VL(t)
Unit wise it is correct.
One of the biggest difficulties for me is plotting the signals (i tried to understand but not following). Basic question is should i plot with X axis in (t sec) or (w rad/sec * t sec) or (f cycles / sec), which one should i prefer? How many points do i need to take?

"Does it make sense" part without plotting but based on equations
As soon as switch is closed capacitor voltage cannot change and inductor current cannot change hence at
t=0 sec
All the voltage will be applied across the inductor
Hence VL(0) = V; Vc(0) = 0; I(t) = 0;
Current increases, Voltage of the inductor decreases and the capacitor voltage increases. Beyond this i can only understand based on plot. Am i applying correct way the "Does it make sense" part
The final goal is to solve the below circuit

 

Okay, I see what you're doing, I just don't see the point in doing it. Your approach only works if you know enough about the waveform to be able to calculate the instantaneous power as a function of time for all time. If you can do that, then there's no point using a simulator in the first place. But we frequently need to determine average power for extremely complicated and highly nonlinear waveforms that are periodic. The normal way to do that is to average the power over an integral number of waveforms. In a simulator, that is always possible (though you may have to dump the waveform data and post-process it, depending on the simulator). I'm talking about "real" simulators, here, not the toys that some places offer.

In the physical world, back before digital scopes and such, you could use a True RMS meter that measured the heat dumped into a calibrated resistor over a period of time long. Sometimes, for a variety of reasons, this couldn't be done continuously with the actual waveform, so you got creative. One technique was to gate the signal so that an integral number of periods were applied to the resistor (often an amplified copy of it) but separated by intervals with no signal. That is what you measured the average power of with your thermal-sensing meter and then you backed out the average power of the waveform of interest based on the reading and the dwell time.

Hello again,

"I just don't see the point in doing it"
I can't imagine what you mean here. The problem is to calculate the average power over some time periods, or did I miss something?
I calculated over 10 cycles because that seems like the best way. I calculated from t=0 to t=0.18 because the member seemed to have wanted to calculate over that period also. Then, I saw that it would be good to show how it changed from over 10 full cycles to the 10 full cycles plus the extra time that brought it out to 0.180 seconds, and that would show how the average would be with the right (original) waveform.
I do understand however why you wanted to keep the ending part that was shown as DC in that one plot.
I am showing a simulation of the average power. The green plot is the average at the very end of the 0.180 seconds, and the red plot is the calculated value shown as a constant. They match very closely at the 0.180 seconds point.
It's a little hard to see but at the time 16.67ms the average is slightly below the red line, and that should be at 88 watts as that is one full cycle.

"Your approach only works if you know enough about the waveform..."
What else are we looking for here?

"In the physical world..."
In the physical world I would have to sometimes estimate the power in the switching transistors in a rather high-power converter, so we could verify that the driver was working correctly and the transistors would not overheat. Do do that, we had to measure the current and voltage with a CRT scope and estimate the current and voltage waveshapes, then come up with an average power calculation. We did not have digital scopes back then as they were just starting to emerge around that time and were very expensive and not that great anyway.
To accompany that, sometimes we had to drill into the back side of the heat sink to insert a probe and measure the temperature after so many hours of run time.
These were very expensive power converters everything had to be right.

 

I am new to power calculations using LTSpice but yes i understood the mistake i have done.

Hi,

As @WBahn pointed out, you do have to make sure things are right.
For example, it is a good idea to use a maximum step size as small as possible so the calculations come out decent.