È possibile utilizzare due diversi programmi di modellazione per confermare i risultati reciproci?


8

Modelli di computer

La modellistica computerizzata è utilizzata in vari campi dell'ingegneria. Sto specificamente prendendo in considerazione l'analisi strutturale o l'analisi agli elementi finiti (FEA). A volte i modelli vengono utilizzati per accelerare i calcoli ripetitivi che potrebbero essere eseguiti a mano. A volte i modelli vengono utilizzati per eseguire calcoli che non sono facili o addirittura possibili da eseguire a mano.

verifica

Esistono alcuni metodi standard per controllare i risultati dei modelli di computer.

  • Esegui modelli di verifica e conferma che i risultati corrispondono a una risposta calcolata in precedenza.
  • Esegui modelli semplici che possono essere controllati mediante calcoli manuali.
  • Test dei modelli fisici.

Il problema con i primi due metodi di controllo sopra è che controllano solo situazioni specifiche o controllano solo le parti semplici del programma.

Il metodo del modello fisico può essere costoso per i modelli a dimensione intera e i modelli in scala potrebbero non dare sempre gli stessi risultati della dimensione intera.

Questo lascia un vuoto in quali risultati possono essere controllati. Per qualsiasi modello complicato, non esiste un modo semplice per verificare che i risultati del programma siano corretti. L'ingegnere deve fidarsi che il software abbia prodotto risultati corretti dal modello.

Verifica comparativa

Il modello potrebbe essere inserito in due diversi programmi (realizzati da diverse società). Il presupposto è che se i risultati dei due modelli sono abbastanza simili, i risultati dovrebbero essere corretti per il modello utilizzato. Ciò non rileva errori nella creazione del modello originale, ma rileva errori nell'implementazione del software.

  • È possibile utilizzare due programmi separati per verificare la "correttezza" dei risultati dal modello?
  • L'uso di questo metodo per confrontare un modello in due programmi separati fornirebbe lo stesso livello di sicurezza nei risultati di qualsiasi altro metodo di controllo?
  • Quali potrebbero essere gli svantaggi dell'utilizzo di questa procedura?

Lo "Space Shuttle" è andato in orbita usando 5 computer di volo. 4 di questi hanno condotto lo stesso programma, controllando i risultati degli altri, concordando tra loro chi era sano di mente e votando fuori qualsiasi membro insano. Il quinto computer ha eseguito un programma completamente diverso, scritto in modo indipendente da una squadra diversa. 'Nel caso in cui'. Non so se sia mai stato necessario.
Russell McMahon,

Entrambi i programmi per computer potrebbero essere sbagliati allo stesso modo, quindi direi di no. Questa non è una buona pratica. È meglio confrontare le soluzioni numeriche con i casi in cui una soluzione è nota, analiticamente, empiricamente o attraverso ricerche pubblicate.
Paolo,

@Paul Sì, è così che le cose vengono generalmente controllate, ma ciò dimostra solo che il programma funziona per quel problema. È possibile ipotizzare se anche altre configurazioni che utilizzano gli stessi percorsi di codice siano corrette, ma ci sarà sempre un caso limite. L'ipotesi inclusa nell'uso di due programmi separati è che i programmatori hanno errori in diversi casi limite.
hazzey

Risposte:


7

Sì, ottenere una seconda opinione può essere utile. Questo viene fatto di routine nelle previsioni meteorologiche in cui non si conoscono le soluzioni esatte e si ha un giudizio su come applicare vari fattori.

Ci sarà meno spazio di manovra in qualcosa di simile a un'analisi delle sollecitazioni di mesh ad elementi finiti perché le equazioni iterative per risolverlo saranno sostanzialmente le stesse, indipendentemente da chi ha scritto il software. Il vero problema non è risolvere la mesh quanto creare una mesh abbastanza buona in primo luogo.

Un modo quindi di ottenere opinioni multiple è quello di variare i parametri della mesh. Spero che tu abbia ancora la stessa risposta. Se rendi la mesh 2x più fine e ottieni una risposta significativamente diversa, allora è un indizio forte che la mesh originale non era abbastanza dettagliata. Inoltre, non sai con certezza che la mesh successiva sia sufficientemente dettagliata senza crearne una ancora più dettagliata e ottenere la stessa risposta.

