Laboratório de Engenharia Virtual LEV - Caderno de ... · 4.5.1 Exercício I: ... Caderno de...

Laboratório de Engenharia Virtual

LEV - Caderno de Atividades

Relatório de andamento de trabalho

CA 2015/001 – Tutorial para resolução de problemas de otimização utilizando Framework de Otimização LOF-MH

Wakim Saba, Angelo Passaro, Carlos Alberto da Silva Junior, Nancy M. Abe

Palavra chave: Otimização Computacional, Meta-heurísticas, Framework, C/C++, XML, OOP, CodeBlocks.

Sumário

1 Objetivo .................................................................................................................. 2

2 Justificativa ............................................................................................................. 2

3 Datas....................................................................................................................... 2

4 Procedimentos ......................................................................................................... 3

4.1 Introdução ao pacote DirectModel – Estrutura e filosofia ............................................. 3

4.2 O ambiente de desenvolvimento para a implementação dos casos considerados neste tutorial 4

4.3 Implementação da máquina de cálculo - problema Sphere 2D ...................................... 7

4.4 Implementação da máquina de cálculo - problema Sphere 4D .................................... 16

4.5 Implementação da máquina de cálculo - problema Rosenbrock 2D............................. 19 4.5.1 Exercício I: ................................................................................................................................... 23

4.6 Implementação da máquina de cálculo - problema AMGM ......................................... 23 4.6.1 Exercício I: ................................................................................................................................... 26

4.7 Implementação da máquina de cálculo – Problema da Dieta ...................................... 27 4.7.1 Exercício I: ................................................................................................................................... 34 4.7.2 Exercício II: .................................................................................................................................. 34 4.7.3 Exercício III: ................................................................................................................................. 34

4.8 Implementação da máquina de cálculo – Problema p-medianas ................................. 35 4.8.1 Exercício I: ................................................................................................................................... 40 4.8.2 Exercício II: .................................................................................................................................. 41 4.8.3 Exercício III: ................................................................................................................................. 41

4.9 Implementação da máquina de cálculo – Acelerômetro micro-eletro-mecânico capacitivo 42

4.9.1 Exercício I: ................................................................................................................................... 50

5 Conclusões ............................................................................................................. 51

6 Referências ............................................................................................................ 51

2

Caderno de Atividades – Laboratório de Engenharia Virtual

1 Objetivo Apresentar um guia para implementações de máquinas de cálculo em um formato

compatível com o framework de otimização LOF-MH.

2 Justificativa Permitir a um usuário do LOF-MH elaborar o código necessário para definir funções

objetivo e aplicar restrições visando resolver um problema específico de otimização por meio de

meta-heurísticas implementadas no framework. Serão apresentados alguns casos exemplos, que

permitem o estudo de busca de mínimo local em funções de teste, a resolução de problemas simples

de otimização com restrições e um problema associado a uma dissertação de mestrado (L. L. Silva

2015). Para cada caso são apresentados detalhes do arquivo de configuração que permitirá ao LOF-

MH montar o ambiente requerido para o estudo de otimização.

Os resultados esperados em cada caso estão indicados, contudo, os resultados obtidos não

são discutidos neste tutorial. Para os interessados nessa análise, sugere-se que os resultados obtidos

sejam estudados em termos do número máximo de iterações definido no arquivo geral de

configuração.

3 Datas

Versão Autor(es) Descrição Data início Data término

V 1.0 Wakim Boulos Saba

/ Angelo Passaro

Versão inicial do documento 06/10/2016 13/10/2016

V 1.1 Wakim Boulos Saba

/ Angelo Passaro

Inclusão do problema p-medianas 15/10/2016 18/10/2016

V 1.2 Wakim Boulos

Saba/Angelo Passaro

Inclusão do problema de acelerômetro micro-eletro-mecânicao

capacitivo (publicada)

18/10/2016 05/11/2016

V 1.3 Wakim Boulos

Saba/Angelo Passaro

Inclusão do Algoritmo evolutivo para resolver o problema

Rosenbrock 2D. Inclusão do Exercício I nas sessões 4.5 e 4.6.

14/10/2016 16/11/2016

3


4 Procedimentos

4.1 Introdução ao pacote DirectModel – Estrutura e filosofia

O sistema LOF-MH é composto por um conjunto de classes que implementam diferentes

meta-heurísticas, visando sua utilização para encontrar valores extremos de um dado problema

(máximos ou mínimos). As meta-heurísticas são algoritmos genéricos que permitem a obtenção de

extremos não importando o problema considerado. Basicamente, são mecanismos de busca.

Para a resolução de um problema específico, a função objetivo deve ser definida, assim

como um conjunto de restrições que devem ser respeitadas. Cada problema específico apresenta sua

própria função objetivo e conjunto de restrições e deve ser implementado pelo usuário. Essa

implementação é realizada com base em um segundo conjunto de classes, associado ao pacote

denominado modelo direto.

O funcionamento do LOF-MH depende da interação entre os conjunto de classes de meta-

heurísticas do framework e das classes de métodos diretos. No caso de métodos populacionais, por

exemplo, são gerados um conjunto de indivíduos pelo LOF-MH. Cada indivíduo está associado a

uma solução tentativa cujo valor depende da evolução da meta-heurística.

Definida uma solução tentativa, o LOF-MH consulta a máquina de cálculo direto para

avaliar a qualidade do indivíduo em questão como solução adequada para o problema. A relação

entre o LOF-MH e as classes de cálculo direto é apresentada na Figura 1.

Figura 1 – Diagrama de classes do pacote DirectModel e o relacionamento com à interface Individual

4


A interface DirectModel define um conjunto de regras de implementação computacional

que devem ser respeitados sempre que se deseja construir uma máquina de cálculo nos moldes do

pacote modelo direto. O intuito dessas regras é facilitar as tarefas de implementação computacional

permitindo ao usuário deste tutorial concentrar-se ao máximo no modelo direto associado ao

problema específico estudado.

Tomando como o exemplo a classe SpecificDirectModel, Figura 1, toda máquina de

cálculo pertence ao pacote modelo direto por meio de um relacionamento de herança, definido pela

seta entre SpecificDirectModel e a interface DirectModel. Ao construir uma máquina de cálculo

que respeita essa forma o usuário deverá se preocupar apenas em utilizar um método que já recebe a

estrutura de dados, Individual, contendo todas as variáveis de projeto para escrever a lógica da

função objetivo e do conjunto de restrições associados ao seu problema.

O mecanismo de comunicação utilizado entre máquinas de cálculo e framework, estão

implementados na classe ExternalDirectModel e implícitos aos dois relacionamento que existem

entre Individual e DirectModel. Contudo esse mecanismo compõem um conjunto de

funcionalidades do projeto do framework que se apresentam de forma transparente ao usuário deste

tutorial sem que exista a necessidade de entendimentos mais detalhados.

4.2 O ambiente de desenvolvimento para a implementação dos casos considerados neste tutorial

Os exemplos deste tutorial foram escritos em linguagem de programação C/C++,

construídos por meio da ferramenta de desenvolvimento de software Code::Blocks (Team 2016),

versão 16.01 em ambiente sistema operacional Windows 8. O Code::Blocks é a ferramenta

necessária para realização dos passos deste tutorial e a versão portable deste aplicativo pode ser

baixada a partir de:

http://sourceforge.net/projects/codeblocks/files/Binaries/16.01/Windows/codeblocks-16.01mingw-

nosetup.zip

Depois de realizar o download do arquivo codeblocks-16.01mingw-nosetup.zip é

necessário escolher um local no disco rígido para descompacta-lo. Uma sugestão é criar uma pasta

com o nome codeblocks-16.01mingw-nosetup no drive C:\ e descompactar dentro dela todo o

conteúdo do arquivo codeblocks-16.01mingw-nosetup.zip. Para executar o Code::Blocks basta

um duplo clique no arquivo CbLauncher.exe que fica dentro do diretório codeblocks-

16.01mingw-nosetup, Figura 1.

5


Figura 2 – Conteúdo da pasta C:\ codeblocks-16.01mingw-nosetup\

Este tutorial utiliza o arquivo compactado DirectModel-app-example.zip que contém entre

outras coisas, um projeto de software com a implementação de uma máquina de cálculo no formato

reconhecido pela ferramenta Code::Blocks. Esse arquivo deve ser obtido a partir da página End

User subseção Downloads da documentação on-line oficial do projeto do framework, Figura 3.

Figura 3 – Página End User, sessão Downloads da documentação oficial do projeto LOF-MH.

6


No conteúdo do arquivo DirectModel-app-example.zip existem quatro pastas, lof-mh-lib-

