Memo issued on behalf of
National Nuclear Data Center
Brookhaven National Laboratory
USA
Memo CP-C/388
Date:
To:
From:

11 February 2010
Distribution
O. Schwerer

Subject:

Must compilers always use all possible options?

I am increasingly confused by requests from NRDC colleagues (in their feedback oncompilations) to use compilation options which are optional, in cases where these
options are, in my opinion, not only not obligatory, but making things unnecessarily
complicated both for the compiler and the user.
I therefore suggest to discuss this at the forthcoming NRDC meeting with the aim ofeither making (some of) these options obligatory (which in general I do not support),
or to leave the decision to the compiler, as it was originally intended.
Two recent examples:
1) Requests to add the heading (MONIT)
to keywords MONITOR and MONIT-REF when only one monitor was used.
I believe that it is obvious for the user that the values of a single monitor reaction,
defined under the keyword MONITOR, will appear in the DATA section under theheading MONIT.
Repeating the heading MONIT in the BIB section appears to me more confusing thanhelpful for the user and an unnecessary additional step for the compiler.
The option to code headings such as MONIT1, MONIT2 etc. under MONITOR,MONIT-REF and DECAY-MON is used when more than one monitor reaction needs
to be coded, and should, in my opinion, normally be restricted to these cases.

2) Coding of natural isotopic abundances in coded form under SAMPLEThis option was introduced after a proposal in February 2009 (memo CP-D/546 ofwhich I was a co-author). The possibility to code abundances of isotopes within asample of natural isotopic composition was not meant to be a new obligation tocompilers but an option to give these numbers when necessary, e.g. in cases ofisotopes of very low abundance which are not as accurately known as the mainisotopes, or when authors used an old value which is no longer up to date, or
whenever the compiler considers it useful. However, in case of isotopes whoseabundance has been known accurately for a long time, for which authors give thevalues e.g. of NuDat, there should be no obligation to code them under SAMPLE.
While there can be cases where the use of a non-obligatory "option" can berecommended for a good reason, I am against automatic requests to always use allthinkable additional options, and I do not consider this to be always the bestcompilation practice.
I would welcome clarification of the two cases outlined above and, more generally, aconfirmation that optional compilation possibilities are really optional rather thanobligatory.

Distribution:
blokhin@ippe.ru
chiba@earth.sgu.ac.jp
claes.nordborg@oecd.org
emmeric.dupont@oecd.org
ganesan@barc.gov.in
gezg@ciae.ac.cn
hongwei@ciae.ac.cn
jhchang@kaeri.re.kr
j.roberts@iaea.org
kaltchenko@kinr.kiev.ua
katakura.junichi@jaea.go.jp
kato@nucl.sci.hokudai.ac.jp
kirarlyb@atomki.hu
l.vrapcenjak@iaea.org
manuel.bossant@oecd.org
manokhin@ippe.ru
mmarina@ippe.ru
mwherman@bnl.gov
nicolas.soppera@oecd.org
nklimova@kinr.kiev.ua

n.otsuka@iaea.org
nrdc@jcprg.org
oblozinsky@bnl.gov
ogritzay@kinr.kiev.ua
otto.schwerer@aon.at
pronyaev@ippe.ru
r.forrest@iaea.org
samaev@obninsk.ru
s.babykina@polyn.kiae.su
scyang@kaeri.re.krs.dunaeva@iaea.org
stakacs@atomki.hu
stanislav.hlavac@savba.sk
taova@expd.vniief.ru
tarkanyi@atomki.hu
varlamov@depni.sinp.msu.ru
vlasov@kinr.kiev.ua
vmclane@optonline.net
v.zerkin@iaea.org
yolee@kaeri.re.kr