Ovviamente oggigiorno la generazione della mesh stessa è in qualche modo automatizzata e adattiva. Non si tratta più solo della fisica della risoluzione della mesh, ma include l'euristica su quando e come suddividere. Software diversi possono variare a questo proposito, quindi può essere utile eseguire due programmi diversi con gli stessi dati iniziali.


6

Scrivo questo dal punto di vista di un ingegnere che sviluppa software di simulazione.

Penso che la pratica descritta sia negativa e ti consiglio di non usare due software diversi per "confermare" i risultati.

In generale, due diversi software di modellazione non possono essere utilizzati per confermare qualcosa di diverso dalla loro somiglianza. Due software potrebbero facilmente ottenere due risposte simili ma sbagliate, specialmente se usano modelli simili. Mi viene in mente almeno un caso in cui questo è sicuramente il caso, e Trevor Archibald ne menziona un altro. Sarei più colpito da due software che usano diverse tecniche di modellazione ottenendo risultati simili.

Questo argomento si chiama verifica e validazione dei modelli di computer e ha una letteratura abbastanza vasta. Offrirò uno schizzo delle basi. La verifica sta confrontando un modello con una soluzione "esatta" (che potrebbe essere un calcolo manuale o qualcosa di più complesso), vale a dire verificare la matematica del software. Le ipotesi alla base della soluzione esatta potrebbero essere sbagliate, ma almeno dovresti assicurarti che il software ottenga la parte matematica giusta. La convalida sta confrontando un modello con un esperimento. Ciò ti consente di verificare se il modello che stai utilizzando è accurato, il che è qualcosa che la verifica non può fare per te.

Il problema con i primi due metodi di controllo sopra è che controllano solo situazioni specifiche o controllano solo le parti semplici del programma.

Questo è un vero problema per gli sviluppatori e gli utenti di software. Ci sono modi stabiliti per gestirlo che sono molto meglio del confronto tra due diversi software.

Il problema è che non puoi mai testare ogni possibile caso. Il tuo software potrebbe superare il caso A, ma il caso A non coinvolge la fisica X, Y o Z, e questo ti rende totalmente fuori dal caso B. Quindi, ciò che vorresti sono un gran numero di controlli che coprono almeno tutti le funzionalità di base che si desidera verificare. Molti software hanno "suite V&V" che sono sostanzialmente esattamente questo.

In termini di verifica, ci sono numerose opzioni. Potresti generare nuove soluzioni esatte per casi diversi. A volte questo da solo è adeguato. Tuttavia, come hai notato, spesso ciò che puoi fare a mano è limitato a casi molto semplici. Per i casi più generali, è possibile utilizzare una tecnica chiamata metodo delle soluzioni prodotte (Google it). Ciò richiede programmazione e può diventare disordinato, ma ti consente di testare praticamente qualsiasi cosa ti venga in mente. (A proposito, la parte del disordine può essere gestita tramite una libreria come MASA .)

Inoltre, vorrei sottolineare che contrariamente a quanto suggerisce Olin Lathrop, con il metodo delle soluzioni fabbricate, è possibile generare quali sono, ai fini del test, soluzioni esatte. Non sono "esatti" in senso stretto, perché non soddisfano esattamente le equazioni che il software sta risolvendo senza modifiche. Ma soddisfano equazioni molto vicine e la differenza viene spiegata per rendere rigoroso il test. Questa tecnica non è molto popolare al momento, ma è stata utilizzata per testare cose che in precedenza erano ritenute difficili da testare.

In termini di convalida, potresti cercare altri dati sperimentali o eseguire i tuoi esperimenti.


4

Penso che nel complesso sia una buona pratica.

Utilizzando due diversi software, potresti essere in grado di evitare due tipi di errori: 1) errori che derivano da un software impreciso (che non deve essere trascurato), 2) errori che derivano dalla mancanza di abitudine dell'utente con il software (opzioni nascoste, impostazioni predefinite ...).

