I FDS är det möjligt att ta med ytterligare ”species” i beräkningen. Med hjälp av &SPEC ID och MASS_FLUX och  kan olika gaser föras in i domänen. Det kan vara bra om du vill se hur andra förbränningsprodukter än koldioxid, kolmonoxid och sot sprider sig och vilka koncentrationer som byggs upp. I manualen avsnitt 5.5 beskrivs tekniken. Tyvärr glömde de skriva ut att FDS inte vill att du lägger till fler än fyra extra species för då kraschar programmet…

Kevin McGrattan en av de på NIST som jobbar med Fire Dynamics Simulator meddelade i ett nyhetsbrev att släppet av FDS 5 får vänta ytterligare. NIST håller på att strukturera om koden och introducerar en ny plattform för utveckling och validering. McGrattan poängterar vikten av validering i framtiden och har en förhoppning att användare är intresserade av att delta. Håll dig uppdaterad med regelbundna besök på den kommande FDS-hemsidan.

Det finns flera sätt att föra effektutvecklingen i FDS tidsberoende. Det vanligaste är att använda RAMP_Q eller TAU_Q. Problemet med dessa metoder är att det är HRRPUA som de styr och en av de viktigaste parametrarna i FDS för att få ett resultat med god kvalitet är just effektutvecklingen per ytenhet (HHRPUA). Om denna är för låg i förhållande till cellstorleken påverkar detta flammans upplösning och värdet kallat ”Fire Resolution Index” blir klart mindre än 1,0:

The fire resolution index is defined as the fraction of the ideal stochiometric value of the mixture fraction that is being used in the calculation; i. e. combustion efficiency. It indicates how well resolved the calculation is. When the fire resolution index is close to 1, the calculation is well resolved.

Ett sätt att komma runt detta är att experimentera med funktionen spread_rate, vilken anger hur snabbt branden ska spridas till olika celler med bibehållen HRRPUA. Då går det att på  förhand avgöra hur vilken minsta cellstorlek som krävs för att beräkningen ska få en god upplösning. Mer om detta hittar du i t.ex. här.

I ett nummer av ”Consulting-Specifying Engineer” intervjuas fyra företrädare av brandingenjörsvetenskapen om fördelar och möjligheter med CFD. Kevin McGrattan, en av de på NIST som ansvarar för utvecklingen av FDS säger så här om vad som är viktigast att tänka på när man använder CFD-modeller:

Accuracy is a concern. When using CFD sofware, errors in calculation often come from using a coarse mesh. A user should validate results with some experimental data or empirical correlation. For example, there are simple formulas that can be used to predict the descent of a smoke layer in a simple space. In a nutshell, validation is vital.

Kluster ger möjligheter, men defintivt också problem som gör att man tvingas lära sig en hel del om nätverk och sådant som hitintills inte varit särskilt intressant. Jag har för närvarande tre trimmade datorer, vilka ska jobba tillsammans för att snabbt simulera bränder i stora byggnader. Datorerna, namngivna efter stora matematiker fungerar utmärkt var för sig, men när de kopplas ihop verkar det som ”Euler” och ”Newton” inte riktigt är bästa vänner med ”Perelman”. Av någon anledning är där en fördröjning i kommunikationen som gör att systemets presentanda minskar. T.ex kan Euler och Newton räkna på en parallell körning snabbare om de är ensamma om jobbet, än om Perelman också ska vara med.

Just nu pågår felsökning och optimering av nätverket. Jag har upptäckt att FDS är komplierat för en version av MPI (Message Passing Interface) kallad MPICH1, vilken inte har uppdaterats sedan 2003. Numera bedrivs utveckling i en standard kallad MPI 2 och då finns MPICH2 tillgänglig. Men eftersom fds4_mpi.exe inte fungerar med MPICH2 eller andra specifika MPI-program för Windows som DeinoMPI behöver jag kompliera om källkoden för FDS. När detta är gjort kommer jag ha möjlighet att bygga ett kluster baserat på Windows XP med helt annan möjlighet till kontroll och styrning än vad MPICH1 medger.

Har du också kluster-strul, skicka ett mail så kan vi utbyta erfarenheter…

Jag blir alltid lika glad när beräkningsprogram ger felmeddelande som forrtl: severe (157) Program exception – access violation och Memory allocation failed for…the routine INIT. Då vet jag nämligen att jag måste ägna de kommande fyra timmarna åt att överhuvudtaget förstå vad jag ska göra åt saken och komma vidare.

FDS kan ge en del lustiga felmeddelanden. T.ex forrtl: severe: Program Exception – stack overflow. Detta vet vi sedan länge har att göra med att hur mycket stackminne som FDS snor åt sig. En fix finns på Nist:s hemsida. Men, andra fel än så är inte lika lätta att komma vidare med. I mitt arbete med MVG i Umeå jobbar jag med en grid på knappt 2 miljoner celler. Inte speciellt mycket, men då mängden block (byggnadsdelar) är stor blir det jobbigt för Win XP. Antingen vill inte simuleringen starta överhuvudtaget eller så kommer kära forrtl: severe: och meddelar sin närvaro efter några hundra iterationer.

Lösningen då? Jo, tack vare Google lärde jag mig att XP hanterar minne som fragment och kan inte ha mer än 2 GB i en klump (tråd). Lösningen på detta blir att dela upp simuleringen i fler trådar med fds4_mpi och MPICH. Jag har lyckats med att köra fds med parellella processorer förut och det gick även denna gång. I stället för att dra igång indatafilen med fds4 < job_name.data använder jag mpirun -np X c:nistfdsfds_mpi.exe (X = antal grids) och lyckas starta X trådar som räknar galant.

Pyrosim är en sk pre-processor till FDS. I stället för att manuellt sitta och skriva rolig programkod är det nu möjligt att köpa ett program som underlättar inmatningen av indata till FDS enormt. Jag har ägnat större delen av gårdagen för att rita upp en modell av Sergelgången 2 och känner att jag redan nu behärskar programmet. Nästan bäst av allt är att du kan lägga in din planritning i bakgrunden och sedan placera ut väggar, öppningar, etc precis där de ska vara. Mycket finurligt. Pyrosim visar indatafilen i 2D, 3D och i ren textform om du så vill.

Innan du drar igång din simulering kan du vällja att granska hur smokeview tolkar datafilen och när du väl bestämmer dig för att köra igång FDS så kommer det upp ett litet fint fönster som övervakar simuleringen och till och med ger dig en beräknad sluttid. Fast min nuvarande simulering är beräknad att pågå ytterligare 596 h, så jag vet inte hur tillförlitlig denna funktion är. 500 $ vill de ha för ett års användning.