1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
CVS info : $Header$
Cactus Code Thorn Formaline
Thorn Author(s) : Erik Schnetter <schnetter@aei.mpg.de>
Thorn Maintainer(s) : Erik Schnetter <schnetter@aei.mpg.de>
--------------------------------------------------------------------------
Purpose of the thorn:
Send meta information about a run to a server, so that it is kept
there forever. The information sent is e.g. the parameter file, date,
time, machine, and user id of the run, location of the output data,
number of iterations, an efficiency summary, etc.
Meaning and pronunciation. Formaline (or: formalin) is a solution of
formaldehyde (methanal) in water. The chemical formula of
formaldehyde is H_2CO. Formaline is commonly used to preserve
biological specimen. It is pronounced "fOrmaleen".
TODO:
put unique job IDs into all output files
done for Carpet output
but not yet after restarting
BSD tar: read files from file: -I filename
tar: don't use -z; use tar and gzip
AIX: tar is GNU tar, but uses -L instead of -T
use GNU tar, and autodetect it properly
follow symbolic links
(maybe: respect hard links)
IOUtil should not depend on anything
(MoL should not depend on NaNChecker)
use a configuration script to amend all thorns' make.code.deps files
to create the tarballs when the thorns are compiled
put arrangement name into thorn source name
use subdirectories for arrangements
use strings instead of chars for data
announce: maybe use <array> for parameter arrays
maybe use <dateTime.iso8601>20100302T00:00:00</dateTime.iso8601>
for dates and times
put the output files into the build directory instead of the scratch
directory
output grid variables
register as output method
implement reductions
implement missing data types
output only if value has changed
update the source tarballs not only when the thorn library changes,
but also when a *.ccl or make.* file changes.
do not necessarily update them all when the bindings change.
fork (or spawn a thread) before announcing, so that the simulation
does not have to wait
make sure to kill the old spawn before a new is created
make max_warn_level and output_info steerable
register with Portal/Announce as information provider
[Tom/Ian want to make Announce accept a table instead of XMLRPC]
prevent connecting to the wrong simulation, if a simulation is
outdated, and a new simulation uses the same hostname/port
combination: the portal can store the job id, and if there is a new
port id for the same hostname/port combination, deactivate the old
link.
Rebuild the flesh tarball when the ThornList changes
factor out relaying into its own class
RSS: add RSS feed
see http://blogs.law.harvard.edu/tech/rss for an RSS specification
a simple example is:
<rss version="2.0">
<channel>
<title>...</title>
<link>...</link>
<description>...</description>
<item>
<title>...</title>
<description>...</description>
</item>
</channel>
</rss>
Give each value a type. The type should describe the content, not the
presentation. E.g.: "scalar double value, normal range [0..1]", or
"keyword", or "keyword, possible values are ...", or "integer value,
value range is [1..10]".
|