Como visto na Se¸c˜ao 4.1, os controles s˜ao respons´aveis pelo fluxo de execu¸c˜ao principal do MFree Framework. Eles s˜ao, na verdade, a interface entre o framework e a aplica¸c˜ao escrita pelo desenvolvedor. As Figuras 4.25 e 4.26 mostram os controles e os conceitos das traits que devem ser utilizadas.
4.15. Controles Controller +execute() #execute_method() #create_domain() <<virtual>>#create_local_distance() #create_support_domain() #create_shape_function() #create_integration() #create_formulation() #create_method() <<virtual>>#configure_geometry(domain: Traits::Domain*) <<virtual>>#configure_nodes(domain: Traits::Domain*) <<virtual>>#configure_support_domain(support_domain: Traits::Support_domain*) <<virtual>>#configure_shape_function(phi: Traits::Phi*) <<virtual>>#configure_integration(integration: Traits::Integration*) <<virtual>>#configure_formulation(formulation: Traits::Formulation*) <<virtual>>#configure_method(method: Traits::Method*) <<virtual>>#post_processing(method: Traits::Method*) Traits Controller_1 <<virtual>>#post_processing(method: Traits::Method*) Traits Controller_2 <<virtual>>#post_processing(method: Traits::Method*) Traits Controller_global_1 <<virtual>>+create_local_distance() <<virtual>>+configure_support_domain(support_domain: Traits::Support_domain*) <<virtual>>+configure_integration(integration: Traits::Integration*) Traits Controller_global_2 <<virtual>>+create_local_distance() <<virtual>>+configure_support_domain(support_domain: Traits::Support_domain*) <<virtual>>+configure_integration(integration: Traits::Integration*) Traits Controller_local_2 <<virtual>>+create_local_distance() <<virtual>>+configure_support_domain(support_domain: Traits::Support_domain*) <<virtual>>+configure_integration(integration: Traits::Integration*) Traits
Figura 4.25: Diagrama UML: Controles.
Para construir uma aplica¸c˜ao, o programador deve (1) criar uma classe traits que for- ne¸ca os tipos requeridos pelo controle, (2) criar uma classe derivada de um dos controles
ControllerTraits <<concept>> <<type>>+K <<type>>+Domain <<type>>+Support_domain <<type>>+Phi <<type>>+Integration <<type>>+Method <<type>>+Formulation ControllerGlobalTraits <<concept>> <<type>>+Local_distance_support ControllerLocalTraits <<concept>> <<type>>+Local_distance_support <<type>>+Local_distance_integration
Figura 4.26: Diagrama UML: Traits para controles.
existentes, (3) implementar os m´etodos abstratos§, configurando as caracter´ısticas do m´e-
todo sem malha de acordo com suas necessidades, e (4) efetuar uma chamada ao m´etodo
execute()do controle criado. Observe que execute() ´e o ponto de entrada para o fluxo
de controle determinado pelo framework.
A classe base para controles ´e Controller (Figura 4.25). Os m´etodos de Controller tˆem fun¸c˜ao de criar as estruturas de dados, configur´a-las, resolver o problema e executar o p´os-processamento. Existem dois tipos de controles: um destinado aos m´etodos de forma fraca global (Controller_global_1 e Controller_global_2) e outro aos de forma fraca local (Controller_local_2). No segundo caso, al´em de existir uma estrutura relacionada `as distˆancias locais utilizada pelo dom´ınio de suporte, existe outra para os dom´ınios de integra¸c˜ao, visto que esta ´e realizada por subdom´ınios locais.
A seguir, descrevem-se os passos do fluxo de controle do MFree Framework mostrados na Figura 4.2.
1. Cria¸c˜ao do Dom´ınio
Cria-se o dom´ınio do problema. Inicialmente, a geometria e as condi¸c˜oes de contorno s˜ao constru´ıdas. O processo de determina¸c˜ao da geometria e condi¸c˜oes de contorno ainda ´e feito por meio de c´odigo dentro da fun¸c˜ao configure_geometry(...). A ideia era que esse procedimento fosse usado apenas na fase inicial do desenvolvimento do framework para que se pudesse testar o correto funcionamento de problemas com diferentes tipos de geometria e condi¸c˜oes de contorno. Entrar com essas informa¸c˜oes via c´odigo n˜ao ´e adequado pois exige que o cliente codifique o problema e que a aplica¸c˜ao seja sempre recompilada. A melhor forma para isso ´e fornecer tais § M´etodos abstratos s˜ao m´etodos apenas declarados mas n˜ao implementados. Em C++, s˜ao denomina-
4.15. Controles informa¸c˜oes atrav´es de um arquivo externo, o que se pretende fazer em vers˜oes futuras do framework. Ap´os lidas geometria e condi¸c˜oes de contorno, criam-se os n´os por meio da fun¸c˜ao configure_nodes(...). Por padr˜ao, os n´os s˜ao lidos de um arquivo externo, conforme formato descrito em A.1.
2. Cria¸c˜ao das Distˆancias Locais
Criam-se as distˆancias locais relacionadas `as densidades de n´os em todo o dom´ınio. O framework faz os c´alculos, por meio da fun¸c˜ao create_local_distance(), a partir do tipo especificado em Traits.
3. Cria¸c˜ao do Dom´ınio de Suporte
Cria-se a estrutura para dom´ınio de suporte. Cabe ressaltar que os dom´ınios s˜ao calculados de fato durante o processo de montagem do sistema de equa¸c˜oes. O
framework faz a cria¸c˜ao da estrutura de dados automaticamente. Caso o progra-
mador deseje configurar algum parˆametro extra, deve fazˆe-lo por meio da fun¸c˜ao configure_support_domain(...).
4. Cria¸c˜ao da Integra¸c˜ao
Cria-se a estrutura de dados para integra¸c˜ao. O framework oferece uma imple- menta¸c˜ao padr˜ao. Caso o desenvolvedor deseje configurar a integra¸c˜ao de modo alternativo, deve redefinir a fun¸c˜ao configure_integration(...).
5. Cria¸c˜ao da Fun¸c˜ao de Forma
Nesse passo ´e criada a estrutura para constru¸c˜ao das fun¸c˜oes de forma. O progra- mador deve, obrigatoriamente, definir a fun¸c˜ao configure_shape_function(...), onde ´e configurada a estrutura de dados.
6. Cria¸c˜ao da Formula¸c˜ao
Cria-se a formula¸c˜ao. Caso necess´ario, a fun¸c˜ao configure_formulation(...) deve ser implementada para configurar algum parˆametro extra da formula¸c˜ao.
7. Cria¸c˜ao do M´etodo sem Malha
Cria-se o m´etodo sem malha. O procedimento ´e feito automaticamente pelo
framework. Uma configura¸c˜ao alternativa pode ser feita redefinindo o m´etodo
configure_method(...).
8. Execu¸c˜ao do M´etodo sem Malha
Nesse item, o problema ´e solucionado. Primeiramente, monta-se o sistema de equa- ¸c˜oes que, posteriormente, ´e resolvido. Essa etapa ´e totalmente automatizada.
9. Execu¸c˜ao do P´os-Processamento
Executa-se o p´os-processamento. Por padr˜ao, nesse passo ´e calculada a aproxima¸c˜ao da solu¸c˜ao nos pontos informados no arquivo externo descrito em A.3, e a solu¸c˜ao ´e gravada em um arquivo de formato A.5. O desenvolvedor pode, por ventura, redefinir a fun¸c˜ao post_processing(...) para executar os procedimentos de p´os- processamento que desejar.
Cap´ıtulo 5
Resultados
No cap´ıtulo 4 foi descrita a arquitetura do MFree Framework. Este cap´ıtulo traz algumas aplica¸c˜oes do framework a problemas eletrost´aticos e magnetost´aticos comuns em uma e duas dimens˜oes. Investiga-se os problemas da calha, do capacitor, do eletro´ım˜a e do campo magn´etico uniforme. Em alguns deles, h´a varia¸c˜oes de geometria, das condi¸c˜oes de contorno ou da constitui¸c˜ao dos materiais. Os resultados s˜ao comparados com a solu¸c˜ao anal´ıtica, quando dispon´ıvel, ou com a obtida utilizando o M´etodo dos Elementos Finitos com elementos triangulares de primeira ordem. Para visualiza¸c˜ao dos resultados, usou-se o software MATLAB [38] vers˜ao R2007b.
O intuito do cap´ıtulo n˜ao ´e discutir com profundidade a qualidade das solu¸c˜oes ou mesmo qual m´etodo aplicar a determinado problema de eletromagnetismo, mas sim ilustrar as op¸c˜oes e ferramentas dispon´ıveis no framework e verificar o seu correto fucionamento. Quando julgado apropriado, algumas considera¸c˜oes com respeito `as caracter´ısticas do m´e- todo ou da solu¸c˜ao s˜ao feitas, todavia de forma superficial, como ressaltado anteriormente.