Wildfire: distributed, Grid-enabled workflow construction and execution

BACKGROUND: We observe two trends in bioinformatics: (i) analyses are increasing in complexity, often requiring several applications to be run as a workflow; and (ii) multiple CPU clusters and Grids are available to more scientists. The traditional solution to the problem of running workflows across multiple CPUs required programming, often in a scripting language such as perl. Programming places such solutions beyond the reach of many bioinformatics consumers. RESULTS: We present Wildfire, a graphical user interface for constructing and running workflows. Wildfire borrows user interface features from Jemboss and adds a drag-and-drop interface allowing the user to compose EMBOSS (and other) programs into workflows. For execution, Wildfire uses GEL, the underlying workflow execution engine, which can exploit available parallelism on multiple CPU machines including Beowulf-class clusters and Grids. CONCLUSION: Wildfire simplifies the tasks of constructing and executing bioinformatics workflows

IP services design and implementation in a prototype device for transient tactical access to sensitive information

In network-centric warfare, access to critical information can result in a strategic advantage. During critical situations, a soldier using tactical devices may need transient access to information beyond their normal clearances. The Least Privilege Separation Kernel (LPSK) being developed at the Naval Postgraduate School, can be the basis of an extended multilevel security (MLS) system that can support and control such access. A Trusted Services Layer (TSL), which depends on the LPSK, provides support for various multilevel security services. Currently, the LPSK lacks a software network stack for networking communications. Without networking functionality, tactical devices cannot share vital situational updates and information superiority is unattainable. An Internet Protocol (IP) stack was proposed for the LPSK-based system. The IP stack is to be implemented in the context of the LPSK architecture, which uses modularity and layering to organize its software. Open source implementations of the IP stack were evaluated to leverage the common functionality required by all IP stacks. Lightweight Internet Protocol (LWIP) was selected as a starting point for use with the LPSK. LWIP required modifications for use with the LPSK. The IP stack and a proof of concept networking demonstration were successfully implemented in this project.http://archive.org/details/ipservicesdesign109454982Singapore Technologies Engineering author (civilian)Approved for public release; distribution is unlimited

Wildfire: distributed, Grid-enabled workflow construction and execution-5

<p><b>Copyright information:</b></p><p>Taken from "Wildfire: distributed, Grid-enabled workflow construction and execution"</p><p>BMC Bioinformatics 2005;6():69-69.</p><p>Published online 24 Mar 2005</p><p>PMCID:PMC1274263.</p><p>Copyright © 2005 Tang et al; licensee BioMed Central Ltd.</p> The components in this workflow are all custom applications, or custom scripts calling standard applications. Components format, group, join_scr and process_scr are administrative programs which translate and convert files from one format to another. Component rscript uses the R-project to cluster the amino acid sequences from a database of known allergens. For each cluster, we align its sequences and use a wavelet algorithm to predict motifs. The resulting motifs are used to construct HMM profiles using hmmbuild. Finally, we use these profiles with hmmpfam to predict allergenic sequences. Components join_scr and process_scr collate and summarise the results

Wildfire: distributed, Grid-enabled workflow construction and execution-4

<p><b>Copyright information:</b></p><p>Taken from "Wildfire: distributed, Grid-enabled workflow construction and execution"</p><p>BMC Bioinformatics 2005;6():69-69.</p><p>Published online 24 Mar 2005</p><p>PMCID:PMC1274263.</p><p>Copyright © 2005 Tang et al; licensee BioMed Central Ltd.</p>rallel within a parallel for loop. The circle denotes a while loop, with test as loop guard: if test returns false, then we follow the bottom branch to extract, otherwise we follow the right branch and test test again after reassign. Component eval2 is executed in parallel once for each file matching follower_sol*

Wildfire: distributed, Grid-enabled workflow construction and execution-0

<p><b>Copyright information:</b></p><p>Taken from "Wildfire: distributed, Grid-enabled workflow construction and execution"</p><p>BMC Bioinformatics 2005;6():69-69.</p><p>Published online 24 Mar 2005</p><p>PMCID:PMC1274263.</p><p>Copyright © 2005 Tang et al; licensee BioMed Central Ltd.</p>ation which allows users to construct workflows using a drawing analogy. Wildfire executes the workflow by exporting it as a GEL script which is executed using a suitable GEL interpretor. There are GEL interpretors for execution on (i) the Grid, using Condor, (ii) a cluster, using LSF, PBS or SGE, and (iii) the same machine, which could be a laptop, desktop or multi-processor server

ImFCS: A software for imaging FCS data analysis and visualization

10.1364/OE.18.025468Optics Express182525468-2548

Moisturisers from birth in at-risk infants of atopic dermatitis – a pragmatic randomised controlled trial

10.1111/ajd.13703Australasian Journal of Dermatology62

An integrated command and control architecture concept for unmanned systems in the year 2030

U.S. Forces require an integrated Command and Control Architecture that enables operations of a dynamic mix of manned and unmanned systems. The level of autonomous behavior correlates to: 1) the amount of trust with the reporting vehicles, and 2) the multi-spectral perspective of the observations. The intent to illuminate the architectural issues for force protection in 2030 was based on a multi-phased analytical model of High Value Unit (HVU) defense. The results showed that autonomous unmanned aerial vehicles are required to defeat high-speed incoming missiles. To evaluate the level of autonomous behavior required for an integrated combat architecture, geometric distributions were modeled to determine force positioning, based on a scenario driven Detect-to-Engage timeline. Discrete event simulation was used to schedule operations, and a datalink budget assessment of communications to determine the critical failure paths in the the integrated combat architecture. The command and control principles used in the integrated combat architecture were based on Boyd's OODA (Obseve, Orient, Decide, and Act) Loop. A conservative fleet size estimate, given the uncertainties of the coverage overlap and radar detection range, a fleet size of 35 should be anticipated given an UAV detection range of 20km and radar coverage overlap of 4 seconds.http://archive.org/details/anintegratedcomm109455244US Navy (USN) authorsApproved for public release; distribution is unlimited