Makefile (mínimo!)

Quem trabalha com programação sabe que é necessário manter tudo em ordem: não importa se o trabalho é solo ou em grupo. Além de se utilizar um software de gerenciamento de códigos (eg., CVS, Subversion, git), à medida em que o(s) código(s) cresce(m), torna-se necessário (e desejável também), a utilização de algum software para o gerenciamento do projeto (eg., Redmine, Trac). Mas no meio disso tudo – na verdade, antes disso tudo, há um pequeno pedaço de software que é responsável pela organização hierárquica de todo o projeto. Estamos falando sobre o Makefile.

Continuar lendo

Anúncios

Instalando a suite Free PGI no OS X (e mais um pouco)

Esta semana a Portland Group – empresa desenvolvera de compiladores fortran e C (e outros produtos), lançou uma versão gratuita de seus compiladores para o OS X (exceto o compilador C++). Infelizmente, uma versão gratuita ainda não parece estar disponível para o Linux ou Windows. A instalação é bastante simples e direta: basta abrir uma imagem DMG e arrastar o aplicativo para a pasta Applications do OS X. Mas acontece que a utilização dos compiladores fica restrita apenas ao Terminal.app! Isto significa dizer que, caso você utilize outro emulador de terminal, como o iTerm2.app, você simplesmente não consegue invocar os compiladores! Isto acontece porque para utilizar os compiladores, você não deve abrir o Terminal.app, mas você precisa clicar no ícone do programa instalado (Free PGI.app) e aí sim ele abre um terminal e então os compiladores podem ser utilizados. Mas que bobagem…

Continuar lendo

Compilando LAPACK e BLAS com ifort

