Russisches Projekt - MD@Home - Übersetzer gesucht
-
S_Garbe
- Rechenkraft.net-Sponsor

- Beiträge: 1219
- Registriert: 09.11.2001 01:00
- Wohnort: Kohlstädt
-
Michael H.W. Weber
- Vereinsvorstand

- Beiträge: 23170
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
Also es ist absolut UNNORMAL, daß der Client zu irgend einer Zeit "herum-idled". Vorstellen kann ich mir das nur, wenn der Cache leer ist und keine neue Wu geladen werden kann.
Man kann die Setup JEDERZEIT separat starten und dort einige wichtige Änderungen vornehmen. Der "approximation mode" bestimmt, wie schnell die Ergebnisdaten in eine sendbare Datei umgewandelt werden. Dabei bestimmt einfach die zur Verwendung erlaubte RAM-Größe die Geschwindigkeit. Der voreingestellte Wert ist bei "slow" angesiedelt und benötigt selbst auf meinem TBred XP2600+ 30 Minuten! Stellt man hingegen auf maximalen RAM-Bedarf um (wohl gemerkt: das betrifft NUR die Datenumwandlung) - das sind selbst hier bloß 60 MB - erzielt man eine Beschleunigung um mehr als Faktor 6.
Kurz zum "approximation mode". Es handelt sich eben NICHT um eine "simple" Datenkompression. Aufgrund der argen Ressourcenlimitationen in Rußland, wurde ein eigener Algorithmus entwickelt, der die Ergebnisdaten von 600 kB auf wenige kB reduziert. Bemerkenswert. Laut obigen Aussagen der Projektbetreiber, sollen dabei keine wesentlichen Daten verloren gehen. Ich kann es nur hoffen...
Weiterhin kann man die Cachegröße und die Zahl der Ergebnisse pro Sendeversuch einstellen. Voreingestellt sind 10/4, d.h. der Client lädt 10 WUs herunter, berechnet 4 und sendet diese dann zusammen ab. Anschließend wird der Cache wieder gefüllt, usw. Damit eignet sich der Client auch hervorragend als offline dc Projekt - wenn man den Cache nur groß genug einstellt. Aber Vorsicht. Stellt hier keine unsinnig hohen Werte ein. Momentan werden nur Tripeptide berechnet und mein Gespann aus TBird@1.1GHz und TBred@2.083 GHz kann pro Tag ZUSAMMEN bestenfalls 10 WUs abliefern. Die Rechengeschwindigkeit skaliert grob gesagt mit der CPU-Frequenz (der TBred ist wegen der verbesserten Architektur etwas mehr als doppelt so schnell wie der TBird) - so könnt ihr einfach abschätzen, wieviele WUs pro Tag eure Kiste(n) schaffen können und danach SINNVOLL die Cachegröße einstellen.
Der MDH-Server registriert genau, welche WU an welchen Benutzer (nicht Client) geschickt wurde. Es wird eine doppelte Redundanz berechnet, um Betrügereien auszuschließen. Dabei stellt der Server sicher, daß NIEMALS ein und derselbe Benutzer dieselbe WU erhält. Das gesamte Projekt hat:
20 hoch 2 = 400 (Dipeptide)
20 hoch 3 = 8000 (Tripeptide)
20 hoch 4 = 160000 (Tetrapeptide)
20 hoch 5 = 3,2 Millionen (Pentapeptide)
also insgesamt 3,3684 Millionen WUs bei nicht-redundantem Durchlauf.
Die wichtigste Datei im MDH-Verzeichnis ist "distributed.txt". Sie dient als Protokolldatei für alle durchgeführten Operationen - inkl. (lokaler) "time stamps". Dort ist auch genau der Status des Caches und der abgeschickten WUs zu entnehmen.
Eine weitere wichtige Date ist "client.ini". Dort stehen eure Konfigurationsdaten drin. "wu.txt" entält Informationen über die zuletzt abgeschlossene WU. "modyp.txt" schließlich liefert die Zeit in Sekunden, die zur Kompression der berechneten Ergebnisse benötigt wurde.
Merke: Der Client führt zunächst die moleküldynamischen Berechnungen durch und geht dann zur Ergebnisapproximierung über. Erst danach wird gesendet.
MDH läuft problemlos mit anderen Programmen - auch Spielen diverser Art - zusammen und stört nicht im Geringsten.
Der RAM-Anspruch ist minimal und die voreingestellte Priorität niedrig. Nach knapp 4 Tagen habe ich noch immer keinen einzigen Fehler erlebt. Auch soll der Client als Dienst installierbar sein - das muß ich demnächst mal im Detail herausfinden, da ich ihn dann auf unserem Domaincontroller laufen lassen werde.
Der Client hat eine astreine GUI und auch ein separates Fenster, in welchem alle relevanten thermodynamischen Daten angezeigt werden. Sehr gut gemacht und auch was für's Auge. Die GUI kann auch im Vollbildmode angestellt werden. Wer also "hoppelnde Moleküle" mag, kommt hier voll auf seine Kosten!
Ab sofort mein Lieblingsclient und zusammen mit Folding@home & Genome@home mit das beste Projekt auf dem Markt (meine persönliche Meinung - ist klar...).
Michael.
Man kann die Setup JEDERZEIT separat starten und dort einige wichtige Änderungen vornehmen. Der "approximation mode" bestimmt, wie schnell die Ergebnisdaten in eine sendbare Datei umgewandelt werden. Dabei bestimmt einfach die zur Verwendung erlaubte RAM-Größe die Geschwindigkeit. Der voreingestellte Wert ist bei "slow" angesiedelt und benötigt selbst auf meinem TBred XP2600+ 30 Minuten! Stellt man hingegen auf maximalen RAM-Bedarf um (wohl gemerkt: das betrifft NUR die Datenumwandlung) - das sind selbst hier bloß 60 MB - erzielt man eine Beschleunigung um mehr als Faktor 6.
Kurz zum "approximation mode". Es handelt sich eben NICHT um eine "simple" Datenkompression. Aufgrund der argen Ressourcenlimitationen in Rußland, wurde ein eigener Algorithmus entwickelt, der die Ergebnisdaten von 600 kB auf wenige kB reduziert. Bemerkenswert. Laut obigen Aussagen der Projektbetreiber, sollen dabei keine wesentlichen Daten verloren gehen. Ich kann es nur hoffen...
Weiterhin kann man die Cachegröße und die Zahl der Ergebnisse pro Sendeversuch einstellen. Voreingestellt sind 10/4, d.h. der Client lädt 10 WUs herunter, berechnet 4 und sendet diese dann zusammen ab. Anschließend wird der Cache wieder gefüllt, usw. Damit eignet sich der Client auch hervorragend als offline dc Projekt - wenn man den Cache nur groß genug einstellt. Aber Vorsicht. Stellt hier keine unsinnig hohen Werte ein. Momentan werden nur Tripeptide berechnet und mein Gespann aus TBird@1.1GHz und TBred@2.083 GHz kann pro Tag ZUSAMMEN bestenfalls 10 WUs abliefern. Die Rechengeschwindigkeit skaliert grob gesagt mit der CPU-Frequenz (der TBred ist wegen der verbesserten Architektur etwas mehr als doppelt so schnell wie der TBird) - so könnt ihr einfach abschätzen, wieviele WUs pro Tag eure Kiste(n) schaffen können und danach SINNVOLL die Cachegröße einstellen.
Der MDH-Server registriert genau, welche WU an welchen Benutzer (nicht Client) geschickt wurde. Es wird eine doppelte Redundanz berechnet, um Betrügereien auszuschließen. Dabei stellt der Server sicher, daß NIEMALS ein und derselbe Benutzer dieselbe WU erhält. Das gesamte Projekt hat:
20 hoch 2 = 400 (Dipeptide)
20 hoch 3 = 8000 (Tripeptide)
20 hoch 4 = 160000 (Tetrapeptide)
20 hoch 5 = 3,2 Millionen (Pentapeptide)
also insgesamt 3,3684 Millionen WUs bei nicht-redundantem Durchlauf.
Die wichtigste Datei im MDH-Verzeichnis ist "distributed.txt". Sie dient als Protokolldatei für alle durchgeführten Operationen - inkl. (lokaler) "time stamps". Dort ist auch genau der Status des Caches und der abgeschickten WUs zu entnehmen.
Eine weitere wichtige Date ist "client.ini". Dort stehen eure Konfigurationsdaten drin. "wu.txt" entält Informationen über die zuletzt abgeschlossene WU. "modyp.txt" schließlich liefert die Zeit in Sekunden, die zur Kompression der berechneten Ergebnisse benötigt wurde.
Merke: Der Client führt zunächst die moleküldynamischen Berechnungen durch und geht dann zur Ergebnisapproximierung über. Erst danach wird gesendet.
MDH läuft problemlos mit anderen Programmen - auch Spielen diverser Art - zusammen und stört nicht im Geringsten.
Der RAM-Anspruch ist minimal und die voreingestellte Priorität niedrig. Nach knapp 4 Tagen habe ich noch immer keinen einzigen Fehler erlebt. Auch soll der Client als Dienst installierbar sein - das muß ich demnächst mal im Detail herausfinden, da ich ihn dann auf unserem Domaincontroller laufen lassen werde.
Der Client hat eine astreine GUI und auch ein separates Fenster, in welchem alle relevanten thermodynamischen Daten angezeigt werden. Sehr gut gemacht und auch was für's Auge. Die GUI kann auch im Vollbildmode angestellt werden. Wer also "hoppelnde Moleküle" mag, kommt hier voll auf seine Kosten!
Ab sofort mein Lieblingsclient und zusammen mit Folding@home & Genome@home mit das beste Projekt auf dem Markt (meine persönliche Meinung - ist klar...).
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.