Se i software sono abbastanza diversi, le probabilità di ottenere due volte gli stessi risultati errati sono basse.

Tuttavia, gli errori che derivano da una cattiva scelta di modelli non possono essere evitati in questo modo. Quindi direi che lo svantaggio principale è la fiducia eccessiva nei risultati perché sono stati confermati da due software.

Penso che sia meglio padroneggiare un software, eseguendo tutti i tipi di casi di test (confronto con i risultati accademici per esempio), piuttosto che usare diversi software e avere solo una conoscenza media. Inoltre, penso che sia meglio conoscere le basi dell'analisi FEM e usare solo due software "one-click-to-run" è una cattiva pratica perché è probabile che gli utenti riproducano errori di modellazione.

PS: sto scrivendo come utente di analisi elettromagnetica / termica FEM (nessun altro dominio).


2

Risposta dal punto di vista di un progettista

Controllare i risultati di un programma rispetto a un altro ti darà un certo livello di certezza che i risultati sono corretti. È improbabile che ti dia certezza al 100%, ma poi quel livello di certezza è difficile da raggiungere.

Un grosso problema che vedo è la possibilità di trasferire il modello da un software all'altro. Sebbene l'importazione / esportazione di modelli sia migliorata dalla maggior parte delle società di software (grazie al BIM), non mi aspetto che tutte le funzionalità di un modello siano esportabili. La geometria è relativamente facile da importare / esportare poiché il file di scambio deve contenere solo coordinate. Ad esempio, è probabile che le versioni finali dei membri vengano archiviate in modo molto diverso da software diverso, quindi a meno che / fino a quando non verrà concordato un formato di scambio di file universale, sospetto che sarebbero necessari molti sforzi per ricostruire completamente un modello nel secondo programma software.

In base alla mia esperienza personale, è molto più probabile che gli errori nei risultati provengano da un inserimento errato di dati o da ipotesi errate rispetto a quelli di software scritto male. Il tempo e lo sforzo nell'uso di software indipendenti per verificare una risposta non sono quindi probabilmente un buon uso del tuo tempo.

Risposta dal punto di vista di un ingegnere del software

La verifica del software rispetto ad altri software non è considerata una giustificazione della correttezza del software. È molto meglio trovare dati / risultati pubblicati che possono essere utilizzati per verificare che il software fornisca risposte corrette. Immagina un incontro di vendita in cui una società di software sta cercando di vendere il proprio software a una società di ingegneria:

Ingegnere: come sappiamo che il tuo software è corretto?

Venditore di software: Bene, l'abbiamo verificato con il software del nostro concorrente e abbiamo ottenuto la stessa risposta.

Ingegnere: Quindi stai dicendo che il tuo concorrente è sufficientemente migliore di te che il suo software è il parametro di riferimento rispetto al quale misuri il tuo software? Sembra invece che dovremmo comprare il suo software!


1
Spero che il tecnico del software non pubblicizzi che il software viene confrontato con un altro programma, anche se è il caso in laboratorio. Penserei anche che un ingegnere del software apprezzerebbe il fatto che potrebbero esserci casi limite che non sono stati completamente coperti dai test unitari.
hazzey

2

Concordo con le altre risposte qui, che questa in generale può essere una buona idea e contribuirà a garantire l'accuratezza dei risultati della simulazione. In termini di quanto sia buono rispetto agli altri metodi di verifica, direi che risultati precedentemente noti e test fisici sono entrambe opzioni migliori se fattibili, ma i calcoli manuali potrebbero richiedere un'eccessiva semplificazione se il modello è sufficientemente complesso.

Quello che voglio davvero sottolineare è qualcosa che non è stato affrontato sull'ultimo punto: potenziali punti deboli di questa pratica. L'utilizzo di due diversi pacchetti FEA può rilevare una peculiarità di un pacchetto che causa un errore, a condizione che sia possibile identificare quale analisi è corretta e quale è disattivata. Tuttavia, ci sono alcune limitazioni generali alla FEA in generale, indipendentemente dal metodo o dall'attuazione. Gli spigoli vivi e altri concentratori di stress che causano singolarità nel modello non sono qualcosa che cambierà molto da pacchetto a pacchetto, questi saranno sempre punti deboli. È qui che sono richieste conoscenza e intuizione ingegneristiche.

