More Like this

1. Investigation and Design of a Towable Hydrophone Array for General Ocean Sensing

   https://doi.org/10.1109/OCEANSE.2019.8867239  

   Schinault, Matthew E. ; Penna, Seth M. ; Garcia, Heriberto A. ; Ratilal, Purnima ( June 2019 , IEEE OCEANS 2019 - Marseille)

   An eight-element oil-filled hydrophone array is used to measure the acoustic field in littoral waters. This prototype array was deployed during an experiment between Jeffrey’s Ledge and the Stellwagen Bank region off the coast of Rockport, Massachusetts USA. During the experiment, several humpback whale vocalizations, distant ship tonals and high frequency conventional echosounder pings were recorded. Visual confirmation of humpback moving in bearing relative to the array verifies the directional sensing from array beamforming. During deployment, the array is towed at speeds varying from 4-7 kts in water depths of roughly 100 m with conditions at sea state 2 to 3. This array system consists of a portable winch with array, tow cable and 3 water-resistant boxes housing electronics. This system is deployed and operated by 2 crew members onboard a 13 m commercial fishing vessel during the experiment. Non-acoustic sensor (NAS) information is obtained to provide depth, temperature, and heading data using commercial off the shelf (COTS) components utilizing RS485/232 data communications. Acoustic data sampling was performed at 8 kHz, 30 kHz and 100 kHz with near real-time processing of data and enhanced Signal to Noise Ratio (SNR) from beamforming. The electrical system components are deployed with 3 stacked electronics boxes housing power, data acquisition and data processing components in water resistant compartments. A laptop computer with 8 TB of external storage and an independent Global Positioning System (GPS) antenna is used to run Passive Ocean Acoustic Waveguide Remote Sensing (POAWRS) software providing beamformed spectrogram data and live NAS data with capability of capturing several days of data. The acquisition system consists of Surface Mount Device (SMD) pre-amplifiers with filter to an analog differential pair shipboard COTS acquisition system. Pre-amplifiers are constructed using SMD technology where components are pressure tolerant and potting is not necessary. Potting of connectors, electronics and hydrophones via 3D printed molding techniques will be discussed. Array internal components are manufactured with Thermoplastic Polyurethane (TPU) 3D printed material to dampen array vibrations with forward and aft vibration isolation modules (VIM). Polyurethane foam (PUF) used to scatter breathing waves and dampen contact from wires inside the array without attenuating high frequencies and allowing for significant noise reduction. A single Tygon array section with a length of 7.5 m and diameter of 38 mm contains 8 transducer elements with a spacing of 75 cm (1 kHz design frequency). Pre- amplifiers and NAS modules are affixed using Vectran and steel wire rope positioned by swaged stops along the strength member. The tow cable length is 100 m with a diameter of 22 mm that is potted to a hose adapter to break out 12 braided copper wire twisted pair conductors and terminates the tow cable Vectran braid. This array in its current state of development is a low-cost alternative to obtain quality acoustic data from a towed array system. Used here for observation of whale vocalizations, this type of array also has many applications in military sonar and seismic surveying. Maintenance on the array can be performed without the use of special facilities or equipment for dehosing and conveniently uses castor oil as an environmentally safe pressure compensating and coupling fluid. Array development including selection of transducers, NAS modules, acoustic acquisition system, array materials and method of construction with results from several deployments will be discussed. We also present beamformed spectrograms containing humpback whale downsweep moans and underwater blowing (bubbles) sounds associated with feeding on sand lance (Ammodytes dubius). 

   more » « less
2. D-Egg: a dual PMT optical module for IceCube

   https://doi.org/10.1088/1748-0221/18/04/P04014  

   Abbasi, R. ; Ackermann, M. ; Adams, J. ; Aggarwal, N. ; Aguilar, J.A. ; Ahlers, M. ; Alameddine, J.M. ; Alves, A.A. ; Amin, N.M. ; Andeen, K. ; et al ( April 2023 , Journal of Instrumentation)

   Abstract The D-Egg, an acronym for “Dual optical sensors in an Ellipsoid Glass for Gen2,” is one of the optical modules designed for future extensions of the IceCube experiment at the South Pole. The D-Egg has an elongated-sphere shape to maximize the photon-sensitive effective area while maintaining a narrow diameter to reduce the cost and the time needed for drilling of the deployment holes in the glacial ice for the optical modules at depths up to 2700 m. The D-Egg design is utilized for the IceCube Upgrade, the next stage of the IceCube project also known as IceCube-Gen2 Phase 1, where nearly half of the optical sensors to be deployed are D-Eggs. With two 8-inch high-quantum efficiency photomultiplier tubes (PMTs) per module, D-Eggs offer an increased effective area while retaining the successful design of the IceCube digital optical module (DOM). The convolution of the wavelength-dependent effective area and the Cherenkov emission spectrum provides an effective photodetection sensitivity that is 2.8 times larger than that of IceCube DOMs. The signal of each of the two PMTs is digitized using ultra-low-power 14-bit analog-to-digital converters with a sampling frequency of 240 MSPS, enabling a flexible event triggering, as well as seamless and lossless event recording of single-photon signals to multi-photons exceeding 200 photoelectrons within 10 ns. Mass production of D-Eggs has been completed, with 277 out of the 310 D-Eggs produced to be used in the IceCube Upgrade. In this paper, we report the design of the D-Eggs, as well as the sensitivity and the single to multi-photon detection performance of mass-produced D-Eggs measured in a laboratory using the built-in data acquisition system in each D-Egg optical sensor module. 

   more » « less
