FARM COMPUTER ADOPTION IN THE GREAT PLAINS

Computers change rapidly, yet the last survey on computer use in agriculture was in 1991. We surveyed Great Plains producers in 1995 and used logit analysis to characterize adopters and non-adopters. About 37% of these producers use computers which is consistent with the general population. We confirmed previous surveys emphasizing the importance of education, age/experience, and other farm characteristics on adoption. However, we also found that education and experience may no longer be a significant influence. Future research and education could focus on when and where computers are most needed, and therefore when adoption is most appropriate.adoption, agriculture, computers, farmers, Great Plains, logit, Farm Management,

The Cloud Services Innovation Platform-Enabling Service-Based Environmental Modelling Using Infrastructure-As-A-Service Cloud Computing

Service oriented architectures allow modelling engines to be hosted over the Internet abstracting physical hardware configuration and software deployments from model users. Many existing environmental models are deployed as desktop applications running on user\u27s personal computers (PCs). Migration to service - based modelling centralizes the modelling functions to service hosts on the Internet . Users no longer require high-end PCs to run models and model updates encapsulating science advances can be disseminated more rapidly by hosting the modelling functions centrally via an Internet host instead of requiring software updates to user\u27s PCs . In this paper we present the Cloud Services Innovation Platform (CSIP), an Infrastructure -as -a -Service cloud application architecture , used to prototype development of distributed and scalable environmental modelling services. CSIP aims to provide modelling as a service to support both interactive (synchronous) and batch (asynchronous) modelling. CSIP enables c loud-based computing resources to be harnessed for both new and existing environmental models supporting the disaggregation of work into subtasks which execute in parallel using a scalable number of virtual machines. This paper presents CSIP \u27s implementation using the RUSLE2 model as a prototype model. RUSLE2 model service benchmarks are presented to demonstrate performance gains from using cloud resources. We also provide benchmarks for virtualization overhead observed using popular virtual machine hypervisors and demonstrate how application profile characteristics significantly impact performance when virtualized

The Virtual Machine (VM) Scaler: An Infrastructure Manager Supporting Environmental Modeling on IaaS Clouds

Infrastructure-as-a-service (IaaS) clouds provide a new medium for deployment of environmental modeling applications. Harnessing advancements in virtualization, IaaS clouds can provide dynamic scalable infrastructure to better support scientific modeling computational demands. Providing scientific modeling as-a-service requires dynamic scaling of server infrastructure to adapt to changing user workloads. This paper presents the Virtual Machine (VM) Scaler, an autonomic resource manager for IaaS Clouds. We have developed VM-Scaler, a REST/JSON-based web services application which supports infrastructure provisioning and management to support scientific modeling for the Cloud Services Innovation Platform (CSIP) [Lloyd et al. 2012]. VM-Scaler harnesses the Amazon Elastic Compute Cloud (EC2) application programming interface to support model- service scalability, cloud management, and infrastructure configuration for supporting modeling workloads. VM-Scaler provides cloud control while abstracting the underlying IaaS cloud from the end user. VM-Scaler is extensible to support any EC2 compatible cloud and currently supports the Amazon public cloud and Eucalyptus private clouds versions 3.1 and 3.3. VM-Scaler provides a platform to improve scientific model deployment by supporting experimentation with: hot spot detection schemes, VM management and placement approaches, and model job scheduling/proxy services

The Virtual Machine (VM) Scaler: An Infrastructure Manager Supporting Environmental Modeling on IaaS Clouds

Infrastructure-as-a-service (IaaS) clouds provide a new medium for deployment of environmental modeling applications. Harnessing advancements in virtualization, IaaS clouds can provide dynamic scalable infrastructure to better support scientific modeling computational demands. Providing scientific modeling as-a-service requires dynamic scaling of server infrastructure to adapt to changing user workloads. This paper presents the Virtual Machine (VM) Scaler, an autonomic resource manager for IaaS Clouds. We have developed VM-Scaler, a REST/JSON-based web services application which supports infrastructure provisioning and management to support scientific modeling for the Cloud Services Innovation Platform (CSIP) [Lloyd et al. 2012]. VM-Scaler harnesses the Amazon Elastic Compute Cloud (EC2) application programming interface to support model- service scalability, cloud management, and infrastructure configuration for supporting modeling workloads. VM-Scaler provides cloud control while abstracting the underlying IaaS cloud from the end user. VM-Scaler is extensible to support any EC2 compatible cloud and currently supports the Amazon public cloud and Eucalyptus private clouds versions 3.1 and 3.3. VM-Scaler provides a platform to improve scientific model deployment by supporting experimentation with: hot spot detection schemes, VM management and placement approaches, and model job scheduling/proxy services

