LTspice equivalent for Linux - Page 1
Forum section: electronics / general

author: bd139
author_rank: Super Contributor
timestamp: November 15, 2020, 12:18:16 pm
content: So I'm fairly well embedded in the LTspice ecosystem. But I'm trying to do a slow and steady migration to Linux. One of the key gaps is a native simulation package of this calibre. Does anyone have any suggestions in this space? Particularly something which is at least semi-aware of S-parameter modelling and has a UI which is not like attacking your testicles with a cheese grater.I really don't want to run LTspice in Wine if I can help it, but that is the current exit plan.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 15, 2020, 02:46:33 pm
content: A good meal always goes down better with a glass of Wine!Or, run Win 7 in a Virtual Box? - The pinnacle of Microsoft achievement, after all - worth keeping around for all the stuff that won't run natively?That's the kind of direction I think I'm headed, anyway. Had enough of the direction the IT industry is going with requiring us to subscribe to everything up to and including the weather...

author: PKTKS
author_rank: Super Contributor
timestamp: November 15, 2020, 03:54:29 pm
content: Quote from: blueskull on November 15, 2020, 03:02:30 pmI don't even know the distro you are using but I can tellyou based solely on my long trial and error experienceof setting up a TOTALLY FUNCTIONAL system is:- avoid having a 32 bit system mixed with 64 bit one.this is a total mess and several strange things will happen.- compile a clean 32bit system and properly installed winebase (e.g. the base of wine lies on what the applicationthinks is "windows" itself (registry and hidden services)- your symptoms sound very much alike just GPU accel problemsand they are hard to solve. Different toolkits present differentsymptoms very much related to the compilation options of the serverdriver... being AMD or NVIDIA or Intel - they all present issues...Total lack of vendor support for GPU code base.Menus improperly rendered. Lists improperly rendered... etc..In my opinion WINE runs much much better being totally 32bitBeing even faster... Although running under a 64bit clean compileshould be fine... unless you mess 32 with 64 code base.You definitely need to review your distro of choice..or compile yourself a small proper alternative..After all it is just to run wine...I assure you: After dealing and finding these gotchasand solving them myself .. WINE RUNS 100% OK in a wide rangeof apps. LTSpice is one of them.None of these symptoms appears under a proper compiled systemAlthough some recent GPUs will need proper options to avoid thatPaul

author: PKTKS
author_rank: Super Contributor
timestamp: November 15, 2020, 04:06:42 pm
content: Quote from: blueskull on November 15, 2020, 04:02:02 pmDon't think that those docker things would be of any better resultChances are it may be worse...In your case I would set up a small cheap side systembased on a cheap 128 SSD totally 32bit withoutany fancy GPU closed driver...You don't need that for plain WINE..Cheap really cheap 32 bit system without fancy GPUshould give you better results. A matter of 30 to 60 minutesto setup in a box or bench holder.being there some timesPaul

author: paul@yahrprobert.com
author_rank: Regular Contributor
timestamp: November 15, 2020, 04:34:37 pm
content: I've been running ngspice on Linux for years. You can avoid its GUI by using available packages for Octave or for Python (my favorite). Once you have its output in one of those languages then its easy to generate your S matrices, do plots, etc.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: November 16, 2020, 10:42:06 am
content: You can draw schematics in KiCad and use ngSpice for simulation.http://ngspice.sourceforge.net/ngspice-eeschema.htmlngSpice is also being actively maintained, with 2 updates in 2018, 1019 and 2020:http://ngspice.sourceforge.net/news.htmlI have done some simple simulations this way and it seems to work.The biggest hurdle for ngSpice is probably that a lot of spice models are not compatible with it for various reasons. Encrypted models are not supported at all as far as I know, and other spice models seem to depend on extensions that are limited to a specific spice package.

author: asmi
author_rank: Super Contributor
timestamp: November 17, 2020, 03:12:58 pm
content: Quote from: PKTKS on November 15, 2020, 03:54:29 pmThere is much simpler way - just scrap all that Linux nonsense and run WindowsProblem solved!No googling around for solutions, no compiling anything, no creating over 9000 different installations of OS, each one of which will have something that doesn't work. Simple, cheap, reliable!

author: bd139
author_rank: Super Contributor
timestamp: November 17, 2020, 03:39:17 pm
content: Not helpful.Thanks everyone for theconstructivereplies so far. I'm going to spend some time at the weekend evaluating them. Much appreciated

