LCAbyg-Templates
Version 1
UPDATE: 2025-07-01
Den 1. Juli udkom der nye krav til CO2 ud ledelse og samme med dette nyt generisk datagrundlag for LCA-beregning. Nye generisk datagrundlag som ikke er blevet indarbejdet i en ny version af LCAbyg, i stedet har LCAbyg udgivet et nyt datasæt med de nye genriske data, som man skal importere ind i LCAbyg.
Jeg vil ikke udkomme med en opdateret template, da det ikke er muligt. Efter at have undersøgt om det var muligt at lave en template med datasættet importeret i sig, kan jeg konkludere at det importerede materiale, BR25 datasættet, ikke kan fungere i en template, da jeg oplever at hvis man lukker filen ned efter at have importeret det nye datasæt, vil det ikke længere være synligt i UI, men hvis man prøver at importere datasættet igen vil man få meddelt en fejl der rapportere at dataene allerede findes i filen.
Jeg vil derfor ikke foreløbigt lave en ny template da workflowet alligevel ikke vil ændres.
Nogle ting man lige skal være opmærksom på ved brug af det nye datasæt:
GenDK23 biblioteket er ikke længere gyldigt.
Særlige forhold er midlertidigt ikke gyldig.
Spild og transport er midlertidigt ikke gyldig.
Grænseværdier viser ikke de nye krav – dette må gøres i Excel.
Det nye datasæt skal importeres hver gang det skal bruges.
Indledning
Når vi starter et nyt LCAbyg-projekt, gentager vi ofte de samme manuelle indtastninger: biblioteker, bygningsdele, klassifikationer, standardkonstruktioner osv. Hvad nu hvis vi kunne spare tid ved at have ét gennemprøvet “skelet” – en template – som fundament for alle vores projekter? I dette indlæg deler jeg mine erfaringer og overvejelser omkring at skabe netop dét: fleksible og fase-tilpassede LCAbyg-templates.
Først skal vi sætte os ind i hvad der er af muligheder for at oprette templates indenfor LCAbyg.
Der er tre typer:
- .lb5-Filer
- JSON
- CSV
Lad os starte med .lb5-filer. .lb5 formatet er LCAbyg’s eget filformat, der er ikke så meget at lære om .lb5-filformatet i brugervejledning eller på hjemmesiden, men man kan åbne filerne i VScode eller lignende program. Hvis man åbner filerne, vil man se at .lb5-filer bygger på JSON-formatet.
Ud fra hvordan programmet er skruet sammen, er der så at sige ikke en måde at lave en rigtig “.lb5-template” på, men man kan oprette og udfylde et normalt LCAbyg projekt, til en sådan grad hvor projektet indeholder alt hvad man kunne tænke sig alle nye projekter indeholder. Derefter kan man gemme projektet ned og Ctrl+C, Ctrl+V det hver gang man skal lave et nyt LCAbyg projekt. Hvis man har en A104 mappestruktur liggende et sted, som altid bliver kopieret ud på nye projekter, kan man eventuelt ligge templaten i den.
Som beskrevet over kan man som sådan ikke oprette et nyt projekt ud fra lb5 filer, men det kan du fra json. JSON-formatet er det eneste som rigtigt åbner op for muligheden at lave en template. Efter at have undersøgt muligheden i at lave templates ud fra JSON-formatet, er det lidt hip som hap om man opretter nyt projekt ud fra en json eller om man tager og ctrl+c – ctrl+v på et lb5 fil og ligger det i ens projekt mappe. Tidsmæssigt er der ikke noget at spare og det skal kun gøres en enkelt gang pr. projekt.
Så formatet templaten er i, spiller ikke den store rolle, da alt der videre arbejde foregår inde i LCAbyg (for det meste, medmindre man vil bruge LCAbyg i et mere avanceret omfang). Når det er sagt vil jeg deraf foreslå at starte med at lave templates i .lb5-formatet, da det ikke kan betale sig at sætte sig ind i JSON-formatet, hvis man kun skal bruge LCAbyg i dets basale omfang. Hvis man dog allerede har viden om JSON/API/programmering og BIM-integration, vil jeg dog klart anbefale man kigger lidt ind i JSON ved siden af.
Jeg har overvejet nogle forskellige ting i forhold til hvad en template skal indeholde. Hvilket fase er man i, når man starter? Afhængigt af hvilken fase man er i, i hvor stor grad er det hjælpsomt med præ-indtastet objekter?
I de tidlige faser er alt lidt oppe i luften, intet er besluttet og alt er på generisk niveau (Her er GenDk biblioteket idealet, og GenDK biblioteket er de integrerede objekter/obnygninger/materialer osv. indeholdt i programmet) i de tidlige faser kør man også gerne mange variant sammenligninger, kunne det være hjælpsomt at lave en tidlig .lb5 template hvor der er skruet maksimalt op for præ-indtastede BAU (buissness as usual) konstruktioner? Hvor man så blot skal klikke “medtages i beregning” fra?
Både ja og nej, når man klikker på en bygningsdel, vil der dukke en oversigt op med indholdet i den bygningsdel, samt en graf der viser aftrykket af konstruktionerne. Bygningsdelen kan godt være klikket fra at være medtaget, men for at en konstruktion er synlig i grafen, for at sammenligne aftrykket, skal den konstruktion være klikket til, det vil derfor være for besværligt at have en beregningstemplate med en masse konstruktioner indenfor hver bygningsdel, da alle disse konstruktioner skal være klikket til for at kunne sammenlignes, det vil sige processen fra mange til en, vil kræve enormt meget tid til at klikke ting fra, det vil derfor give mere mening at dette i stedet bliv til en variant sammenligningsfil, som udelukkende blev brugt som et analyse værktøj.
I de lidt senere faser, bevæger vi os over i det lidt mere specifikke, intet er rigtig generisk mere, GenDK biblioteket bliver mindre relevant og bliver mere brugt som noget vi kloner og tilretter, her ville en masse præ-indtastede konstruktioner måske være mere rodet og noget vi alligevel ville slette, her ville det være mere brugervenligt blot at have indtastet en masse tomme bygningsdele, både hoved- og undergrupper, med tilnærmede klassificering, som “22x.xxx (…)ydervæg”, som så kan projektspecifikt udfyldes.
Hvorfor har jeg ikke nævnt CSV templates? Det kommer lidt af begrænsningerne af CSV filen, som jeg faldt over i undersøgelsen af denne. Ideen med CSV-formatet er god, jeg tror bare lidt den kommer til kort, når der begynder at optræde flere bygningsdele indenfor en konstruktion. Jeg vil mene det er lige så hurtigt at sætte en lb5 template.
Under finder i to zip-filer, det ene er en variantsammenligningsfil der skal tænkes som et analyseværktøj i designfasen. I denne fil finder i en .lb5 LCAbyg fil der indeholder alle undergrupper af bygningsdele, samt forskellige GenDK konstruktioner, som man kan sammenligne aftryk af. Ideen er her man hurtigt kan danne sig et overblik over forskellige GenDK konstruktioners aftryk. Det er dog vigtigt at når man bruger GenDK objekter i analyser at man husker hvad GenDK værdier er, de er et konservativt gennemsnit. Så når man analysere på hvad materialer og opbygninger der ville passe ind i et projekt i designfasen og kigger på aftrykkene i denne fil, så husk at tallene her kun er en indikator.
Den anden fil i finder, vil være en projekt-template, det er en mere trimmet template, hvor jeg blot har oprettet tomme bygningsdele på undergruppe-niveau. Der er altså ikke noget som er præ-indtastet. Det er en template som er ment til at blive taget i brug når man rent faktisk skal regne på et projekts aftryk, det er altså blevet afklaret hvad de forskellige bygningsdele skal være i opbygninger og typer, så man har noget at regne på.
Det er en meget trimmet template, eftersom der kan være forskel i hvordan folk strukturere og bruger LCAbyg. Derfor er templaten meget trimmet og ment som noget man selv skal vurdere hvordan man vil tilrette til ens behov, nogle ønsker mere i en template og nogle ønsker mindre. Jeg synes dog som minimum at alle bygningsdeles undergrupper bør være synlige til at starte med, da dette skaber et godt overblik over ting man skal gøre sig en holdning om skal med i beregningen.