Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “input”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 379 records · Page 21

Biological mechanisms may contribute to soil carbon saturation patterns

Increasing soil organic carbon (SOC) storage is a key strategy to mitigate rising atmospheric CO 2 , yet SOC pools often appear to saturate, or increase at a declining rate, as carbon (C) inputs increase. Soil C saturation is commonly hypothesized to result from the finite amount of reactive mineral surface area available for retaining SOC, and is accordingly represented in SOC models as a physicochemically determined SOC upper limit. However, mineral-associated SOC is largely microbially generated. In this perspective, we present the hypothesis that apparent SOC saturation patterns could emerge as a result of ecological constraints on microbial biomass—for example, via competition or predation—leading to reduced C flow through microbes and a reduced rate of mineral-associated SOC formation as soil C inputs increase. Microbially explicit SOC models offer an opportunity to explore this hypothesis, yet most of these models predict linear microbial biomass increases with C inputs and insensitivity of SOC to input rates. Synthesis of 54 C addition studies revealed constraints on microbial biomass as C inputs increase. Different hypotheses limiting microbial density were embedded in a three-pool SOC model without explicit limits on mineral surface area. As inputs increased, the model demonstrated either no change, linear, or apparently saturating increases in mineral-associated and particulate SOC pools. Taken together, our results suggest that microbial constraints are common and could lead to reduced mineral-associated SOC formation as input rates increase. We conclude that SOC responses to altered C inputs—or any environmental change—are influenced by the ecological factors that limit microbial populations, allowing for a wider range of potential SOC responses to stimuli. Understanding how biotic versus abiotic factors contribute to these patterns will better enable us to predict and manage soil C dynamics.

54 ENVIRONMENTAL SCIENCES↗

WORM (Write One, Read Many)

WORM (Write One, Run Many) is an easy to use, cross platform, embedded and extensible, functional programming language designed to facilitate the creation of input-decks for computer codes that use standard ASCII text files for input. WORM makes it easy to create generic (yet, complex and powerful) reusable models. Additionally its nature allows for complex calculations and routines to be coded once and easily reused, further simplifying the creation of input decks. WORM (Write One, Run Many) is a powerful and versatile tool designed to improve the efficiency of today’s criticality safety analyst by allowing: + input decks for parametric studies to be created quickly and easily, + calculations and variables to be imbedded into any input deck, thus allowing for meaningful parameter specifications, + problems to be specified using any combination of units, and + complex mathematically defined models to be created. A very simple syntax is employed, and therefore the WORM is easy to learn. A WORM model is essentially a standard input deck with some of its numerical values replaced by WORM code. WORM code may include and evaluate the following mathematical operators and functions: addition, subtraction, multiplication, division, exponentiation, modulus, sine, cosine, tangent, arcsine, arccosine, arctangent, the natural logarithm, logarithm base 10, integer truncation, absolute value, and random number. Several common constants, e.g., pi, e, and Avogadros’s Number (both as 6.022e23 and 0.6022), are predefined in WORM. Additionally, many unit conversion factors are also predefined: millimeters, meters, inches, feet, yards, and mils to centimeters; kilograms, pounds, and ounces to grams; liters, milliliters, gallons, and fluid ounces to cubic centimeters; and angular degrees to radians. For parametric studies, WORM supports various shorthand list specifications: the explicit step size, linear interpolation, and logarithmic interpolation. The list notation sequentially assigns multiple values to a name. WORM creates an input deck for each value of the name. If multiple lists are used, WORM steps through each list individually, i.e., WORM creates input decks corresponding to each and every permutation of the list values. Additionally, a library of standard material definitions and Perl subroutines are included. Any one of these files can be incorporated into the subject model with a simple WORM read command. WORM is completely written in Perl, the Practical Extraction and Reporting Language. Perl is one of the most portable programming languages available today. As such, the WORM works on practically any computer platform.

Sartor, Raymond↗

Final Report On Non-Intrusive Load Monitoring Of Welding Processes

