Incidenteel inconsistent rekenresultaat

[chrispijo]

Uittredepunten 331, 430 en 733 hebben voor de limit states Beta-waarden die niet kloppen. Daar zie je dat de Beta-waarden voor uplift, heave en piping exact hetzelfde zijn. Voor de total_model_runs is voor 2 van de 3 limit states 0 als aantal. Wat een extra indicatie is dat er iets niet klopt.

Oorzaak: Het vermoeden is dat het in de PTK-tool fout gaat.

Oplossing: Een voorgestelde oplossing is dat indien deze situatie ontstaat, de worker de berekening nog een keer uitvoert.

data.zip

[chrispijo]

Als invalid gemarkeerd omdat het waarschijnlijk een bug in de probablistic_library is, i.p.v. in GeoProb-Pipe. Natuurlijk moeten we hier wel op anticiperen.

[skapinga]

De oorzaak van het issue is nog niet bewezen. Mogelijke oorzaken kunnen zijn:

1. In system_calculation.py:122-123 wordt importance_sampling gebruikt voor de Combine-berekening. De probabilistische bibliotheek heeft hiervoor de instellingen is_repeatable_random en random_seed, maar GeoProb-Pipe stelt die niet in. Ook kan een unieke combinatie van invoerparameters er mogelijk voor zorgen dat het oplossingsalgoritme niet werkt. Dit verklaart niet alle verschillen die gevonden worden.
2. Parallelle verwerking: De berekeningen worden verdeeld over meerdere processen in build_and_run.py:171-176. De Combine-berekening gebruikt bovendien parallelle verwerking. De volgorde waarin berekeningen klaar zijn kan verschillen, waardoor de invoer voor de volgende stap niet klopt of later wordt overschreven door een andere berekening?
3. Resultaten worden in onbepaalde volgorde verzameld: imap_unordered verzamelt resultaten in aankomstvolgorde, niet in invoervolgorde (build_and_run.py:176-178). Veel dataframes worden later gesorteerd, maar niet alle tussenresultaten. Bij gelijke waarden of aggregaties kan die volgorde relevant worden, mogelijk ook in combinatie met parallelle verwerking?
4. Inputvolgorde uit SQLite/GeoPackage is niet gegarandeerd: Queries zoals in input_data_object.py:52-57 gebruiken geen ORDER BY. Ook drop_duplicates() in base_system_build.py:91-95 behoudt de oorspronkelijke volgorde. Die volgorde kan verschillen tussen databases, exports of runs.

Een combinatie van oorzaken is ook mogelijk. Dezelfde dataset is op meerdere PC's met verschillende typen CPU's meerdere malen getest. Afhankelijk van het aantal cores van de CPU worden de berekeningen opgedeeld in chunks. Op de ene PC's is het probleem te reproduceren, op de andere niet. Tussen de PC's zit een verschil in besturingssysteem (windows/linux). Wijst dit richting de parallelle verwerking van de berekeningen?

[VincentJilesen]

Als eerste stap voor het uitzoeken van waar het misgaat heb ik een aantal debug logs toegevoegd aan de worker. Hiermee kan worden gekeken of de fouten al in de worker beginnen of pas in de verdere verwerking tot stand komen.

Update: Ik heb een waarschuwing eraan toegevoegd als er een resultaat is met 0 total model runs. Deze ben ik nu een keer tegengekomen na 10+ runs.

[chrispijo]

Merged naar beta.