Pruning by Array>we simply haven't coded for them. nThat's the same, if you hardcoded a narrow list of cards, that means you have banned all other cards. You don't need to code a card list first of all. CUDA code works with any card supporting the compiled version. AFAIK, driver should report the supported version#. If it was compiled for Turing TU architecture with CUDA 7.5 - it should and will work on ANY Turing-based card and on many others, depending on nVidia code compatibility list.n>certain features and board architecturenAgain - exact board architecture is a top secret protected by nVidia with machine guns and ninjas. All the developers have on hands are standard APIs, and unofficial hacks that you can not use legally.nn>library fudge to let the GeForce card work,nI want to know myself. In the post you deleted, I was speculating about reasons. It may be a limited up-compatibility for older Geforce cards. The latter is a tricky thing, as I know it (I may be mistaken here)nStarting from Kepler, nvidia boards have good up-compatibility in SDK (compiler). i.e. a code compiled for CUDA up to 7.5 will work on Kepler cards, that natively support version 3.5. Starting from CUDA SDK 11 (CUDA 8.6) Kepler was removed from the up-compatibility list. But it is not the case with HFSS 2020, which just could not use CUDA 8.6 released later. Therefore any board with Kepler and newer architectures should be compatible with HFSS. At least every Quadro board, which we see.nBut compatibility policies of nVidia are tricky. It may happen, that the code compiled with SDK10 may opt-out Kepler Geforce class device ids.nThat does not explain why Maxwell Pascal, Volta and native Turing class Geforce boards do not work in HFSS 2020. Personally, I could not find a pascal based GTX card around, but seems like other users find them not working with HFSS.nI would like to clarify this topic.n