directmodel, lof-mh-new-directmodel, lof-mh-test e others, Figura 4. A pasta lof-mh-lib-

directmodel contém um conjunto de arquivos de cabeçalho e um arquivo binário necessários para a

compilação adequada da máquina de cálculo. A pasta lof-mh-test contém o executável do

framework, lof-mh.exe, juntamente com um arquivo, GeneralConfiguration.xml, já configurado

segundo a conveniência de testes que devem ser realizados neste tutorial. A pasta lof-mh-new-

directmodel contém todos os arquivos e a estrutura de projeto de software reconhecidos pelo

Code::Blocks. A pasta others contém um exemplo de implementação de máquina de cálculo

também utilizada em outros capítulos deste tutorial.

Figura 4 – Conteúdo das pastas lof-mh-new-directmodel e lof-mh-test de DirectModel-app-example.zip.

No próximo passo o projeto da máquina de cálculo deve ser aberto utilizando o

Code::Blocks. Inicialmente deve-se abrir o aplicativo Code::Blocks executando o arquivo

CbLauncher.exe, Figura 2. Despois disso é necessário abrir o arquivo de projeto, lof-mh-lib-

directmodel-test.cbp, que se encontra dentro do diretório lof-mh-new-directmodel, Figura 4.

Na Figura 5 é apresentado a sequência de passos que devem ser realizados para que o

projeto lof-mh-lib-directmodel-test.cbp seja aberto no Code::Blocks. Para realizar o passo a passo

clique no menu File, item 1, e escolha a opção Open..., item 2, para que seja aberto a janela “Open

file”. Utilizando a arvore de diretórios do lado esquerdo da janela “Open file” encontre a pasta lof-

mh-new-directmodel, item 3. Selecione o arquivo lof-mh-lib-directmodel-test.cbp, item 4 e

pressione o botão Abrir, item 5. Ao termino desses itens o projeto de software deve ser apresentado

no Code::Blocks conforme ilustrado na Figura 7.

7


Figura 5 – Passo a passo para abrir o projeto lof-mh-new-directmodel.cbp no Code::blocks.

4.3 Implementação da máquina de cálculo - problema Sphere 2D Neste capitulo são apresentados os passos necessários para a construção de uma máquina de

cálculo visando obter o valor mínimo associado à função Sphere bidimensional. Para esse fim, será

escrita uma classe do tipo SpecificDirectModel.

A função Sphere para problemas com n dimensões é dada pela expressão abaixo e sua

representação gráfica é apresentada na Figura 6:

�(��, ��, … ��) =��

�

��

.

O domínio de estudo é [−100.0, 100.0]� sendo que, nesse domínio, a função possui valor

mínimo global de �(�∗) = 0.0 em �∗ = (0, 0,… , 0).

8


Figura 6 – Representação gráfica para a função Sphere de 2-dimensões

O projeto da máquina de cálculo apresentado na Figura 7 contém três arquivos de código

fonte escritos em C++ que podem ser encontrados no lado esquerdo da referida imagem. Os

arquivos ExampleDirectModel.cpp e ExampleDirectModel.h juntos constituem a implementação

de uma classe do tipo SpecificDirectModel que herda a classe generalizada DirectModel, Figura

1, Figura 8. O arquivo main.cpp contém a implementação necessária para definir o formato da

máquina de cálculo para o tipo executável e compatível com o protocolo de comunicação utilizado

pelo framework, Figura 8. O arquivo main.cpp é bastante simples, mas o usuário deve especificar

a classe associada ao problema de interesse (SpecificDirectModel) na posição indicada pelas

elipse. Neste exemplo, a mudança consiste de instanciar o modelo direto por meio da instrução new

SphereDirectModel().

Ao longo do tutorial serão mostradas as alterações necessárias no caso de outros problemas.

A máquina de cálculo apresentada na Figura 7 e Figura 8, implementa a função Sphere de

n dimensões no corpo da função Run() implementada no arquivo ExampleDirectModel.cpp. Essa

função é a que representa a função objetivo e as restrições específicas do problema. É nessa função

que se concentra o esforço de implementação do usuário.

A função Run() recebe por parâmetro o ponteiro para um objeto de dados do tipo

Individual, que contém entre outras coisas as variáveis de projeto. Nessa implementação a

quantidade de variáveis de projeto, ou quantidade de dimensões de sphere, é obtida a partir da

chamada da função individual->GetQuantityOfDecisionVariables(), linha 6. Entre as linhas 8 e

12 foi implementado um laço de repetições para obter o conteúdo de cada variável de projeto por

9


meio da chamada da função individual->GetDecisionVariable(i), onde i é o índice da variável.

Cada variável de projeto é elevada a 2º potência e o resultado é adicionado na variável dResult,

linha 11. Depois de calculado o valor da função objetivo esse valor deve ser atualizado no

individual por meio da chamada da função individual->SetObjetctiveFunctionValue(), linha 14.

A implementação de Run() é obrigatória para classes que herdam DirectModel, Figura 1.

Figura 7 – Projeto lof-mh-lib-directmodel-test.cbp.

Figura 8 – Arquivos ExampleDirectModel.cpp, ExampleDirectModel.h e main.cpp.

10


A implementação da máquina de cálculo Sphere foi escrita de forma generalizada, para

qualquer número n de dimensões (número de variáveis de projeto). A quantidade de variáveis de

projeto é definida no arquivo de entrada do framework GeneralConfiguration.xml, Figura 4. Ou

seja, alterar o número de variáveis de projeto não implica em alteração no código computacional.

GeneralConfiguration.xml contém a configuração geral do problema. Este arquivo já está

preparado para a execução do problema Sphere 2D e, portanto, nenhuma alteração é necessária em

seu conteúdo. Contudo, para efeito deste item do tutorial daremos atenção a três conjuntos de

informações contidas no arquivo, indicados na Figura 9, Figura 10 e Figura 11. Na Figura 9 é

realizada a configuração da máquina de cálculo lof-mh-lib-directmodel-test.exe cujo projeto e

código fonte também são fornecidos, Figura 7 e Figura 8. Na Figura 10 é feita a configuração das

variáveis de projeto. Para este caso foram configuradas duas variáveis de projeto, linhas 60, 61 e 62.

O valor atribuído ao atributo NoConstantQuantity, linha 60, em conjunto com as configurações das

duas linhas abaixo, 61 e 62, define a quantidade de variáveis de projeto. Nas linhas 61 e 62 foram

configurados os limites de valores máximo e mínimo que uma variável de projeto pode assumir por

meio dos atributos MaxValue e MinValue, o índice para cada variável por meio do atributo

Sequence, o nome da variável utilizando o atributo Name, entre outros. O conteúdo do atributo

Sequence corresponde ao índice i utilizado na função individual->GetDecisionVariable(i) para

obter o valor da i-ésima variável de projeto, linha 10 Figura 8. A Figura 11 apresenta as

configurações da meta-heurística. Na linha 125, o conteúdo 1 do atributo Activated indica ao

framework que a meta-heurística particle swarm deve ser utilizada. O conteúdo do tag <Iteration>,

linha 127, define o número máximo de interações, neste caso 10. A quantidade de partículas

utilizadas é definida na linha 139 onde foi atribuído o número 6.

Figura 9 –Configuração da máquina de cálculo.

11


Figura 10 –Configuração dos parâmetros de projeto para os domínio [100.0, -100.0].

Figura 11 – Configuração dos parâmetros da meta-heurística particle swarm.

Nos próximos passos deve ser realizada a compilação da máquina de cálculo utilizando o

Code::Blocks e posteriormente a execução do framework para resolver o problema da Sphere

configurado para 2 dimensões. O projeto de software está configurado com a opção Build target em

modo Release na ferramenta Code::Blocks, Figura 12, que portanto deve produzir o executável no

caminho esperado pelo arquivo de configuração, ver atributo SolutionFilePath na Figura 9.

Acione o comando Build\Build ou Ctrl+F9, Figura 12. O resultado esperado é apresentado

nos itens 3 e 4 da Figura 12, em que não existem ocorrências do tipo warning nem do tipo error,

item 3, e que o arquivo executável lof-mh-lib-directmodel-test.exe foi gerado, item 4.

12


Figura 12 – Instruções para compilação da máquina de cálculo.

Com a máquina de cálculo compilada e o arquivo lof-mh-lib-directmodel-test.exe criado, é

possível realizar um teste de otimização utilizando lof-mh.exe.

Pressione duplo clique com o botão esquerdo do mouse sobre o arquivo lof-mh.exe para

iniciar a execução da aplicação framework. Isso faz com que o framework inicie o mecanismo de

