क्या एक दूसरे के परिणामों की पुष्टि के लिए दो अलग-अलग मॉडलिंग कार्यक्रमों का उपयोग किया जा सकता है?

8

कंप्यूटर मॉडल

कंप्यूटर मॉडलिंग का उपयोग विभिन्न इंजीनियरिंग क्षेत्रों में किया जाता है। मैं विशेष रूप से संरचनात्मक विश्लेषण या परिमित तत्व विश्लेषण (FEA) पर विचार कर रहा हूं। कभी-कभी मॉडल दोहराए जाने वाले गणनाओं को गति देने के लिए उपयोग किया जाता है जो हाथ से किया जा सकता है। कभी-कभी मॉडल का उपयोग गणना करने के लिए किया जाता है जो हाथ से करना आसान या संभव नहीं होता है।

जाँच हो रही है

कंप्यूटर मॉडल के परिणामों की जाँच के लिए कुछ मानक विधियाँ हैं।

सत्यापन मॉडल चलाएं और पुष्टि करें कि परिणाम पहले से गणना किए गए उत्तर से मेल खाते हैं।
सरल मॉडल चलाएं जिन्हें हाथ की गणना द्वारा जांचा जा सकता है।
शारीरिक मॉडल का परीक्षण करें।

पहले दो जाँच तरीकों के साथ समस्या यह है कि वे या तो केवल विशिष्ट स्थितियों की जाँच करते हैं या वे केवल कार्यक्रम के सरल भागों की जाँच करते हैं।

भौतिक मॉडल विधि पूर्ण आकार के मॉडल के लिए महंगी हो सकती है और स्केल मॉडल हमेशा पूर्ण आकार के समान परिणाम नहीं दे सकते हैं।

यह उन परिणामों में एक अंतर छोड़ देता है जिन्हें जांचा जा सकता है। किसी भी जटिल मॉडल के लिए, यह जांचने का कोई आसान तरीका नहीं है कि कार्यक्रम से परिणाम सही हैं। इंजीनियर को भरोसा होना चाहिए कि सॉफ्टवेयर ने मॉडल से सही परिणाम उत्पन्न किए हैं।

तुलना की जाँच करें

मॉडल को दो अलग-अलग कार्यक्रमों (विभिन्न कंपनियों द्वारा किए गए) में इनपुट किया जा सकता है। धारणा यह है कि यदि दो मॉडलों के परिणाम समान हैं, तो उपयोग किए गए मॉडल के लिए परिणाम सही होना चाहिए। यह मूल मॉडल बनाने में कोई त्रुटि नहीं पकड़ेगा, लेकिन यह सॉफ्टवेयर कार्यान्वयन में त्रुटियों को पकड़ लेगा।

क्या मॉडल से परिणामों की "शुद्धता" की जांच करने के लिए दो अलग-अलग कार्यक्रमों का इस्तेमाल किया जा सकता है?
दो अलग-अलग कार्यक्रमों में एक मॉडल की तुलना करने की इस पद्धति का उपयोग करने से परिणामों में समान स्तर का आश्वासन मिल सकता है अन्य जाँच के तरीकों की तरह?
इस प्रक्रिया का उपयोग करने के क्या नुकसान हो सकते हैं?

modeling software finite-element-method

— हाज़ी
स्रोत

"स्पेस शटल" 5 x उड़ान कंप्यूटरों का उपयोग करके कक्षा में गया। इनमें से 4 ने एक ही कार्यक्रम चलाया, एक-दूसरे के परिणामों की जाँच की, आपस में सहमति जताई और किसी भी पागल सदस्य को वोट दिया। 5 वें कंप्यूटर ने एक अलग टीम द्वारा स्वतंत्र रूप से लिखे गए एक पूरी तरह से अलग कार्यक्रम को चलाया। 'शायद ज़रुरत पड़े'। मुझे नहीं पता कि क्या इसकी कभी ज़रूरत थी।

— रसेल मैकमोहन

दोनों कंप्यूटर प्रोग्राम एक ही तरह से गलत हो सकते हैं, इसलिए मैं नहीं कहूंगा। यह अच्छा अभ्यास नहीं है। उन मामलों के संख्यात्मक समाधानों की तुलना करना बेहतर है, जिनमें कोई समाधान ज्ञात, विश्लेषणात्मक रूप से, अनुभवजन्य रूप से या प्रकाशित शोध के माध्यम से होता है।

— पॉल

