Início Exemplos Capturas de ecrã Manual do utilizador Logótipo Bluesky YouTube
OghmaNano Simular células solares orgânicas/Perovskita, OFETs e OLEDs DESCARREGAR

Parte D: Estabilidade do solucionador/malhamento

Esta seção se concentra na estabilidade do solucionador e na escolha da malha. Simulações unidimensionais (1D) são, em geral, muito estáveis e executam rapidamente. À medida que você aumenta a dimensionalidade — de 1D para 2D e 3D — o número de equações e o número de termos de acoplamento entre elas cresce, tornando a instabilidade numérica mais provável. Se as configurações não forem escolhidas com cuidado para uma simulação 2D ou 3D, uma simulação pode falhar em convergir.

Aqui vamos deliberadamente forçar algumas configurações simples para provocar não convergência, depois diagnosticar por que isso acontece e como corrigir. Ao reproduzir você mesmo esses modos comuns de falha, aprenderá a reconhecer os sintomas e aplicar os remédios corretos (por exemplo, ajustando a malha, reduzindo o tamanho do passo de polarização ou moderando parâmetros extremos de material) para recuperar uma solução estável.

1. Valores irrealisticamente baixos

Em muitos casos, problemas de convergência surgem de valores de entrada não físicos. Para ilustrar isso, definimos deliberadamente a mobilidade de portadores como 0 e examinamos os erros resultantes. É claro que, em um material real, a mobilidade nunca é verdadeiramente zero — ela sempre tem um valor finito —, mas este exemplo mostra o que acontece quando o solucionador recebe um parâmetro irrealista.

Abra o editor de Electrical Parameters (janela principal → aba Device) e defina a mobilidade como 0, como mostrado em ??. Agora execute a simulação. Você deverá ver uma tela de erro semelhante à ??, com duas caixas vermelhas: uma caixa vertical em torno do resumo de resíduos e uma caixa horizontal próxima da mensagem de falha.

Se você observar a caixa vermelha vertical, poderá ver f()=2.54e2, seguido de outras linhas em que f() é muito grande (por exemplo, 1e15, 1e5, 1e8, 1e7). Aqui, f() é o erro residual do solucionador: uma medida de quão bem as equações acopladas estão atualmente sendo satisfeitas. Idealmente, o resíduo do solucionador seria exatamente zero, embora, na prática, isso nunca possa ser alcançado. Um residual na faixa de 1e−10 a 1e−8 indica convergência muito boa, enquanto valores em torno de 1e−1 ainda são aceitáveis. Em contraste, resíduos na casa das centenas (por exemplo, 2.54e2) — especialmente quando acompanhados por valores de componentes tão grandes quanto 1e15 — são um sinal claro de que o solucionador está enfrentando dificuldades e que o sistema se tornou instável.

Editor de parâmetros elétricos com a mobilidade definida como 0, um valor não físico que impede o transporte de portadores e causa erros do solucionador.
Mobilidade zero (μ = 0). Uma configuração não física que bloqueia completamente o transporte e normalmente aciona não convergência em drift–diffusion.
Rastreamento de falha do solucionador mostrando falha após definir a mobilidade como zero.
Erro por mobilidade zero. Com μ = 0, as equações de transporte tornam-se inconsistentes, fazendo a simulação gerar erro e eventualmente falhar.

A caixa vermelha horizontal normalmente informa por que a execução finalmente é abortada: Holes asking for 3e5 but only defined in range [min, max]. Isso significa que o nível quasi-Fermi calculado foi para fora da faixa tabulada. Antes de iniciar, o modelo pré-tabula relações como nível quasi-Fermi vs. densidade de portadores em um intervalo grande de energia — de fato, muito maior do que normalmente se esperaria encontrar em um dispositivo. Quando o solucionador se torna instável, o modelo pode solicitar valores irreais muito além desse intervalo; nesse ponto, o solucionador não consegue avaliar as quantidades necessárias e para.

Em resumo, ao definir a mobilidade como um valor não físico (μ = 0), forçamos as equações para um regime que não faz sentido físico, então o método numérico falha: grandes resíduos, seguidos por uma solicitação de valores fora das tabelas pré-computadas e, então, uma falha. É importante notar que esse resultado não é uma fraqueza do modelo nem um bug do software. Ao inserir parâmetros não físicos, o solucionador é empurrado para um regime em que não existe solução matemática ou fisicamente válida e, portanto, ele não pode fornecer um resultado significativo.

2. Valores irrealisticamente altos

Neste exemplo, definimos a mobilidade de portadores como μ = 1×106 m²·V⁻¹·s⁻¹. Este é um valor intencionalmente não físico para um modelo drift–diffusion de semicondutores: tal magnitude poderia estar associada a regimes de condução metálica, em vez de transporte por hopping/banda em semicondutores orgânicos ou típicos. Na prática, você não utilizaria um valor tão grande para simulações de OFET.

