Aplicação web para modelagem de sistema PET

(1)

COMISS ˜AO NACIONAL DE ENERGIA NUCLEAR

CENTRO REGIONAL DE CI ÊNCIAS NUCLEARES DO NORDESTE PROGRAMA DE P ÓS-GRADUAÇ ÃO EM TECNOLOGIAS ENERG ÉTICAS E

NUCLEARES

LEANDERSON PEREIRA CORDEIRO

APLICAC¸ ˜AO WEB PARA MODELAGEM DE SISTEMA PET

Recife

2016

(2)

APLICAC

¸ ˜

AO WEB PARA MODELAGEM DE SISTEMA

PET

Dissertação submetida ao Programa de Pós-Graduação em Tecnologias Energéticas e Nucleares para obtenção do t´ıtulo de Mestre em Tecnologias Energéticas e Nucleares.

´

Area de Concentração: Modelagem Computacional de Tomógrafos por Emissão de Pósitrons.

Orientadores: Dr. Fernando Roberto de Andrade Lima Dr. Jos´e Wilson Vieira

Recife

2016

(3)

C794a Cordeiro, Leanderson Pereira.

Aplicação web para modelagem de sistema PET. / Leanderson Pereira Cordeiro. - Recife, 2016.

51 f. : il., figs., gráfs., tabs.

Orientadores: Dr. Fernando Roberto de Andrade Lima. Dr. José Wilson Vieira.

Dissertação (mestrado) – Universidade Federal de Pernambuco. CTG. Programa de Pós-Graduação em Tecnologias Energéticas e Nucleares, 2016.

Inclui referências e apêndices.

1. Engenharia Nuclear. 2. GATE. 3. Monte Carlo. 4. PET. I. Lima, Fernando Roberto de Andrade, orientador. II. Vieira, José Wilson, orientador. III. Título.

UFPE

(4)

APLICAC

¸ ˜

AO WEB PARA MODELAGEM DE SISTEMA

PET

Dissertação submetida ao Programa de Pós-Graduação em Tecnologias Energéticas e Nucleares para obtenção do t´ıtulo de Mestre em Tecnologias Energéticas e Nucleares.

Aprovada em: 04/08/2016.

BANCA EXAMINADORA

Profo Dr. Fernando Roberto de Andrade Lima (Orientador) - CRCN/NE

Profo Dr. Jos´e Wilson Vieira (Orientador) - IFPE

ProfoDr. Vin´ıcius Saito Monteiro de Barros (Examinador Interno) - DEN/UFPE

ProfoDr. Silvio de Barros Melo (Examinador Externo) - CIN/UFPE

Pesquisador Dr. Clayton Augusto Benevides (Examinador Externo) - CRCN/NE

Recife

2016

(5)

Aos professores Dr. Fernando e Dr. Wilson, meus estimados orientadores, sempre dando grandes ideias de como melhorar meu trabalho e sempre encontrando soluc¸˜oes para os problemas que apareciam.

Ao meu amigo Igor, idealizador deste trabalho, que me incentivou muito a seguir uma carreira acadˆemica, al´em de participar ativamente neste trabalho.

Ao Daniel Bonifácil, grande pesquisador de sistemas PET, além de se tornar um grande amigo, teve grande partipação no desenvolvimento do desing da aplicação web contru´ıda.

Ao meu grande amigo Alex e companheiro de pesquisa, me ajudando e abrindo meus olhos para problemas que pareciam ser insolucionav´eis.

Aos doutores Silvio Melo, Viriato Leal e Clayton Benevides que acompanharam este trabalho desde o in´ıcio, apresentando cr´ıticas construtivas.

Aos meus amigos Márcio, Manuela, Izabelle, Patr´ıcia e Ísis que tornaram o ambiente de trabalho muito agradável.

`

A minha irm˜a Leilane, futura f´ısica, sempre me apoiando e me dando orgulho.

E por fim, `a minha grande hero´ına Da Marlene que sempre me apoiou e me deu suporte, minha m˜ae.

(6)

Simulações no âmbito da medicina nuclear com utilização do GATE (Geant4 Application for Emission Tomography), têm contribu´ıdo fortemente no desenvolvimento de pesquisas para a melhoria na eficácia de suas tecnologias. Entre elas, a Tomografia por Emissão de Pósitron (PET) que avalia o metabolismo celular, identificando a localização e as dimensões de regiões cancer´ıgenas. No entanto, a necessidade de dom´ınio de linguagens de programação, a complexidade de instalação do GATE e seus pré-requisitos, assim como as restrições de compatibilidade com os sistemas operacionais populares, restringem significativamente o público alvo desses estudos. O objetivo deste trabalho é desenvolver uma interface web que integre um único ambiente as ferramentas necessárias para execução de simulações de equipamentos PET, solucionando os problemas de instalação e compatibilidade do GATE, além de gerar os comandos solicitados para realizar uma simulação. Para isto, uma aplicação web foi desenvolvida, a WebGUIGATE, utilizando principalmente a linguagem de programação Python e o Django, framework de construção de aplicações web. A WebGUIGATE apresenta-se na forma de uma interface, solicitando parâmetros de entrada que servirão para modelagem do scanner, fantoma, processos f´ısicos, fontes e detectores, resultando nas contruções de macros (arquivos de textos) que contém os comandos na linguagem do GATE. Para validação, o microPET FOCUS 220 foi implementado através da WebGUIGATE, que mesmo estando em processo de desenvolvimento, foi capaz de gerar as macros para simulação com êxito.

(7)

Simulations in the field of nuclear medicine with the use of GATE (Geant4 Application for Emission Tomography), have strongly contributed to the development of research to improve the effectiveness of its technologies. Among them, the Positron Emission Tomography (PET) that assesses cellular metabolism, identifying the location and dimensions of carcinogenic regions. However, the need programming languages knowledge, the complexity of the installation and its GATE prerequisites as well as compatibility constraints with popular operating systems significantly restrict the target audience for these studies. The objective of this work is to develop a web interface that integrates a unique environment the necessary tools to perform PET equipment simulations, solving the problems of installation and compatibility of GATE and generate the commands required to perform a simulation. For this, a web application was developed, WebGUIGATE, mainly using the Python programming language and the Django, a framework for building web applications. The WebGUIGATE is presented in the form of an interface, requesting input parameters that will be used to scanner modeling, phantom, physical processes, sources and detectors, exporting macro (text files) containing the commands in GATE language. For validation, microPET FOCUS 220 has been implemented by WebGUIGATE, that even being in development process, was able to generate macros for successful simulation.

(8)

Figura 1 – Gr´afico de um espectro de energia depositada por um detector. . . 14

Figura 2 – Esquema e diagrama de um tubo fotomultiplicador. . . 15

Figura 3 – Esquema de detectores configurados para medirem fótons coincidentes. 16 Figura 4 – Eventos de coincidências aleatórias e de espalhamento em PET scan. . . 17

Figura 5 – Definição da resolução de um detector. Para picos cuja forma é gaussiana com desvio padrão σ . . . 18

Figura 6 – Ilustrac¸˜ao para dois modelos de comportamento do tempo morto em detectores PET. . . 19

Figura 7 – Esquema do m´odulo digitizer. . . 21

Figura 8 – Esquema de construc¸˜ao da WebGUIGATE. . . 26

Figura 9 – Script de um fantoma cil´ındrico simples. . . 26

Figura 10 – Esquema de funcionamento da WebGUIGATE. . . 28

Figura 11 – Definição dos novos parâmetros para implementação do scanner. . . 29

Figura 12 – P´agina inicial WebGUIGATE. . . 31

Figura 13 – Página para definição de parâmetros gerais da simulação. . . 32

Figura 14 – P´agina para modelagem do scanner. . . 32

Figura 15 – P´agina para modelagem do phantom. . . 33

Figura 16 – Interatividade dos campos em resposta às ações do usuário, no aplicativo Phantom. . . 33

Figura 17 – Página para definição do physic list builder. . . 34

Figura 18 – P´agina para modelagem da fonte. . . 34

Figura 19 – Página para modelagem do método de digitalização dos detectores. . . . 35

Figura 20 – Página para definição dos classificadores de coincidências. . . 36

Figura 21 – Página para definição de cadeia de coincidências. . . 36

Figura 22 – Página para definição do tipo e conte údo dos resultados da simulação. . 37

Figura 23 – P´agina para download dos resultados. . . 37

Figura 24 – Simulação de um microPET FOCUS 220 usando o GATE, através de macros criadas pela WebGUIGATE. . . 38

(9)

Tabela 1 – Coeficientes de atenuação linear para o tecido mole, osso, óxido de bismuto-germânio (BGO), chumbo e tungstênio em 511 keV. . . 13 Tabela 2 – Comparação estat´ıstica de parâmetros da simulação proposta usando

scripts escritos manualmente (GATE) e scripts escritos automaticamente (WebGUIGATE). . . 38

(10)

1 INTRODUC¸ ˜AO . . . 11

2 FUNDAMENTAÇ ÃO TE ÓRICA . . . 13

