Write your own Einstein@home screensaver
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4330
Credit: 251584517
RAC: 36414
1 Feb 2008 9:42:31 UTC
Topic 193483
(moderation:
A nice advantage of the "separate graphics" Apps is that the computation is completely independent of the graphics, which are now a separate program instead of a thread. Nothing that happens to the graphics (error, crash, etc.) could affect the computation, and the graphics code doesn't even have to be linked (in a technical sense) to the rest of the program.
Therefore we (as the project) simply don't care about what program runs as a graphics program (if at all), and what code it is. This gives you, the participants, the opportunity to code your own graphics for Einstein@home and run it, share it with your friends, customize it for your team etc. You can make one that suits the graphical power of your computer better than the standard one does (in either direction).
A lot of the fun in running BOINC is due to some kind of competition. So let's have an open competition for the best Einstein@home graphics. Write it, publish and announce it in the forum (here in this thread) and the whole community can and will take a look. Maybe at some point we'll chose a new "official" one, or give a list to choose from (in project preferences).
Here are some technical graphics/project-specific hints and instructions that will help you writing an Einstein@home graphics program (How to get, compile and link the BOINC library is out of the scope of this description):
* The only mandantory requirement for a BOINC graphics program is that it understands and honors a comand-line option "--fullscreen". If it gets passed this option, it should display graphics on the whole (main) screen and terminate on mouse movements or key presses. If it gets called without that option, it should open a window showing the same or different graphics and might react on keys and mouse movents in its own way.
* You will probably want to display some project-related information in any way. For this purpose you will need to use some functions of the BOINC library.
(void*)boinc_graphics_get_shmem("EinsteinHS") returns a pointer to a shared memory segment into which the main Einstein@home application writes a XML document describing its current status. In current Apps (S5R3 4.25-4.27) this looks like:
[pre]
%f
%f
%f
%f
%f
[/pre]
All the values (%f) are floats. The sky position is given in rad.
Future Apps will pass additional information:
[pre]
%f (float) right ascension current sky-position [rad]
%f (float) declination of current sky-position [rad]
%f (float) progress done so far, [0.0...1.0]
%f (float) CPU time spent so far [sec]
%f (float) timestamp of this XML
%f (float) base frequency of the current search [Hz]
%f (float) frequency bandwidth [Hz] - search will range
from frequency to frequency+bandwidth
One of current "top candidates" for a GW pulsar signal in this WU
%f (float) base frequency
%f (float) spindown
%f (float) right ascension
%f (float) declination
%f (float) hough significance (kind of rating)
The current BOINC status of the task / App
%d (see boinc/api/boinc_api.h)
%d
%d
%d
%d
%f
%f
,
[/pre]
The information contained in the XML may be extended in the future (e.g. on request) - that's why we chose XML.
A lot of data you probably want to show is passed to the App from the BOINC Core Client in a file init_data.xml. You could use BOINC functions to read and parse it:
Call boinc_parse_init_data_file() once at the beginning of your program, then boinc_get_init_data(/*APP_INIT_DATA*/ app_init_data) will get you a copy of the BOINC-internal APP_INIT_DATA structure in your variable app_init_data. The full definition of APP_INIT_DATA is in boinc/lib/app_ipc.h, it lists things like user- and teamname, total credit and RAC for host and user account etc., but also some technical stuff like the path to the project and slot directories on your disk.
A GLUT-based OpenGL event-loop is provided by BOINC as boinc_graphics_loop(argc,argv). When using this it will take care of the command-line parsing (i.e. "--fullscreen" disticntion), termination in fullscreen mode etc. Some documentation can be found in the BOINC Wiki at http://boinc.berkeley.edu/trac/wiki/GraphicsApi . The current Einstein@home starsphere uses this loop, but mainly because it's the way things were done previously and it required only minimal changes to the code. For new implementations I'd rather drop GLUT, partly because it's incompatible with the "virtual root window"-concept of xscreensaver. I'd use SDL or some other portable library to manage windows and interaction for OpenGL graphics. You could use DirectX, too, but then your graphics program is limited to MS Windows.
All the current S5R3 "separate graphics Apps" 4.25-4.27 come with an app_info.xml. To let your graphics program run with BOINC, place the program in the project directory and replace the einstein_S5R3_*_graphics_* entry in app_info.xml with your program filename (and restart the client). If all goes well, pressing "Show graphics" in the manager will fire up the graphics in a window, and the BOINC Screensaver will start it in fullscreen mode.
I intend to publish the Einstein@home starsphere sourcecode as an example soon.
Looking forward to hearing from you!
BM
BM
Write your own Einstein@home screensaver
)
Now this sounds cool!!
Think about the possibilities, e.g. you could interface E@H with other program, like Starry night or Stellarium, as was proposed in teh "Wish List" sub-forum several times, e.g. here.
I think a nice extension to the XML interface would be a filename & path to a file containing all the current toplist candidates, so basically the checkpointing file, but probably a copy of it that is refreshed less frequently to so that the graphics and checkpointing is decoupled and would not interfere with each other.
Then you could write a screensaver that displays progress similar to the TOPCAT graphics shown in the "visualization" thread.
CU
Bikeman
RE: I think a nice
)
One info contained in the APP_INIT_DATA is the slot directory the App is running in which contains the checkpoint file (*.cpt). You could make a copy of it for your own use periodically. I'd recommend to use boinc_copy() from the BOINC library for this (see boinc/lib/filesys.h), it will take care of platform dependencies (e.g. retry when the file is locked by the App or a virus scanner on Windows). You could keep the copy in the slot directory, it is cleaned up by the client once the task exits.
Oh, and actually also the graphics program should be started from the slot, i.e. will have the slot directory with the checkpoint file as CWD. So using "./" for the files should be fine.
We have one guy at the AEI Hannover who started working on passing the info (XML and APP_INIT_DATA) over the network, i.e. the "graphics program" is a server which the actual graphics program could connect to also from a remote machine.
BM
BM
RE: you could interface E@H
)
That's a pretty good point I didn't even think about before.
Any volunteers?
BM
BM
This sounds really cool. Pity
)
This sounds really cool. Pity I suck at graphics programming ;-) but I'm curious what the cracks can do. Success to all of you who try!
RE: I intend to publish the
)
Here it is: The sourcecode starsphere.zip and some libraries (JpegLib and freeglut) precompiled for an easier build on Windows: win_adds.zip.
The Windows build should work with Visual Studio Pro 2003 and 2005; I don't think BOINC currently compiles with VS 2008 (though the files affected may not be needed for the graphics build). As for the Express editions I doubt that they will work with this setup, though someone might be able to publish a project file for this. Shouldn't be hard to collect the necessary information from the batch file.
BM
BM
More information on how to
)
More information on how to make and test screen saver graphics, can be read on Eric Myers' BOINC Developers' Notes - Graphics site.
RE: More information on how
)
Oh, he updated it for v6?
RE: Oh, he updated it for
)
The page was last updated in late January 2008. He lists an email address for corrections and improvement suggestions. It would appear he has every intention of keeping the page up to date.
Cheers,
Gary.
RE: (void*)boinc_graphics_g
)
Is it a null-terminated string?
With the data being text, the length of individual fields can change, shifting off all the rest. There is a possible race condition: The science app updating the contents while the graphics app is halfway parsing it. For example, say the graphics app reads , and then reads a 4-digit number. At this point, the science app updates the XML contents, and cpu_time ends up having a 5-digit number. If the graphics app continues reading at the byte offset it had left off, it would get /cpu_time> (note the lost open bracket).
I don't know how you could do proper synchronization though... (hint: an "I'm currently updating" byte won't work)
RE: RE: (void*)boinc_grap
)
It is a null-terminated string. And yes, it's possible that the data or part of it is outdated. I wouldn't rely on the data for calculation, in particular not when the XML is malformed (one should really use an XML library for parsing, don't use the dirty hack of the example!), but for the graphics display it should be ok to throw a possible update away.
An "I'm updating" byte would work if it's the first byte, wouldn't it?
Filling the whole shmem with zeros before writing something in there should at least cause a XML parsing error when it has been incompletely written.
Do you agree?
BM
BM