Se você executar a simulação com essa configuração, poderá observar o solucionador tendo dificuldade para convergir. Na leitura de resíduos (a caixa que informa f()), você verá erros extremamente grandes — por exemplo, 1e24, 1e19, 1e21 — que não decaem. É normal que os resíduos estejam elevados durante as primeiras iterações, enquanto o solucionador encontra um estado consistente, mas eles devem rapidamente se estabilizar em valores pequenos. Resíduos persistentemente enormes são um indício claro de que o sistema se tornou numericamente rígido ou não físico devido aos parâmetros escolhidos.

A conclusão é: evite mobilidades irrealisticamente altas. Coeficientes de transporte excessivos tornam o sistema de EDPs muito rígido, causando mau condicionamento e não convergência. Use valores de μ fisicamente razoáveis para o seu sistema de materiais e execute novamente com passos de polarização moderados para restaurar um comportamento estável.

Editor de parâmetros elétricos com uma mobilidade irrealisticamente alta definida como 1×10^6 m²·V⁻¹·s⁻¹, o que desestabiliza o solucionador.
Mobilidade irrealista (μ = 1×106 m²·V⁻¹·s⁻¹). Coeficientes de transporte extremamente grandes criam sistemas muito rígidos e comumente levam à falha do solucionador.
Mensagem de erro do solucionador causada por configurações de mobilidade irrealisticamente altas que desestabilizam a solução numérica.
Erro por mobilidade irrealisticamente alta. Valores muito grandes de μ tornam o sistema de EDPs rígido demais, levando à instabilidade e à falha do solucionador.

3. Estruturas de dispositivo ruins

Neste exemplo, abrimos o editor de contatos e definimos a largura do contato Source como um valor muito pequeno (veja ??), para um mícron. À primeira vista isso pode não parecer problemático, mas cria um problema sutil: a simulação é baseada em uma malha de diferenças finitas, na qual quantidades como campo elétrico e densidade de portadores são calculadas apenas nos pontos definidos da malha.

Se você inspecionar o Electrical Mesh Editor (encontrado na aba Electrical), notará que esse contato ultrafino de um mícron cai entre pontos da malha (veja ??). Como resultado, o contato é efetivamente “ignorado” pela grade de diferenças finitas e nunca é aplicado corretamente à estrutura do dispositivo. Isso cria um descompasso entre a geometria definida e a malha numérica, impedindo que a simulação convirja.

Para corrigir isso, você pode aumentar a espessura do contato para que ele sobreponha pelo menos um ponto da malha, ou aumentar a densidade da malha (ou seja, adicionar mais pontos) na grade de diferenças finitas para que o contato seja capturado corretamente.

Editor de camadas mostrando o contato source configurado com uma largura extremamente fina — muito menor que o espaçamento da malha —, o que leva à não convergência.
Contato source configurado com uma largura patologicamente fina (mais fina que o espaçamento da malha). Tais características sub-malha causam condições de contorno mal postas e normalmente impedem a convergência.
Painel de configurações de malha mostrando uma malha 2D típica de OFET com cerca de 10 divisões ao longo de X — uma configuração de base estável.
Malhamento típico e estável para OFETs 2D: ~10 pontos ao longo de X. Uma malha modesta mantém o sistema bem condicionado e geralmente convergente.

4. Pontos de malha demais

Um preconceito comum ao começar com modelos de diferenças finitas é que mais pontos de malha produzem automaticamente resultados mais precisos. O raciocínio costuma ser: “cinco pontos de malha devem ser ruins, mas mil devem ser excelentes”. Na prática, não é o caso.

O OghmaNano usa um método de discretização chamado esquema de Scharfetter–Gummel, que interpola com precisão quantidades como densidade de portadores e potencial entre pontos de malha. O solucionador não simplesmente assume comportamento linear entre nós; em vez disso, ele usa uma abordagem com ajuste exponencial que captura a física do transporte com alta precisão mesmo em malhas relativamente grosseiras. Isso significa que você pode obter boa precisão com surpreendentemente poucos pontos.

Aumentar a densidade da malha não apenas aumenta o tempo de execução — pode, na verdade, reduzir a estabilidade e a precisão. Uma malha mais fina gera um sistema maior de equações, tornando o problema numérico mais difícil de resolver. Como resultado, a matriz se torna mais rígida, os resíduos podem aumentar e o solucionador pode ter dificuldade em convergir.

Sempre existe um compromisso entre capturar a física, manter o tempo de simulação razoável e evitar erro numérico desnecessário. As figuras abaixo ilustram isso: com 100 pontos de malha ao longo do dispositivo, o solucionador inicialmente informa resíduos muito grandes (por exemplo, 1e6, 1e5). Somente depois de muitas iterações ele se estabiliza em valores razoáveis de f(). Essa instabilidade surge porque a malha é excessivamente fina, tornando o sistema difícil para o solucionador tratar.

Painel de configurações de malha com a malha X definida em 100 divisões, muito acima do normalmente necessário para um OFET 2D.
Malhamento excessivo: malha X = 100 pontos. Grades super refinadas inflacionam o tamanho do sistema e a rigidez, tornando o solucionador 2D lento e propenso à não convergência.
Caixa de diálogo de erro do solucionador destacada em vermelho após usar um número excessivamente alto de pontos de malha.
Erro devido a uma malha super refinada. Densidade excessiva de malha aumenta a rigidez e a carga de memória, resultando em erros do solucionador (caixa vermelha).