The conventional method of weld process monitoring is to monitor the process output electrical power close to the point of welding. Non-Intrusive Load Monitoring (NILM) describes the method of monitoring primary or utility electrical power into a welding process well away from the point of welding. The objective of this project was to determine if there is sufficient information within the welding process input power to understand process output power characteristics, and, if so, determine if there is sufficient resolution within the input electrical characteristics to infer some measures of weld quality. To understand the relationship between process input and output power, both input and output power were monitored for two welding processes (GMAW and GTAW) and two different power source types (inverter and SCR). Welds were made with and without intentional disturbances. The results showed that there is a strong correlation between input and output power and that the influence of process disturbances are evident within the input power. A simple method using input power only was devised and successfully demonstrated to discriminate between a weld made with no intentional disturbance (a nominal weld) from a weld made with an intentional disturbance (off-nominal weld). The primary conclusions of this work is that NILM of process input power is sensitive to process disturbances that could influence weld quality and that the approach warrants additional study.

36 MATERIALS SCIENCE↗

Uncertainty-informed selection of CMIP6 Earth System Model subsets for use in multisectoral and impact models

Earth system models (ESMs) and general circulation models (GCMs) are heavily used to provide inputs to sectoral impact and multisector dynamic models, which include representations of energy, water, land, economics, and their interactions. Therefore, representing the full range of model uncertainty, scenario uncertainty, and interannual variability that ensembles of these models capture is critical to the exploration of the future co-evolution of the integrated human–Earth system. The pre-eminent source of these ensembles has been the Coupled Model Intercomparison Project (CMIP). With more modeling centers participating in each new CMIP phase, the size of the model archive is rapidly increasing, which can be intractable for impact modelers to effectively utilize due to computational constraints and the challenges of analyzing large datasets. In this work, we present a method to select a subset of the latest phase, CMIP6, featuring models for use as inputs to a sectoral impact or multisector dynamics models, while prioritizing preservation of the range of model uncertainty, scenario uncertainty, and interannual variability in the full CMIP6 ensemble results. This method is intended to help impact modelers select climate information from the CMIP archive efficiently for use in downstream models that require global coverage of climate information. This is particularly critical for large-ensemble experiments of multisector dynamic models that may be varying additional features beyond climate inputs in a factorial design, thus putting constraints on the number of climate simulations that can be used. We focus on temperature and precipitation outputs of CMIP6 models, as these are two of the most used variables among impact models, and many other key input variables for impacts are at least correlated with one or both of temperature and precipitation (e.g., relative humidity). Besides preserving the multi-model ensemble variance characteristics, we prioritize selecting CMIP6 models in the subset that preserve the very likely distribution of equilibrium climate sensitivity values as assessed by the latest Intergovernmental Panel on Climate Change (IPCC) report. This approach could be applied to other output variables of climate models and, possibly when combined with emulators, offers a flexible framework for designing more efficient experiments on human-relevant climate impacts. It can also provide greater insight into the properties of existing CMIP6 models.

Snyder, Abigail C.↗

Power converter circuitry for photovoltaic devices

Power converter circuitry includes a direct current (DC) input comprising a first DC input node and a second DC input node, an alternating current (AC) output comprising a first AC output node coupled to the first DC input node and a second AC output node, a first boost switch coupled between the second DC input node and a boost intermediate node, a second boost switch coupled between the boost intermediate node and a common node, a boost inductor coupled between the boost intermediate node and the first DC input node, a link capacitor coupled between the second DC input node and the common node, a first half-bridge switch coupled between the second DC input node and a half-bridge intermediate node, a second half-bridge switch coupled between the half-bridge intermediate node and the common node, and a half-bridge inductor coupled between the half-bridge intermediate node and the second AC output node.

Ayyanar, Rajapandian↗

Oxy-combustion process with modular boiler design

A modular boiler system for implementing fuel combustion is provided. The system includes a first boiler and a second boiler of a plurality of boilers, an oxygen input unit, a fuel input unit, a recycled flue gas input unit, and a flue gas separator. The first boiler receives oxygen from the oxygen input unit, fuel from the fuel input unit, and recycled flue gas from the recycled flue gas input unit. The first boiler outputs intra-system flue gas. The flue gas separator separates the intra-system flue gas into a first and second flue gas stream, transfers the first flue gas stream to the second boiler, and transfers the second flue gas stream to a gas cleaning system. The second boiler receives oxygen from the oxygen input unit, fuel from the fuel input unit, and the first flue gas stream from the flue gas separator.

