How to update SpiceOpamp library?

[csrabak]

Present SpiceOpamp library has some ICs but lacks some which already are available in qucsator, like TL081/TL082.

What is the proposed workflow for users (I surmise that work has been done in this realm by the dev team) to include models still not available in the present version of Qucs-S?

[tomhajjar]

Nothing stopping you from making your own OpAmp library and keeping it in user_lib. You can also make sub-circuits and keep them in the project folder. I've made many subcircuits.

The pitfalls of making compatible devices is the Manufacturers Spice model may not be compatible with ngspice even with "set ngbehavior=ltpsa". You then have to ask Vadim or the guys at ngspice for assistance.

Manufacturers Spice models will never be 100% accurate and there are many ways to model a device. OpAmp Models can be "Component level", "Transient", "Behavioral" or be based on macro models developed in the 1970s like Boyles model.

OpAmp Spice Models_prj.zip

[csrabak]

I agree "nothing stopping..." part, my questioning stems exactly from your reasoning, which concludes: « You then have to ask ... ».

On the other hand, we've a lot of "group knowledge" that we could reuse, as in my specific example, an opamp already has it model available for qucsator (whose format is not compatible w/Spice) but not in SpiceOpAmp library.

Should I understand the workflow is to create a user library and if/when the part becomes part of newer libraries of future releases reform the projects already done?

[tomhajjar]

New libraries and devices are always welcome. That being said there is no guarantee any devices you create will become one of the built in devices/libraries but they will still be useful for you. The Libraries will never have hundreds of manufacturers devices. The Libraries are to give users enough components they can simulate almost any circuit.

Getting back to OpAmps, when there are 5 different models from 3 different manufacturers/sources for the same device which one should be chosen? The obvious choice is the model that works "best" in your specific circuit. A model that "works" in one circuit may not work in another. Models have limitations that limit their accuracy for certain conditions. For example many models don't have provisions for modeling Vcc/Vee currents. If your circuit uses Vcc/Vee currents in a biasing scheme like the amp below, a model that doesn't reflect these currents won't work.

It is up to the User to decide what parameters a model needs to accurately reflect. No one model for say a TL071 will work in every simulation. You may need 5 different models of TL071 and choose one based on your circuit.

[csrabak]

I see this comment as the proverbial double-edge sword.

I understand that the focus of the project is in the enhancement of the Qucs-S and users will have to check the usefulness of the models.

Supporting more than one simulator engine really complicates a lot the creation of a curated collection of models.

[ra3xdh]

You can find a guide how to make a library here: https://habr.com/ru/articles/805963/ There is no English version, but the Google translate may help. You have to create a project containing new devices and then create library. It will be placed in the $HOME/QucsWorksapce/user_lib There is no way to merge two libraries automatically. You have to open files with text editor, copy-paste new library content and edit subcircuits names to match the library name. If you are making a new libraries please submit the new library and source project to me. I will upload it to the repository.