Reference people

A couple of days ago, a rather malformed email with the subject "Reference man....bad? should it be changed?" arrived in my inbox:

Hi,

I am and one of the cases is talking about how the nuclear clean-up sites standards should be changed from not only including the Reference Man...but other age groups as well.

Do you think this would be an effective policy to put in place? Or do you see places where they might have problems?

Thanks!

~Chrissy

I am still baffled by the first half of the first sentence, but I attempted a coherent answer nonetheless, since I have the feeling that this individual is a grade schooler asking for information for a research report. Conceivably, my answer may be of use to some other fledgeling researcher, so I'm posting it here.

Dear Chrissy,

If I understand your question correctly, you're asking if the Reference Man model is too inaccurate to continue being used. In short, the answer is no; however, there are a number of applications where its use as model would be inappropriate. In fact, in the 35 years since ICRP 23 (which defined Reference Man) was released, a number of other reference individuals have been created. According to the book for my health physics class [James E. Turner, Atoms, Radiation, and Radiation Protection, 2nd ed., John Wiley & Sons, Inc., New York, 1995, pp. 487--489], "reference data have been compiled for an adult female and for children and infants of various ages." So, actually, part of what you're asking has already been done.

Reference Man's purpose is to simulate the effect of an internal radiation dose (i.e., inhaling radioactive dust that sticks inside the lungs) on the rest of a person's body. For the most part, these estimates for effective radiation doses are very rough, accurate to perhaps on the order of ten percent. Since Reference Man is primarily used to estimate values for workmen, it would usually approximate an average worker pretty well. (Children, for example, are not often radiation cleanup workers.) For other cases where more accurate doses to particular people need to be calculated, one of the other reference models can be used.

When high precision is needed, the models used are far more detailed. As an example, consider radiation therapy for cancer, where very high doses of radiation are needed to very specific areas of a person (the cancerous parts). Cancer tissue is more susceptible to radiation than healthy tissue, but healthy parts are still damaged by large amounts of radiation. Therefore, the medical physicists need to make very accurate representations of the person, which is usually done by taking a detailed scan of them with MRI or CT scans. Then, once they have determined the proper settings that will eliminate the cancer but not the person, they do the therapy. No professional would consider using a rough model like Reference Man for a one-shot, high-precision job like that.

In summary, Reference Man is only a tool. He is a model used as a good first-order approximation to the general public. As such, it's not necessary to impose extra policies: when more precision is needed, better models are used.

I hope this answers your question satisfactorily.

Regards,
Seth Johnson

ANS transaction summary example

It's "call to papers" time for the ANS transactions, and a number of hits regarding a LaTeX template for it are increasing. (For whatever reason, the ANS only provides an example file in MS Word.)  I've had a request for an example file showing how to use them; for any other interested parties, the example has now been uploaded.

New design

Five years after this blog's inception, I've updated the appearance. I have too much else going on to make everything pixel-perfect, but its current state is satisfactory compared to the previous stale design.

Who needs five digits of accuracy anyway

At the ANS Mathematics & Computational topical conference this spring, I heard a rumor (from a very well-placed source) about an ironic error in MCNP.

MCNP is considered by many in the labs and industry to be "the" nuclear simulation program of choice. It's a Monte Carlo transport program with continuous energy data and the ability to represent virtually exact geometry (with no truncation error for smooth surface, unlike in deterministic methods). It's had many decades of development, and it's been tested and tweaked considerably to match up with experimental and numerical benchmarks. Naturally, then, a simulated result from MCNP is often used as a reference answer when comparing new codes.

No simulation can exactly represent reality: there are always errors in data, simplifications in the physics, etc. This should always be kept in mind when doing computational anything. Case in point, I heard of a "run-off" benchmark between MCNP and another reactor code, SCALE. The result was that MCNP got the right answer and SCALE was wrong: the only problem was that their definition of the "right" answer was based on an MCNP-run calculation.

The error in MCNP—which you can verify yourself with the card entry print 98—is laughably simple yet indeterminately old. Avogadro's number, which converts between the number of atoms and the mass in a material, is programmed to be 6.022043447E+23 rather than the correct 6.02214179E+23. (In fact, it's written to 16 digits of "accuracy" even though only about ten are scientifically known to any precision.) The irony is that if they change Avogadro's number, their carefully benchmarked answers will come out "wrong."