Axelbaum, Richard L.↗

System and method for micromechanical logical and gate

The present disclosure relates to a mechanical AND-gate logic system that may make use of a first and second lever arms, a first pivot linkage coupling the lever arms, an output member, and a second pivot linkage coupling the second lever arm to the output member. The first lever arm has first and second spaced apart ends for independently receiving separate logic level 1 or logic level 0 input signals thereon, and an output end spaced apart from the first and second input ends. The output end is disposed generally equidistant from the first and second spaced apart ends. The second lever arm has an input end and an output end and can move in both pivoting and translating movements. The first pivot linkage couples the output end of the first lever arm to the input end of the second lever arm such that both the input end and the output end of the second lever arm are able to either pivot and or to translate. The second lever arm is only able to translate and apply a logic 1 level input signal to the output member, to thus generate a logic 1 level output signal, when a logic level 1 input signal is applied simultaneously to both of the first and second input ends of the first lever arm.

Panas, Robert Matthew↗

Using a Genetic Algorithm to Optimize Configurations in a Data-Driven Application

Users of highly-configurable software systems often want to optimize a particular objective such as improving a functional outcome or increasing system performance. One approach is to use an evolutionary algorithm. However, many applications today are data-driven, meaning they depend on inputs or data which can be complex and varied. Hence, a search needs to be run (and re-run) for all inputs, making optimization a heavy-weight and potentially impractical process. In this paper, we explore this issue on a data-driven highly-configurable scientific application. We build an exhaustive database containing 3,000 configurations and 10,000 inputs, leading to almost 100 million records as our oracle, and then run a genetic algorithm individually on each of the 10,000 inputs. We ask if (1) a genetic algorithm can find configurations to improve functional objectives; (2) whether patterns of best configurations over all input data emerge; and (3) if we can we use sampling to approximate the results. We find that the original (default) configuration is best only 34% of the time, while clear patterns emerge of other best configurations. Out of 3,000 possible configurations, only 112 distinct configurations achieve the optimal result at least once across all 10,000 inputs, suggesting the potential for lighter weight optimization approaches. We show that sampling of the input data finds similar patterns at a lower cost.

Sinha, Urjoshi↗

Chemical and isotopic evolution of flowback fluids from the Utica Gas Shale Play, Eastern Ohio USA

For this work, hydraulic fracturing flowback fluids were collected from two Utica/Point Pleasant well pads in eastern Ohio. One site was in the wet gas zone (UPPW), while the site ~50 km south consisted of four wells on the same pad in the dry gas zone (UPPS). Samples of input fluids also were collected before and during hydraulic fracturing. Flowback fluids are Na-Ca-Cl brines with total dissolved salt (TDS) concentrations that increase over several months from ~100 to 200 g/L. The slightly higher TDS of the dry gas fluids are in part due to recycled flowback used as input fluids, and in part due to lower volume of water used in hydraulic fracturing. Concentrations of most major ions (Ca 2+ , Mg 2+ , Na + , Sr2 + , Fe, Mn, Cl – , Br – ) are similar for the five wells sampled, although small but systematic changes occur in the major element ratios over time. Most notably, an increase in the Sr/Cl ratio corresponds to an increase in the 87 Sr/ 86 Sr ratio in the fluids, suggesting interactions with a more radiogenic Sr source in the subsurface. Dissolved Ba concentrations and Ra activities were different between the two sites, reflecting a high SO 4 2– fluid used at the UPPW site, and water-rock reactions occurring during hydraulic fracturing at the UPPS site. Water oxygen (δ 18 O) and hydrogen (δD) isotopes for input fluids used in the UPPW4 well and fresh water used for the UPPS wells fall on the Global Meteoric waterline (GMWL). Flowback fluids from both sites are relatively enriched in δ 18 O and δD compared to the input, but do not appear to follow a simple mixing trend, suggesting reaction and isotopic exchange with carbonates and fractionation due to imbibition in the rock. Cl isotopes, δ 37 Cl in the FP fluids varied from ~ –0.43 to +0.13‰, the largest variation was observed in the earlier stages of flowback, while in the later stages δ 37 Cl exhibited a small but systematic increase over time, suggesting diffusion control of isotopic composition. Some of the trace species measured (dissolved Fe, Mn, thiosulfate and organic acids) do not follow the same trends as the major ions, suggesting contributions from input fluids, or microbially mediated reactions are exerting control on their concentrations. Input water chemistry exerts an important control on the Sr and Ba concentrations in flowback water. High SO 4 2– in the input fluids used for hydraulically fracturing the wet gas well leads to precipitation of barite-celestite in flowback fluids.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

