Jean, I would not want to go later than Feb. 13, i.e. give them the
weekend. I will also be at a meeting next week Mo-Thurs. which limits my
infrastructural possibilities some (but not totally :-)) - Chris
Jean Utke wrote:
>Hi,
>
>I briefly talked to Paul about this but since I hadn't seen a
>problem postponing the due date to begin with I am not sure what
>to tell him about delivering his revised version later.
>Chris and Shaun, since you voted for sticking to the 7th as I remember
>can you please let me know what to tell Paul (or send him e-mail
>directly)?
>
>Thanks,
>
>jean
>
>Jean Utke
>Argonne National Lab./MCS
>utke(a)mcs.anl.gov
>phone: 630 252 4552
>cell: 630 363 5753
>
>On Mon, 6 Feb 2006, Paul Hovland wrote:
>
>
>
>>Dear AD2006 organizers,
>>
>>Today we received reminders from Uwe that our revised papers are due
>>tomorrow, Feb 7, and from the ICCS organizers that they are due Feb
>>19. The original conditional acceptance letter we received from Jean
>>indicated that the deadline of Feb 7 was due to a Feb 10 final deadline
>>imposed by the ICCS organizers. Since the ICCS organizers appear to
>>have pushed this final date back to the 19th, will the AD2006 deadline
>>be pushed back to Feb 16 (or, since 19 is a Sunday, perhaps Feb 15)?
>>I'm not too worried about the Linearity paper with Michelle (although
>>given all of my other commitments, a few extra days there wouldn't hurt
>>either), but I'm a little worried about the Dynamic Analysis paper with
>>Barbara Kreaseck, especially since Michelle and I haven't been able to
>>devote much time to it. We will comply with the Feb 7 deadline if
>>necessary, but 12 days for y'all to evaluate the revised version does
>>seem a tad excessive.
>>
>>Thanks for any clarification you can provide...
>>
>>Paul
>>
>>
>>
>>
>
>
>
>
--
Prof. Christian Bischof, Ph.D.
Institute for Scientific Computing and Center for Computing and
Communications
RWTH Aachen University
Seffenter Weg 23, 52074 Aachen, Germany
Tel. +49-241-8029110, Fax +49-241-8022241
bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>,
www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>
Hi Barbara,
I briefly discussed this with Paul this morning. I sent an e-mail
to hear from the other members of the organizing committee since
some of us definitly wanted to keep the 7th despite the last minute
surprise extension
given by the conference. I will let you know as soon as I get feedback.
Jean
Barbara Kreaseck wrote:
>Hi Jean,
>
>This announcement from ICCS 2006, contains the deadline of
>February 19 for the final version of the paper. I understand
>that this extends the deadline from February 10 to February 19.
>
>What impact does this new deadline have upon the workshop
>deadline of February 7 (tomorrow)? Can we have until February
>16, instead?
>
>Thanks.
>
>-- Barbara
>
>---------------------- Original Message -----------------------
>Subject: [ICCS 2006] Review results
>From: "ICCS 2006 Org. Com." <dick(a)science.uva.nl>
>Date: Sat, February 4, 2006 4:31 am
>To: "B. Kreaseck" <bkreasec(a)lasierra.edu>
>---------------------------------------------------------------
>
>Dear B. Kreaseck:
>
>This e-mail concerns your paper submission entitled Hybrid
>Static/Dynamic
>Activity Analysis for one of the workshops in ICCS 2006. We
>would like to
>thank you for your contribution to the ICCS 2006 conference.
>After an
>extensive review we are happy to announce that your paper has
>been accepted
>for publication and for ORAL PRESENTATION (20 minutes) at the
>ICCS 2006
>conference in Reading (UK)
>
>Comments by the reviewers of your paper can be found on the
>following specific
>web page:
>http://www.iccs-meeting.org/iccs2006/papers/paper.php?authid=884P447BD6FBBE…
>This acceptance is CONDITIONAL in the sense that BEFORE
>February 19 we need:
>- your paper of no more than 8 camera-ready pages, taking into
>account the
>remarks by the reviewers and formatted STRICTLY ADHERING to the
>LNCS format
>rules.
> The guidelines for submitting the camera-ready paper can be
>found on the
>following web page:
> http://www.springer.com/sgw/cda/frontpage/0,11855,5-164-2-72376-0,00.html,
>- your copyright transfer form,
>- your registration for the conference before March 10!
>
>Please, note that exceeding the 8 page limit will result in you
>paper being
>dropped from the proceedings.
>
>Please, precisely follow the LNCS rules and upload the final
>camera-ready
>version in POSTSCRIPT or PDF. Also upload the complete sources.
>(MS Word doc
>files, or tex with all figures and styles. The latter
>preferably in a zip or
>zipped tar file.)
>Remember that at least one of the co-authors of each paper must
>register for
>the conference and present the paper in order for the paper to
>be included in
>the Proceedings.
>
>Your copyright transfer should be faxed to Fax: + 44 118 378
>5224; for the
>form see the Spinger site above.
>
>For your registration form and information on the registration
>fee, see:
>http://www.iccs-meeting.org/iccs2006/
>Registration information will be available from Monday,
>February 6 onwards.
>
>Thank you for your work and interest in ICCS. Please, do not
>hesitate to
>contact us with any questions that you may have.
>
>Please, note that travel to Reading may require you to start
>arranging things
>NOW (visa, airline seat reservations, etc.).
>Information about obtaining invitation letters for visa can be
>found on the
>ICCS 2006 website.
>
>Thanks again for your contribution to ICCS 2006 conference.
>
>
>Scientific Organizing Committee
>ICCS 2006
>
>
>
>
--
Jean Utke
Argonne National Lab./MCS
utke(a)mcs.anl.gov
phone: 630 252 4552
cell: 630 363 5753
Folks,
Info from the organizers concerning notification of authors below.
I just sent out a reminder for the three accepted papers that I am
responsible for (to Shaun, Ralf Giering, J. Kim@MCS) to remind them of
the fact that papers were due on Feb. 7.
I also had two slots for a telco scheduled, 4.30pm on Tue and 4pm on
Wed. In light of the moved deadline, I suggest that we do a TelCo on
Wed. 4pm my time. Would that suit all of you?
Best regards,
Chris
-------- Original Message --------
Subject: [ICCS 2006] e-mails sent
Date: Sat, 04 Feb 2006 15:04:13 +0100
From: ICCS 2006 Org. Com. <dick(a)science.uva.nl>
Reply-To: dick(a)science.uva.nl
To: bischof(a)sc.rwth-aachen.de, "C. Bischof" <bischof(a)sc.rwth-aachen.de>
Dear C. Bischof,
Barring mistakes, your authors should now have received the e-mails giving
them the review outcome.
Kind regards,
Dick van Albada
--
Prof. Christian Bischof, Ph.D.
Institute for Scientific Computing and Center for Computing and
Communications
RWTH Aachen University
Seffenter Weg 23, 52074 Aachen, Germany
Tel. +49-241-8029110, Fax +49-241-8022241
bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>,
www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>
Please find attached:
-- The revised version of our ICCS 2006 paper
as a tar.gz file with the latex source,
2 postscript figures and a .bib bibliography
-- The concatenation of the three referees reports,
with our replies inserted inside.
The paper suggests a formal approach to characterize
checkpointing sets vs taping. Both the application to
programs that do not exhibit a special looping structure
as well as the characterization of minimal solutions are new.
It is a very usefull foray into using data flow for
determining checkpointing sets and should definitly be
accepted.
The issues mentioned below should improve readability
for the general audience.
major comments:
A:
I realize notation regarding the result of
the source transformation of program subsections in
terms of forward and reverse is difficult
because it does not lend itself easily to checkpointing schemes.
E.g. on pg.3 Sect.3 states:
$\overline{C}\Doteq\overrightarrow{C};\overleftarrow{C}$
and in this notation there is no mentioning of taking
the checkpoint, running forward and later restoring the checkpoint
although this certainly belongs to the source transformation of
code section $C$ which is presumably what is denoted by $\overline{C}$
if one goes by the explanation of $P$ and $\overline{P}$ on page 2.
Then on the top of page 4 there is a different notation that does
includes the store/restore etc.
>> Right. I added notation [] to denote checkpointing.
>> \overline{C;D} is thus
>> \overrightarrow{C};\overrightarrow{D};\overleftarrow{D};\overleftarrow{C}
>> whereas \overline{[C];D} is the reverse diff program with C checkpointed
>> with the store, restore, etc.
However, on page 4 I am missing
an explanation of the notation "\hbox{\it Req} \vdash"
which is repeatedly used as something being executed while
"Req" itself is a set. The notation should be clarified.
>> Req is not a piece of code. It is a context in which
>> the code generation is done. When using rewrite rules,
>> people use \vdash to mean this.
>> Yes the rewrite rules here are ambiguous.
>> I put a box around to distinguish the rewrite terms
>> plus one line of explanation.
B:
I don't see a clear motivation for the backward snapshot
as opposed to the tape. In the paper just states it is a "hybrid".
The need for the regular checkpoints is clear.
>> Backward snapshot does not save memory space,
>> but may reduce memory traffic (e.g only one
>> push/pop pair instead of 2. Added this on page 4.
Sect 4. mentions that there can be a trade-off between
storing/restoring things in big blocks vs.
doing it one at a time. This would presumably be the implied
motivation for the backward snapshots.
It would be nice if the conclusions section could address this by
showing more detail about profile data for taping push/pops
vs. storing/restoring snapshots.
>> Our first measurements on memory traffic are too recent,
>> and not conclusive yet.
C:
I missed any mentioning of checkpoint placement as an issue.
The space constraints don't allow to go into much detail.
However, it should be pointed out that (aside from special
cases such as time stepping loops) the segmentation of the code
into the subsections U,C,D
which in this paper is predetermined can have a substantial
impact on the checkpoint size.
>> I took your words to rephrase the end of the conclusion,
>> which meant that.
minor comments:
pg 2: If there isn't a special purpose for calling the three parts
upstream/center/downstream, could they be renamed A/B/C instead?
>> I sort of like using U for Upstream, C for Checkpoint, D for Downstream ?
pg 2: Can you cite the TBR paper at the first mentioning of TBR
analysis .
>> Done
pg 2: change "... finds the Req set of these required values." to
"...finds the set of these required values denoted by Req."
>> ok
May be there is a chance to also actually
say what precisely "out()" and "use()" mean, in particular
if it is 'local use' only of cumulative with the 'use' of
a segments 'callees'. To the uninitiated
reader it is probably not clear enough from the context.
>> added a few words on bottom of page 4
pg 2: the sentence
"In other words ... must be built in such a way that:"
with the following formula should either be removed or better
explained. The assertion "must be built" wrt. the formula
becomes clear only after reading on and going back later.
>> Good. We gain 3 lines!
pg 3: I think the sentence
"This also uses memory space, although less than the tape for ..."
should really relate to the *placement* of the checkpoints, i.e.
the segmentation of the program. That is crucial and should be
mentioned to better motivate above sentence and the initial
trade-off between taping and checkpointing space.
>> agreed.
pg 5: in the condition for "\it Snp" (3rd last line),
it is not immediately apparent to me where the
\cup (\hbox{\it Req} \setminus \hbox{\it Sbk}
comes from. I suspect this is just my mistake but
without that last bit it appears
to be directly derived from eqn. (3). With
it the intersection on the right hand side may be larger
than without which makes me wonder
about the "necessary and sufficient"? Since I have
a similar problem with the Req_D eqn. I am just
guessing I am missing some step but you may want to
consider adding this.
>> This is because Snp also appears in
>> equation (4). Equation (3) alone does imply that
>> Snp >= (out(C) \cup (out(Db) \ ReqD)) \cap use(Cb)
>> in addition (4) implies that
>> Snp >= (out(C) \cup (out(Db) \ ReqD)) \cap (Req \ Sbk)
>> same happens for ReqD.
>> We do think the conditions are necessary and sufficient.
pg 6: In the solution of the set equations - what is the
optimality criterion? The text mentions "minimal" and
"optimal" solutions. Naively looking at the equations in (6)
it seems Opt_2^- is the only part occurring twice so any
partition that leaves Opt_2^- empty seems to be better
in terms of the total size of Sbk, Snp, Req_D, Req_C ?
So I suspect total memory footprint isn't the criterion.
>> Right. I added that these sets are minimal in the sense that any
>> semantics-preserving choice of the 4 sets is
>> larger or equal to one of these minimal quadruplets.
pg 8: Please clarify "... choices of the other checkpoints around."
What is around? It could be that once the notation issue raised
under the major issue "A" is addressed this may well become clear.
>> Rephrased.
--------------------------------------------------------------
[Overview]
More explanation on notation is needed.
>> added explanations on the \overline notation
>> and the rewrite rule on page 4
>> However, we will also have to spare half a page,
>> so sometimes we have to rely on commonly
>> used notation.
[Comments]
page 2, line -8 (8 from the bottom)
The term "out" is not defined here.
>> removed and explained on next occurrence page 4
page 3, line 11
The meaning of the semicolon in the notation
$\overline{D}\Doteq\overrightarrow{D};\overleftarrow{D}$
should be explained.
>> done. This use of semicolon for code sequence is widespread.
page 3, Figure 2
The term "Sbk" is not defined here.
>> Right, but it is defined upon its first occurrence in the text
page 4, line 3
The notation "$Req\vdash \overline{C;D}$" was hard to be understood
because PUSH(Sbk) is undefined here.
page 5, line 15 ( eq.(3))
The reason of disappearance of "PUSH(Sbk)" in (1) should be explained.
>> done. A PUSH does not overwrite any program variable.
--------------------------------------------
1. Introduction
You write: ... it (reverse mode AD) suffers from a high memory consumption...
That is only true for the store all or store minimal strategy
implemented in Tapenade, ADIFOR 3, and OpenAD.
If every intermediate result is recomputed then reverse mode AD needs little
memory but suffers from computational costs!
You might want to read and cite other papers about AD.
You write: This memory consumption is inherent to the nature of
gradient computation.
That is obviously wrong.
You write: to solve the adjoint equations ... is also known to consume
memory space.
What you mean by this. Almost every computation requires memory
(it doesn't consume it like eating bred).
AD generated code also solves the adjoint equation!
The first two paragraphs in the introduction need to be rewritten totally.
>> Rewritten as:
>> The methods to compute gradients can be classified in two categories.
>> In the first category, methods use CPU more intensively because
>> several operations are duplicated. This can be through
>> repeated tangent directional derivatives, or through reverse
>> Automatic Differentation using the ``Recompute-All'' strategy.
>> This is not the context of this paper. In the second category,
>> methods spare duplicated operations through increased memory use.
>> This encompasses hand-coded resolution of the ``adjoint equations''
>> and reverse Automatic Differentation using the ``Store-All'' strategy,
>> which is the context of this work.
2. Reverse Automatic Differentiation
You write: AD is a program transformation technique.
... an AD tool creates a new program ...
no, see tools based on operator overloading
>> ok. Text modified.
TBR = to be recorded not to be restored
>> Right. Fixed.
What is the definition of 'Req'?
>> Explained in section 2. Rephrased.
What is the difference between Req and use(U)?
>> In the paper we define Req as use(\overleftarrow{U}),
>> which is smaller than use(U) as said in section 2 and
>> detailed in refs [2,6]
What is the definition of OUT?
I guess what you name OUT is actually termed KILL in data flow analysis.
>> Defined now page 4. KILL usually denotes scalar and array
>> variables completely overwritten. OUT is for variables even
>> only partly overwritten.
3. The equation of checkpointing snapshots
You write: This allows the tape consumed ... to be freed ...
That is also true without checkpointing.
The tape consumed by C is relevant here,
it is needed after adjoint of D has finished.
>> Both what you write and what we wrote is true,
>> and both lead to the conclusion stated by
>> the sentence that follows.
What is Sbk?
>> Defined in detail on its first occurrence in the text, page 4.
>> True it appears on figure 2 before, but it is just a
>> support for the discussion on page 4.
You write: This also uses memory space, although less than the tape for C.
That is not always true.
>> Ok, but one can almost always write pathological examples
>> for any such assumption. In real life, the snapshot is really
>> smaller. It's an interesting question to detect those "C"'s
>> for which snapshots are larger than the tape, but
>> it's not in the scope of this paper.
4 Discussion and Experimental results
Table 1: What run-time is shown, the function or the adjoint?
One needs to see the run-time of function, eager adjoint, and lazy adjoint.
What is the memory usage and run-time without checkpointing?
>> added run-time of function.
>> Run-times with eager and lazy do not differ significantly.
>> Most examples would simply run out of memory if no
>> checkpointing was made.
5 Conclusions
I am missing an discussion of the computational cost of checkpointing,
i.e. the additional flops and the cost of writing and reading the tape.
The central question is what is the best mixture of recomputations and
taping, not memory usage alone.
>> Certainly a very general and important question.
>> This paper does not claim to answer this question.
>> But it gives an element to understand it better.
Dear organizers,
as requested I send the revised version of our paper and the commented reviews
with this email (please see the attachments). I have also submitted the new
version (PS and TGZ) via the web interface.
Regards,
Andreas Kowarz
--
*********************************************************************
Attention: My email address "kowarz(a)math.tu-dresden.de" is subject to
removal within the next few month. Please use my new
address "Andreas.Kowarz(a)tu-dresden.de" in order to contact
me per mail. Please update your address book.
Thanks.
*********************************************************************
major comments:
A:
related to pg 5 first paragraph etc:
The condition for retaping is stated only to be
a change of control flow.
...
Since a lot of this paper is about the nested taping it think it should
undertake the effort to precisely characterize when a tape representative
for a time step is valid, which invalidating scenarios are
automatically caught and which extra steps are required.
Comment:
Now, we explain that the function evaluation is retaped automatically
when the control flow changes due to a change of an adouble value.
Furthermore, now we provide a flag such that if this flag is set to 1
the function evaluation is retaped for each reverse differentiation to be on
the save side. A corresponding explanation is contained in the revised version
of the paper.
B:
related to the numerical example in Sect 3. I would find it much more
compelling if the paper gave more detail on the practical example
...
The paper would gain significantly if this effect could be shown in
a practically relevant application.
Comment:
We skipped the trajectory example and present now only the robotor example in
detail.
minor comments:
pg 2, first paragraph: The statement of "enormous memory reduction" should
be qualified. I.e. it should be stated that - presumably -
it is compared to the tape (I guess more precisely
execution trace and value tape) arising from purely split mode.
Comment:
done
pg 2, insert:
"The size of the much smaller randomly accessed ...."
^^^^^^^^^^^
Comment:
done
pg 2 last paragraph first sentence:
The memory grows with run-time, regardless if this is
a time-stepping procedure or not and what is acceptable depends on the user.
I suggest to refer directly to the new nested tape facility
in ADOL-C and
point out that time-stepping procedures usually imply repetitions of
identical operation sequences on the tape which the nested taping
eliminates as explained on the bottom of page 3.
Comment:
We reformulated this sentence
pg 4 end of first paragraph insert:
"... presented at the AD 2004 conference."
^^^^^^^^^^
Comment:
done
pg 5 Interface section: The time_step_function signature requires
the user to pack and unpack the state data that might be
distributed over various arrays into u. I am not sure that everybody
agrees this is "minimal user effort". Instead it might be fairer to say
that the objective is a "lean and concise interface" which I believe
has been achieved.
Comment:
reformulated correspondingly
The following is more of a general comment. As ADOL-C
wants to attract not only C but also C++ codes it should consider
providing actual C++ interfaces along with the old C style ones.
Serious C++ users of ADOL-C will likely
cringe at the sight of the CpInfos* to be populated
and a bunch of C functions when
all of this perfectly lends itself to a well organized class.
Comment:
We added a C++ interface and changed the description correspondingly.
p. 3 Fig 1, Fig 2: The light grey rectangle used in the new tape generation
should be explained. What is the difference w.r.t the original ones ?
Comment:
A description of this light grey rectangle is contained in the text.
What is the semantic of the arrows ? If you manage to show graphically the
different tapes it would enforce the paper.
Comment:
The figures were rearranged and are hopefully easier to understand now.
p. 4: You talk about the "external diff. function", but give no explanation
nor a pointer to the paper at AD2004.
Comment:
This was presented in the poster session. We plan to have a
documentation of this "external diff. function" facility in the
ADOL-C manual within the near future.
p. 5: You should give a code or a function example to clarify the user
intervention. Explain the difference with a manual use of resolve from
the user point of view.
Comment:
From out point of view, there is no space for such an explanation
when the page limit is set to 8. Once more, we plan to have a
corresponding documentation in the ADOL-C manual within the near future.
Typos:
p. 1 section 1: you use e.g sometimes in an unapropriate way.
Comment:
Well, we tried to fix as many as possible
p. 7: "despite the fact of the" should be changed.
Comment:
done
Experiments are made on a very small academic example.
The results are quite convincing. I'm looking forward
to results on real-life codes.
Comment:
We switched from the academic example to the roboter example
Table 1 is puzzling. It actually looks like a simple affine
function: tape-size = 492 + l*252. From which I deduce that
it shows the memory consumption without any checkpointing?
If there was some sort of optimal checkpointing, size should
grow like log(l), right?
Then why not show a table that shows that, which would
better illustrate the benefits of checkpointing?
Comment:
In the old version, the Table shows the tape-size without any
checkpointing. The tape size itself is constant if the
checkpointing is use within ADOL-C. Only the amout of memory
needed to store the checkpoints grows.
The table now shows the tape size needed without and with checkpointing.
Minor stuff:
--The "applied checkpointing procedure" sounds bizarre
cause it makes me wonder what is "applied checkpointing".
Comment:
Reformulated.
--I was told that "allowing the usage..." is incorrect,
should be "allowing us to use...", or "permits the usage..."
Comment:
Reformulated.
Wed 4pm German (=3pm GMT) OK for me.
Shaun
#####################################################################
Dr Shaun Forth
Applied Mathematics & Operational Research
Engineering Systems Department
Cranfield University, Shrivenham Campus
Swindon SN6 8LA, England
tel.: +44 (0)1793 785311
fax.: +44 (0)1793 784196
email: S.A.Forth(a)cranfield.ac.uk
http://www.amorg.co.uk <http://www.amorg.co.uk/>
http://www.rmcs.cranfield.ac.uk/amor
#####################################################################
-----Original Message-----
From: org-ad-workshop-bounces(a)lists.rwth-aachen.de
[mailto:org-ad-workshop-bounces@lists.rwth-aachen.de] On Behalf Of
Christian Bischof
Sent: Sunday, February 05, 2006 11:21 AM
To: Organizers AD Workshop
Subject: [Org-ad-workshop] [Fwd: [ICCS 2006] e-mails sent] -
next Telco
Folks,
Info from the organizers concerning notification of authors
below.
I just sent out a reminder for the three accepted papers that I
am responsible for (to Shaun, Ralf Giering, J. Kim@MCS) to remind them
of the fact that papers were due on Feb. 7.
I also had two slots for a telco scheduled, 4.30pm on Tue and
4pm on Wed. In light of the moved deadline, I suggest that we do a TelCo
on Wed. 4pm my time. Would that suit all of you?
Best regards,
Chris
-------- Original Message --------
Subject: [ICCS 2006] e-mails sent
Date: Sat, 04 Feb 2006 15:04:13 +0100
From: ICCS 2006 Org. Com. <dick(a)science.uva.nl>
<mailto:dick@science.uva.nl>
Reply-To: dick(a)science.uva.nl
To: bischof(a)sc.rwth-aachen.de, "C. Bischof"
<bischof(a)sc.rwth-aachen.de> <mailto:bischof@sc.rwth-aachen.de>
Dear C. Bischof,
Barring mistakes, your authors should now have received the
e-mails giving
them the review outcome.
Kind regards,
Dick van Albada
--
Prof. Christian Bischof, Ph.D.
Institute for Scientific Computing and Center for Computing and
Communications
RWTH Aachen University
Seffenter Weg 23, 52074 Aachen, Germany
Tel. +49-241-8029110, Fax +49-241-8022241
bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de> ,
www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/> ,
www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>
--
This message has been scanned for viruses and
dangerous content by the Cranfield MailScanner, and is
believed to be clean.
Works for me.
Uwe Naumann
Software & Tools for Computational Engineering
RWTH Aachen
http://www.stce.rwth-aachen.de
Folks,
Info from the organizers concerning notification of authors below.
I just sent out a reminder for the three accepted papers that I am
responsible for (to Shaun, Ralf Giering, J. Kim@MCS) to remind them of
the fact that papers were due on Feb. 7.
I also had two slots for a telco scheduled, 4.30pm on Tue and 4pm on
Wed. In light of the moved deadline, I suggest that we do a TelCo on
Wed. 4pm my time. Would that suit all of you?
Best regards,
Chris
-------- Original Message --------
Subject: [ICCS 2006] e-mails sent
Date: Sat, 04 Feb 2006 15:04:13 +0100
From: ICCS 2006 Org. Com. <dick(a)science.uva.nl>
Reply-To: dick(a)science.uva.nl
To: bischof(a)sc.rwth-aachen.de, "C. Bischof" <bischof(a)sc.rwth-aachen.de>
Dear C. Bischof,
Barring mistakes, your authors should now have received the e-mails giving
them the review outcome.
Kind regards,
Dick van Albada
--
Prof. Christian Bischof, Ph.D.
Institute for Scientific Computing and Center for Computing and
Communications
RWTH Aachen University
Seffenter Weg 23, 52074 Aachen, Germany
Tel. +49-241-8029110, Fax +49-241-8022241
bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>,
www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>
_______________________________________________
Org-ad-workshop mailing list
Org-ad-workshop(a)lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/org-ad-workshop
I'd prefer to stick with Feb 7th and use the slack for getting any second revisions made ( I certainly don't want my co-author thinking he can stretch things out!).
Where possible I don't think we should be going back to the referees - unless there is some point that we are not able to adequately resolve ourselves.
Shaun
P.S.
I've contacted Adrian Sandhu twice and had no reply from him - have other authors been "responsive"
________________________________
From: org-ad-workshop-bounces(a)lists.rwth-aachen.de on behalf of Jean Utke
Sent: Wed 01/02/2006 17:20
To: Organizers AD Workshop
Subject: Re: [Org-ad-workshop] [Fwd: Official acceptance of your ICCS 2006 workshop.]
Hi,
My thought was that we do this review amongst 4 of us without involving
the reviewers unless there are
specific questions. I didn't plan on spending a huge amount of time on
that, basically just going through the
authors comments towards the issues raised by the reviewers and
verifying some changes right away on the
day I get it and then we discuss it. That allows for 1 or 2 days in case
another fix is needed which I hope is enough.
So, I would be ok to tell them we want it by the 14th or 15th. The 19th
is a Sunday which may be bad since I still
am unclear how we are supposed to submit the final version. Chris, have
you got more info on that?
Jean
Christian Bischof wrote:
> Hi folks,
>
> we're in. Congrats and thanks to the work to yo all.
>
> Do we want to let the deadline slip (before it was Febr. 10). My
> feeling is that the we should stick to the previously announced
> deadline of Febr. 7 (i.e. roughly a week from now) and use the extra
> days to look over the papers returned carefully. In fact, I was
> planning on reminding "my" authors tomorrow of the Febr. 7 deadline.
>
> - Chris
>
> -------- Original Message --------
> Subject: Official acceptance of your ICCS 2006 workshop.
> Date: Wed, 01 Feb 2006 16:42:47 +0100
> From: Dick van Albada <dick(a)science.uva.nl>
> To: Christian Bischof <bischof(a)rz.rwth-aachen.de>
> References: <43A03FAD.6050005(a)rz.rwth-aachen.de>
> <43D4ECC5.8090809(a)science.uva.nl> <43D507EB.4050207(a)rz.rwth-aachen.de>
>
>
>
>Dear Prof Bischof,
>
>After the factual acceptation of your workshop for ICCS 2006, I still
>owe you the offical acceptance. You have already informed your authors.
>We'll be sending out acceptance/rejection e-mails to all workshop
>authors shortly with formatting and size instructions, but are waiting
>for the results of some of the other workshops. You can let your authors
>know that the firm deadline for camera-ready papers is now at February 19.
>
>Many thanks for your efforts for ICCS 2006
>
>Kind regards,
>
>Dick van Albada
>
>Christian Bischof wrote:
>
>> Dear Prof. van Albada,
>>
>> Of the 9 papers accepted, eight are in our view acceptable with small
>> modifications, one paper needs a substantial rewrite. We have informed
>> the authors of our decision, and asked them to submit a revised
>> version by Febr. 7, in order to make sure that the authors take the
>> suggestions of the referees into account.
>>
>> With best regards,
>> Chris Bischof
>>
>> Dick van Albada wrote:
>>
>>> Dear Prof Bischof,
>>>
>>> I was happy to notice on your workshop management page that you have
>>> already completed your reviews. The quality of the reviews looks very
>>> good in general, although I noticed one or two strongly differing
>>> opinions here and there.
>>> I saw that you have marked 9 out of 15 papers as "invited", but do
>>> not know if you have already informed the authors about the results.
>>> If not, please do wait until the end of this week. We'll be
>>> discussing the review results with the scientific organising
>>> committee on Thursday and Friday, and because of the sheer size of
>>> the conference, we may have to ask to use a slightly stricter cut.
>>> By the way, you marked the accepted papers as invited - please use
>>> "oral" or, where applicable, "poster".
>>>
>>> Kind regards,
>>>
>>> Dick van Albada
>>>
>>>
>>
>> --
>>
>> Prof. Christian Bischof, Ph.D.
>>
>> Institute for Scientific Computing and Center for Computing and
>> Communications
>>
>> RWTH Aachen University
>>
>> Seffenter Weg 23, 52074 Aachen, Germany
>>
>> Tel. +49-241-8029110, Fax +49-241-8022241
>>
>> bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
>> www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/ <https://secure.rmcs.cranfield.ac.uk/> >,
>> www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/ <https://secure.rmcs.cranfield.ac.uk/,DanaInfo=www.rz.rwth-aachen.de+> >
>>
>
>
>
>
>
>
> --
>
> Prof. Christian Bischof, Ph.D.
>
> Institute for Scientific Computing and Center for Computing and
> Communications
>
> RWTH Aachen University
>
> Seffenter Weg 23, 52074 Aachen, Germany
>
> Tel. +49-241-8029110, Fax +49-241-8022241
>
> bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
> www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/ <https://secure.rmcs.cranfield.ac.uk/,DanaInfo=www.sc.rwth-aachen.de+> >,
> www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/ <https://secure.rmcs.cranfield.ac.uk/,DanaInfo=www.rz.rwth-aachen.de+> >
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Org-ad-workshop mailing list
>Org-ad-workshop(a)lists.rwth-aachen.de
>http://mailman.rwth-aachen.de/mailman/listinfo/org-ad-workshop <https://secure.rmcs.cranfield.ac.uk/mailman/listinfo/org-ad-workshop,DanaIn…>
>
>
--
Jean Utke
Argonne National Lab./MCS
utke(a)mcs.anl.gov
phone: 630 252 4552
cell: 630 363 5753
_______________________________________________
Org-ad-workshop mailing list
Org-ad-workshop(a)lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/org-ad-workshop <https://secure.rmcs.cranfield.ac.uk/mailman/listinfo/org-ad-workshop,DanaIn…>
--
This message has been scanned for viruses and
dangerous content by the Cranfield MailScanner, and is
believed to be clean.
Hi,
I think I remembered things not quite right and
rereading the following bit of an earlier mail fron van Albada:
As the review deadline now only is one week away,
I have now disabled the registration of new papers for all
workshops. (Depending on the settings for your workshop,
authors still may be able to upload modified versions of their papers.)
it sounds like we could turn author uploading back on and it would allow
them to
update their files. I would prefer the upload over having the revised
version mailed to us and
then (me at least) getting the update wrong.
But it might also be useful to keep the old version for comparison. I
have a set
of the papers I reviewed in the first round on my laptop. So, by when
should we open the upload again?
That should also go into the reminder e-mail to be sent out.
jean
--
Prof. Christian Bischof, Ph.D.
Institute for Scientific Computing and Center for Computing and
Communications
RWTH Aachen University
Seffenter Weg 23, 52074 Aachen, Germany
Tel. +49-241-8029110, Fax +49-241-8022241
bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>,
www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>
_______________________________________________
Org-ad-workshop mailing list
Org-ad-workshop(a)lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/org-ad-workshop
Hi folks,
we're in. Congrats and thanks to the work to yo all.
Do we want to let the deadline slip (before it was Febr. 10). My feeling
is that the we should stick to the previously announced deadline of
Febr. 7 (i.e. roughly a week from now) and use the extra days to look
over the papers returned carefully. In fact, I was planning on reminding
"my" authors tomorrow of the Febr. 7 deadline.
- Chris
-------- Original Message --------
Subject: Official acceptance of your ICCS 2006 workshop.
Date: Wed, 01 Feb 2006 16:42:47 +0100
From: Dick van Albada <dick(a)science.uva.nl>
To: Christian Bischof <bischof(a)rz.rwth-aachen.de>
References: <43A03FAD.6050005(a)rz.rwth-aachen.de>
<43D4ECC5.8090809(a)science.uva.nl> <43D507EB.4050207(a)rz.rwth-aachen.de>
Dear Prof Bischof,
After the factual acceptation of your workshop for ICCS 2006, I still
owe you the offical acceptance. You have already informed your authors.
We'll be sending out acceptance/rejection e-mails to all workshop
authors shortly with formatting and size instructions, but are waiting
for the results of some of the other workshops. You can let your authors
know that the firm deadline for camera-ready papers is now at February 19.
Many thanks for your efforts for ICCS 2006
Kind regards,
Dick van Albada
Christian Bischof wrote:
> Dear Prof. van Albada,
>
> Of the 9 papers accepted, eight are in our view acceptable with small
> modifications, one paper needs a substantial rewrite. We have informed
> the authors of our decision, and asked them to submit a revised
> version by Febr. 7, in order to make sure that the authors take the
> suggestions of the referees into account.
>
> With best regards,
> Chris Bischof
>
> Dick van Albada wrote:
>
>> Dear Prof Bischof,
>>
>> I was happy to notice on your workshop management page that you have
>> already completed your reviews. The quality of the reviews looks very
>> good in general, although I noticed one or two strongly differing
>> opinions here and there.
>> I saw that you have marked 9 out of 15 papers as "invited", but do
>> not know if you have already informed the authors about the results.
>> If not, please do wait until the end of this week. We'll be
>> discussing the review results with the scientific organising
>> committee on Thursday and Friday, and because of the sheer size of
>> the conference, we may have to ask to use a slightly stricter cut.
>> By the way, you marked the accepted papers as invited - please use
>> "oral" or, where applicable, "poster".
>>
>> Kind regards,
>>
>> Dick van Albada
>>
>>
>
> --
>
> Prof. Christian Bischof, Ph.D.
>
> Institute for Scientific Computing and Center for Computing and
> Communications
>
> RWTH Aachen University
>
> Seffenter Weg 23, 52074 Aachen, Germany
>
> Tel. +49-241-8029110, Fax +49-241-8022241
>
> bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
> www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>,
> www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>
>
--
Prof. Christian Bischof, Ph.D.
Institute for Scientific Computing and Center for Computing and
Communications
RWTH Aachen University
Seffenter Weg 23, 52074 Aachen, Germany
Tel. +49-241-8029110, Fax +49-241-8022241
bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>,
www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>,
www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>