Este tutorial é muito simples e mostra como compilar as bibliotecas de Álgebra Linear BLAS e LAPACK do netlib (http://www.netlib.org) utilizando os compiladores C e fortran da Intel (icc e ifort).

Tanto para Linux (Ubuntu 11.04) quanto no OS X (Mountain Lion), os procedimentos são os mesmos:

$ wget -c http://www.netlib.org/lapack/lapack-3.4.2.tgz
$ tar -zxvf lapack-3.4.2.tgz
$ cd lapack-3.4.2
$ cp INSTALL/make.inc.ifort ./make.inc
$ make lapacklib
$ make blaslib

Como resultado da compilação, duas bibliotecas (libs) deverão ser criadas:

  • liblapack.a
  • librefblas.a

Dependendo da sua aplicação, pode ser necessário atribuir algum valor para a variável “LAPACK_PATH” indicando o caminho das libs que foram geradas. Se a compilação das libs foi feita em /home/user/lapack-3.4.2, então, pode-se fazer:

$ export LAPACK_PATH=/home/user/lapack-3.4.2

Este comando pode ser incluído no seu ~/.bashrc ou mesmo em /etc/bash.bashrc.

Referência:

Catastrophic error: could not set locale “” to allow processing of multibyte characters

As mensagem de erro de compilação dos compiladores da Intel são bastante interessantes: “Catastrophic error…”, ou “Erro catastrófico…” 🙂

Esse erro apareceu quando executei o comando “make” para compilar um código fonte em uma máquina Linux (Ubuntu 11.04) utilizando os compiladores da Intel (ifort/icc). Esse erro apareceu porque o Makefile não conseguiu determinar qual é o “idioma” do terminal, muito embora a variável “LANG” estivesse ajustada para “en_US.UTF-8” (LANG=en_US.UTF-8).

A solução foi ajustar mais uma variável de localização, a “LC_ALL” com o mesmo valor de “LANG”, ou seja:

$ export LC_ALL=en_US.UTF-8

Você pode colocar no seu .bashrc ou ainda em /etc/bash.bashrc, e problema resolvido!

Referência:

 

Erro: no such instruction: `vzeroupper’ do PGF90 12.8-1

Recentemente instalei a versão trial do compilador fortran do Portland Group (PGI) para compilar um pacote. No primeiro teste (com um programa Hello World), ocorreu o seguinte erro:

$ pgf90 teste.f90
NOTE: your trial license will expire in 14 days, 0.939 hours.
NOTE: your trial license will expire in 14 days, 0.939 hours.
teste.f90:74:no such instruction: `vzeroupper'
teste.f90:83:no such instruction: `vzeroupper'
teste.f90:90:no such instruction: `vzeroupper'
teste.f90:97:no such instruction: `vzeroupper'
teste.f90:101:no such instruction: `vzeroupper'
teste.f90:107:no such instruction: `vzeroupper'
teste.f90:234:no such instruction: `vzeroupper'

O que é muito estranho, pois o programa hello world contém apenas uma instrução para imprimir uma linha na tela. Dando uma olhada aqui e alí, encontrei a solução aqui, e a sugestão foi acrescentar a opção  “-tp=nehalem-64” na compilação:

$ pgf90 -tp=nehalem-64 teste.f90
NOTE: your trial license will expire in 14 days, 0.901 hours.
NOTE: your trial license will expire in 14 days, 0.901 hours.

Ou seja, o “a.out” (programa compilado) foi criado e funciona sem problemas. Este problema pode afetar máquinas Linux ou Mac OS X com processador Intel, especialmente com o chip SandyBridge. Meu Macbook Pro é de 2011 e tem processador Intel com chip Sandybridge e a Apple não atualizou (ainda…) o Xcode (que fornece acesso a algumas instruções básicas do processador) para suportar as instruções AVX presentes a partir dos chips SandyBridge (o que é ridículo, pois já temos os novos chips IvyBridge…). Então, esta solução força o compilador a interpretar o chip como um modelo mais antigo, ou mais ou menos isso 🙂

Referência:

http://www.pgroup.com/userforum/viewtopic.php?t=2794&sid=3fb09a8305d263e7694c5c20887035b8

Instalando o MPICH2 pelo HomeBrew compilado com o Ifort

Uma das vantagens dos gerenciadores de pacotes disponíveis para o Mac OS X (e.g., Fink, HomeBrew, MacPorts) está na compilação de todos os pacotes, gerando executáveis rápidos e 100% compatíveis com as instruções do processador e com o ambiente de execução. Por outro lado, esta vantagem é contrabalançada pelas diversas opções disponíveis para o ambiente de compilação (flags de compilação). O HomeBrew é um desses gerenciadores e você pode especificar algumas opções de compilação, por exemplo, o compilador fortran a ser utilizado na compilação de um pacote. Um caso interessante é a compilação do pacote MPICH2. Se você compilar com o gfortran, então todos os executáveis gerados na compilação do MPICH2 serão lincados com as bibliotecas do gcc e com os headers do gfortran. Isso seria um padrão para o caso de haver apenas o gfortran como compilador fortran na máquina. Mas você pode querer compilar o MPICH2 com o ifort, o compilador fortan da Intel ou mesmo com o g95 ou pgi.

No linux, esse tipo de instalação seria mais ou menos assim, considerando-se o bash como shell e o ifort como compilador fortran:

$ export FC=ifort ICC=icc
$ make
$ make check
$ sudo make install

No caso da instalação do MPICH2 pelo HomeBrew, utilizando-se o ifort como compilador padrão, as instruções são semelhantes:

$ export FC=ifort ICC=icc CPP=icc
$ brew install mpich2 --default-fortran-flags

Só isso. O modificador “–default-fortran-flags” ajusta as variáveis FCFLAGS e FFLAGS (que são variáveis que otimizam a compilação de um código fortran) com valores compatíveis com um compilador nos padrões do gcc, como é o caso do ifort e o icc.

Dicas para quem está iniciando em “modelagem”

A idéia deste post é mostrar algumas dicas para quem está iniciando a “rodar” modelos, seja realizando testes, seja realizando implementações. Com algum tempo trabalhando com modelagem (no meu caso em meteorologia), você acaba colecionando algumas dicas que podem ser preciosas em diversos aspectos da atividade prática da modelagem. Mas antes de mais nada, vou definir aqui que o termo “modelagem”, se refere à atividade prática (à execução da modelagem) de preparar um determinado sistema ou modelo computacional e seu respectivo ambiante de compilação/submissão, e não necessariamente a modelagem em si – que por si só tem seus desafios. Estas mesmas idéias podem ser facilmente aplicadas a situações mais simples, como por exemplo, desenvolver um programa em linguagem C, fortran ou um script shell simples que automatize algumas tarefas. É preciso ter em mente apenas começar da forma correta, o não o isenta de cometer erros (inerentes ao seu trabalho) e aprender com eles.

Pois bem, quem está começando sempre tem um pouco de pressa, ou por não saber que o processo prático da modelagem é não linear, ou porque é muito apressado e sabe que não tem muito tempo para gerar e analisar os seus resultados. Nesse caso, há um caminho bastante longo e complicado entre “gerar” e “analisar” os resultados. Muitas vezes, gerar os resultados pode parecer um alívio, mas se eles não foram gerados da forma correta, podem lhe trazer muita dor de cabeça. Então, para começarmos, vamos colocar os tópicos desta discussão na seguinte ordem:

  1. Cheguei agora, o que faço?
  2. Certo, agora que já comecei, o que faço?
  3. Deu pau, o que faço?
  4. Deu pau de novo, o que posso fazer?
  5. Acho que agora está dando certo…, o que faço?
  6. Meu primeiro resultado! E agora, o que faço?
  7. Meu tempo acabou, o que faço?
  8. Outras dúvidas…

Certamente, poderiam haver outros “… e agora, o que faço?”, mas com certeza estes sete tópicos são bastante representativos do processo prático da modelagem como um todo e certamente podem lhe ajudar. Portanto, entenda este texto como uma espécie de “auto-ajuda” da prática da modelagem (antes que você tenha que recorrer à alguma ajuda externa) ou um “caminho-zen” para as suas atividades em modelagem.

1. Cheguei agora, o que faço?

Com certeza, essa é a sua primeira dúvida quando não se tem experiência prévia na prática do seu trabalho de pesquisa. Geralmente, a iniciação científica nos serve como uma espécie de laboratório com experimentos controlados em que não se assume a responsabilidade por um determinado resultado, ou melhor, aprende-se – num espaço curto de tempo, a colocar a mão na massa. Mas nem sempre, quem faz iniciação científica, acaba trabalhando com os mesmo temas em pesquisas futuras. Nesse momento, as dúvidas e aflições de quem está começando são, frequentemente, as seguintes: “putz, vou ter que mexer no linux…”, “putz, vou ter que mexer no terminal do linux…”, “putz, vou ter que trabalhar com programação…”, “putz, vou ter que trabalhar com o cluster…”, “putz, vou ter que trabalhar com o supercomputador…” etc. Na verdade, a grande sacada nesse momento é não se aborrecer e nem se preocupar com o tal do linux e seu terminal, até porque – dependendo da área em que você trabalhe, vai acabar percebendo que ao invés dele ser um vilão, ele será a melhor ferramenta com que você vai trabalhar. Dito isto, comece a se preparar fazendo-se as seguintes perguntas:

Se eu vou trabalhar com um modelo computacional ou um programa fortran, ou script do matlab etc, onde ele(s) está(ão)?

Essa é a primeira coisa que você tem que se perguntar. Se isso lhe parecer um pouco óbvio demais, saiba que se você não for cuidadoso(a) a partir daqui, os seus problemas podem começar logo de início. Se você for trabalhar no linux (sendo no seu computador/notebook, em um cluster ou em um supercomputador), com certeza terá que lidar com o terminal. Por isso, pesquise com os seus colegas de trabalho onde pode-se obter o modelo ou programa com que você vai trabalhar. Não se preocupe demais com o terminal e os seus comandos, com certeza você vai aprender praticando.

Sempre, eu eu disse SEMPRE, a melhor situação é quando você pode trabalhar com repositórios (em cvs, svn, git, bazar etc).

Os repositórios são importantes porque permitem que você crie um histórico de alterações e de versões dos seus scripts e rotinas que for trabalhar/criar/modificar. Além disso, ele vai lhe ajudar naquele momento em que você estiver escrevendo um relatório ou em que precisar lembrar de uma determinada data em que modificações ou implementações foram realizadas. Portanto, nessa primeira situação, pergunte a seus chefes, colegas, orientadores se o código com o qual você for trabalhar está em um repositório e em que tipo de repositório. Pergunte também se você pode criar um ramo (repositório) próprio para realizar os seus desenvolvimentos. Com certeza, essa é a melhor maneira de se iniciar o trabalho com códigos computacionais em sistemas e modelos. Para exemplos de utilização do svn, por exemplo (eu aprendi a trabalhar com o svn), leia este post sobre a criação de um repositório svn em sua máquina local (https://craftmind.wordpress.com/2011/04/25/criando-um-repositorio-svn-local/) e este sobre como utilizar o svn (http://samuca.wordpress.com/2007/04/12/tutorial-subversion/).

2. Certo, agora que já comecei, o que faço?

Se você já sabe onde está o código ou modelo com que vai trabalhar, agora é o momento de aprender a instalar/utilizar/testar o seu código. Todo código que tem um desenvolvimento ordenado e, por mais simples que seja, deve ter um README ou um LEIAME com a descrição do programa, notas de versão, bugs conhecidos e – principalmente, como instalar/utilizar/testar. Este trio (instalar/utilizar/testar) é essencial e deve ser seguido antes que qualquer outro tipo de teste seja feito com o código que você vai trabalhar. Procure saber se há uma conjunto de dados de teste (geralmente um conjunto pequeno de dados que permita testar todos os aspectos do programa).

Leia o README, siga as instruções, tire suas dúvidas e quando se sentir confortável o suficiente para começar, inicie o trio instalar/utilizar/testar.

3. Deu pau, o que faço?

Tem certeza de que leu o README por completo? Tem certeza de que não surgiram dúvidas? Se alguém lhe deu uma explicação e você não entendeu muito bem, volte e pergunte novamente. Não se acanhe! Quanto menos dúvidas você tiver sobre o processo de instalar/utilizar/testar, melhor. Assim você poderá se preocupar menos com os aspectos práticos do sistema e mais com os aspectos teóricos da sua pesquisa. Caso todas as informações do README e as instruções que lhe foram fornecidas tenham sido completamente atendidas, então o problema pode ser outro. Será necessário ler todos os logs do sistema e procurar por erros desconhecidos ou que, por uma razão ou outra, ainda não foram relatados.

Inclusive, esta pode ser uma oportunidade para que você colabore com os desenvolvedores do sistema que você está utilizando.

4. Deu pau de novo, o que posso fazer?

Se o problema persiste ou lhe parece ser algo sistemático (que está se repetindo sempre, da mesma forma), pode ser que o problema não seja com o seu sistema, mas sim com a máquina em que está sendo executado.

Lembre-se que assim como o seu computador, qualquer sistema – por mais moderno e seguro que seja, ele é suscetivel a problemas de software e hardware diversos. Se você tiver certeza de que os problemas não fazem parte do seu sistema (dos modelos/rotinas/scripts), entre em contato com o administrador da máquina que você está utilizando.

Se você está utilizando apenas o seu computador, não perca tempo e peça ajuda a alguém mais experiente. Geralmente, problemas de compilação estão relacionados à variáveis de ambiente mal ajustadas e programas que não estão completamente instalados. Se você depende de algum tipo de biblioteca que não é fornecida com o seu sistema, leia este post para uma explanação geral sobre a instalação de programas a partir do código fonte no linux (https://craftmind.wordpress.com/2011/04/25/variaveis-de-ambiente-para-programas-fonte/).

5. Acho que agora está dando certo…, o que faço?

Com muita sorte, as coisas dão certo logo de primeira ou pelo menos nas primeiras tentativas. Se não derem certo de primeira e você teve que queimar uma pouco da sua preciosa mufa para resolver, parabéns: com certeza você aprendeu mais coisas do que esperava. Uma vez que as coisas começam a fluir e a funcionar de forma como tem que ser (ou pelo menos da forma como se espera), fique atento com a performance do seu modelo/programa e veja se os resultados preliminares (on the flie) estão razoavelmente dentro do que se sabe/conhece. Geralmente os modelos computacionais geram saídas de log e erro a partir das quais pode-se acompanhar os valores calculados de uma determinada variável ou o tempo que está demorando para realizar algum cálculo. Observando estes aspectos, você poderá ser capaz de identificar problemas como: valores espúrios, situações fisicamente impossíveis, instabilidade numérica, problemas de paralelismo etc. Este tipo de diagnóstico pode lhe poupar horas, dias ou até semanas de trabalho! Imagine a situação em que um modelo numérico de previsão de tempo é empregrado para integrar uma condição inicial durante sete dias. Atualmente, dependendo de onde o modelo está sendo executado, este trabalho pode demorar de horas a dias e se você não se preocupar em olhar os valores que estão sendo escritos no log do sistema, só vai perceber que alguma coisa está errada no final.

Portanto, fique atento aos logs e aprenda a interpretar os valores e resultados preliminares. Ah, não se engane com as médias!!

6. Meu primeiro resultado! E agora, o que faço?

Ótimo, se você conseguiu chegar até aqui, já deve ter alguma bagagem com coisas interessantes que aprendeu sobre o processo prático da modelagem. No caso dos resultados de modelo, certamente haverá um arquivo final com os valores/campos e, dependendo do sistema empregado, esse arquivo poderá ser convertido para um formato padrão (por exemplo, grib, netcdf, hdf etc) que, além de ocupar menos espaço, já disponibiliza o arquivo final para visualização em um software específico (por exemplo, o GrADS). Geralmente, o conjunto dessas rotinas de conversão é chamada de pós-processamento e geralmente, são feitas interpolações e outros procedimentos matemáticos que podem embutir pequenos erros oriundos de aproximações. Fique atento às fontes de erros nos seus resultados e saiba ponderá-las em sua avaliação. Procure também comparar os dados brutos (antes do pós-processamento) com os dados finais (pós-processados).

Certamente, estas informações podem lhe assegurar um controle e visão melhores sobre os resultados que você obteve.

Ao sinal de qualquer dúvida sobre os resultados gerados, se você tiver tempo, refaça os experimentos e tire suas dúvidas. Além disso, a avaliação estatística e/ou interpretação física dos resultados deve ser feita de forma bastante consistente. Leve em consideração os tipos de avaliação que outros pesquisadores estão fazendo e tente comparar os seus resultados com os deles. Isso ajuda e muito na validação dos seus experimentos e também vai lhe assegurar que a sua metodologia não contém falhas.

7. Meu tempo acabou, o que faço?

Isso vai acontecer e, geralmente no mestrado – em que se tem pouco tempo para executar a parte prática, você pode se desesperar com a qualidade dos seus resultados.

Se você tomar todos os cuidados e rever sempre os seus passos, dificilmente passará por algum problema por culpa sua.

Acredite, erros todos comentem e perder o tempo que se tem para uma determinada tarefa, é o pior deles. Então, tome os devidos cuidados e extraia o máximo que puder do aprendizado da prática de modelagem. Com certeza, numa outra oportunidade, você estará mais calejado e esperto para enfrentar novos desafios e saberá como começar…

Outras dúvidas…

Na verdade, este tópico não é sobre dúvidas, mas sim recomendações. Sempre que você estiver desenvolvendo algo, seja minucioso, documente tudo o que você está fazendo. Se a sua memória é fraca, certamente você estará se livrando de um imprevisto ou de ter que bolar uma solução para um problema que você já resolveu. Para as rotinas e scripts que você escrever, utilize o Doxygen ou o ProTeX para gerar a documentação. É justo com você, porque agrega valor ao seu trabalho e justo com quem vai colaborar ou dar continuidade aos desenvolvimentos que você iniciou. Lembre-se que linguagem de máquina é para máquina, humanos lêem textos.

Se ao escrever a documentação você ficar na dúvida se escreve em português ou em inglês, não exite: escreva em português.

Sempre tem alguém que diz “tem que escrever em inglês porque se houver alguma colaboração de fora, todos têm que entender”. Isso está correto, desde que se saiba escrever corretamente em inglês… não adianta nada escrever em inglês se apenas os nativos procurarem a documentação para ler, e vai ser pior se estiver em inglês mal escrito. Portanto, a menos que alguém se disponha a revisar a documentação, escreva em bom português mesmo. Vale lembrar que a documentação, além de ajudar no entendimento dos seus programas, ajuda também a escrever o trabalho final ou relatório.

Ao escrevermos, sempre confrontamos e revisamos idéias anteriores e fixamos o que sabemos.

Boa sorte!

PS.: Este texto deverá ser melhorado ao longo do tempo.

Ler uma lista de arquivos em uma rotina fortran

Esses dias estava tentanto executar uma rotina em fortran que lia um arquivo texto e convertia em binário. Como eram vários arquivos a serem lidos, eu tinha duas opções: primeira, que seria fazer um script em shell com um loop para ler os arquivos, gerar a rotina para ler cada arquivo e executar; segunda, melhorar a rotina para que ela pudesse ler uma lista com arquivos e executar a conversão para cada arquivo lido da lista. É claro que a segunda opção é mais eficiente e elegante, e também a que dá mais preguiça de pensar. Eis a solução (não sei se é a melhor, mas funciona):

program le_lista_arquivos                                                                                                             
   implicit none
 
  ! Variaveis:
  ! file: e o nome do arquivo a ser lido
  ! filelist: e o nome da lista com os arquivos a serem lidos
  ! cont: e um contador
  ! ierro: e uma variavel de status (se ierro=1, entao ocorreu erro de I/O)
  ! total: vai receber a quantidade total de arquivos lidos
 
  integer                            :: cont, total, ierro
  character(len=200)                 :: arquivo, lista
  character(len=200), dimension(500) :: vetor
 
  call getarg(1,lista)
 
  open(unit=10,file=trim(lista),status="old",form="formatted")
 
  cont=0
 
  do  
 
    read(10,"(A)",iostat=ierro) arquivo

    if(ierro.ne.0) exit

    cont = cont + 1 
    vetor(cont) = trim(arquivo)

    print *, "Arquivo: ", arquivo
 
  enddo
 
  total=cont
 
  close(10)
 
  print *, "Numero de arquivos lidos: ", total
 
end program le_lista_arquivos

No programa acima, há um loop que se encarrega de ler um arquivo de texto (lista) cujo conteúdo é o nome de cada arquivo texto, da seguinte forma:

$ more lista
 arquivo1.txt
 arquivo2.txt
 arquivo3.txt
 ...

O pulo do gato nesse programa, é o comando “call getarg” que vai permitir que a rotina tome o arquivo “lista” como se fosse um argumento.

Dentro desse loop em que os nomes dos arquivos são lidos, pode-se realizar as operações que se desejar com o conteúdo deles.

Para compilar, pode-se fazer assim (usando o ifort, mas funciona também com o gfortran):

$ ifort -traceback -o le_lista_arquivos.x le_lista_arquivos.f90

E para executar, basta fazer:

$ ./le_lista_arquivos.x lista

Como resultado, a execução do programa imprime a lista dos arquivos a serem lidos e informa a quantidade de arquivos lidos:

 
Arquivo: arquivo1.txt
Arquivo: arquivo2.txt
Arquivo: arquivo3.txt
Arquivo: arquivo4.txt
Arquivo: arquivo5.txt
Arquivo: arquivo6.txt
Arquivo: arquivo7.txt
Arquivo: arquivo8.txt
Arquivo: arquivo9.txt
Arquivo: arquivo10.txt
Arquivo: arquivo11.txt
Arquivo: arquivo12.txt
Arquivo: arquivo13.txt
Arquivo: arquivo14.txt
Arquivo: arquivo15.txt
Arquivo: arquivo16.txt
Arquivo: arquivo17.txt
Arquivo: arquivo18.txt
Arquivo: arquivo19.txt
Arquivo: arquivo20.txt
Numero de arquivos lidos: 20

A opção “-traceback” é interessante porque, mesmo quando a compilação é bem sucedida, pode ser que na execução exista algum erro, como a falta de um argumento. Assim, se você tentar executar o programa “le_lista_arquivos.x” sem o argumento “filelst”, você vai receber a seguinte mensagem de erro:

$ ./le_lista.x
forrtl: severe (43): file name specification error, unit 100, file "Unknown"
Image              PC                Routine            Line        Source             
le_lista.x         000000000046FAFA  Unknown               Unknown  Unknown
le_lista.x         000000000046E5F6  Unknown               Unknown  Unknown
le_lista.x         000000000042FC60  Unknown               Unknown  Unknown
le_lista.x         0000000000405E6E  Unknown               Unknown  Unknown
le_lista.x         00000000004053AF  Unknown               Unknown  Unknown
le_lista.x         00000000004104ED  Unknown               Unknown  Unknown
le_lista.x         0000000000402BA9  MAIN__                     13  le_lista.f90
le_lista.x         0000000000402A9C  Unknown               Unknown  Unknown
libc.so.6          00007F03CA7A1EFF  Unknown               Unknown  Unknown
le_lista.x         0000000000402999  Unknown               Unknown  Unknown

Na lista de erros de execução do ifort, há a seguinte descrição da mensagem “severe (43)”:

severe (43): File name specification error
FOR$IOS_FILNAMSPE. A pathname or file name given to an OPEN or INQUIRE statement was not acceptable to the Intel Fortran RTL I/O system.

Repare que na mensagem de erro, há a indicação de que na linha 13 há uma problema. Na verdade, a mensagem se refere ao arquivo “filelst” que está declarado na linha 13 do programa, que está sendo indicado pela mensagem “severe (43)”.

É isso!

Erro: cannot open source file “asm/errno.h”

Se você está tentando compilar algum programa em linguagem C ou que precisa ler algum reader do sistema escrito em linguagem C e o compilador fortran da Intel (ifort) não consegue encontrar o header correto (no caso errno.h) e recebe o seguinte erro:

catastrophic error: cannot open source file "asm/errno.h"

Pode ser que você não tenha as bibliotecas extras do GCC instaladas por completo no seu sistema. Para resolver, basta instalar o pacote gcc-multilib:

$ sudo apt-get install gcc-multilib

Referência: http://secure-software.intel.com/en-us/forums/showpost.php?p=149314