A resolution independent neural operator

The Deep operator network (DeepONet) is a powerful yet simple neural operator architecture that utilizes two deep neural networks to learn mappings between infinite-dimensional function spaces. This architecture is highly flexible, allowing the evaluation of the solution field at any location within the desired domain. However, it imposes a strict constraint on the input space, requiring all input functions to be discretized at the same locations; this limits its practical applications. Here, in this work, we introduce a general framework for operator learning from input–output data with arbitrary number and locations of sensors. This begins by introducing a resolution-independent DeepONet (RI-DeepONet), enabling it to handle input functions that are arbitrarily, but sufficiently finely, discretized. To this end, we propose two dictionary learning algorithms to adaptively learn a set of appropriate continuous basis functions, parameterized as implicit neural representations (INRs), from correlated signals defined on arbitrary point cloud data. These basis functions are then used to project arbitrary input function data as a point cloud onto an embedding space (i.e., a vector space of finite dimensions) with dimensionality equal to the dictionary size, which can be directly used by DeepONet without any architectural changes. In particular, we utilize sinusoidal representation networks (SIRENs) as trainable INR basis functions. The introduced dictionary learning algorithms are then used in a similar way to learn an appropriate dictionary of basis functions for the output function data, which defines a new neural operator architecture referred to as the R esolution I ndependent N eural O perator (RINO). In the RINO, the operator learning task simplifies to learning a mapping from the coefficients of input basis functions to the coefficients of output basis functions. We demonstrate the robustness and applicability of RINO in handling arbitrarily (but sufficiently richly) sampled input and output functions during both training and inference through several numerical examples.

Deep operator network (DeepONet)↗

Kernel-based global sensitivity analysis obtained from a single data set

Results from global sensitivity analysis (GSA) often guide the understanding of complicated input–output systems. Kernel-based GSA methods have recently been proposed for their capability of treating a broad scope of complex systems. In this paper, we develop a new set of kernel GSA tools when only a single set of input–output data is available. Three key advances are made: (1) A new numerical estimator is proposed that demonstrates an empirical improvement over previous procedures. (2) A computational method for generating inner statistical functions from a single data set is presented. (3) A theoretical extension is made to define conditional sensitivity indices, which reveal the degree that the inputs carry shared information about the output when inherent input–input correlations are present. Utilizing these conditional sensitivity indices, a decomposition is derived for the output uncertainty based on what is called the optimal learning sequence of the input variables, which remains consistent when correlations exist between the input variables. Further, while these advances cover a range of GSA subjects, a common single data set numerical solution is provided by a technique known as the conditional mean embedding of distributions. The new methodology is implemented on benchmark systems to demonstrate the provided insights.

42 ENGINEERING↗

SymbolNet: neural symbolic regression with adaptive dynamic pruning for compression

Abstract Compact symbolic expressions have been shown to be more efficient than neural network (NN) models in terms of resource consumption and inference speed when implemented on custom hardware such as field-programmable gate arrays (FPGAs), while maintaining comparable accuracy (Tsoi et al 2024 EPJ Web Conf. 295 09036). These capabilities are highly valuable in environments with stringent computational resource constraints, such as high-energy physics experiments at the CERN Large Hadron Collider. However, finding compact expressions for high-dimensional datasets remains challenging due to the inherent limitations of genetic programming (GP), the search algorithm of most symbolic regression (SR) methods. Contrary to GP, the NN approach to SR offers scalability to high-dimensional inputs and leverages gradient methods for faster equation searching. Common ways of constraining expression complexity often involve multistage pruning with fine-tuning, which can result in significant performance loss. In this work, we propose S y m b o l N e t , a NN approach to SR specifically designed as a model compression technique, aimed at enabling low-latency inference for high-dimensional inputs on custom hardware such as FPGAs. This framework allows dynamic pruning of model weights, input features, and mathematical operators in a single training process, where both training loss and expression complexity are optimized simultaneously. We introduce a sparsity regularization term for each pruning type, which can adaptively adjust its strength, leading to convergence at a target sparsity ratio. Unlike most existing SR methods that struggle with datasets containing more than O ( 10 ) inputs, we demonstrate the effectiveness of our model on the LHC jet tagging task (16 inputs), MNIST (784 inputs), and SVHN (3072 inputs).