@Paul हाँ, यह है कि चीजों को आम तौर पर जाँच की जाती है, लेकिन यह केवल दिखाता है कि कार्यक्रम उस समस्या के लिए काम करता है। आप यह मान सकते हैं कि क्या समान कोड पथ का उपयोग करने वाले अन्य कॉन्फ़िगरेशन भी सही हैं, लेकिन हमेशा एक किनारे का मामला होगा। दो अलग-अलग कार्यक्रमों का उपयोग करने में शामिल धारणा यह है कि प्रोग्रामर के पास अलग-अलग किनारे के मामलों में त्रुटियां हैं ।

— hazzey

7

हां, दूसरी राय लेना उपयोगी हो सकता है। यह मौसम के पूर्वानुमान में नियमित रूप से किया जाता है जहां सटीक समाधान अज्ञात होते हैं, और विभिन्न कारकों को लागू करने के तरीके के बारे में कुछ निर्णय होता है।

एक परिमित तत्व जाल तनाव विश्लेषण की तरह कुछ में कम wiggle कमरा होगा क्योंकि इसे हल करने के लिए पुनरावृत्ति समीकरण मूल रूप से वही होगा जो सॉफ्टवेयर ने नहीं लिखा था। असली मुद्दा मेष को हल नहीं कर रहा है क्योंकि पहली जगह में एक अच्छा पर्याप्त जाल बना रहा है।

एक तरह से एकाधिक राय प्राप्त करने के लिए जाल के मापदंडों को अलग करना है। उम्मीद है कि आप अभी भी बहुत ही एक ही जवाब मिलता है। यदि आप जाली 2x को महीन बनाते हैं और काफी अलग उत्तर प्राप्त करते हैं, तो यह एक मजबूत सुराग है जो मूल जाल पर्याप्त विस्तृत नहीं था। आप यह भी नहीं जानते कि यह सुनिश्चित करने के लिए कि अगला जाल पर्याप्त विस्तृत है, और भी अधिक विस्तृत किए बिना और उसी उत्तर के बारे में प्राप्त कर सकता है।

बेशक आजकल की पीढ़ी कुछ हद तक स्वचालित और अनुकूली है। यह अब केवल जाल को सुलझाने के भौतिकी के बारे में नहीं है, लेकिन कब और कैसे उपविभाजित करना है इसके बारे में आंकड़े शामिल हैं। इस संबंध में विभिन्न सॉफ्टवेयर अलग-अलग हो सकते हैं, इसलिए एक ही प्रारंभिक डेटा के साथ दो अलग-अलग प्रोग्राम चलाना उपयोगी हो सकता है।

— ओलिन लेट्रोप
स्रोत

6

मैं इसे एक इंजीनियर के दृष्टिकोण से लिखता हूं जो सिमुलेशन सॉफ्टवेयर विकसित करता है।

मुझे लगता है कि वर्णित अभ्यास खराब है, और मैं आपको परिणामों की "पुष्टि" करने के लिए दो अलग-अलग सॉफ्टवेयर्स का उपयोग नहीं करने की सलाह देता हूं।

सामान्य तौर पर, दो अलग-अलग मॉडलिंग सॉफ्टवेयर्स का उपयोग उनकी समानता के अलावा और कुछ की पुष्टि करने के लिए नहीं किया जा सकता है। दो सॉफ्टवेअर आसानी से दो समान लेकिन गलत उत्तर प्राप्त कर सकते हैं, खासकर यदि वे समान मॉडल का उपयोग करते हैं। मैं कम से कम एक उदाहरण के बारे में सोच सकता हूं जहां यह निश्चित रूप से होता है, और ट्रेवर आर्चीबाल्ड एक और उल्लेख करते हैं। मैं दो सॉफ्टवेयर्स से अधिक प्रभावित होऊंगा जो अलग-अलग मॉडलिंग तकनीकों का उपयोग करते हैं जो समान परिणाम प्राप्त करते हैं।

इस विषय को कंप्यूटर मॉडल का सत्यापन और सत्यापन कहा जाता है, और इसमें काफी विशाल साहित्य है। मैं मूल बातें का एक स्केच प्रदान करता हूँ। सत्यापन एक "सटीक" समाधान (जो एक हाथ की गणना, या कुछ अधिक जटिल हो सकता है) के खिलाफ एक मॉडल की तुलना कर रहा है, जो कि सॉफ्टवेयर के गणित की जांच कर रहा है। सटीक समाधान के पीछे की धारणाएं गलत हो सकती हैं, लेकिन बहुत कम से कम आप यह सुनिश्चित करना चाहेंगे कि सॉफ्टवेयर को गणित का हिस्सा सही मिले। सत्यापन एक प्रयोग के खिलाफ एक मॉडल की तुलना कर रहा है। यह आपको यह जांचने की अनुमति देता है कि क्या आप जिस मॉडल का उपयोग कर रहे हैं वह सटीक है, जो कुछ सत्यापन आपके लिए नहीं कर सकता है।

