Teste com alternativas de processamento de programação inteira

O modelo de programação inteira era necessário para resolução do OBS e, portanto, teríamos que encontrar alguma forma de reduzir o tempo de processamento sem a eliminação da produção inteira do modelo. O software que utilizamos, Express Solver Engine da

Frontline System apresenta uma série de opções de processamento para solução de problemas

de otimização linear. Entre os parâmetros utilizados para reduzir o tempo de processamento dois apresentaram grande êxito:

Tolerância de soluções inteiras

Como foi explorado no capítulo 2, o método Branch and Cut de resolução de problemas com restrições inteiras primeiro soluciona o problema de forma relaxada, isso é, ignorando as restrições inteiras para depois testar as diversas soluções inteiras existentes dentro da zona de respostas factíveis. O modelo matemático utilizado pelo Express Solver Engine® guarda o valor da função objetivo da resolução do modelo relaxado e o compara com os valores da resolução do problema com as soluções inteiras. Ao mesmo tempo, o sistema disponibiliza uma caixa de texto onde se pode estabelecer qual é a diferença percentual aceitável entre a resolução do modelo relaxada e resolução do modelo com as restrições inteiras usando a seguinte equação:

Vfo com restrições inteiras – Vfo sem restrições inteiras / Vfo sem restrições inteiras

Onde Vfo é o valor da função objetivo para o problema.

Ao percorrer a árvore do método Branch and cut, uma vez que o modelo encontre uma solução inteira dentro da porcentagem estabelecida pelo usuário, apresenta-se a resolução e o sistema pára de realizar outros testes com soluções inteiras. Desta forma estabelecemos que se uma solução com uma diferença de até 5% da resolução do modelo relaxada fosse encontrada, o sistema poderia deixar de realizar outras interações.

Os tempos de resolução caíram drasticamente. Foram feitos mais de 20 testes com conjuntos de estoques e ordens de produção distintas e com aproximadamente o mesmo

número de variáveis: entre 25 e 35 ordens de produção e 650 e 780 lotes linhas de estoque o que equivale a 21300 variáveis binomiais. Nesse conjunto de testes se obteve uma média de tempo de 6,85 minutos e um desvio padrão de 2,1 minutos. Ou seja, não somente o tempo de processamento diminuiu como o desvio também decresceu significativamente. Ademais, utilizou-se esse parâmetro nos 3 testes de grande escala que foram realizados. O resultado pode ser visto no gráfico 4.3.

0 2 4 6 8 10 1 2 3 testes te m p o ( m in )

Gráfico 4.3: Tempo de processamento de 3 testes com restrição da tolerância de soluções inteiras

Fonte: Arquivos da Gelita

Embora se soubesse que a resposta obtida com essa alteração não seria a melhor, como estávamos lidando de um programa que serve para controlar a programação de moagem de uma fábrica inteira, tínhamos que conjugar performance e esforço de processamento. Ou em outras palavras, estabelecer uma boa troca (trade off) entre o quão perto da melhor resposta se consegue chegar em um razoável tempo de processamento. Contudo, os tempos ainda eram altos e outras soluções para diminuir o tempo de processamento ainda eram necessárias. Restrição de adição de nós

O método branch and cut estabelece cortes de respostas (nódulo) na área de respostas factíveis que obviamente não são melhores que a resposta atual O Express Solver Engine® alem de realizar os cortes tradicionais, possibilita a definição dos valores incrementais da função objetivo que se deseja analisar através de um caixa de texto. Ou seja, o sistema

possibilita ajustar o quanto o valor da função objetivo referente ao próximo nódulo deve ser maior do que a melhor resposta atual para que seja analisado. Desta feita, se um nódulo que atenda as restrições inteiras estabelecer um valor para a função objetivo cujo valor percentual é menor do que aquele na caixa de texto, então o nódulo e o sub segmento de respostas relacionadas a ele na árvore de resolução do método de branch and cut não será analisado.

Estabelecemos que o sistema somente analisaria nós que apresentassem um valor incremental maior que 1% que a atual melhor resposta. Tal parâmetro possibilitou uma redução significativa do tempo de processamento. Mais de 20 testes foram feitos com conjuntos semelhantes àqueles que foram utilizados para analisar a tolerância das soluções inteiras e os tempos nunca ultrapassaram os 6 minutos.

Redução do número de variáveis inteiras

Embora tenhamos reduzido o tempo de processamento significativamente, ainda existia um desconforto com o tempo que o sistema demorava para realizar algumas simulações das misturas quando se processava um conjunto grande de lotes de produção e/ou ordens de moagem.

A última solução que se aplicou para a redução do tempo de processamento não está relacionada às opções de processamento do Express Solver Engine; mas sim na própria dinâmica de execução da programação de moagem. Embora os programadores processassem o OBS com a presença de várias ordens de produção, a liberação dessas, era feita de forma individual. Ou seja, analisava-se cautelosamente os lotes de produção empenhados nas ordens de moagem pelo sistema antes de enviá-las para o armazém onde os lotes seriam segregados e colocados nos moinhos. Uma vez que uma ordem de produção já tivesse sido analisada e aprovada, os lotes de produção empenhados nessas ordens aprovadas poderiam deixar de ser variáveis fazendo com que o número de variáveis e restrições no modelo fosse reduzido.

A tabela 4.5 mostra a matriz de variáveis binomiais xi,jcom i lotes de produção e j ordens de moagem do sistema OBS . Como a análise e aprovação da alocação dos lotes de produção nas ordens de moagem, tais linhas e colunas podem deixar de ser variáveis fazendo com que o problema fique menor e, como consequência, reduzindo o tempo de processamento.

Tabela 4.5: Representação da exclusão de ordens de moagem e pedido da base de variáveis

Fonte: elaborado pelo autor

Após estas 3 soluções o tempo de processamento do OBS ficou adequado ao tempo requerido para a operacionalização da programação de ordens de moagem e pôde ser implementado. A performance da busca de melhor solução foi reduzida e uma boa condição de otimização versus tempo de processamento foi atingida.