author: PKTKS
author_rank: Super Contributor
timestamp: November 17, 2020, 05:04:58 pm
content: Quote from: asmi on November 17, 2020, 03:12:58 pmI understand that point of view and I have dealt withsuch arguments for over decades...The issue is not about running windows...The BIG ISSUE is the BUZ MODEL THAT COMES WITH MS...and "partners" they put in their bandwagon.Their platform is totally INSECURE and they had put anenormous financial prejudice on all users imposingtheir exclusive use of hardware resourcesand making that obsolete at will (when their cash demands)So to keep a sane system secure and running appletsthey no longer want or allow others to use... one should adapt.Essentially there is just a single other company that pretendsto "sell computer" but instead ... oblige the so called user tobe bound to a nasty landlord contract of non ownership of their hardwareThose both contracts today (MS and Apple) actually are fakendoors to "rent services" using a FULL PAID HARDWARE whichthey do not provide control to end user..in short words those systems take ownership of the hardware we pay forHave a close look to their licenses and put thatseriously in a proper timeline budget..They assume no responsibility they give users noaccess or control to their paid hardware (drivers are closed source)and they withdraw support whenever it is convenient.IMHO? both must go to hell with their licenses and crappy products.THE HARDWARE I HAVE PAID FOR IS NOT THEIR PROPERTY.simple as thatPaul

author: langwadt
author_rank: Super Contributor
timestamp: November 17, 2020, 05:11:05 pm
content: Quote from: blueskull on November 15, 2020, 03:02:30 pmonly problem I have is figuring out how to use alt/ctrl for power and average

author: bd139
author_rank: Super Contributor
timestamp: November 17, 2020, 05:20:44 pm
content: Can we not turn this into a Linux vs Windows vs Apple thread please

author: PKTKS
author_rank: Super Contributor
timestamp: November 17, 2020, 05:28:10 pm
content: Quote from: bd139 on November 17, 2020, 05:20:44 pmWell kinda hard ... given that the whole pointboils down to using WINE instead of the full native one..The other way around also applies.. the whole pointis why using WINE ....It mattersand each argument should be carefully taken by each oneconsidering such moves..They have time and money implications..it mattersPaul

author: bd139
author_rank: Super Contributor
timestamp: November 17, 2020, 05:38:12 pm
content: Working on assumptions is bad. Windows applications are the compromise for me. My entire day is sitting in front of hundreds of Linux machines and writing software on Linux. My objective is to make less compromises thus the debate is about equivalents not changing the compromise.My interest in simulation and LTspice is purely for leisure (these days) or maybe commercial purposes in the future.

author: PKTKS
author_rank: Super Contributor
timestamp: November 17, 2020, 05:42:48 pm
content: So you have answered your question.If you run Linux without a single miss of MSor other OS...Think no further.. spare a small partition of small systemto check how damn good a 32 bit clean distro wellcompiled and installed will perform for you goals..Think no further.

author: bd139
author_rank: Super Contributor
timestamp: November 17, 2020, 06:35:27 pm
content: Erm I’m all 64-bit everything unless I’ve misunderstood you somewhere.

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 11:29:38 am
content: Quote from: bd139 on November 17, 2020, 06:35:27 pmProbably you did.It is not about you want or not - to be all 64 bit...Your applets (the ones you intend to run under WINE)is what matters.So far I am not able to see any 64 installation outperforma clean well done 32 bit one.. and unless the apps youintend to run are all 64 bit .. your chances of goodresults lies on the proper matching of a 32 bit clean system32 bit systems are smaller and faster than a similar 64 bit oneand unless you must run a 64 bit applet you should matchyour 32 bits applets under a proper 32 bit WINE system.If all you have is 64 bit applets then you go 64 bit WINE.Mixing things is the recipe of strange issues...no magic solution apply.So far 32 bits are still faster.. and they have less bugsas they are also older ..Trends are being pushed by force to *yet again*obsolete a whole generation of hardware... wastelands ...so far I have not seen any better result on 64 bit systemsover a 32 bit installation... way different when thingsevolved from 16 to 32..Paul

author: SilverSolder
author_rank: Super Contributor
timestamp: November 18, 2020, 02:04:11 pm
content: Quote from: PKTKS on November 18, 2020, 11:29:38 amOne benefit of the 64 bit version of Excel is that it can load a lot more rows of data than the 32 bit version. 64 bit version of Photoshop works with larger images. And so on... - I don't think 64 bit was a complete waste of time, but definitely overkill for many things. I do use 32 bit Windows in virtual machines because they are generally more efficient if you don't expect to need to deal with massive datasets.Not sure if LTSpice is able to use the capabilities of the 64 bit architecture at all?

