Ingenieurs gebruiken software omdat computers duizenden keren sneller repetitieve analyses en ontwerpberekeningen kunnen uitvoeren, dan wanneer ze dit handmatig moeten doen met pen en papier. In theorie leidt ieder ingegeven ontwerp tot hetzelfde resultaat, maar als je aan 10 ingenieurs vraagt om dezelfde berekening te maken met rekensoftware, zal er toch wat spreiding op die resultaten zitten. We interviewen Dorien Elleboog, support engineer bij BuildSoft, over de waarde van software- en berekeningsvalidatie.
Beginnen bij het begin: wat is validatie?
“Validatie”, in z’n ruimste betekenis, houdt in dat je door middel van verificatie aantoont dat een apparaat, systeem, wiskundig model of instrument met een grote mate van zekerheid, in staat is om de bedoelde resultaten op te leveren.
Als we dat concept projecteren op software voor structurele analyse, dan komt het erop neer dat je enerzijds moet controleren of de data correct werden ingegeven in de software en anderzijds of de software geldige methodes voor z’n analyses en ontwerp gebruikt.
Waarom is validatie zo belangrijk?
Je mag nooit uit het oog verliezen dat rekensoftware een hulpmiddel is. Je moet software zien als een rekenmachine die een bepaalde input (= de geometrie, de lasten) door bepaalde algoritmes (= zoals de mesh- en analyse instellingen) laat lopen en daarmee een bepaalde output (= resultaten) genereert. Daarbij gebeurt er geen controle op de samenhang of logica van die input. Als je rommel invoert, krijg je rommel als resultaat.
Op geen enkel ogenblik is Diamonds, of eender welke rekensoftware, in staat om een interpretatie of oordeel over die input of output te vellen.
Je mag nooit uit het oog verliezen dat rekensoftware een hulpmiddel is. Je moet software zien als een rekenmachine die een bepaalde input (= de geometrie, de lasten) door bepaalde algoritmes (= zoals de mesh- en analyse instellingen) laat lopen en daarmee een bepaalde output (= resultaten) genereert. Daarbij gebeurt er geen controle op de samenhang of logica van die input. Als je rommel invoert, krijg je rommel als resultaat.
Op geen enkel ogenblik is Diamonds, of eender welke rekensoftware, in staat om een interpretatie of oordeel over die input of output te vellen.
Wie doet die validatie?
Het controleren of de input van de data tot het gewenste (te verwachten) resultaat leidt, is naar mijn mening persoonlijk en project gebonden.
- Laat me het woord “persoonlijk’ beter toelichten. Stel: ik geef een bepaalde input aan software, ik controleer de resultaten en concludeer dat die zinvol zijn. Maar wat is dat statement waard als ik niet deel welke input ik gebruikte en hoe ik die ingegeven heb? Want zonder die info, kan niemand leren hoe je die input goed doorgeeft.
- “Project gebonden”, want ieder project heeft z’n eigen problematiek. De validatie van het ene project, is niet noodzakelijk geldig voor het andere.
Dus ik hoop dat niet enkel de gebruikers van onze software hun eigen berekeningen valideren, maar ook die van hun collega’s. Want die discussies, het delen van inzichten en kennis, zijn van onschatbare waarde.
Verder mag je de externe controlemechanismes, zoals Kiwa en Seco, niet vergeten.
Kiwa is een bedrijf gespecialiseerd in de certificering van allerhande processen, waaronder ook rekensoftware. SECO wordt dan eerder ingeroepen om bestaande berekeningen van belangrijk projecten te controleren.
Valideren jullie zelf jullie software?
Absoluut! Voor iedere release worden de nieuwe én bestaande features (zoals rekenmethodes voor analyse en ontwerp) getest.
Ik heb lang gezocht naar een manier om die testen op een eenvoudige manier te publiceren, en ondertussen staat een selectie van deze validatie-testen op onze support-website.
Er is geprobeerd om een breed spectrum aan berekeningen te behandelen: lasten, beton, staal, brand, statische en modale analyse. Deze lijst is een “work-in-progress”. Als ik ergens een rekenvoorbeeld tegenkom dat een meerwaarde kan zijn voor de lijst, dan wordt het toegevoegd.
De voorbeelden werden soms letterlijk overgenomen uit de literatuur, soms werden ze erop geïnspireerd of soms zijn het pure handberekeningen.
Ik hoop dat die voorbeelden onze gebruikers meer inzicht geven over de werking van onze software.
Handberekeningen, is dat een eerste stap in de richting van validatie?
Het is een goede gewoonte om een idee te hebben over de grootte-orde van de te berekenen resultaten. Een handberekening is hier zeker op z’n plaats.
Het doel van een handberekening is niet om exact hetzelfde resultaat als de software uit te komen, maar wel een “aanvaardbaar” resultaat.
Als algemene regel mag je aannemen dat als de resultaten uit een handberekening minder dan 10% afwijken van het software resultaat [1], dat zowel de software als je handberekening juist zijn. Wijken de resultaten meer dan 20% af, dan heb je ergens een fout gemaakt. Uitgaande dat de handberekening juist is, zit de fout hoogstwaarschijnlijk in:
- een foutieve ingave
Vb: verkeerde randvoorwaarden, verkeerde betondekking, - het niet begrijpen hoe (standaard) instellingen werken
Vb: instellingen voor de mesh - het niet begrijpen hoe de software werkt
Vb: onnodig excentriciteiten gebruiken - het niet begrijpen wat de beperkingen van de software zijn
Vb: gedrongen of volume elementen modelleren in een software die er niet voor geschikt is.
Hieronder enkele specifieke voorbeelden in Diamonds om dat te verduidelijken:
- Wanneer de mesh wordt gegenereerd, detecteert het mesh algoritme in Diamonds of twee oppervlakken aan elkaar grenzen of niet. Als twee oppervlakken aan elkaar grenzen, wordt hun gemeenschappelijke rand roze gekleurd. Wanneer een oppervlak niet grenst aan een ander oppervlak, wordt de relevante rand groen gekleurd. Een groene rand is dus equivalent aan een rand waar geen krachten worden overgedragen.
Stel, ik maak een Diamonds model waarin de muren van twee verdiepingen niet perfect boven elkaar staan. Het mesh algoritme ziet dat de muren niet netjes uitgelijnd zijn en kleurt de rand tussen de twee muren groen… terwijl die eigenlijk roze zou moeten zijn want ik wil dat die twee muren aan elkaar hangen.
Op geen enkel moment zal Diamonds zeggen: “Hé Dorien, let op, want ik denk dat deze twee muren niet mooi boven elkaar staan!”. Want voor Diamonds zijn dat geen twee muren boven elkaar, maar twee oppervlakken die ergens in een 3-dimensionale ruimte staan.
Op het eerste gezicht is er niets mis met deze geometrie.
Als je de positie van de groene randen controleert, zie je dat er iets niet pluis is.
- Diamonds berekent de doorbuiging van een plaat, maar kan niet controleren of die doorbuiging voldoet. Dat komt door de overspanningslengte: als de plaat geen voorkeursdraagrichting heeft en een grillige vorm zoals in onderstaand voorbeeld, dan zijn er veel mogelijkheden voor de overspanning: de gele, de oranje, de blauwe, de groene, … lijn. Ik kan hier als constructief/ structureel ingenieur een zinvolle keuze in maken, maar Diamonds kan dat niet. Want het programma ziet enkel lijnen die onderdeel uitmaken van een vloer.
Handberekeningen, is dat dan de heilige graal?
Nee. Ik denk dat iedere manier van rekenen of elke tool om te rekenen, z’n beperkingen heeft. Ook handberekeningen. Rekensoftware kan met effecten rekening houden die in handberekeningen verwaarloosd worden… Terwijl die effecten in de praktijk niet te verwaarlozen zijn! Dus enige oplettendheid is wel aan de orde.
Zijn er nog manieren om aan validatie te doen?
Oordelen of een resultaat al dan niet zinvol is, vraagt enige ervaring. Die intuïtie leer je jezelf aan door kritisch te zijn, zaken te vereenvoudigen en te ontleden.
Een handberekening zal zeker helpen, maar ook de meerwaarde van opleidingen, een interne kennisbank, interne procedures en de ondersteuning door meer ervaren collega’s zijn niet te onderschatten. Je moet als ingenieur je hele carrière lang open staan om te leren.
“Een ingenieur is eeuwig student”
Bij BuildSoft geven we minstens 3 keer per jaar opleidingen over het gebruik van de software (ga naar de kalender). Dat gaat van op de juiste knopjes klikken, tot Eurocode helemaal uitspitten om te weten te komen waarom het nu is zoals het is. Verder hebben we ook een uitgebreide kennisbank en online opleidingen via e-learning.
Heb je nog tips voor de lezers?
Ik denk dat de meest onderschatte feature van Diamonds, de mesh configuratie is. Zie het voorbeeld van enkele vragen terug.
Nog te vaak krijg ik de indruk dat gebruikers denken: “Diamonds rekent, dus de resultaten zullen wel zinvol zijn”. Bij het ontwerp komen dan toch wat rariteiten naar boven en valt de vraag “Van waar komt dat?”. Ik vrees dan voor de onoplettende gebruiker, die de rariteiten in de resultaten niet opmerkt… Terwijl 98% van de problemen met een model eigenlijk al zichtbaar zijn in de mesh. Dus ik kan het niet genoeg herhalen “controleer de mesh”. Oefening baart kunst.
Literatuur:
[1] Validating the results of structural engineering software, Cliff Swinger (Structure magazine article)
[2] Quality assurance for structural engineering firms, Cliff Swinger