busca e utilize a máquina de cálculo recém criada para obter o valor de função objetivo do problema

Sphere para avaliar cada solução tentativa produzida pelo próprio framework. No início da

execução é realizada no interior da pasta lof-mh-test a criação da pasta

SphereDirectModel_2D_Project, que recebe o mesmo nome do conteúdo da tag <ProjectName>

utilizada para definir o nome do projeto no arquivo de configuração (linha 3, Figura 9). Dentro de

SphereDirectModel_2D_Project são criadas duas outras pastas, out e traces. Na pasta traces são

armazenados os arquivos de log do framework e dentro de out são armazenados arquivos de

resultados produzidos em tempo de execução. Na configuração padrão, os arquivos de trace, que

mantém registrado um conjunto de informações obtidas durante o processo de busca, não são

gerados. Para ligar um dos 6 níveis de trace no arquivo GeneralConfiguration.xml basta atribuir o

valor 1 no atributo Activated de um dos níveis desejados, Figura 13. Gerar os arquivos Trace

13


consome memória e aumenta o tempo de processamento. O que deve ser armazenado e a frequência

com que as informações são gravadas deve ser foco de atenção por parte do usuário.

Figura 13 – Configuração de desabilitado para todos os tipos de trace.

Ao termino da execução do framework é possível visualizar o console de ações realizadas

juntamente com o tempo consumido em segundos para cada uma delas, Figura 14. Neste exemplo

foram consumidos por volta de 100 segundos.

Figura 14 – Console de ações realizadas em uma execução do framework utilizando o particle swarm.

Na pasta out podem ser encontrados três tipos de arquivos que são identificados pelo tipo de

extensão utilizada. O prefixo do nome de cada um deles é o nome da meta-heurística utilizada pelo

framework, neste caso PARTICLESWARM. O arquivo com extensão txt é único e seu nome é

PARTICLESWARM_Evolution.txt. Neste arquivo é armazenado a cada iteração uma linha

contendo o registro do número da iteração, o melhor valor de função objetivo encontrado até o

momento, o número de cálculos de função objetivo realizados e o tempo consumido na iteração. O

segundo tipo de arquivo gerado apresenta a extensão dat. É gerado um arquivo por iteração e o

nome desse arquivo é composto pelo número da iteração na qual ele foi produzido. Na 5ª iteração

por exemplo seu nome é PARTICLESWARM_Iteration_00005.dat. O terceiro tipo de arquivo

utiliza extensão xml e também tem seu nome composto pelo número de iteração. Esse arquivo

armazena a lista de melhores soluções, Individuals, encontrados desde o início da execução da

meta-heurística. Na última iteração os dois arquivos com extensão dat e xml recebem apenas o

nome da meta-heurística utilizada pelo framework seguido de sua extensão.

14


Depois que o framework terminar a execução, a pasta out deve conter todos os arquivos txt,

dat e xml produzidos, Figura 15. Um exemplo de conteúdo dos arquivos gerados são apresentados

na Figura 16, Figura 17 e Figura 18:

arquivo PARTICLESWARM_Evolution.txt, Figura 16,

arquivo PARTICLESWARM_Iteration_00005.dat, Figura 17, e

arquivo PARTICLESWARM_Iteration_00005.xml, Figura 18.

É importante ressaltar que meta-heurísticas são métodos estocásticos e, portanto, não se

espera que duas execuções resultem exatamente nas mesmas respostas. Dessa forma, não se espera

que os resultados encontrados em cada um dos arquivo apresentados coincidam com os resultados

encontrados pelo usuário deste tutorial.

Figura 15 – Exemplo do conteúdo da pasta out depois que particle swarm terminou sua busca em 10 instruções.

15


Figura 16 – Exemplo do conteúdo do arquivo de convergência do framework para execução de particle swarm em 10 interações.

Figura 17 – Arquivo de dados brutos no formato ASCII contendo a lista de 6 partículas da iteração 5.

16


Figura 18 – Arquivo xml contendo as 6 melhores partículas encontradas até a 5º iteração.

4.4 Implementação da máquina de cálculo - problema Sphere 4D Neste capitulo são apresentados as configurações necessárias no arquivo de entrada do

framewok para utilizar a função Sphere com 4 dimensões.

Como a implementação da máquina de cálculo Sphere apresentada na Figura 4 foi escrita

de forma generalizada, então o executável utilizado no item 4.3 será aproveitado neste capitulo sem

alteração no código computacional.

17


Dessa forma, daremos atenção a três alterações pontuais que devem ser realizadas no

arquivo GeneralConfiguration.xml.

A primeira alteração consiste em adicionar duas outras variáveis de projeto para que a

configuração tenha quatro variáveis no total, Figura 19Erro! Fonte de referência não encontrada..

Note a importância de atribuir o conteúdo 4 ao atributo NoConstantQuantity e os números

sequenciais aos atributos Sequence associados a cada variável de projeto, linha 10 Figura 8.

Figura 19 – Configuração de 4 variáveis de projeto.

A segunda alteração deve ser realizada nos parâmetros da meta-heurística particle swarm,

Figura 20. Um dos objetivos é tornar o número de velocidades da meta-heurística compatível com

o número de variáveis de projeto do framework. Outra alteração é o aumento do número de

iterações e da quantidade de partículas utilizadas por particle swarm. Essa última alteração é uma

sugestão de aumento de esforço computacional em função do tamanho do problema, que agora tem

4 variáveis de projeto.

Figura 20 – Configuração das velocidades de 4 particulas da meta-heurística particle swarm.

18


A última configuração necessária consiste em alterar o nome do projeto para que o

framework crie uma nova estrutura de diretório onde deve gravar todos os arquivos de resultados,

Figura 21.

Figura 21 – Configuração do nome do projeto Sphere para 4 dimensões.

Depois dessas alterações realizadas no arquivo de configuração do framework pressione

duplo clique com o botão esquerdo do mouse sobre o arquivo lof-mh.exe para iniciar a execução da

aplicação framework. Ao termino da execução do framework pode-se obter os arquivos de

resultados no interior da pasta out que fica dentro da pasta recém criada

SphereDirectModel_4D_Project. Um exemplo do arquivo de convergência é apresentado na

Figura 22.

Figura 22 – Exemplo de arquivo de convergência para resolver Sphere2D com particle swarm em 30 interações .

19


4.5 Implementação da máquina de cálculo - problema Rosenbrock 2D Antes de realizar a implementação descrita neste capitulo, sugere-se a realização de

procedimentos de backup dos projetos de máquina de cálculo implementada em capítulos

anteriormente. Essa sugestão vale também para os próximos capítulos.

Neste exemplo é utilizada a meta-heurística evolutionary algorithm para resolver o problema

Rosenbrock 2D. Algoritmos evolutivos também são utilizados na resolução de difíceis problemas de

otimização (Back, Fogel e Michalewicz 1997) e neste trabalho é utilizada uma implementação que

suporta operadores para variáveis de projeto do tipo REAL (Yoon e Yong-Hyuk 2012). A função de

Rosenbrock é uma função �-dimensional, monomodal, cuja expressão é apresentada abaixo e sua

forma gráfica é ilustrada na Figura 23.

�(�) = �(��, ��, … , ��) = �[100(�� − ��)� + (�� − 1)�]

��

��

.

O domínio de estudo é [−30.0, 30.0]�, sendo que nesse domínio a função possui um único

valor mínimo global de �(�∗) = 0 em �∗ = (1, 1, … , 1).

Figura 23 – Representação gráfica para a função Rosenbrock de 2-dimensões.

As alterações de código são pontuais e devem ser realizadas nos três arquivos de código

fonte.

A primeira alteração deve ser a substituição do nome da classe para o novo nome que faça

mais sentido para o tipo de problema estudado, neste caso será utilizado o nome

20


RonsembrockDirectModel. As posições no código onde as alterações são necessárias estão

identificadas com elipse nos arquivos ExampleDirectModel.cpp, ExampleDirectModel.h e

main.cpp, Figura 24.

A função Run(), que contém os cálculos da função objetivo deve ser alterada para conter a

expressão matemática da função Rosenbrock. Essa alteração é apresentada na integra circundada

por um retângulo vermelho no interior da função Run() da nova máquina de cálculo, Figura 24.

Nas linhas 5, 6 e 7 são declaradas algumas variáveis que serão utilizadas no interior da função. Na

linha 9 à variável n é atribuído o valor associado a quantidade de variáveis de projetos

configuradas, neste caso o número 2. O laço de repetições for, apresentado entre as linhas 11 e 17,

