Ansys, COMSOL e Abaqus: simulazione CAE

Quanto dura una simulazione in Ansys, COMSOL o Abaqus lo decidono tre cose prima del numero di core: quanti core la licenza ti lascia usare, se il modello sta tutto in RAM e quanto in fretta la RAM passa i dati al processore. La scheda video accelera solo alcuni solver. Spiegato con i numeri dei produttori e dei test.

Lanci la simulazione alle sette di sera. Il modello è quello grosso, con il contatto e la plasticità, e il responsabile aspetta il risultato per la riunione di domani. La mattina trovi una di queste due cose. Il job, cioè la simulazione che hai lanciato, è ancora lì al 40%, con il disco che lavora di continuo. Oppure si è fermato alle tre di notte per memoria insufficiente, o per disco pieno. In tutti e due i casi la macchina non è rotta: il modello non ci stava, e nessuna workstation per la simulazione CAE scelta solo sul numero di core avrebbe cambiato la notte.

L'istinto di chi lavora con Ansys, COMSOL o Abaqus, davanti a una simulazione lenta, dice «mi serve una macchina più veloce», e traduce più veloce con più core. I numeri dei produttori dicono un'altra cosa. Nei benchmark pubblicati da Ansys per il solver diretto di Mechanical, su una workstation a 64 core, da 32 a 56 core il guadagno è del 12% circa. COMSOL scrive che in generale sei o otto core sono una buona scelta per tutti gli usi, anche se più core possono essere meglio. Dassault conta i core in token, con una tabella che cresce molto meno dei core. Raddoppiare i core non dimezza il tempo della simulazione, perché quel tempo lo decidono prima tre vincoli che nella scheda tecnica non si vedono. Vale per il solver diretto, quello delle non linearità; per il CFD e per i solver espliciti i core contano di più, ma solo se la memoria riesce ad alimentarli. Qui sotto i tre vincoli con i numeri delle guide ufficiali, quando la scheda video aiuta, e le domande che un esperto fa prima di dimensionare la macchina. Nel video qui sopra trovi la versione in tre minuti.

1. Prima di tutto: il tuo solver è diretto o iterativo?

Il solver è la parte del programma che fa i calcoli, e dentro Ansys Mechanical, COMSOL e Abaqus/Standard ce ne sono due famiglie, che chiedono due macchine diverse. Il solver diretto, chiamato anche sparse, è quello che i tre programmi scelgono da soli quando il modello ha contatto, plasticità o altre non linearità. Risolve la matrice intera in un colpo solo: chiede molta RAM, fa i conti in doppia precisione e, secondo Ansys, è limitato dalla capacità di calcolo del processore. Il solver iterativo arriva alla soluzione per approssimazioni successive: in Ansys si chiama PCG, in Abaqus AMG, e COMSOL ne offre diversi. I tre programmi lo usano per i grandi modelli lineari in elementi solidi. Chiede circa dieci volte meno RAM e, sempre secondo Ansys, è limitato dalla banda di memoria.

La regola che vale per tutto l'articolo: se il tuo job gira con il solver diretto, il problema della macchina è la RAM; se gira con l'iterativo, la RAM serve dieci volte meno e il problema diventa la banda di memoria. Il CFD (la fluidodinamica) di Fluent e i solver espliciti, quelli degli urti e dei crash come Abaqus/Explicit e LS-DYNA, scalano con i core, ma solo se i canali di memoria li alimentano. Quale solver usi lo trovi nel file di log: Mechanical scrive se il solver sparse lavora in memoria o su disco, COMSOL riporta gradi di libertà e memoria usata, Abaqus stampa nel file .dat le stime di memoria prima di partire.

2. Primo vincolo: la licenza decide quanti core puoi usare

È il vincolo che la scheda tecnica non mostra, e i tre produttori lo gestiscono in tre modi opposti.

Fonti: guida alle licenze di Ansys 2026 R1; guida all'installazione e requisiti di sistema di COMSOL 6.4; documentazione di Dassault Systèmes e, per la curva dei token di Abaqus, le tabelle di licenza in uso presso i centri di calcolo universitari (2026). Ottobre 2026.

Ansys: quattro core inclusi, poi si paga per core

