Autoantibodies to Agrin in Myasthenia Gravis Patients

To determine if patients with myasthenia gravis (MG) have antibodies to agrin, a proteoglycan released by motor neurons and is critical for neuromuscular junction (NMJ) formation, we collected serum samples from 93 patients with MG with known status of antibodies to acetylcholine receptor (AChR), muscle specific kinase (MuSK) and lipoprotein-related 4 (LRP4) and samples from control subjects (healthy individuals and individuals with other diseases). Sera were assayed for antibodies to agrin. We found antibodies to agrin in 7 serum samples of MG patients. None of the 25 healthy controls and none of the 55 control neurological patients had agrin antibodies. Two of the four triple negative MG patients (i.e., no detectable AChR, MuSK or LRP4 antibodies, AChR-/MuSK-/LRP4-) had antibodies against agrin. In addition, agrin antibodies were detected in 5 out of 83 AChR+/MuSK-/LRP4- patients but were not found in the 6 patients with MuSK antibodies (AChR-/MuSK+/LRP4-). Sera from MG patients with agrin antibodies were able to recognize recombinant agrin in conditioned media and in transfected HEK293 cells. These sera also inhibited the agrin-induced MuSK phosphorylation and AChR clustering in muscle cells. Together, these observations indicate that agrin is another autoantigen in patients with MG and agrin autoantibodies may be pathogenic through inhibition of agrin/LRP4/MuSK signaling at the NMJ

BacHBerry: BACterial Hosts for production of Bioactive phenolics from bERRY fruits

BACterial Hosts for production of Bioactive phenolics from bERRY fruits (BacHBerry) was a 3-year project funded by the Seventh Framework Programme (FP7) of the European Union that ran between November 2013 and October 2016. The overall aim of the project was to establish a sustainable and economically-feasible strategy for the production of novel high-value phenolic compounds isolated from berry fruits using bacterial platforms. The project aimed at covering all stages of the discovery and pre-commercialization process, including berry collection, screening and characterization of their bioactive components, identification and functional characterization of the corresponding biosynthetic pathways, and construction of Gram-positive bacterial cell factories producing phenolic compounds. Further activities included optimization of polyphenol extraction methods from bacterial cultures, scale-up of production by fermentation up to pilot scale, as well as societal and economic analyses of the processes. This review article summarizes some of the key findings obtained throughout the duration of the project

Iterative optimization for the data center

Iterative optimization is a simple but powerful approach that searches for the best possible combination of compiler optimizations for a given workload. However, each program, if not each data set, potentially favors a different combination. As a result, iterative optimization is plagued by several practical issues that prevent it from being widely used in practice: a large number of runs are required for finding the best combination; the process can be data set dependent; and the exploration process incurs significant overhead that needs to be compensated for by performance benefits. Therefore, while iterative optimization has been shown to have significant performance potential, it is seldomly used in production compilers. In this paper, we propose Iterative Optimization for the Data Center (IODC): we show that servers and data centers offer a context in which all of the above hurdles can be overcome. The basic idea is to spawn different combinations across workers and recollect performance statistics at the master, which then evolves to the optimum combination of compiler optimizations. IODC carefully manages costs and benefits, and is transparent to the end user. We evaluate IODC using both Map Reduce and throughput compute-intensive server applications. In order to reflect the large number of users interacting with the system, we gather a very large collection of data sets (at least 1000 and up to several million unique data sets per program), for a total storage of 10.7TB, and 568 days of CPU time. We report an average performance improvement of 1.48x, and up to 2.08x, for the MapReduce applications, and 1.14 x, and up to 1.39x, for the throughput compute-intensive server applications