Enhet 10 / 11

Engineering Calculation Automation med Python

Gevinster:

  • Evne til å automatisere ingeniørberegning, enhetsadministrasjon og databehandling med AI-drevet Python-kode
  • Evne til å validere AI-kode med enhetskontroll, testing av kjente resultater og kanttilfeller
  • Evne til å få en vane med å produsere repeterbare, sporbare og versjonskontrollerte kontodokumenter

I maskinteknikk gjøres den samme beregningen om og om igjen: spenninger i en familie av deler, pumpekraft for en rekke driftspunkter, egenskapstabeller ved forskjellige temperaturer. Å gjøre disse manuelt er både sakte og utsatt for feil. Python (et programmeringsspråk som er lett å lære med rike biblioteker for engineering) automatiserer disse iterasjonene; Det gjør kontoen repeterbar, sporbar og versjonskontrollert. Kunstig intelligens (AI) Python er utrolig rask til å generere kode: konvertere en formel til en funksjon, legge til enhetsadministrasjon, lese data, plotte grafer. Men det er en farlig misforståelse her: bare fordi koden fungerer uten feil betyr ikke det at den beregner riktig. AI-koden kan stille tilbake feil resultater på grunn av feil enhetskonvertering, feil formel eller i edge-tilfeller, og programmet vil fortsette å kjøre uten feil. Det er derfor hver ingeniørkode produsert med AI; Testinndata med kjente resultater er upålitelige uten verifisering ved enhets- (størrelse)kontroll og kanttilfelleforsøk. I denne enheten lærer du hvordan du trygt setter opp Python-kontoautomatisering med AI.

Hvorfor kodekonto? Sporbarhet og reproduserbarhet

En manuell beregning er en engangsberegning; Når en inngang endres, gjøres det fra bunnen av og mellomtrinn går tapt. Beregning gjort i kode er som et dokument: inndata, formler og utdata er tydelig skrevet; du endrer en inngang og får et nytt resultat i løpet av sekunder; Med versjonskontroll (som git), kan "hva jeg beregnet med hvilken verdi på hvilken dato" spores. Dette er uvurderlig med tanke på kontroll og ansvarlighet. Men denne kraften avhenger av kodens korrekthet; En feil kode gir feil resultat, også reproduserbart og raskt.

Tips: Skriv en test for hver beregningsfunksjon med et kjent sant resultat ved siden av (hevd i Python). For eksempel bør stressfunksjonen din gi 28,1 MPa i en kjent prøve. Denne testen varsler deg umiddelbart hvis du bryter noe når du endrer koden i fremtiden. Ingeniørkode som ikke er testet er en ubekreftet konto.

Volumstyring: Den vanligste feilkilden

I ingeniørkoden kommer de fleste feilene fra enheter: N med kN, m med mm, Pa med MPa, som kan forveksles med en faktor på 1000 eller 1.000.000. Det er to forsvar. Den første er disiplin: å velge et enkelt enhetssystem fra begynnelsen (f.eks. N, mm, MPa) og konvertere alle innganger til det og legge til enheter til variabelnavnene (lengde_mm, kraft_N). Det andre er verktøyet: et bibliotek som pint bærer enhetene i koden og fanger opp den inkonsekvente operasjonen som en feil.

Tilnærming

Hvordan fungerer det

Fordel

Navnedisiplin

som kraft_N, lengde_mm

Enkelt, ingen avhengigheter

enkelt enhetssystem

Alt konvertert til N-mm-MPa

Enkelhet, hastighet

halvliter bibliotek

Flytter enhet for variabel

Fanger automatisk inkonsekvens

Kjent resultattest

referanse med hevde

Fanger formel/enhetsfeil

Forsiktig: En enhetskonvertering kan mangle eller være feil i den AI-genererte koden, og koden vil fortsatt "fungere". Hvis for eksempel diameteren er mm og arealet forventes å være m², vil resultatet avvike 1 000 000 ganger, men programmet vil ikke gi feil. Før du kjører koden, kommenter enhetene for innganger og utganger; deretter gi resultatet med et kjent eksempel.

Trinn for trinn: AI-verifiserbar kontokode

  1. Avklar problemet og enhetssystemet. Innganger, utganger, enheter.
  2. Generer funksjonen. Enkelt ansvarlig, fortolkende, forent.
  3. Legg til test av kjente resultater. Påstå med referanseeksempel.
  4. Prøv kantsaker. Null, negativ, veldig stor/liten inngang.
  5. Gjør en enhetssjekk. Stemmer produksjonsenheten med det som forventes?
  6. Dokument og versjon. Forutsetninger, kilde, dato; sporbarhet med git.

Spørring som genererer funksjoner og tester

Rolle: Erfaren Python-utvikler som skriver tekniske beregninger. Oppgave: Skriv en funksjon som beregner maksimal bøyespenning i en rektangulært tverrsnitt utkragende bjelke. Inngang: F (N), L (mm), b (mm), h (mm). Utgang: sigma (MPa). Konvensjon: Enhetssystem N-mm-MPa; kommenter enheten for hver oppføring. Regel: bruk I = b*h^3/12 og sigma = M*c/I; kommentere trinnene.Regel: Legg til en test med KJENT RESULTAT: sigma ~28.1 MPa for F=500,L=300,b=20,h=40; Sjekk med påstand (liten toleranse).

Edge status melding

Legg til kanttilfellesjekker til funksjonen ovenfor:- Hvis b, h eller L er null eller negativ, gi en signifikant feil (raise ValueError).- Kommenter om det er et overløp/presisjonsproblem med veldig store/små innganger. Legg også til 3 flere forskjellige testinndata og skriv det forventede resultatet; forklare resultatene på en måte som jeg kan verifisere dem manuelt.