La guida alle licenze di Ansys 2026 R1 è chiara: la maggior parte delle applicazioni usa quattro core senza licenze HPC. La licenza HPC è il nome che Ansys dà alla licenza per ogni core oltre i quattro inclusi; in alternativa ci sono i pacchetti HPC Pack, e due pacchetti arrivano in totale a 36 core. Due dettagli cambiano il modo di scegliere la macchina. Il primo riguarda l'Hyper-Threading, la funzione che fa vedere al sistema operativo due processori per ogni core fisico: per Ansys ogni processore che il sistema vede conta come un core e si paga. Un processore a 12 core con l'Hyper-Threading acceso mostra 24 processori. Se lanci il job su tutti e 24, Ansys ti chiede 20 licenze HPC (24 meno i 4 inclusi) invece delle 8 che pagheresti sui 12 core fisici; la stessa guida sconsiglia di usarlo. Il secondo riguarda i pacchetti: un pacchetto serve un solo job alla volta, non puoi dividerlo tra due simulazioni. Con le licenze singole, invece, due simulazioni da 8 core pagano 4 licenze ciascuna, cioè 8 in tutto, mentre una simulazione sola da 16 core ne paga 12 (nostro calcolo dalla regola Ansys). Chi lancia più job in parallelo e chi ne lancia uno grande hanno due conti diversi, prima ancora di guardare i processori.

COMSOL: nessun limite, ma il produttore stesso frena

COMSOL è all'opposto: la guida all'installazione della 6.4 scrive che il numero di core che puoi usare è limitato solo dall'hardware e dal sistema operativo, con qualunque licenza (quella di rete serve solo per il cluster). Eppure è COMSOL stessa, nella guida all'hardware, a frenare, con due frasi. In generale sei o otto core sono una buona scelta per tutti gli usi, anche se più core possono essere meglio. Troppi core in parallelo possono perfino rallentare, anche se di solito solo sui modelli piccoli. Nel suo blog aggiunge che, per un modello singolo, nella maggior parte dei casi oltre otto core il vantaggio è poco; più di quattro canali di memoria servono a chi risolve di routine modelli molto grandi o più modelli in parallelo. La 6.4 è la versione attuale; la 2027 è annunciata per questo autunno.

Abaqus: i token crescono piano

Dassault licenzia Abaqus a token: non vende licenze per core ma un numero di gettoni, e ogni job ne consuma un numero che dipende dal tipo di analisi e dai core usati. La tabella in uso presso i centri di calcolo cresce molto meno dei core: da 8 a 32 core i token non raddoppiano. Qui il freno ai core non è la licenza, è la macchina; e i token premiano un job grande rispetto a due piccoli, il contrario di Ansys. Su una workstation Abaqus/Standard usa il solver diretto in modalità thread per impostazione predefinita: il parallelismo è già attivo, restano da impostare il numero di core e la memoria.

3. Secondo vincolo: la RAM decide se la simulazione resta in memoria

«Mi serve tanta RAM, questo lo so. Ma quanta esattamente non saprei dirvi.» È la frase che noi di Syspack sentiamo più spesso, ed è la domanda giusta. I tre produttori danno tre modi per rispondere.

Ansys Mechanical: da 10 a 20 GB per milione di gradi di libertà

La Performance Guide di Mechanical 2026 R1 dà i numeri. Per il solver diretto che lavora tutto in RAM, Ansys indica da 10 a 20 GB per ogni milione di gradi di libertà. Con gli elementi quadratici in 3D, che sono di solito quelli predefiniti, Ansys dice di aggiungere dal 50 al 100%; con le matrici non simmetriche o complesse delle analisi armoniche, di raddoppiare circa. Sul tuo modello: un milione di nodi con elementi solidi sono circa tre milioni di gradi di libertà, quindi da 30 a 60 GB per il solver con gli elementi lineari e da 45 a 120 GB con i quadratici predefiniti. Sono nostre stime dai numeri Ansys. Il solver iterativo PCG chiede invece circa 1 GB per milione di gradi di libertà.

Quando la RAM non basta, il solver diretto non si ferma: passa su disco, dove la memoria scende a circa 1 GB per milione di gradi di libertà ma il disco scrive e rilegge circa 10 GB per milione. Ansys scrive di puntare sempre alla modalità in memoria, se il fabbisogno resta sotto il 90% della RAM fisica, perché la modalità su disco causa un degrado significativo di prestazioni e scalabilità. E aggiunge: nella maggior parte dei casi un sistema con più memoria batte un sistema con meno memoria, anche se quest'ultimo ha processori più veloci.