Ho fatto simulazioni su parti che conosco resistere facilmente a determinate sollecitazioni, e il modello mostra che la sollecitazione interna è 10 volte la forza di snervamento; questo è ovviamente errato, perché è su un modello di spline involuto e al software FEA non piace.

Infine, dovrebbe essere ovvio che la modifica del software non elimina l'errore dell'utente. Se si commette un errore nel modello o nei parametri, quell'errore ti rovinerà qualunque cosa tu usi per analizzarlo.


Non ho idea di cosa sia un "modello di spline involuto", quindi questo commento potrebbe non essere pertinente, ma se stai ottenendo uno stress interno con una resa 10x, forse la modellazione con un materiale non lineare sarebbe in ordine? Ciò eliminerebbe le concentrazioni estreme di stress locale.
AndyT

A questo punto, non ricordo se ho usato una risposta materiale elastico lineare o qualcosa di più semplice, ma non volevo che la simulazione funzionasse per sempre, e questo è un primo utilizzo di FEA per noi. Era essenzialmente una riprogettazione di una parte esistente per la quale conosciamo la modalità di guasto e il modo in cui abbiamo dovuto impostare il modello ha messo alcuni vincoli difficili sulla spline (una spline a spirale è la forma della maggior parte dei denti degli ingranaggi). Se stavo facendo un'analisi più completa, potrei provare a risolverlo, ma questa era una prova di concetto in più, rispetto alla parte esistente.
Trevor Archibald,

1

Le condizioni al contorno e la tecnica di modellazione influenzeranno notevolmente i risultati. Quello che suggerisco è di eseguire una versione semplificata / idealizzata (come planare o assiale) e una piena piena e confrontando le due.

Il problema con due diversi software FEA è che sotto il cofano i solutori saranno sostanzialmente gli stessi. Le differenze osservate verrebbero forse da diversi criteri di convergenza o da diverse ipotesi su come vengono applicate le condizioni al contorno. Non stai verificando il modello, ma la capacità di ciascun risolutore di sapere che ha raggiunto una soluzione.

Penso che i risultati della FEA debbano essere convalidati dal primo buon senso e dai calcoli manuali, quindi da modelli simili ma diversi (solidi anziché travi per esempio) e infine da test fisici per vedere se le parti falliscono dove e come prevede la FEA. Il momento in cui una parte fallirà è più difficile perché è influenzato dai processi di produzione, dalle variazioni dei materiali e dalle sollecitazioni resudiali.


Non tutte le discipline ingegneristiche hanno il lusso di poter fare un test di distruzione fisica. Nell'ingegneria civile e strutturale la stragrande maggioranza dei progetti sta costruendo oggetti unici una tantum - costruirne uno completamente separato solo per testarli alla distruzione sarebbe proibitivamente costoso!
AndyT

Punto preso. È comunque una buona idea convalidare i risultati FEA con i test, anche se si tratta di pezzi campione o in scala.
Ja72,

Vedo il tuo punto ... ma nei miei sei anni di progettazione del ponte non ho mai sentito parlare di un test fisico su un modello in scala di un ponte.
AndyT,

Quindi quali ponti dovrei evitare allora? Prendere in giro. Quindi devono esserci margini di sicurezza sufficienti per tenere conto delle cose che non sono modellate con FEA. Non esiste un modello FEA accurato al 100%.
Ja72,

In effetti, abbiamo fattori di sicurezza ovunque! Lo standard britannico BS5400 (ora praticamente defunto) includeva un fattore 1,1, chiamato gammaf3, che era "un fattore che tiene conto della valutazione imprecisa degli effetti del carico, della distribuzione imprevista delle sollecitazioni nella struttura e delle variazioni nella precisione dimensionale ottenute nella costruzione ". cioè qualunque sia la tua analisi FE ti dice che lo stress è, moltiplicalo per 1,1 nel caso in cui sia un valore non conservativo.
AndyT
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.