Model-As-A-Service (MaaS) Using the Cloud Services Innovation Platform (CSIP)

Cloud infrastructures for modelling activities such as data processing, performing environmental simulations, or conducting model calibrations/optimizations provide a cost effective alternative to traditional high performance computing approaches. Cloud - based modelling examples emerged into the m ore formal notion: \u27Model - as - a - Service\u27 (MaaS). This paper presents the Cloud Services Innovation Platform (CSIP) as a software framework offering MaaS. It describes both the internal CSIP infrastructure and software architecture that manages cloud resources for typical modelling tasks, and the use of CSIP\u27s \u27 ModelServices API \u27 for a modelling application . CSIP\u27s architecture supports fast and resource aware auto - scaling of computational resources. An example model service is presented: the USDA hydrograph model EFH2 used in the desktop - based \u27engineering field tools\u27 is deployed as a CSIP service. This and other MaaS CSIP examples benefit from the use of cloud resources to enable straightforward scalable model deployment into cloud environments

An Exploratory Investigation on the Invasiveness of Environmental Modeling Frameworks

Environmental modeling frameworks provide an array of useful features that model developers can harness when implementing models. Each framework differs in how it provides features to a model developer via its Application Programming Interface (API). Environmental modelers harness framework features by calling and interfacing with the framework API. As modelers write model code, they make framework-specific function calls and use framework specific data types for achieving the functionality of the model. As a result of this development approach, model code becomes coupled with and dependent on a specific modeling framework. Coupling to a specific framework makes migration to other frameworks and reuse of the code outside the original framework more difficult. This complicates collaboration between model developers wishing to share model code that ma y have been developed in a variety of languages and frameworks. This paper provides initial results of an exploratory investigation on the invasiveness of environmental modeling frameworks. Invasiveness is defined as th e coupling between application (i.e., model) and framework code used to implement the model. By comparing the implementation of an environmental model across several modeling frameworks, we aim to better understand the consequences of framework design. How frameworks present functionality to modelers through APIs can lead to consequences with respect to model development, model maintenance, reuse of model code, and ultimately collaboration among model developers. By measuring framework invasiveness, we hope to provide environmental modeling framework developers and environmental modelers with valuable in formation to assist in future development efforts. Eight implementations (six framework-based) of Thornthwaite, a simple water balance model, were made in a variety of environmental modeling frameworks and languages. A set of software metrics were proposed and applied to measure invasiveness between model implementation code and framework code. The metrics produced a rank ordering of invasiveness for the framework-based implementations of Thornthwaite. We compared model invasiveness results with several popular software metrics including size in lines of code (LOC), cyclomatic complexity, and object oriented coupling. To investigate software quality implications of framework invasiveness we checked for relationships between the Chidamber and Kemerer (1994) object oriented software metrics and our framework invasiveness measures. For the six framework-based implementations of Thornthwaite we found a five-fold variation in code size (LOC). We observed up to a seven-fold variation in total cyclomatic complexity, and a two to three-fold variation in object oriented coupling. For the model implementations we found that total size, total complexity, and total coupling all had a significant positive correlation. The raw count version of our invasiveness measures correlated with application size (LOC), total cyclomatic complexity, total efferent coupling (fan out) and total afferent coupling (fan in). Large size, complexity, and high levels of coupling between units (classes, modules) in a software system are often cited in software engineering as causes of high maintenance costs due to poor understandability and flexibility of the code. This study provides initial results but further investigation is desired to evaluate the utility of our invasiveness measurement approach as well as the software quality implications of framework invasiveness

Environmental Modeling Framework Invasiveness: Analysis and Implications