Abaqus: i due numeri nel file .dat

Abaqus ti dice quanta memoria serve prima di partire. Basta lanciare un datacheck, il controllo preliminare che Abaqus fa senza calcolare: nel file .dat compaiono due valori. Il primo è la memoria minima, sotto la quale il job difficilmente arriva in fondo. Il secondo è la memoria per evitare il disco, con la quale Abaqus tiene tutti i dati temporanei in RAM. Tra i due, Abaqus scrive il resto sui dischi scratch, cioè i dischi dove il solver appoggia i file temporanei durante il calcolo. La documentazione dice che dare più memoria spesso migliora le prestazioni e che, se il job ne chiede più di quanta ne ha la macchina, conviene spostarlo su una macchina con più memoria; per impostazione predefinita Abaqus può usare fino all'80% della RAM fisica. Abaqus/Explicit, invece, non scrive file scratch: chiede meno memoria e la vuole tutta in RAM.

COMSOL: la RAM è il fattore più importante

COMSOL lo scrive così, nella guida all'hardware: il singolo fattore più importante è avere abbastanza memoria fisica; con RAM insufficiente la soluzione rallenta in modo significativo, e la RAM oltre il necessario non dà benefici. Il metodo che consiglia: risolvi versioni più piccole dello stesso modello, leggi memoria e gradi di libertà nel log ed estrapola. Con i solver diretti la memoria cresce più in fretta del modello: se raddoppi i gradi di libertà, la memoria cresce da circa tre a quattro volte, e per i modelli 3D grandi COMSOL propone l'iterativo. Quando la memoria finisce, il solver diretto passa su disco in automatico, al 99% della RAM fisica, e i tempi si allungano.

Fluent: anche il CFD ha fame di RAM

Per il solver su processore di Fluent il manuale non dà una regola; lo staff Ansys sul forum ufficiale (2024) indica da 2 a 4 GB per milione di celle: un caso da 50 milioni di celle sono da 100 a 200 GB di RAM. Con il solver su scheda video la regola è nel manuale: circa 1 GB di memoria della scheda per milione di celle esaedriche in singola precisione, il 50% in più in doppia, dal 20 al 40% in più con le mesh poliedriche. Per la guida all'acquisto pubblicata da Ansys, la RAM del computer deve essere almeno pari alla memoria delle schede video montate.

Un'ultima cosa che i numeri del solver non vedono: mentre il solver gira, l'interfaccia tiene in memoria il modello, e il post-processing apre file di risultati da decine di GB. La RAM che ti serve è quella del solver più quella dell'interfaccia e dei risultati, come abbiamo spiegato in quanta RAM serve davvero per lavorare nel 2026.

4. Terzo vincolo: la banda di memoria decide se i core lavorano

Qui sta la risposta alla domanda del titolo. I core fanno i conti sui dati che arrivano dalla memoria; se i dati non arrivano abbastanza in fretta, i core aspettano. Ogni canale di memoria è una corsia tra RAM e processore: più canali, più dati al secondo. Un desktop ne ha due, una workstation di fascia media quattro, una professionale otto, un server dodici per processore; con la stessa memoria, otto canali portano in teoria quattro volte i dati di due. Anche la memoria massima cresce con i canali: da qualche centinaio di GB sul desktop a uno o più terabyte sulle piattaforme a quattro e otto canali. Il resto lo fa il solver: una parte del calcolo non si divide tra i core e pesa sempre uguale, come ricorda COMSOL nella sua guida al calcolo multicore.

I produttori del software lo scrivono. La Performance Guide di Ansys Mechanical dice che alcuni processori multicore non hanno banda di memoria sufficiente per alimentare tutti i core, e che per alcuni processori consiglia di usare al massimo metà dei core disponibili. Il blog Ansys di luglio 2026 scrive che più core non sono sempre meglio per ogni carico di Fluent: su alcuni modelli grandi un processore server a 96 core è andato meglio di uno con più core, perché con molti core la banda di memoria per core diventa significativa. COMSOL fa un esempio nella guida all'hardware: su un sistema a quattro canali, un modulo per canale è la scelta migliore, mentre con un solo modulo grande le prestazioni possono essere circa quattro volte peggiori sui modelli che usano molta memoria.