3. Fitting parameter estimations for droplet breakage rate models

   https://doi.org/10.1063/5.0173987  

   Ravichandar, Krishnamurthy ; Vigil, R. Dennis ; Olsen, Michael G. ( January 2024 , Physics of Fluids)

   Chemical process engineering unit operations such as solvent extraction, liquid–liquid chemical reactions, and emulsion processing are all dependent on turbulent liquid–liquid droplet flow dynamics. The design and operation of equipment used in these applications is often guided by theoretical models for droplet breakup. Although several models for droplet breakage in agitated liquid emulsions have been developed, their utility is limited because they incorporate fitting factors that must be determined empirically by performing experiments using a specific fluid pairing and relevant flow configuration. The need to acquire experimental data to determine model constants is a significant drawback that hinders widespread use of breakage models to design and optimize process equipment. In this work, analytical expressions are formulated to predict the value of a fitting parameter associated with droplet breakage time for two commonly used breakage rate models without having to perform empirical studies. These equations were derived by using the underlying assumptions within each of the two breakage models considered, namely, that droplet breakage is a result of the competition between relevant deformation and restorative stresses. Data from experiments conducted in a homogeneous turbulent von Kármán box as well as from previously published investigations of droplet breakage in heterogeneous flow devices were utilized to validate the derived equations for the breakage time parameters. In general, good agreement was observed between predictions obtained using the derived equations for fitting parameters and those obtained from experiments.

    

   more » « less
