Leaks: attempts at removing discrepency between leak_calc true and fa…

[PieterTack]

…lse calculations

[PieterTack]

Dus: main issue: de transmission efficiency van non-leak photons verschilt wanneer de berekening met leak_calc of zonder leak_calc wordt uitgevoerd. Secundaire issue: het aantal sum_not_entered fotonen verschilt ook (veel) wanneer met of zonder leaks wordt gerekend. Echter, polycap_photon_launch() geeft zelfde output wanneer met of zonder leaks wordt gerekend. Het probleem komt ook voor ongeacht of er single core of multicore wordt gerekend, alsook wanneer er met een fixed seed wordt gerekend.

Ben een beetje ten einde raad... Voornamelijk de issue met de sum_not_entered snap ik helemaal niet, daar deze return value echt compleet onafhankelijk is van of er nu leak berekeningen zijn of niet...

[tschoonj]

Hey Pieter, excuses voor mijn recente stilte... het is na mijn vakantie nogal hectisch geworden op het werk.

Hoe gaat het met polycap? Zit je nog altijd vast?

[PieterTack]

Geen probleem hoor :) De status is hier ook enige tijd onverandert gebleven, moet eind deze maand mijn FWO heraanvraag insturen voor tweede post-doc termijn dus heb daar redelijk wat tijd in gestoken.

Met de code heb ik het probleem al doorheen alle functies getraced, en het probleem duikt op na de polycap_segment() functie. De issue lijkt te zijn dat voor leak calculations er een foton getraced wordt dat a) in het betreffende capillair zit, maar b) niet langer in het polycapillair zit. Een beetje een freaky puntje dus ;) Ben er nog niet achter waar dit probleem vandaan komt. Volgende aanpakken zijn om de wiskunde achter de polycap_segment() functie eens grondig onder de loep te nemen (was het enige deel dat ik eerlijk gezegd niet snapte, gevorderde vectorrekenen enzo, en heb dus Laszlo voor uitleg gevraagd), en om toch eens te kijken of het polycapillair profile wel steek houdt (i.e. of er inderdaad in de simulatie mss geen capillair wordt gesimuleerd dat (deels) buiten de external polycap radius gaat). Positieve is wel dat het lijkt dat als ik het probleem dat we nu hebben efficient kan oplossen, dat de leak calculations een pak sneller zouden moeten verlopen (i.e. minder nutteloze trajectories simuleren). Maar daar ben ik dus nog niet :)

[tschoonj]

Ok, veel geluk met de FWO verlenging!

[PieterTack]