पहले दो जाँच तरीकों के साथ समस्या यह है कि वे या तो केवल विशिष्ट स्थितियों की जाँच करते हैं या वे केवल कार्यक्रम के सरल भागों की जाँच करते हैं।

यह सॉफ्टवेयर डेवलपर्स और उपयोगकर्ताओं के सामने एक वास्तविक समस्या है। इसे संभालने के स्थापित तरीके हैं जो दो अलग-अलग सॉफ्टवेयर्स की तुलना में बहुत बेहतर हैं।

मुद्दा यह है कि आप हर संभव मामले का परीक्षण कभी नहीं कर सकते। आपका सॉफ़्टवेयर केस A पास कर सकता है, लेकिन केस A में भौतिकी X, Y, या Z शामिल नहीं है, और जो आपको केस बी से पूरी तरह से दूर कर देता है। तो, आप जो चाहते हैं, वह बड़ी संख्या में चेक हैं जो कम से कम सभी को कवर करते हैं मूलभूत सुविधाएँ जिन्हें आप जाँचना चाहते हैं। कई सॉफ्टवेयर्स के पास "वी एंड वी स्वीट्स" हैं जो मूल रूप से ठीक हैं।

सत्यापन के संदर्भ में, कई विकल्प हैं। आप विभिन्न मामलों के लिए नए सटीक समाधान उत्पन्न कर सकते हैं। कभी-कभी यह अकेला पर्याप्त होता है। हालाँकि, जैसा कि आपने देखा है, अक्सर आप जो हाथ से कर सकते हैं वह बहुत ही साधारण मामलों तक सीमित होता है। अधिक सामान्य मामलों के लिए, आप एक तकनीक का उपयोग कर सकते हैं जिसे निर्मित समाधान की विधि कहा जाता है (यह Google)। इसके लिए प्रोग्रामिंग की आवश्यकता है और यह गड़बड़ हो सकता है, लेकिन आपको मूल रूप से कुछ भी परीक्षण करने की अनुमति देता है जो आप सोच सकते हैं। (मेसनेस पार्ट को MASA जैसी लाइब्रेरी के जरिए संभाला जा सकता है ।)

इसके अलावा, मैं यह बताना चाहूंगा कि ओलिन लेथ्रॉप के विपरीत, निर्मित समाधानों की विधि के साथ, आप परीक्षण के उद्देश्य, सटीक समाधानों के लिए क्या उत्पन्न कर सकते हैं। वे सख्त अर्थ में "सटीक" नहीं हैं, क्योंकि वे उन समीकरणों को पूरी तरह से संतुष्ट नहीं करते हैं जो सॉफ्टवेयर बिना संशोधन के हल कर रहे हैं। लेकिन वे समीकरणों को संतुष्ट करते हैं जो बहुत करीब हैं, और अंतर को कठोर बनाने के लिए जिम्मेदार है। यह तकनीक इस समय बहुत लोकप्रिय नहीं है, लेकिन इसका उपयोग उन चीजों का परीक्षण करने के लिए किया गया है जिन्हें पहले परीक्षण करना मुश्किल माना जाता था।

सत्यापन के संदर्भ में, आप अधिक प्रयोगात्मक डेटा देख सकते हैं या अपने स्वयं के प्रयोग चला सकते हैं।

— बेन त्रेतल
स्रोत

4

मुझे लगता है कि यह कुल मिलाकर एक अच्छा अभ्यास है।

दो अलग-अलग सॉफ्टवेयर्स का उपयोग करके, आप दो प्रकार की त्रुटियों से बच सकते हैं: 1) त्रुटियां जो एक त्रुटिपूर्ण सॉफ़्टवेयर से आती हैं (जिसे अनदेखा नहीं किया जाना चाहिए), 2) सॉफ़्टवेयर के साथ उपयोगकर्ता की आदत की कमी से आने वाली त्रुटियाँ (छिपे हुए विकल्प, डिफ़ॉल्ट सेटिंग्स ...)।

