Logo do repositório
 

Resultados da pesquisa

A mostrar 1 - 10 de 156
  • Reconstruction of meteorological records by methods based on dimension reduction of the predictor dataset
    Publication . Balsa, Carlos; Breve, Murilo Montanini; Rodrigues, Carlos Veiga; Rufino, José
    The reconstruction or prediction of meteorological records through the Analog Ensemble (AnEn) method is very efficient when the number of predictor time series is small. Thus, in order to take advantage of the richness and diversity of information contained in a large number of predictors, it is necessary to reduce their dimensions. This study presents methods to accomplish such reduction, allowing the use of a high number of predictor variables. In particular, the techniques of Principal Component Analysis (PCA) and Partial Least Squares (PLS) are used to reduce the dimension of the predictor dataset without loss of essential information. The combination of the AnEn and PLS techniques results in a very efficient hybrid method (PLSAnEn) for reconstructing or forecasting unstable meteorological variables, such as wind speed. This hybrid method is computationally demanding but its performance can be improved via parallelization or the introduction of variants in which all possible analogs are previously clustered. The multivariate linear regression methods used on the new variables resulting from the PCA or PLS techniques also proved to be efficient, especially for the prediction of meteorological variables without local oscillations, such as the pressure.
  • Distributed heterogeneous computing with clOpenCL
    Publication . Ribeiro, Tiago Filipe Rodrigues; Afonso, Mário João da Costa; Rufino, José; Alves, Albano
    Clusters of heterogeneous computing nodes provide an opportunity to significantly increase the performance of parallel and High-Performance Computing (HPC) applications, by combining traditional multi-core CPUs coupled with accelerator devices, interconnected by high throughput and low latency networking technologies. However, developing efficient applications to run in clusters that integrate GPUs and other accelerators often requires a great effort, demanding programmers to follow complex development methodologies in order to suit algorithms and applications to the new heterogeneous parallel environment. OpenCL is an open programming standard for heterogeneous computing. It suffers, however, from a major limitation: applications can only make use of the local compute devices, present on a single machine. clOpenCL (cluster OpenCL) supports the simple deployment and efficient running of unmodified OpenCL-based parallel applications that may span several cluster nodes, expanding the original single-node OpenCL model.
  • Autent+ Desenvolvimento de abordagem inovadoras com vista à valorização e exploração do potencial de mercado do mel Português
    Publication . Amaral, Joana S.; Quaresma, Andreia; Rodrigues, Pedro João; Rufino, José; Henriques, Dora; Calaim, Luís; Gaspar, Albino; Pinto, M. Alice
    A FENAPICOLA candidatou-se, como proponente, a uma medida de investigação aplicada, tendo convidado o Instituto Politécnico de Bragança (IPB) como entidade parceira, envolvendo este último uma equipa multidisciplinar de 6 investigadores provenientes dos centros de investigação CIMO (Centro de Investigação de Montanha) e CEDRI (Centro de Investigação em Digitalização e Robótica Inteligente). Assim foi criado o projeto AUTENT+, um projeto financiado pelo Instituto de Financiamento da Agricultura e Pescas (IFAP), em resultado da candidatura submetida ao Plano Apícola Nacional (PAN) 2020/2022, medida 5.1 "Apoio a projetas de investigação aplicada”. O AUTENT + tem como principal objetivo a valorização do mel nacional como um produto autêntico e sustentável, através de abordagens que visam diferenciar, acrescentar valor e o potencial de mercado a este produto. Para tal, o projeto centra-se no desenvolvimento de metodologias inovadoras com vista à deteção de adulterações do mel, em particular no que respeita à origem botânica e entomológica/geográfica, e no desenvolvimento de ferramentas que permitam , de uma forma simples, informar o consumidor sobre as caraterísticas do produto que adquirem.
  • An architecture for reliable transportation of delicate goods
    Publication . Matos, Paulo; Rufino, José; Lopes, Rui Pedro
    Adequate conditions are critical to avoiding damage or degradation of products during transportation, especially in the case of delicate goods like food products, live animals, precision machinery or art items, among others. The damages are not always readily identified: sometimes they are only detected several days or weeks after the merchandise has been delivered. Moreover, it may be hard to assess if the problems resulted from the transport conditions, and it may be even harder to prove it, making it difficult to determine and assign responsibilities. Also, transport is a global business, typically involving different companies and means (truck, train, plane, ship, …). Usually, customers hire the service to a single commercial entity, but the service is performed by several companies, like transporters, stockists and dispatchers. To know whether the transport requirements are fulfilled or not is thus essential to assessing responsibilities and encouraging compliance by all the players in the process. In this paper, the authors propose an architecture that allows certifying, in an exempt manner, the conditions under which the transport of sensitive goods are carried out. In case of compliance, it protects the entities of the transport chain and ensures the customer that the merchandise has not been subject to conditions that may have affected its integrity or quality. If problems are detected, it allows to identify the non‐compliant players and to assign responsibilities. The solution is based on ultra‐low‐power, low‐cost devices (equipped with several sensors, a real‐time clock, and Bluetooth Low Energy services), a mobile application and several cloud services (including a Coordinated Universal Time service)
  • MCSFilter performance: a comparison study
    Publication . Monteiro, Luís; Rufino, José; Romanenko, Andrey; Fernandes, Florbela P.
  • Applications of the analog ensembles method to meteorological data reconstruction in the Northeast of Portugal
    Publication . Breve, Murilo Montanini; Rufino, José; Balsa, Carlos; Costa, Luís
    The observation of weather states has always been a human need. Our most distant ancestors already tried to understand and predict the weather, but did not have reliable methods. In the 19th century, modern meteorology took its first steps: the French government, motivated by the sinking of ships near the coast of Crimea, because of a heavy rainstorm, created a network of 24 stations spread across Europe, which began to observe the weather. In recent years, due to computational advances, different methods of predicting weather states have begun to emerge, increasing the forecast extent and its accuracy. The Analog Ensembles method (AnEn), introduced by Luca Delle Monache in 2011 [1], is a post-processing tool that has shown good results to improve whether predictions or perform hindcasting (reconstruction of missing meteorological data). The goal of this study is to use the AnEn method to perform hindcasting, in order to reconstruct past weather conditions in a specific area of the northeeast of Portugal and verify its similarity with the actual forecast.
  • Uma abordagem à comunicação segura em aplicações distribuídas
    Publication . Rufino, José
    Nesta dissertação apresenta-se o S3L, fundamentalmente uma API que fornece serviços de segurança (Privacidade, Autenticação, Integridade e Sequenciação -- contra ataques-de-repetição --) imediatamente acima da interface de programação dos sockets de Berkeley, preservando, tanto quanto possível, grandes semelhanças sintácticas e semânticas com o dito modelo de programação. O S3L permite a migração, com um mínimo de esforço, de aplicações não seguras baseadas em sockets de Berkeley, para um modo de operação mais seguro, no qual a troca de informação de segurança (e.g, chaves, algoritmos, números de sequência, códigos de autenticação, etc.) ocorre de uma forma quase stateless. Desde que tenha lugar uma execução inicial do protocolo proposto Skeyx (o qual permite a troca segura de chaves públicas de Diffie-Hellman não certificadas) então, quaisquer contactos futuros entre duas entidades comunicantes poderão ocorrer, quer sobre protocolos não-orientados-à-conexão (IP/UDP) -- incluindo a variante multiponto --, quer sobre protocolos orientados-à-conexão (TCP), sem que para tal seja necessário o estabelecimento prévio de uma sessão segura. A informação de segurança específica para cada pacote viaja lado a lado com os dados do utilizador e a única (mas obrigatória) execução do protocolo Skeyx tem lugar de uma forma transparente e automática.
  • The role of background colour in pollen recognition task using CNN
    Publication . Monteiro, Fernando C.; Pinto, Cristina M.; Rufino, José
    Pollen recognition is a crucial but challenging task in addressing a variety of questions like pollination or palaeobotany, but also for other fields of research, e.g., allergology, melissopalynology or forensics. State-of-the-art methods mainly use deep learning CNNs for pollen recognition, however, we observe that existing published approaches use original images without study the possible biased recognition due to pollen’s background colour. In this paper, we evaluate the DenseNet model trained with original images and with segmented images (remove background) and analyse network’s predictive performance under these conditions using a cross evaluation approach. An accuracy of 97.4% was achieved that represents one of the best successes rate when weighted with the number of taxa of any attempt at automated pollen analysis currently documented in the literature. From these results, we confirm the existence of background specific influence in the recognition task.
  • Is diabetic retinopathy grading biased by imbalanced datasets?
    Publication . Monteiro, Fernando C.; Rufino, José
    Diabetic retinopathy (DR) is one of the most severe complications of diabetes and the leading cause of vision loss and even blindness. Retinal screening contributes to early detection and treatment of diabetic retinopathy. This eye disease has five stages, namely normal, mild, moderate, severe and proliferative diabetic retinopathy. Usually, highly trained ophthalmologists are capable of manually identifying the presence or absence of retinopathy in retinal images. Several automated deep learning (DL) based approaches have been proposed and they have been proven to be a powerful tool for DR detection and classification. However, these approaches are usually biased by the cardinality of each grade set, as the overall accuracy benefits the largest sets in detriment of smaller ones. In this paper, we applied several state-of-the-art DL approaches, using a 5-fold cross-validation technique. The experiments were conducted on a balanced DDR dataset containing 31330 retina fundus images by completing the small grade sets with samples from other well known datasets. This balanced dataset increases robustness of training and testing tasks as they used samples from several origins and obtained with different equipment. The results confirm the bias introduced by using imbalanced datasets in automatic diabetic retinopathy grading.
  • Desempenho comparativo do BLAST e do mpiBLAST
    Publication . Rufino, José
    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.