-
Michael H.W. Weber
- Vereinsvorstand

- Beiträge: 23170
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
Pascal, mir fiel nur eine (nötige) Korrektur auf:

Michael.
Der voreingestellt Wert ist nicht "tiny" sondern "slow" und die Größ0e der WU ist nicht selektierbar.Pascal hat geschrieben:Im Setup von MD@Home kann man die Grösse der WU angeben. Dort zwecks schnellerem Packen und Schätzen gegen Ende der WU bitte von "Tiny" auf "Huge" umstellen.
Michael.
Zuletzt geändert von Michael H.W. Weber am 08.05.2003 13:22, insgesamt 1-mal geändert.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.


-
MaFi
-
Pascal
-
Konstantin Leontiev
MD@home client file architecture.
MoDyp.exe - Main calculation module that calls other modules. It can works as service and standatd GUI application.
gapprox.exe - Results approximator.
7za.exe - ZIP archiver.
MD-Setup.exe & MSINET.OCX - the Setup utility.
php.exe, php4ts.dll, php.ini - PHP script engine setted up for command line working.
include\distributed.php - Main PHP script library for MD@home
include\readini.php - client.ini file parser
extract_wu.php - script to get next wu in to working directory to calculate
return_wu.php - script to return ready WU in to cache
update_cache.php - script to send and receive WU's from\to key server.
update_cache.bat - batch file to help users update cache manualy
uninstall.bat - batch file that is need to delete all files that came with current client version. It is need for autoupdate feature and manualy client updates.
dirlist.bat - batch file that creates dirlist.log file that can help me to solve some client problems.
client.ini - the main configuration file of the client
client.ini-distr - example of the client.ini
Log files:
distributed.log & distributed2.log - main log files that holds all MD@home client actions.
modyp.log - special log file of the main window of MoDyp.exe
approx.log - gapprox.exe log file
dirlist.log - produced by dirlist.bat (need to some support)
wu.log - file that appended to result.zip. Holds start and stop WU calculation events
modyp.pid - file that holds the current modyp.exe PID. Need to Lock working directory.
Other files:
*.sc1, *.sc2, *.cp1, *.cp2 - control points of the current work - updated every 10 minutes.
wu-path.dat - path to cache directory that holds current calculated WU.
WU ZIP file structure:
wu.prm - main calculation task
*.str - molecule structure.
*.tsb - statistics that will be calculated for this WU
wu.lst - list of all files in WU
result.lst - list of all files that must be included in result.zip for this WU
Cache structure:
last-wu.dat - next WU that need to be processed. If greated than cache_size than will be assumed to 1
wu-stat.dat - file that contains current WU state
wu.zip - the WU archive
wu-guid.dat - GUID of the current WU
work.dat - WU clculation progress file (will be in 1.17 build 3a)
node.dat - Contains node name that get this WU for calculation. Usable if you create farm with shared cache.
MoDyp.exe - Main calculation module that calls other modules. It can works as service and standatd GUI application.
gapprox.exe - Results approximator.
7za.exe - ZIP archiver.
MD-Setup.exe & MSINET.OCX - the Setup utility.
php.exe, php4ts.dll, php.ini - PHP script engine setted up for command line working.
include\distributed.php - Main PHP script library for MD@home
include\readini.php - client.ini file parser
extract_wu.php - script to get next wu in to working directory to calculate
return_wu.php - script to return ready WU in to cache
update_cache.php - script to send and receive WU's from\to key server.
update_cache.bat - batch file to help users update cache manualy
uninstall.bat - batch file that is need to delete all files that came with current client version. It is need for autoupdate feature and manualy client updates.
dirlist.bat - batch file that creates dirlist.log file that can help me to solve some client problems.
client.ini - the main configuration file of the client
client.ini-distr - example of the client.ini
Log files:
distributed.log & distributed2.log - main log files that holds all MD@home client actions.
modyp.log - special log file of the main window of MoDyp.exe
approx.log - gapprox.exe log file
dirlist.log - produced by dirlist.bat (need to some support)
wu.log - file that appended to result.zip. Holds start and stop WU calculation events
modyp.pid - file that holds the current modyp.exe PID. Need to Lock working directory.
Other files:
*.sc1, *.sc2, *.cp1, *.cp2 - control points of the current work - updated every 10 minutes.
wu-path.dat - path to cache directory that holds current calculated WU.
WU ZIP file structure:
wu.prm - main calculation task
*.str - molecule structure.
*.tsb - statistics that will be calculated for this WU
wu.lst - list of all files in WU
result.lst - list of all files that must be included in result.zip for this WU
Cache structure:
last-wu.dat - next WU that need to be processed. If greated than cache_size than will be assumed to 1
wu-stat.dat - file that contains current WU state
wu.zip - the WU archive
wu-guid.dat - GUID of the current WU
work.dat - WU clculation progress file (will be in 1.17 build 3a)
node.dat - Contains node name that get this WU for calculation. Usable if you create farm with shared cache.
-
MaFi
laut widows task-manager hat php.exe 2 von 4 stunden verbraucht seit der client läuft. meine resultate sind noch in meinem cache verzeichnis. schon seltsam. evtl. verbindungsprobleme?Pascal hat geschrieben:Maybe. Die php.exe macht den Up- und Download der WUs.MaFi hat geschrieben:hi
hab da was bemerkt: wenn der client einige zeit läuft, startet php.exe und krallt sich ca. 50% der cpu-zeit. muss das so sein?
markus
as per windows task-manager php.exe took 2 hours of cpu time since I started the client (4 h ago). and my results are still in my cache folders (I assume that the files result.zip are the results
when I run update_cache.bat only
Content-type: text/html
Update Cache.....
is displayed and nothing happens.
markus
-
Konstantin Leontiev
Well in this case you can send us (modyp@moldyn.ru) a distributed.log file, modyp.log file and client.ini file... It is good to run dirlist.bat and also send dirlist.log file.
-
Michael H.W. Weber
- Vereinsvorstand

- Beiträge: 23170
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
Resultiert nicht in die neue Clientversion. Diese hat ebenfalls eine neue Setup-Datei, sowie zwei in der Version a nicht enthaltene Batchdateien. Die also bitte auch hineinkopieren.Pascal hat geschrieben:...nur die modyp.exe in der bisherigen Installation ersetzen. Dafür natürlich den (alten) Client vorher beenden
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.


-
Pascal
Die Dateinamen wüsste ich - neben vielen anderen - dann gerne. Man man man!Michael H.W. Weber hat geschrieben:Resultiert nicht in die neue Clientversion. Diese hat ebenfalls eine neue Setup-Datei, sowie zwei in der Version a nicht enthaltene Batchdateien. Die also bitte auch hineinkopieren.Pascal hat geschrieben:...nur die modyp.exe in der bisherigen Installation ersetzen. Dafür natürlich den (alten) Client vorher beenden
Michael.
-
crit
- Rechenkraft.net-Sponsor

- Beiträge: 213
- Registriert: 26.03.2003 19:31
- Wohnort: Syke
ich werd noch mal verrückt mit dem projekt.
hab alles gelöscht und nochmal instaliert.
alles eingestelt.
50 wu und nach einer schicken.
auf Huge.
danach:
un as service supported
Trying to initialise and run calculation thread:
DNet_Thread: running get/send thread.
================= Distributed Caclulations =================
*** Waiting for task....
*** Calculating task....
=================== Single Run =================
Reading parameters file wu.prm
Section CONSTS found
Section STEPS found
Section NAMES found
Section CALCPRM found
Section TERMOSTAT found
Section QMODE found
Section VDWMODE found
Section HBMODE found
Section FLAGS found
Section V LIMIT found
Section RNDGEN found
Reading structure file LDW.str
Atom types found: 16
Molecules expected: 1
Residues expected: 5
Atoms found: 67
Valence bonds found: 68
Valence angles found: 120
Torsion angles found: 199
Improper torsions found: 20
Van-der-Waals pairs found: 0
Hydrogen bond pairs found: 0
After analysis of structure file:
Molecules found: 1
Residues found: 5
Loading statistics batch: LDW.tsb
All declared statistics loaded: 26
Calculating...
Calculation evaluates in 17834 seconds
Calculations done.
Packing results in to result.zip file.
und danach passiert wieder nix.
is das normal?
hab alles gelöscht und nochmal instaliert.
alles eingestelt.
50 wu und nach einer schicken.
auf Huge.
danach:
un as service supported
Trying to initialise and run calculation thread:
DNet_Thread: running get/send thread.
================= Distributed Caclulations =================
*** Waiting for task....
*** Calculating task....
=================== Single Run =================
Reading parameters file wu.prm
Section CONSTS found
Section STEPS found
Section NAMES found
Section CALCPRM found
Section TERMOSTAT found
Section QMODE found
Section VDWMODE found
Section HBMODE found
Section FLAGS found
Section V LIMIT found
Section RNDGEN found
Reading structure file LDW.str
Atom types found: 16
Molecules expected: 1
Residues expected: 5
Atoms found: 67
Valence bonds found: 68
Valence angles found: 120
Torsion angles found: 199
Improper torsions found: 20
Van-der-Waals pairs found: 0
Hydrogen bond pairs found: 0
After analysis of structure file:
Molecules found: 1
Residues found: 5
Loading statistics batch: LDW.tsb
All declared statistics loaded: 26
Calculating...
Calculation evaluates in 17834 seconds
Calculations done.
Packing results in to result.zip file.
und danach passiert wieder nix.
is das normal?