Tsoi, Ho Fung (ORCID:0000000225502184)↗

Computer Model Calibration with Time Series Data Using Deep Learning and Quantile Regression

Computer models play a key role in many scientific and engineering problems. One major source of uncertainty in computer model experiments is input parameter uncertainty. Computer model calibration is a formal statistical procedure to infer input parameters by combining information from model runs and observational data. The existing standard calibration framework suffers from inferential issues when the model output and observational data are high-dimensional dependent data, such as large time series, due to the difficulty in building an emulator and the nonidentifiability between effects from input parameters and data-model discrepancy. To overcome these challenges, we, in this work, propose a new calibration framework based on a deep neural network (DNN) with long short-term memory layers that directly emulates the inverse relationship between the model output and input parameters. Adopting the “learning with noise” idea, we train our DNN model to filter out the effects from data-model discrepancy on input parameter inference. We also formulate a new way to construct interval predictions for DNN using quantile regression to quantify the uncertainty in input parameter estimates. Through a simulation study and real data application with the Weather Research and Forecasting Model Hydrological modeling system (WRF-Hydro), we show our approach can yield accurate point estimates and well-calibrated interval estimates for input parameters.

97 MATHEMATICS AND COMPUTING↗

VERAIO Software Management Plan

VERAIO is a set of utility codes used to provide a common set of input and outputs to the Virtual Environment for Reactor Applications (VERA). VERA is a collection of several different computer codes that all have a common input and output. This prevents the need to manage input and output from each individual code, allowing for ease of use and reducing errors associated with code operability. The VERAIO utilities include VERAIn, VERAView, and VERARun. Each of these utilities is described below. VERAIn is an input processor that reads an ASCII input file generated by users, parses the file, performs some error checking, and writes an XML file to be read by other VERA codes. The main purpose of VERAIn is to provide a common input to all of the VERA codes so users only need to learn one input. VERAIn is written in Perl and uses YAML configuration files to provide flexibility. VERAView is a graphical user interface (GUI) that reads a VERA HDF output file and allows users to visualize results. VERAView is written in Python. VERARun is a script that drives the VERA execution in a high performance computing (HPC) environment. Work performed at the code level supports the Quality Assurance Program Plan (QAPP) (VERA-QA-001), and VERA Software Quality Assurance Plan (VERA-QA-002).

97 MATHEMATICS AND COMPUTING↗

VERAIO Software Management Plan

VERAIO is a set of utility codes used to provide a common set of inputs and outputs to the Virtual Environment for Reactor Applications (VERA). VERA is a collection of several different computer codes that all have a common input and output. This prevents the need to manage input and output from each individual code, allowing for ease of use and reducing errors associated with code operability. The VERAIO utilities include VERAIn, VERAView, and VERARun. Each of these utilities is described below. VERAIn is an input processor that reads an ASCII input file generated by users, parses the file, performs some error checking, and writes an XML file to be read by other VERA codes. The main purpose of VERAIn is to provide a common input to all of the VERA codes, so users only need to learn one input. VERAIn is written in Perl and uses YAML configuration files to provide flexibility. VERAView is a graphical user interface (GUI) that reads a VERA hierarchical data format (HDF) output file and allows users to visualize results. VERAView is written in Python. VERARun is a script that drives the VERA execution in a high performance computing (HPC) environment. Work performed at the code level supports the quality assurance program plan (QAPP) (VERA-QA-001) and the VERA Software Quality Assurance Plan (VERA-QA-002).

97 MATHEMATICS AND COMPUTING↗

FUN-BioCROP model with litter decomposition parameters derived from the LIDET dataset