I numeri: dove la curva dei core si appiattisce

I benchmark pubblicati da Ansys per Mechanical 2025 R1, su una workstation a 64 core con otto canali di memoria e Windows 11, mostrano la curva del solver diretto. Da 4 a 16 core la simulazione va 2,6 volte più veloce; da 16 a 32 core guadagna un altro 60%; da 32 a 56 core un altro 12% circa. Con il solver iterativo PCG la curva oltre 32 core sale e scende: il risultato migliore è a 48 core, ma a 40 e a 56 è sotto quello dei 32. Tradotto: su una piattaforma a otto canali, per un singolo job con il solver diretto, fino a 16 core il guadagno è quasi pieno, tra 16 e 32 dipende dal modello, oltre 32 è marginale. I core oltre servono per un secondo job, per Fluent o per un solver esplicito, non per accorciare quel job.

I test indipendenti confermano il peso dei canali. In un test indipendente di febbraio 2026 su un benchmark CFD sintetico, a parità di consumo elettrico massimo, un processore a 96 core con otto canali è andato 1,85 volte più veloce di uno a 64 core con quattro canali. Nello stesso test un 32 core con otto canali, di una generazione più vecchia, ha impiegato circa 2,2 volte il tempo del 96 core: i core contano, ma meno che in proporzione, e solo se ogni canale ha il suo modulo. In test indipendenti di marzo 2024, su processori della generazione precedente e su un carico limitato dalla memoria tipico di molti solver ingegneristici, un 64 core a otto canali ha smesso di guadagnare a 16 core, e un 64 core a quattro canali già a 8. Sul desktop il conto è ancora più corto: due canali, e una frequenza della memoria che, secondo la specifica AMD, con quattro moduli scende di circa un terzo.

Due limiti che la scheda tecnica non mostra: Windows e l'Hyper-Threading

