client_state.xml poškozen - možnost opravy?

[Honza]

Sulphur uz zadne nemam, ale myslim, ze Carl struktura tricklu zasadne nemenil (tedy krome moznosti jej mit 64+Kb a podobne).
Navic ani nikde nemam zadny neodeslany trickle (vsechno jde rovnou), abyc to overil.

Pokud tedy budu spolehat na svou nespolehlivou pamet, tak v trickle souboru jsou opravdu vsechny potrebne informace. Uz do dob klasika CPDN je znaceni modelu v nejake podobe jako ted (kombinace oznaceni typu modelu, souboru parametru a pripadne poradoveho cisla) a do WorkUnitID a ResultID se to rozkodovava az na serveru. Ale klidne muzu kecat, protoze ta pamet...

Trochu off-topic...tedy vlastne jenom vuci tvemu prispevku, ale jinak velmi on-topic.
5.4.9 by snad mela umet pri startu restaurovat poskozeny client_state.xml z client_state_prev.xml ...ale nezkousel jsem to

[forest]

Trochu off-topic...tedy vlastne jenom vuci tvemu prispevku, ale jinak velmi on-topic.
5.4.9 by snad mela umet pri startu restaurovat poskozeny client_state.xml z client_state_prev.xml ...ale nezkousel jsem to

Tak tohle by pomohlo řešit problémy spousty lidí, kterým se model odporoučí právě díky poškození client_state.xml, což se i mně už 2x stalo, když u nás vyskočil jistič

[Honza]

Tak tohle by pomohlo øešit problémy spousty lidí, kterým se model odporouèí právì díky poškození client_state.xml, což se i mnì už 2x stalo, když u nás vyskoèil jistiè

Se nediv, ze ti vyskocil jistic, kdyz jsi mel doma overclockunty Presshot
Jak rikam, nezkousel jsem, ale mohlo by to v nekterych pripadech pomoci...

[forest]

Vyskočil vždy jen když jsem se amatérsky hrabal v elekrice na baráku a podařilo se mně něčím propojit drátky

[Indy]

Takže jsem včera dopočítal těch 80%, ukončil jsem počítání, zazálohoval adresář, pak znovu spustil, abych to odeslal. K mému překvapení boinc nahlásil opět chybu, napsal 100% a hotovo. Zjistil jsem však jednu zajímavou věc - názvy tricklů v adresáři měly hned za názvem "sulphur_ei55_000676697" ještě "_1", ale sbalený zip soubor po čtvrté fázi "_0". Bohužel se stalo asi to, že původní porušený projekt měl na konci za názvem "_0" a potom nový stažený "_1", já nevěděl, že v tom může být rozdíl a vnutil jsem mu počítat data dál s tou jedničkou na konci, ikdyž můj workunit tam měl mít 0. Proto mi tam taky ty trickly průběžně nenaskakovaly - byly odlišné. Provedl jsem tedy další úpravu client_state a nahradil ty jedničky nulama, opravil název posledního tricklu - změnil jsem v názvu tu 1 na 0 a zkusil to odeslat. Boinc opět hlásil asi 5 chyb, že nemůže najít nějaké soubory, ale trickl odeslal a odeslal i zip soubor po čtvrté fázi. A světe div se, ten trickl se mi tam i objevil a dnes dokonce i body ( asi 3100, jako by se nic nestalo viz http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1352716 )
Otázka tedy zní:
1. Kam chodily ty trickly s jedničkou v názvu a mohly někomu jinému poškodit jeho výsledky?
2. Ikdyž dopočítám vše do konce, využije se nějak výsledek, bude-li tam napsáno, že je tam chyba "client error" ?

P.S.: Máte-li někdo ještě jednotku sulphur_xxxx_999999999 a za ní "_0", pošlete mi prosím client_state na porovnání na indy@wo.cz , dík.

EDIT: Omlouvám se, mělo to být v threadu "client_state.xml poškozen - možnost opravy?"
EDIT2: Díky za přesun

[Honza]

Je urcite potesujici, kdyz se to podari alespon trochu opravit.

ad 2 - server vysledky prijde bez ohledu na "state". Pro dalsi zpracovani jsou dulezite uploadovane soubory, ne trickle. V novejsich modelech uz se trochu stira rozdil mezi uploadem a trickle soubory, resp. trochu meni vyznam. Upload soubor muze v podstate obsahovat restart dump (neco jako checkpoint, od ktereho lze pocitat dal) a trickle uz neobsahuji pouze udaj o tom, kde se dany model ve vypoctech nachazi, ale i nejake zakladni udaje o vysledcich (drive mega-trickle).
ad 1 - na to nedokazi presne odpovedet, sulphur uz zadny nemam a podrobnosti si nepamatuji.

[LiborA]

P.S.: Máte-li někdo ještě jednotku sulphur_xxxx_999999999 a za ní "_0", pošlete mi prosím client_state na porovnání na indy@wo.cz , dík.

Mám rozpočítané ještě tři SC:
sulphur_ilyp_100868273_0 a sulphur_ix34_100882688_1 a sulphur_ilrs_100868024_0
Ty první dva jsou dosud OK, ten poslední již spadnul a počítám ho ze zálohy - už na 3 kompu
Takže pokud nějaký chceš, mohu klidně poslat, stačí si vybrat který

[Indy]

Takže pokud nějaký chceš, mohu klidně poslat, stačí si vybrat který

Beru tedy ten první, díky. Pak svoje opravím a dopočítám, ať můžu klidně spát

[Indy]

Takže velký dík všem, a to i za starší postřehy - z toho jsem vycházel. Počítám už bezproblémů to co mám, trickly se také odesílají, viz http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1352716 , takže pokud to zase nějakým zásahem nezruším, tak nejpozději do konce června budu konečně s první jednotkou u CPDN hotov.
Důležité je, že pokud se neporuší soubory z adresáře climateprediction.net ( a vlastně nějaké ty zipy klidně mohou ), tak by to mělo zpravidla jít opravit.