2.1 Tomografia por Emiss˜ao de P´ositron - PET . . . 13

2.1.1 Atenuação de Fótons . . . 13

2.1.2 Detectores . . . 14

2.1.3 Resolução de Temporização e Detecção de Coincidências . . . 16

2.1.4 Espalhamento de Fótons . . . 16 2.1.5 Resolução de Energia . . . 17 2.1.6 Tempo Morto . . . 18 2.2 GATE . . . 18 2.2.1 Geometria . . . 19 2.2.2 Geometria do Scanner . . . 20 2.2.3 Geometria do Fantoma . . . 20

2.2.4 Processos Eletromagnéticos Envolvidos na Simulação GATE . . . 20

2.2.5 M´odulo Digitizer . . . 20

2.2.6 Fontes . . . 22

2.2.7 Sa´ıda de Dados . . . 22

2.3 IHC - Interface Humano Computador . . . 22

2.4 Porquê Django? . . . 23 2.5 JQuery . . . 23 2.6 CSS . . . 23 2.7 GitHub . . . 23 2.8 HTML . . . 24 3 METODOLOGIA . . . 25 3.1 Metodologia de Desenvolvimento . . . 25 3.1.1 A GUIGATEClass . . . 25 3.1.2 Templates . . . 26 3.1.3 Dinâmica da Aplicação . . . 27 3.1.4 Estilização . . . 27 3.2 Metodologia de Funcionamento . . . 27 3.2.1 A WebGUIGATE . . . 27 3.2.2 General Settings . . . 27 3.2.3 Scanner . . . 28 3.2.4 Phantom . . . 28

(11)

3.2.7 Digitizer . . . 30 3.2.8 Output . . . 30 4 RESULTADOS . . . 31 4.1 WebGUIGATE . . . 31 4.1.1 General Settings . . . 31 4.1.2 Scanner . . . 31 4.1.3 Phantom . . . 32 4.1.4 Physics . . . 33 4.1.5 Source . . . 34 4.1.6 Digitizer . . . 35 4.1.7 Outputs . . . 36 4.1.8 Download . . . 37 4.2 Validação . . . 37 4.3 Dificuldades . . . 39 5 CONCLUS ÕES . . . 40 6 PERSPECTIVAS . . . 41 REFER ÊNCIAS . . . 42

AP ÊNDICE A – SIMULAÇ ÃO DO MICROPET FOCUS 220 . . . 44

AP ÊNDICE B – ALGORITMO DE REDUÇ ÃO DE VARI ÁVEIS DE UM SCANNER PET CILÍNDRICO . . . 51

(12)

1 INTRODUC

¸ ˜

AO

Tomografia por Emissão de Pósitron (PET - Positron Emission Tomography) tem permitido o avanço da medicina nuclear moderna, a partir de aquisições de imagens funcionais, avaliando do metabolismo celular. Sendo amplamente aplicado nos diagnósticos em cardiologia, neurologia e oncologia, devido aos resultados em aquisições de imagens locais e de corpo inteiro (LJUNGBERG; STRAND; KING, 2012). Por efeito da utilização desta tecnologia, os sistemas PET são simulados através dos métodos Monte Carlo (MC), quer seja em avaliações pré-cl´ınicas, quer seja em controle da qualidade.

Fatores f´ısicos como eficiência dos detectores e colimadores, eventos não colineares e aleatórios, configuração do scanner e reconstrução de imagem, podem ser simulados. Para isto a comunidade de medicina nuclear conta com os códigos MC de uso geral, entre eles o GEANT4 (GEometry ANd Tracking), escrito em liguagem de programação C++ e desenvolvido pelo CERN (Conseil Européen pour la Recherche Nucléaire), realiza simulações de transporte de part´ıculas em qualquer material (ZAIDI, 2006). E o software GATE (Geant4 Application for Emission Tomography) baseado no GEANT4 e desenvolvido pela OpenGATE (OPENGATE, 2002), suporta simulações de tomografia por emissão, entre eles o PET scan, e radioterapia, porém utiliza scripts em sua linguagem.

No entanto, é exigida do usuário, habilidade no processo de instalação e, no caso do GEANT4, em linguagem de programação C++. Em adição, a instalação do GATE e a inserção dos dados necessários na forma de scripts apresentam certo grau de complexidade, dificultando seu uso em maior escala devido à sua curva de aprendizado.

Para solucionar este problema, foi constru´ıda uma interface desktop chamada GUIGATE (VIEIRA, 2013). O software GUIGATE foi criado utilizando linguagem Python obtendo sucesso em seus objetivos, contudo, a GUIGATE ainda apresentava dificuldades referentes à sua instalação, sendo necessário uma significativa quantidade de pré-requisitos como: instalação do GEANT4, GATE, ROOT e bibliotecas Python. Em adição, era altamente recomedado a utilização do sistema operacional Linux, restrigindo ainda mais seu público alvo.

Um exemplo que resolveu um problema semelhante, é o software CALDose X (CALculation of Dose for x-ray diagnosis) (KRAMER; KHOURY; VIEIRA, 2008) que possui um extensão chamada de CALDose X online permitindo o cálculo de dose absorvida em órgãos e tecidos, no diagnóstico de raios-X, para pacientes com diferentes massas corporais, alturas e posturas. Esta extensão online não contém problemas referentes à compatibilidade com sistemas operacionais ou necessidade de pré-requesitos, sendo necessário apenas um computador com internet. No intuido de adquirir as vantagens semanhantes às do CALDose X online, o objetivo deste projeto é desenvolver uma aplicação web, robusta e amigável, que integre em um único ambiente a possibilidade de realizar simulações de equipamentos PET, quer seja scanner de uso cl´ınico quer seja de uso em pesquisa, resolvendo todos os problemas

(13)

de compatibilidade e sem a necessidade de instalação de pré-requesitos, podendo ser utilizado a partir de qualquer dispositivo com acesso à internet e um navegador. Para isto, o Django, framework de alto n´ıvel Python para web, será utilizado, assim como, outras linguagens de programação utilizadas para construção de websites como HTML, CSS e JavaScript.

Como estudo de caso, o microPET FOCUS 220 (SIEMENS) (JAN et al., 2005) será simulado na aplicação web a ser desenvolvida, usando a versão do GATE (v7.0). Este trabalho se aplicará nas áreas de instrumentação PET, mostrando-se potencialmente útil para avaliar, por exemplo, estudos pré-cl´ınicos e testes de controle da qualidade baseados no NEMA (National Electrical Manufacturers Association).

(14)

2 FUNDAMENTAC

¸ ˜

AO TE ´

ORICA

2.1 Tomografia por Emiss˜

ao de P´

ositron - PET

Exames PET são baseados na detecção de coincidências de dois fótons de 511 keV, estes emitidos pela aniquilação do pósitron (β+ - antipart´ıcula do elétron) com um elétron (e−) proveniente do tecido (SAHA, 2010). Os equipamentos PET fornecem imagens funcionais, isto é, imagens que revelam a atividade metabólica celular, de forma a quantificar a absorção de radionucl´ıdeo na região de interesse (ROI – Region Of Interest). A seguir, será abordada as principais caracter´ısticas, relacionadas à f´ısica, envolvidas no funcionamento de um sistema PET.

2.1.1 Atenua¸c˜ao de F´otons

De acordo com Hubbell, 1999, o espalhamento incoerente ou Compton é o principal mecanismo de interação para fótons de 511 keV. Como consequência deste fato, a part´ıcula primária muda de direção, isto é, é espalhada, e perde energia. Em adição, o átomo onde a alteração ocorreu é ionizado. (BAILEY et al., 2004).

Para uma fonte de fótons e detectores bem colimados, as absorções de fótons de 511 keV na matéria, podem ser descritas pela relação monoexponencial, mostrada na equação abaixo (BAILEY et al., 2004)

I(x, y, z) = I0e−µ(x,y,z)

Onde, I0 representa o fluxo de f´otons de 511 keV que incide o meio, I(x, y, z) ´e o fluxo de

fótons de 511 keV que passa sem interagir com o meio e µ(x, y, z) coeficiente de atenuação linear. A Tabela 1 abaixo exemplifica valores de coeficientes de atenuação linear de alguns materiais.

Tabela 1 – Coeficientes de atenuação linear para o tecido mole, osso, óxido de bismuto-germânio (BGO), chumbo e tungstênio em 511 keV.

µcompton(cm)−1 µf otoeletrico(cm)−1 µ (cm)−1 Valor m´edio da espessura(cm)

Tecido mole ∼ 0, 096 ∼ 0, 00002 ∼ 0, 096 7, 2 Osso _{∼ 0, 169} _{∼ 0, 001} _{∼ 0, 17} 4, 1 BGO _{∼ 0, 51} _{∼ 0, 40} _{∼ 0, 96} 0, 76 Chumbo _{∼ 0, 76} _{∼ 0, 89} _{∼ 1, 78} 0, 42 Tungstˆenio ∼ 1, 31 ∼ 1, 09 ∼ 2, 59 0, 29

Fonte: Adaptado de (TAI et al., 2001).

