I believe it should not be necessary. No matter what, the problematic settings are overridden after loading the default and custom configuration files. Sure, you can add a Spice directive in the schematic sheet which enable them, but then you are really shooting your own foot on purpose.
Regards, Orson On 10/13/2016 06:22 PM, Simon Wells wrote: > If the user file is loaded is it worth adding this to the copy version > info or something to make it easy to see and ask someone about a > custom init file if they experience issues with it? > > On Fri, Oct 14, 2016 at 4:13 AM, Maciej Sumiński > <maciej.sumin...@cern.ch> wrote: >> It still loads the original configuration files (when possible) and >> afterwards it checks a few extra locations (relative to the executed >> binary path). This gives a chance to package maintainers to provide a >> proper spinit file. If it fails to find a custom spinit file, but it >> detects a path to codemodel libraries correctly, it will just load them. >> >> Regards, >> Orson >> >> On 10/13/2016 04:08 PM, Wayne Stambaugh wrote: >>> Does this patch override the users configuration or does it just solve >>> the default configuration issue on windows and osx? If so, that's not a >>> good thing. I'm fine if respects the users config. I still stand by my >>> original investigation that this is a package configuration issue, not a >>> broken code issue but if no one is willing to resolve those issues and >>> your patch respects the user config, then I'm OK with it. >>> >>> On 10/13/2016 9:49 AM, Maciej Sumiński wrote: >>>> Finally, I could get back to the issue. If we really focus about the >>>> consequences, the real problem is not that spinit is not processed, but >>>> the codemodel libraries are not loaded. >>>> >>>> Looking at the default spinit file: >>>> - most of the lines are comments >>>> - one causes problems ('set interactive', has to be unset later) >>>> - three others have no special meaning in shared library mode (aliases >>>> and 'set x11lineararcs') >>>> - the only meaningful lines are the ones that load codemodel libraries >>>> >>>> To fix the problem, there is a patch which: >>>> - Allows ngspice to load the default spinit/.spiceinit files (no changes >>>> here). >>>> >>>> - Looks for codemodel files in a few paths relative to eeschema >>>> executable. If a valid path is found, then an ngspice variable __CMPATH >>>> is set. >>>> >>>> - After the default initialization, looks for spiceinit (note it is >>>> spiceinit not .spiceinit) file in a few paths relative to eeschema >>>> executable. If one is found, then it is executed. If we decide to >>>> provide our spiceinit file (see the attachment), then thanks to __CMPATH >>>> variable we can point to the right codemodel directory. >>>> >>>> - If no spiceinit was found, but we know the correct path to codemodels, >>>> then they are simply loaded. >>>> >>>> - Unsets a few variables which may cause simulator hangups. >>>> >>>> Once the patch is committed, codemodels should work out of the box for >>>> the common msys2 builds and nightly Windows installers, even without a >>>> custom spiceinit. If OSX bundles provide codemodel libraries, then there >>>> is a chance it will work for them as well, otherwise we can add another >>>> search path. >>>> >>>> I know it may look like an ugly hack, but sincerely I have no better >>>> idea at the moment. I am going to leave it here for comments for a few >>>> days, if there are no objections, I will commit the changes. >>>> >>>> Regards, >>>> Orson >>>> >>>> On 10/06/2016 05:53 PM, Wayne Stambaugh wrote: >>>>> I have some additional information that may prove useful: >>>>> >>>>> 1) Using relative paths in the spinit file does not work on windows. >>>>> >>>>> 2) Placing a spinit file in the path where the ngspice and libngspice >>>>> binaries reside works with no need to set any environment variables. >>>>> >>>>> Option 2 could be used by the installer. The installer itself would >>>>> have to create the spinit file by substituting the install path for the >>>>> path of the .cm files. I'm not sure if this would work on osx. Maybe >>>>> one of our osx devs could test this. If it does, than that would >>>>> resolve the simulation init issues. >>>>> >>>>> I've attached a simple circuit that demonstrates the issue. When the >>>>> .cm files are not located, the simulation will run with the following >>>>> warnings and cause the output of the op-amp to be an impossibly high 260V: >>>>> >>>>> Error on line 0 : >>>>> a$poly$e.xu1.eos %vd [ xu1.53 xu1.98 ] %vd ( xu1.3 net-_u1-pad1_ ) >>>>> a$poly$e.xu1.eos >>>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eos >>>>> Warning: Model issue on line 0 : >>>>> .model a$poly$e.xu1.eos spice2poly coef = [ 1.7e-3 1 ] ... >>>>> Unknown model type spice2poly - ignored >>>>> Error on line 0 : >>>>> a$poly$e.xu1.eref1 %vd [ vdd 0 0 0 ] %vd ( xu1.98 0 ) a$poly$e.xu1.eref1 >>>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref1 >>>>> Warning: Model issue on line 0 : >>>>> .model a$poly$e.xu1.eref1 spice2poly coef = [ 0 0.5 0.5 ] ... >>>>> Unknown model type spice2poly - ignored >>>>> Error on line 0 : >>>>> a$poly$e.xu1.eref2 %vd [ net-_u1-pad1_ 0 /out 0 ] %vd ( xu1.97 0 ) >>>>> a$poly$e.xu1.eref2 >>>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref2 >>>>> Warning: Model issue on line 0 : >>>>> .model a$poly$e.xu1.eref2 spice2poly coef = [ 0 0.5 0.5 ] ... >>>>> Unknown model type spice2poly - ignored >>>>> Error on line 0 : >>>>> a$poly$e.xu1.eo3 %vd [ xu1.98 xu1.30 ] %vd ( vdd xu1.42 ) a$poly$e.xu1.eo3 >>>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo3 >>>>> Warning: Model issue on line 0 : >>>>> .model a$poly$e.xu1.eo3 spice2poly coef = [ 0.7175 0.5 ] ... >>>>> Unknown model type spice2poly - ignored >>>>> Error on line 0 : >>>>> a$poly$e.xu1.eo4 %vd [ xu1.30 xu1.98 ] %vd ( xu1.44 0 ) a$poly$e.xu1.eo4 >>>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo4 >>>>> Warning: Model issue on line 0 : >>>>> .model a$poly$e.xu1.eo4 spice2poly coef = [ 0.7355 0.5 ] ... >>>>> Unknown model type spice2poly - ignored >>>>> Reducing trtol to 1 for xspice 'A' devices >>>>> Doing analysis at TEMP = 27.000000 and TNOM = 27.000000 >>>>> Warning: vv3: no DC value, transient time 0 value used >>>>> >>>>> Let me know if you have any other questions or comments. >>>>> >>>>> Cheers, >>>>> >>>>> Wayne >>>>> >>>>> On 10/6/2016 10:56 AM, Nick Østergaard wrote: >>>>>> Hi Maciej >>>>>> >>>>>> In the latest nightlies they are now stored in lib/ngspice/ >>>>>> >>>>>> I guess that should equate to a relative path to the executables to >>>>>> ../lib/ngspice/*.cm, given that the exe's are in the bin folder on the >>>>>> same level as lib. >>>>>> >>>>>> So feel free to submit your fix. Also, are there any demos that make >>>>>> use of those cm libs such that it can be tested? >>>>>> >>>>>> Nick >>>>>> >>>>>> 2016-10-05 23:16 GMT+02:00 Maciej Sumiński <maciej.sumin...@cern.ch>: >>>>>>> Hi Nick, >>>>>>> >>>>>>> Are the .cm files included in the Windows nightlies installer? If so, >>>>>>> could you tell me what is the relative path to the directory storing >>>>>>> them? The easiest way to fix the problem is to send a few commands to >>>>>>> ngspice before a simulation starts. >>>>>>> >>>>>>> Regards, >>>>>>> Orson >>>>>>> >>>>>>> On 10/05/2016 10:23 PM, Nick Østergaard wrote: >>>>>>>> Is this really needed? What exactly does the .cm files provide? >>>>>>>> >>>>>>>> When I run the latest nightly I can run the allen key demo without >>>>>>>> problems as far as I can see. Maybe some other simulation modes do >>>>>>>> not work properly? >>>>>>>> >>>>>>>> 2016-09-30 14:37 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>: >>>>>>>>> That would work as a long term solution as well. I was trying to at >>>>>>>>> least prove that it can be done without make changes to the current >>>>>>>>> code. Until a full solution is implemented, users (me) will have an >>>>>>>>> interim solution if they want to use the spice simulator. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Wayne >>>>>>>>> >>>>>>>>> On 9/30/2016 3:40 AM, Maciej Sumiński wrote: >>>>>>>>>> We have also discussed on IRC another possibility, which is loading >>>>>>>>>> the >>>>>>>>>> extensions manually instead of having ngspice process its >>>>>>>>>> initialization >>>>>>>>>> file (spinit). This way we can adjust the paths during runtime. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Orson >>>>>>>>>> >>>>>>>>>> On 09/29/2016 08:51 PM, Wayne Stambaugh wrote: >>>>>>>>>>> After much cursing and many config attempts, I finally have a >>>>>>>>>>> working >>>>>>>>>>> spice simulation solution on windows. I'm guessing similar >>>>>>>>>>> parallels >>>>>>>>>>> can be applied to osx as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Option A: running from a mingw32 or mingw64 terminal. >>>>>>>>>>> >>>>>>>>>>> 1) copy the installed spinit file (by default will be in >>>>>>>>>>> ${MINGW-PACKAGE-PREFIX}/share/ngspice/scripts) to ~/.spiceinit. >>>>>>>>>>> 2) change the msys2 paths (/mingw##) in ~/.spiceinit to absolute >>>>>>>>>>> windows >>>>>>>>>>> paths with / not \ (in my case C:/msys64/mingw##). >>>>>>>>>>> 3) Launch kicad.exe from the terminal. >>>>>>>>>>> >>>>>>>>>>> I realize this is not very elegant and will only work with either >>>>>>>>>>> the 64 >>>>>>>>>>> or 32 bit mingw (not both without editing .spiceinit) but it works >>>>>>>>>>> and >>>>>>>>>>> is handy for mingw users. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Option B: configuring windows and run kicad from a shortcut. >>>>>>>>>>> >>>>>>>>>>> 1) locate the installed spinit file >>>>>>>>>>> ($INSTALL_PATH/share/ngspice/scripts) and change the msys2 paths >>>>>>>>>>> (/mingw##) to absolute windows paths with / not \ (in my case >>>>>>>>>>> C:/msys64/mingw##). >>>>>>>>>>> 2) Run kicad, open the config paths dialog, and add an environment >>>>>>>>>>> variable SPICE_LIB_DIR with path to the spinit file minus the last >>>>>>>>>>> "scripts" path ($INSTALL_PATH/share/ngspice). >>>>>>>>>>> >>>>>>>>>>> I also tried copying the .spiceinit file from option A to >>>>>>>>>>> %USERPROFILE% >>>>>>>>>>> but that did not work when launching kicad from a shortcut. >>>>>>>>>>> >>>>>>>>>>> Option B a cleaner solution but still requires some configuration >>>>>>>>>>> by the >>>>>>>>>>> user. This is going to be an interesting problem to solve for our >>>>>>>>>>> package devs. We need to figure out a way to generate or modify the >>>>>>>>>>> spinit file base on where it gets installed by the installer on >>>>>>>>>>> platforms where this is relevant. We will also either have to set >>>>>>>>>>> an >>>>>>>>>>> the SPICE_LIB_DIR environment variable or teach ngspice how to find >>>>>>>>>>> the >>>>>>>>>>> correct spinit file at run time. >>>>>>>>>>> >>>>>>>>>>> At least now windows users have a way to have the same functional >>>>>>>>>>> spice >>>>>>>>>>> simulation as linux users. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Wayne >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>> >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp