Relative path in Nutmeg script about qucs_s HOT 13 CLOSED

Nutmeg script doesn't support paths relative to schematic directory. The paths are resolved relative to simulator execution directory. Usually $HOME/.qucs/spice4qucs. It is changed since #658 Use the absolute paths instead.

from qucs_s.

This is really a show stopper and brings a lot of trouble into project organization.
I just started to include qucs-s projects into my example folder qucs-s ekv3 example. Without this qucs-s capability the user have to edit the local .spiceinit file. This is tedious and error-prone and load time will explode because ngspice must load all models for each simple simulation.
See qucs-s usage

from qucs_s.

Can we allow relative path in nutmeg block on schematic and convert path to absolute while creating ngspice netlist?

from qucs_s.

Maybe it is a solution: ngspice works with both: the relative path as shown above and the absolute path (in may case): ~/Projects/spice/Verilog-A/VA-Models/osdilibs/ekv3.osdi.

Can't understand why qucs-s didn't work - the generated netlist.cir with relative path simulates with ngspice on cmdline in the schematics folder ~/Projects/spice/Verilog-A/VA-Models/examples/ekv/qucs-s_prj/ very well.

from qucs_s.

To me, for "portability" one should put every file/model needed for a project into the same project folder.

Countless problems trying to recreate others work due to missing files or long file paths only relevant on the authors PC has only reinforced this belief. This issue is common to Qucs, Qucs-S, QucsStudio, LTspice and every CAD program I have ever used.

Let's not get into Windows versus Linux issues...

@dwarning

Is there a special version of ngspice needed for this project? I'm getting "Unknown model type ekv3_rf " errors.

from qucs_s.

@tomhajjar :
ngspice >= 41
You have to generate the osdi files accordingly VA-Models and then load the ekv3.osdi lib with Nutmeg script and absolute path or make a copy into the prj folder, because you like it.
Let me know if problems rise-up.

from qucs_s.

I'm confused. This schematic and most of the others in this project don't contain the Nutmeg script to load ekv3.osdi. Do only the schematics with the Nutmeg script work?

I assumed this project was like EKV3_xyce_prj...

EKV3_xyce_prj.zip

from qucs_s.

Yes - this is the problem: Thread name is "Relative path in Nutmeg script". It is not functional - qucs-s disturb the input path of ngspice for the osdi lib. You can give the absolute path in Nutmeg script, make a copy of the osdi file as said or wait for other solutions.

from qucs_s.

Generously Holger has implemented in ngspice developer branch the request to the environment variable NGSPICE_OSDI_DIR which allows pre_osdi commands without path in qucs-s schematics Nutmeg script. This will released in next ngspice release 43.
In case that relative paths are not available in qucs-s another workaround would be to implement a configuration entry like the simulator executable pathes in simulators setting menu for osdi library files.

from qucs_s.

Wondering why XYCE natively supports EKV3, MOS Level 301 but ngspice doesn't natively support EKV2.4, MOS Level 44 or EKV3, MOS Level 301?

from qucs_s.

I can guess about EKV - it was closed source until recent times

from qucs_s.

Can we allow relative path in nutmeg block on schematic and convert path to absolute while creating ngspice netlist?

This could be done in a two ways, but both has many disadvantages.

• Implement a parser of Nutmeg scripts that will disassemble and reassemble the script and substitute the absolute paths. It is a complicated task and this solution may introduce many new bugs.
• Change the working directory to schematic directory. This has the following disadvantage. The simulator will not follow the XDG specification to store temporary data. The caches cannot be cleared using OS tools. See #145

The Nutmeg script is a feature for advanced user and should be avoided in a normal schematics. So, I am inclined to keep the things as is because of mentioned above disadvantages.

The best solution will be to implement an OSDI library block that will work similar to existing .LIB block. The file devices can resolve the relative paths after #640

from qucs_s.

I am moving this issue to Discussion/General

from qucs_s.