Environmental modeling frameworks support scientific model development by providing an Application Programming Interface (API) which model developers use to implement models. This paper presents results of an investigation on the framework invasiveness of environmental modeling frameworks. Invasiveness is defined as the quantity of dependencies between model code and the modeling framework. This research investigates relationships between invasiveness and the quality of modeling code. Additionally, we investigate the relationship between invasiveness and two common framework designs (lightweight vs. heavyweight). Five metrics to measure framework invasiveness were proposed and applied to measure invasiveness between model and framework code of several implementations of Thornthwaite and the Precipitation-Runoff Modeling System (PRMS), two hydrological models. Framework invasiveness measurements were compared with existing software metrics including size (lines of code), cyclomatic complexity, and object-oriented coupling with generally positive correlations being found. We found that models with lower framework invasiveness tended to be smaller, less complex, and have lower coupling. In addition, the lightweight framework implementations of the Thornthwaite and PRMS models were less invasive than the heavyweight framework model implementations. Our initial results suggest that framework invasiveness is undesirable for model code quality and that lightweight frameworks may help reduce invasiveness

Large-scale phenotyping of patients with long COVID post-hospitalization reveals mechanistic subtypes of disease

One in ten severe acute respiratory syndrome coronavirus 2 infections result in prolonged symptoms termed long coronavirus disease (COVID), yet disease phenotypes and mechanisms are poorly understood1. Here we profiled 368 plasma proteins in 657 participants ≥3 months following hospitalization. Of these, 426 had at least one long COVID symptom and 233 had fully recovered. Elevated markers of myeloid inflammation and complement activation were associated with long COVID. IL-1R2, MATN2 and COLEC12 were associated with cardiorespiratory symptoms, fatigue and anxiety/depression; MATN2, CSF3 and C1QA were elevated in gastrointestinal symptoms and C1QA was elevated in cognitive impairment. Additional markers of alterations in nerve tissue repair (SPON-1 and NFASC) were elevated in those with cognitive impairment and SCG3, suggestive of brain–gut axis disturbance, was elevated in gastrointestinal symptoms. Severe acute respiratory syndrome coronavirus 2-specific immunoglobulin G (IgG) was persistently elevated in some individuals with long COVID, but virus was not detected in sputum. Analysis of inflammatory markers in nasal fluids showed no association with symptoms. Our study aimed to understand inflammatory processes that underlie long COVID and was not designed for biomarker discovery. Our findings suggest that specific inflammatory pathways related to tissue damage are implicated in subtypes of long COVID, which might be targeted in future therapeutic trials

Large-scale phenotyping of patients with long COVID post-hospitalization reveals mechanistic subtypes of disease

One in ten severe acute respiratory syndrome coronavirus 2 infections result in prolonged symptoms termed long coronavirus disease (COVID), yet disease phenotypes and mechanisms are poorly understood1. Here we profiled 368 plasma proteins in 657 participants ≥3 months following hospitalization. Of these, 426 had at least one long COVID symptom and 233 had fully recovered. Elevated markers of myeloid inflammation and complement activation were associated with long COVID. IL-1R2, MATN2 and COLEC12 were associated with cardiorespiratory symptoms, fatigue and anxiety/depression; MATN2, CSF3 and C1QA were elevated in gastrointestinal symptoms and C1QA was elevated in cognitive impairment. Additional markers of alterations in nerve tissue repair (SPON-1 and NFASC) were elevated in those with cognitive impairment and SCG3, suggestive of brain–gut axis disturbance, was elevated in gastrointestinal symptoms. Severe acute respiratory syndrome coronavirus 2-specific immunoglobulin G (IgG) was persistently elevated in some individuals with long COVID, but virus was not detected in sputum. Analysis of inflammatory markers in nasal fluids showed no association with symptoms. Our study aimed to understand inflammatory processes that underlie long COVID and was not designed for biomarker discovery. Our findings suggest that specific inflammatory pathways related to tissue damage are implicated in subtypes of long COVID, which might be targeted in future therapeutic trials

FARM COMPUTER ADOPTION IN THE GREAT PLAINS

Computers change rapidly, yet the last survey on computer use in agriculture was in 1991. We surveyed Great Plains producers in 1995 and used logit analysis to characterize adopters and non-adopters. About 37% of these producers use computers which is consistent with the general population. We confirmed previous surveys emphasizing the importance of education, age/experience, and other farm characteristics on adoption. However, we also found that education and experience may no longer be a significant influence. Future research and education could focus on when and where computers are most needed, and therefore when adoption is most appropriate