Il primo lo scrive Ansys nella Performance Guide 2026 R1: Windows raggruppa i processori logici (i core, o i thread se l'Hyper-Threading è acceso) in gruppi da 64, e un job usa bene un gruppo solo. Per questo Ansys consiglia di tenere ogni job entro 64 processori logici su Windows e di passare a Linux per andare oltre; è un limite di Windows, non del processore. Il secondo è l'Hyper-Threading stesso: Ansys consiglia di disattivarlo e, se resta attivo, di non superare il numero di core fisici; COMSOL scrive che non ne trae beneficio e usa da sola i soli core fisici. I processori desktop più recenti hanno core di due tipi, e per alcuni modelli grandi COMSOL consiglia di limitarsi ai core ad alte prestazioni. Sono decisioni di configurazione, non di catalogo: sulle macchine dedicate al calcolo noi spegniamo l'Hyper-Threading; su quelle a uso misto lo lasciamo acceso e lanciamo i job solo sui core fisici.

Quando i molti core hanno senso: i solver espliciti e i job in parallelo

Non tutto si appiattisce. Abaqus/Explicit divide il modello in domini e scala con i core finché la banda regge: non scrive file scratch, vuole la memoria in RAM e, dice Dassault in un'intervista del 2023, tende a dipendere fortemente dalla banda di memoria. LS-DYNA in Ansys parte da un core incluso e cresce con le licenze HPC. Il CFD di Fluent su processore scala con i core finché i canali di memoria li alimentano. E chi lancia tre job da 16-32 core sulla stessa macchina usa tutti i core di una workstation a 64 o 96 core. Per questi lavori la workstation professionale a otto canali e molti core ha senso; per un job solo con il solver diretto, no. Ed è il motivo per cui, quando una macchina ha i canali di memoria popolati a metà, chi simula lo sente prima degli altri: ne parliamo in i quattro limiti delle workstation di marca.

Prima e dopo il solver: il singolo core

Metà della giornata di chi simula non è nel solver: è nella geometria, nella mesh, nel setup e nel post-processing. Gran parte di quel lavoro usa un core alla volta, e lì conta la frequenza del singolo core: COMSOL scrive che un clock più alto rende più veloce tutto il software. Le piattaforme professionali di oggi dichiarano frequenze di picco del singolo core vicine a quelle dei desktop: scegliere gli otto canali non vuol dire rinunciare al core veloce.

5. La scheda video: quando aiuta davvero

La risposta è «dipende dal solver», e il motivo è nella scheda tecnica di NVIDIA. Le schede video workstation e consumer di questa generazione fanno i calcoli in doppia precisione (numeri a 16 cifre significative) a un sessantaquattresimo della velocità con cui fanno quelli in singola (7 cifre). I solver diretti strutturali usano la doppia; il solver su scheda video di Fluent lavora di norma in singola. NVIDIA scrive che le poche unità a doppia precisione servono a far funzionare correttamente i programmi che la usano; le schede da data center per il calcolo scientifico hanno invece unità a doppia precisione piene.

Un sessantaquattresimo non vuol dire sessantaquattro volte più lenta di un processore. Una scheda workstation di fascia alta fa circa 2 TFLOPS in doppia precisione, duemila miliardi di operazioni al secondo (nostro calcolo dal dato NVIDIA): sulla carta è l'ordine di grandezza di un processore a 16 core. Nei test del solver diretto, però, la scheda vale quanto qualche core in più, non sedici, perché il trasferimento dei dati verso la scheda e la sua memoria contano quanto i calcoli. Per questo aiuta chi ha quattro o dodici core licenziati e serve poco a chi ne ha trentadue (nostra stima, coerente con i numeri della tabella).

Fonti: guide, requisiti e blog di Ansys, COMSOL e Dassault Systèmes; whitepaper NVIDIA sull'architettura Blackwell; test di partner e test indipendenti indicati nelle celle con la data. Ottobre 2026.

Fluent: la scheda è una leva vera, a tre condizioni

Il solver nativo su scheda video di Fluent lavora in singola precisione, e le schede workstation lo fanno bene: la guida all'acquisto pubblicata da Ansys elenca come testate le schede professionali delle ultime tre generazioni, non le GeForce. Nel test di partner della tabella, con 96-128 core il processore è però tornato davanti alla scheda. Le condizioni sono tre. La fisica: il solver su scheda è un solver separato, solo 3D, con una lista di modelli coperti che cresce a ogni versione; chi fa multifase euleriano o combustione dettagliata controlla la lista prima di pensare alla scheda. La memoria: circa 1 GB per milione di celle in singola precisione, e per Ansys la RAM del computer deve essere almeno pari alla memoria della scheda. La licenza: il solver su scheda esiste solo con i livelli CFD Enterprise e CFD HPC Ultimate, e Ansys conta le unità di calcolo della scheda (gli SM della scheda tecnica NVIDIA) come se fossero core. Le prime 40 sono incluse, per ogni unità in più serve una licenza HPC, e la scheda si licenzia tutta o niente: una scheda workstation di fascia alta ha 188 unità, cioè 148 licenze HPC, le stesse con cui faresti girare 148 core in più. Con la licenza CFD HPC Ultimate non servono licenze aggiuntive. Prima di comprare la scheda, parla con il tuo rivenditore Ansys.

Mechanical e Abaqus: utile con pochi core

Per il solver diretto di Mechanical la guida all'installazione di Ansys 2026 R1 raccomanda solo le schede da data center con doppia precisione piena; le schede workstation e consumer sono indicate per i solver iterativi e misti, con almeno 16 GB di memoria sulla scheda. Il «sì» c'è: il PCG sulle schede workstation gira, quindi chi fa grandi modelli lineari con una scheda e poche licenze può avere un guadagno (Ansys consiglia almeno 24 GB sulla scheda per il PCG), e nel conteggio Ansys la scheda sostituisce un core: tre core più una scheda stanno nei quattro inclusi. Per Abaqus, Dassault non pubblica una lista di schede per il solver diretto; NVIDIA, nel 2016, parlava di 2-3 volte con le sue schede a doppia precisione e sconsigliava le GeForce. I test indipendenti della tabella dicono la stessa cosa dei nostri conti: con pochi core la scheda aiuta, con molti core il guadagno cala fino a sparire. Nel modello a token tradizionale la scheda conta come un core in più (NVIDIA, 2016): puoi provarla, ma non dimensionare la workstation sulla scheda. Il nuovo solver iterativo di Abaqus deve invece stare tutto nella memoria della scheda, e Dassault lo prova su schede da data center con modelli da 22 a 51 milioni di gradi di libertà: è il passaggio dalla workstation al mondo che abbiamo raccontato in DGX Spark o workstation: la macchina giusta per l'AI.

COMSOL: il solver diretto su scheda, con tutte le licenze

COMSOL 6.4 ha aggiunto il solver diretto di NVIDIA, cuDSS, in alternativa a MUMPS e PARDISO, con tutte le licenze e anche con più schede nella stessa macchina. Lavora in doppia precisione di default; i numeri dichiarati da COMSOL sono nella tabella. La sua guida alla scelta della scheda dice tre cose utili: la memoria della scheda determina la dimensione massima del modello, le prestazioni in doppia precisione sono in genere inferiori sulle schede workstation, e prima di tutto conviene controllare se il modello ha bisogno del solver diretto. Una scheda video serve comunque a tutti e tre i software per la grafica: i produttori testano le schede professionali, e per il viewport bastano pochi GB di memoria.

6. Il disco, la memoria con correzione degli errori e le ore di notte

Il disco scratch è il quarto protagonista della notte. Ansys scrive che il solver diretto e il solver Block Lanczos delle analisi modali leggono e riscrivono file enormi più volte: con questi solver un'analisi di taglia media muove facilmente un terabyte di dati o più, e i file dei risultati vanno da decine a centinaia di GB. Le sue raccomandazioni: dischi locali a stato solido con una capacità di circa dieci volte la RAM installata (con 128 GB di RAM circa 1,3 TB: nostro calcolo), un disco separato per il solver, mai una cartella di rete, che Ansys chiama un collo di bottiglia importante. Abaqus lo dice in una frase: un'alta velocità di lettura e scrittura dei dischi scratch è essenziale per le prestazioni dell'analisi. COMSOL aggiunge il contrario, che vale altrettanto: se il sistema usa il disco come memoria virtuale, aggiungere RAM aiuta più di un disco più veloce.

Sulla memoria con correzione degli errori (ECC) nessuno dei tre produttori scrive una regola. È una nostra scelta di progetto per le macchine che restano accese tutta la notte, e le piattaforme professionali la portano di serie: sui Threadripper PRO AMD la dichiara attiva di default, i Xeon W di Intel accettano solo moduli ECC registrati, sul desktop esiste solo con schede madri specifiche. Non è l'ECC a salvare il job notturno, che quando fallisce lo fa di solito per memoria, per disco o per convergenza; è quello che evita l'errore silenzioso in un risultato che finisce in una relazione tecnica.

7. Quattro situazioni che costano una notte

Il processore con più core non accorcia il job singolo

Con il solver diretto la curva si appiattisce oltre 16-32 core, la licenza Ansys li fa pagare uno a uno o a pacchetti, e Windows ne usa bene al massimo 64 per job, contando anche i thread. Il 96 core ha senso per chi lancia più job insieme, per Fluent e per i solver espliciti.

Il desktop a due canali perde banda con quattro moduli

Due moduli grandi stanno nella specifica a piena frequenza; quando il fabbisogno non ci sta in due moduli e se ne montano quattro, la specifica del processore abbassa la frequenza della memoria: hai la RAM che ti serve e i core che aspettano. A quel punto la piattaforma giusta ha quattro o otto canali.

La scheda video non aiuta il solver diretto quando i core sono tanti

Una scheda workstation accanto a un 32 core, per Mechanical o Abaqus/Standard, aggiunge poco rispetto a quanto costa, e Ansys non la raccomanda per quel solver. È una scelta giusta per Fluent, per COMSOL cuDSS e per chi ha pochi core licenziati.

I thread virtuali costano licenze e non danno velocità

Con l'Hyper-Threading acceso e il job lanciato sul numero di thread invece che di core, in Ansys licenzi il doppio dei core per non guadagnare quasi niente, e in COMSOL non guadagni nulla. Si lancia sui core fisici, oppure si spegne l'Hyper-Threading sulle macchine dedicate.

8. Le domande che fa un esperto prima di dimensionare la macchina

Prima di parlare di componenti, un nostro esperto ti chiede come lavori. Sono domande a cui sai rispondere senza aprire una scheda tecnica, e da ognuna dipende un pezzo della macchina.

Quale solver usi: diretto o iterativo, implicito o esplicito, perché decide se conta la RAM o la banda, e se i core servono.

Quanto è grande il modello più grande dell'anno: nodi, elementi o celle, perché da lì si calcola la RAM.

Oggi lavori in memoria o su disco: lo dice il file di log, e dice se la macchina attuale è corta di RAM o di core.

Quante licenze hai: licenze HPC, pacchetti, token, perché fissano il numero di core che puoi usare.

Quanti job lanci insieme, e quanti sweep parametrici (lo stesso modello lanciato molte volte cambiando un parametro), perché decidono se i core oltre i 32 servono.

Windows o Linux, perché sopra i 64 processori logici cambia il discorso.

La tua fisica è nella lista del solver su scheda video, se usi Fluent, e quante licenze HPC hai per la scheda.

Quanto pesano i file dei risultati, e dove li salvi, perché decidono il disco.

Quante ore di calcolo a notte, perché decidono raffreddamento, alimentazione e memoria con correzione degli errori.

9. Come lo facciamo in Syspack

Da quelle risposte progettiamo la macchina, in questo ordine. Scegliamo la piattaforma sui canali di memoria, prima che sui core. Scegliamo i core sulle licenze che hai e sui job che lanci insieme. Dimensioniamo la RAM sul modello più grande dell'anno, con un modulo per canale e alla frequenza di specifica. Mettiamo la scheda video solo dove il solver la usa. Dedichiamo allo scratch un disco a stato solido grande circa dieci volte la RAM. Dimensioniamo il raffreddamento per ore di calcolo, non per minuti. Poi mettiamo a punto la macchina: piano energetico a massime prestazioni (COMSOL avverte che i piani a risparmio rallentano la soluzione), Hyper-Threading spento sulle macchine dedicate al calcolo, job entro i 64 processori logici su Windows, cartella temporanea dei solver sul disco giusto. Sono le scelte da cui partono tutte le nostre workstation professionali per la simulazione e il calcolo scientifico, assemblate in Italia per studi di ingegneria, reparti di ricerca e sviluppo, università e centri di ricerca. E nel dopo vendita chi ha configurato la macchina è la persona che risponde.

Domande frequenti

Quanti core servono per Ansys Mechanical?

Dipende dal solver e dalle licenze. Per un job solo con il solver diretto, su una piattaforma a otto canali, il punto di equilibrio sta tra 16 e 32 core (dati Ansys, sezione 4); ogni core oltre i quattro inclusi ha bisogno di una licenza HPC (sezione 2). Più core servono a chi lancia più job insieme.

Quanta RAM serve per Ansys, COMSOL e Abaqus?

Per il solver diretto di Mechanical Ansys indica da 10 a 20 GB per milione di gradi di libertà; Abaqus stampa il fabbisogno nel file .dat; COMSOL consiglia di estrapolare dai modelli più piccoli. Si dimensiona sul modello più grande dell'anno, più la memoria dell'interfaccia e dei risultati (sezione 3).

La scheda video accelera le simulazioni?

Nel CFD di Fluent e nel solver diretto di COMSOL sì, alle condizioni della sezione 5. Nei solver diretti di Mechanical e Abaqus aiuta chi ha pochi core licenziati e poco chi ne ha molti; Ansys riserva lo sparse diretto alle schede da data center a doppia precisione piena.

Windows o Linux per il calcolo?

Fino a 64 processori logici per job Windows va bene; oltre, Ansys consiglia Linux. L'accelerazione su scheda video di Abaqus/Explicit, arrivata a gennaio 2026, è disponibile solo su Linux.

Continua a leggere: DGX Station GB300: a chi serve davvero e quando basta una workstation

Le regole di licenza, i requisiti e le indicazioni sulla memoria citati in questo articolo vengono dalla documentazione ufficiale di Ansys (2026 R1), COMSOL (6.4) e Dassault Systèmes (Abaqus 2026), dalle schede tecniche di AMD, Intel e NVIDIA e, dove indicato, da test indipendenti e test di partner dei produttori, con la data, consultati a ottobre 2026. Le stime sui gradi di libertà per nodo, sulla doppia precisione delle schede e sulle fasce di hardware sono nostre. I produttori aggiornano requisiti e licenze a ogni versione.