Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

Hi Nick,

Thank you for testing the patch. I have just committed it to the master
branch.

Regards,
Orson

On 10/17/2016 08:59 AM, Nick Østergaard wrote:
> Hi Maciej
> 
> It looks like your patchs works for the windows build. At least I
> don't get the errors that Wayne mentioned and I see a square wave with
> the patch applied. So committing that will essentially fix the
> nightlies.
> 
> Additionally I noticed a small bug with the plot view. When resizing
> the window in any size, the y-axis will increase in value, which will
> make the graph smaller. This does not happen when maximizing the
> window.
> 
> 2016-10-14 15:30 GMT+02:00 Maciej Sumiński :
>> Yes, I override three Spice variables:
>>
>> - unset interactive
>> Disable interactive mode. You should expect hang ups when the option is
>> enabled and you get an error during parameter evaluation (it asks you
>> whether you want to continue, but there is no way to confirm).
>>
>> - set noaskquit
>> Do not ask the user whether to quit the simulation.
>>
>> - set nomoremode
>> Disables stopping output until a return key is pressed whenever there is
>> a large number of lines to be displayed.
>>
>> I hope these three settings are reasonable. I override them as they have
>> no meaning when ngspice is used as a shared library, but in a different
>> configuration they cause troubles. Note that I do not put them into any
>> config files, these options are set only when simulation is run in KiCad.
>>
>> Regards,
>> Orson
>>
>> On 10/14/2016 03:12 PM, Wayne Stambaugh wrote:
>>> I didn't look that carefully but are you overriding any settings from
>>> the user config?  I would prefer that you didn't so I don't spend time
>>> trying to figure out why my config settings are not being respected.
>>>
>>> On 10/13/2016 11:13 AM, Maciej Sumiński 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 

Re: [Kicad-developers] Spice simulation on windows.

[Nick Østergaard]

Hi Maciej

It looks like your patchs works for the windows build. At least I
don't get the errors that Wayne mentioned and I see a square wave with
the patch applied. So committing that will essentially fix the
nightlies.

Additionally I noticed a small bug with the plot view. When resizing
the window in any size, the y-axis will increase in value, which will
make the graph smaller. This does not happen when maximizing the
window.

2016-10-14 15:30 GMT+02:00 Maciej Sumiński :
> Yes, I override three Spice variables:
>
> - unset interactive
> Disable interactive mode. You should expect hang ups when the option is
> enabled and you get an error during parameter evaluation (it asks you
> whether you want to continue, but there is no way to confirm).
>
> - set noaskquit
> Do not ask the user whether to quit the simulation.
>
> - set nomoremode
> Disables stopping output until a return key is pressed whenever there is
> a large number of lines to be displayed.
>
> I hope these three settings are reasonable. I override them as they have
> no meaning when ngspice is used as a shared library, but in a different
> configuration they cause troubles. Note that I do not put them into any
> config files, these options are set only when simulation is run in KiCad.
>
> Regards,
> Orson
>
> On 10/14/2016 03:12 PM, Wayne Stambaugh wrote:
>> I didn't look that carefully but are you overriding any settings from
>> the user config?  I would prefer that you didn't so I don't spend time
>> trying to figure out why my config settings are not being respected.
>>
>> On 10/13/2016 11:13 AM, Maciej Sumiński 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 

Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

Yes, I override three Spice variables:

- unset interactive
Disable interactive mode. You should expect hang ups when the option is
enabled and you get an error during parameter evaluation (it asks you
whether you want to continue, but there is no way to confirm).

- set noaskquit
Do not ask the user whether to quit the simulation.

- set nomoremode
Disables stopping output until a return key is pressed whenever there is
a large number of lines to be displayed.

I hope these three settings are reasonable. I override them as they have
no meaning when ngspice is used as a shared library, but in a different
configuration they cause troubles. Note that I do not put them into any
config files, these options are set only when simulation is run in KiCad.

Regards,
Orson

On 10/14/2016 03:12 PM, Wayne Stambaugh wrote:
> I didn't look that carefully but are you overriding any settings from
> the user config?  I would prefer that you didn't so I don't spend time
> trying to figure out why my config settings are not being respected.
> 
> On 10/13/2016 11:13 AM, Maciej Sumiński 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 

Re: [Kicad-developers] Spice simulation on windows.

[Wayne Stambaugh]

I didn't look that carefully but are you overriding any settings from
the user config?  I would prefer that you didn't so I don't spend time
trying to figure out why my config settings are not being respected.

On 10/13/2016 11:13 AM, Maciej Sumiński 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 ] ...
 

Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

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
>  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 

Re: [Kicad-developers] Spice simulation on windows.

[Simon Wells]

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
 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 ] 

Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

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 

Re: [Kicad-developers] Spice simulation on windows.

[Wayne Stambaugh]

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.00 and TNOM = 27.00
>> Warning: vv3: no DC value, transient time 0 value used
>>
>> Let me know if you have any other questions 

Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

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.00 and TNOM = 27.00
> 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 :
>>> Hi Nick,
>>>
>>> Are the .cm files included in 

Re: [Kicad-developers] Spice simulation on windows.

[Wayne Stambaugh]

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.00 and TNOM = 27.00
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 :
>> 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 :
 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 

Re: [Kicad-developers] Spice simulation on windows.

[Wayne Stambaugh]

@Nick,

They are installed in ${CMAKE_INSTALL_PREFIX}/lib/ngspice on msys2
builds so your assumption is correct.  The problem is that the spinit
file generated at config time will no be correct.  We may have to add
some script fu to the ngspice-git pkgbuild file to correct the paths in
the spinit file.  Msys paths /mingw32/lib/ngspice/*.cm have no meaning
for windows apps.  The other vexing issue is how to get libngspice to
find the spinit file.  It too is hard coded with an msys2 path during
config and it will not be the path where the install places the spinit
file.  I don't know if this code fixed with some script fu as well.  We
could try relative paths and see if that works.  In any case, I don't
think the solution is going to be simple.

Cheers,

Wayne

On 10/5/2016 5:20 PM, Nick Østergaard wrote:
> They are not currently copied, I have only copied the ngspice dll
> itself. I suspect they should be installed to the
> installdir/lib/ngspice/.
> 
> 2016-10-05 23:16 GMT+02:00 Maciej Sumiński :
>> 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 :
 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 : 

Re: [Kicad-developers] Spice simulation on windows.

[Nick Østergaard]

They are not currently copied, I have only copied the ngspice dll
itself. I suspect they should be installed to the
installdir/lib/ngspice/.

2016-10-05 23:16 GMT+02:00 Maciej Sumiński :
> 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 :
>>> 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

Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

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 :
>> 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



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

Re: [Kicad-developers] Spice simulation on windows.

[Wayne Stambaugh]

The .cm files are required to use things like polynomial support used in
behavioral models.  This was what was giving me fits on windows.  I had
to modify the spinit file to point to the correct path for the .cm files
and set the SPICE_INIT_DIR environment variable to point to the spinit
file because the windows paths were not getting converted when using
msys2 as the build environment.  Spice support is definitely rough
around the edges but once you get everything configured correctly it
works fine.  Of course everything works just fine on linux but that is
to be expected.

On 10/5/2016 4: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 :
>> 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

Re: [Kicad-developers] Spice simulation on windows.

[Nick Østergaard]

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 :
> 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

Re: [Kicad-developers] Spice simulation on windows.

[Wayne Stambaugh]

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

Re: [Kicad-developers] Spice simulation on windows.

[Maciej Sumiński]

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
> 




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