This repository contains the code and data necessary to run the FUN-BioCROP (Fixation and Uptake of Nitrogen-Bioenergy Carbon, Rhizosphere, Organisms, and Protection) model with litter decomposition parameters derived from a modified Monte Carlo simulation that used the Long-term Intersite Decomposition Experiment Team dataset. Related publication:Juice, S.M., Ridgeway, J.R., Hartman, M.D., Parton, W.J., Berardi, D.M., Sulman, B.N., Allen, K.E., & Brzostek, E.R. Reparameterizing litter decomposition using a simplified Monte Carlo method improves litter decay simulated by a microbial model and alters bioenergy soil carbon estimates. Description of Files: FUNBioCROP_LIDET Study.Rmd R code with FUN-BioCROP model that can be run with 10 different sets of parameters for litter decomposition (Baseline, LIDET, or eight other best parameter sets identified in the modified Monte Carlo simulation. CORPSE Functions_Bioenergy_V2.R Code with CORPSE model functions, called by FUNBioCROP_LIDET Study.Rmd Model Input Data: bulk.csv, bulk_till.csv, rhizo.csv, rhizo_till.csv, litter.csv Initial C and N (kg C or N/m2) pool values for each soil compartment, final values from spin up. All five files have the same columns: (Column - Description - Units) uFastC - Unprotected fast decomposing carbon - kg carbon/m2 uSlowC - Unprotected slow decomposing carbon - kg carbon/m2 uNecroC - Unprotected necromass carbon - kg carbon/m2 pFastC - Protected fast decomposing carbon - kg carbon/m2 pSlowC - Protected slow decomposing carbon - kg carbon/m2 pNecroC - Protected necromass carbon - kg carbon/m2 livingMicrobeC - Carbon in living microbial biomass - kg carbon/m2 uFastN - Unprotected fast decomposing nitrogen - kg nitrogen/m2 uSlowN - Unprotected slow decomposing nitrogen - kg nitrogen/m2 uNecroN - Unprotected necromass nitrogen - kg nitrogen/m2 pFastN - Protected fast decomposing nitrogen - kg nitrogen/m2 pSlowN - Protected slow decomposing nitrogen - kg nitrogen/m2 pNecroN - Protected necromass nitrogen - kg nitrogen/m2 inorganicN - Inorganic nitrogen - kg nitrogen/m2 CO2 - Carbon in carbon dioxide - kg carbon/m2 livingMicrobeN - Nitrogen in living microbial biomass - kg nitrogen/m2 Model Input Data: FluxTower_AvgSoilT.csv: Average daily soil temperature (oC) at 10 cm depth at University of Illinois Urbana-Champaign (UIUC) Energy Farm flux tower from 7/2008-3/2016. (One year of averaged data) Model Input Data: FluxTower_AvgSoilVWC.csv: Average daily soil volumetric water content (VWC) at 10 cm depth at UIUC Energy Farm flux tower from 7/2008-3/2016. (One year of averaged data) Model Input Data: input_CCS_LIDET Study.csv: This file has daily data to run FUN-BioCROP (Column - Description - Units): yr - calendar year - year doy - day of year (1 to 365) (no leap year) - day anpp - aboveground NPP (DayCent) - kg C/m2/day bnpp - belowground NPP (DayCent) - kg C/m2/day aglivc - live aboveground biomass carbon (DayCent) - kg C/m2 bglivcj - live juvenile fine root biomass carbon (DayCent) - kg C/m2 bglivcm - live mature fine root biomass carbon (DayCent) - kg C/m2 aglivn - live aboveground biomass nitrogen (DayCent) - kg N/m2 bglivnj - live juvenile fine root biomass nitrogen (DayCent) - kg N/m2 bglivnm - live mature fine root biomass nitrogen (DayCent) - kg N/m2 nyr - simulation year - year cult - indicates a cultivation event (0 or 1) crop - indicates a new crop (0 or 1) fert - indicates a fertilizer event (0 or 1) frst - indicates the first day of the growing season (0 or 1) harv - indicates a harvest event (0 or 1) last - indicates the end of the growing season (0 or 1) croptype - crop type (0=none; 1=alfalfa; 2=corn; 3=grass clover pasture; 4=soybean; 5=wheat) cropsrl - crop specific root length - mm/g root cultrhizmix - fraction of rhizosphere mixed with bulk soil during cultivation (0.0-1.0) - fraction cultlitmix - fraction of litter mixed with bulk soil during cultivation (0.0-1.0) - fraction harvremov - fraction of above ground biomass removed during harvest (0.0-1.0) - fraction fertamt - fertilization amount - g N/m2 lifehist - plant life history (0 = annual, 1 = perennial) froot_turnover_c - amount of C in fine root turnover - kg C/m2 froot_turnover_n - amount of N in fine root turnover - kg N/m2 agrd_turnover_c - amount of C in aboveground biomass turnover - kg C/m2 agrd_turnover_n - amount of N in aboveground biomass turnover - kg N/m2 leaf_litter_fastfrac - Fast decomposing fraction of leaf litter (0.0-1.0) - fraction root_litter_fastfrac - Fast decomposing fraction of root litter (0.0-1.0) - fraction root_diameter - root diameter - mm root_length - root length - mm root/m2 rhizo_frac - fraction of total soil volume that is rhizosphere (0.0 - 1.0) - fraction date - date in format YYYY-MM-DD Instructions: Save the model code ("FUN-BioCROP_LIDET Study.Rmd") and accompanything files (data streams and CORPSE function code) in the same folder. In model code "Chunk 3: Load CORPSE Data Streams" set the working directory (setwd) to the folder with the files saved in step #1. In "Chunk 5: Define LIDET parameter sets" select the litter decomposition parameter set to be used in the run, and comment out all other sets. If changing any parameter values, edit them in "Chunk 6: Load parameters." Run all chunks up to and including "Chunk 10: Prepare Data for Export." In "Chunk 11: Export Output Data" edit data frames for export and filenames, as necessary. "Chunk 12: Graph Total Soil C" makes a figure of C remaining over the model run period. Description of each model chunk (in file FUN-BioCROP_LIDET Study.Rmd): Chunk 1: Remove all functions, clear memory. Removes all functions from R environment, clears the memory. Chunk 2: Load Packages. Loads packages necessary to run the code. Chunk 3: Load CORPSE Data Streams. Sets the working directory and loads the data files necessary to run CORPSE. Chunk 4: Load CORPSE Functions. Loads the R script with CORPSE functions from the working directory, "CORPSE Functions_Bioenergy_V2.R". Chunk 5: Define LIDET parameter sets. Has ten different parameter sets for litter decomposition tested in this study: Baseline parameters, LIDET parameters, and the other 8 best performing parameter sets identified in the modified Monte Carlo. To run the model, all but one parameter set must be commented out. Chunk 6: Load Parameters. Loads all fixed parameters to run the model. Data frame with definitions of parameters is in the CORPSE function script "CORPSE Functions_Bioenergy_V2.R" Chunk 7: Prepare Data Streams. Takes data streams loaded in Chunk 3 and puts them in the format necessary to run the model. The model is coded to run at least two sites at a time, so if only one site is being run it must be run in duplicate. Individual data tables of daily values are created in this chunk from the input data file. Chunk 8: Set Initial Conditions. Creates data tables of soil C and N pools for each soil compartment (rhizo_till, rhizo, bulk_till, bulk, litter) and loads initial values into the data tables. Creates lists for each soil compartment to hold model output. Chunk 9: Load FUN Data and Set Up Matrices. Uses DayCent data to calculate FUN input data: root and leaf N demand, total N demand, plant CN, leaf N available for retranslocation, and litter production. Creates matrices for FUN model outputs. Chunk 10: Run Model. Runs the model. Chunk 11: Prepare Data for Export. Combines data from each day saved as lists into data frames for each soil compartment. Adds values from all soil compartments together to calculate total soil values, creates separate data frames for each soil C and N pool (e.g., protected slow C) for the total soil value. Adds different C and N pools together to calculate total soil C and N for all layers. Creates data frame of ratio of protected to unprotected SOC. Organizes FUN data for export. Chunk 12: Export Results. Exports CSV files of model results to the working directory. Chunk 13: Graph Total Soil C. Makes figure of C remaining over time. Related Links: Original FUN-BioCROP model: https://github.com/BrzostekEcologyLab/FUN-BioCROP LIDET dataset: https://andlter.forestry.oregonstate.edu/data/abstract.aspx?dbcode=TD023

Juice, Stephanie↗

Urban morphology and urban water demand evolution in the Los Angeles region

Detailed description of the dataset sources used in this study, the experimental workflow, and plotting for the paper figures provided at the associated GitHub Meta Repo: https://github.com/IMMM-SFA/Ferencz_et_al_2024_ERL The future water demand projections from this study are hypothetical future water demands that reflect the population and urban land cover changes represented by the scenarios considered. The intent and emphasis of this work is investigating the interactions between population change, evolution of urban morphology, and water demand. These projections are not meant to be likely future demands for specific water providers or the LA region and should not be interpreted as such. The folders contain input and output data for each step of the "Recreate my Experiment" workflow described in the associated GitHub meta-repository as well as data used for plotting Figures for the paper that this dataset supports. Description of each folder's contents and use: Step_1a: Inputs to the associated python script provided on the GitHub repo. Step_1b: Inputs (downscaled population rasters) used by the associated python script provided on the GitHub repo. Original 1-km squared rasters that were downscaled also provided. Step_1c: Urban growth projection rasters corresponding to SSP3 and SSP5 population scenarios are provided in separate subfolders as well as the water provider boundaries used for analysis. Outputs of data processing also provided. Associated python script provided on GitHub. Step_1d: Description of Inputs used by the QGIS Model Builder GUI that automates geospatial processing and clipping the of the high-resolution 60 cm land cover data for each urban land class footprint within a defined polygon boundary. The Model Builder is provided on the GitHub repo and can be used by QGIS. The outputs of this step are in "Clipped Provider Hi Res Landcover". If the user wants to use The Model Builder for different regions of LA or to test our outputs, they will need to download the hi resolution landcover raster listed in the Readme and in Ref [2] of the GitHub Page. Step_1e: All necessary inputs to generate average monthly demand over the 2017-2021 period and the minimum and maximum demands over the 2014-2021 for each water provider. Associated python scripts are on GitHub. Step 2: Output data about land cover metrics (areas and fractions) for each urban land class for each water provider. Associated python script on GitHub. Uses outputs from Step 1d "Clipped Provider Hi Res Landcover" Step 3: Both the Inputs for and Outputs from the urban projection raster analysis Python script on GitHub. The inputs are urban land class rasters for specific SSP and zoning scenarios (low, medium, high) from Step 1c. The outputs are rasters of urban pixels that were converted to a higher land class and the number of land class units that changed (Values of 1, 2, or 3). For example, a value of 2 could be LC 21 -> 23 or LC 22 -> 24. These maps are label "intensification." The other outputs are "urban growth" rasters showing the conversion of non urban to urban land, which are indicated by pixel values of 1. These are used for the urban growth change maps in Figure 3. Step 4: Output projections of indoor and outdoor annual and monthly demands for each water provider for the average, minimum, and maximum monthly demand scenarios for each of the four urban growth scenarios (SSP3 med, SSP5 low, SSP5 med, and SSP5 high). The outputs also include metrics on each water provider used for the demand sensitivity analysis presented in Figure 8. Outputs from Step 4 are used for Figures 4 - 8 of the paper. Figures: This folder has data used for plotting Figures 1 through 5, and 8. Data for Figures 6 and 7 are sourced directly from folders associated with the Processing and Analysis Steps 1 - 4. The GitHub meta repository provides descriptions of how each figure was made and the associated plotting scripts used.

Los Angeles↗

Dimming LED circuit augmenting DC/DC controller integrated circuit

Embodiments include systems, methods, and apparatuses for providing a dimming function in a single stage AC input light emitting diode (LED) driver with a controller that contains an on-chip error amplifier and an on-chip fixed reference voltage source coupled to a first input of the error amplifier. The controller controls a duty cycle of a switching transistor to cause a feedback voltage, applied to a first package input terminal, to match the reference voltage. To achieve a dimming function, a voltage across a current sense resistor in series with the LEDs is applied to a first input of a high gain differential amplifier, and a variable dimming control voltage is applied to a second input of the differential amplifier. The output of the differential amplifier is coupled to the first package input terminal. The differential amplifier input signals will be matched at the target LED current level.

Song, Zhengrong↗