qucsator : avoid taking a time step that will bring too close to a breakpoint. #202
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
uh, oh, |
|
Did you run also the |
|
yes |
|
uhm, simulating one of the failing circuits manually in the GUI, |
|
The The circuits are not meeting the error < 1e-6 constraint... With your changes the error is on the 1e-3 range. These are the modified schematics I tried: https://gist.github.com/guitorri/ccb78d17b9b1180296b8 |
|
Crap! |
|
ok, there are several things going on here:
|
|
Nice job. This is looking good.
|
|
Regarding the default Roff, no particular reason that I know of, but this is the value it always was. I suppose there is a risk that a lower value will result in significant unexpected currents in some circuits? Arguably this is better than not working at all by default, so I'd support the change, but this is a sticking plaster for the real issue. |
|
@guitorri , do you use |
|
in |
|
@crobarcro, I asked about @in3otd I am also using autotools. I often do a I will fix the two sawtooth examples and add a couple more. |
|
Can you please rebase and push to pick up the latest Travis/AppVeyor settings? |
|
rebased... |
In case the selected step will bring too close to a breakpoint, reduce this step so that the next step will be larger. This avoids numerical errors when needing a very small time steps when approaching a breakpoint.
|
Looking good. |
|
The test was already added as DC_TR_LM358_spice_prj to qucs-test. The only change is MinStep that was increased to 1e-10 (from 1e-16). With your path both MinStep work. No relevant changes in execution speed before and after the patch. Merging. Thanks! |
guitorri
added a commit
that referenced
this pull request
Jan 27, 2016
qucsator : avoid taking a time step that will bring too close to a breakpoint.
|
...was just taking a look now |
|
@Qucs/maintainers I've just pushed a branch to my fork which adds the ability for circuit elements to suggest a suitable next time step (delta). Circuit elements also have a 'hasEvents' property. On each time step, all circuits with hasEvents==true are queried to provide a suggested time step. So far I have only made the tswitch use this functionality, with the idea being that it suggests a time exactly at the switching time. You can find the branch here: I need to test this, does anyone have a circuit with switches which is currently failing on master? The smallest suggested time step is taken as the next step unless the normal delta is smaller. |
|
ah, great work ! I have a directory where I try to put all the failing examples I see around, I'll look for a suitable example there later. |
|
strangely enough I did not find a circuit with timed switches that currently fails in my collection, but I made this from a failing circuit with a relay posted some time ago on Sourceforge not sure the convergence issues are due to the switch only, in any case playing with the switch parameters you can cause the simulation to fail in various ways 😒 |
|
I thing the important thing might be to have the transition method set to 'abrupt' for it to fail. I can get another simple circuit I have to fail by doing this. |
|
ok I've just pushed some changes which allow the circuit below to finish which is failing on master (by simulation hanging for a long time). My new code passes all the same tests in the python qucs test suite, but is a little slower in some cases, but faster for the schematic: netlist @in3otd The circuit you posted still fails with my new code, but in a different way from before, here's the output of my version of qucsator with this circuit: |
|
with the current "my" circuits has other issues also, I think: I've often had the impression that the LTE calculation for some components gives bad results as the timestep gets smaller trying to achieve convergence on a time point, as a results the timestep is reduced even further until it gets so small that the Jacobian becomes singular. The computed LTE and other internal variables can be easily put in the output dataset, so these can be plotted along the usual circuit variables, to see if this is the source of the problem. Will post an example later. |
|
I'm, on 64 bit Linux. I've actually updated my branch to get rid of the assert statements in tswitch, instead I do: My branch can now solve the circuit without hanging at the point of switching, even with 'abrupt' switching type, however I've realised your circuit does actually solve, just quit slowly, on master and when compiled as release (I think I had compiled as debug for the results I posted earlier, but I'm not absolutely sure). However, my branch fails. Output from master: Output from my branch: |
|
My branch does solve the circuit if I replace the diode with the standard diode. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
quick fix for #186 : the issue is related to the fact that for this particular simulation the internal time steps taken should have been submultiples of the user-requested time steps (print steps). In practice after some internal steps the simulator came very close, but not exactly on, to a print time step, probably due to numerical errors and then it attempted to take a very small time step (same order of magnitude as the machine precision) to reach the print step. This very small step likely caused to have companion circuits with extreme values.
Now, in case a step will bring too close to a print step, it will be reduced so that the next step will be larger. Might not work with a lot of corner cases, but is good enough for the #186 circuit.
While this passes all the
qucs-testcircuits, with no appreciable changes in the simulation time, it might not be the best solution, feel free to keep it on hold.And unfortunately it does not solve the transient simulation issues of the other known problematic circuits...