primeira coisa que eu deveria saber, na verdade eu ja sabia, so nao apliquei direito. Comecei a fazer as alteracoes criando modulos novos e testando. So que chegou uma hora que eu parei de testar os modulos porque nao conseguia mais entender como modularizar os testes das funcoes. Esse foi o primeiro erro. Com um pouco de conversa com os mais experientes eu provavelmente teria conseguido fazer os testes, e nao programar varias funcoes diferentes sendo chamadas umas nas outras sem saber onde estavam os erros.2) Flags de compilacao. Isso e basico, muito basico. O que foi mais util pra mim foram as flags de avisos, que me ajudaram a rastrear nao so os erros, como o que estava mal escrito. Sem esses avisos, o compilador apontava pra linhas que eu nao conseguia entender por que havia um erro. Depois de ativar os avisos veio a resposta: porque o erro nao estava ali. Entao, comecei compilando com:$ gfortran programa.f90 -o programaE agora eu faco usando scripts como esse:$ cat c.shstr=$1len=${#str}gfortran -g -fbounds-check -fmax-errors=3 -Wuninitialized -ffpe-trap=overflow -fbacktrace -ffree-line-length-0 -Wall -Wtabs $1 -o ${str:0:(len-4)}$ ./c.sh programa.f03Para o .bat, eu lembro que a referencia e dada por %1 e nao $1, mas nunca lembro como manipula strings.Nota que tem um ponto importante que foi a fonte dos meus pepinos dos ultimos meses, que o -fbounds-check evita. O seguinte codigo nao vai dar erro sem o -fbounds-check. Por sinal, por algum motivo nao consegui fazer dar erro agora pelo vetor a nao ter sido inicializado, tenho que dar uma olhada nisso com mais calma.program erradoimplicit noneinteger,dimension(:),allocatable :: ainteger :: ballocate(a(10))b = a(11)endprogram errado3) Debugger. Fiz o debug por mais de um ano colocando todos os write(*,*) possiveis e imaginaveis no codigo, ate perceber que tinha variaveis demais e eu nao estava entendo mais o que acontecia. Meu trabalho teria sido mais rapido e facil se, 1 ano atras, eu tivesse aprendido a usar algum debugger. Entao, era hora de procura-lo, antes tarde do que nunca, dizem por ai. Resolvi usar o GDB. O detalhe e que ele, a principio, ta redondinho pro Fortran 77, mas nao necessariamente pros mais recentes. Nao sei se o pepino e do GDB ou do gFortran, mas depois de 2 dias aprendendo a usar o GDB eu descobri que nao conseguia ver as variaveis dos arrays alocados dinamicamente. Resolvi fazer um programa de teste pra encontrar o problema, e mudei pra encontrar a "solucao" (tambem conhecida como gambiarra). O programa ficou o seguinte:program kindrealimplicit noneinteger,parameter :: kr4=4,kr8=8real(kr4),dimension(2) :: a4real(kr8),dimension(2) :: a8real(kr4),dimension(:),allocatable :: b4real(kr8),dimension(:),allocatable :: b8real(kr8) :: arg1,arg2arg1 = 10.d0arg2 = 9.d200a8 = (/ arg1,arg2 /)b8 = (/ arg1,arg2 /)a4(1) = real(arg1,kr4)b4(1) = real(arg1,kr4)a4(2) = huge(a4(2))b4(2) = huge(b4(2))write(*,*)'a4',a4(:)write(*,*)'b4',b4(:)write(*,*)'a8',a8(:)write(*,*)'b8',b8(:)endprogram kindrealE a saida ficou: a4 10.000000 3.40282347E+38 b4 10.000000 3.40282347E+38 a8 10.000000000000000 8.99999999999999939E+200 b8 10.000000000000000 8.99999999999999939E+200Vendo no GDB, fica da seguinte forma:(gdb) p a4$1 = (10, 3.40282347e+38)(gdb) p b4$2 = (0)(gdb) p a8$3 = (10, 8.9999999999999994e+200)(gdb) p b8$4 = (0)(gdb) p *((real *)b4)$5 = 10(gdb) p *((real *)b4)@2$6 = (10, 3.40282347e+38)(gdb) p *((real *)b8)@2$7 = (0, 2.5625)O que mostra que o problema e como