यदि सॉफ्टवेयर्स पर्याप्त भिन्न हैं, तो दो बार एक ही गलत परिणाम प्राप्त करने की संभावना कम है।

हालाँकि, एक गलत मॉडलिंग विकल्प से आने वाली त्रुटियों को इस तरह से टाला नहीं जा सकता है। इसलिए मैं कहूंगा कि मुख्य नुकसान नतीजों पर भरोसा करना है क्योंकि उनकी पुष्टि दो सॉफ्टवेयर्स ने की है।

मुझे लगता है कि कई सॉफ्टवेयर परीक्षण (उदाहरण के लिए शैक्षणिक परिणामों की तुलना), कई सॉफ्टवेयर्स का उपयोग करने और केवल एक औसत ज्ञान रखने की तुलना में, एक सॉफ्टवेयर में मास्टर करना बेहतर है। इसके अलावा, मुझे लगता है कि एफईएम विश्लेषण की मूल बातें जानना सबसे अच्छा है, और केवल दो "वन-क्लिक-टू-रन" सॉफ्टवेयर्स का उपयोग करना एक बुरा अभ्यास है क्योंकि उपयोगकर्ताओं को मॉडलिंग त्रुटियों को पुन: पेश करने की संभावना है।

पुनश्च: मैं एक इलेक्ट्रोमैग्नेटिज्म / थर्मल एफईएम विश्लेषण उपयोगकर्ता (कोई अन्य डोमेन नहीं) के रूप में लिख रहा हूं।

— TZDZ
स्रोत

2

डिज़ाइन इंजीनियर के दृष्टिकोण से उत्तर

दूसरे के खिलाफ एक कार्यक्रम के परिणामों की जाँच करने से आपको निश्चितता का कुछ स्तर मिलेगा कि परिणाम सही हैं। यह आपको 100% निश्चितता देने की संभावना नहीं है, लेकिन फिर उस स्तर की निश्चितता हासिल करना कठिन है।

एक बड़ा मुद्दा जो मैं देख रहा हूं वह मॉडल को सॉफ्टवेयर के एक टुकड़े से दूसरे में स्थानांतरित करने में सक्षम है। हालाँकि ज्यादातर सॉफ्टवेयर कंपनियों (BIM की वजह से) मॉडल आयात / निर्यात में सुधार हो रहा है, लेकिन मैं किसी मॉडल की सभी सुविधाओं को निर्यात करने की उम्मीद नहीं करूँगा। जियोमेट्री का आयात / निर्यात करना अपेक्षाकृत आसान है क्योंकि एक्सचेंज फाइल में केवल निर्देशांक होते हैं। लेकिन उदाहरण के लिए सदस्य समाप्ति रिलीज़ को अलग-अलग सॉफ़्टवेयर द्वारा बहुत अलग तरीके से संग्रहीत किए जाने की संभावना होती है, इसलिए जब तक / जब तक कि एक सार्वभौमिक फ़ाइल विनिमय प्रारूप पर सहमति न हो, मुझे संदेह है कि दूसरे सॉफ़्टवेयर प्रोग्राम में एक मॉडल को पूरी तरह से फिर से बनाने के लिए बहुत प्रयास की आवश्यकता होगी।

मेरे स्वयं के अनुभव के आधार पर, परिणामों में त्रुटियां डेटा के गलत इनपुट या गलत मान्यताओं से आने की अधिक संभावना है, क्योंकि वे खराब लिखे गए सॉफ़्टवेयर से हैं। किसी उत्तर को सत्यापित करने के लिए स्वतंत्र सॉफ़्टवेयर का उपयोग करने का समय और प्रयास इसलिए संभवत: आपके समय का अच्छा उपयोग नहीं है।

सॉफ्टवेयर इंजीनियर के दृष्टिकोण से उत्तर

अन्य सॉफ़्टवेयर के विरुद्ध सॉफ़्टवेयर को सत्यापित करने का औचित्य नहीं है क्योंकि आपका सॉफ़्टवेयर सही है। प्रकाशित डेटा / परिणाम खोजने के लिए यह बेहतर है कि सॉफ्टवेयर को सही उत्तर देने के लिए सत्यापित किया जा सकता है। एक बिक्री बैठक की कल्पना करें जहां एक सॉफ्टवेयर कंपनी अपने सॉफ्टवेयर को इंजीनियरिंग कंपनी को बेचने की कोशिश कर रही है:

इंजीनियर: हमें कैसे पता चलेगा कि आपका सॉफ्टवेयर सही है?