O coeficiente de atenuação linear indica a probabilidade, por unidade de comprimento, da ocorrência de uma interação. Em outras palavras, o coeficiente de atenuação linear reflete a soma das probabilidades, seja absorção pelo efeito fotoelétrico ou espalhamento pelo

(15)

espalhamento Compton. Em casos PET, a maior contribuição será no espalhamento Compton devido à faixa de energia dos fótons. Os fótons, que interagem com a matéria, emergem com uma energia menor que 511 keV e tem suas trajetórias alteradas, provocando um erro na localização da fonte. Logo, a função dos sistemas PET é detectar os fótons que não sofreram interação, necessitando assim de um detector que possua alta densidade, uma vez que, a probabilidade de ocorrência do efeito fotoelétrico é maior em materiais mais densos. Sendo assim, as interações fotoelétricas são prefer´ıveis no detector, haja vista que, resulta numa maior deposição local de energia, aumentando, portanto, a qualidade do sinal.

2.1.2 Detectores

As interacções da radiação ionizante com a matéria formam a base sobre a qual detectores de radiação são desenvolvidos. A ideia inerente destes detectores é medir a energia total depositada na passagem de fótons nos mesmos. Normalmente, detectores de radiação convertem a energia depositada em um sinal elétrico ou carga mensurável. A integral deste sinal é então proporcional ao total da energia depositada no detector pela radiação. Para a radiação incidente monoenergética, nos casos PET, haverão variações devidas ao espectro de energia, logo, variações na carga total apresentada no detector também irá variar. As grandes variações representam deposição incompleta de energia pela radiação incidente. Por exemplo, em PET alguns dos fótons incidentes de 511 keV podem sofrer um ou mais espalhamentos Compton, depositando uma parcela de sua energia e, em seguida, saindo do detector. Múltiplos espalhamentos Compton poderiam eventualmente levar à deposição de quase toda a energia do fóton, empurrando assim o evento para o fotopico do espectro de energia. A capacidade de medir com precisão a energia depositada é de suma importância para a maioria de seus usos. Esta precisão é caracterizado pela largura do fotopico no espectro de energia, e é referida como a resolução de energia do detector (BAILEY et al., 2004). A Figura 1 mostra um gráfico de um espectro de energia depositada por um detector.

Figura 1 – Gr´afico de um espectro de energia depositada por um detector.

(16)

Segundo Bailey, 2004, duas catedorias de detectores são usados em PET: tubos fotomultiplicadores e semiconditores baseados em fotodiodo. Tubos fotomultiplicadores representam a técnica mais antiga e mais confiável para medir e detectar baixos n´ıveis de luz de cintilação. Eles consistem de um compartimento de vácuo com uma camada fina de fotocátodo na janela de entrada. Um fóton de cintilação que entra deposita sua energia no fotocátodo e provoca a liberação de um fotoelétron. Os fotoelétrons são acelerados a um d´ınodo próximo devido à um campo elétrico aplicado, que possui um potencial positivo em relação ao fotocátodo. No momento do impacto com o d´ınodo, o elétron, com a sua energia aumentada, resulta na emissão de múltiplos elétrons secundários (Figura 2). O processo de aceleração e de emissão é, então, repetido por vários d´ınodos de potenciais crescentes, conduzindo a um ganho superior a um milhão no d´ınodo final (ânodo). Este alto ganho obtido a partir de um tubo fotomultiplicador leva a uma ótima relação sinal-ru´ıdo (SNR) para n´ıveis baixos de luz e é a principal razão para o sucesso e aplicação dos tubos fotomultiplicadores para uso em detectores de cintilação . A sua única desvantagem é a baixa eficiência no controle de emissão e escape de um fotoelétron a partir do cátodo, após a deposição de energia por um único fóton de cintilação. Esta propriedade é chamada a eficiência quântica (Quantum Efficiency - QE) do tubo fotomultiplicador e é tipicamente 25% para a maior parte dos tubos fotomultiplicadores.

Figura 2 – Esquema e diagrama de um tubo fotomultiplicador.

Fonte: Adaptado de (BAILEY et al., 2004)

Fotodiodos, por outro lado, são baseados em semicondutores que possuem uma elevada sensibilidade para detectar os fótons de cintilação de energia substancialmente mais baixos. Estes detectores são tipicamente na forma de diodos PIN (PIN refere-se às três zonas do diodo: do tipo P, intr´ınseco, do tipo N). A fabricação de um fotodiodo PIN envolve a derivação de um metal alcalino, tal como o l´ıtio, num semicondutor do tipo p, tal como sil´ıcio dopado. A cintilação de fótons incidentes produzem pares de elétron-lacuna no detector e um campo

(17)

elétrico aplicado neles resultam em um fluxo de carga que pode ser medido através de um circuito externo. Uma desvantagem significativa dos fotodiodos é o baixo SNR alcançado devido à presença de um fluxo de cargas termicamente ativadas e uma amplificação muito baixa do sinal intr´ınseco. Nos últimos anos, um novo tipo de fotod´ıodo, chamado de fotodiodo (APD -Avalanche -Avalanche Photo Diode), tem sido desenvolvido, que proporciona uma amplificação interna do sinal, melhorando assim o SNR.

2.1.3 Resolu¸cão de Temporiza¸cão e Deteçcão de Coincidências

A resolução do temporização de um detector PET descreve a incerteza nas caracter´ısticas de temporização de um detector de cintilação, devido a flutuações estat´ısticas. A resolução de temporização é importante porque envolve a detecção de dois fótons provenientes de um único evento coincidente. Uma vez que a resolução de temporização representa a variabilidade nos tempos de chegada do sinal para diferentes eventos, ele precisa ser devidamente contabilizados quando detecta eventos coincidentes. A Figura 3 mostra um esquema de dois detectores configurados para medirem fótons coincidentes sendo emitidos a partir de um ponto equidistante dos dois detectores.

Figura 3 – Esquema de detectores configurados para medirem f´otons coincidentes.

2.1.4 Espalhamento de F´otons

Um PET scan adquire três tipos de eventos de coincidência: verdadeira, aleatória e coincidências de espalhamento. Coincidências verdadeiras são emissões a partir de pontos de aniquilações que entram no detector sem sofrer quaisquer interações significativas dentro do campo de visão (FOV - Field Of Vision) da imagem. Coincidências aleatórias surgem devido à detecção acidental de dois eventos não relacionados dentro da janela de tempo de coincidência. Estas coincidências adicionam uma imagem de background e reduzem o contraste. E por

(18)

fim, coincidências de espalhamento são eventos verdadeiros de coincidência de pontos de aniquilação individuais, no entanto, um ou ambos os fótons sofreram espalhamento Compton dentro do FOV da imagem antes de entrar no detector. Uma vez que coincidências espalhamento levam a um erro de posicionamento das linhas de resposta, deturpam a verdadeira distribuição de atividade dentro do FOV, ou seja, piora o contraste da imagem.

Na Figura 4 o evento (1) mostra um evento coincidente onde um dos raios γ é espalhado, levando uma incoerência na linha de resposta (LOR - Line Of Response) (linha pontilhada) para a reconstrução da imagem. Os eventos (2) e (3) representam dois eventos independentes com apenas um fóton a ser detectado. Se eles ocorrem dentro da janela de tempo de coincidência, uma LOR incorreta é atribu´ıda (coincidência aleatória).

Figura 4 – Eventos de coincidˆencias aleat´orias e de espalhamento em PET scan.

2.1.5 Resolu¸c˜ao de Energia

