On Saturday 11 January 2014, Felix Salfelder wrote: > in combination, it seems to work best. consider > d_switch_nro.3.ckt. > > vanilla gnucap yields > iterations: op=0, dc=0, tran=18028, fourier=0, total=26977 > transient timesteps: accepted=147, rejected=8802, total=8949 > > with my euler fallback i get > iterations: op=0, dc=0, tran=425, fourier=0, total=573 > transient timesteps: accepted=148, rejected=0, total=148
Without seeing the code, I don't know what that means. You could get a similar apparent fix by changing ITL1 to 99. The rejections in this case are code 17, missed event. SWITCH_BASE::tr_review computed a next event in the past, because there was no event yet the state changed. That is because of a DC convergence failure. This circuit does not have a stable DC operating point so the convergence failure is the correct result. For it to converge would be incorrect. I think this case is an example of where it is appropriate to ignore time==0 in step control, like e_element does, because it gives bogus results. Some of the test files are designed to fail. If you "fix" it, it is necesary to ask if the fix really fixes something or if it just changes the test case so the test no longer tests what it is supposed to test. If your euler fallback introduces a new step based on truncation error (code 6) first, absorbing the non-event state change, that would be the case. It isn't fixed. It's an arbitrary change that makes it so the concept being tested isn't being tested anymore. Another test ... if I add "skip 2" to the tran command, it's down to 4 rejections (code 16, truncation or curve fit error), none at the beginning. Again, it doesn't really fix anything, just changes the test. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