é a representação computacional do símbolo somatória que existe na expressão Rosenbrock. Nas

linhas 13 e 14 são obtidos os valores das variáveis de projeto �� e �� respectivamente. Na linha

19, o valor calculado é atualizado como novo valor de função objetivo desse Individual.

Figura 24 – Arquivos ExampleDirectModel.cpp, ExampleDirectModel.h e main.cpp adaptados para a função

Rosenbrock.

Com o projeto aberto utilizando a ferramenta Code::Blocks acione o comando Build\Build

ou Ctrl+F9, conforme item 1 da Figura 12. Os resultados esperados são os mesmos já apresentado

nos itens 3 e 4 da Figura 12, onde não foram encontradas ocorrências do tipo warning nem do tipo

error na compilação e o arquivo executável lof-mh-lib-directmodel-test.exe foi gerado com

sucesso.

Antes de executar lof-mh.exe, deve-se alterar o arquivo de configuração do framework,

GeneralConfiguration.xml. A primeira alteração consiste em alterar para 2 o número de variável

de projetos. Essa alteração deve ser realizada nos parâmetros de projeto, Figura 25. A segunda

21


alteração consiste em configurar os parâmetros da meta-heurística. Deve ser utilizada a meta-

heurística Evolutionary Algorithm. Desabilite a meta-heurística particle swarm, e habilite a meta-

heurística evolutionary algorithm no arquivo de configuração, Figura 26. Os parâmetros da meta-

heurística evolutionary algorithm utilizados são apresentadas na Figura 27. Os parâmetros

indicados pela letra D são utilizados para definir os tamanhos das listas de indivíduos, que neste

caso são 40 para a população, 20 para os melhores e 6 para a lista elite. Os conjuntos de parâmetros

indicados pelas letras A, B e C, definem as configurações associadas à operações de recombinação,

operações de mutação e do tipo de seleção utilizados respectivamente. Neste caso, operadores de

recombinações do tipo CROSSOVER_BOX estão habilitados com taxa de 0.7 e os operadores de

mutação do tipo GAUSSIANDISTRIBUTION estão habilitados com taxa de 0.05. O operador de

seleção é do tipo RAFFLE. A última alteração no arquivo de configuração consiste em substituir o

nome do projeto atual para RosenbrockDirectModel_Project, Figura 28.

Figura 25 – Configuração das variáveis de projeto.

Figura 26 – Configuração para desabilitar particle swarm e habilitar Evolutionary Algorithm.

22


Figura 27 – Configuração dos parâmetros da meta-heurística evolutionary algorithm.

Figura 28 – Configuração do nome do projeto para o caso Rosenbrock.

Com as configurações devidamente alteradas deve-se novamente pressionar duplo clique

com o botão esquerdo do mouse sobre o arquivo lof-mh.exe para iniciar a execução da aplicação

framework. A Figura 29 ilustra um exemplo do arquivo de resultados

EVOLUTIONARYALGORITHM_Evolution.txt para esse tipo de execução.

23


Figura 29 – Exemplo do conteúdo do arquivo de convergência do framework para execução de evolutionary

algorithm para 30 interações.

4.5.1 Exercício I:

Realize o backup dos arquivos de resultado de seu interesse e execute novamente o

framework utilizando a meta-heurística particle swarm. Para isso desabilite a meta-heurística

evolutionary algorithm e habilite a meta-heurística particle swarm no arquivo de configuração do

framework, considerando os seguintes valores de parâmetros: a) regra de parada habilitada para 30

iterações; b) SwarmSize contendo 12 indivíduos; c) taxa de inércia, InitialRate, igual a 0.625; c)

constante de aprendizagem de grupo, ParticleLearningRate, e constante de aprendizagem da

partícula, ParticleLearningRate, iguais a 1.875, e d) duas velocidades com limites máximo e

mínimo dentro do intervalo 1 e -1. Execute lof-mh.exe e avalie os resultados. Compare os

resultados obtidos utilizado particle swarm com os resultados utilizando evolutionary algorithm?

4.6 Implementação da máquina de cálculo - problema AMGM

24


As alterações sugeridas neste capitulo visam alterar a máquina de cálculo de exemplo para

computar a função AMGM (Arithmetic Mean - Geometric Mean). AMGM é uma função �-

dimensional e possui infinitas soluções globais (todo ponto da forma �� = �� = ⋯ = �� é uma

solução do problema). Sua expressão matemática é dada abaixo e sua representação gráfica

bidimensional é apresentada na Figura 30.

�(�) = �(��, ��, … , ��) = �1

��

�

��

� − � � ��

�

��

�

�

�

e no domínio [0.0, 10.0]� a função possui valor mínimo global de �(�∗) = 0, sendo �∗

qualquer ponto da forma

�∗ = (��, ��, … , ��), �� = �� = ⋯ = ��.

Figura 30 – Representação gráfica para a função AMGM de 2-dimensões.

As mudanças de código necessárias na máquina de cálculo envolvem os arquivos

ExampleDirectModel.cpp, ExampleDirectModel.cpp e main.cpp e são pontuais como

apresentado na Figura 31. Basicamente, o nome da classe foi substituído para AmgmDirectModel

indicado por elipse, e a implementação da função objetivo corresponde a expressão matemática da

25


função AMGM, indicado por um retângulo. As alterações são similares às apresentadas no capitulo

4.5 e ilustradas na Figura 24.

Despois das alterações, utilizando a ferramenta Code::Blocks, acione o comando

Build\Build ou Ctrl+F9, conforme item 1 da Figura 12.

Desabilite qualquer meta-heurística que esteja habilitada no arquivo de configuração

mantendo apenas a meta-heurística particle swarm habilitada. Utilize as configurações apresentadas

na Figura 20, capitulo 4.4, exceto o número de variáveis que deve ser 2 apenas. O nome do projeto

foi alterado para AmgmDirectModel_Project, Figura 32. Os limites de batente de cada variável

de projeto foram alterados para respeitar o domínio da função AMGM.

Depois que as configurações estiverem atualizadas execute o lof-mh.exe.

Um exemplo da convergência de resultados é apresentado utilizando o arquivo

PARTICLESWARM_Evolution.txt, Figura 34. Neste caso a convergência para o ótimo global

ocorreu na iteração 3 da meta-heurística particle swarm.

Figura 31 – Arquivos ExampleDirectModel.cpp, ExampleDirectModel.h e main.cpp adaptados para a função

Amgm.

26


Figura 32 – Configuração do nome do projeto para o caso Amgm.

Figura 33 – Configuração das variáveis de projeto com limites de domínio [0.0,10.0].

Figura 34 – Exemplo de arquivo de convergência para resolver AMGM com particle swarm em 30 interações.

4.6.1 Exercício I:

Realize o backup dos arquivos de resultado de seu interesse e execute novamente o

framework utilizando a meta-heurística evolutionary algorithm. Para isso desabilite a meta-

heurística particle swarm e habilite a meta-heurística evolutionary algorithm no arquivo de

configuração do framework, considerando os seguintes valores de parâmetros: a) regra de parada

27


habilitada para 30 iterações; b) Tamanho da população Size de 20 indivíduos; c) Tamaho da lista de

melhores de 10 indivíduos; d) Tamanho da lista elite de 6 indivíduos; e) Operações de

recombinação do tipo CROSSOVER_LINE habilitada com taxa de recombinação igual a 0.70; f)

Operações de recombinação do tipo GAUSSIANDISTRIBUTION habilitada com taxa de mutação

igual a 0.05; c) Operador de seleção do tipo RAFFLE. Execute lof-mh.exe e avalie os resultados.

Compare os resultados obtidos utilizado particle swarm com os resultados utilizando evolutionary

algorithm?

4.7 Implementação da máquina de cálculo – Problema da Dieta Neste capitulo é apresentada uma implementação computacional do problema da Dieta

apresentado da forma clássica em (Namen e Bornstein 2004):

��

�

��

Sujeito à:

��

�

��

≥ �� = 1,2, … , �

�� ≥ 0 ��

onde:

{1,2, … , �} = conjunto de índices dos alimentos disponíveis para a formulação da dieta

�� = custo unitário do j-ésimo alimento

�� = quantidade do j-ésimo alimento presente na dieta

{1,2, … , �} = conjunto de índices dos nutrientes

�� = quantidade do i-ésimo nutriente em uma unidade do j-ésimo alimento

�� = quantidade mínima necessária do i-ésimo nutriente

Para criar uma instancia do problema da Dieta foram utilizados os valores sugeridos por

(Pinho 2012), apresentados neste documento na Tabela 1, Tabela 2,

Tabela 3 e na Figura 35. Na Tabela 1 e na Tabela 2 são apresentados um conjunto de

alimentos juntamente com a informação nutricional associada a cada um deles. Nessas tabelas

também é apresentada a informação da quantidade de cada porção de alimento e seu valor

28


correspondente em centavos de euros. Por exemplo, uma porção do alimento “leite”, cujo peso é

244g, é composta de 134.2 calorias, 8.784 gramas de proteínas, 2.44mg de Vitamina C e custa 12

centavos de euro, Tabela 1. A porção do alimento “pescada”, cujo peso é 150 g, é composta de

40.5mg de cálcio, 1.2mg de ferro, 2.55g de lipídios e custa 75 centavos de euro, Tabela 2. Na

Tabela 3 são apresentados alguns grupos e a lista de alimentos que os constitui. O grupo 1 é

composto dos alimentos “leite magro” e “Iogurte”, enquanto o grupo 6 é composto dos alimentos

“feijão” e “grão de bico”. Esse agrupamento de alimentos é utilizado para impor um conjunto de

restrições, onde é definida a quantidade mínima e máxima de porções de alimentos permitida por

grupo, Figura 35. Por exemplo, não é permitido uma solução que apresente uma quantidade de

porção inferior a 3 e superior a 5 para o grupo 3 de alimentos. Parra respeitar esse requisito,

soluções contendo 3 unidades de alface e 2 unidades de cenoura são aceitas enquanto que soluções

que apresentam 3 unidades de alface e 3 unidades de cenoura são penalizadas.

Tabela 1 – Lisa I de alimentos contendo informações nutricionais e de preço

Tabela nutricional com preço I

Alimentos

Leite magro

(1copo)

Iogurte Maça (1 unid.)

Laranjas (1 unid.)

Alface Cenoura (1 unid.)

Arroz Espaguete Batata Pão (1 unid.)

Variáveis x0 x1 x2 x3 x4 x5 x6 x7 x8 x9

Porção (g) 244 125 138 131 15 72 100 140 100 32

Energia (kcal) 134.2 77.5 84.18 115.28 2.7 30.24 360 491.4 80 100.16

Proteínas (g) 8.784 3.75 0.414 1.572 0.18 0.648 7.2 15.68 42 34.56

Cálcio (mg) 390.4 137.5 8.28 60.26 6 25.2 9 33.6 8 10.24

Fibra (g) 0 0 3.174 5.633 0.105 1.296 0.3 0.56 1.9 0.32

Vitamina C (mg) 2.44 1.25 8.28 78.6 1.8 4.32 0 0 16 0

Ferro (mg) 0.732 0.125 0.552 0.9825 0.24 0.576 1.4 2.52 0.9 0.576

Lipídios (g) 5856 4.25 0.414 0.262 0.03 0.252 0.6 0.924 0.1 0.576

Preço/Porção (€/100) 12 32 16 11 2 9 7 20 8 7

Tabela 2 – Lisa II de alimentos contendo informações nutricionais e de preço

Tabela nutricional com preço II

Alimentos

Atum Salsichas Ovos (1

unid.)

Fiambre Frango Pescada Feijão Grão de Bico Azeite Manteiga

Variáveis x10 x11 x12 x13 x14 x15 x16 x17 x18 x19

Porção (g) 85 100 50 15 150 150 80 80 13 20

Energia (kcal) 181.9 330 73 13 364.5 141 288 296.8 117 150.2

Proteínas (g) 20.4 16.8 5.7 0.17 27.45 29.25 16.16 16.4 0 0.2

Cálcio (mg) 7 10 27 0 15 40.5 380 120 0 3.8

29


Fibra (g) 0 0 0 0 0 0 5.6 3.2 0 0

Vitamina C (mg) 0 1 0 0 3 0 2.4 1.6 0 0

Ferro (mg) 1.598 2.5 1.25 0.135 2.7 1.2 9.52 5.6 0 0.4

Lipídios (g) 11.05 27.1 13.55 0 21.75 2.55 1.12 3.84 2.6 16.8

Preço/Porção (€/100) 69 14 182 12 29 75 0.6 6 34 9

Tabela 3 – Agrupamento por tipos de alimentos

Grupo de alimentos Grupo 1 Grupo 2 Grupo 3 Grupo 4 Grupo 5 Grupo 6 Grupo 7 Lacticínios Frutas Hortícolas Cereais,

Derivados e Tubérculos

Carne, Peixe e ovos

Leguminosas Óleos e Gorduras

Leite Magro Maçãs Alface Arroz Atum Feijão Azeite

Iogurtes Laranjas Cenoura Esparguete Salsicha Grão de bico Manteiga

Batata Ovos

Pão Fiambre

Frango

Pescada

Figura 35 – Quantidade de porções mínimas por grupo de alimentos.

Para esse exemplo são fornecidos dois arquivos, ExampleDirectModel.cpp e

GeneralConfiguration.xml obtidos a partir da pasta others/diet do arquivo DirectModel-app-

example.zip inicialmente fornecido, Figura 4. O arquivo DietDirectModel.cpp contém a

implementação computacional da função objetivo com restrições e o arquivo

GeneralConfiguration.xml contém todas as configurações necessárias para a execução do

framework utilizando a meta-heurística particle swarm para resolver o problema da dieta. O

primeiro passo é substituir os arquivos ExampleDirectModel.cpp e GeneralConfiguration.xml

30


localizados na pasta lof-mh-test pelos arquivos ExampleDirectModel.cpp e

GeneralConfiguration.xml fornecidos.

Nos arquivos ExampleDirectModel.h e main.cpp deve ser realizada a substituição do

nome da classe para DietDirectModel, conforme demarcado por elipses, Figura 36.

Figura 36 – Implementação dos arquivos main.cpp e ExampleDirectModel para o problema de dieta.

A implementação computacional de ExampleDirectModel.cpp é apresentada, Figura 37.

Nos itens 1, 2 e 3 são apresentados o vetor c de custos, a matriz n que relaciona o nutriente

associado a cada alimento e o vetor b que contém as valores de quantidades mínimas para cada

nutriente. A implementação das tabelas no corpo do programa exemplo foi adotada para simplificar

o exemplo. Em um problema real, as tabelas estariam armazenas em arquivos de dados e lidos pelo

programa. No item 4 é realizada a atribuição dos valores de cada variável de projeto em elementos

do vetor x. Cada elemento desse vetor corresponde à quantidade de porções de cada alimento. Por

exemplo, x0 = 2 significa 2 copos de leite magro. No item 5 é realizado o cálculo da função

objetivo e o valor obtido é atualizado no Individual. No laço de repetições entre as linhas 29 e 39 é

realizado o cálculo da quantidade de cada nutriente associado à quantia de cada alimento ��. A

quantidade de cada nutrientes calculada é gravada em uma variável do Individual, denominada

resultado solver, que possibilita gravar esses valores nos arquivos de resultado do framework, item

6. Os itens 7, 8 e 9 compõem a implementação de um conjunto de restrições que visam, ao termino

do processamento de Run(), item 9, indicar ao mecanismo de busca do framework o grau de

viabilidade(feasibility) de cada indivíduos. Valor de restrição igual a 0 indica indivíduo viável, caso

contrário indivíduo inviável sendo que quanto maior o valor da restrição menor a viabilidade do

indivíduo. A cada infração para as quantidades mínimas de nutrientes estabelecidas o individual

recebe uma adição de 10 restrições, item 7. A cada desrespeito para a quantidade mínima de

31


porções por grupo de alimento o individual recebe a adição de 1 restrição, item 8. No fim da

computação o valor de restrição é atualizado no Individual, item 9.

Figura 37 – Implementação computacional da função objetivo e restrições para um problema de dieta.

Despois das alterações, utilizando a ferramenta Code::Blocks, acione o comando

Build\Build ou Ctrl+F9, conforme item 1 da Figura 12.

As principais partes do arquivo de configuração fornecido, GeneralConfiguration.xml, são

apresentados, Figura 38 e Figura 39. Na Figura 38 são apresentadas as configurações de projeto.

Para cada uma das �� variáveis de projeto foi utilizado o nome do alimento especificamente, item 1.

Note também que não é permitido à uma variável de projeto assumir um valor maior, MaxValue, do

que o maior valor permitido pelo seu grupo, Figura 35. O conjunto de variáveis configuradas no

item 2 são denominadas de resultado do solver. O conteúdo dessas variáveis é preenchido pela

32


máquina de cálculo no momento que é computada a função objetivo. Essas variáveis são gravadas

juntamente com as variáveis de projetos nos arquivos de resultados do framework permitindo que