A resolução de energia de um detector de radiação caracteriza a sua capacidade de distinguir radiação em diferentes energias. Em PET, uma boa resolução de energia é necessária para um detector, especialmente na formação de imagens espaciais em modo 3D, a fim de alcançar um bom contraste de imagem e reduzir as contagens de background na imagem. O Full width at half maximum (FWHM) é ilustrado na Figura 5, e é definido como a largura da distribuição a um n´ıvel que é apenas metade do máximo do pico. A resolução de energia do detector é convencionalmente definido como o FWHM dividido pela centróide do pico H0 (KNOLL,

(19)

Figura 5 – Definição da resolução de um detector. Para picos cuja forma é gaussiana com desvio padrão σ .

Fonte: Adaptado de (KNOLL, 2010)

2.1.6 Tempo Morto

O tempo morto é definido como a quantidade m´ınima de tempo em que um detector separa dois eventos, a fim de que eles sejam gravados como dois pulsos separados. Em outras palavras, o tempo necessário para um detector processar um sinal, neste intervalo de tempo outras interações serão perdidas num sistema de contagem. Essas “perdas” podem se tornar bastantes graves quando altas taxas de contagem são encontradas, e quaisquer medidas de contagem feitas sob estas condições devem incluir alguma correção para essas perdas.

Segundo Knoll, 2010, dois modelos de comportamento de sistemas de contagem do tempo morto tem sido usados: paralyzable e nonparalyzable. Num modelo nonparalyzable, como mostrado na Figura 6, assumi-se um tempo fixo τ para seguir cada evento verdadeiro que ocorre durante o “per´ıodo vivo”do detector. Eventos verdadeiros que ocorrem durante o tempo morto são perdidos e não têm qualquer efeito sobre o comportamento do detector. Neste caso, o detector nonparalyzable iria gravar quatro contagens de seis interações verdadeiras. Em contrapartida, num modelo paralyzable, o mesmo tempo morto τ é assumido para seguir cada um dos eventos verdadeiros que ocorrem durante o per´ıodo vivo do detector. Eventos verdadeiros que ocorrem durante o tempo morto, no entanto, embora ainda não contabilizados como contagens, estendem o tempo morto por um outro per´ıodo τ após o evento perdido. Na Figura 6, apenas três contagens são registadas de seis eventos verdadeiros.

2.2 GATE

O GATE é uma ferramenta computacional, de distribuição livre, para simulações numéricas utilizadas em aplicações médicas. Entre suas principais funcionalidades, o GATE permite simular sistemas PET, tomografia por emissão de fóton único (SPECT), tomografia computadorizada (CT) e aplicações em radioterapia.

(20)

Figura 6 – Ilustrac¸˜ao para dois modelos de comportamento do tempo morto em detectores PET.

Fonte: Adaptado de (KNOLL, 2010)

1. Definir a geometria do scanner1;

2. Definir a geometria do fantoma(neologismo da palavra inglesa phantom); 3. Estabelecer os processos f´ısicos envolvidos;

4. Iniciar a simulac¸˜ao;

5. Estabelecer o modelo do detector; 6. Estabelecer as fontes;

7. Especificar o formato de sa´ıda dos dados; 8. Iniciar a aquisic¸˜ao dos dados.

2.2.1 Geometria

A definição de uma geometria é um passo fundamental no planejamento de uma simulação, pois é através dela que o dispositivo de imagem e objeto a ser analisado são descritos. A geometria no GATE é baseada em volumes e cada volume é ligado em sequência seguindo uma estrutura hierárquica. Os volumes da geometria devem ser caracterizados por uma forma, dimensão, posição e de qual material é composto. O volume world é o único volume já definido no GATE, isto é, não necessita de “parentesco”. Todos os outros volumes devem ser definidos como “filhos” de outro volume, anteriormente definido. O volume world consiste em um paralelep´ıpedo centrado na origem do sistema de coordenadas cartesianas, e tem dimensões definidas pelo usuário. O rastreamento de qualquer part´ıcula pára caso atravesse as dimensões do volume world (GUIDE, 2014). A lista de materiais dispon´ıveis é definida no arquivo

1 _{Visando à manutenção das palavras-chaves utilizadas no GATE, algumas expressões são mantidas na l´ıngua}

(21)

chamado GateMaterials.db que deve ser importado na simulação. Também é poss´ıvel transladar e rotacionar os volumes, todavia, deve-se atentar para não ultrapassar os limites do volume world.

2.2.2 Geometria do Scanner

Antes de definir a geometria do scanner, o usuário tem a opção de visualizar sua construção. Para isto, deve ser usada uma interface gráfica OpenGL proveniente do GEANT4 para visualização online, através de scripts de comando. O scanner deve ser inserido como volume filho do world. Neste momento o usuário deve definir o tipo de scanner (e suas dimensões) a ser simulado, como por exemplo, o cylindricalPET. No GATE, outros tipos de scanner podem ser modelados como, Scanner, CTscanner, cylindricalPET, Ecat, ecatAccel, OPET, SPECTHead e OpticalSystem. No scanner são acoplados volumes que serão compostos por outros volumes chamados, rsector, modules, submodules, crystal e layer (GUIDE, 2014).

2.2.3 Geometria do Fantoma

Para a construção do fantoma no GATE, o usuário utiliza o mesmo princ´ıpio da construção do scanner. O fantoma também deve ser definido como filho do world. O usuário deve definir a forma, a dimensão, a posição e qual material é composto. É poss´ıvel recuperar as interações dos efeitos Compton e Rayleigh dentro do fantoma definindo um detector sens´ıvel associado ao volume do fantoma usando o comando phantomSD (GUIDE, 2014).

2.2.4 Processos Eletromagn´eticos Envolvidos na Simula¸c˜ao GATE

Os processos eletromagnéticos são usados para simular as interações eletromagnéticas das part´ıculas com a matéria. Estas interações são derivadas de pacotes do GEANT4 (GUIDE, 2014). Estes estão divididos em três modelos:

1. Standard para energias de 1 keV a 100 TeV; 2. Livermore para energias de 250 eV a 100 GeV;

3. PENELOPE (PEnetration and Energy LOss of Positron and Electrons) para energias de 250 eV a 1 GeV.

Os modelos Livermore e PENELOPE simulam espalhamento Rayleigh, diferentemente do Standard, onde este fen ômeno é desprezado devido à faixa de energia.

2.2.5 M´odulo Digitizer

Conforme o manual do GATE, o módulo digitizer é o processo de simular a resposta eletrônica de um detector em um scanner, realizando conversões das interações de fótons e

(22)

part´ıculas carregadas em contentores de energia, posição de detecção e coincidências. Para isso, porções da geometria do scanner são definidas como detectores sens´ıveis que registram as interações dentro dessas regiões.

Sensibilidade dos detectores é usada para armazenar a informação da interação da part´ıcula nos volumes, onde cada interação é chamada de hit. Dois tipos de volumes sens´ıveis são definidos no GATE: No cristal usando o comando crystalSD, responsável na detecção de hitsde interações dentro de porções do scanner; e no fantoma usando o camando phantomSD, responsável na detecção e contagem das interações de baixa energia.

O módulo digitizer simula um processo de detecção realista para construção de observáveis f´ısicos a partir dos hits. Os observáveis f´ısicos de cada detector são: a energia, determinado pela soma dos hits em cada detector e a posição, determinada pelo centróide da energia ponderada das diferentes posições dos hits (GUIDE, 2014). O digitizer, no GATE, consiste em uma cadeia de módulos de processamento que toma uma lista de hits dos detectores sens´ıveis e a transforma em um pulso, chamado de single.

O subm´odulo adder soma a energia depositada pelos hits para produzir um pulso, haja vista que, uma part´ıcula gera m´ultiplos hits ao entrar num detector sens´ıvel.

O submódulo readout adiciona os pulsos juntos num grupo de volumes sens´ıveis definidos pelo usuário. Isto produz um pulso contendo a energia total depositada no interior do grupo de volumes sens´ıveis. A posição deste pulso é definida como a mesma do pulso do adder que possui maior energia, adotando a pol´ıtica ”o vencedor leva tudo”, conforme mostrado na Figura 7.

Figura 7 – Esquema do m´odulo digitizer.

(23)

´

E poss´ıvel inserir outros parâmetros para sua modelagem como o Energy Blurring - que simula o borramento gaussiano do espectro de energia de um pulso depois da leitura do módulo Readout; o Crystal Blurring - geralmente útil para atribuir uma resolução de energia diferente para cada cristal no bloco detector, entre um valor máximo e m´ınimo; o Thresholder e o Upholder - que define a janela de energia; o Pile Up e o Dead Time - que modela o tempo-resposta dos detectores; o Memory Buffers - que modela a perda de dados devido a um sobrecarregamento de um buffer de memória, realizando uma leitura periódica, seguindo uma determinada frequência de leitura; o Coincidences Sorters - que define os classificadores de coincidência; e o Coincidences Chain - define uma cadeia de múltiplos processos, enriquecendo os dados de sa´ıda da simulação. E por fim, os pulsos são transformados em observáveis f´ısicos de um scanner, isto é, singles.

2.2.6 Fontes

Para introduzir uma fonte numa simulação GATE, o usuário precisa definir o tipo, entre eles voxelized, linacBeam, phaseSpace, PencilBeam, TPSPencilBeam ou GPS (General Particle Source), assim como parâmetros de ângulo, posição, energia e sua distribuição (GUIDE, 2014). O volume da fonte também pode ser definido. Outras distribuições de fontes podem ser usadas como. Point, Beam, Plane, Surface ou Volume. Caso a forma não seja definida, o GATE estabelece a forma Point como padrão.

2.2.7 Sa´ıda de Dados

A plataforma GATE oferece diversos formatos de sa´ıda de dados, entre eles: ASCII, Binários e ROOT. Este último armazena diversas variáveis referentes aos processos Coincidences, Hits e Singles. É necessário que o usuário defina no m´ınimo um formato de sa´ıda, haja vista que todos os formatos de sa´ıda no GATE estão inicialmente desabilitados.

2.3 IHC - Interface Humano Computador

Este trabalho, ao apresentar objetivos realacionados a criação de uma ferramenta computacional que será usada por pessoas, faz-se necessário um estudo da interação entre humanos e computadores, o IHC. Como a área preocupada com design, IHC é definido como a avaliação e a implementação de sistemas computacionais interativos para uso humano, e, ainda, com o estudo dos principais fenômenos subjacentes a eles (ROCHA; BARANAUSKAS, 2003). Dentre os elementos que garantem boa interface em computação, destacam-se as ferramentas funcionais, capazes de melhorar a segurança, a usabilidade e a utilidade dos sistemas computacionais. As interfaces para usuários humanos são produtos de trabalhos interdisciplinares, que agregam profissionais de campos distintos em torno do objetivo comum de aperfeiçoar a aprendizagem da funcionalidade dos sistemas.

(24)

Nos conceitos básicos do IHC, a denominação interface amigável ou interface agradável designa a interface capaz de disponibilizar est´ımulos visuais, como cores, formas, fontes, texturas e outros elementos, de forma equilibrada e harmônica, visando não saturar a visão nem sobrecarregar a capacidade de assimilação dos sujeitos diante do crescente fluxo informacional (BATISTA; PRODUÇ ÃO, 2003). Em se tratando da interface interativa, refere-se àquela que propicia ao indiv´ıduo controlar as atividades dos sistemas de computação, de forma fácil e ágil, e também de maneiras variadas, sem provocar erros no momento de uso.

2.4 Porquˆ

e Django?

Django é um framework que permite a construção rápida de aplicações web de alto desempenho e elegância utilizando linguagem Python (HOLOVATY; KAPLAN-MOSS, 2009); possui fácil comunicação com banco de dados; o Django dispõe de um servidor de desenvolvimento, recurso altamente recomendado para desenvolvedores web; recursos de debug eficientes para detecção de erros de implementação; as URLs (Uniform Resource Locator), endereço de rede de páginas web, se apresentam em um esquema simples, sem a necessidade de formas como: .php, .cgi, 0, 2097, 1-1-1928, 00, comumente vistos em URLs de páginas web. Logo, uma vez que o tempo é um fator importante para este trabalho, os recursos oferecidos pelo Django torna-o a opção mais viável para desenvolvimento web.

2.5 JQuery

JQuery é uma biblioteca JavaScript que possibilita a manipulação de elementos dos templates escritos em HTML. Eventos de mostrar ou ocultar parâmetros que poderão ser necessários ou desnecessários no momento da implementação estão definidos através das funções do Jquery.

2.6 CSS

CSS (Cascading Style Sheets) é uma liguagem de folhas de estilo utilizadas na definição da apresentação de templates HTML (SILVA, 2008). Esta linguagem é responsável pelo posicionamento, estilização de fontes e cores e principalmente na formatação de espessura, altura, bordas, entre outras caracter´ısticas dos elementos HTML, descritos na páginas web.

2.7 GitHub

GitHub é um Serviço de web hosting compartilhado para controle de versão de software. Esta ferramenta fornece planos comerciais e gratuitos para projetos de código aberto com a disponibilidade de criação de repositórios públicos e privados. Este recurso tem o intuito de gerenciar os códigos das versões deste projeto, visando o seu desenvolvimento e

(25)

aprimoramento, além de permitir poss´ıveis colaborações, pois o código estará num repositório do GitHub.

2.8 HTML

A Linguagem de Marcação de Hypertexto, ou simplesmente HTML, sigla abreviada do inglês (HyperText Markup Language), é uma linguagem utilizada para publicação de conteúdo na web (SILVA, 2008). Esta linguagem será utilizada para criar os templates das páginas web deste trabalho. Cada página possuirá seu template que irá conter seus formulários espec´ıficos, para preenchimento dos dados de entrada, em cada etapa da arquitetura de simulação.

(26)

3 METODOLOGIA

Nesta seção, a metodologia será dividida em duas partes: metodologia de desenvolvimento e funcionamento. A metodologia de desenvolvimento conterá as informações, em detalhes, dos recursos utilizados para construção da aplicação web, nomeada WebGUIGATE. Em adição, na metodologia de funcionamento conterá as informações de como a interface irá funcionar, detalhando os parâmetros de entrada a serem inseridos, como uma espécie de tutorial.

3.1 Metodologia de Desenvolvimento

Linguagem HTML e CSS, foram importantes, no que se refere à organização dos formulários que são responsáveis por receber os parâmetros de entrada inseridos pelo usuário. Através do JQuery, os eventos de mouse criados são respon´saveis por tornar a aplicação intuitiva, evitar erros de implementação e contribuir no entendimento do funcionamento de uma simulação usando o GATE, ou seja, ao utilizar a aplicação, o usuário compreenderá com facilidade a metodologia de funcionamento de uma simulação.

O esquema de contrução da WebGUIGATE está descrito na Figura 8. Utilizando o framework Django, foram criados os arquivos: views.py que recebem os dados de entrada coletados nos formulários; os arquivos forms.py onde estão definidos os formulários; e os arquivos models.py responsáveis por salvar as variáveis no banco de dados. Para cada tela da aplicação será criado um arquivo HTML nomeado index.html, localizados na pasta Templates. Através do Django, aplicativos foram criados de forma didática, seguindo a lógica da arquitetura de construção de uma simulação PET, apresentados na forma de páginas web, sendo elas: General Settings, Scanner, Physic, Phantom, Source, Digitizer e Outputs.

Mesmo com o recurso de criação de formulários via linguagem Python, usando a classe Forms do Django, a maioria dos formulários foram criados usando a linguagem HTML, uma vez que a classe Forms, da versão Django utilizada, não interage de forma satisfatória com as funções de animação do JQuery. Em adição, o único arquivo models.py constru´ıdo é o responsável pelo cadastro de usuários, nos outros casos, as variáveis serão salvas em arquivos de texto.

As definições das URLs estão presentes no arquivo chamado urls.py, que importa um módulo Python chamado URLconf (configuração de URL).

3.1.1 A GUIGATEClass

No desenvolvimento da classe principal, a GUIGATEClass, foi utilizada a liguagem de programação Python por ser muiltiplataforma e possuir uma sintaxe mais “limpa” e sucinta comparada a outras linguagens de programação conhecidas (HORSTMANN; NECAISE, 2013). A GUIGATEClass, possui as funções fundamentais para criação dos scripts, recebendo

(27)

Figura 8 – Esquema de construc¸˜ao da WebGUIGATE.

Fonte: Autor.

os parâmetros de entrada dos formulários intermediados por arquivos views.py, para criar arquivos de sa´ıda, as macros. As macros criadas são arquivos de texto que possuem extensão .mac. Estas contém os scripts que implementam as etapas de uma simulação de um PET, baseados no manual da versão 7.0 do GATE. A Figura 9 abaixo mostra um exemplo de um script, implementando um fantoma cil´ındrico simples.

Figura 9 – Script de um fantoma cil´ındrico simples.

Fonte: Adaptado de (GUIDE, 2014).

3.1.2 Templates

Como visto em 2.4, mesmo utilizando o framework Django, foi prefer´ıvel utilizar os recursos do HTML para construção de formulários, uma vez que sua interatividade em conjunto com os recursos do JQuery, respondem melhor aos objetivos deste trabalho, no que se refere aos efeitos dinâmicos dos elementos dos formulários que mudam sua apresentação, de acordo com a interação do usuário.

(28)

3.1.3 Dinˆamica da Aplica¸c˜ao

Este recurso foi utilizado para criar diversos eventos que, de alguma forma, irão direcionar o usuário no preenchimento correto dos dados de entrada. Com este recurso, poss´ıveis erros básicos de implementação ou na sequência lógica de construção dos scripts, serão evitados.

Por exemplo, na escolha da forma da fonte, item do formulário do aplicativo Source, o usuário tem as opções: Point, Beam, Plane, Surface e Volume. Se a opção Volume for escolhida, opções de volume serão apresentadas no p´roximo campo do formulário como: cylinder, box, sphere, parallelepiped e ellipsoid. Caso a opção Plane for escolhida, opções de planos serão apresentados, como: circle, annulus, ellipsoid2, square, or rectangle, e assim por diante.

Seguindo a mesma lógica, se o usuário escolhe a forma Volume e o tipo da forma cylinder, serão solicitados, no próximo campo do formulário, os parâmetros referentes à definição de um cilindro(raio da base e altura).

3.1.4 Estiliza¸c˜ao

As folhas de estilos das páginas encontram-se em arquivos nomeadas style.css (linguagem CSS) dentro dos diretórios de cada página da aplicação. Para a primeira versão, será utilizada uma estilização simples, uma vez que o foco estará no funcionamento da interface.

3.2 Metodologia de Funcionamento

3.2.1 A WebGUIGATE

Como dito anteriormente, a WebGUIGATE está dividida em sete aplicativos principais: General Settings, Scanner, Phantom, Physics, Source, Digitizer e Outputs, conforme mostrada na Figura 10. Cada aplicativo possui formulários para preenchimento dos dados de entrada. Assim que os dados forem submetidos, as funções definidas em cada arquivo views.py serão acionadas, que por sua vez, executarão as classes definidas na classe principal da aplicação, a GUIGATEClass.

3.2.2 General Settings

No aplicativo General Settings, o usuário definirá os parâmetros gerais de simulação: grau de verbosidade; tempo de simulação e número de fatias; gerador de números aleatórios; e definição dos parâmetros do volume world.

Grau de verbosidade: o aumento da verbosidade, acarretará no aumento do tamanho dos arquivos de sa´ıda da simulação, uma vez que, a verbosidade está ligada diretamente ao n´ıvel de detalhamento dos resultados. Tempo inicial, tempo final e número de cortes: neste campo, o usuário pode definir o in´ıcio e o fim da aquisição, assim como o número de cortes da simulação. Gerador de números aleatórios: o Ranlux64, o James Random e o Mersenne Twister estão

(29)

Figura 10 – Esquema de funcionamento da WebGUIGATE.

Fonte: Autor.

dispon´ıveis, sendo o Mersenne Twister o gerador padrão do GATE. Volume world: definição das dimensões do volume world que está definido como um paralelep´ıpedo.

3.2.3 Scanner

Neste ambiente, o usuário poderá modelar o seu scanner. Nesta versão, a aplicação está limitada apenas à modelagem de um único tipo de scanner, o cylindricalPET. Nesta tela, o formulário possui alguns parâmetros de entrada diferentes dos quais são exigidos pelo manual, uma vez que, um novo algoritmo de modelagem de scanner foi desenvolvido. No entanto, a quantidade de parâmetros solicitados é menor, comparado ao manual, facilitando sua implementação. O algoritmo mencionado está descrito em detalhes no Apêndice B. A Figura 11 apresenta as definições dos novos parâmetros de entrada.

Onde, CFOV é a distância entre o centro e um bloco do scanner; x, y e z as dimensões do cristal; PitchX (crystal) e PitchZ(crystal) a distância entre os centros de dois crystais vizinhos em seus respectivos eixos; PitchX (module) e PitchZ(module) a distância entre os centros de dois módulos vizinhos em seus respectivos eixos; e o NumberO f Heads a quantidade de blocos do scanner.

3.2.4 Phantom

Fantomas anal´ıticos, ideais para modelagem de fantomas NEMA (The Association of Electrical Equipment and Medical Imaging Manufacturers), podem ser implementados neste aplicativo. Formas como, cilindros, cubos, esferas, cones e elips´oides est˜ao dispon´ıveis. O

(30)

Figura 11 – Definição dos novos parâmetros para implementação do scanner.

Fonte: Adaptado de (VIEIRA et al., 2014).

usuário pode definir vários fantomas para criar formas mais complexas que atendam suas necessidades. Volumes em movimento também podem ser modelados, utilizando mudanças em sua posição e orientação a cada espaço de tempo, como: translação, rotação, orbitais e oscilações.

3.2.5 Physics

A versão 7.0 GATE traz uma grande mundança na definição dos processos eletromagnéticos numa simulação. Em versões anteriores, era necessário construir uma macro com todos os processos eletromagnéticos desejados. A partir da versão 7.0, é altamente recomendado que o usuário escolha um construtor de uma lista de processos f´ısicos (physic list builder). Para usar um construtor, o comando addPhyslicsList deve ser usado.

Esses physic list builders são módulos fornecidos pelo GEANT4 que contém os processos eletromagnéticos. Os physic list builders fornecidos são:

1. emstandard 2. emstandard opt1 3. emstandard opt2 4. emstandard opt3 5. emlivermore 6. emlivermore polar

(31)

7. empenelope

Cada construtor contém uma lista de processos f´ısicos que interagem objetivando resultados espec´ıficos, por exemplo, se o usuário tem interesse em alta precisão no rastreamento de elétrons, pósitros e ´ıons, utilizando baixa energia e sem a presença de campo magnético, ele deve optar pelo emlivermore. Mais detalhes sobre os physic list builders são encontrados na comunidade do GEANT4 (CERN, 2012).

3.2.6 Source

Nesta etapa, o usuário pode modelar uma ou mais fontes através da definição de parâmentros conforme descritos no manual do GATE. Tipo de part´ıcula emitida, valor da energia e sua distribuição, tempo de meia vida, atividade e tipo de emissão angular deverão ser informados pelo usuário. A fonte também poderá se apresentar na forma não pontual. Planos, superf´ıcies e volumes poderão ser definidos seguindo uma mecânica similar à definição de formas para os phantoms. É poss´ıvel anexar fontes à volumes em movimento para simular movimentos involuntários do paciente.

3.2.7 Digitizer

O módulo Digitizer é destinado à modelagem do detector. Parâmetros como janela de energia, resolução temporal, tempo morto e regras de coincidências, entre outros, estão dispon´ıveis através dos submódulos do Digitizer, como visto em 2.2.5. Um algoritmo escrito em JQuery está implementado neste aplicativo com o objetivo de guiar o usuário no preenchimento dos dados de entrada. Três templates foram criados para este aplicativo: Digitizer, coicidences sorter e coincidences chain tornando-o mais intuitivo, haja vista que esta etapa possui muitos parâmetros de entrada.

3.2.8 Output

E por fim, na tela Outputs, o usuário seleciona o tipo de sa´ıda de dados que resultará da simulação. Os formatos ASCII, binário e ROOT estão dispon´ıveis conforme visto em 2.2.7.

(32)

4 RESULTADOS

4.1 WebGUIGATE

Na página inicial, conforme Figura 12, a WebGUIGATE possui um sistema simples de cadastro, onde será solicitado nome de usuário, e-mail e senha. Após a realização do cadastro, o usuário poderá iniciar a implementação do seu sistema PET. A seguir serão apresentados os esquemas das páginas, suas funções e formulários de inserção de dados de entrada.

Figura 12 – P´agina inicial WebGUIGATE.

Fonte: Autor.

4.1.1 General Settings

Ao processar esta página, o GUIGATEClass cria uma macro principal, a MainMacro.mac, a macro que define o n´ıvel de verbosidade, a Verbose.mac e a macro de visualização, a Visualization.mac. A MainMacro.mac importa todas as macros e contém os parâmetros gerais da simulação, discutidos em 3.2.2. A Figura 13 exibe com detalhes os parâmetros de entrada do aplicativo General Settings.

4.1.2 Scanner

A macro Scanner.mac será criada pelo processamento da página Scanner. A Figura 14 exibe os parâmetros necessários para modelagem de um sitema PET, tipo cil´ındrico, conforme visto em 3.2.3.

(33)

Figura 13 – Página para definição de parâmetros gerais da simulação.

Fonte: Autor.

Figura 14 – P´agina para modelagem do scanner.

Fonte: Autor.

4.1.3 Phantom

Quando processada, esta p´agina cria a macro Phantom.mac, onde se define o(s) fantoma(s) modelado(s) pelo usu´ario. No campo, onde se define a forma do fantoma, foram adicionadas

(34)

funções do JQuery que interagem com a escolha da forma do fantoma, isto é, os parâmetros mudam de acordo com o forma escolhida, ver Figura 16, evitando poss´ıveis erros e/ou ausência de parâmentros fundamentais. A Figura 15 exibe os parâmetros de entrada do aplicativo Phantom.

Figura 15 – P´agina para modelagem do phantom.

Fonte: Autor.

Figura 16 – Interatividade dos campos em resposta às ações do usuário, no aplicativo Phantom.

Fonte: Autor.

4.1.4 Physics

Nesta página, a physic list builder deve ser definido, como visto em 3.2.5. O usuário têm a opção de definir as regiões de cortes (Cuts), que são responsáveis por definir uma região onde não haverá produção de part´ıculas secundárias; e os Maximun Step Size3 que limitam a distância entre duas interações em cada volume implementado. Assim que processado, este

3 _{Segundo o manual, as regi˜oes de Cuts e Maximun Step Size devem ser utilizados somente por usu´arios}

(35)

aplicativo cria a macro Physic.mac. A Figura 17 exibe os parˆametros de entrada do aplicativo Physic.

Figura 17 – Página para definição do physic list builder.

Fonte: Autor.

4.1.5 Source

Nesta página, os dados de entrada processados criam a macro Source.mac. Mais de uma fonte pode ser implementada. Em adição, fontes tipo backToback (fótons em sentidos opostos) e fastI124 (esquema de decaimento simplificada de um emissor beta não-puro de iodo-124 no qual pósitrons são emitidos, mas não nêutrons) descrito no manual do GATE (GUIDE, 2014) podem ser modelados. A Figura 18 exibe os parâmetros de entrada do aplicativo Source.

Figura 18 – P´agina para modelagem da fonte.

(36)

4.1.6 Digitizer

Nesta tela, os dados são processados criando a macro Digitizer.mac que irá modelar o comportamento dos detectores do scanner. Funções JQuery estão em diversos elementos do formulário. Um exemplo é o campo Energy Blurring, que pode seguir dois comportamentos diferentes: a lei do inverso do quadrado ou a lei linear. Para cada comportamento são solicitados seus respectivos parâmetros. A Figura 19 exibe os elementos da implementação do módulo Digitizer.

Figura 19 – Página para modelagem do método de digitalização dos detectores.

Fonte: Autor.

Caso o usuário queira definir os classificadores de coincidência, deverá marcar yes na pergunta “ Add Coincidences Sorter ? ” e uma página chamada Coincidences Sorter contendo um formulário espec´ıfico será aberta, conforme a Figura 20.

Da mesma forma, caso o usuário queira definir uma cadeia de coicidências, ele deve marcar yesna pergunta “ Add Coincidences Chain ? ” e uma página chamada Coincidences Chain será aberta para implementação, conforme Figura 21. Os scripts criados nas páginas Coincidences Sortere Coincidences Chain serão adicionadas à macro Digitizer.mac

(37)

Figura 20 – Página para definição dos classificadores de coincidências.

Fonte: Autor.

Figura 21 – Página para definição de cadeia de coincidências.

Fonte: Autor.

4.1.7 Outputs

Nesta estapa, o usuário deve definir os tipo de sáida de dados, como visto em 3.2.8. Caso nenhum tipo de sa´ıda de dados for marcado, o comando /gate/output/allowNoOutput será adicionado aos scripts de simulação uma vez que o GATE apresenta apresenta um erro, caso não seja definido o formato de sa´ıda de dados. A Figura 22 exibe os elementos da definição do Output.

A simulação poderá ser iniciada ao responder a opção yes em Run the simulation?. A WebGUIGATE aciona o GATE e carrega os scripts. Este trabalho está em andamento

(38)

exatamente nesta etapa.

Figura 22 – Página para definição do tipo e conte údo dos resultados da simulação.

Fonte: Autor.

4.1.8 Download

Uma tela extra foi criada para exibir os resultados gerados pela WebGUIGATE. Nesta tela, os scripts gerados em cada etapa poderão ser baixados imediatamente após o término da implementação dos parâmetros de entrada. A Figura 23 exibe os arquivos de sa´ıda para download.

Figura 23 – P´agina para download dos resultados.

Fonte: Autor.

4.2 Valida¸c˜

ao

Para realizar a validação foi realizada duas simulações do scanner de um microPET FOCUS 220, cujos parâmetros foram obtidos de (SILVA, 2010). A primeira simulação foi usado o método tradicional, escrevendo cada macro manualmente, e segunda de forma automática, através da aplicação WebGUIGATE que recebe apenas os parâmetros de entrada. As macros criada pela WebGUIGATE estão dispon´ıvel no Apêndice A deste trabalho.

A simulação do microPET FOCUS 220 foi realizada, implementando uma fonte de Flúor-18 esférica de 2 mm de raio e atividade de 10000 Bq centrada na origem do sistema de coordenadas,

(39)

inserida num fantoma anal´ıtico esférico de 2 cm de raio e sua composição definida como acr´ılico (PMMA), visualizado na Figura 24. A simulação foi realizada num tempo de aquisição de 240 s.

Figura 24 – Simulação de um microPET FOCUS 220 usando o GATE, através de macros criadas pela WebGUIGATE.

Fonte: Autor.

Nas MainMacro (macro principal responsável por importar as outras macros: scanner, phantom, physics, source, digitizer e outputs) de cada run foi adicionado um actor estat´ıstico - um script que extrai informações da simulação entre os quais: número de eventos, números de passos geométricos e f´ısicos e número de tracks. Abaixo, é mostrado os scripts usados para criação do actor:

1. /gate/actor/addActor SimulationStatisticActor MyActor 2. /gate/actor/MyActor/save MyOutput.txt

A Tabela 2 mostra alguns valores estat´ısticos das duas simulações, evidenciando uma diferença relativa menor que 0, 5 % para todas as variáveis em questão.

Tabela 2 – Comparação estat´ıstica de parâmetros da simulação proposta usando scripts escritos manualmente (GATE) e scripts escritos automaticamente (WebGUIGATE).

Manualmente (GATE) Automaticamente (WebGUIGATE) diferenc¸a relativa N´umero de eventos 2371988 2369237 0, 12%

Númetro de tracks 7423276 7408135 0, 20% Número de passos 35019903 34969275 0, 14% Número de passos f´ısicos 22311101 22267427 0, 20% Número de passos geométricos 12708802 12701848 0, 05%

(40)

4.3 Dificuldades

Uma das dificuldades encontradas neste projeto foi no momento de entrega dos resultados de simulação ao usuário. Após o término do preenchimento dos dados de entrada, o usuário pode iniciar a simulação de seu modelo implementado. Neste momento a aplicação importaria as macros criadas e abriria um agente externo, ou seja, o ambiente de operação do GATE, acionado dentro do terminal do sistema do servidor, onde as macros seriam carregadas. Assim que as macros fossem carregadas e a simulação inicializada, o código da WebGUIGATE iria exportar os resultados simulados. No entanto os resultados não estariam dispon´ıveis, pois o GATE ainda estaria processando, ocasionando um erro na hora do envio dos resultados ao usuário. Este problema foi resolvido utilizando o método wait(), da biblioteca sys do Python, que “espera”o GATE processar os resultados, interrompendo temporariamente o código da WebGUIGATE.

O tempo de simulação foi outro problema encontrado, uma vez que o mesmo varia de acordo com o n´ıvel de detalhes do scanner, do fantoma, número de histórias, physic list builder de precisão, hardware do servidor, entre outras variáveis, tornando inviável uma simulação instantânea. Formas para solução deste problema estão sendo estudas, entre elas, a criação de um banco de dados contendo os resultados de simulações dos equipamentos PET e fantomas mais utilizados, objetivando a entrega imediata dos resultados. Técnicas de interpolação para ajuste dos resultados aos parâmetros de entrada também estão sendo estudados. Tais soluções estão presentes nas perspectivas deste trabalho. Este problema foi parcialmente resolvido por meio de uma função, criada em linguagem Python, que realiza uma pré-simulação utilizando um tempo de aquisição mil vezes menor que o inserido pelo usuário, contabilizando o tempo e por fim multiplicando-o por mil. Dessa forma uma mensagem com o tempo estimado é impresso na tela download e ao fim da simulação, uma notificação, via e-mail, pode ser enviada ao usuário. Recentemente foi identificado um erro que provavelmente seja na instalação do GATE no computador simulado. Manualmente o GATE funciona normalmente (abrindo o terminal e executando-o na forma tradicional), entretanto, ao executá-lo através da WebGUIGATE um erro tipo bash é apresentado. Esse tipo de erro é proveniente das definições das variáveis de ambiente do sistema Linux, ou seja, a WebGUIGATE não reconhece o diretório do executável do GATE, todavia, a instalação do GATE foi corretamente realizada utilizando o procedimento de instalação do seu manual. Formas de resolver este problema, estão sendo pesquisadas na comunidade do GATE.

Outra dificuldade está na implantação da aplicação na web. Além de um dom´ınio, é necessario um servidor com um grande espaço de armazenamento para alocar os resultados de simulação, logo, envolvendo um grande custo financeiro. O GDN (Grupo de Dosimetria Numérica) adquiriu, recentemente, um servidor e o disponibilizou para a viabilização deste trabalho.

(41)

5 CONCLUS ˜

OES

A WebGUIGATE realizou com êxito a criação dos scripts para a simulação do microPET FOCUS 220 apresentando uma diferença relativa menor que 0.5 % na quantidade de eventos detectados. Esta diferença é facilmente explicada, uma vez que os métodos MC, dentro do GEANT4, utilizam geradores de números aleatórios.

As etapas de implementação seguem uma lógica da arquitetura de simulação PET, contida no manual do GATE, apresentando-se de forma intuitiva, ou seja, acelerando o aprendizado da linguagem de scripts para realizações de simulações usando o GATE. Esta didática, é de grande importância para pesquisadores que estão iniciando trabalhos de simulação.

A dinâmica das telas evitam erros fundamentais de implementação como erros de digitação e equ´ıvocos nas unidades de medidas, comumente encontrados no momento da criação dos scripts. Além de promover uma alta acessibilidade, por se tratar de uma aplicação web estando compat´ıvel com os navegadores mais populares e superando as dificuldades de instalação dos pré-requesitos de instalação do GATE como sistemas operacionais e pacotes adicionais.

O único pré-requesito para realizar uma simlução usando a WebGUIGATE é no preenchimento dos parâmetros de entrada nos formulários, consequentemente, um ganho considerável de tempo no processo de criação dos scripts é facilmente percebido. Ao utilizar WebGUIGATE, o usuário implementa seu PET scan de forma mais rápida e com a mesma eficiência, comparado à implementação tradicional escrita manualmente.

o algoritmo criado para reduzir a quantidade de parâmetros de entrada para implementação do scanner, mostrou-se eficaz para câmeras PET do tipo cil´ındricas, reduzindo a quantidade variáveis e gerando a mesma macro do scanner implementado manualmente. A possibilidade de implementação de outros tipo de câmeras PET está listada nas perspectivas deste trabalho.

Diversos fantomas do tipo anal´ıtico estão dispon´ıveis para implemetação. A possibilidade de implementar vários fantomas na mesma simulação oferece a criação de fantomas mais complexos, recurso importante para estudos e análises no controle da qualidade.

A etapa de modelagem dos detectores disponibiliza diversos parâmetros como, efeito quântico, tempo morto, janela de energia, janela de coincidências, simulação das perdas estat´ısticas e ru´ıdo eletrônico, entre outros citados em 3.2.7, oferece uma maior precisão nos resultados da simulação.

Portanto, nesta primeira versão, a WebGUIGATE suporta a implementação de modelos PET tipo cil´ındrico, assim como diversas formas de fantomas anal´ıticos, fontes tipo GPS, e detectores, obtendo as macros com os scripts como resultados que poderão ser baixados no final do preenchimento dos formulários, (na tela download) facilitando o processo de implementação.

(42)

6 PERSPECTIVAS

As perpectivas para este trabalho est˜ao relacionadas abaixo:

1. Implementação para outros tipos de PET scan, além do cylindricalPET; 2. Implementação de fantomas voxelizados;

3. Implementação de outros tipo de fontes, além do GPS; 4. Implementação de fontes voxelizadas;

5. Implementac¸˜ao de volumes em movimento; 6. Leitura e tratamento de arquivos ROOT;

7. Utilização de clusters para maior velocidade nas simulações;

8. Criação de um algoritmo praticável que realize o envio dos resultados de simulação; 9. Criação de banco de dados de simulações dos PET scanners mais utilizados;

10. Modelagens de outros equipamentos como SPECT, CT e h´ıbridos, ex: PET/MRI; 11. Avaliar dose em simulac¸˜oes de radioterapia;

12. Melhoria do design da aplicação, sistema de cadastro de usuários; 13. Criação de um help com tutorial de utilização;

(43)

REFER ˆ

ENCIAS

BAILEY, D.; TOWNSEND, D.; VALK, P.; MAISEY, M. Positron Emission Tomography: Basic Sciences. [S.l.]: Springer London, 2004. ISBN 9781852334857.

BATISTA, C.; PRODUÇ ÃO, U. F. de Santa Catarina. Programa de Pós-Graduação em Engenharia de. Desenvolvimento de interface para ambiente hiperm´ıdia voltado ao ensino de geometria sob a ótica da ergonomia e do design gráfico. [S.l.]: Universidade Federal de Santa Catarina, Centro Tecnológico. Programa de Pós-Graduação em Engenharia de Produção., 2003.

CERN. Geant4 User’s Guide for Application Developers. Switzerland, 2012. Vers˜ao Geant4 9.6. Dispon´ıvel em: hhttp://cern.ch/geant4i. Acesso em: Marco 2015.

GUIDE, G. U. OpenGATECollaboration User’s Guide V7.0. 2. ed. http://wiki.opengatecollaboration.org/index.php/Users Guide V7.0, 2014.

HOLOVATY, A.; KAPLAN-MOSS, J. The Definitive Guide to Django: Web Development Done Right. Apress, 2009. (IT Pro). ISBN 9781430219378. Dispon´ıvel em: hhttps://books. google.com.br/books?id=h2tR8p-4a9QCi.

HORSTMANN, C. S.; NECAISE, R. D. Python for Everyone. 1st. ed. [S.l.]: Wiley Publishing, 2013. ISBN 1118626133, 9781118626139.

JAN, S.; DESBREE, A.; PAIN, F.; GUEZ, D.; COMTAT, C.; GURDEN, H.; KERHOAS, S.; LANIECE, P.; LEFEBVRE, F.; MASTRIPPOLITO, R.; TREBOSSEN, R. Monte Carlo simulation of the microPET FOCUS system for small rodents imaging applications. In: IEEE Nuclear Science Symposium Conference Record, 2005. [S.l.: s.n.], 2005. v. 3, p. 1653–1657. ISSN 1082-3654.

KNOLL, G. F. Radiation Detection and Measurement. 4th. ed. [S.l.]: Wiley, 2010. ISBN 9780470131480.

KRAMER, R.; KHOURY, H. J.; VIEIRA, J. W. Caldose x — a software tool for the assessment of organ and tissue absorbed doses, effective dose and cancer risks in diagnostic radiology. Physics in Medicine and Biology, v. 53, n. 22, p. 6437, 2008. Dispon´ıvel em: hhttp://stacks. iop.org/0031-9155/53/i=22/a=011i.

LJUNGBERG, M.; STRAND, S.; KING, M. Monte Carlo Calculations in Nuclear Medicine, Second Edition: Applications in Diagnostic Imaging. [S.l.]: Taylor & Francis, 2012. (Series in Medical Physics and Biomedical Engineering). ISBN 9781439841099.

OPENGATE, C. GATE: Simulations of Preclinical and Clinical Scans in Emission Tomography, Transmission Tomography and Radiation Therapy. 2002. Accessed: 2015-07-30. Dispon´ıvel em: hhttp://www.opengatecollaboration.org/i.

ROCHA, H. da; BARANAUSKAS, M. Design e avaliac¸˜ao de interfaces humano-computador. [S.l.]: Unicamp, 2003. ISBN 9788588833043.

SAHA, G. Basics of PET Imaging: Physics, Chemistry, and Regulations. Springer New York, 2010. ISBN 9781441908056. Dispon´ıvel em: hhttps://books.google.com.br/books?id=

(44)

SILVA, M. Criando Sites com HTML: Sites de Alta Qualidade com HTML e CSS. Novatec Editora, 2008. ISBN 9788575221662. Dispon´ıvel em: hhttps://books.google.com.br/books?id=

\ HBVQ-w5ZcoCi.

SILVA, S. Small Animal PET Imaging Using GATE Monte Carlo Simulations: Implementation of Physiological and Metabolic Information. Tese (Doutorado) — Departamento de F´ısica, Universidade de Lisboa, 2010.

TAI, Y. C.; CHATZIIOANNOU, A.; SIEGEL, S.; YOUNG, J.; NEWPORT, D.; GOBLE, R. N.; NUTT, R. E.; CHERRY, S. R. Performance evaluation of the microPET P4: a PET System Dedicated to Animal Imaging. Physics in Medicine and Biology, v. 46, n. 7, p. 1845, 2001. VIEIRA, I. F. Desenvolvimento de um Software para Modelagem de Tomógrafos por Emissão de Pósitrons. Dissertação (Mestrado) — Departamento de Energia Nuclear, Universidade Federal de Pernambuco, 2013.

VIEIRA, I. F.; KOOLE, M.; BONIFACIO, D. A. B.; CORDEIRO, L. P.; VIEIRA, J. W.; LIMA, F. R. D. A. GUIGATE: an User-Friendly Graphical Interface for PET Scanner Simulations Using GATE/GEAN4. In: European Association of Nuclear Medicine. [S.l.: s.n.], 2014. ZAIDI, H. Quantitative Analysis in Nuclear Medicine Imaging. [S.l.]: Springer US, 2006. ISBN 9780387254449.

(45)

AP ˆ

ENDICE A – SIMULAC

¸ ˜

AO DO MICROPET FOCUS 220

Como estudo de caso, o microPET FOCUS 220 foi simulado, utlizando as macros criadas pela WebGUIGATE, complementando a validação da aplicação. Para isso, são mostrados abaixo os scripts das macros criada pela ferramenta WebGUIGATE, por meio dos valores de referência obtidos de (SILVA, 2010).

#******************************* MAINMACRO ********************************** #========================================================================# # :) G U I - G A T E: A USER-FRIENDLY TOOLS FOR PET SCANNERs MODELS (:

#========================================================================# #******************************************************************************* # DISCLAIMER

#

# The author of this software system, nor their employing # institutes, nor the agencies providing financial support for this # work make any representation or warranty, express or implied, # regarding this software system or assume any liability for its use. #

# This code implementation is the intellectual property of the # Leanderson Cordeiro/Igor Vieira/Daniel Bonifacio, Brazil.

# (Contact: leoxofisicogmail.com/igoradiologiagmail.com/danielird.gov.br) # By copying, distributing or modifying the Program (or any work

# based on the Program) you indicate your acceptance of this # statement, and all its terms.

# ***************************************************************************** # V I Z U A L I Z A T I O N /vis/disable # V E R B O S I T Y /control/execute Verbose.mac # S C A N N E R /control/execute Scanner.mac # P H A N T O M /control/execute Phantom.mac

(46)

# P H Y S I C S /control/execute Physics.mac # I N I T I A L I Z E /gate/run/initialize # D I G I T I Z E R /control/execute Digitizer.mac # S O U R C E /control/execute Source.mac # O U T P U T /control/execute Output.mac # M E A S U R E M E N T S E T T I N G S /gate/application/setTimeStart 0. s /gate/application/setTimeStop 240. s /gate/application/setTimeSlice 240. s # R A N D O M /gate/random/setEngineName MersenneTwister /gate/application/startDAQ #****************************** VERBOSITY ********************************* /gate/verbose Physic 0 /gate/verbose SD 0 /gate/verbose Actor 0 /gate/verbose Cuts 0 /gate/verbose Step 0 /gate/verbose Error 0 /gate/verbose Warning 0 /gate/verbose Output 0 /gate/verbose Beam 0 /gate/verbose Volume 0 /gate/verbose Image 0 /gate/verbose Core 0 /run/verbose 0 /event/verbose 0