सॉफ्टवेयर सेल्समैन: ठीक है, हमने अपने प्रतियोगी सॉफ्टवेयर के खिलाफ इसकी जाँच की और उसी उत्तर को मिला।

इंजीनियर: तो आप कह रहे हैं कि आपका प्रतियोगी आपके लिए पर्याप्त रूप से बेहतर है कि उसका सॉफ़्टवेयर वो यार्डस्टिक है जिसके विरुद्ध आप अपना सॉफ़्टवेयर मापते हैं? लगता है जैसे हम उसके बजाय सॉफ्टवेयर खरीदना चाहिए!

— AndyT
स्रोत

1

मुझे उम्मीद है कि सॉफ्टवेयर इंजीनियर विज्ञापन नहीं करेगा कि सॉफ्टवेयर की तुलना किसी अन्य प्रोग्राम से की जाए, भले ही लैब में ऐसा हो। मुझे यह भी लगता है कि एक सॉफ्टवेयर इंजीनियर इस बात की सराहना करेगा कि ऐसे मामले हो सकते हैं जो पूरी तरह से यूनिट परीक्षणों से ढके नहीं हैं।

— हाजी

2

मैं यहां अन्य उत्तरों के साथ सहमत हूं, कि यह सामान्य रूप से एक अच्छा विचार हो सकता है और सिमुलेशन परिणामों की सटीकता सुनिश्चित करने में मदद करेगा। अन्य सत्यापन विधियों के संबंध में यह कितना अच्छा है, इस संबंध में, मैं पहले से ज्ञात परिणाम और भौतिक परीक्षण दोनों बेहतर विकल्प कहूंगा यदि संभव हो तो, लेकिन यदि मॉडल पर्याप्त रूप से जटिल है तो हाथ की गणना को अधिक सरलीकरण की आवश्यकता हो सकती है।

जो मैं वास्तव में इंगित करना चाहता हूं वह कुछ ऐसा है जिसे अंतिम बिंदु पर संबोधित नहीं किया गया है: इस अभ्यास की संभावित कमजोरियां। दो अलग-अलग FEA पैकेजों का उपयोग करने से एक पैकेज की ख़ासियत हो सकती है जो एक त्रुटि का कारण बनता है, बशर्ते आप यह पहचान सकें कि कौन सा विश्लेषण सही है और कौन सा बंद है। हालांकि, FEA कुल मिलाकर कुछ सामान्य सीमाएँ हैं, भले ही विधि या कार्यान्वयन की परवाह किए बिना। तेज कोनों और अन्य तनाव सांद्रता जो मॉडल में विलक्षणता का कारण बनते हैं वे कुछ ऐसे नहीं हैं जो पैकेज से पैकेज में बहुत बदल जाएंगे, ये हमेशा कमजोर स्पॉट होंगे। यह वह जगह है जहाँ इंजीनियरिंग ज्ञान और अंतर्ज्ञान की आवश्यकता होती है।

मैंने उन हिस्सों पर सिमुलेशन किया है जिन्हें मैं जानता हूं कि कुछ तनावों के लिए आसानी से खड़े हो जाओ, और मॉडल से पता चलता है कि आंतरिक तनाव उपज की ताकत से 10x है; यह स्पष्ट रूप से गलत है, क्योंकि यह एक इनवैलिड स्पलाइन पैटर्न पर है और FEA सॉफ्टवेयर इसे पसंद नहीं करता है।

अंत में, यह स्पष्ट होना चाहिए कि सॉफ्टवेयर बदलना उपयोगकर्ता की त्रुटि को समाप्त नहीं करता है। यदि आप मॉडल या पैरामीटर्स में कोई त्रुटि करते हैं, तो वह त्रुटि आपको बिना किसी समस्या के पेंच देगी, जिसका आप विश्लेषण करने के लिए उपयोग करते हैं।

— ट्रेवर आर्चीबाल्ड
स्रोत

मुझे पता नहीं है कि एक "इनवैलिड स्पलाइन पैटर्न" क्या है, इसलिए यह टिप्पणी प्रासंगिक नहीं हो सकती है, लेकिन यदि आप 10x उपज पर आंतरिक तनाव प्राप्त कर रहे हैं, तो शायद एक गैर-रेखीय सामग्री के साथ मॉडलिंग क्रम में होगी? यह चरम स्थानीय तनाव सांद्रता को दूर करेगा।

— एंडी