informações importantes obtidas durante o processo de busca não se percam. Neste caso foram

utilizadas sete variáveis para armazenar a quantidade de cada nutriente obtido para cada

configuração de alimentos encontrada. NaErro! Fonte de referência não encontrada. Figura 39 é

apresentada a configuração da meta-heurística particle swarm. O número máximo de iterações é

100 e a quantidade de velocidades corresponde a quantidade de variáveis de projeto, neste caso 20.

Figura 38 – Configuração das variáveis de projeto e de resultados para o problema de dieta.

33


Figura 39 – Configuração de meta-heurística para o problema de dieta.

Execute lof-mh.exe e acompanhe a produção de resultados na pasta lof-mh-test\out.

Neste tutorial são apresentados os exemplos de dois melhores indivíduos encontrados a

partir de duas execuções do framework utilizando o problema da dieta com as mesmas

configurações recomendadas neste capitulo, Figura 40. Os dois resultados convergiram para

valores de função objetivo próximos, sendo que no primeiro obteve-se aproximadamente 177

centavos de euro enquanto que no segundo caso obteve-se aproximadamente 189 centavos de euro.

O primeiro caso estão incluídos 2 iogurtes enquanto que no segundo caso esse item foi substituído

por 3 copos de leite magro. Para ambos os resultados aparece uma lista de indicadores como

Energia_Kcal, Proteina_g, entre outras. Essa lista de indicadores compõem a lista de resultados

solver que foram configurados no item 2 da Figura 38 e que são atualizadas a cada passagem pelo

item 6 da Figura 37.

34


Figura 40 – Melhores Individuos encontrados em duas execuções do framework para resolver o problema da

dieta.

4.7.1 Exercício I:

Faça uma alteração na implementação computacional para que Indivíduos com Energia

superior a 2300 calorias recebam uma restrição de 2 unidades. Realizada a alteração, execute o lof-

mh.exe novamente com o critério de parada por iteração configurado para 200 iterações. Há

diferença nos resultados?

4.7.2 Exercício II:

Crie uma nova variável de retorno do solver para armazenar o custo associado à quantia de

batata de cada indivíduo. Onde devem ser feitas as alterações (código e configuração) Execute lof-

mh.exe com o critério de parada por iteração configurado para 200 iterações.

4.7.3 Exercício III:

Insira uma nova opção de alimento chamada manteiga2 que deve ter exatamente o dobro de

concentração de nutrientes do alimento manteiga. Execute lof-mh.exe com o critério de parada por

iteração configurado para 100 iterações. Há diferença nos resultados?

Indivíduo 1 Indivíduo 2

35


4.8 Implementação da máquina de cálculo – Problema p-medianas Neste capitulo é apresentada a implementação computacional de uma máquina de cálculo

para um problema clássico de cobertura, o problema p-medianas. Diversas aplicações práticas do

problema p-medianas podem ser encontradas na literatura como, por exemplo, na localização de

escolas (Pizzolato, Barcelos, F.B. e Lorena, L.A.N 2002) e no posicionamento de antenas de

telecomunicação (Lorena e Pereira, M.A. 2002).

O problema p-medianas consiste em localizar p vértices de um grafo dado de N vértices, de

forma que os (N-p) vértices restantes sejam associados aos p vértices, escolhidos. Os p vértices são

denominados medianas. Esta associação é definida de forma que a soma das distâncias entre os

vértices e sua mediana escolhida seja mínima. A distância entre cada par de vértices é representada

por uma matriz simétrica denominada matriz de adjacência. No caso estudado a matriz de

adjacência contém as distâncias euclidianas entre os nós.

Formalmente, busca-se minimizar:

�� ∈��∈�

�

Sujeito à:

∑ ��∈� = 1;� ∈ � ,

∑ ��∈� = �,

�� ≤ ��;�, � ∈ � ,

�� ∈ {0,1};�, � ∈ � ,

onde:

� = {1,… , �}.

[��]�×� é uma matriz simétrica de distâncias com �� = 0, ∀ �∈ � .

[��]�×� é uma matriz de alocação com :

�� = 1 se o nó j é alocado à mediana i, e

36


�� = 1 se o nó i é uma mediana.

p é o número de medianas;

n é o número de nós.

Para esse caso são fornecidos os arquivos ExampleDirectModel.cpp e

ExampleDirectModel.h, já com a implementação da função objetivo e restrições, e o arquivo

GeneralConfiguration.xml, já com a configuração necessária para execução. Ambos estão

disponíveis na pasta others/pmedian do arquivo DirectModel-app-example.zip, Figura 4. O

leitor é incentivado a estudar com atenção a implementação fornecida e fazer paralelos com os

casos anteriores. Substitua o arquivo ExampleDirectModel.cpp de dentro da pasta lof-mh-new-

directmodel pelo arquivo ExampleDirectModel.cpp fornecido. Substitua o arquivo

GeneralConfiguration.xml localizado na pasta lof-mh-test pelo arquivo

GeneralConfiguration.xml fornecido.

O arquivo ExampleDirectModel.h fornecido já contém as alterações necessárias, mas o

arquivo main.cpp deve ser alterado, Figura 41. Observe que no arquivo ExampleDirectModel.h

que o nome da classe é PMedianDirectModel e as alterações para esse item estão indicadas com

elipses. No retângulo de cor vermelha entre as linhas 12 e 17 estão as declarações da variáveis

utilizadas para a implementação computacional do problema p-medianas. O outro retângulo contém

a definição do método Inicialization() que faz parte da implementação especifica deste problema.

A única alteração necessária no arquivo main.cpp é o nome da classe encontrada na linha 6 e

marcada com uma elipse. Altere o arquivo main.cpp conforme ilustrado na Figura 41.

Figura 41 – Arquivo main.cpp para o problema de p-medianas.

37


O arquivo ExampleDirectModel.cpp contém a implementação da função objetivo e do

conjunto de restrições associados ao problema p-medianas, Figura 42.

Nessa implementação foi construído o método Initialization() que contém um conjunto de

comandos de dimensionamento de variáveis. Basicamente Inicialization() define a quantidade de

vértices utilizados no problema, item 1, quais os valores para coordenadas x e y associada a cada

vértice, item 2, aloca uma quantidade de memória para a matriz d e o vetor x, itens 4 e 5

respectivamente, e atribui à cada elemento da matriz d a distância euclidiana associada a cada par

de vértices do problema calculada, item 5. Novamente, a opção de implementação dos pontos no

corpo da função visa apenas facilitar a execução do caso exemplo por parte do leitor. Numa

implementação mais geral, os pontos devem ser lidos de arquivos e os dimensionamentos devem ser

feitos em função dos dados externos.

O corpo da função Run() é apresentado no lado esquerdo da Figura 42. Run() executa a

função Initialization(), linha 5, e computa o valor de função objetivo e das restrições, retângulos

A, B e C. Dentro do retângulo A é utilizada o número de variáveis de projetos para definir o valor

de p. A parte inteira associada à cada variável de projeto, correspondente ao índice i de um vértice

escolhido como mediana, é atribuída à cada elemento do vetor x. O retângulo B contém a lógica de

cálculo da função objetivo e atualização do valor calculado no indivíduo. No retângulo C uma

restrição é adicionada ao indivíduo a cada repetição de índice encontrada.

38


Figura 42 – Implementação da função objetivo e restrições para resolver o p-medianas.

O arquivo GeneralConfiguration.xml fornecido foi configurado para resolver o problema

de 5 medianas. O nome do projeto foi alterado para PMedianDirectModel, Figura 43. Foram

configuradas 5 variáveis de projeto, cada uma correspondente à uma mediana, com intervalo de 0 a

19, Figura 44. A definição desse intervalo é importante para garantir que uma variável de projeto

não recebera um valor de índice fora do domínio de 20 vértices. A meta-heurística escolhida é

particle swarm que tem 5 velocidades configurados, Figura 45.

Figura 43 – Exemplo de resultado para um problema p-medianas de dimensões p=5 e n=20.



Compile o projeto utilizando o comando Build\Build ou Ctrl+F9, Figura 12, obtendo o

resultado esperado nos itens 3 e 4 da Figura 12 e pressione duplo clique em lof-mh.exe para

executar o framework.

39


Um exemplo de resultado para a solução do problema de p-medianas é apresentado no

formato de arquivo de saída do framework, Figura 46. A representação gráfica da solução,

construída a partir dos arquivos de resultados do lof-mh, é apresentada na Figura 47 (a

compreensão exige do leitor o entendimento do problema e a interpretação do arquivo de saída).

Neste exemplo o resultado tem valor de função objetivo igual à 96.6662 com os vértices 7, 3, 15, 6