author: bd139
author_rank: Super Contributor
timestamp: November 18, 2020, 02:07:28 pm
content: My LTspice is compiled for 64-bit. When I did a complex simulation recently of a discrete step generator with a small time step it ate 7Gb of memory which would have been interesting with 32-bit architectures.

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 02:44:49 pm
content: Quote from: SilverSolder on November 18, 2020, 02:04:11 pmYES indeed ... memory mapping is the single advantageeasily spotted on 64 bit systems.Databases... games (video memory mappings)...massive data arrays ... (as you said)and also some direct memory images (large system images)able to boot on a single image file...apart from those typical large memory maps 64 bit systemsdouble the data and addr bus being also slower in performance..But they will certainly find a way when next gen stuffmoves from Giga to all Tera bytes...but not exactly "now" ...Paul

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 02:56:47 pm
content: Quote from: bd139 on November 18, 2020, 02:07:28 pmOn *NIX platforms under x86 this was never an issueA proper compiled kernel for 32bit x86 allowsdirect mapping of 64G.. on any kind of x86 compatible hardwareProper compilation option must be enable with other relevantchoices that goes under the same kind of setup...I do similar simulations with data logging as well.It goes above 2G of disk space while 8G of memory was never exceeded.Figure shows relevant option to enable 64G memory map on 32 bitPaul