4. Simulation Data for Design of Peptides that Fold and Self-Assemble on Graphite

   https://doi.org/10.5281/zenodo.6426152  

   Comer, Jeffrey ; Thakkar, Ravindra ; Velásquez-Silva, Astrid ; Miranda-Carvajal, Ingrid ( January 2022 , Zenodo)

   This data set for the manuscript entitled "Design of Peptides that Fold and Self-Assemble on Graphite" includes all files needed to run and analyze the simulations described in the this manuscript in the molecular dynamics software NAMD, as well as the output of the simulations. The files are organized into directories corresponding to the figures of the main text and supporting information. They include molecular model structure files (NAMD psf or Amber prmtop format), force field parameter files (in CHARMM format), initial atomic coordinates (pdb format), NAMD configuration files, Colvars configuration files, NAMD log files, and NAMD output including restart files (in binary NAMD format) and trajectories in dcd format (downsampled to 10 ns per frame). Analysis is controlled by shell scripts (Bash-compatible) that call VMD Tcl scripts or python scripts. These scripts and their output are also included.

   Version: 2.0

   Changes versus version 1.0 are the addition of the free energy of folding, adsorption, and pairing calculations (Sim_Figure-7) and shifting of the figure numbers to accommodate this addition.

   
   Conventions Used in These Files
   ===============================

   Structure Files
   ----------------
   - graph_*.psf or sol_*.psf (original NAMD (XPLOR?) format psf file including atom details (type, charge, mass), as well as definitions of bonds, angles, dihedrals, and impropers for each dipeptide.)

   - graph_*.pdb or sol_*.pdb (initial coordinates before equilibration)
   - repart_*.psf (same as the above psf files, but the masses of non-water hydrogen atoms have been repartitioned by VMD script repartitionMass.tcl)
   - freeTop_*.pdb (same as the above pdb files, but the carbons of the lower graphene layer have been placed at a single z value and marked for restraints in NAMD)
   - amber_*.prmtop (combined topology and parameter files for Amber force field simulations)
   - repart_amber_*.prmtop (same as the above prmtop files, but the masses of non-water hydrogen atoms have been repartitioned by ParmEd)

   Force Field Parameters
   ----------------------
   CHARMM format parameter files:
   - par_all36m_prot.prm (CHARMM36m FF for proteins)
   - par_all36_cgenff_no_nbfix.prm (CGenFF v4.4 for graphene) The NBFIX parameters are commented out since they are only needed for aromatic halogens and we use only the CG2R61 type for graphene.
   - toppar_water_ions_prot_cgenff.str (CHARMM water and ions with NBFIX parameters needed for protein and CGenFF included and others commented out)

   Template NAMD Configuration Files
   ---------------------------------
   These contain the most commonly used simulation parameters. They are called by the other NAMD configuration files (which are in the namd/ subdirectory):
   - template_min.namd (minimization)
   - template_eq.namd (NPT equilibration with lower graphene fixed)
   - template_abf.namd (for adaptive biasing force)

   Minimization
   -------------
   - namd/min_*.0.namd

   Equilibration
   -------------
   - namd/eq_*.0.namd

   Adaptive biasing force calculations
   -----------------------------------
   - namd/eabfZRest7_graph_chp1404.0.namd
   - namd/eabfZRest7_graph_chp1404.1.namd (continuation of eabfZRest7_graph_chp1404.0.namd)

   Log Files
   ---------
   For each NAMD configuration file given in the last two sections, there is a log file with the same prefix, which gives the text output of NAMD. For instance, the output of namd/eabfZRest7_graph_chp1404.0.namd is eabfZRest7_graph_chp1404.0.log.

   Simulation Output
   -----------------
   The simulation output files (which match the names of the NAMD configuration files) are in the output/ directory. Files with the extensions .coor, .vel, and .xsc are coordinates in NAMD binary format, velocities in NAMD binary format, and extended system information (including cell size) in text format. Files with the extension .dcd give the trajectory of the atomic coorinates over time (and also include system cell information). Due to storage limitations, large DCD files have been omitted or replaced with new DCD files having the prefix stride50_ including only every 50 frames. The time between frames in these files is 50 * 50000 steps/frame * 4 fs/step = 10 ns. The system cell trajectory is also included for the NPT runs are output/eq_*.xst.

   Scripts
   -------
   Files with the .sh extension can be found throughout. These usually provide the highest level control for submission of simulations and analysis. Look to these as a guide to what is happening. If there are scripts with step1_*.sh and step2_*.sh, they are intended to be run in order, with step1_*.sh first.

   
   CONTENTS
   ========

   The directory contents are as follows. The directories Sim_Figure-1 and Sim_Figure-8 include README.txt files that describe the files and naming conventions used throughout this data set.

   Sim_Figure-1: Simulations of N-acetylated C-amidated amino acids (Ac-X-NHMe) at the graphite–water interface.

   Sim_Figure-2: Simulations of different peptide designs (including acyclic, disulfide cyclized, and N-to-C cyclized) at the graphite–water interface.

   Sim_Figure-3: MM-GBSA calculations of different peptide sequences for a folded conformation and 5 misfolded/unfolded conformations.

   Sim_Figure-4: Simulation of four peptide molecules with the sequence cyc(GTGSGTG-GPGG-GCGTGTG-SGPG) at the graphite–water interface at 370 K.

   Sim_Figure-5: Simulation of four peptide molecules with the sequence cyc(GTGSGTG-GPGG-GCGTGTG-SGPG) at the graphite–water interface at 295 K.

   Sim_Figure-5_replica: Temperature replica exchange molecular dynamics simulations for the peptide cyc(GTGSGTG-GPGG-GCGTGTG-SGPG) with 20 replicas for temperatures from 295 to 454 K.

   Sim_Figure-6: Simulation of the peptide molecule cyc(GTGSGTG-GPGG-GCGTGTG-SGPG) in free solution (no graphite).

   Sim_Figure-7: Free energy calculations for folding, adsorption, and pairing for the peptide CHP1404 (sequence: cyc(GTGSGTG-GPGG-GCGTGTG-SGPG)). For folding, we calculate the PMF as function of RMSD by replica-exchange umbrella sampling (in the subdirectory Folding_CHP1404_Graphene/). We make the same calculation in solution, which required 3 seperate replica-exchange umbrella sampling calculations (in the subdirectory Folding_CHP1404_Solution/). Both PMF of RMSD calculations for the scrambled peptide are in Folding_scram1404/. For adsorption, calculation of the PMF for the orientational restraints and the calculation of the PMF along z (the distance between the graphene sheet and the center of mass of the peptide) are in Adsorption_CHP1404/ and Adsorption_scram1404/. The actual calculation of the free energy is done by a shell script ("doRestraintEnergyError.sh") in the 1_free_energy/ subsubdirectory. Processing of the PMFs must be done first in the 0_pmf/ subsubdirectory. Finally, files for free energy calculations of pair formation for CHP1404 are found in the Pair/ subdirectory.

   Sim_Figure-8: Simulation of four peptide molecules with the sequence cyc(GTGSGTG-GPGG-GCGTGTG-SGPG) where the peptides are far above the graphene–water interface in the initial configuration.

   Sim_Figure-9: Two replicates of a simulation of nine peptide molecules with the sequence cyc(GTGSGTG-GPGG-GCGTGTG-SGPG) at the graphite–water interface at 370 K.

   Sim_Figure-9_scrambled: Two replicates of a simulation of nine peptide molecules with the control sequence cyc(GGTPTTGGGGGGSGGPSGTGGC) at the graphite–water interface at 370 K.

   Sim_Figure-10: Adaptive biasing for calculation of the free energy of the folded peptide as a function of the angle between its long axis and the zigzag directions of the underlying graphene sheet.

    

   This material is based upon work supported by the US National Science Foundation under grant no. DMR-1945589. A majority of the computing for this project was performed on the Beocat Research Cluster at Kansas State University, which is funded in part by NSF grants CHE-1726332, CNS-1006860, EPS-1006860, and EPS-0919443. This work used the Extreme Science and Engineering Discovery Environment (XSEDE), which is supported by National Science Foundation grant number ACI-1548562, through allocation BIO200030. 

   more » « less