e 12 escolhidos como medianas.



40


4.8.1 Exercício I:

Faça as mudanças necessárias no projeto da máquina de cálculo e no arquivo de

configuração do framework para que a quantidade de medianas seja p=2. É necessário realizar

mudanças no código fonte ou uma alteração no arquivo de configuração é o suficiente? Execute lof-

mh.exe com o critério de parada por iteração configurado para 100 iterações. Para esse exercício é

apresentado um exemplo de resultado, Figura 48, juntamente com a representação gráfica da

solução, Figura 49.



41


4.8.2 Exercício II:

Faça uma alteração na máquina de cálculo incluindo também os pontos {(5,5), (25,3),

(15,10), (35,35), (20,20), (10,40)}. Para esse caso, considere p=8. Execute lof-mh.exe com o

critério de parada por iteração configurado para 200 iterações.

4.8.3 Exercício III:

Considerando a conclusão do exercício II inclua uma restrição que penalize soluções em que

exista pelo menos uma mediana com menos de duas vértices associadas a ela. Execute lof-mh.exe

com o critério de parada por iteração configurado para 200 iterações. Os resultados melhoraram ou

pioraram?

42


4.9 Implementação da máquina de cálculo – Acelerômetro micro-eletro-mecânico capacitivo

Neste capitulo é apresentada a implementação computacional para otimização de um

acelerômetro micro-eletro-mecânico realizada em um trabalho de mestrado concluído no ano de

2015 (L. L. Silva 2015). Esse trabalho está disponível a partir do link:

http://www.bdita.bibl.ita.br/tesesdigitais/lista_resumo.php?num_tese=68141

Uma ilustração computacional com vista explodida do acelerômetro é apresentada na

Figura 50. Os principais parâmetros dimensionais do transdutor de aceleração MEMS, são

apresentados na Figura 51.

Figura 50 – Ilustração computacional em vista explodida, do transdutor de aceleração MEMS.

Figura 51 –Ilustração esquemática da geometria da estrutura mecânica do microacelerômetro (transdutor de

aceleração). (a) vista frontal da massa sísmica. (b)Vista lateral ilustrando as partes internas do conjunto

transdutor montado.

43


A tabela abaixo contém os principais parâmetros dimensionais de um acelerômetro utilizado

como referência neste estudo:

Tabela 4 – Informações de dimensão associada ao acelerômetro estudado

Parâmetros geométricos Valor Gap entre eletrodos fixos e massa sísmica (h0) 2 μm Distância entre massa sísmica e viga (wgap1) 210 μm Distância entre estrutura de sustentação e viga (wgap2) 210 μm Comprimento da borda plana da estrutura de sustentação, paralela as faces de contato dos eletrodos (wrimp)

150 μm

Comprimento do dispositivo (Td) 4.380 μm Espessura da viga (tb) 55 μm Largura da viga (wb) 200 μm Largura do gap lateral (wgap) 1.040 μm Comprimento da viga (lb) 2.820 μm Comprimento da massa sísmica (Wm) 2.000 μm Largura da massa sísmica (Lm = Wm) 2.000 μm Espessura da massa sísmica (tm) 380 μm Distância de recuo da viga (dlb) 220 μm Frequência natural mecânica (fn) 2.678 Hz Sensibilidade eletro-mecânica (SEM) 0,6 pF/g

O objetivo da otimização proposta é maximizar a sensibilidade eletromecânica do transdutor

de aceleração (SEM), assim como a frequência de corte, aqui denominada de frequência angular de

corte (ωc0). Ainda, o problema de otimização visa à minimização do tamanho total do dispositivo

(Td). Para atingir esses objetivos, a função objetivo é definida como:

�� . � . = ��1

��+ ��

1

��+ ��,

(1)

onde, P1 = 0,3 e P2 = 0,4 e P3 = 0,3 são os pesos atribuídos as parcelas da função objetivo. Devido

às diferenças nas grandezas envolvidas, é efetuada uma normalização nos parâmetros aplicados na

função objetivo; assim, a sensibilidade eletromecânica normalizada é dada por:

�� =��

��, (2)

onde a sensibilidade eletromecânica para normalização é SEMnor = 1,0 pF/g. A sensibilidade

eletromecânica do transdutor SEM, pode ser então dada como:

�� = �� (3)

44


A sensibilidade elétrica SE linearizada é expressa por:

�� =2��

ℎ�� , (4)

onde, ε0 = 8,854x10-12 F/m é a permissividade elétrica do vácuo, εr é a permissividade elétrica

relativa do dielétrico ar, considerada εr = 1 e Am é a área da face da massa sísmica, normal ao eixo

de sensibilidade de aceleração. A sensibilidade mecânica do transdutor SM, pode ser expressa, pela

derivada parcial do deslocamento em z com relação à aceleração no eixo z dada como:

�� =��

��=��

��=

1

��=

1

4��, (5)

onde, fn é a frequência natural mecânica do transdutor, a frequência natural angular do transdutor ωn

é dada por:

�� = ��

�� (6)

onde, Meff e Keff correspondem à massa efetiva e à constante de rigidez efetiva do sistema,

respectivamente:

�� = �� + ��13

35��, (7)

�� = �� − �� = 48��

�� −

2��

�

ℎ�� , (8)

onde :

Ms é a parcela relativa à massa sísmica, dada por:

�� = �� +

√2

2��

� +��

�

6�, (9)

com ρsi = 2.230,0 kg/m3 expressando a densidade do silício monocristalino, em temperatura

ambiente (Hull, 1999),

45


nb é o número de vigas,

mb é a massa das vigas

�� = 2��2√2�� + ��, (10)

Vsb é a tensão elétrica dc de alimentação do sistema,

keq expressa a constante de rigidez mecânica equivalente do sistema,

E é o módulo de Young,

I é o momento de inércia de área das vigas que sustentam a massa sísmica,

o parâmetro kel expressa a constante de rigidez eletrostática,

o momento de inércia da viga I é calculado por:

� =�2√2 �� + 4��

�

48 (11)

A frequência angular de corte normalizada é expressa como:

�� =��

��, (12)

onde ωc0 é a frequência angular de corte, que define o limite máximo da faixa linear dinâmica e

ωcnor = 6000 π rad/s é a frequência angular de corte para normalização.

O tamanho total do dispositivo normalizado é expresso por:

�� =��

��, (13)

onde Td é o tamanho do dispositivo e Tdnor = 4.500μm é o tamanho total do dispositivo para

normalização. Os valores dos parâmetros SEmnor, ωcnor e Tdnor são baseados nos valores obtidos no

projeto do micro acelerômetro de referência, ou seja, são baseados no conhecimento prévio do

comportamento das variáveis do problema.

Uma vez apresentadas as principais expressões utilizadas na modelagem física do problema,

são apresentados os principais aspectos associados à configuração a implementação computacional

no contexto do framerwork.

46


Neste exemplo são fornecidos dois arquivos adicionais, ExampleDirectModel.cpp e

GeneralConfiguration.xml, localizados dentro da pasta accelerometer que fica dentro da pasta

others, Figura 4.

Substitua o conteúdo do arquivo ExampleDirectModel.cpp, localizado na pasta lof-mh-

new-directmodel pelo conteúdo do arquivo ExampleDirectModel.cpp localizado na pasta

others\accelerometer. Substitua o conteúdo do arquivo GeneralConfiguration,xml localizado na

pasta lof-mh-test pelo arquivo GeneralConfiguration.xml localizado na pasta

others\accelerometer. Depois disso é necessário realizar algumas alterações pontuais marcadas

com elipse na Figura 52. Altere o código como indicado na Figura 52, e utilizando a ferramenta

Code::Blocks, acione o comando Build\Build ou Ctrl+F9, conforme item 1 da Figura 12. A

confirmação de sucesso é a evidência de 0 erros conforme itens 3 e 4 da Figura 12.

Figura 52 – Configuração das variáveis de projeto da implementação computacional do acelerômetro.

O arquivo GeneralConfiguration.xml fornecido permite executar 100 iterações da meta-

heurística particle swarm. O nome do projeto é AcelerometerDirectModel_Project. A

configuração das variáveis de projeto foi baseada nas informações dos parâmetros geométricos do

acelerômetro, Figura 51, considerando uma definição conveniente para os limites, Figura 53. Foi

definida uma lista contendo cinquenta e uma variáveis denominadas resultados do solver, cujo

conteúdo deve ser preenchido pela máquina de cálculo e gravado nos arquivos de resultado do

framework a cada iteração, Figura 54. Note que praticamente todos esses valores de saída devem

