960 resultados para Blast furnace slag
Resumo:
Numerical analysis is a suitable tool in the design of complex reinforced concrete structures under extreme impulsive loadings such as impacts or explosions at close range. Such events may be the result of terrorist attacks. Reinforced concrete is commonly used for buildings and infrastructures. For this reason, the ability to accurately run numerical simulations of concrete elements subjected to blast loading is needed. In this context, reliable constitutive models for concrete are of capital importance. In this research numerical simulations using two different constitutive models for concrete (Continuous Surface Cap Model and Brittle Damage Model) have been carried out using LS-DYNA. Two experimental benchmark tests have been taken as reference. The results of the numerical simulations with the aforementioned constitutive models show different abilities to accurately represent the structural response of the reinforced concrete elements studied.
Resumo:
Este Trabajo de Fin de Grado (TFG) consiste en el diseño y el desarrollo de una base de datos para almacenar datos de secuenciación genética. Además, también será necesario poder utilizar la herramienta BLAST, que está formada por un conjunto de programas para buscar por similitud y alinear secuencias, con los datos que se encuentran almacenados en dicha base de datos.---ABSTRACT---The aim of this Bachelor’s Thesis is to design and develop a database to store data of genetic sequences. Furthermore, it will be necessary to use BLAST, which is a suite of programs to search and match similarities sequences into a database.
Resumo:
Civil buildings are not specifically designed to support blast loads, but it is important to take into account these potential scenarios because of their catastrophic effects, on persons and structures. A practical way to consider explosions on reinforced concrete structures is necessary. With this objective we propose a methodology to evaluate blast loads on large concrete buildings, using LS-DYNA code for calculation, with Lagrangian finite elements and explicit time integration. The methodology has three steps. First, individual structural elements of the building like columns and slabs are studied, using continuum 3D elements models subjected to blast loads. In these models reinforced concrete is represented with high precision, using advanced material models such as CSCM_CONCRETE model, and segregated rebars constrained within the continuum mesh. Regrettably this approach cannot be used for large structures because of its excessive computational cost. Second, models based on structural elements are developed, using shells and beam elements. In these models concrete is represented using CONCRETE_EC2 model and segregated rebars with offset formulation, being calibrated with continuum elements models from step one to obtain the same structural response: displacement, velocity, acceleration, damage and erosion. Third, models basedon structural elements are used to develop large models of complete buildings. They are used to study the global response of buildings subjected to blast loads and progressive collapse. This article carries out different techniques needed to calibrate properly the models based on structural elements, using shells and beam elements, in order to provide results of sufficient accuracy that can be used with moderate computational cost.
Resumo:
The rice blast fungus, Magnaporthe grisea, generates enormous turgor pressure within a specialized cell called the appressorium to breach the surface of host plant cells. Here, we show that a mitogen-activated protein kinase, Mps1, is essential for appressorium penetration. Mps1 is 85% similar to yeast Slt2 mitogen-activated protein kinase and can rescue the thermosensitive growth of slt2 null mutants. The mps1–1Δ mutants of M. grisea have some phenotypes in common with slt2 mutants of yeast, including sensitivity to cell-wall-digesting enzymes, but display additional phenotypes, including reduced sporulation and fertility. Interestingly, mps1–1Δ mutants are completely nonpathogenic because of the inability of appressoria to penetrate plant cell surfaces, suggesting that penetration requires remodeling of the appressorium wall through an Mps1-dependent signaling pathway. Although mps1–1Δ mutants are unable to cause disease, they are able to trigger early plant-cell defense responses, including the accumulation of autofluorescent compounds and the rearrangement of the actin cytoskeleton. We conclude that MPS1 is essential for pathogen penetration; however, penetration is not required for induction of some plant defense responses.
Resumo:
A short interspersed nuclear element, Mg-SINE, was isolated and characterized from the genome of the rice blast fungus, Magnaporthe grisea. Mg-SINE was isolated as an insertion element within Pot2, an inverted-repeat transposon from M. grisea and shows typical features of a mammalian SINE. Mg-SINE is present as a 0.47-kb interspersed sequence at approximately 100 copies per haploid genome in both rice and non-rice isolates of M. grisea, indicating a common evolutionary origin. Secondary structure analysis of Mg-SINE revealed a tRNA-related region at the 5' end which folds into a cloverleaf structure. Genomic fusions resulting in chimeric Mg-SINEs (Ch-SINEs) composed of a sequence homologous to Mg-SINE at the 3' end and an unrelated sequence at its 5' end were also isolated, indicating that this and other DNA rearrangements mediated by these elements may have a major effect on the genomic architecture of this fungus.
Resumo:
Resumen del póster presentado en PIC2015 – the 14th International Congress on Combustion By-Products and Their Health Effects, Umeå, Sweden, 14-17 June 2015.
Resumo:
no.2(1922)
Resumo:
Em Bioinformática são frequentes problemas cujo tratamento necessita de considerável poder de processamento/cálculo e/ou grande capacidade de armazenamento de dados e elevada largura de banda no acesso aos mesmos (de forma não comprometer a eficiência do seu processamento). Um exemplo deste tipo de problemas é a busca de regiões de similaridade em sequências de amino-ácidos de proteínas, ou em sequências de nucleótidos de DNA, por comparação com uma dada sequência fornecida (query sequence). Neste âmbito, a ferramenta computacional porventura mais conhecida e usada é o BLAST (Basic Local Alignment Search Tool) [1]. Donde, qualquer incremento no desempenho desta ferramenta tem impacto considerável (desde logo positivo) na atividade de quem a utiliza regularmente (seja para investigação, seja para fins comerciais). Precisamente, desde que o BLAST foi inicialmente introduzido, foram surgindo diversas versões, com desempenho melhorado, nomeadamente através da aplicação de técnicas de paralelização às várias fases do algoritmo (e. g., partição e distribuição das bases de dados a pesquisar, segmentação das queries, etc. ), capazes de tirar partido de diferentes ambientes computacionais de execução paralela, como: máquinas multi-core (BLAST+ 2), clusters de nós multi-core (mpiBLAST3J e, mais recentemente, co-processadores aceleradores como GPUs" ou FPGAs. É também possível usar as ferramentas da família BLAST através de um interface/sítio WEB5, que permite, de forma expedita, a pesquisa de uma variedade de bases de dados conhecidas (e em permanente atualização), com tempos de resposta suficientemente pequenos para a maioria dos utilizadores, graças aos recursos computacionais de elevado desempenho que sustentam o seu backend. Ainda assim, esta forma de utilização do BLAST poderá não ser a melhor opção em algumas situações, como por exemplo quando as bases de dados a pesquisar ainda não são de domínio público, ou, sendo-o, não estão disponíveis no referido sitio WEB. Adicionalmente, a utilização do referido sitio como ferramenta de trabalho regular pressupõe a sua disponibilidade permanente (dependente de terceiros) e uma largura de banda de qualidade suficiente, do lado do cliente, para uma interacção eficiente com o mesmo. Por estas razões, poderá ter interesse (ou ser mesmo necessário) implantar uma infra-estrutura BLAST local, capaz de albergar as bases de dados pertinentes e de suportar a sua pesquisa da forma mais eficiente possível, tudo isto levando em conta eventuais constrangimentos financeiros que limitam o tipo de hardware usado na implementação dessa infra-estrutura. Neste contexto, foi realizado um estudo comparativo de diversas versões do BLAST, numa infra-estrutura de computação paralela do IPB, baseada em componentes commodity: um cluster de 8 nós (virtuais, sob VMWare ESXi) de computação (com CPU Í7-4790K 4GHz, 32GB RAM e 128GB SSD) e um nó dotado de uma GPU (CPU Í7-2600 3.8GHz, 32GB RAM, 128 GB SSD, 1 TB HD, NVIDIA GTX 580). Assim, o foco principal incidiu na avaliação do desempenho do BLAST original e do mpiBLAST, dado que são fornecidos de base na distribuição Linux em que assenta o cluster [6]. Complementarmente, avaliou-se também o BLAST+ e o gpuBLAST no nó dotado de GPU. A avaliação contemplou diversas configurações de recursos, incluindo diferentes números de nós utilizados e diferentes plataformas de armazenamento das bases de dados (HD, SSD, NFS). As bases de dados pesquisadas correspondem a um subconjunto representativo das disponíveis no sitio WEB do BLAST, cobrindo uma variedade de dimensões (desde algumas dezenas de MBytes, até à centena de GBytes) e contendo quer sequências de amino-ácidos (env_nr e nr), quer de nucleótidos (drosohp. nt, env_nt, mito. nt, nt e patnt). Para as pesquisas foram 'usadas sequências arbitrárias de 568 letras em formato FASTA, e adoptadas as opções por omissão dos vários aplicativos BLAST. Salvo menção em contrário, os tempos de execução considerados nas comparações e no cálculo de speedups são relativos à primeira execução de uma pesquisa, não sendo assim beneficiados por qualquer efeito de cache; esta opção assume um cenário real em que não é habitual que uma mesma query seja executada várias vezes seguidas (embora possa ser re-executada, mais tarde). As principais conclusões do estudo comparativo realizado foram as seguintes: - e necessário acautelar, à priori, recursos de armazenamento com capacidade suficiente para albergar as bases de dados nas suas várias versões (originais/compactadas, descompactadas e formatadas); no nosso cenário de teste a coexistência de todas estas versões consumiu 600GBytes; - o tempo de preparação (formataçâo) das bases de dados para posterior pesquisa pode ser considerável; no nosso cenário experimental, a formatação das bases de dados mais pesadas (nr, env_nt e nt) demorou entre 30m a 40m (para o BLAST), e entre 45m a 55m (para o mpiBLAST); - embora economicamente mais onerosos, a utilização de discos de estado sólido, em alternativa a discos rígidos tradicionais, permite melhorar o tempo da formatação das bases de dados; no entanto, os benefícios registados (à volta de 9%) ficam bastante aquém do inicialmente esperado; - o tempo de execução do BLAST é fortemente penalizado quando as bases de dados são acedidas através da rede, via NFS; neste caso, nem sequer compensa usar vários cores; quando as bases de dados são locais e estão em SSD, o tempo de execução melhora bastante, em especial com a utilização de vários cores; neste caso, com 4 cores, o speedup chega a atingir 3.5 (sendo o ideal 4) para a pesquisa de BDs de proteínas, mas não passa de 1.8 para a pesquisa de BDs de nucleótidos; - o tempo de execução do mpiBLAST é muito prejudicado quando os fragmentos das bases de dados ainda não se encontram nos nós do cluster, tendo que ser distribuídos previamente à pesquisa propriamente dita; após a distribuição, a repetição das mesmas queries beneficia de speedups de 14 a 70; porém, como a mesma base de dados poderá ser usada para responder a diferentes queries, então não é necessário repetir a mesma query para amortizar o esforço de distribuição; - no cenário de teste, a utilização do mpiBLAST com 32+2 cores, face ao BLAST com 4 cores, traduz-se em speedups que, conforme a base de dados pesquisada (e previamente distribuída), variam entre 2 a 5, valores aquém do máximo teórico de 6.5 (34/4), mas ainda assim demonstradores de que, havendo essa possibilidade, compensa realizar as pesquisas em cluster; explorar vários cores) e com o gpuBLAST, realizada no nó com GPU (representativo de uma workstation típica), permite aferir qual a melhor opção no caso de não serem possíveis pesquisas em cluster; as observações realizadas indicam que não há diferenças significativas entre o BLAST e o BLAST+; adicionalmente, o desempenho do gpuBLAST foi sempre pior (aproximadmente em 50%) que o do BLAST e BLAST+, o que pode encontrar explicação na longevidade do modelo da GPU usada; - finalmente, a comparação da melhor opção no nosso cenário de teste, representada pelo uso do mpiBLAST, com o recurso a pesquisa online, no site do BLAST5, revela que o mpiBLAST apresenta um desempenho bastante competitivo com o BLAST online, chegando a ser claramente superior se se considerarem os tempos do mpiBLAST tirando partido de efeitos de cache; esta assunção acaba por se justa, Já que BLAST online também rentabiliza o mesmo tipo de efeitos; no entanto, com tempos de pequisa tão reduzidos (< 30s), só é defensável a utilização do mpiBLAST numa infra-estrutura local se o objetivo for a pesquisa de Bds não pesquisáveis via BLAS+ online.
Resumo:
Description based on: 1913/1914.
Resumo:
Mode of access: Internet.
Resumo:
Mode of access: Internet.
Resumo:
"Work Performed Under Contract No. EG-77-C-01-4042."
Resumo:
"Progress report AEC Contract no. AT(29-1)-1242."