इस बिंदु पर, मुझे याद नहीं है कि क्या मैंने एक रैखिक-लोचदार सामग्री प्रतिक्रिया या कुछ और बुनियादी उपयोग किया था, लेकिन मैं सिमुलेशन को हमेशा के लिए नहीं चलाना चाहता था, और यह हमारे लिए FEA का शुरुआती उपयोग है। यह अनिवार्य रूप से एक मौजूदा हिस्से का एक नया स्वरूप था, जिसके लिए हम विफलता मोड को जानते हैं, और जिस तरह से हमें मॉडल स्थापित करना था, उसने कुछ कठिन बाधाओं को रखा (एक अचूक पट्टी अधिकांश गियर दांतों का आकार है)। यदि मैं अधिक व्यापक विश्लेषण कर रहा था, तो मैं कोशिश कर सकता हूं और इसे ठीक कर सकता हूं, लेकिन मौजूदा भाग की तुलना में यह अवधारणा का अधिक प्रमाण था।

— ट्रेवर आर्चीबाल्ड

1

सीमा की स्थिति और मॉडलिंग तकनीक परिणामों को बहुत प्रभावित करेगी। मैं जो सुझाव देता हूं वह एक सरलीकृत / आदर्शित संस्करण (जैसे प्लानर, या एक्सिसिमेट्रिक) और एक पूर्ण ठोस एक और दोनों की तुलना करके चल रहा है।

दो अलग-अलग एफईए सॉफ्टवेयर के साथ समस्या यह है कि हुड के तहत सॉल्वर काफी हद तक एक ही होने जा रहे हैं। देखा गया अंतर शायद विभिन्न अभिसरण मानदंडों से हो सकता है, या सीमा की स्थिति को कैसे लागू किया जाता है, इस पर अलग-अलग धारणाओं से होगा। आप मॉडल की जांच नहीं कर रहे हैं, लेकिन प्रत्येक सॉल्वर की यह जानने की क्षमता एक समाधान तक पहुंच गई है।

मुझे लगता है कि FEA परिणाम अगर भागों असफल देखने के लिए समान है, लेकिन अलग-अलग मॉडल (ठोस बजाय उदाहरण के लिए मुस्कराते हुए) और अंत में शारीरिक परीक्षण के द्वारा, पहले सामान्य ज्ञान और हाथ गणना द्वारा मान्य किया जाना चाहिए तो जहां और कैसे FEA भविष्यवाणी की है। जब एक हिस्सा असफल हो जायेगी और अधिक कठिन है क्योंकि यह विनिर्माण प्रक्रियाओं, सामग्री विविधताओं और resudial तनाव से infuenced जाता है।

— ja72
स्रोत

सभी इंजीनियरिंग विषयों में भौतिक विनाश परीक्षण करने में सक्षम होने की विलासिता नहीं है। सिविल और स्ट्रक्चरल इंजीनियरिंग में बड़ी संख्या में परियोजनाएं एक से एक अनूठी वस्तुओं का निर्माण कर रही हैं - पूरी तरह से अलग बनाने के लिए इसे नष्ट करने के लिए परीक्षण करना पूर्णतः महंगा होगा!

— एंडी

मुद्दा लेना। यह अभी भी परीक्षण के साथ FEA परिणामों को मान्य करने के लिए एक अच्छा विचार है, भले ही यह नमूना या स्केल टुकड़ों के साथ हो।

— ja72

मैं आपकी बात देख सकता हूं ... लेकिन अपने छह साल के ब्रिज डिजाइन में मैंने कभी किसी ब्रिज के स्केल मॉडल पर किए गए फिजिकल टेस्ट के बारे में नहीं सुना।

— एंडी

तो मुझे कौन से पुलों से बचना चाहिए? मजाक। तो FEA के साथ सामान नहीं मॉडल के लिए सुरक्षा के पर्याप्त मार्जिन होना चाहिए। 100% सटीक FEA मॉडल के रूप में ऐसी कोई बात नहीं है।

— ja72

दरअसल, हमारे पास हर जगह सुरक्षा के कारक हैं! ब्रिटिश मानक BS5400 में gammaf3 नामक 1.1 का एक कारक शामिल था, जो "लोडिंग के प्रभावों का गलत आकलन, संरचना में अप्रत्याशित तनाव वितरण, और निर्माण में हासिल की गई आयामी सटीकता में बदलाव का कारक है। । " यानी जो भी आपका FE विश्लेषण आपको बताता है कि तनाव है, इसे 1.1 से गुणा करें, यदि यह एक अनौपचारिक मूल्य है।

— एंडी