Spørre om enhetssikkerhet (liter).

Unit-safe den samme kontoen med 'pint'-biblioteket. La innganger defineres i enheter (f.eks. 500 * ureg.newton). Konverter utdataene til MPa og skriv det ut. Legg til et lite eksempel som viser hvordan pint mislykkes når det gis en inngang med feil enhet.

Kodekontrollspørsmål

Kritikk min tekniske beregningskode nedenfor fra et kodegjennomgangsperspektiv, ikke enig med meg. Spesielt: er enhetskonverteringen riktig, er formelen riktig, har kanttilfeller (null, negativ) blitt vurdert, er testene virkelig bekreftende? For hvert funn, skriv hvordan du fikser det.[kode]

Svak forespørsel / sterk forespørsel

Svak melding:

Skriv Python-kode for spenningsberegning.

Ingen valg av enheter, formler, inngangsdefinisjoner og tester; AI genererer kode som fungerer, men som er ubekreftet og hvis enhet er ukjent.

Kraftig ledetekst:

Skriv bøyespenningsfunksjonen i utkragningsbjelken. Inngang F(N), L(mm), b(mm),h(mm); utgang sigma(MPa). N-mm-MPa system, spesifiser hver enhet i kommentarfeltet. Legg til en test med kjente resultater (F=500, L=300, b=20, h=40 → ~28,1 MPa, påstå). Gi en feil på null/negativ inngang. Tolke kantsaker.

Den andre ledeteksten krever enhetssystem, formel, innganger, test- og kanttilfeller; Det gjør koden verifiserbar.

Tre minietuier (etter tall)

Tilfelle 1 - Stille volumfeil. Arealberegningen produsert av AI tar diameteren i mm og gir mm² med pi*d**2/4, men neste linje setter den inn i en formel som forventer m²; Koden fungerer uten feil og gir stressen 1 000 000 ganger lavere. Når teknikeren kjører testen med et kjent resultat (assert abs(sigma-28.1)<0.5), eksploderer testen og feilen fanges opp. Hvis det ikke var noen test, ville feil resultat ha kommet inn i rapporten ubemerket. Leksjon: arbeidskode ≠ riktig kode.

Tilfelle 2 - Kanttilstandskrasj. I koden som går i løkker for en delfamilie, legges tykkelse h=0 inn på én linje; Når I = b*h**3/12 = 0, gir sigma = M*c/I en divisjon med null feil. Takket være if h<=0: raise ValueError-kontrollen lagt til av AI, stopper koden med en meningsfull melding og produserer ikke inf. Leksjon: håndter kantsaker på forhånd.

Tilfelle 3 - Repeterbarhetsgevinst. Det tok en ingeniør en halv dag å manuelt beregne pumpeeffekten for 40 forskjellige driftspunkter. Skriptet, skrevet i AI, leser CSV-en, beregner kraften for hver linje og verifiserer et kjent punkt med assert, reduserer arbeidet til ~2 minutter og skriver resultatene til en sporbar fil. Når en oppføring endres, oppdateres hele tabellen hvert sekund. Leksjon: Verifisert automatisering er både rask og pålitelig.

Vanlige feil

  • "Fungert = riktig" feilslutning: Å tro at koden som fungerer uten feil er riktig.
  • Ikke skrive tester: Stole på kode uten referansetest med kjent resultat.
  • Unit tvetydighet: Forlater input/output enheter utolket, hopper over konvertering.
  • Ignorerer kanttilfeller: Stille feil eller krasj ved null/negativ inngang.
  • Ikke dokumentere kilden/antakelsen: Ikke skrive ned kilden og antakelsen om formelen som er brukt.
  • Ikke versjonering: Forlater kontoen som en engangsfil uten å gjøre den sporbar (git).

Oppsummert

  • Python gjør ingeniørberegninger repeterbare, sporbare og versjonskontrollerte.
  • AI er veldig rask til å generere kode; Men det at koden fungerer uten feil betyr ikke at den regner riktig.
  • Hver kode bør valideres gjennom testing av kjente resultater, enhetskontroll og kanttilfeller.
  • Enhetsfeil er den hyppigste og mest lumske feilkilden; Forsvar av enkeltenhetssystem, nomenklatur eller halvliter.
  • Validert automatisering sparer tid og gir selvtillit; Ubekreftet kode er farlig.

Søknadsoppgave

Velg en tilbakevendende ingeniørberegning (som stress, pumpekraft, varmebelastning). Skriv en Python-funksjon til AI-en som gjør denne beregningen; Kommenter enheten for hver inngang og utgang og legg til en påstandstest med et kjent resultat. Kjør testen og se om den består. Gjør så to verifikasjoner til: prøv en kant-case (null eller negativ inngang) for å sjekke at koden returnerer en signifikant feil, og angi enheten for utgangen manuelt i et eksempel. Få om mulig også en enhetssikker versjon produsert i halvliter. Til slutt legger du til beregningens forutsetninger, formelkilde og dato i koden som en kort tittel og skriv hvorfor denne koden fortsatt krever ingeniørgodkjenning.

sjekkliste

  • [ ] Inn- og utdataenheter er tydelig dokumentert i koden; enkeltenhetssystem ble valgt.
  • [ ] En test (påstå) med kjent resultat ble lagt til og bestått.
  • [ ] Minst én kant-case (null/negativ) ble forsøkt; Koden ga en betydelig feil.
  • [ ] Utgangsenheten ble gitt av et manuelt eksempel (ikke forutsatt at "fungerte = riktig").
  • [ ] Formelkilde, forutsetninger og dato notert i koden.
  • [ ] Konto holdes sporbar/sporet; endelig godkjenning ble overlatt til ingeniøren.