ser calculados pela máquina de cálculo para se avaliar a função objetivo. Portanto, não resultam em

cálculos adicionais.

47


Figura 53 – Configuração das variáveis de projeto da implementação computacional do acelerômetro.

Figura 54 – Configuração das variáveis de projeto da implementação computacional do acelerometro.

O conteúdo do arquivo ExampleDirectModel.cpp fornecido não é apresentado neste tutorial,

entretanto, o usuário desse guia tem a liberdade de abri-lo utilizando a ferramenta Code::Blocks ou

48


outro editor de texto para estuda-lo. Novamente, o leitor é incentivado a estudar com atenção a

implementação fornecida e fazer paralelos com os casos anteriores.

De forma resumida, o conteúdo de ExampleDirectModel.cpp contém a implementação

computacional utilizando as expressões matemáticas que regem o fenômeno físico apresentadas

neste capítulo. Uma sugestão para analisar a implementação do arquivo ExampleDirectModel.cpp é,

com base nos exemplos apresentados anteriormente, identificar os blocos de código responsáveis

por: a) realizar a leitura das variáveis de projeto; b) realizar a computação do valor de função

objetivo; c) atribuir um valor de restrição para soluções que devem ser penalizadas; d) atribuir ao

indivíduo o valor de função objetivo computada; e e) atualizar as variáveis denominadas resultado

do solver.

Para executar o framework pressione duplo clique em lof-mh.exe e observe os arquivos de

saída.

A partir de uma execução do framework utilizando a máquina de cálculo do acelerômetro

com as configurações sugeridas neste capitulo foram utilizados os valores de resultado do arquivo

de saída Evolution.txt para confeccionar um gráfico com o objetivo de ilustrar um exemplo de

solução encontrado, Figura 55.

Figura 55 – Curva de convergência utilizando os resultados do problema do acelerômetro.

49


O resultado ilustrado na Figura 55 apresenta os melhores valores de função objetivo

encontrados durante o processo de busca que consistiu da execução de 100 iterações. Note-se que

no início da execução do framework a melhor solução tem valor de função objetivo próximo de 20,

e com aproximadamente 10 iterações os valores chegaram à aproximadamente 2.3, convergindo

para a melhor solução encontrada com valor de função objetivo igual a 1.8112. Um comportamento

curioso ocorre na iteração 58, quando o framework substitui a melhor solução para um valor maior,

mesmo tratando-se de um problema de minimização. Essa substituição é consequência de uma

decisão de projeto do lof-mh (que pode ser alterada no futuro). Pode ocorrer que uma solução com

menor quantidade de restrições, menos penalizada pela máquina de cálculo, seja encontrada mas

com valor de função objetivo maior que a solução penalizada, Figura 56. No exemplo apresentado,

a melhor solução da iteração 58 tem apenas uma restrição enquanto que a melhor solução

encontrada na iteração 57 tem 3 restrições. Com o processo de penalização automática do

framework, opção adotada neste exemplo e que não envolve alteração da função objetivo por parte

da máquina de cálculo direto, a classificação das soluções é feita iteração a iteração, o que parece

gerar uma inconsistência. Porém, o framework mantém registro das penalizações e utiliza essa

informação para atualizar a curva de convergências. Os aumentos de função objetivo, portanto,

estão associados à redução do numero de restrições da solução. Para os casos em que é possível

prever, por exemplo, valores máximo e mínimo de referencia para a função objetivo a penalização,

em valores absolutos, pode ser feita diretamente na máquina de cálculos direto, alterando o valor da

função objetivo calculada. Para saber se a solução final está penalizada, é necessário consultar os

arquivos de saída, Figura 56.

Figura 56 – Melhores indivíduos encontrados nas iterações 57 e 58.

Neste exemplo a solução final, que tem valor de função objetivo igual a 1.8112, não

apresenta restrições apesar da quantidade relativamente pequena de iterações.

50


Para melhorar os valores obtidos em um estudo de otimização utilizando meta-heurísticas

diferentes abordagens podem ser empregadas. Uma delas consiste do refinamento do modelo

matemático/físico/computacional, o que implica no conhecimento dos fenômenos físicos relevantes

que regem o problema que permitam realizar a tradução adequada do modelo (Goldbarg e Luna

2005). Outra abordagem consiste em utilizar os parâmetros de meta-heurística mais adequados para

a categoria do problema de otimização estudado. Um estudo nesse sentido envolvendo tunning off-

line aplicado à meta-heurística particle swarm foi realizado por (Silva, et al. 2014) utilizando um

conjunto de funções de teste dos tipos mono e multimodais. Nesse estudo foi possível identificar

um conjunto de parâmetros da meta-heurística particle swarm que apresentam resultados bons para

uma quantidade expressiva de funções de teste com diferentes topologias.

4.9.1 Exercício I:

Estude o conteúdo do arquivo ExampleDirectModel.cpp fornecido. Identifique em quais

linhas começa e termina os blocos de código responsáveis por:

a) realizar a leitura das variáveis de projeto;

b) realizar a computação do valor de função objetivo;

c) atribuir um valor de restrição para soluções que devem ser penalizadas;

d) atribuir ao indivíduo o valor de função objetivo computada; e

e) atualizar as variáveis denominadas resultado do solver.

51


5 Conclusões

Ao término deste tutorial espera-se que o usuário esteja em condições de resolve um

problema mono-objetivo, ou um multi-objetivo pelo método das restrições utilizando as ferramentas

disponíveis no LOF-MH. Problemas com e sem restrições foram apresentados com diferentes níveis

de dificuldades e espera-se que a alteração dos projetos aqui apresentados para adaptação a novos

problemas propostos pelo usuário seja, do ponto de vista conceitual, considerada fácil.

O documento foi desenvolvido considerando que o usuário final tenha pouca familiaridade

com as ferramentas de desenvolvimento em C++, de forma que a sequência de passos foi definida

com base em uma das ferramentas de software livre disponíveis na internet. Em princípio, o sistema

pode utilizar qualquer ferramenta de desenvolvimento com o qual o usuário já tenha familiaridade.

6 Referências Back, Thomas, D B Fogel, e Z Michalewicz. Handbook of Evolutionary Computation. Taylor &

Francis, 1997. Goldbarg, Marco Cesar, e Henrique Pacca L. Luna. Otimização combinatória e programação

linear: modelos e algoritmos. Rio de Janeiro: Campus, 2005. Lorena, L.A.N., e Pereira, M.A. “A Lagrangean/surrogate heuristic for the maximal covering

location problem using Hillsman's edition.” International Journal of Industrial, 2002: 57-67. Namen, Anderson Amendoeira, e Cláudio Thomás Bornstein. “Uma ferramenta para avaliação de

resultados de diversos modelos de otimização de dietas.” Pesqui. Oper. vol.24 no.3 , 2004. Pinho, Liliana Vieira. Departamento de Matemática Faculdade de Ciências e Tecnologias -

Universidade de Coimbra. 7 de 12 de 2012. http://www.mat.uc.pt/~mat0829/PL-AndreLiliana2012.pdf (acesso em 12 de 10 de 2016).

Pizzolato, N.D, Barcelos, F.B., e Lorena, L.A.N. “School Location Methodology in Urban Areas of Developing Countries.” IFORS2002 - The sixteenth triennial conference of the International Federation of Operational Research Societies. Edinburgh, Scotland, 2002.

Silva, C, W Saba, N Abe, e A Passaro. “A metric to assist the selection of the particle swarm optimization parameters.” Em Engineering Optimization 2014, por Aurélio Araújo, 105-109. LISBON, PORTUGAL: CRC Press, 2014.

Silva, Liangrid Lutiani da. “Análise de acelerômetros MEMS capacitivos.” Dissertação (Mestrado em Ciências e Tecnologias Espaciais) - Instituto Tecnológico de Aeronáutica. São José dos Campos, 2015.

Team, The Code::Blocks. “Code::Blocks.” The open source, cross platform, free C, C++ and Fortran IDE. 28 de 01 de 2016.

Yoon, Yourim, e Kim Yong-Hyuk. “The Roles of Crossover and Mutation in Real-Coded Genetic.” Em The Roles of Crossover and Mutation in Real-Coded Genetic, Bio-Inspired Computational Algorithms and Their Applications, por Dr. Shangce Gao, 65-69. Rijeka: InTech Europe, 2012.

Laboratório de Engenharia Virtual LEV - Caderno de ... · 4.5.1 Exercício I: ... Caderno de...

Documents

Transcript of Laboratório de Engenharia Virtual LEV - Caderno de ... · 4.5.1 Exercício I: ... Caderno de...