PeRL : a circum-Arctic Permafrost Region Pond and Lake database

Ponds and lakes are abundant in Arctic permafrost lowlands. They play an important role in Arctic wetland ecosystems by regulating carbon, water, and energy fluxes and providing freshwater habitats. However, ponds, i. e., waterbodies with surface areas smaller than 1.0 x 10(4) m(2), have not been inventoried on global and regional scales. The Permafrost Region Pond and Lake (PeRL) database presents the results of a circum-Arctic effort to map ponds and lakes from modern (2002-2013) high-resolution aerial and satellite imagery with a resolution of 5m or better. The database also includes historical imagery from 1948 to 1965 with a resolution of 6m or better. PeRL includes 69 maps covering a wide range of environmental conditions from tundra to boreal regions and from continuous to discontinuous permafrost zones. Waterbody maps are linked to regional permafrost landscape maps which provide information on permafrost extent, ground ice volume, geology, and lithology. This paper describes waterbody classification and accuracy, and presents statistics of waterbody distribution for each site. Maps of permafrost landscapes in Alaska, Canada, and Russia are used to extrapolate waterbody statistics from the site level to regional landscape units. PeRL presents pond and lake estimates for a total area of 1.4 x 10(6) km(2) across the Arctic, about 17% of the Arctic lowland (Peer reviewe

Log::ProgramInfo: A Perl module to collect and log data for bioinformatics pipelines.

BackgroundTo reproduce and report a bioinformatics analysis, it is important to be able to determine the environment in which a program was run. It can also be valuable when trying to debug why different executions are giving unexpectedly different results.ResultsLog::ProgramInfo is a Perl module that writes a log file at the termination of execution of the enclosing program, to document useful execution characteristics. This log file can be used to re-create the environment in order to reproduce an earlier execution. It can also be used to compare the environments of two executions to determine whether there were any differences that might affect (or explain) their operation.AvailabilityThe source is available on CPAN (Macdonald and Boutros, Log-ProgramInfo. http://search.cpan.org/~boutroslb/Log-ProgramInfo/).ConclusionUsing Log::ProgramInfo in programs creating result data for publishable research, and including the Log::ProgramInfo output log as part of the publication of that research is a valuable method to assist others to duplicate the programming environment as a precursor to validating and/or extending that research

Wetting of gradient fields: pathwise estimates

We consider the wetting transition in the framework of an effective interface model of gradient type, in dimension 2 and higher. We prove pathwise estimates showing that the interface is localized in the whole thermodynamically-defined partial wetting regime considered in earlier works. Moreover, we study how the interface delocalizes as the wetting transition is approached. Our main tool is reflection positivity in the form of the chessboard estimate.Comment: Some typos removed after proofreading. Version to be published in PTR

PURR - The Persistent URL Resource Resolver

URLs have a precarious functional lifespan. They resolve the intended target (web page, PDF, audio stream, and so on) only so long as the target is available, otherwise they'll point to a dead end. Unfortunately, because companies fold, management changes, URL hostnames change, pages move, services are upgraded and reorganized, content becomes obsolete, and a host of other reasons, reliable, persistent URLs are the exception to the norm. We implemented PURR to provide persistent URLs to documents in our eprint archives. (See http://library.caltech.edu/digital)

Covariance and Controvariance: a fresh look at an old issue (a primer in advanced type systems for learning functional programmers)

Twenty years ago, in an article titled "Covariance and contravariance: conflict without a cause", I argued that covariant and contravariant specialization of method parameters in object-oriented programming had different purposes and deduced that, not only they could, but actually they should both coexist in the same language. In this work I reexamine the result of that article in the light of recent advances in (sub-)typing theory and programming languages, taking a fresh look at this old issue. Actually, the revamping of this problem is just an excuse for writing an essay that aims at explaining sophisticated type-theoretic concepts, in simple terms and by examples, to undergraduate computer science students and/or willing functional programmers. Finally, I took advantage of this opportunity to describe some undocumented advanced techniques of type-systems implementation that are known only to few insiders that dug in the code of some compilers: therefore, even expert language designers and implementers may find this work worth of reading