Zucht :( Ik krijg weer issues met compilen door de HIDDEN keyword voor de polycap_capil_trace_wall() functie. Hoe los je dat weer op?

[tschoonj]

Ben er naar aan het kijken.

By the way heb al een probleem gevonden:

../../src/polycap-source.c:752:47: warning: variable 'j' is uninitialized when used here [-Wuninitialized]
                                efficiencies->images->src_start_coords[0][j] = photon->src_start_coords.x;

Dit soort zaken leidt altijd tot miserie.

[tschoonj]

Dit deugt ook niet:

../../src/polycap-capil.c:781:12: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
        *r_cntr = abs(r_i);
                  ^
../../src/polycap-capil.c:781:12: note: use function 'fabs' instead
        *r_cntr = abs(r_i);
                  ^~~
                  fabs
../../src/polycap-capil.c:782:12: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
        *q_cntr = abs(q_i);
                  ^
../../src/polycap-capil.c:782:12: note: use function 'fabs' instead
        *q_cntr = abs(q_i);
                  ^~~
                  fabs

[tschoonj]

Laat die HIDDEN gewoon vallen.

[PieterTack]

Ben er naar aan het kijken.

By the way heb al een probleem gevonden:

../../src/polycap-source.c:752:47: warning: variable 'j' is uninitialized when used here [-Wuninitialized]
                                efficiencies->images->src_start_coords[0][j] = photon->src_start_coords.x;

Dit soort zaken leidt altijd tot miserie.

Hm, vreemd... Die j zit er al van in het begin in... Ik definieer die in de main code, noem ze dan in #pragma als private, en dan gebruik ik ze als variable in de for loop... Gek dat nu fout oplevert als vroeger steeds mocht.

[PieterTack]

Oke, wtf, ik krijg hier hele resem aan compilation errors die ik vroeger nooit kreeg, in bestanden waar ik niks veranderde... Zie jij iets wat ik fout deed? Ik moet wel zeggen dat ik na een vorige commit (ik denk net voor 891a53f, maar kan er ook net na geweest zijn. Kzie het niet direct terug in mijn history) per ongeluk git pull deed. Dit leek wel enkele files te veranderen, maar kon nergens de concrete verschillen zien daar al mijn recente veranderingen nog intact waren. Misschien fuckte dit toch vanalles op?

[tschoonj]

Mja, ziet er een beetje vreemd uit bij nader onderzoek... Waarschijnlijk een false positive

Misschien best die private(i, j) weg halen uit uw #pragma omp parallel en die variabelen gewoon te definiëren daaronder:

#pragma omp parallel \
    default(shared) \
    num_threads(max_threads)
{
        int i, j;
    int thread_id = omp_get_thread_num();
    polycap_rng *rng;

[tschoonj]

De Travis-CI builds lijken anders wel te lukken, maar de tests lijken te hangen of duren veel te lang.

[PieterTack]

Hmm... De build op zich lijkt hier inderdaad te lukken. Zal mss eens mijn eigen build map moeten deleten en opnieuw configuren enzo, mss is er daar iets fout gegaan. Dat de tests te lang duren is normaal. Met mijn aanpassingen om de issues uit de leak berekeningen te halen heb ik blijkbaar ervoor gezorgd dat de gewone berekeningen nu (net als de leaks) superlang duren. Moet nog uitpluizen wat er aan de hand is, maar ging dus niet want kon niet meer builden :P

Momenteel voor een weekje in workshop in Grenoble, dus zal niet veel kunnen doen (voornamelijk omdat ik niet remote kan inloggen op xmi2, en dat builden op lvserver of xmisrv02 sowieso faalt door bepaalde dependencies die ontbreken). Wanneer ik terug ben kan ik weer aan de slag (hopelijk ;) )

[tschoonj]

Als je wil kan ik anders ook de ontbrekende dependencies op lvserver en/of xmisrv02 installeren.

Btw kan je niet gewoon na te ssh'en naar lvserver, gewoon door ssh'en naar xmi4 (of welke andere machine dan ook)?

Veel plezier in Grenoble!

[tschoonj]

Werkt alles lokaal nu? De CI problemen zijn te wijten aan de nieuwe xraylib versie van vorige week...

[PieterTack]

yup, lokaal werkt het. Kzeg het, er zit nog een vreemd geval in dat soms voorkomt (en bij leak simulaties dus meer dan zonder doordat er gewoon veel meer trajectories gesimuleerd worden bij leaks), maar ksnap niet hoe/waarom dit kan gebeuren en vind er nog geen oplossing voor. Denk dat het iets te maken heeft met manier waarop de surface norm van het reflecting surface wordt bepaald, maar kzie niet direct wat er mis kan gaan en ook al mijn andere manieren om te berekenen geven foute oplossingen.

Long story short: het werkt, de resultaten zien r goed uit (ben nu aan het simuleren om die paper van vorig jaar eindelijk af te werken) en de rest kan ik stap voor stap proberen verbeteren, naargelang hoeveel tijd ik heb :P

[tschoonj]

Als je denkt dat alles in orde is, merge dan gerust in.

Ik zal daarna xraylib 4.0.0 op de xmi cluster installeren en de polycap code aanpassen zodat het daarmee compatibel is.

[PieterTack]

Ben nog even de simulaties aan het optimaliseren voor de paper. Als die overeen komen zal ik hier proberen mergen, dan kan de paper ook weg :P

[tschoonj]

👍

[PieterTack]

Zoals je waarschijnlijk vermoedde ben ik op nog wat issues gestuit :P Mijn grootste issue was/is dat de leak events (recap in de code, internal in het manuscript dat we ooit wel weten af te werken) een te hoog gewicht krijgen ivm experimentele waarden. Nu terug op punt waar ik nogmaals kan vergelijken met experimentele waarden wat de uitkomst is. Vermoedelijk ga ik ergens een extra normalisatie moeten uitvoeren, maar ben nog niet mee waar. Blijft ook vreemd dat ik in de gewone berekeningen precies nergens melding krijg van fotonen die volledig geabsorbeerd worden (maar met gesimuleerde energie tot 50 of 80 keV is dat misschien niet te verbazen)

[tschoonj]

Merci, ik zal een dezer dagen eens grote kuis houden in de CI