It's not a huge problem, since I doubt most answers would be sensitive to such a small perturbation, but it serves as a warning to carefully consider the difference between "true" and "best approximation."

Grammar fact of the day

I am apparently overly prone to hyphenating words. I knew that compound adjectives are supposed to be hyphenated. (Compound adjectives are modifiers composed of two words stuck together.) However, I wasn't sure if predicate adjectives were supposed to be hyphenated. I would certainly have a time-dependent simulation, but could I say that my simulation is time-dependent? As it turns out, I cannot grammatically say so. My problem is time dependent, as is my comprehension of the English language and its quaint usage rules.

SWIG and Traits classes

With all the new code I've been writing—namely, a large number of classes and template parameters and typedefs—I've been using a number of traits classes. This unfortunately posed a problem for SWIG (which provides a Python front-end to the C++ code), because it had trouble deducing the true object types through the maze (albeit short) of inheritance, typedefs, and template parameters. It had trouble despite the %include "Traits.hpp" command, which makes it aware of the traits class with template parameters.

My first solution was to wrap the troublesome traits-derived typenames with #if SWIG [explicitly substitute types] #else [use normal traits] #endif. It nullified a subset of the purpose of the traits class, but it did the job well enough.

The problem cropped up again today with a new class. Frustrated, I cast about for a solution, and tried explicitly instantiating the template in SWIG with %template(TraitsT) Traits<OneD, Gray>;. To my surprise, it worked! So apparently it's necessary to instantiate a traits class (even if it is a struct with no methods or data) in order to get SWIG to properly parse the typedefs in classes that use those traits.

EDIT: Looks like the manual actually has an entry about this. It recommends %template() traits<double,double>; to avoid generating unnecessary wrappers for it.

Bad writing

I am compelled to link to How To Write Badly Well, whose example texts read like entries to the Bulwer-Lytton Fiction Contest. Coincidentally, they both resemble Dan Brown's writing style.

Make dylib paths absolute

One problem I have come across in my trek through the murky swamps of open source libraries and so forth have been occasional issues with shared libraries on the mac. Shared libraries (dylib files on the mac, so files on Linux systems) are modules of code loaded at run time; the binary executables (or other object files) only store a path to the shared library file (and sometimes a version number). Sometimes this path is wrong: either the shared library has moved, or in the case of Boost's generated libraries, it compiled in a relative path rather than an absolute path. I ran into this issue before with CUDA's dynamic library (I was flabbergasted that it didn't automatically store an absolute path when I passed an absolute path to the linker), and my half-kludge of a fix was to add the environmental variable DYLD_LIBRARY_PATH=:/usr/local/cuda/lib.

Well, it happened again today; Boost was failing with dyld not loaded, image not found. I hit upon the google query that brought up an Apple developer page that explained the issue well.

I invented a general solution, since this will probably happen again to me. If you have shared libraries that don't use an absolute path (or don't use the right path), cd to the directory in which they reside and run the following command:

for f in *.dylib; do sudo install_name_tool -id $(pwd)/$f $f; done

Ta-da!

Ah, keyboard shortcuts.

I'm too used to using vim, where Ctrl-w deletes the preceding word in insert mode. (The same shortcut works in the terminal and other places, as well.) The downside is that when I'm on a Windows machine, i.e. using Firefox at the library, trying to delete a word reflexively closes the window in which I'm typing. This has happened three times already and almost happened once while typing in this post.

Abbreviating Russian names in BibTeX

Some of my research involves a Russian-developed method called Quasidiffusion, so naturally the appropriate works need to be properly cited. BibTeX, however, was mangling the correctly abbreviated Russian names.

"Дмитрий Ю. Анистратов" is transliterated as "Dmitriy Yu. Anistratov." Note that the middle initial is one character in the Cyrillic alphabet, but it becomes two Latin characters. Even when I enclosed the middle initial with a set of braces (which in most cases forces it to represent the text exactly), BibTeX truncated it to one Latin character (ANISTRATOV, D. Y.), which is incorrect.

The solution, gleaned from this document, is to use {\relax Yu}. as the middle name. Now, the author entry Anistratov, Dmitriy {\relax Yu}. is correctly abbreviated as "ANISTRATOV, D. YU."