author: SilverSolder
author_rank: Super Contributor
timestamp: November 18, 2020, 03:12:23 pm
content: Quote from: PKTKS on November 18, 2020, 02:56:47 pmInteresting. Wouldn't the application have to be coded to support the big 64Gb model too?

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 03:24:10 pm
content: Quote from: SilverSolder on November 18, 2020, 03:12:23 pmI am not aware of such constraint ...What really maters is that the underlying OS manages thememory addr. pool unattended from what applet requestchunks of memory...Since the advent of multitasking combined with multi-threadedapps the burden relies on the OS limit. As such the swap is anintegral part of the pool.You don't even need 32G installed...As long as you have a swap enabled the OS triggerspage faults to swap in and out whatever page on the poolInteresting side note is the PATHETIC recent solution (obviouslyfrom the systemd goonies) trying to avoid modern SSD and NVMswearing out due to excessive swapping faults...They use the same memory which actually is missing.. go figure..I have been using another approach much much betterto solve this on my SSDs..... trivial trick known for decades...awk -- '/swap/ && ($1 !~ /#/) { system("mkswap -v1 "$1) }' /etc/fstabeach and every single boot a whole new swap file is indeed createdon the SSD or NVM which eliminates the wear out...Go figure what those idiot goonies are thinking with that systemd...absolute EXOTIC IN MEMORY SWAP..Paul

author: langwadt
author_rank: Super Contributor
timestamp: November 18, 2020, 04:52:46 pm
content: Quote from: PKTKS on November 18, 2020, 02:56:47 pmbut isn't each process still limited to 2-3GB ?

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 05:03:28 pm
content: Quote from: langwadt on November 18, 2020, 04:52:46 pmhmmm the term "process" actually implies the limitsof the shell under execution or under the supervisorwhich started the service itself...I would not answer that cases instead answering whatfirst comes to me when using application memory thresholds ...When internal data types are defined (integers, longs, doubles...)they actually play the role of limiting the maximum possibleaddr mapping or data maximum in the applet itself.This is not the case itself for memory pointers itselfas they are defined in the kernel headings and willbe compiled cf. you compiler options. One possibleoption is using "large pointers" and data typesproperly suited to your kernel (heading undercompilation) - usually that thing is a bunch of macros...Once compiled your pointers will have a "long or large"capable memory mapping but that itself will notensure your data types (integers and doubles...) willproperly match things - in particular when casts are used.Very difficult to say and although I am making the commentsabove I WOULD SAY THAT IT *DEPENDS* ... and depends ofa bunch of IF THIS THAN THAT IF NOT other these... or that...But FACT IS : your x86 32 bit kernel has availablea FLAT 64G memory mapping space...Not simple to answer under generic termsPaul

author: bd139
author_rank: Super Contributor
timestamp: November 18, 2020, 05:13:55 pm
content: No the kernel has 4Gb segments and PAE to manage which is massive overhead as it's a massive hack job rather than a real solution. Sun were pushing 64-bit CPUs with hardware contexts out a lot earlier because they saw this coming. Intel bodged PAE on to save face and left it for AMD to do the 64-bit intel.As for the 3Gb process size, it's arbitrary safety and OS dependent but mostly memory mapped IO lives in it. You can't address more than 4Gb of RAM because pointers are only 32-bits on 32-bit architectures.Also full stop 64-bit is a hell of a lot faster, simply because of the bus width. Pulling stuff up into cache and squirting it out takes less time. Even on day one when we got our AMD64 machines we were looking at a 30% gain. Now I have a couple of processes running in production which have 1TiB+ heap usage on machines with 1.5TiB of RAM.Let's just leave 32-bit in the bin where it belongs. It's not even part of this discussion...

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 05:22:28 pm
content: Yes PAE also plays essential role on x86 and shouldbe compiled in ...For what concerns 32 bit in my case I will say that:- my machines are all using 64 bit CPUs ( FX, icores i5, i7)- But 99.99% of my legacy apps are 32 bits... I am a veteran- So I am required to tun those 32 bit legacy apps on 32 bit WINE- I have crafted some 64 bit for test.. they do not outperform the legacy- so I kept the system where WINE matters to run as 32 bit,- I ensure you that this solution does not belong to the bin..- 99.99% legacy 32 bits apps run perfectly fine with no issueswhatsoever to mentionAnd concerning those limits I do have simulations going above 4Gbut below 8G thresholds.. so far never found a single glitch ...But my system is hand crafted bottom to top...Mileage will vary in each casePaul

author: bd139
author_rank: Super Contributor
timestamp: November 18, 2020, 05:24:56 pm
content: Yes but this one is my problem and none of that is related to it

author: PKTKS
author_rank: Super Contributor
timestamp: November 18, 2020, 05:28:25 pm
content: Quote from: bd139 on November 18, 2020, 05:24:56 pmYour case seems to me simpler..You already dumped 32 bit in favor of 64 bit only...Think no further.. setup a small dedicated clean 64 bit WINE system..Far simpler than dealing with those legacy 32 bits apps as in my case...I drag the stuff along for necessity .. say what.. doing thissince early 80s.. believe that I run a CP/M emulator as wellin the same system of WINE itselfPaul

author: guenthert
author_rank: Frequent Contributor
timestamp: November 18, 2020, 06:12:52 pm
content: I'm generally skeptic of WINE, my experience with it has been quite mixed. More so, if an application worked (more or less) in a given version of WINE, it didn't necessarily in the next. The Linux kernel community is very strict about dealing with regressions at high priority, ensuring improving quality; the WINE community seems to have other priorities. Said that, things seem to have improved since WINE 1.0 and the author of LTspice, while sadly not offering a native Linux application, puts some effort into ensuring that it runs in current versions of WINE. Works for me.

author: Jay_Diddy_B
author_rank: Super Contributor
timestamp: November 18, 2020, 06:17:41 pm
content: Hi,I don't know anything about Linux or WINE, but you could try running LTspice IV instead of the latest version XVII.XVII was written for Windows 10IV was written for all the earlier versions.There are bigger differences in the way it interacts with the operating system.Link:https://www.analog.com/en/design-center/design-tools-and-calculators/ltspice-simulator.htmlJay_Diddy_B

author: Warhawk
author_rank: Frequent Contributor
timestamp: November 24, 2020, 10:27:54 am
content: Just a comment on Wine - My experience is similar to blueskull's. LTspice in wine sort of works but I have difficulties to reach some dialogs that appear only after mouseover, etc.I tried various versions and then started using it in Windows again. Honestly, I would buy an older windows 7 OEM license key from eBay, created a virtual machine that never expiresand use it from there. I realize that this is not what you likely want to hear but there are still many engineering tools that have no linux alternative.If you think I am not helping you can tryhttps://ra3xdh.github.io/A friend of mine uses that. If you accept virtualized windows you can even use the combo LTspice + pSpice for TI which covers most of the available simulation models.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 24, 2020, 03:52:29 pm
content: Quote from: Jay_Diddy_B on November 18, 2020, 06:17:41 pmXVII works on Win 7 with no issues here?

author: PKTKS
author_rank: Super Contributor
timestamp: November 24, 2020, 04:37:24 pm
content: Quote from: Warhawk on November 24, 2020, 10:27:54 amYou won't be exception to the issues I had pointed..If you try to run a code based mostly on 32b toolkitunder the WINE API compiled as 64bit... you will findproblems like mentioned ...Improperly rendered menus lists and dialogs ..fonts may fail as well.. these problems alsoplague some native toolkits like GTK or QTMostly related to the GPU driver compilationthe callbacks will present some issues.Nevertheless I assure you that a 32 bit nativeWINE running under a proper 32 bit kernelworks almost perfectly without those symptomsReason why I still run and sometimes even prefera native 32 bit system... Although in time that will changePaul

author: CDN_Torsten
author_rank: Regular Contributor
timestamp: November 26, 2020, 01:17:41 pm
content: ...just wanted to chime in that I have seen no issues running LTspice in Linux with Wine 5.0.3.(I realize that the OP is looking for an alternative native app...haven't found one as simple as LTspice)

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 01:25:52 pm
content: Thanks for the on topic report - much appreciated