Hoi Marcel, hoi Truuske,

Haast je langzaam, maar zodra je de tijd ervoor hebt, bestudeer dan even wat
ik hieronder schrijf en laat me weten wat je ervan vindt:


Transitiematrices: voorstel voor specificaties:
-----------------------------------------------

    De configuratieparameter 'Transitions:' is optioneel. Als-ie niet wordt
gespecificeerd wordt de implementatie van simrisc 14.03.00 gebruikt, als-ie
wel wordt gespecificeerd worden de transitiematrices gebruikt. Hieronder volgt
een uitgewerkt specificatievoorbeeld, toelichting daarna.

voorbeeld configuratiefile specificatie:

    ----------------------------------
    Transitions:
            steps:  4
            ages:   0-50 50-70:5 70-*
            file:   file-lokatie
      (of:  
            matrices: 
        gevolgd door het vereiste aantal transitiematrices, rijgewijs
        gespecificeerd)
    ----------------------------------

'steps' geeft het aantal transitiestappen. 4 betekent: een 4 x 4 matrix
waarvan element [i, j] de waarschijnlijkheid definieert dat er een transitie
van toestand i naar toestand j plaatsvindt. Rijgewijs moeten de transities
sommeren tot 1. 

Stel dat 'steps: 2' is gespecificeerd, dan betekent dat bij bv. de matrix

                    .95 .05
                    .01 .99

dat een case in toestand 1 een p = .05 heeft om naar toestand 2 over te
gaan. Een case in toestand 2 heeft een p = .01 om terug te keren naar toestand
1. 

'ages' definieert voor welke leeftijdsgroepen een transitiematrix beschikbaar
is. 
    a-b betekent: 1 transitiematrix die wordt toegepast vanaf leeftijd a tot
        leeftijd b. Als voor b * wordt gespecificeerd wordt de transitiematrix
        vanaf leeftijd a toegepast.
    a-b:c betekent: c transitiematrices die worden toegepast op de
        opeenvolgende leeftijdsblokken (b - a) / c. In het voorbeeld
        hierboven: 50-70:5 betekent dat er 5 transitiematrices zijn die,
        respectievelijk, worden toegepast in de leeftijdsintervallen:
            50 tot 54
            54 tot 58
            58 tot 62
            62 tot 66
            66 tot 70

In het bovenstaande voorbeeld zijn er dus 7 4x4 matrices nodig. Het is
mogelijk om die matrices in de configuratiefile zelf op te nemen, maar 't is
wellicht handiger om ze in een file op te slaan, waardoor je bv makkelijk
tussen transities kunt wisselen. Vandaar de 'file' optie: de naam die volgt op
'file:' geeft de locatie (pad + filenaam) van de file die de matrices
bevat. Maar 't is ook nog steeds mogelijk om de matrices wel in de
configuratiefile zelf op te nemen: na 'matrices:' wordt het vereiste aantal
matrices verwacht.

----------------------------------------------------------------------------

Transitiematrices: implementatievoorstel:
------------------------------------------

Wanneer 'Transitions:' is gespecificeerd dan wordt er per case pas een tumor
gesimuleerd zodra die case het laatste transitiestadium bereikt. Het proces
(per case) zal dan alsvolgt verlopen:

    beginleeftijd: 1e leeftijd waarvoor een transitiematrix beschikbaar is
        (in 't voorbeeld dus: 0)

    eindleeftijd: laatste leeftijd waarvoor een transitiematrix beschikbaar
        is (in 't voorbeeld dus: de max. leeftijd (*, = 100). 

    begin toestand: 1

    simulatieproces:
    ----------------
    deel 1:
    =======
        vervolgens wordt geitereerd van begin naar eind, waarbij in elke stap
    ogv de van toepassing zijnde transitiematrix wordt bepaald wat de toestand
    is in die leeftijd.

        Wanneer gedurende deze iteraties std. screeningsleeftijden worden
    bereikt dan wordt/worden de bijbehorende screening/s uitgevoerd met
    wellicht als resultaat een fout-positieve diagnose.

        Wanneer de natuurlijke overlijdensleeftijd wordt bereikt stopt de
    simulatie van deze case.

        deel 1 wordt verlaten zodra de laatste toestand v.d. huidige
    transitiematrix is bereikt

    deel 2:
    =======
        Tenzij de simulatie al bij deel 1 is gestopt gaat de simulatie
    alsvolgt verder:

        Zoals dat in de huidige versie v simrisc ook gebeurt wordt een tumor
    gesimuleerd, en de simulatie verloopt vanaf dat moment overeenkomstig de
    wijze waarop dat nu ook al gebeurt.

        Tevens wordt bij elk volgend jaar opnieuw een transitieberekening
    uitgevoerd, omdat een transitie naar een vorig stadium mogelijk is.

----------------------------------------------------------------------------

Transitiematrices: versnelling van simrisc:
-------------------------------------------

Wanneer we bovenstaande procedure gaan toepassen betekent dat een toename van
het werk dat het programma moet uitvoeren omdat de N screeningsrondes dan
genest zijn binnen een omhullende iteratie van K leeftijden.

Ik kan niet overzien hoeveel langer simrisc dan bezig zal zijn met een
simulatie en of dat tot een wezenlijke vertraging zal leiden. Maar mocht dat
zo zijn (niet onwaarschijnlijk) dan kan zo'n vertraging worden verminderd door
simrisc multi-threaded te maken.

Op dit moment verloopt 't simulatieproces alsvolgt:

    voor elke case:
        initialiseer de case,
        pre-screening,
        screening,
        post-screening.
        schrijf de resultaten naar file

Zouden we simrisc multi-threaded maken dan kunnen de analyses voor een aantal
cases parallel worden uitgevoerd:

    voor elke case:
        zodra mogelijk: verwerk de volgende case

Stel dat er twee cases parallel kunnen worden verwerkt, dan bestaat zo'n
verwerking uit deze stappen:

        (busy)          - dwz in bovenstaande regel wordt bij 'zodra mogelijk' 
                        - gewacht totdat een verwerkings-thread beschikbaar is
            initialiseer de case,
            pre-screening,
            screening,
            post-screening,
            schrijf de resultaten naar file.
        (beschikbaar)
        
Maar er treedt hier wellicht een probleempje op wanneer fixed en stapsgewijze
seeds worden gebruikt bij het herinitialiseren van de random nr. generatoren:
binnen de simulatiestappen (per case) worden random nrs gebruikt. Zou simrisc
op de hier beschreven wijze multi-threaded worden dan ligt de volgorde waarin
de random getallen worden bepaald niet meer vast, omdat thread 1 en thread 2
op onvoorspelbare momenten random getallen genereren, waardoor de sequentie
binnen een case-gebonden simulatie dus niet meer vastligt, zoals dat wel het
geval is wanneer je single-threaded (zoals nu) simuleert.

Maar we zouden dat probleem kunnen oplossen door elke thread z'n eigen random
nr. generatoren te geven, die dan worden geinitialiseerd met de seed die op
dat moment van toepassing is + het case-nr dat bij de thread-run hoort. Op die
manier handhaven we de herhaalbaarheid van de random nrs, en daarmee de
herhaalbaarheid van de case-gebonden waarden wanneer bv verschillende
modaliteiten met elkaar worden vergeleken.

Er is op dit moment nog geen sprake van multi-threading, maar mocht 't
aantrekkelijk worden om multi-threading te gaan toepassen dan zou een aanpak
zoals hier beschreven m.i. mogelijk zijn: wel multi-threading, met handhaving
van herhaalbare simulatieresultaten.