5. The Deep Learning Epilepsy Detection Challenge: Design, Implementation, and Test of a New Crowd-Sourced AI Challenge Ecosystem

   Kiral, Isabell ; Roy, Subhrajit ; Mummert, Todd ; Braz, Alan ; Tsay, Jason ; Tang, Jianbin ; Asif, Umar ; Schaffter, Thomas ; Mehmet, Eren ; Picone, Joseph ; et al ( April 2019 , Challenges in Machine Learning Competitions for All (CiML))

   null (Ed.)

   The DeepLearningEpilepsyDetectionChallenge: design, implementation, andtestofanewcrowd-sourced AIchallengeecosystem Isabell Kiral*, Subhrajit Roy*, Todd Mummert*, Alan Braz*, Jason Tsay, Jianbin Tang, Umar Asif, Thomas Schaffter, Eren Mehmet, The IBM Epilepsy Consortium◊ , Joseph Picone, Iyad Obeid, Bruno De Assis Marques, Stefan Maetschke, Rania Khalaf†, Michal Rosen-Zvi† , Gustavo Stolovitzky† , Mahtab Mirmomeni† , Stefan Harrer† * These authors contributed equally to this work † Corresponding authors: rkhalaf@us.ibm.com, rosen@il.ibm.com, gustavo@us.ibm.com, mahtabm@au1.ibm.com, sharrer@au.ibm.com ◊ Members of the IBM Epilepsy Consortium are listed in the Acknowledgements section J. Picone and I. Obeid are with Temple University, USA. T. Schaffter is with Sage Bionetworks, USA. E. Mehmet is with the University of Illinois at Urbana-Champaign, USA. All other authors are with IBM Research in USA, Israel and Australia. Introduction This decade has seen an ever-growing number of scientific fields benefitting from the advances in machine learning technology and tooling. More recently, this trend reached the medical domain, with applications reaching from cancer diagnosis [1] to the development of brain-machine-interfaces [2]. While Kaggle has pioneered the crowd-sourcing of machine learning challenges to incentivise data scientists from around the world to advance algorithm and model design, the increasing complexity of problem statements demands of participants to be expert data scientists, deeply knowledgeable in at least one other scientific domain, and competent software engineers with access to large compute resources. People who match this description are few and far between, unfortunately leading to a shrinking pool of possible participants and a loss of experts dedicating their time to solving important problems. Participation is even further restricted in the context of any challenge run on confidential use cases or with sensitive data. Recently, we designed and ran a deep learning challenge to crowd-source the development of an automated labelling system for brain recordings, aiming to advance epilepsy research. A focus of this challenge, run internally in IBM, was the development of a platform that lowers the barrier of entry and therefore mitigates the risk of excluding interested parties from participating. The challenge: enabling wide participation With the goal to run a challenge that mobilises the largest possible pool of participants from IBM (global), we designed a use case around previous work in epileptic seizure prediction [3]. In this “Deep Learning Epilepsy Detection Challenge”, participants were asked to develop an automatic labelling system to reduce the time a clinician would need to diagnose patients with epilepsy. Labelled training and blind validation data for the challenge were generously provided by Temple University Hospital (TUH) [4]. TUH also devised a novel scoring metric for the detection of seizures that was used as basis for algorithm evaluation [5]. In order to provide an experience with a low barrier of entry, we designed a generalisable challenge platform under the following principles: 1. No participant should need to have in-depth knowledge of the specific domain. (i.e. no participant should need to be a neuroscientist or epileptologist.) 2. No participant should need to be an expert data scientist. 3. No participant should need more than basic programming knowledge. (i.e. no participant should need to learn how to process fringe data formats and stream data efficiently.) 4. No participant should need to provide their own computing resources. In addition to the above, our platform should further • guide participants through the entire process from sign-up to model submission, • facilitate collaboration, and • provide instant feedback to the participants through data visualisation and intermediate online leaderboards. The platform The architecture of the platform that was designed and developed is shown in Figure 1. The entire system consists of a number of interacting components. (1) A web portal serves as the entry point to challenge participation, providing challenge information, such as timelines and challenge rules, and scientific background. The portal also facilitated the formation of teams and provided participants with an intermediate leaderboard of submitted results and a final leaderboard at the end of the challenge. (2) IBM Watson Studio [6] is the umbrella term for a number of services offered by IBM. Upon creation of a user account through the web portal, an IBM Watson Studio account was automatically created for each participant that allowed users access to IBM's Data Science Experience (DSX), the analytics engine Watson Machine Learning (WML), and IBM's Cloud Object Storage (COS) [7], all of which will be described in more detail in further sections. (3) The user interface and starter kit were hosted on IBM's Data Science Experience platform (DSX) and formed the main component for designing and testing models during the challenge. DSX allows for real-time collaboration on shared notebooks between team members. A starter kit in the form of a Python notebook, supporting the popular deep learning libraries TensorFLow [8] and PyTorch [9], was provided to all teams to guide them through the challenge process. Upon instantiation, the starter kit loaded necessary python libraries and custom functions for the invisible integration with COS and WML. In dedicated spots in the notebook, participants could write custom pre-processing code, machine learning models, and post-processing algorithms. The starter kit provided instant feedback about participants' custom routines through data visualisations. Using the notebook only, teams were able to run the code on WML, making use of a compute cluster of IBM's resources. The starter kit also enabled submission of the final code to a data storage to which only the challenge team had access. (4) Watson Machine Learning provided access to shared compute resources (GPUs). Code was bundled up automatically in the starter kit and deployed to and run on WML. WML in turn had access to shared storage from which it requested recorded data and to which it stored the participant's code and trained models. (5) IBM's Cloud Object Storage held the data for this challenge. Using the starter kit, participants could investigate their results as well as data samples in order to better design custom algorithms. (6) Utility Functions were loaded into the starter kit at instantiation. This set of functions included code to pre-process data into a more common format, to optimise streaming through the use of the NutsFlow and NutsML libraries [10], and to provide seamless access to the all IBM services used. Not captured in the diagram is the final code evaluation, which was conducted in an automated way as soon as code was submitted though the starter kit, minimising the burden on the challenge organising team. Figure 1: High-level architecture of the challenge platform Measuring success The competitive phase of the "Deep Learning Epilepsy Detection Challenge" ran for 6 months. Twenty-five teams, with a total number of 87 scientists and software engineers from 14 global locations participated. All participants made use of the starter kit we provided and ran algorithms on IBM's infrastructure WML. Seven teams persisted until the end of the challenge and submitted final solutions. The best performing solutions reached seizure detection performances which allow to reduce hundred-fold the time eliptologists need to annotate continuous EEG recordings. Thus, we expect the developed algorithms to aid in the diagnosis of epilepsy by significantly shortening manual labelling time. Detailed results are currently in preparation for publication. Equally important to solving the scientific challenge, however, was to understand whether we managed to encourage participation from non-expert data scientists. Figure 2: Primary occupation as reported by challenge participants Out of the 40 participants for whom we have occupational information, 23 reported Data Science or AI as their main job description, 11 reported being a Software Engineer, and 2 people had expertise in Neuroscience. Figure 2 shows that participants had a variety of specialisations, including some that are in no way related to data science, software engineering, or neuroscience. No participant had deep knowledge and experience in data science, software engineering and neuroscience. Conclusion Given the growing complexity of data science problems and increasing dataset sizes, in order to solve these problems, it is imperative to enable collaboration between people with differences in expertise with a focus on inclusiveness and having a low barrier of entry. We designed, implemented, and tested a challenge platform to address exactly this. Using our platform, we ran a deep-learning challenge for epileptic seizure detection. 87 IBM employees from several business units including but not limited to IBM Research with a variety of skills, including sales and design, participated in this highly technical challenge. 

   more » « less