Índice de software LAPS README Este arquivo LAPS README (versão 0-56-9) é visível na WWW através da página inicial LAPS em laps. noaa. gov 1.0 Informações gerais LAPS Abaixo está uma descrição do arquivo tar contendo a ingestão de dados LAPS E código de análise. O componente preditivo do LAPS (MM5, RAMSSFM, ETA) é configurado separadamente (ver Seção 3.4). Observe que o GSD oferece suporte para o software LAPS somente se um acordo prévio for feito para esse efeito. Além disso, as perguntas relativas a LAPS devem ser feitas em referência ao arquivo final lançado mais recente que não podemos suportar versões antigas do código LAPS. Também é recomendável que os usuários do LAPS tentam tirar proveito das atualizações mais recentes do LAPS ao importar periodicamente um novo arquivo tar a cada alguns meses ou mais. Verifique a LAPS Software Page em laps. noaa. govcgiLAPSSOFTWARE. cgi para obter informações sobre lançamentos recentes. Um fluxograma para o software LAPS pode ser encontrado em: laps. noaa. govdocSlide1.png 1.1 LAPS Software Disclaimer Open Source LicenseDisclaimer, Forecast Systems Laboratory NOAAOARGSD, 325 Broadway Boulder, CO 80305 Este software é distribuído sob a definição Open Source, que pode Seja encontrado em opensource. org. Em particular, a redistribuição e o uso em formas de origem e binárias, com ou sem modificação, são permitidos desde que sejam atendidas as seguintes condições: - Redistribuições do código-fonte devem reter esta notificação, esta lista de condições e a seguinte declaração. - As redistribuições em formato binário devem fornecer acesso a este aviso, esta lista de condições e o seguinte aviso e o código-fonte subjacente. - Todas as modificações neste software devem ser claramente documentadas e são da responsabilidade exclusiva do agente que efetua as modificações. - Se forem feitas modificações significativas ou aprimoramentos neste software, o GSD Software Policy Manager (softwaremgr. fslnoaa. gov) deve ser notificado. ESTE SOFTWARE E SUA DOCUMENTAÇÃO ESTÃO NO DOMÍNIO PÚBLICO E SÃO FORNECIDOS COMO É. OS AUTORES, OS GOVERNOS DOS ESTADOS UNIDOS, SUAS INSTRUMENTAÇÕES, OFICIAIS, EMPREGADOS E AGENTES NÃO FAZEM GARANTIA, EXPRESSA OU IMPLÍCITA, SOBRE A UTILIDADE DO SOFTWARE E DOCUMENTAÇÃO PARA QUALQUER FINALIDADE. NÃO ASSUMEM NENHUMA RESPONSABILIDADE (1) PARA USO DO SOFTWARE E DOCUMENTAÇÃO OU (2) PARA FORNECER APOIO TÉCNICO AOS USUÁRIOS. 2.0 Instalando e executando o código LAPS IngestAnalysis 2.1 Requisitos do sistema UNIX As plataformas UNIX suportadas incluem. Estamos trabalhando na adição de mais plataformas suportadas. Congratulamo-nos com sugestões sobre como modificar LAPS para outras versões de plataformas. Observe que não podemos garantir a portabilidade de LAPS para todas essas outras plataformas (por exemplo, Windows NT). 2.1.1 Biblioteca NetCDF O pacote netCDF é necessário para as voltas, sugerimos usar a versão 3.6.0 disponível aqui: uma vez que o netCDF esteja corretamente instalado, verifique se os programas ncdump e ncgen estão no seu caminho (por exemplo, o ncdump), para que o configure Encontre-os e forneça o pacote de voltas com o caminho adequado. A configuração do caminho também ajudará os programas LAPS a serem executados corretamente. Observe que essa especificação de caminho irá substituir qualquer coisa fornecida com o argumento de linha de comando --netcdf. O NetCDF é uma estrutura de formato geral. O formato detalhado de cada arquivo de dados é auto-descrevente (via ncdump) e é espelhado em um arquivo estático separado chamado CDL. Este CDL pode ser a versão do GSDs ou a outras pessoas. Se possível, verifique se a sua biblioteca netCDF foi construída para ser compatível com o mesmo compilador FORTRAN que você está usando. A biblioteca netCDF contém rotinas C que devem ser vinculadas com as rotinas LAPS FORTRAN. Consulte a discussão na seção 2.2.2.1 para obter detalhes sobre como solucionar problemas. 2.1.2 Perl O pacote perl também é necessário para as voltas, está disponível via internet em qualquer site perl, como perl. Perl 5.003 ou superior é necessário. Verifique se perl está no seu caminho (por exemplo, qual perl). 2.1.3 make Laps Makefiles funciona melhor usando gnu make (versão 3.75 ou superior). Isso pode ser baixado a partir de sites gnu, como o seguinte URL: gnu. orgsoftwaremakemake. html. Você pode verificar sua versão do gnu make digitando make - v. Alguns fornecedores fornecidos também podem funcionar, no entanto, se você achar que está tendo problemas nesta área, tente obter e usar o gnu make. Verifique se a marca está no seu caminho. 2.1.4 Compilador C Em geral, um compilador C compatível com ANSI deve ser usado. Em algum hardware, a conformidade ANSI requer uma bandeira do compilador, se você não tiver certeza de verificar a documentação para o compilador. Algumas plataformas, como Solaris e HPUX, não possuem um compilador C compatível com ANSI por padrão. Se você não comprou esse produto adicional do fornecedor, recomendamos GNU C (gcc) disponível no gnu. orgsoftwaregccgcc. html. Verifique se o compilador C está no seu caminho. Com o compilador pgf90 FORTRAN, recomenda-se o pgcc. Com o compilador IF if for FORTRAN, recomenda-se icc. Para plataformas AIX, Solaris, HPUX, cc é recomendado. 2.1.5 Compilador FORTRAN Tenha em atenção que o LAPS usa memória dinâmica dentro do código FORTRAN na forma de matrizes automáticas e alocáveis, bem como outras construções FORTRAN 90. Isso implica que você precisará de um compilador f90 ou o equivalente. LAPS não funcionará mais na maioria dos compiladores do f77. Verifique se o compilador FORTRAN está no seu caminho. Para plataformas IBMAIX, recomenda-se xlf. Para as plataformas Solaris HP-UX, o f90 funciona bem. Para as plataformas Linux (i386, i686, x8664), sugere-se que o ifort (versão 12.0.4 ou posterior) esteja sendo testado. O gfortran está sendo testado Para plataformas Linux (Alpha chip), é sugerido o forte (uso serial normal). 2.1.6 Espaço em disco Os requisitos de espaço em disco para LAPS variam dependendo de fatores como o tamanho do domínio e os parâmetros de purga. Como guia geral, 10 MB seriam necessários para o código-fonte. São necessários cerca de 30 MB para binários executáveis. 500 MB para 1GB são normalmente necessários para 12-24 horas de dados de saída. É necessária uma quantidade de espaço semelhante para os dados de entrada brutos. 2.1.7 Memória Etc. (ulimit) As configurações de ulimit devem ser colocadas de forma ilimitada, se possível. Os requisitos de memória variam para LAPS. Como guia geral, é necessário 128 MB e 256 MB são preferidos. Mais é necessário para grandes domínios. Para domínios muito grandes, um guia aproximado da memória necessária seria 100 x NX x NY x NZ bytes. 2.1.8 Traçar a biblioteca de gráficos NCAR (opcional) O Lapsplot é um programa de traçado opcional, portanto os gráficos NCAR são opcionais. Se você deseja construir o processo lapsplot, o acesso a bibliotecas de gráficos NCAR é necessário para que você possa executar o comando ncargf77 no LAPS Makefiles. Você pode baixar o software de gráficos NCAR grátis (NCL) no URL mostrado abaixo. Observe que as bibliotecas de gráficos NCAR devem ser construídas contra o mesmo compilador FORTRAN que está sendo usado em LAPS. O executável lapsplot. exe é um programa interativo que lê nos arquivos NetCDF LAPS e produz um arquivo gmeta como saída. O arquivo gmeta pode ser exibido usando outros utilitários de gráficos NCAR como ctrans e idt. O Lapsplot foi projetado para funcionar com a versão 3.2 (ou superior) de gráficos NCAR. A variável de ambiente NCARGROOT deve ser configurada ao configurar, compilar ou executar o lapsplot. exe. Antes de executar o configure, verifique se ncargf77 andor ncargf90 está no seu caminho. Se você estiver usando um compilador diferente do f77, verifique depois de executar o configure para ver se o item certo foi feito inspecionando NCARGFC e FC dentro de srinccludemakefile. inc. NCARGFC deve apontar para o script ncargf90 ou ncargf77. Se configure quiser usar o ncargf90 e você ainda não possui um, considere fazer um link suave chamado ncargf90 que aponte para o script ncargf77 ou copiando ncargf77 para uma nova localização e chamando ncargf90. Se você tiver apenas um script ncarg90 (ou seja, não ncargf77), você também pode fazer um script chamado ncargf77 que lista o compilador f77. Isso pode ajudar a configurar o teste para fazer a mudança de ncargf77 para ncargf90. O Lapsplot é construído como uma opção especial para fazer, simplesmente digite make lapsplot ou make installlapsplot. Não é construído com uma simples execução. Para obter o lapsplot para compilar e vincular corretamente, pode ser necessário editar sua própria versão do ncargf90 ou mesmo o script ncargf77 original. Verifique se o compilador FORTRAN apropriado, as bandeiras de carga e as bibliotecas de carga estão configuradas no script. Uma possível alternativa para corrigir ncargf77ncargf90 é editar srcincludemakefile. inc com o caminho completo para NCARGFC e compilador apropriado para FC (e, possivelmente, sinalizadores de compilação) para o seu sistema (depois de executar o configure). Às vezes, a ligação de lapsplot pode mostrar referências indefinidas às rotinas da biblioteca. Isso muitas vezes representa uma incompatibilidade entre gráficos NCAR e várias bibliotecas de sistemas. Possíveis soluções para isso incluem a edição da lista de bibliotecas dentro do script ncargf77ncargf90 ou a ativação ou desativação do sinalizador - Bstatic. Lapsplot pode ser modificado para mostrar limites políticos fora dos EUA. Os seguintes arquivos de dados são relevantes do diretório staticncarg: continenteminusus. dat, statefromcounties. dat e uscounty. dat. Esses arquivos de fronteira política são armazenados em formato bigendiano. Estes deveriam ser convertidos manualmente antes de usar o lapsplot, se sua máquina estiver esperando littleendian. Vamos considerar automatizar isso no futuro. Para executar o lapsplot manualmente, você pode fazer o seguinte. 1. setenv LAPSDATAROOT para o caminho correto 2. execute LAPSINSTALLROOTbinlapsplot. exe (responda as perguntas que ele interage de forma interativa) Por favor, note que o lapsplot é fornecido para ajudá-lo a verificar como sua implementação LAPS está funcionando. Além dos produtos da Web pré-gerados e on-the-fly, não temos outros pacotes de planejamento ou visualização disponíveis para distribuição com LAPS neste momento. Muitos usuários interagiram LAPS com seu próprio software de exibição (por exemplo, IDV, VIS5D, AVS, IDL, NCL, NCVIEW, GEMPAK). O IDV é útil, pois pode ler a saída de análise LAPS Grib-2 que pode ser gerada através do programa laps2grib. Não hesite em postar perguntas sobre os vários pacotes de traçadas para o fórum online LAPS. Outra nota de interesse é que o LAPS é visualizado como parte integrante dos sistemas AWIPS ALPS. Se você tem AWIPS (incluindo AWIPS-I ou AWIPS-II), então LAPS deve estar executando sobre ele e você pode visualizar sua saída na estação de trabalho. 2.1.8.1 Web Display O arquivo gmeta pode ser convertido em um arquivo GIFJPEG para exibição na web usando ctrans em conjunto com o pacote netpbm de programas de conversão de imagem que podem ser baixados no link abaixo. Dentro deste pacote, nossos scripts de exibição da web usam os programas rastopnm e ppmtogif. Temos a opção de fazer imagens GIF pré-geradas que podem ser exibidas na web, invocando o argumento de linha de comando simulado sched. pl - f. Consulte a seção 2.4 para obter mais informações sobre sched. pl. As imagens da Web aparecem como arquivos. gif no diretório lapsprdwwwanal2d. Os scripts associados relacionados à web (para análises), como etc. wwwfollowupncarg. sh, estão no repositório. Esses scripts de wrapper executam lapsplot. exe e exibem as imagens GIF adequadas para exibição na web. O conjunto de produtos de imagem da web é definido com arquivos de configuração em staticwwwlapsplot .. As tabelas de cores são especificadas no staticwww. lut. Outros parâmetros de traçado definíveis pelo usuário estão localizados em staticlapsplot. nl. Um script separado relacionado à web é a nossa página on-the-fly que está contida em etc. wwwnph-laps. cgi. Este script CGIPERL pode ser executado através de um servidor web. Isso também chama um conjunto de scripts que envolvem o lapsplot. exe. O (s) sistema (s) de arquivos que executam LAPS devem ser visíveis em seu servidor web. Depois de executar a configuração, as seguintes etapas ajudarão a configurar esta página da web. 1) edite etcwwwnph-laps. cgi e configure o webroot para ser o diretório raiz do servidor da web (raiz do documento) 2) edite etc. bwlaps. cgi e configure o webroot como o diretório raiz do servidor web 3) edite o arquivo etc. wwwnph-laps. cgi E configure o ncargroot para ser o diretório raiz da instalação Gráficos NCLNCAR 4) mkdir - p webrootrequest 5) cd webrootrequest ln - s LAPSINSTALLROOTetcwwwnph-laps. cgi. 6) cd webrootrequest ln - s LAPSINSTALLROOTetcwwwlaps. cgi. 7) Para cada NOME DE DOMÍNIO (foo): a) mkdir - p webrootdomainsfoo b) cd webrootdomainsfoo ln - s LAPSDATAROOT privatedata 8) edite etc. wwwnph-laps. cgi e defina o defaultdomain como seu domínio favorito foo dentro da lista de domínio estabelecida no passo ( 7) Neste ponto, você deve poder usar um navegador da Web e executar a página on-the-fly com algo parecido com este URL: 2.1.9 Bibliotecas externas GRIB2 Os modelos de fundo lidos pelo modelo inicialmente adivinhar o programa (LGA) Incluem arquivos formatados GRIB1 e GRIB2. Se você estiver lendo dados do primeiro modelo do modelo no formato GRIB2, então você deseja instalar essas bibliotecas. As bibliotecas externas de compressão necessárias para o processamento de arquivos com formatação GRIB2 são libjasper. a, libpng. a e libz. a. Eles geralmente são encontrados em usrlib ou usrlib64. Recomenda-se que um administrador do sistema instale essas bibliotecas externas se elas ainda não estiverem no seu sistema. (JPEG2000 e outros algoritmos de compressão de imagem são incorporados no GRIB2. O suporte da biblioteca para JPEG2000 é fornecido através da biblioteca JasPer. A implementação da compressão JPEG2000 reduz os tamanhos de arquivo até 80.) O script de configuração determinará se essas bibliotecas estão presentes. Se todos forem encontrados, configure prepara o arquivo srcincludemakefile. inc com os valores DEGRIBLIBS, DEGRIBFLAGS e CDEGRIBFLAGS, permitindo que o software lga seja compilado para ler os arquivos formatados GRIB1 e GRIB2. Sem essas três bibliotecas de compressão específicas disponíveis, o lga é criado para ler apenas arquivos formatados GRIB1, além de arquivos formatados com netCDF. Pode haver algumas ocasiões em que a biblioteca Jasper não foi detectada automaticamente por configuração. Por exemplo, se a biblioteca Jasper for colocada em um local diferente da área do sistema (usrlib), então, pode-se configurar uma variável de ambiente CPPINCLUDEPATH para a lga criar assim: setenv CPPINCLUDEPATH optjasper1.900.1include Depois de executar configure, o valor DEGRIBLIBS no makefile. inc pode ser editado manualmente para incluir as informações da trajetória para a biblioteca Jasper. Da mesma forma, as bandeiras - DUSEJPEG2000 e - DUSEPNG podem ser adicionadas ao valor de DEGRIBFLAGS. O comando do sistema unixlinux comando ldd imprime as dependências da biblioteca compartilhada em um executável executando ldd lga. exe é um comando útil na situação quando você baixa os binários pré-compilados LAPS e precisa de mais informações sobre bibliotecas compartilhadas exigidas pelo lga. exe. Consulte o diretório de origem: LAPSSRCROOTsrclibdegribREADMELIBS arquivo para obter informações adicionais. 2.1.10 GNUPLOT ImageMagick para verificação (opcional) O LAPS possui um pacote de verificação incorporado e isso precisa ser instalado de GNUPLOT e ImageMagick para serem totalmente executados. 2.2 Resumo do procedimento de instalação Para apresentar esta seção, aqui está uma lista hierárquica de alguns diretórios e arquivos principais na árvore de voltas. A estrutura LAPS padrão é mostrada na primeira árvore abaixo. Esses diretórios são criados em várias partes da seção 2.2 e além. Vários diretórios raiz são mencionados na forma de variáveis de ambiente. Estes podem, opcionalmente, ser configurados para tornar mais fácil seguir as instruções abaixo, mais literalmente. Os scripts de instalação podem ser executados sem configurar essas variáveis se você quiser inserir os caminhos associados diretamente como entrada de linha de comando. LAPSSRCROOT - O caminho completo que foi criado quando o arquivo tar LAPS foi descompactado. Isso contém o código fonte e outros softwares de suporte. LAPSSRCROOT é necessário para criar LAPS, mas não é necessário no tempo de execução. LAPSINSTALLROOT - O caminho completo dos binários e scripts instalados (bin e etc). É aqui que você cria os executáveis, configura os scripts (converte o. pl. in para. pl) e configure LAPSSRCROOTsrcincludemakefile. inc. Nota: LAPSSRCROOT e LAPSINSTALLROOT são em muitos casos os mesmos, mas não precisam ser. LAPSINSTALLROOT é necessário no tempo de execução. LAPSDATAROOT - O caminho completo para os dados de saída e namelists. Isso inclui subdiretórios de lapsprd que contêm grades de saída LAPS e arquivos de dados intermediários. LAPSDATAROOT é necessário no tempo de execução e contém todos os arquivos configurados para executar um domínio de análise localizado em um local na Terra. A árvore LAPSINSTALLROOT pode gerar vários LAPSDATAROOTs. Os dados de entrada em sua forma bruta são armazenados fora da árvore LAPSDATAROOT. Nota: LAPSDATAROOT geralmente é (e recomendado para ser) diferente de LAPSSRCROOTdata e LAPSINSTALLROOTdata, mas eles não precisam ser. Além disso, LAPSSRCROOTdatacdl e LAPSSRCROOTdatastatic são as versões do repositório e devem ser mantidos prístinos. Nota: os nomes que você obtém do tar são configurados para o nosso domínio Colorado. Mais sobre a localização de um domínio para sua própria área mais tarde. Para resumir, essas três variáveis de ambiente podem ser parte de uma árvore de diretórios ou divididas em árvores separadas, conforme discutido mais adiante em várias horas abaixo. Em muitos ambientes UNIX, grandes arquivos de dados são armazenados em um disco de dados e o código fonte é armazenado em um disco doméstico menor. Abaixo está uma estrutura de diretório de voltas típica para essa configuração. Recomendamos usar algo como esta configuração para a maioria dos usuários LAPS. Este tipo de separação torna mais fácil atualizar o código-fonte LAPS enquanto mantém seus dados intactos. 2.2.1 Desbloquear o código-fonte Coloque o arquivo tar no diretório do homedisk ou homediskbuilds. Desmarque o código-fonte das voltas usando um comando como. Prompt gzcat laps-m-n-o. tgz tar xf - prompt gunzip laps-m-n-o. tgz prompt tar - xf laps-m-n-o. tar O diretório LAPSSRCROOT será configurado um nível abaixo do arquivo tar. Se você está tendo problemas para executar o gunzip, o problema poderia ser que o arquivo laps-m-n-o. tgz estava corrompido durante o download. Nesse caso, simplesmente tente fazer o download novamente. 2.2.2 Execução Configurar Vá para o diretório LAPSSRCROOT e execute. O prompt. configure configure suporta muitas opções, o mais importante é a opção --prefix que diz fazer onde instalar o sistema de voltas (executáveis FORTRAN, Scripts Perl, etc.). O padrão (se você não usou --prefix) é instalar qualquer que seja a fonte. O uso da opção --prefix é altamente recomendado para tornar mais fácil atualizar seu código-fonte (por exemplo, importar um novo arquivo tar LAPS), sem perturbar os binários, os dados e os parâmetros de tempo de execução com os quais você está trabalhando no local. Isso acompanha o segundo diagrama de árvore do diretório mostrado acima na Seção 2.0. Por exemplo, para instalar as voltas no diretório usrlocallaps (ou seja, LAPSINSTALLROOT). Prompt. configure --prefixusrlocallaps Um ou mais diretórios de dados para executar as voltas podem ser especificados no tempo de execução, se desejar. Um conjunto único de binários pode assim suportar vários diretórios de dados como descrito abaixo. Outra opção de configuração é --arch. Configurar tenta obter a arquitetura a partir de um comando uname, mas isso pode ser substituído por ter uma variável de ambiente ARCH ou usando o --arch. Os valores permitidos para arco incluem aix, hpux, etc. Para obter mais informações sobre como passar em sinalizadores de linha de comando para configurar executar. Prompt. configure --help 2.2.2.1 Modificando Bandeiras do Compilador O script de configuração modifica automaticamente os sinalizadores do compilador e compilação, modificando srcincludemakefile. inc de acordo com o tipo de plataforma em que você está. Espero que as bandeiras funcionem bem em sua plataforma específica. Se você deseja alterar os sinalizadores do conjunto padrão, você pode fornecer argumentos de linha de comando para o script de configuração. Alguns exemplos baseados em nossa experiência são os seguintes: Solaris. Prompt. configure --cccc Para as plataformas IBMAIX, você deseja substituir o compilador FORTRAN padrão com xlf usando a opção de linha de comando --fcxlf da seguinte maneira. Prompt. configure --fcxlf Para plataformas SGI, algumas bandeiras podem ser necessárias. - mips3 parece ajudar no IRIX64 v6.2. Um segundo método de modificação dos sinalizadores do compilador é editar srcincludemakefile. inc, depois de executar o configure. Se você achar que os sinalizadores de compilação padrão não funcionam para sua plataforma ou que sua plataforma não tem padrão, você precisará experimentar para encontrar o conjunto correto de sinalizadores. Alterações no srinccludemakefile. inc modificarão automaticamente as bandeiras usadas em toda a volta. Se você encontrar bandeiras que funcionam para a sua plataforma e gostaria que as adicionássemos aos padrões de configuração, informe-nos por e-mail. No Solaris, por exemplo, você pode querer remover - C do DBFLAGS com uma edição de srcincludemakefile. inc para permitir a compilação das versões de depuração FORTRAN do software. Em algumas plataformas (por exemplo, Linux), a ligação de programas FORTRAN a netCDF e outras rotinas da biblioteca C pode precisar de ajuste. Isso diz respeito à existência e ao número de sublinhados nos nomes de rotina C quando chamados pelas rotinas FORTRAN. As correções para isso podem incluir uma combinação de alteração do número de sublinhados nas rotinas C, alterando o CPPFLAGS para LAPS ou alterando o FFLAGS para LAPS. Como exemplo, com erros ligados às rotinas netCDF nf, você pode reconstruir a biblioteca netCDF C com um número diferente de sublinhados e ajustar o FFLAGS de acordo com a página man no seu compilador FORTRAN. Em uma máquina Linux-Intel, a biblioteca netCDF pode ser reconstruída com os seguintes sinalizadores. Os erros ligados a outras rotinas LAPS C podem ser abordados com outros ajustes no CPPFLAGS (entre FORTRANUNDERSCORE e FORTRANDOUBLEUNDERSCORE) ou FFLAGS. 2.2.3 Ingerir mudanças de software Neste arquivo (principalmente Sec 2.3), uma série de mudanças manuais em potencial para código de ingestão são delineadas antes da execução da marca e LAPSINSTALLROOTetclocalizedomain. pl, especialmente se alguém estiver usando formatos de dados de ingestão diferentes dos usados padrão no GSD . Depois de se familiarizar com as mudanças necessárias para a sua implementação, recomenda-se que você desenvolva um método para salvar os arquivos editados a mão em um local seguro fora da estrutura do diretório de voltas ou usando um sistema de controle de revisão como o CVS. Esta estratégia tornaria mais fácil atualizar sua implementação de LAPS com o último arquivo de volts-m-n-o. tgz da GSD, minimizando o incômodo envolvido com modificações de software para sua implementação local. 2.2.4 Execução de execução O próximo passo é criar e instalar os executáveis, isso pode ser feito executando o seguinte (observe que a sintaxe pode variar se o shell que você está usando é diferente do shell Bourne). Prompt cd LAPSSRCROOT prompt faça 1 make. out 21 prompt faça a instalação 1 makeinstall. out 21 prompt faça installlapsplot 1 makeinstalllapsplot. out 21 Verifique se os executáveis foram colocados no diretório LAPSINSTALLROOTbin. O número total deve ser o número de EXEDIRS em LAPSSRCROOTMakefile mais 2 isso inclui lapsplot. exe. O Lapsplot só pode ser instalado se você tiver gráficos NCAR. Recomendamos usar o Gnu Make Versão 3.75 ou posterior disponível via ftp a partir de qualquer site GNU. Existem muitos outros alvos no Makefile que podem ser usados para fins especializados, como limpar as coisas para obter um novo começo. Em particular, observe que um make disney é recomendado antes de executar configurar uma segunda vez para que as coisas funcionem sem problemas. 2.2.5 Bancos de dados geográficos Atualmente, existem três bases de dados de geografia obrigatórias necessárias para localizar um domínio LAPS (com um quarto opcional). Estes são: 1) elevação do terreno (obrigatório) 2) categoria de uso do solo (requerido) 3) climatologia do albedo (requerido) 4) tipo de base do solo (opcional) Os outros caminhos de dados geográficos listados em staticnest7grid. parms representam dados que podem ser processados pelo A localização é desnecessária pelas análises. Por isso, é desnecessário baixar estes e eles não estão disponíveis na nossa página de download de software. Os dados de elevação do terreno 30 são encontrados nos arquivos tar para topo30s. Os dados de uso da terra são dados globais de 30 e necessários para calcular uma máscara de água terrestre. A máscara é usada durante a localização para forçar a consistência entre os outros dados geográficos nos limites da terra-água. A fração de terra é derivada dos dados de uso da terra usando a categoria de água, com valores válidos que variam continuamente entre 0,0 e 1,0. O banco de dados global de climatologia do albedo tem menos resolução do que o terreno ou os dados de uso da terra. O albedo é de aproximadamente 8,6 minutos (0,144 graus) e foi obtido no Centro Nacional de Previsão Ambiental (NCEP). Esses dados são usados na análise da nuvem LAPS com dados de imagens visíveis. Os dados da geografia vêm em arquivos de tar comprimidos separados do resto da distribuição LAPS. Os dados são usados no processo gridgenmodel, que é o código fortran para processar todos os dados geográficos conforme especificado pelo usuário (veja a seção 2.7.4 para obter mais informações sobre gridgenmodel). Apenas uma cópia dos dados geográficos é necessária, independentemente de quantas instalações de datacús LAPS você suporte. Os caminhos para os diretórios de dados geográficos (topo30s, landuse30s e albedoncep) são definidos como parâmetros de tempo de execução no arquivo nest7grid. parms (Seção 2.2.6). Os dados geográficos estão disponíveis na página da LAPS Home (link de software). Você encontrará os seguintes conjuntos de dados globais neste site webftp. Alguns dos dados foram subdivididos em quartershperes para download mais fácil. Selecione os arquivos necessários para seu aplicativo ou obtenha todos eles se você pretende gerar localizações ao redor do globo inteiro. 132446109 24 de agosto de 2001 topo30stopo30sNE. tar. gz 63435504 24 de agosto de 2001 topo30stopo30sNW. tar. gz 37194099 24 de agosto de 2001 topo30stopo30sSE. tar. gz 29204244 24 de agosto de 2001 topo30stopo30sSW. tar. gz 12324069 24 de agosto de 2001 landuse30slanduse30sNE. tar. gz 6118611 24 de agosto de 2001 landuse30slanduse30sNW. tar. gz 3355822 24 de agosto de 2001 landuse30slanduse30sSE. tar. gz 2808861 24 de agosto de 2001 landuse30slanduse30sSW. tar. gz albedoncepA90S000E albedoncepA90S000W albedoncepAHEADER Atualmente estamos trabalhando em um procedimento para acessar dados de maior resolução de terreno e uso do solo do USGS (pelo menos 1 arcsec ). Tipo de solo e outros bancos de dados opcionais: O processo de caducidade do processo gridgenmodel descrito abaixo na seção 3.0 também pode processar o tipo de solo, a temperatura anual média do solo e a fração de fração, mas estes não são dados obrigatórios necessários em LAPS e, portanto, não descrevemos aqui. O tipo de solo pode ser usado na análise de umidade do solo. Você verá alguma referência a essas bases de dados abaixo e adicionamos caminhos para esses dados em nosso arquivo namelist (nest7grid. parms), mas você deve inserir caminhos falsos para esses dados no caso de você não os ter disponível. O processo gridgenmodel avisará que esses dados não estão disponíveis, mas você ainda deve ver a execução de localização para conclusão (ou seja, static. nest7grid é gerada). --- 2.2.5.1 Terreno de alta resolução (sub-quilômetro) --- O terreno de alta resolução pode ser importado (experimentalmente) em LAPS através de dois métodos, o Assistente WRF (ver seção 2.2.7) e Topograbante - veja laps. noaa. govtopograbber O WRF Wizard pode ser usado para gerar um arquivo GEOGRID na mesma grade que a análise LAPS. O terreno deste arquivo pode ser importado durante a localização do LAPS, definindo o path_tottops do caminho do namelist nest7grid. parms pathtotopt30s para conter a string wps no nome do diretório. Além disso, Topograbber está em desenvolvimento e isso pode ser usado com algum trabalho adicional. Os azulejos produzidos podem precisar de algumas modificações no programa gridgenmodel. exe para que possam ser lidos. Uma segunda maneira de usar Topograbber com LAPS é gerar um arquivo de terreno WPS GEOGRID e, em seguida, lê isso durante o processo de localização LAPSSTMAS (veja acima parágrafo). 2.2.6 Localizando para domínios de dados únicos ou múltiplos Alterações de parâmetros de tempo de execução podem ser necessárias para adaptar LAPS para seu (s) domínio (s), isto inclui nomes de caminho de dados de ingestão e geografia, dimensões da grade, localização da grade e outros aspectos potencialmente do processamento de dados. Os arquivos de parâmetros são datastaticnest7grid. parms, datastatic. nl e datastatic. parms. A localização envolve várias operações. Os arquivos de parâmetros são combinados com as versões do repositório se necessário. As dimensões nos arquivos cdl também são ajustadas. Em seguida, vários programas executáveis são executados, incluindo gridgenmodel. exe e gensfclut. exe conforme seção 3.1. Abaixo estão dois procedimentos principalmente equivalentes para localizar LAPS para configurar um ou mais domínios. O primeiro é um método mais novo, mais eficiente (e altamente recomendado) usando diretórios de modelos de domínio. O segundo é o nosso método original de localização. Você quer usar o Método 1 ou o Método 2, mas não os dois. 2.2.6.1 Método de localização 1 O primeiro método é especialmente útil se você estiver usando uma árvore de dados separados ou múltiplos domínios. Também é recomendado se você estiver fazendo atualizações de software repetidas. Uma vez que você aprende esse método, pode economizar muito tempo e erros que podem ocorrer ao longo do uso do Método 2. CONFIGURAÇÃO DOS PARÂMETROS DE CORRESPONDÊNCIA Se você estiver trabalhando em um diretório de dados separado (por exemplo, usando a segunda árvore mostrada acima), você pode configurar Até uma cópia dos arquivos de parâmetros de tempo de execução (para cada janela) em um novo diretório (chamado TEMPLATE) com um subconjunto de parâmetros reduzidos. Os arquivos namelist do diretório TEMPLATE devem conter apenas os parâmetros que precisam ser alterados para cada um dos domínios das configurações no repositório, LAPSSRCROOTdatastatic. Os restantes parâmetros inalterados devem ser omitidos nas versões de TEMPLATE. Caso contrário, o namelist do modelo parece exatamente como o namelist originalmente fornecido, exceto que a seção de comentários deve ser omitida. Os parâmetros de TEMPLATE modificados geralmente incluem configurações de projeção de mapa, caminhos de dados, etc. Os parâmetros fixos remanescentes serão posteriormente mesclados automaticamente da árvore de diretório LATAISTAATATAATA pelos scripts de localização (próxima etapa). Os modelos devem ser mantidos em um local separado da distribuição LAPS e LAPSDATAROOT (por exemplo, veja o diretório do modelo nos diagramas da árvore acima). Isso evita que sejam apagados durante atualizações de software e relocalizações. Assim, os modelos podem ser considerados mais permanentes, pois contêm parâmetros dependentes da implementação local e relativamente independentes das atualizações de software. Depois de configurar o diretório do modelo, você estará pronto para executar o script windowdomainrt. pl. Aqui está um exemplo idealizado que ilustra o processo de mesclagem namelist que é feito durante a localização. E aqui está um exemplo de um modelo real para o arquivo nest7grid. parms. LOCALIZANDO com windowdomainrt. pl Gerar novas localizações, reconfigurar localizações existentes e reconfigurar localizações existentes sem remover lapsprd ou informações de log é facilitada com o script perl LAPSINSTALLROOTetcwindowdomainrt. pl (janela a seguir). O script da janela faz uso de modelos de domínio namelist que definem especificamente as localizações de usuários. O script da janela usa variáveis de ambiente LAPSSRCROOT, LAPSINSTALLROOT e LAPSDATAROOT, no entanto, as entradas de linha de comando - s, - i e - d substituem essas variáveis de ambiente conforme necessário, dependendo das necessidades do usuário. A entrada de linha de comando - t especifica o diretório do modelo de domínio e o script salva o histórico de loglapsprd se a opção de linha de comando - c não for usada ou, remova completamente LAPSDATAROOT, então um mkdir LAPSDATAROOT se - c for fornecido. As voltas sempre são sempre necessárias. O script da janela pode ser executado manualmente ao configurar ou reconfigurar localizações. Window copies the domain template namelists (partial nest7grid. parms or. nls) into a new static subdirectory which, in turn, are merged with the full namelists by script localizedomain. pl. Recall that LAPSINSTALLROOT contains bin and etc while LAPSSRCROOT contains the untarred full namelists from the repository. In the event that LAPSSRCROOT does not exist, a data subdirectory containing static and cdl must be available for use by localizedomain. pl (i. e. LAPSSRCROOT LAPSINSTALLROOT). Even though it is possible to have LAPSSRCROOTdata LAPSINSTALLROOTdata LAPSDATAROOT, this is not recommended since it does not allow multiple localizations. Templates will ensure that specific namelist modifications are merged with the untarred full namelists. Templates also ensure that specifics to a localization are merged into new software ports and new namelist variables (available with new software) are merged into existing localizations. If you decide to manually change any parameters in LAPSDATAROOTstatic after running the localization, it is suggested to make the same change in the TEMPLATE directory as well. This will help preserve your local changes in the future if you install an updated version of LAPS. 2.2.6.2 Localization Method 2 This method is included partly for historical reasons and can be useful if you havent yet learned how to use template directories andor the separated LAPSDATAROOT (see method 1). This procedure provides a result equivalent to that from Localization Method 1 and provides an alternative method (even if not recommended) of modifying the parameters. For each domain you wish to create, run. prompt cd LAPSINSTALLROOTetc prompt perl makedatadirs. pl --srcrootLAPSSRCROOT --installrootLAPSINSTALLROOT --datarootLAPSDATAROOT --systemtypelaps where the path name LAPSDATAROOT must be named differently for each data domain if there is more than one. Recall that each domain can be set up in a separate subdirectory under datadisklaps. Next, follow the setup and localization steps below. The order of the command line arguments is important, but only the first one is required. If for example a LAPSDATAROOT is not supplied, the dataroot tree location will default to where the LAPS binaries are installed via configure. Thus, the default value of LAPSDATAROOT is LAPSINSTALLROOTdata. The runtime parameters should be emplaced andor modified within each LAPSDATAROOT directory tree prior to running the localization. More details on nest7grid. parms and other parameter files are discussed in subsequent parts of Section 2. As one option you can edit the parameter files that are in LAPSSRCROOTdatastatic and tailor them for your domain. If you have LAPSDATAROOT different from LAPSSRCROOTdatastatic, then a good alternative may be to copy any parameter files you need to edit into LAPSDATAROOTstatic from LAPSSRCROOTdatastatic. Finally, you can create the static data files and look up tables specific to the domain(s) you have defined in datastaticnest7grid. parms and other runtime parameter files. Shown below is an example of running the localization for a particular laps domain. This should be repeated (with a unique dataroot) for each domain if there is more than one. prompt cd LAPSINSTALLROOTetc prompt perl localizedomain. pl --srcrootLAPSSRCROOT --installrootLAPSINSTALLROOT --datarootLAPSDATAROOT --whichtype laps 2.2.6.3 Localization with LAPS GUI LAPS has a GUI interface under development that can be used to localize the domain. This can be found in the LAPSSRCROOTgui directory. There it can installed using the installgui. pl PERL script as outlined in the local README file. 2.2.7 WRF Domain Wizard LAPS Support The WRF Domain Wizard can be used to help specify correctly navigated LAPS domain map parameters. When the Wizard is run it will write out a nest7grid. parms file for each nest that can be used as input templates for LAPS localization. 2.2.8 MPI support for LAPS wind analysis There is capability to compile and run the wind analysis (wind. exe) using MPI. We do this by doing a separate software build with mpif90 and then sched. pl runs the serial versions of most things while running the parallelized version of the wind analysis. To build LAPS using mpif90 edit the makefile. inc file, between running configure and make, adding - DUSEMPI into the CPPFLAGS. The sched script presently submits multiple processor jobs using the SGE queueing environment. We may consider adding an option to sched. pl to runsubmit directly with mpirun if that would be useful. 2.3 Raw data ingest There is a layer of raw data ingest code that may have to be modified for the individual location depending on data formats. Its purpose is to reformat and preprocess the various types of raw data into simple common formats used by the subsequent analyses. It also helps to modularize the software. Working with the ingest code is usually the largest task within the porting of LAPS. The supported component of the LAPS code is the analysis section. Ingest code is supported only if your raw data looks has the same configuration and format as GSDs raw data. It is the reponsibility of the LAPS user to modify the LAPS ingest code if necessary to generate the intermediate data files that are inputs to the analysis code. A flow chart for the ingest processes may be found at this URL: laps. noaa. govdocslide1v3.gif The default LAPS ingest code obtains raw data, generally from the GSD NIMBUS system. The raw data can either be in ASCII, netCDF (as point data), or netCDF (as gridded data - generally not on the LAPS grid). Note that the ingest code is also generally compatable with raw SBNNOAAPORT data as stored in netCDF files on the WFO-Advanced system. The ingest code processes the raw data and outputs the LAPS intermediate data files. The intermediate files are generally in ASCII for point data and netCDF format for gridded data that have now been remapped onto the LAPS grid. Most ingest code is located under the srcingest directory. When netCDf format is used for the raw data, a cdl file for the raw data is sometimes included in the source code directory. Depending on the data source, you may generally prefer one of three choices: 1) Convert your raw data to appropriate netCDF formats then run the LAPS ingest code as is. The CDLs and sample rawNIMBUS netCDF files supplied with our test dataset can serve as a guide to writing the software to do this. If the CDL is unavailable, doing ncdump - h on the actual data file will yield equivalent information. We generally do not maintain or support any software for writing raw netCDF files as this is done external to LAPS. Sometimes by posting a message to laps-users you can obtain information from other LAPS users as to how they may have implemented this step. 2) Run a process independent of the LAPS ingest code that creates the intermedate data file. 3) Modify LAPS ingest code to accept your own raw data format. This often entails writing a subroutine that reads the data and linking this routine into the existing ingest process. That process then writes out the LAPS intermediate file. Note that generating an GSD style raw data file is not here needed - all that really counts is producing an intermediate data file. Recommended only for advanced users or those who believe their modifications have enough general interest for inclusion in the baseline LAPS repository. For the model background and in-situ observations generally (1) is the best option. For gridded data (satellite or radar) options (1) or (2) usually work best. Most external users should avoid option (3) unless it is done in close consultation with LAPS staff. A key consideration is how easy it will be to update your version of LAPS and have it work with your local data. You may note the following data sources used at GSD. These data sources are what the GSD ingest code is tailored to for producing intermediate data files. Note that LAPS will still run even if some of the data sources are withheld, albeit in degraded fashion. A minimum dataset of model background and surface observations is generally needed to get reasonable results. The pathnames for the ingest data sources are assigned within the. datastaticnest7grid. parms and other. nl files and can be set accordingly at runtime. Doing a grep for path in these files will give you a quick listing of the relevant parameters. Unless otherwise specified, the time window for data in the intermediate data files should be - lapscycletime. The time window for data in the raw data files is more variable and is generally specified within the raw data (e. g. in the CDL). Further information on specific LAPS ingest processes for the various data sources is found in Section 3 of this README. 2.3.1 Model Background (lgalgb) The model first guess (background) is generally on a larger-scale grid than LAPS and is run independently. The model data is interpolated to the LAPS grid by the LAPS ingest to produce lgalgb files. The interpolation is done in time, in space, and can be from one map projection to another. This lgalgb output is distinct from the fuafsf files that are first guess files of similar format generated by the LAPS forecast model using an intermittent 4dda mode. The nest7grid. parms namelist variable fddamodelsource controls the background used in the analysis, including lga. A list of fdda backgrounds that are available with this release are specified in file etclapstools. pm - module mkdatadirs. Even though fdda subdirectories are populated with current backgrounds, the analysis can be forced to override this by making the first entry of fddamodelsource lga. The acceptable models and formats for the background model are listed in datastaticbackground. nl. Many models can be accepted in netCDF format. A new capability in LAPS is to process GRIB input without first converting to netCDF format. For Grib data to be decoded an associated Vtable. XXX needs to be found in directory datastaticVariableTables. The Vtable can be configured for either GRIB-1 or GRIB-2. However we are unable to guarentee that any model specified in background. nl will work without some software modification. Rapid Refresh (RR) grids are ftped from NCEP to GSD, then converted at GSD from GRIB to netCDF. This netCDF file is the input for the LAPS ingest process that writes lga. For more information on RR check the following URL for more info: rapidrefresh. noaa. gov Note that we often read these into LAPS as RUC (Rapid Update Cycle) look alike files. RR is also available from UNIDATA and distributed to universities through private companies like Alden. The conversion from GRIB to netCDF is done outside of LAPS by GSDs Information and Technology Services (ITS) group (in the NIMBUS system). Having the CDL should mostly be sufficient along with general knowledge of netCDF for writing out the data. Beyond that, you may wish to contact the ITS group for more info (see the reference to them in section 3.2.1). The Atlanta, Sterling, and Seattle WFOs have followed a more direct route, going from the RREta to the intermediate lga file, bypassing the netCDF file on the model grid. This includes RR on isobaric surfaces. 2.3.1.1 Acquiring Model Background Data GRIB-formatted background model files are now supported and can be directly read into lga. --- Where Can Users Find GRIB Data --- At the NCEP ftp server for real time data sets located at ftp:ftpprd. ncep. noaa. govpubdatanccfcom. These products can be downloaded from the web or via anonymous ftp. The following is a discussion for locating and acquiring NAM, GFS, and RUC model backgrounds for use with lga. The models are available in grib1 and grib2 formats as indicated. NAM Model: NAM 221 High Resolution North American grid, 32-km can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomnamprod with the directory and filenames as follows nam. nam. t.awip32.tm00 where YYYYMMDD is the current date, CC is the model cycle time (00, 06, 12, or 18) and FF is the forecast hour (00-84). awip32 indicates the 32 km North America (NCEP grid 221). GFS Models: GFS global longitude-latitude grid (360x181) 1.0 deg (fh 00-180) can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomgfsprod gfs. gfs. t z. pgrbf , and GFS global longitude-latitude grid (720x361) 0.5 deg (fh 00-180) can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomgfsprod gfs. gfs. t z. pgrb2f where CC is the model cycle time (i. e. 00, 06, 12, 18) and XXX is the forecast hour of product from 00 - 180. The 1.0 degree GFS uses file identifier pgrb (pressure-based grib) and is now available in grib2 as well when. grib2 is present. The 0.5 degree GFS uses pgrb2 (pressure-based) and is only available in grib2. RUC Model: RUC Rapid Update Cycle 40km and 20km pressure data sets can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomrucprod ruc2a. ruc2.t z. pgrb where CC is the model cycle time (i. e. 00, 06, 12, 18) and XXX is the forecast hour of product from 00 - 12 (or more). File identifier pgrb is used for the 40km resolution and pgrb20 is used for the 20km. Additional description of NCEP products can be found at nco. ncep. noaa. govpmbproducts. A master list of NCEP GRIDS ID numbers (e. g. 211) and other specifications can be found at nco. ncep. noaa. govpmbdocson388tableb. html --- How Do Users Name The GRIB Data Files --- For LAPS ingest at NOAAESRL, we have a process that automatically downloads GRIB files to a designated directory. For example, datagridgfsglobal0p5deg, datagridgfsglobal1p0deg, and datagridgfsconus211 are three directories for the GFS global 0.5 degree, global 1.0 degree and CONUS 211 domains. The files within these directories are renamed from the complex patterns listed above to filenames with the following pattern: YYJJJHHMMhhhh. Here the hhhh part represents the number of hours into the forecast. Thus a file for GFS CONUS 211 initialized on Jul 23 2008 at 1200 UTC, with a 6 hour forecast would be named datagridgfsconus211grib0820512000006. The HRRR model follows a slightly different convention of YYJJJHHMMhhmm, so that forecasts of under one hour can be represented. --- How Does lga. exe Know Where To Find The Data --- For lga. exe, the acceptable models, directory paths and file formats are identified in datastaticbackground. nl. In the example above if we wanted to use the US-scaled data, we would set bgpathdatagridgfsconus211grib, bgmodel13 (for GRIB), and cmodelGFS. 2.3.2 Radar ingest The following are intermediate files for various forms of radar data. These may have already been pre-processed (remapped) from raw data, and at this stage are in Cartesian format on the LAPS grid. A description and flow chart showing polar radar data usage in LAPS is on the Web at: laps. noaa. govalbersremapperraw. html. with some additional text details for various types of radar data in: laps. noaa. govalbersradardecisiontree. txt. These include information on which types of radar data are processed via the various intermediate data files. Further information on using individual radar ingest processes is in Section 3. Specifically we should establish whether your raw data is in polar or Cartesian form. If polar, please take a look at Polar Radar Data in section 3.2.3. NOWRAD WSI (Cartesian) data is covered separately within Section 3.2.4. 2.3.3 Surface Data Sfc Obs (lso): GSD uses surface observations as input with the default being GSDs NIMBUS netCDF format. These are generally used when running LAPS within ESRLGSD using data from public, and is only available within GSD unless one is working with the supplied test data case. Surface observations of various types, covering much of the world are available in realtime from GSDs MADIS system (with some restrictions). This data, generally in WFOAWIPS netCDF format, are distributed via the MADIS server at madis. noaa. gov. Thus MADIS is available both inside and outside ESRLGSD. The MADIS netCDF has additional variables (such as QC flags) that go beyond what is in the NIMBUS format. The supported MADIS surface observation datasets include metar (METARSYNOP), maritime (BuoyShip), mesonet, urbanet, and others. This is an excellent source of surface observations for most users outside of ESRLGSD to start with. To request a real-time data stream please go to the MADIS data application page at this link: madis. noaa. govdataapplication. html A few other METARSYNOP formats are now being supported in LAPS software as listed in the staticobsdriver. nl namelist. The GSD code is in the . srcingestsao directory, and includes routines to read and reformat various surface data types (METARSYNOP, mesonet or localLDAD, buoyship or maritime, and GPSprofiler surface obs). There is a subroutine tree outline in the srcingestsaoREADME file including information on the supported data formats for each observation type. Paths to the datasets are specified in the obsdriver. nl file. In most cases users should be able to convert their surface observations into the NIMBUS or MADIS NetCDF formats. Note that the parameters and variable names in each NetCDF dataset or directory will vary. Only observations reasonably near the standard shelter height (2 meters, except 10 meters for wind) should be included in the LSO file. Tower mounted instruments should instead be placed in the SND file using TOWER for the observation type. 2.3.4 Wind Profiler RASS ProfilersRASS (prolrs) - The raw data are obtained from GSDs NIMBUS database andor AWIPS in netCDF format where they are stored in four different directories. The data originally come from GSDs Demonstration Branch (DB) from two main networks. The 30 NPN (National Profiler Network - NOAAnet) profiler network is located mostly in the central U. S. The second network supplies boundary layer profilers for both wind and temperature, with formats including NIMBUS, MADIS Multi-Agency Profilers (LDAD), and RSA (LDAD) format. The profiler data for wind goes into the pro intermediate file, and RASS temperature profiles go into the lrs intermediate file. Note that the cdls associated with each data source indicate the time frequency of the data that our ingest code can process. The path names for the profiler data are all set in nest7grid. parms. The NPN wind profiler data is available via another route from GSD with some restrictions. This data, in WFOAWIPS netCDF format, is distributed via GSDs MADIS project at madis. noaa. gov 2.3.5 PIREPS ACARS from aircraft PIREPS (pin) - We are ingesting GSD NIMBUS and WFOAWIPS (netCDF) pirep files to translate the cloud layers from voice pilot reports into intermediate PIN files. ACARS (pin) - We are ingesting GSD NIMBUS, WFOAWIPS (netCDF) and AFWA databases for ACARS data to translate the automated aircraft observations. The wind, temperature and humidity obs are appended to our intermediate PIN file. A NIMBUS equivalent netCDF database is available (with some restrictions) on the Web via MADIS at madis. noaa. gov Note the TAMDAR is presently being screened out from the NIMBUS database while this data source is being validated. 2.3.6 RAOB Dropsonde Radiometer RAOBs (snd): GSD NIMBUS, WFOAWIPS, CWB, or AFWA databases. These are available in real-time from GSD with some restrictions. RAOB data in WFOAWIPS netCDF format is distributed via GSDs MADIS project at madis. noaa. gov Dropsondes (snd): A Dropsonde ingest module has been developed for the CWB database. An ingest module has also been developed for AVAPS. We now allow the SND format to be used as input (so far just for the AIRDROP project). For the SND input option, the ingest program simply does a time windowing of the raw data. We may include modules for other (e. g. netCDF) databases in the future, such as NIMBUS or WFOAWIPS. Radiometers (snd): A radiometer ingest module has been developed for the MADIS database - madis. noaa. gov 2.3.7 Satellite Satellite Image Ingest (lvd): GOES data ingest. Data is acquired at GSDs ground station and stored in netCDF. We also obtain AWIPSNOAAPORTSBN data (stored in netCDF). Ingest of Air Force Weather Agency (AFWA) satellite data is also possible. Raw GVAR satellite data can be ingested and navigated using GIMLOC routines. These files are in NetCDF. Further details can be found in the file srcingestsatellitelvdREADME. The ITS group at ESRLGSD has put together a converter from McIDAS AREA files to the GVAR netCDF format (lvd input). These files are similar to the raw GVAR, except they have latlon arrays added to make the files self navigating. The AREA files can be obtained from sources such as the NESDIS ADDE server. The Java based converter package can be found online at this URL: Note that the NESDIS ADDE server can also supply worldwide geosynchronous satellite data. Some tweaking of satellite coordinate and image dimensions may be needed when setting up the McIDAS package, as can be seen in the sample illustration (link below). Programs like ncview can be helpful to check if the window is navigated properly in the GVAR netCDF files prior to running the LAPS satellite ingest. Other work has been done in Italy to ingest Meteosat Second Generation data into LAPS, for example at ISAC. Another option under development is to use flat files (ascii files generated by RAMSDIS or binary data) as input. The flat file ingest was still under development as of 3-11-98. Generally it is best to convert your data into either GVAR NetCDF or remap it to create the intermediate LVD files. Satellite Sounder Ingest (lsr): GOES satellite sounder data ingest. Program lsrdriver. exe processes data from both satellites. Product files are yyjjjhhmm. lsr and stored in subdirectories lapsprdlsrsatid. Nineteen channels. Output is Radiance. The namelist datastaticsatsounder. nl defines the appropriate parameters for this ingest process. Only the moisture analysis is using this product. Currently GSD public sounder files in netCDF format are processed. This data is useful only when GOES Vapor (GVAP) is unavailable. Satellite derived soundings (snd): We have interfaces to GOES binary and MADIS POES (Polar Orbiter) formats. AFWA database format was previously used at GSD though not currently. The output represents derived profiles of temperature and moisture. For other formats you may wish to supply your own routine to convert your raw data into the snd format. Cloud Drift Winds (cdw): We are ingesting the ASCII satellite cloud-drift wind files for use in the wind analysis. These come from NESDIS (via NIMBUS) as well as from CWB and AFWA. We can also utilize netCDF files from MADIS. Both NESDIS and MADIS files are included in our sample data set. GPS: LAPS uses GPS data from NIMBUS netCDF files. The precipitable water is used in the humidity analysis. STMAS is being designed to use the signal delay directly instead of the PW. The netCDF files are available online at ftp:gpsftp. fsl. noaa. gov where they are named according to GPSIPWCDFYYDDDHHMM0030o. nc. The leading GPSIPWCDF of the names would have to be stripped off to be used in LAPSSTMAS. There are plans to make files similar to the NIMBUS ones available in AWIPS-II, though again filenaming conventions may need to be addressed. MADIS (LDAD) mesonet files also carry the GPS PW and related data, including surface obs. However there may be some questions about the latency of this data feed for GPS. Based on tests conducted in 2011, with a LAPS cycle that begins at about 20min past the top of the hour, one can generally expect only 5-10 of the GPS data to be avaliable via MADIS when the code is configured to seek the data. 2.3.9 Other Data Sources Radar VAD Algorithm winds (pro) GSD NIMBUS netCDF database, from WSR-88D algorithm output. GSD obtains this from NCEP and does not presently redistribute it. SODAR data (pro) - This is treated in a similar manner to wind profilers and can be processed by LAPS ingest to appear in the PRO file. This is available as part of the RSA project at Kennedy and Vandenberg Space Centers and comes into netCDF format via AWIPSLDAD. Met Tower data (snd) - This is treated in a similar manner to RAOBs and can be processed by LAPS ingest to appear in the SND file. This is available as part of the RSA project at Kennedy and Vandenberg Space Centers and comes into netCDF format via AWIPSLDAD. Radiometric Profiler (snd): We have an interface to radiometric profilers (in netCDF via NIMBUS) that can be used for the temperature and humidity analyses. Lightning Data: Although the LAPS repository doesnt yet have any lightning data ingest it is being considered to do this in terms of a simulated 2-D reflectivity that is one of the components of the VRC intermediate file. 2.4 Running LAPS Analyses LAPS runs in real-time under cron there is a sample cron script in LAPSINSTALLROOTutilcronfile. Referring to this cron, you can see that once each hour (or other cycle time), the main. etcsched. pl runs. As an example at ESRL, we run the sched. pl hourly at :20 after the top of the hour. By inspecting the sched. pl file you can see the various executables that are run in a certain order. Various command line arguments are documented within sched. pl (such as - d 0.25 that is useful for a 15-min cycle when the latency is 20 minutes). You might want to modify the sched. pl file for your needs. In the sample cron script several ingest processes are run separately from the sched. pl. For example the satellite ingest (lvd) is run several times per hour and utilizes. etclapsdriver. pl. NOWRAD Radar ingest (vrc) is also run at more frequent intervals. You might also choose to run remappolarnetcdf. exe for radar ingest in this manner. On many unix systems jobs that run in cron do not have access to the environment defined by the user. They instead use a system default environment defined in etcprofile thus perl may not be in the PATH. The cron file uses the full path to perl to ensure that this will not be a problem. If the path to ncgen is not in etcprofile, then you may want to add this to your own. profile file. Each script in the cron requires the path to laps as a command line argument. A second optional argument specifies the path to the laps data directory structure this path defaults to fullpathtolapsdata if not provided. The utilcronfile is created by the configure step. Much of the needed editing has already been done in the creation of this file. You might see some remaining . constructs though that can be edited either manually or by running the cronfile. pl (next paragraph). The lapsdataroot can be replaced with your path to LAPSDATAROOT and the optional followup can be replaced with anything you wish to run after the sched. pl has completed (using a semicolon to separate the two commands). There is also a script called etccronfile. pl that creates a modified version of utilcronfile tailored to a given domain. This script can be run manually and the output location of the cronfile is located in LAPSDATAROOTcronfile. 2.4.1 Cron timing considerations The frequency of the cron entries for running sched. pl is defined to be the LAPS cycle time. This should correspond to the value of the lapscycletime parameter within the nest7grid. parms file. The best timing of the cron is often related to the arrival time of the raw surface observations. For example, if most of the surface data arrives within 20 minutes of the observation time, then running the cron 20 minutes after the systime would be optimum. The time window for acceptance of surface stations in the LSO file can be controlled by runtime parameters in obsdriver. nl. In most cases, the data cutoff time window for 3D observations is - lapscycletime2 or - lapscycletime. For example an hourly LAPS cycle accepts RAOB data from a -60 minute time window and ACARS from a -30 minute window. 2.4.2 Purging Output Files The script etcpurger. pl purges the lapsprd output files and is in turn run by the sched. pl. There are default settings in place for the number of files and age of files to be kept. These can be overridden in three ways. 1) The sched. pl command line options - r - m N, where N is the (default) maximum number of files to be kept in each product directory by the purger 2) Overrides can be read in from datastaticpurger. dat. This file can be modified by the user to optimize the purging in various domains. One can review the purger. pl script to see how the purger. dat information is used. 2.4.3 STMAS and other configurations Within the LAPS cron the call to sched. pl can have some optional command line arguments that adjust the runtime options. The default is to run both surface and 3-D analyses from the traditional version of LAPS. Here are examples of some other alternatives: 1) STMAS-2D surface analysis only prompt perl sched. pl - M stmasmg. x other regular options Note that when running STMAS-2D analyses, the lgbonly parameter in the background. nl namelist can be set to. true. for improved runtime efficiency. 2) traditional LAPS surface analysis only prompt perl sched. pl - M lapssfc. x other regular options prompt perl sched. pl - V STMAS3D other regular options 2.5 Test data case Tar files containing test data (called lapsdata) are available that contain a snapshot of several hours worth of laps data from the Colorado domain using namelist settings taken from the repository. The tar files include intermediate files from the ingest code plus outputs from the analysis code. Several consecutive analysis cycles are posted with one file per cycle. Included are the contents of the lapsprd, time, static, and log subdirectories under data or LAPSDATAROOT. The log files are useful for diagnosing any differences in output you may observe. The contents of the various directories are outlined elsewhere in this README file. The data was created using the latest software release. Our users can download this data at this URL: It is suggested here to test the localization procedure to ensure that all the static files needed to run LAPS are present. To do this, check that the paths to the geography data are correct in TEMPLATEnest7grid. parms andor LAPSDATAROOTstaticnest7grid. parms. When running LAPS as a whole for the archived data, the etcsched. pl script will accept a - A command line argument. This forces the script to run for the time you are inputting instead of the current time. An example call is shown as follows. prompt perl sched. pl - A dd-mmm-yyyy-hhmm LAPSINSTALLROOT LAPSDATAROOT where the inputted dd-mmm-yyyy-hhmm value is the date (for example 28-Aug-2007-1500). This date can be inferred from the contents of LAPSDATAROOTtimesystime. dat. Best results are obtained when using a time just prior to the latest raw data tarfile time. One can also initiate individual executables (bin directory) listed in the sched. pl to run on the test data. This often helps in getting a better match between your output and ours. Note that LAPSDATAROOT needs to be set as an environment variable when executables are run individually. The time of the run is specified in LAPSDATAROOTtimesystime. dat. This can be modified if needed if you want to try a slightly different time from the one supplied. To do this, interactively run the script LAPSINSTALLROOTetcsystime. pl and write the standard output to LAPSDATAROOTtimesystime. dat. Note that for any given process or set of processes, deviations from the GSD output may be caused by differences in the inputs as well as machine roundoff error. Most, but perhaps not all of the input data is supplied. One main area to check would be differences in available raw background data files. Having all of the data history from lapsprd may also be an issue this may be less of a problem if you run laps for the latest hour of data that is supplied. The history is then supplied from earlier lapsdatalapsprd output. Output differences can be tracked down by recompiling specific analyses with the - g option. This can be done by typing make debug in the appropriate src directories. Various debuggers can then be used such as dbx. Examination of the log files again is helpful. We have a new script (in 2004) called casererun. pl that can be used for archive data runs. We have yet to try it on the supplied test data case though it could prove to be useful. 2.5.1 Analysis Only Test You may want to check that any analysis outputs from this time are not present, leaving only the ingest outputs in place. This may improve the results of comparisons of your own output with GSD analysis output, though this step is not always necessary. You might consider adding the - T command line option when you run sched. pl so that we run the analysis executables only thus skipping the ingest processes. This can be done if the ingest outputs (i. e. analysis inputs) are already present in the various lapsprd subdirectories. One way to supply the analysis inputs is as follows for each input (taken from a list of ingest outputs, see section 3.2): prompt cp testdatalapsprdinputlist LAPSDATAROOTlapsprdinputlist prompt cd LAPSDATAROOTlapsprd prompt ln - s testdatalapsprdinputlist. 2.5.2 Ingest Analysis Test For this type of test, you will want to download the rawdata tar files into your rawdata directory to start the processing of LAPS. Recall that the rawdata directory is on a separate tree than LAPSDATAROOT. Raw data formats and filename conventions are consistent with the default namelist settings taken from the repository. This is generally in NIMBUS (self describing netCDF) format with associated file naming conventions. A typical filename on NIMBUS looks like this: 0606701000100o meaning yydddhhmmHHMM where ddd is the day of year, hhmm is the time of day and HHMM is the file recurrence interval. The o at the end means that observations are binned into files according to observation time (instead of r for receipt time) More about NIMBUS is detailed in publications on the web at this URL: fsl. noaa. govitspapersjbams94.html Note that with the RUC grib data there are two directories. The one with soft links (and without the. grib at the end of the filenames) is the one to use. Time information will be needed in the form of datatimesystime. dat this can be extracted from the lapsdata tar file. The rawdata directory is a convenient place to store test data. User supplied raw data for operational runs can be stored anywhere on your system, often outside of the LAPS trees. Note that the lapsdata tar files contain intermediate plus analysis output files only. The rawdata tar files supply much of the raw data that are inputted to the ingest processes. The times for the raw data match the lapsdata output approximately but not always exactly (one example being the raw background data files). As a hint with the background data check that the available raw files bracket the systime of interest. If needed one can change the useanalysis flag in background. nl to get lga. exe to work better. In many cases, a user could independently generate the intermediate data files (ingest output) and then compare them with ours. If other raw files are needed as they appear on GSDs NIMBUS MADIS systems, please let us know and we can try to add them to our test data case or send them separately. 2.6 IO of LAPS gridded files Once the laps library is compiled (as outlined above), laps grids can be read. There are three levels of software that can access the data. To link to the reading routines, you will want to link to: 2.7 CHANGING THE HORIZONTAL DOMAIN Laps will allow you to change the horizontal domain after compilation and before the running of the localization scripts. Below is a list of the relevant changes. The dimensions and location of the horizontal domain can be changed at run time. Prior to running windowdomainrt. pl, set the following parameters in datastaticnest7grid. parms or in the corresponding template directory (needed only if you are outside the default Colorado domain). This script in turn runs gridgenmodel. exe and other programs. 2.7.1 Number of Grid Points Adjust the horizontal dimensions in terms of the number of grid points (NXL, NYL) in. datastaticnest7grid. parms. NOTE: Various files in the. datacdl directory are automatically edited by. etclocalizedomain. pl using the values found in. datastaticnest7grid. parms. 2.7.2 Location of Analysis Domain (Map projections) When you run. etclocalizedomain. pl, the netCDF static file static. nest7grid will be automatically generated by process gridgenmodel. exe. This contains grids of latitude, longitude, elevation, and land (vs. water) fraction. The following output message, topo30s file U50N119W does not exist, does not necessarily mean there is a problem. It may signify that your domain runs outside the available 30 data, and should still be covered by the 10 worldwide data, if you are using the topo30s dataset. Other WARNINGs or ERRORs may be more significant. 2.7.2.1 MAP PROJECTION FUNCTIONALITYLIMITATIONS LAPS runs with the polar stereographic, lambert, and mercator projections. Please let us know if you encounter any problems. The polar stereographic projection has a pole that may be set to either earths north or south geographic poles. Setting the pole to an arbitrary latlon (local stereographic) is a possible future enhancement. A test local stereographic domain gave an error of 2km in the grid points the test code works in cases where the projection pole coincides with the center of the domain. Further improvement of this may include more fully converting library subroutines GETOPS and (possibly) PSTOGE to double precision. The projection rotation routine projrotlaps also has some approximations when local stereographic is used. These need to be checked for their validity and refined if needed. Cases of interest include a projection pole point at the domain center, as well as offset from the center. The local stereographic projection also ignores standardlatitude from the namelist so this is internally assumed to be 90. This means that the grid spacing is valid at the projection pole location, regardless of both where on the earth the pole is and the poles latitude. The map projection calculations are performed with a spherical earth assumption. 2.7.3 Domain Resolution The default value of the gridspacingm parameter is 10000m. This is one of the parameters used in constructing the static file (as mentioned above). To date, we have run LAPS with resolutions ranging from 1000m to 48000m. 2.7.4 Terrain SmoothingFiltering Edit the file datastaticnest7grid. parms. 2.8 CHANGING THE VERTICAL DOMAIN PRESSURE OF THE LEVELS (and vertical resolution): To do this, perform the following between untarring the tar file and localizing LAPS 1. Copy datastaticpressures. nl to your TEMPLATE directory, then edit it with to have the new set of levels. Update the list of pressures that go in sequence from higher to lower pressures (bottom to top) Note that the default vertical grid uses constant pressure coordinates and that the vertical pressure interval can vary between levels. For example one might want to use higher density in the boundary layer ( 100Pa interval) and make it coarser higher up ( Of course the top pressure should be greater than zero mb. The bottom level should extend below the terrain and below the observations. The pressure values must be in multiples of 100 pascals, corresponding to an integer number of millibars. NUMBER OF LEVELS: 1. The default value of nklaps is set to 21 levels in datastaticnest7grid. parms and will automatically be reset during the localization (based on the contents of pressures. nl). 2. Note that compatibility with model background data will depend of the vertical extent of that data source. Note: If you are feeding LAPS output into an AWIPS workstation, then additional workstation related changes may be needed. 2.8.1 Sigma Height Grid UNDER DEVELOPMENT - mainly for STMAS-3D Similar to 2.8 except that one changes the verticalgrid parameter in nest7grid. parms. Also the heights. nl namelist is used instead of pressures. n l. Note the heights in this namelist are scaled sigma values where the namelist (idealized) height sigma (heighttop - heightbottom) Presently the heighttop and heightbottom values are hard wired to 20000. and 0. meters, respectively. 2.8.2 Sigma Pressure Grid UNDER DEVELOPMENT - mainly for STMAS-3D Similar to 2.8 except that one changes the verticalgrid parameter in nest7grid. parms. Also the sigmas. nl namelist is used instead of pressures. nl. 2.9 CHANGING THE CYCLE TIME The default cycle time is 60 minutes. To change this, do as follows. 1. Edit runtime parameter file datastaticnest7grid. parms to change the value of lapscycletime. 2.10 LQ3 (HUMIDITY ANALYSIS) CHANGES Recent changes as of February 26, 2006 NAMELIST The namelist file. lapsstaticmoistureswitch. nl controls the data assimilation within the moisture analysis. This file is self-documented, refer to it for details. This file has not changed in this latest update however, one of its controlling aspects is GVAP or GOES vapor (total precipitable water, product data) and the application of this data has changed since a major implementation change March 2005. The NESDIS Community Radiative Transmittance Model (CRTM) and forward radiance model called OPTRAN is incorporated into the current release of LAPS. Details of OPTRAN are available from: Tom Kleespies NOAANESDIS Thomas. J.Kleespiesnoaa. gov Also OPTRAN can be used by any U. S. Government or U. S. Military entity without problem. ALL other users need to contact NESDIS (Tom Kleespies) and receive authorization to use this software. Generally a simple acknowledgement to give full credit to the program author is all that is required. GSD assumes no obligation or responsibility in integrating this software as part of LAPS. To disable the use of OPTRAN in LAPS, simply assign the GOES option in the moistureswitch. nl namelist file to zero. The version of OPTRAN in LAPS is configured to work with GOES-8 and -10 sounder or imager at this time. Note also that GOES imager channel 5 (water vapor split window) is currently not available on GOES 11, 12 and future satellites since it was replaced with a different band. Therefore, the GOES imager data should not be used in the moisture algorithm for any GOES satellite 11 and beyond. There are simply not enough moisture channels available to offer any useful information about moisture depth due to this change. Furthermore sounder radiances for GOES-10 are deemed about 98 reliable, they are regarded to be 100 reliable for GOES-8. NaN values have been observed being generated from the GOES-10 sounder coefficients that currently accompany this software. At this time there are only basic provisions to handle the NaN state conditions. They have not been observed to crash the moisture analysis and seem to be handled gracefully to date. Any observation otherwise needs to be communicated to: Dan Birkenheuer NOAAGSD Daniel. L.Birkenheuernoaa. gov To model the atmosphere with OPTRAN, an atmosphere is formulated that extends to 0.1 hPa. This is a composite of the normal LAPS analyzed vertical domain (nominally extending to 100 hPa), spliced together with a climatological atmosphere of 20 levels that extends to 0.1 hPa. The joining of the two vertical coordinate systems is computed automatically and is continuous. This will automatically take place even if the nominal LAPS levels are extended beyond 100 hPa. In this upper region, temperature, and mixing ratio are functions of latitude and Julian day. Ozone is based on the U. S. Standard Atmosphere. ADDENDUM: routine RAOBSTEP. F It should be noted that some users have had to modify the parameter that defines dimensions in routine raobstep. f due to the fact that this can overflow array limits on some machines. The current parameter sndtot is set to 1000. The primary reason for this is to accommodate satellite soundings of which there can be many in even a small area. This parameter ties in to the dimensions of the weight matrix (ii, jj, sndtot). If a large horizontal domain is defined, and you dont have a lot of RAOB data and are not using satellite processed soundings, you may have better success at compiling this routine by reducing the value of sndtot to a smaller value. GVAP data are GOES sounder total precipitable water data acquired from the sounding retrieval process. These data were added to LAPS under a grant from NOAA NESDIS. The analysis for GVAP data has recently changed from the prior application. Up until the March 2005 release, GVAP data were used as a direct total moisture data source in that the integrated state variable in the moisture routine (q) was compared to GVAP totals and part of the minimization procedure was to improve this match through variational techniques. It was learned during the IHOP 2002 experiment that the GVAP data were badly biased, especially at asynoptic times. (see laps. fsl. noaa. govcgibirk. pubs. cgi for all publications, and specifically laps. fsl. noaa. govbirkpapersBirkenheuer2005aj. pdf for the article about IHOP, or it can be located in the literature at: Birkenheuer, D. and S. Gutman, 2005: A comparison of the GOES moisture-derived product and GPS-IPW during IHOP. J. Atmos. Oceanic Tech. 22, 1840-1847.) As a result, the algorithm was modified to use GVAP gradients and to compute gradients in the solution field and match these gradients to those from GVAP. The advantage to using gradients in this procedure was that it eliminates bias and improves data structure. There is not a Tech Memo that has been published and is also available on line that describes this new technique. (refer to: laps. fsl. noaa. govbirkpaperstechmemosGSDTechMemo32.pdf or a copy can be gotten directly from GSD) 2.11 OTHER RUNTIME PARAMETERS It is worthwhile to check the nest7grid. parms and other namelist files in datastatic to make sure all the runtime parameters are correct. Some parameters worth noting are: 2.12 Detecting and Reporting Installation Errors To determine how well LAPS was installed, verify that all (31 at last check) executables were built OK (bin directory) with no errors in the output of make. Similarly, check the output of the localization script. If you have any problems during the configure, install and localization process, there are several things to check. For certain platforms, you can compare your build output with ours by clicking on Results of Latest LAPS Builds on the LAPS Software page. Also double check that youve followed all the installation steps in this section of the README. There is also a FAQ available at laps. noaa. govbirkLAPSFACTS. htm Finally, check the release notes at the laps. noaa. govsoftwarereleasenotes. html URL. If you dont find the answer in these documents, send mail to oplapb. gsdnoaa. gov Include in your mail: 2.12.1 Runtime Monitoring To see how well LAPS is running, check if output files are being placed in the various lapsprd subdirectories. A graphical product monitor that can help with this is available in etclapsmonitor. pl. This script may need some simple editing to suit your needs (e. g. to specify the LAPSDATAROOTs). The monitor script writes HTML output to stdout. This HTML output, if routed to a file or hooked up to a Web server, can be viewed with a browser. You can click on laps. noaa. govmonitorsLapsMonitor. cgi to see an example of the monitor output. Green means optimum product continuity, red means the product is failing to generate, yellow means it is generating OK now but has failed in the past. The numbers in the columns indicate the number of files in each directory, as well as the youngest and oldest file ages in hours. The data flow is generally from top to bottom on the product list, starting with analyses and ending with forecast model (fuafsf) output being listed at the very bottom. In general the root cause of missing products would be the first one that is missing along the data flow. To check what model background and observational data were used in the analyses as well as some QC and error (verification) statistics, you can view the log file summaries in the files LAPSDATAROOTlog. wgi. yydddhhmm. Generally each named wgi file corresponds to the name of an analysis process, except that sfc. wgi. is generated by one of several executables than can provide the LAPS surface analysis depending on the runtime configuration. For more details, check the various log files in the LAPSDATAROOTlog directory for occurrences of the string error and warning. The errors are generally more significant. If any core dumps occur they can usually be flagged by searching for the sh: string in sched. log.. If you are reporting runtime errors it can be useful to tar up your entire LAPSDATAROOT and make it available on your web or FTP server as a compressed tgz file. If the data set is very large you might consider mailing us a CD or DVD. Alternatively if you have the untarred LAPSDATAROOT files on your web server we can browse through the directories for the log and product files as needed to help diagnose the run. If the LAPSDATAROOT is large it can be pared down as there is a script called etctarlapstime. sh that works by just tarring up the current hours worth of files. If you need to narrow this down further just the inputs to the particular analysis would be needed as shown in section 3 of the README. Also, things like the cdl, time and static subdirectories should be included. 3.0 DESCRIPTION OF LAPS PROCESSES The following section contains information on which LAPS processes generate which LAPS output products. Static data (like lat and lon grids) are included in section 3.1. These are the processes contained within the LAPS tar file and built with the localization script. Inter data is an ascii file containing non-gridded data (intermediate data files). Examples of this are surface obs, profiler obs, etc. This list contains all outputs generated by LAPS processes. The products listed under each process are the outputs produced by that process. Inputs are listed here for some analyses. If the cron including sched. pl (see section 2.4) is run according to the flow therein, the necessary inputs will be available. 3.1 Localization Processes 3.1.1 Gridgenmodel (static. nest7grid generation) Package: gridgenmodel. exe - Writes static file, run by localization script. Contact: Steve Albers - Steve. Albersnoaa. gov Inputs: Geography databases (topography, land fraction, landuse, soiltype topbot) greenness fraction, mean annual soil temperature, and albedo. Files are typically in 10, 30, or 180 deg tiles. See section 2.2.5 for details on the geography data. staticnest7grid. parms Source directory: lapssrcgrid Sample Output: Should be available in the test data case. The grids start with gridpoint (1,1) in southwest corner of the domain and end with gridpoint (ni, nj) in the northeast corner. The bottom (southernmost) row of the domain is written first (I increases with consecutive grid points, then J increases). I increases as youre moving east on the grid, J increases as youre moving north. 3.1.2 Surface Lookup Tables (gensfclut. exe) Package: gensfclut. exe - Writes surface lookup tables, run by localization script. (contact: John McGinley Steve Albers) Source directory: lapssrcsfctable In gensfclut. exe, the friction parameter has been configured by automatically producing a scaling factor based on the range of elevations across the domain. This factor can be changed in the dragcoef section of buildsfcstatic. f, if so desired. 3.1.3 Satellite Lookup Tables (genlvdlut. exe) Package: genlvdlut. exe - Writes satellite lookup tables, run by localization script. (contact: John Smart) Source directory: lapssrcingestsatellitelvdtable Additional information on the lookup tables can be found in the file lapssrcingestsatelliteREADME. 3.2 Ingest Processes As mentioned above, a flow chart for the ingest processes may be found at laps. noaa. govdocslide1v3.gif. 3.2.1 LGA Model Background Package: lga. exe - ingest background model data (contact: Steve Albers - Steve. Albersnoaa. gov). LGA LAPS analysis grids from RUC or other analysisforecast grids. Inputs: Raw model data on the models native grid. The acceptable models and formats for the background model are listed in datastaticbackground. nl. We have recently added support for the background models to include GRIB-formatted files. See source directory: LAPSSRCROOTsrclibdegribREADMELIBS file for detailed information. For some models you might want to do a separate conversion of GRIB to netCDF prior to running LGA. One software option for this is available from the GSDITS group as described in section 3 of this web document at the following URL: Tropical cyclone bogusing information is also an input in the form of the tcbogus. nl namelists. These are generated independently of LAPS as raw data, yet are placed in the LAPSDATAROOTlapsprdtcbogus subdirectory. The filename convention should be yydddhhmmtcbogus. nl. To see the format check the sample file located in datastatictcbogus. nl. Outputs: (Feeds various analyses) Source directory: The source code for this is in srcbackground. Library directory: Associated library modules are in srclibbgdata. Parameter namelist file: staticbackground. nl Sample InputOutput: May be available in the test data case. This software currently supports nearly 10 different models. If additional models are required, then software mods may be needed, potentially a new source file added to srclibbgdataread. f. A key variable that relates to which model youre using is bgmodel. Note that time interpolation is used if the required LAPS analysis time(s) are between the valid forecast times for two of the set of input files. In this context output files are produced for the LAPS analysis time as well as - one LAPS analysis cycle time. Input data for LGA should thus be available over an appropriate time span. 3.2.2 Surface Data Ingest 3.2.2.1 obsdriver. x LSO process - obsdriver. x - Ingest surface data (author: Pete StamusSteve Albers) Source directory: LAPSSRCROOTsrcingestsao (contains a README file) Parameter file (specifies input data paths and formats): staticobsdriver. nl The LSO file is fairly self explanatory. The easiest way to see what goes where is to look at the routine readsurfacedata in the file srclibreadsurfaceobs. f, and the corresponding format statements in the file srcincludelsoformats. inc. The routines are pretty well commented, and should be enough to tell you what you need to know if you want to make a decoder that outputs an LSO-type formatted file directly. This direct route would allow you to bypass the step of producing raw netCDF surface observation data. Here are a few recommended settings for the observation type variables (reportType and autoStationType) if you are constructing your own LSO file: The expected accuracies are based on offical NWS numbers where possible. For LDAD observations, theyre just a best guess, since no one really knows how good the obs are. These expected accuracies will be used in the quality control routines sometime in the future. The latlons are in decimal degrees. Gross climatological QC error checks are applied to several variables including temperature, wind, and pressure. MADIS QC flags are checked as can be controlled via namelist. 3.2.2.2 How to Blacklist stations (author: Steve AlbersPete Stamus) As part of the obsdriver code, a Blacklisting function has been added. This allows users to tell LAPS to skip stations with known bad variables (one or several), or to skip a station completely. As of this writing, the user will have to edit a Blacklist. dat file. in the future we hope to include this function in the LAPS GUI. An example file, called Blacklist. example has been included in the same directory as this README file. It shows the format that must be followed for the Blacklist to work properly. An error in the format will either allow the bad station(s) through, or crash the program completely. Lets decode the Blacklist. example file: The first line is the number of obs to blacklist. in this case, 5. Each station goes on a new line. The number of variables to blacklist for that station is next, then the codes for the variable(s) follow. For the first station (KFCS), we are blacklisting the 3 pressure variables. To blacklist the entire station (KDTW) use 1 for the number of variables, and ALL as the variable. All the stations from a particular provider can be blacklisted by adding 100 to the number of variables (third example). The last two examples show 1 and 2 individual variables, respectively. These are the valid codes for variables to blacklist: You might keep in mind that some variables act as a group. For example both HUM and DEW variables feed into the LAPS dewpoint analysis so consideration should be given as to whether to blacklist one or both of these variables. ALT, STP and MSL are a similar group of pressure variables. An incorrect variable code generates a warning message, and the code should hopefully continue without acting on the station in question. Note that when a station is blacklisted, its name, latitude, longitude, elevation, and time, will still be stored in the LSO file. However, the selected variables (up to ALL of them) will be set to the badflag value and skipped in the analyses. To actually get this stuff working, edit the file called Blacklist. dat in the datastatic (or template) directory. The Blacklist. dat being used at GSD is supplied in this directory as a default, and this provides additional examples. Format the file exactly as the Blacklist. example file (using your station information, of course). Save the file, and the next time obsdriver runs, it will use the blacklist information. This will be noted in the obsdriver. log file. You may eliminate element specific or ALL data from a particular provider by replacing the leading 0 with a 1 in the second column. See the WXforYou example in the Blacklist. example file. To ensure the elimination of the data by provider, care must be taken to make certain the correct provider is listed in the Blacklist. dat file. Primarily, offending datasets are from stations received through LDAD. To find the provider for a given station you can look in the logsfc. wgi. files or in the input LDAD netCDF files. For AWIPS users a list of these stations are kept in ldaddata on your AWIPS system. Each. txt file in ldaddata will have a. desc file associated with it which describes the data being ingested etc. by that provider. Look in a particular. desc file of interest. Go to the 3rd word of the 1st line which is not commented out (e. g. aprswxnet. -9999.00 APRSWXNET). For this example, the APRSWXNET (3rd word) is the provider name and should be the entry used if utilizing the elimination by provider feature of the Blacklist. 3.2.3 Polar Radar Data (e. g. WSR 88D Level II, Level III) Author: Steve Albers (Steve. Albers AT noaa. gov) Every volume scan Initiation: Completion of volume scan Inputs: Wideband Radar Data (reflectivity and velocity in polar coordinates, in netCDF format) These have one tilt per file and at least 4 tilts per volume scan (all with the same volume timestamp in the filenames). This data can be obtained from a WSR 88-D Level-II data feed or the equivalent. A description of how we obtain these Polar netCDF files for Level-II is at laps. noaa. govalbersremapperraw. html. Note that narrowband reflectivity data (e. g. WSR 88D Level-III RPG) can also be used as long as it is converted to the required polar coordinate, netCDF format. This is in fact being done for the AWIPS implementation of LAPS for a low-level tilt from a single radar, via the etcLapsRadar. pl script running in the AWIPS environment. The comment section at the top of this script explains how this 4 bit processing of reflectivity data works. etcLapsRadar. pl runs two executables. The first executable tfrNarrowband2netCDF from AWIPS, writes out the polar netCDF files in the directory LAPSDATAROOTlapsprdrdr. raw where. is the radar number. The second executable remappolarnetcdf. exe is run as part of LAPS. We havent been using Level-III velocity data since it is of limited 4-bit resolution and were running only with the lowest tilt at present. For both Level-II and Level-III the polar netCDF files are named according to yydddhhmmelevxx where xx is the tilt number. Sample polar netCDF files including a CDL may be found at: laps. noaa. govsoftwareradarwideband Outputs (LAPS intermediate files - depending on input parameters): The outputs from this process, on the Cartesian LAPS grid, are used by the LAPS wind analysis, and also potentially by cloud and precip accumulation analyses. One output file is written per volume scan. When running the remapper, files such as v01, v02, vrc, etc. are produced depending on which radar is being used and on the input parameters. A further description of how the remapper software functions may be found on the World Wide Web at laps. noaa. govalbersremapperlaps. html. Also recall the flow chart showing the inputs and outputs for remappolarnetcdf. exe at laps. noaa. govalberslapsradarlapsradaringest. html. Source directory: The source code for this is in srcingestradarremap. Compile time parameters: srcincluderemapdims. inc Runtime parameter namelist file: staticremap. nl Sample InputOutput: May be available in the test data case. 3.2.4 WSI NOWRAD RADAR PREPROCESSING (VRC) Process: VRC (vrcdriver. x) Author Steve Albers (Steve. Albersnoaa. gov) Parameter namelist file: staticvrc. nl The WSI data are decoded externally to LAPS and written as netCDF files in NIMBUS format. The vrcdriver. x process reads these netCDF files. WSI sends out many types of radar data. We use the files that are labeled hd (15 min freq). They also send out an hf (5 min freq) file. We use hd because WSI hand edits these for ground clutter. The hf files are not edited. The hd and hf files are composites of low-level elevation scans from the 88Ds around the country. The vrcdriver. x also maps from conus to laps domain for the wfo data set. The map transformation software is found in libgridconv, libnav, and libradarwsiingest. The switch to use wsi versus wfo in variable craddattype in the nest7grid. parms namelist. Pathway to data is variable pathtowsi2dradar in vrc. nl. The output reflectivity is used by the cloud and precip accumulation analyses. 3.2.5 Radar Mosaic Author Steve Albers (Steve. Albers AT noaa. gov) This program runs once per LAPS cycle in the sched. pl. The default is to write just one mosaic file for the cycle valid at systime. A namelist option allows this program to produce multiple mosaic outputs within a given LAPS cycle. The multiple mosaics are all run at the same wall clock time, while the valid mosaic times are spaced throughout the previous LAPS cycle. The nearest radar with valid data is the one chosen to contribute at each grid-point. The output reflectivity mosaic is used by the cloud and precip accumulation analyses. Further QC is done within these analyses. Parameter namelist file: staticradarmosaic. nl 3.2.6 PROFILERVADSODAR (PRO) Ingest Process: PRO (ingestpro. exe) LAPS Wind Profile Ingest Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: lapssrcingestprofiler Parameter namelist files: staticnest7grid. parms, staticvad. nl Sample InputOutput: Should be available in the test data case. For the pro output, each profile starts with an ASCII header and the formatted entries are defined in sequence. After the header, the data entered for each level is as follows. 3.2.7 RASSs (LRS) Ingest Process: (ingestlrs. exe) LAPS local data RASS ingest Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: lapssrcingestrass Sample InputOutput: Should be available in the test data case. 3.2.8 PIREPSACARS Ingest Process: (ingestaircraft. exe) LAPS Pireps ACARS Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: The source code for this is in srcingestacars. Parameter namelist file (for data paths): staticnest7grid. parms Sample InputOutput: Should be available in the test data case 3.2.9 Sounding (RAOBDropsondeSatRadiometer) (SND) Ingest Process: (ingestsounding. exe) LAPS Soundings Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: lapssrcingestraob (contains a README file) Parameter namelist file (for data paths): staticsnd. nl Sample InputOutput: May be available in the test data case. If not, the README in the source directory contains a description of the snd file. Note: Sounding data is used if the observations lie in the time window of - lapscycletime centered on the analysis time. There are flags to toggle usage of the sounding (i. e. snd) data in wind. nl, temp. nl and moistureswitch. nl. 3.2.10 LVD (Satellite Image Cloud Top Pressure) LVD process - lvdsatingest. exe - takes raw sat. data and puts it on LAPS grid. (author: John Smart, contact Kirk Holub - Kirk. L.Holub AT noaa. gov) Input: GOES or other satellite data Parameter namelist file: staticsatellitelvd. nl Source directory: lapssrcingestsatellitelvd (contains a README file) 3.2.11 Cloud Drift Wind (CDW) Ingest Process: (ingestclouddrift. exe) LAPS Cloud Drift Winds Author: Steve Albers (Steve. Albers AT noaa. gov) Parameter namelist file: staticclouddrift. nl Source directory: lapssrcingestsatelliteclouddrift Note: Sounding data is used if the observations lie in the time window of - lapscycletime centered on the analysis time. 3.3 ANALYSIS PROCESSES A flow chart for the analysis processes may be found at this URL: laps. noaa. govdocLAPSflowv02.png Listed below is a summary of each analysis process in the order it is typically run by the sched. pl script. 3.3.1 WIND Process: wind. exe - WIND analysis and related fields Author: Steve Albers (Steve. Albers AT noaa. gov) Generate a wind analysis using surface observations, profiler, cloud drift wind, and aircraft reports. VAD and SODAR can also be read in. Background model grids are used as a first guess and to do quality control on new observations. Time tendencies from the background model are applied to the aircraftcloud-drift wind reports when they are taken before or after the nominal analysis time. The quality control rejects any observations deviating from the background by more than a threshold depending on observation type as in the following table. The wind analysis is done in three steps. The first step analyzes the non-radar data with the background wind field using a multiple iteration successive correction technique. For the second step, the first step results are used as the background. The data used includes non-radar data any grid-points with multiple - Doppler radial velocities are also mixed in. Radial velocities are taken from the Doppler radars after dealiasing and other quality control steps are done. If two or more radars illuminate a given grid-point, a full wind-vector is constructed from a combination of the radial velocities and the preliminary non-radar analysis. This is done via a successive insertion process, beginning with the background (non-radar analysis), then followed with the radial velocity from each radar in sequence. For the final step the background field comes from the result of the second step. All point data is now used, including grid-points illuminated by only a single radar. The tangential component for each radar observation is estimated by using the background from the previous step (i. e. non-radar data andor multi-radar data). The omega field is calculated by kinematically integrating the horizontal wind divergence. The lower boundary condition is specified by the surface wind and terrain gradient. Source directory: lapssrcwind (contains a README file) Parameter namelist files: staticwind. nl, staticnest7grid. parms Further description and reference is at: 3.3.2 SFC (LSX) Surface processing - lapssfc. x (LSX) (authors: John McGinley Pete Stamus Steve Albers) The surface package collects surface data from the LSO intermediate data file (METARs, local mesonets via LDAD, buoyship obs), IR brightness temperatures, and fields from selected background models. Places surface data on LAPS grid and performs a simple quality control of the obs (climo standard deviation checks). The quality control is described in the section below at (3.3.2.2). A flow chart can be seen at this URL: laps. noaa. govalberslapstalkssfcSfcanal. gif The background fields come from the locally-run LAPS model (FSF file), other large-scale models (RUC, ETA, AVN - via the LGB file), or a previous analysis (if all else fails). If the background model terrain is on a coarser grid than LAPS, this is accounted for so that the LGB fields have the fine-scale terrain related structure. For wind fields, the background comes from the 3-D wind interpolated to the surface or LWM file. Prior to analysis of each field, another quality control step is done that rejects observations that deviate from the background by more than a threshold. This threshold is proportional to the standard deviation of the observation increments. The proportionality constant is set depending on the field. The next step in the analyses is done with a successive correction technique similar to the 3-D wind and temperature analyses (see those sections and their web references). Observation increments are used for T, Td, U, V, MSL, P and straight observations are used for visibility. The temperature and dewpoint observations are also corrected for deviations of the station elevation from the LAPS terrain. Standard lapse rates are applied to this elevation difference. The analysis innovation is constrained to vary from the background by no more than the magnitude of the observation rejection threshold discussed above. This helps prevent overshooting (ballooning) of gradients into data sparse areas. For relative humidity, the RH observations are converted into dew point using the station temperature (if the dew point isnt directly reported). The analyzed variable for moisture is dew point. After the analysis is performed the gridded dew point field is converted back into relative humidity using the analyzed temperature. A land fraction term is factored into the weighting whenever the observation and grid point are on either sides of a 0.01 land fraction threshold. This helps prevent situations such as heating over the land having undue effects over the water areas. This weight is applied mainly to the T, Td, U, and V fields. For pressure analysis, three fields are computed including reduced pressure (P) at reference height redplvl, surface pressure (PS), and mean sea level pressure (MSL). Background pressure fields come from the LGB or FSF files. The MSL background is used as read in upon input. The (PS) background is converted from the background model terrain to the LAPS terrain within the LGBFSF file. The (P) background is generated by reducing the (PS) background to the reference analysis height redplvl using Poissons equation. This reference height should be approximately equal to the mean elevation of stations reporting surface pressure or station pressure. Continuing the pressure analysis the altimeter setting observations are converted and added to the set of station pressures using the standard atmosphere. Station pressure observations are in turn converted to reduced pressure using Poissons equation. The (P) analysis uses the (P) background plus the reduced pressure observation increments. The (P) analysis then uses variational techniques to constrain the surface winds and reduced pressures (P) to the full equations on motion. In contrast, mean sea level pressure (MSL) is a direct analysis of the MSLP observation increments together with the model background MSL field. The station pressure analysis (PS) is calculated using the model background gridded PS field, multiplied by the ratio of the (P) analysis to the (P) background. Visibility is arrived at by first analyzing the surface visibility observations. A second step is applied to decrease the visibility in areas that have high RH and are near the cloud base that is given by the cloud analysis (in the previous time cycle). Several derived variables are calculated before the LSX file is written. Also, a dependent data validation is done by interpolating several variables back to the observation locations and comparing the analysis to the obs. Output from this check is written to files located in LAPSDATAROOTlogqclapssfc. ver. hhmm, where hhmm is the analysis systime. Source directory: lapssrcsfc Parameter namelist file: staticsurfaceanalysis. nl 3.3.2.1 SURFACE ANALYSIS RUNTIME PARAMETERS You will need to select an elevation for the reduced pressure analysis. The reduced pressure is the only one really used in the variational portion of LAPS, and the idea is to select an elevation that is representative of the domain (or portion of the domain) you are interested in. For example, the Colorado LAPS domain includes 4000m high mountains over the western 13, and plains that slope below 1000m at the eastern boundary. We use 1500m as the Colorado LAPS reduced pressure. This is close to the elevations over the eastern 23s of the domain, and requires a smaller reduction over the mountains compared to MSL, for example. Change the namelist variable in datastaticnest7grid. parms when you localize LAPS. 3.3.2.2 SURFACE ANALYSIS QUALITY CONTROL LAPS has a layered QC approach that gives us several opportunities to flag erroneous observations. To start with, a variety of gross climo checks are applied to the observations in the obsdriver. x ingest program. The next steps in quality control are encountered in lapssfc. x. This first checks the observations against climatologically reasonable ranges. Next, the observations (most fields except wind) are checked to see which ones are outliers (at 5 sigma) relative to the average observation value in the domain. As a further check, the Temperatures, Dewpoints and MSL pressures are checked to see if they deviate from the background field by more than a threshold absolute amount. The output from these checks is in both lapssfc. log and sfcqc. log. The sfcqc. log file contains the rely (positiveretain, negativereject) values designated as follows: If you wish to skip over these steps, you can change the surfaceanalysis. nl namelist file. A new check looks at the temporal history of the obs where a 24 hour bias check flags temperature observations. Winds that arent changing in speed or direction over the 24 period are also flagged. There is an additional check for all analyzed fields (except visibility) within the spline routine that rejects stations deviating from the background by more than a threshold number of standard deviations of the observation increments. This threshold can be independently adjusted (i. e. tightened or loosened) for each field via the surfaceanalysis. nl namelist. If you see any bulls-eyes in the surface analysis that you dont believe, try contacting Steve Albers at GSD for more information on making these quality control namelist adjustments. 3.3.2.3 SURFACE ANALYSIS VERIFICATION Verification statistics for the surface analyses are written to the logqclapssfc. ver. hhmm files. These contain information of obs differences relative to the background and the analysis. The obs listed have had most of the QC checks already applied, though an ob may have been rejected in the analysis by the final spline standard deviation check yet still have a non-missing value listed in the QC files. Source directory: lapssrcmesowavestmasmg Author: Yuanfu Xie (Yuanfu. Xie AT noaa. gov) Parameter namelist files: staticstmas3d. nl, staticnest7grid. parms 3.3.3 TEMP Process: temp. exe - Temperature-Height analysis Generate a temperature analysis using model background, sfc temp analysis, and RASS data. Quality control is applied to the temperature soundings. If any level in a sounding differs from the model background by more than a threshold ( 10 deg), the entire sounding is rejected. Source directory: lapssrctemp Further description and reference is at: 3.3.4 CLOUD Process: cloud. exe - Cloud analysis package Author: Steve Albers (Steve. Albers AT noaa. gov) Several input analyses are combined with METARs of cloud layers. These input analyses are the 3D temperature analysis, a three-dimensional LAPS radar reflectivity analysis derived from full volumetric radar data, and a cloud top analysis derived from GOES IR band eight data. Vertical cloud soundings from METARs and pilot reports are analyzed horizontally to generate a preliminary three-dimensional analysis. This step provides information on the vertical location and approximate horizontal distribution of cloud layers. The satellite cloud-top temperature field is converted to a cloud-top height field using the three-dimensional temperature analysis. The cloud-top height field is then inserted into the preliminary cloud analysis to better define the cloud-top heights as well as to increase the horizontal spatial information content of the cloud analysis. A set of rules is employed to resolve conflicts between METAR and satellite data. Finally, the three-dimensional radar reflectivity field is inserted to provide additional detail in the analysis. Source directory: lapssrccloud Parameter namelist files: staticcloud. nl, staticnest7grid. parms Further description and reference is at: 3.3.5 WATER VAPOR (HUMIDITY PROCESSING) Last updated: 2242006 by Daniel Birkenheuer The moisture code is coordinated by the LQ3 modules all of which (with the exception of libraries) exist under. srchumid. The main driver, lq3driver. x contains only one subroutine call at this time. is the primary moisture processing module that sequences the various subroutines. There is a second routine that formerly was used for HSM satellite processing it is currently deactivated: Now, using the CRTM forward radiance model and more advanced techniques, the satellite inclusion takes place in the above 1a module. Treat the 1b module as orphan code. Furthermore, a FORTRAN 90 compiler is required to fully compile the forward model along with the rest of the moisture analysis system. An ASCII file intended for easy editing and control of the moisture modules activities. The first record controls usage of RAOB data (0off, 1on). The second record controls usage of satellite data (LVD files) and again (0off 8on, use GOES-8, 9on, use GOES-9). This module is exported with the RAOB feature OFF and the satellite feature ON and SET FOR GOES-8. The third switch enables (1) or disables (0) saturating air in cloudy areas. The fourth now enables using sounder data in lieu of imager data (GOES only). This should be set to (0) for the current time. A switch has been added to enable cloud data use to saturate air in cloudy areas. This is included as the last item in the moistureswitch. nl file that is maintained under the static area. To enable cloud data for saturating the air this is (1) to disable the feature, set the character to (0). You might wonder why we need such a switch. During October (1996), we experienced problems with the cloud analysis. This was inadvertently causing problems in the moisture analysis through the cloud saturation adjustment. The incorrect moisture was in turn causing the models runs to fail. Hence we added this switch so that we could easily reactivate the feature once the cloud analysis was repaired without having to worry about recompiling any code. The capability to ingest RAOB data into the moisture module has been available since 1996. There are two important items to know about: 1) The RAOB data are contained in lapsprdsnd. snd files. The moisture module will automatically use. snd data if present. If you do not wish to use sounding data there are 2 ways to exclude these data, the most obvious is to not provide. snd files. 2) In the event that you wish to exclude the use of sounding data and want them to be present in the data directory (possibly for some other application) you can avoid using them in the moisture code by modifying the file. datastaticmoistureswitch. nl The first record of this ASCII file is used for the RAOB data inclusion. The file itself is documented internally following the second record. If the first record is 1 (nominal case), the use of sounding data will be on, and. snd files will be processed if present. If this character is 0, the moisture code will not process sounding data. Inputs (status as of August 1996) (grid designates LAPS netCDF grid file unless otherwise stated): PRIMARY ALGORITHM SUMMARIES The RAOB data are added to the analysis via a second pass Barnes analysis. Normally, a Barnes analysis consists of two parts. The first fills the entire domain with values weighted by the distance to the neighboring points. In the second pass, a difference field (derived from the difference of the first pass and the observations) is added to the result from the first pass with adjusted weights to better tune to the scale of interest. In this application we skip the first pass using instead the background analysis in place of the result of the first pass Barnes result. The difference field is then generated and applied using a set of weights appropriate for the LAPS domain resolution and density of observations. An essential ingredient of the variational method is a satellite forward radiance model. The forward model produces a simulated radiance based on temperature, moisture, and ozone profiles along with the temperature of the surface or cloud top, and the pressure of that radiating surface (i. e. surface pressure or cloud top pressure whichever applies). Also needed are the zenith angle, used to determine the air mass path and optical depth between the radiator and the satellite. The forward model used for this work was obtained from NESDIS. The forward model coefficients used for this study were vintage late 1995. In order to apply the forward model appropriately, a determination of clear and cloudy fields-of-view (FOV) need to be determined. The LAPS cloud analysis is used to identify clear and cloudy LAPS grid points. The analysis as presented here is only working from FOVs classified as clear. Cloudy FOVs probably can be used, but this is an early attempt at this technique, so a conservative approach was chosen. Later research may focus on using a combination of both clear and cloudy FOVs in the algorithm. The first step in the algorithm is to assure all the data needed for proper execution are present. These include channel radiances derived from AWIPS imagery, the LAPS cloud analysis output, the LAPS surface temperature output, and LAPS 3-D temperatures. The forward model also requires an ozone profile along with moisture and temperature profiles above 100 hPa. These are gotten from climatology since LAPS extends only to 100 hPa. The entire ozone profile is provided by the forward model since LAPS does not analyze this parameter. Next, the forward model is run to verify clear LAPS gridpoints, where clear is defined as those points in which both the modeled and measured GOES image radiances in channel 4 (11 micron) agree to with 2K. This step uses the LAPS thermal and as yet unmodified moisture profiles. Disparity in the channel 4 brightness temperature comparison indicates that the LAPS thermal profile is too far off or perhaps it is really cloudy where the LAPS cloud analysis is indicating it is clear. (It doesnt have to be totally cloudy for a disparity to exist, it can be partially cloudy and this will still be detectable in this difference test.) This is a conservative test it really goes beyond simple cloud detection though that is a likely cause of differences, the forward model check is very sensitive and in many ways eliminates any thermal profiles that subsequent variational technique will find difficult to deal with. We are basically saying that we will not worry about moisture adjustment unless the thermal profiles are reasonable. The current LAPS system uses an older forward radiance model named OPTRAN and this is now being switched to CRTM. However, this test is not that satellite specific and the older OPTRAN model can be used by stating that newer satellite data is of the vintage that OPTRAN uses. For this reason, the user should not be that concerned with the exact satellite specified for this process. At this point, all gridpoints offering promise of moisture adjustment have been identified. If the domain is totally cloudy, the GOES adjustment is discontinued and returns unmodified moisture values which are passed to the final QC step. Assuming some gridpoints have been classified as clear, the next step is a variational adjustment at those locations. The functional evaluated at each gridpoint has and is best described in the literature (see articles under laps. fsl. noaa. govcgibirk. pubs. cgi. Basically a funcational is minimized that differences the perturbed solution against observation. The best perturbation is accepted as the answer. The first term in the functional maximizes agreement between the forward model and observed radiance at the expense of only modifying the water vapor profile. The second term adds stability and gives more weight to solutions in which the coefficients departure from unity (no change to the initial profile) is minimized. The stability term was discovered to be necessary since without it some very good radiance matches were solved but with unreasonable coefficients. Note that differences in all three channels are minimized in this technique, not only the moisture channel. Thus, any improvement in the dirty window, channel 5, will also contribute to the solution. A variational technique is used to minimize this function and typically requires three to 10 iterations to converge. A limit of 50 iterations was set as the maximum number to attempt. If limit was reached, that particular gridpoint was excluded and treated as cloudy. Once the coefficients are determined, Laplaces equation is solved for interior points for which coefficients have not been determined. Then the entire domain is averaged using a spatial invariant filter simply averaging the values in a 3x3 gridpoint window, assigning that average to the windows central grid location. When the coefficients have been determined, they are applied to the specific humidity field at each pressure level for which they are designated. The modified specific humidity field is then advanced to the final analysis step. As a final note it should be mentioned that owing to the unknown bias in radiance data. If it is available, it is far better to use water vapor gradient fields derived from satellite, than to assimilate satellite radiances directly. If the GVAP option is turned on, it is recommended that the direct assimilation is disabled in moistureswitch. nl. This is one reason why direct radiance assimilation has been slow in development with CRTM. Its value still can be reasonably questioned given the unknown bias. It is far more straight forward to rid the system of bias by using the first derivative structure of the radiance or PW field that to try to acceptdeal with the bias. GPS ASSIMILATION ALGORITHM: One of many terms in the humidity variational minimization step, the GPS total water is used to constrain the integrated water computed every iteration. Like the other terms in the functional used in the variational minimization, this term will reach a relative minimum when the state variables and specifically Q, best match this and other observations in a simultaneous manner (simultaneous here is respect to heterogeneous observational fit and not the more traditional state variable multi-variate solution sense). The GPS algorithm traditionally read internal GSD netCDF files for input. It now has the capability (122010) to read MADIS surface data files for GPS data. The MADIS data are typically built every 5 minutes, so to read GPS data from these files, one should look back to the prior hours MADIS file for the most recent GPS data. This is due to the fact that typically the GPS data are not ready for use until about an hour after acquisition time. So for a typical 20-min after the hour LAPS run, the current hours MADIS file will not contain any GPS data. The software is currently tuned to open the prior hours MADIS file and seek the latest GPS data that can be found in that file. This step is required since the MADIS file will be adding GPS data to it as it arrives and by the end of a given hour, MADIS files will contain 2 different GPS ingests. Therefore the user, should be aware that if a LAPS start time other than 20-min past the hour is chosen, the software may have to be changed to acquire the most recent data. Right now things should be pretty stable in this regard. If one starts LAPS at the top of the hour, say 16 UT, this module will read the 15UT MADIS file for GPS data. It will likely find the latest data in that file to have been written about 15:20 UT. This is what the traditional read of internal GPS files would have returned. Furthermore, if the LAPS system starts at 20-min after the hour, the same 15UT MADIS file will be opened and the GPS data read will be from about 15:45UT. Again, the routine will find the same that the traditional GPS file read would acquire. On the other hand, if one were to run at 15:50UT, there is a chance to miss the latest GPS data. The code as now written will open the 14UT MADIS file for data, when in fact the 15UT MADIS file may at this time contain data from 15:20UT. On the other hand, if this mistake is made, the data obtained will likely be nearly within the nearest hour of analysis time (14:50UT) and depending on the cycle time, may or may not be a critical issue. The user will have to determine whether this can be tolerated. Cautions for STMAS: When reading GPS data in a 4DVAR context, GPS data reading will have to spend more time concerned with the actual data time associated with the GPS data. In this regard, multiple MADIS files will likely need to be opened, their contents matched with their respective observation times, and then the data will need to be temporarily stored, sorted, and processed according to the needs of 4DVAR. 3.3.6 DERIV Process: deriv. exe - Derived products Author: Steve Albers (Steve. Albers AT noaa. gov) These derived products are cloud, wind, stability, and fireweather related. Source directory: lapssrcderiv Further description and references are at: 3.3.7 ACCUM Process: accum. exe - SnowfallLiquid Equivalent Precipitation Author: Steve Albers (Steve. Albers AT noaa. gov) LAPS incrementalstorm total snowfallliquid equivalent accumulation. Source directory: lapssrcaccum Parameter namelist file: staticnest7grid. parms The precipitation analysis uses radar estimated precip rates as the primary dataset. The radar reflectiivty can be obtained from any combination of NOWRAD 2-D (Section 3.2.4) or low-level reflectivity from mosaiced 2-D or 3-D radar reflectivity data. The source can be narrowband or wideband radar (section 3.2.3). The mosaics can be performed with either 2-D or 3-D inputs (section 3.2.5). We presently use a Marshall Palmer Z-R relationship to obtain liquid equivalent precipitation. Snow is also estimated using a snowrain ratio derived as a function of column maximum temperature. More on the basic accumulation processing is in Albers et. Al. 1996. In the present LAPS version, areas without radar coverage switch over to a gauge only analysis of 1-hr precipitation - using a background or model first guess field (if available) or zero field as a first guess. Areas having both radar and rain gauges present can be bias adjusted. An algorithm is presently be tested that determines this bias as a function of reflectivity. Reference: Albers S. J. Mcginley, D. Birkenheuer, and J. Smart 1996: The Local Analysis and Prediction System (LAPS): Analyses of clouds, precipitation, and temperature. Weather and Forecasting, 11, 273-287. 3.3.8 SOIL MOISTURE Process: lsm5.exe - Soil Moisture Author: John Smart (John. R.Smart AT noaa. gov) LAPS soil moisture and snow cover This program is in the early stages of development and provides a three layer analysis of soil conditions. The three layers are as follows: A snow cover analysis is included. The fractional snow cover is a composite over time of information from the cloud analysis (visible and IR satellite), and snow accumulation (derived mainly from radar). More documentation can be found within the source code (e. g. soilmoisture5.f, calcevap. f). Note that a soil temperature analysis is not included at this time. The closest thing we have to this is a single layer ground temperature analysis in the LSX surface output file. Source directory: lapssrcsoil 3.3.9 BALANCE Process: qbalpe. exe - Quasi-geostrophic balance of height, wind and clouds. authors: John McGinleyJohn SmartJohn SnookEd Tollerud contact: Edward. Tollerud AT noaa. gov LAPS quasi-geostrophic balance of height and wind with temp adjustment. Cloud fields are now balanced with the other fields. Source directory: lapssrcbalance Parameter namelist file: staticbalance. nl The balance package starts by inputting the results from a simple, offline cloud model which retrieves liquid and ice partitioning and an estimate of vertical motion from the observed clouds (lwclco). The variational scheme is designed to accept cloud vertical motion estimates and ice and water content as observations. The cloud observations are fully coupled to the three dimensional mass and momentum field using dynamical constraints which minimize the local tendency in the velocities and ensure continuity is satisfied everywhere. The scheme performs the analysis on the difference from an input model background with the benefit that existing background model balances need not be recreated each model cycle and that background model error daily compiled is input explicitly on a gridpoint by gridpoint basis. Reference: McGinley, J. A. and J. R. Smart, 2001: On providing a cloud-balanced initial condition for diabatic initialization. Preprints, 18th Conf. on Weather Analysis and Forecasting, Ft. Lauderdale, FL, Amer. Meteor. Soc. 3.3.10 STMAS3D Process: STMAS3D. exe - Space-Time Mesoscale Analysis System in 3D This analysis can be run with the other appropriate executables by using the - V STMAS3D option in sched. pl 3.4 Model Initialization Postprocessing LAPS analyses are used to initialize various mesoscale models (e. g. WRF, MM5, HIRLAM, BOLAM) to accomplish the prediction component. The forecast models themselves are obtained separately from the LAPS analysis tar file. There is some documentation for the model interfacing (for MM5) at this URL: For the WRF model we have a flow chart that illustrates an example of the initialization process: laps. noaa. govdocHMT-m1.png 3.4.1 LAPSPREP Process: lapsprep. exe - Post-processes LAPS analysis files into formats that can be used to initialize a local forecast model (e. g. MM5, RAMS, WRF) This process reformats LAPS data into files suitable for initializing a mesoscale forecast model. The output format is controlled by the outputformat entry in lapsprep. nl and can be set to one of the following: outputformat wps This causes the program to output a file in the WPS format (as needed for WRF version 3). Note that WPS has a constraint that the vertical levels of the initial condition (LAPS) be matched with those from the lateral boundary condition. This matching can be done either when running LAPS or in the WPS processing steps by three methods. 1) In an example with the GFS as a lateral boundary condition one can reduce the levels in the LAPS staticpressures. nl namelist as in this example: laps. noaa. govwpspressures. nl. gfs 2) In an example with the NAM as a lateral boundary condition and if LAPS has more analysis levels than the NAM one can use the WPS utility modlevs. exe. It uses the namelist. wps to rip out the NAM levels not in the namelist. The NAM data has levels from 1000 to 100 at a 25 mb interval plus a surface level. 3) The third method is the most desirable option that we recommend. We first run metgrid. exe for the boundary conditions (e. g. NAM), starting at the initial time and proceeding through the forecast times. We then run real. exe for the boundary conditions over the entire period. This will produce wrfbdyd01 and wrfinputd01 files. We next run metgrid. exe for LAPS, followed by running real. exe for LAPS only at the initial time. In this way the wrfinputd01 (initial time file) will be overwritten by the LAPS initial condition. outputformat cdf Writes a NetCDF file of the output outputformat wrf This causes the program to output a file in the WRF Standard Initialization gribprep format. These files can be read by the WRF SI hinterp process. outputformat mm5 This causes the program to output a file in the MM5v3 pregrid (v4) format that can be read in by MM5 the regridder pre-processor. See the NCAR MM5 REGRID documentation for the format specification of this output file. outputformat rams This causes the program to output a file in the RAMS 4.x RALPH2 format. These files can be read in by the RAMS ISAN pressure stage process. Note that RALPH2 files are in ASCII, so these files are actually human-readable. See the RAMS RALPH2 format specification for documentation. There are three other namelist entries in the lapsprep. nl file: hotstart: Set to. true. if you wish to include the cloud species from the cloud analysis in the output files. This currently only applies when outputformat is equal to mm5 or wrf. balance: Set to. true. if you wish to use the wind and temperature, height, and surface analysis files from the balance package. This will only work if LAPS is running the balance package. adjustrh: Set to. true. if you wish to use the adjusted RH analysis from the balance directory. This program essentially replaces part of the dprep. exe functionality, in that it produces initial conditions files for your local forecast model. If running a forecast model in real time, then this program should be executed immediately following the LAPS analysis during the hours in which the model will be initialized. It can simply be run as the last entry in sched. pl, which means you will always have an initial condition file avaialble immediately following your LAPS analysis. To actually initialize a forecast model, you will still need to run the appropriate program to build the lateral boundary condition files, as LAPSPREP does not provide this function. Parameter namelist file: staticlapsprep. nl Source directory: lapssrclapsprep 3.4.2 LAPS2GRIB Process: laps2grib. exe - Converts LAPS analysis output into a single GRIB2 file located in the lapsprdgr2 subdirectory. The parameters to convert are entered into a configuration file the choice of parameters and the scaling of the parameters is controllable. (author: Brent Shaw) Parameter namelist file: staticlaps2grib. nl lrunlaps2grib. false. (default) or. true. (to create grib2 lapsprdgr2 files) Data file: staticlaps2grib. vtab Source directory: lapssrclaps2grib E. g. parameters in data file: staticlaps2grib. vtab 3d 0,lt1,t3 , 1000.,110000. 1. 0,0, 0, 0 3d 0,lt1,ht , 1000.,110000. 1. 0,0, 3, 5 2d l1s, r01,1000.,4, 1, 0, 0,255,255,255,0, 1, 8 There are two numbers in the laps2grib. vtab file that immediately follow the file name extension and variable name: the conversion factor and the scale factor. The conversion factor will be multiplied by the LAPS variable coming out of the file in order to make the units conform to WMO specs (e. g. like cloud cover, which WMO defines as a percent from 0-100 whereas LAPS uses a fraction of 0-1. so we set the conversion factor to 100). In the case of precipitation, the units need to be in mm for GRIB, so if LAPS has precip specified in meters, then your conversion factor needs to be 1000 so you can get the data into mm. The scale factor specifies how many digits of precision to preserve after the decimal. It can be negative (for example, -1 would have precision to the nearest 10, 0 would give you to the nearest, and 1 gives you 110th, and so forth). So, if you have something that is typically very small (say, mixing ratio which in kgkg ranges from 0.0001 to about 0.01, you might use a scale factor of 4 to preserve 4 digits after the decimal. On the other hand, with cloud cover you may only need the nearest integer value from 1-100, so you could use 0. See lapssrclaps2griblaps2grib. doc for more detailed information. 3.4.3 WFOPREP Process: wfoprep. exe - Processes AWIPSWFO large-scale model forecast files into formats that can be used as lateral boundary conditions to initialize a local forecast model (e. g. MM5, RAMS SMF, WRF). The input files come from the SBN and are in netCDF format. (author: Brent Shaw) This an optional program that can be used in the AWIPSWFO environment. In other environments youll want to use a different program to generate lateral boundary conditions. Parameter namelist file: staticwfoprep. nl Source directory: lapssrcwfoprep 3.4.4 LFMPOST Process: lfmpost. exe - Post-processes WRFMM5 model forecast files into formats that can be used to feed back into LAPS analysis or plotting software. authors: Linda Wharton, Brent Shaw, John Snook, Steve Albers, Isidora Jankov contacts: Linda Wharton Steve Albers Parameter namelist file: staticlfmpost. nl Source directory: lapssrcnewlfmp (new default version) lapssrclfmpost (old version) The default (newer) version of the lfmpost program consists of a Fortran executable: LAPSINSTALLROOTbinlfmpost. exe This has been tested so far with WRF version 3. There is also an old version of lfmpost. To build this version run make and make install in the srclfmpost directory. Then in LAPSDATAROOTstatic (or the template) copy lfmpostold. nl to lfmpost. nl. LFMPOST is used to post-process raw model output files from the following models: 1. MM5 (Version 3 binary output format) 2. WRF (NCAR EM core, Version 1.3 netCDF output format) old lfmpost. exe 3. WRF (NCAR EM core, Version 2 netCDF output format) old lfmpost. exe 3. WRF (Version 3) new lfmpost. exe It performs the following functions: 1. Read in model output for each time 2. Destagger variables to LAPS grid points 3. Vertically interpolation to isobaric levels 4. Output various formats, including LAPS fuafsf netcdf format, Vis5D format, GRIB-1, and tabular text point forecast files. It is controlled by the namelist file lfmpost. nl. If processing point forecasts, you also need to set up lfmpostpoints. txt. Samples of these two files can be found in your LAPSSRCROOTdatastatic directory. To use lfmpost, you will need to copy these two files into MM5DATAROOTstatic or MOADDATAROOTstatic (for MM5 or WRF, respectively) and edit them to your liking. If you are going to output LAPS fuafsf files with lfmpost, you will need a valid LAPSDATAROOT for the same model domain, and your pressure levels selected in lfmpost. nl must be the same levels selected in LAPSDATAROOTstaticpressures. nl. Note that for this option, lfmpost expects the horizontal domain (dimensions, projection, etc.) to identically match for LAPS and the model being used. To execute lfmpost, you should set the following environment variables as necessary: MM5DATAROOT (if running MM5) MOADDATAROOT (if running WRF) LAPSDATAROOT (if fuafsf output is desired) LFMPOST expects to find the raw output files in: MM5DATAROOTmm5prdraw (MM5) MOADDATAROOTwrfprd (WRF v1 and v2) Output from lfmpost goes into: MM5DATAROOTmm5prdd (for MM5) MOADDATAROOTwrfprdd (for WRF) Within the output directories, the following subdirectories need to exist to contain the specific output formats: fsf - For LAPS fsf files (2d and surface fields) fua - For LAPS fua files (3d isobaric output) grib - GRIB data old lfmpost. exe points - Tabular text point forecasts v5d - Vis5D files After setting the appropriate environment variables and ensuring your namelists are configured properly, the syntax (old lfmpost. exe) is: lfmpost. exe NAME DOMNUM where NAME is one of mm5, wrf, or wrf2 for MM5, WRFv1.3, or WRFv2, respectively. DOMNUM is the nest to process. Additional arguments are needed for the new (default) version of lfmpost. exe. lfmpost. exe NAME WRFOUT NEST RCTIME FCSTTIME LAPSDATAROOT NAME - one of mm5, wrf, or wrf2 for MM5, WRFv1.3, or WRFv2, respectively. WRFOUT - full filename of WRFout file NEST - nest number (1 is outer) RCTIME - CTIME in seconds of model initialization FCSTTIME - number of seconds into the forecast LAPSDATAROOT - LAPSDATAROOT where static files are set up (or the equivalent in the WRF directory) LFMPOST is designed to operate on incremental raw model output data, so when you run WRF, be sure to output each time period to a separate file. When running lfmpost in real-time for WRF output there is a Perl script that can be used: LAPSINSTALLROOTetclfmpost. pl (use wrfpost. pl for older lfmpost. exe) There is also a driver script located in etcmodelslfmposttest. csh, often used for non-realtime case runs, that can be executed as in this example: lfmposttest. csh LAPSINSTALLROOT LAPSDATAROOT RUNTIME mvoutput RUNTIME is model initialization time with format yyyymmddhh 3.4.5 FORECAST GRAPHICS A script can be run in cron (after the FUAFSF files are created) to make GIF images of various forecast fields. This is located in etcfollowupfcst. pl. Output images will appear in lapsprdwwwfcst2d. 3.4.6 VERIFICATION LAPS has a built-in verification package. This can be run after a model is run and the verifying observations and analyses are available. The driver script is in etcverifveriffcstdriver. csh. For real time runs it can be run via cron once for each model cycle. The script has several command line arguments that are described in comments at the top. The script will produce stats files and PNGGIF image output in the lapsprdverif directory tree. To help in setting this up or troubleshooting the results please note the input data that are being used: 1) FUAFSF forecast files should be located in LAPSDATAROOTlapsprdfmodel. f 2) Observation and analysis files should be located in various other lapsprd subdirectories. Some examples are as follows: 3) Several parameters are relevant in staticnest7grid. parms including: modelcycletime, modelfcstintvl, modelfcstlen, fddamodelsrc 4) Log files are in LAPSDATAROOTlogfcstverif 5) Animated montages are an option that will work if followupfcst. pl is run prior to the verification (see previous sub-section 3.4.5). 4.0 Porting code mods from LAPS users back to GSD We would like to encourage suggestions from LAPS users on how to improve LAPS, both scientifically and in the software itself. The changes should be made by downloading the most recent source code tree. Edit your changes in the source files, and then retar part or all of the source tree to send back to us. Please state the LAPS version number you had used. Any documentation pertaining to the reasoning behind the changes would be appreciated. In some cases, a less formal process may be easier to go by. Here, the user can provide documentation of suggested mods either in descriptive form, or in terms of before and after code. The code author can then implement the changes in the GSD version. This can be useful in the event the mods are simple, or if the user has been working with a relatively old version of the software andor there have been significant recent GSD mods to the software. This can also be useful if the user has an idea of a desired functionality within LAPS, but has not actually looked at the software details associated with implementing the functionality. 5.0 LAPS Output Variables and netCDF File Organization LAPS Variables and netCDF File Organization LAPS output is written in netCDF format as summarized below. Each file extension contains a set of variables that goes into a separate directory under LAPSDATAROOTlapsprd. This directory includes so-called pre-balanced files, while the final balanced output is in the lapsprdbalance subdirectory. For example the LT1 temperature grid is written with the pre-balanced version in lapsprdlt1 and the balanced version in lapsprdbalancelt1. Map projection attributes are specified in the NetCDF files. Here are some of their definitions: Lat1: latitude of lower left corner grid point Lon1: longitude of lower left corner grid point Lov: longitude on map projection where grid is oriented along true north-south Note that netCDF information on the units of the fields, etc. is contained in the LAPSDATAROOTcdl. cdl files. At the bottom of the list is a section on the intermediate files that are computed while the ingest is running. File LAPS CDF Num Ext Var Var Lvl Field Process surface:LSX U su 1 Surface (10m) wind u (grid north) V sv 1 Surface (10m) wind v (grid east) P fp 1 Reduced Pressure (constant height sfc) PP pp 1 Perturbation Pressure (if available) T st 1 Temp (2m) TD std 1 Dewpt Temp TGD tgd 1 Ground Temp (land surfaceSST) VV vv 1 Vertical Velocity RH srh 1 Relative Humidity MSL mp 1 MSL Pressure TAD ta 1 Temp Advection TH pot 1 Potential Temp THE ept 1 Equivalent Potential Temp PS sp 1 Station Pressure (terrain following) VOR vor 1 Vorticity MR mr 1 Mixing Ratio MRC mc 1 Moisture Flux Convergence DIV d 1 Divergence THA pta 1 Potential Temp Advection MRA ma 1 Moisture Advection SPD spd 1 Surface Wind Speed CSS cssi 1 CSSI VIS vis 1 Surface Visibility FWX fwx 1 Fire Danger (LAPS Kelsch) HI hi 1 Heat Index Process temp: LT1 T3 t 21 Temperature HT z 21 Height (geopotential meters) PBL PTP ptp 1 Boundary Layer Top (pressure) PDM pdm 1 Boundary Layer Depth (in meters) Process accum: L1S S01 s1hr 1 Snow Ac cum Cycle STO stot 1 Snow Accum Storm Tot R01 pc 1 Liq Accum Cycle RTO pt 1 Liq Accum Storm Tot Process humid: LQ3 SH sh 21 Specific Humidity LH3 RH3 rh 21 Relative Humidity RHL rhl 21 Relative Humidity with resp to liquid LH4 TPW tpw 1 Integrated Total Precipitable Water Vapor Process wind: LW3 U3 u 21 Wind u (wrt GRID NORTH) V3 v 21 Wind v (wrt GRID EAST) OM om 21 Wind omega LWM SU u 1 Surface wind u (wrt GRID NORTH) SV v 1 Surface wind v (wrt GRID EAST) Process cloud: LC3 LC3 camt 42 Fractional Cloud Cover (levels 1-42) LCB LCB cbas 1 Cloud base LCT ctop 1 Cloud Top CCE cce 1 Cloud Ceiling LCV LCV ccov 1 Cloud Cover CSC csc 1 Cloud Analysis Implied Snow Cover ALB 1 LAPS derived albedo S3A 1 3.9u satellite data S8A 1 11u satellite data RQC 1 Radar QC information (2D vs 3D) SWI 1 Downward Shortwave Radiation LPS REF ref 21 LAPS Radar Reflectivity Process deriv: LCP LCP ccpc 21 Fractional Cloud Cover Pressure Coord LWC LWC lwc 21 Cloud Liquid Water ICE ice 21 Cloud Ice PCN pcn 21 Hydro meteor Concentration RAI rai 21 Rain Concentration SNO sno 21 Snow Concentration PIC pic 21 Precipitating Ice Concentration LIL LIL lil 1 Integrated Liquid Water lic 1 Cloud Ice cod 1 Cloud Optical Depth cla 1 Cloud Albedo vis 1 Visibility LCT PTY spt 1 Sfc Precip Type PTT ptt 1 LAPS Sfc Precip Type SCT sct 1 Sfc Cloud Type LMD LMD mcd 21 Mean Cloud Drop Diameter LCO COM cw 21 Cloud omega LRP LRP icg 21 Icing Index CTY CTY ctyp 21 Cloud Type PTY PTY ptyp 21 Precip Type LMT LMT etop 1 Max Echo Tops LLR llr 1 Low Level Reflectivity LST LI li 1 Lifted Index PBE pbe 1 Positive Bouyant Energy NBE nbe 1 Negative Bouyant Energy SI si 1 Showalter Index TT tt 1 Total Totals Index K k 1 K Index LCL lcl 1 Lifted Condensation Level WB0 wb0 1 Wet-Bulb Zero LWM SU u 1 Surface wind u (grid north) SV v 1 Surface wind v (grid east) LHE LHE hel 1 Helicity MU mu 1 Mean wind u (grid north) MV mv 1 Mean wind v (grid east) LIW LIW liw 1 log(LIomega) UMF umf 1 Upslope Component of Moisture Flux LMR R mxrf 1 Column Max (Composite) Radar Reflectivity LFR HAH hah 1 High Level Haines Index HAM ham 1 Mid Level Haines Index FWI fwi 1 Fosberg Fireweather Index VNT vnt 1 Ventilation Index UPB upb 1 PBL Mean Wind U-component (grid north) VPB vpb 1 PBL Mean Wind V-component (grid east) CWI cwi 1 Critical Fire Weather Index Process soil: LM1 LSM lsm 3 Soil Moisture LM2 CIV civ 1 Cumulative Infiltration Volume DWF dwf 1 Depth to wetting front WX wx 1 WetDry grid point EVP evp 1 Evaporation Data SC sc 1 Snow cover SM sm 1 Snow melt MWF mwf 1 Soil Moisture content Wetting Front LAPS Fcst Model: FUA U3 ru 21 Fcst Model Wind u (grid north) V3 rv 21 Fcst Model Wind v (grid east) HT rz 21 Fcst Model Height (geopotential meters) T3 rt 21 Fcst Model Temperature SH rsh 21 Fcst Model Specific Humidity FSF USF usf 1 Fcst Model Surface wind u (grid north) VSF vsf 1 Fcst Model Surface wind v (grid east) TSF tsf 1 Fcst Model Surface Temperature DSF dsf 1 Fcst Model Dewpoint RH rh 1 Fcst Model Relative humidity LCB lcb 1 Fcst Model Cloud base LCT lct 1 Fcst Model Cloud top P p 1 Fcst Model 1500m pressure SLP slp 1 Fcst Model MSL pressure PSF psf 1 Fcst Model Surface pressure LIL lil 1 Fcst Model Integrated cloud liquid water TPW tpw 1 Fcst Model Total precipitable water vapor R01 r01 1 Fcst Model Liquid accum cycle RTO rto 1 Fcst Model Liquid accum storm total S01 s01 1 Fcst Model Snow accum cycle STO sto 1 Fcst Model Snow accum storm total TH th 1 Fcst Model Potential temperature THE the 1 Fcst Model Equivalent potential temp PBE pbe 1 Fcst Model Positive buoyant energy NBE nbe 1 Fcst Model Negative buoyant energy PS ps 1 Fcst Model Surface pressure CCE cce 1 Fcst Model Cloud ceiling VIS vis 1 Fcst Model Visibility LCV lcv 1 Fcst Model Cloud cover LMT lmt 1 Fcst Model Max echo tops SPT spt 1 Fcst Model Sfc precip type LHE lhe 1 Fcst Model Helicity LI li 1 Fcst Model Lifted index HI hi 1 Fcst Model Heat index SWI swi 1 Downward Shortwave Radiation SWO swo 1 Fcst Model Outgoing Shortwave Radiatio n LWO lwo 1 Fcst Model Outgoing Longwave Radiation FWI fwi 1 Fcst Model Fosberg fire weather index FWX fwx 1 Fcst Model Kelsch fire weather index RSM LSM lsm 11 Fcst Model Soil Moisture Intermediate LAPS files: Process vrcdriver: VRC REF ref 1 NOWRAD 2D radar reflectivity Process mosaicradar: VRZ 21 (3D reflectivity mosaic) Process remap: V01 REF refd 21 Radar reflectivity VEL veld 21 Radial Velocity NYQ nyqd 21 Nyquist velocity files V02, V03, V04, V05, V06, V07, V08, V09, V10, V11, V12, V13, V14, V15, V16, V17, V18, V19, V20 same format Process lga. exe (background model): LGA HT ht 21 Model isentrop height interp to LAPS isobaric (geopotential meters) T3 t 21 Model isentrop temp interp to LAPS isobaric SH sh 21 Model specific humidity U3 u 21 Model u wind component (grid north) V3 v 21 Model v wind component (grid east) OM om 21 Model vertical velocity (Pascalssecond) LGB USF usf 1 Model Surface wind u (grid north) VSF vsf 1 Model Surface wind v (grid east) TSF tsf 1 Model Surface Te mperature TGD tgd 1 Model Ground Temperature DSF dsf 1 Model Dewpoint SLP slp 1 Model MSL pressure PSF psf 1 Model Surface pressure RSF rsf 1 Model Specific Humidity P p 1 Model reduced pressure PCP pcp 1 Model Precipitation Process lvdsatingest: LVD S8W s8w 1 GOES IR band-8 bright temp warmest pixel S8C s8c 1 GOES IR band-8 bright temp coldest pixel SVS svs 1 GOES visible satellite - raw SVN svn 1 GOES visible satellite - normalized ALB alb 1 albedo S3A s3a 1 GOES IR band-3 bright temp averaged S3C s3c 1 GOES IR band-3 bright temp filtered S4A s4a 1 GOES IR band-4 bright temp averaged S4C s4c 1 GOES IR band-4 bright temp filtered S5A s5a 1 GOES IR band-5 bright temp averaged S5C s5c 1 GOES IR band-5 bright temp filtered S8A s8a 1 GOES IR band-8 bright temp averaged SCA sca 1 GOES IR band-12 bright temp averaged SCC scc 1 GOES IR band-12 bright temp averaged Note: band-8 is approx 11.2 microns. Static LAPS file - run by localization: gridgenmodel. exe: creates file static. nest7grid LAT 1 Latitude (degrees) LON 1 Longitude (degrees) AVG 1 Mean elevation MSL (m) STD 1 Unused ENV 1 Unused ZIN 1 Z coordinate - used for plotting in AVS LDF 1 Land Fraction (0water,1land) USE 1 LanduseIndex of software LAPS README This LAPS README file (version 0-56-9) is viewable on the WWW via the LAPS home page at laps. noaa. gov 1.0 General LAPS info Below is a description of the tar file containing the LAPS data ingest and analysis code. The predictive component of LAPS (MM5, RAMSSFM, ETA) is set up separately (see Section 3.4). Please note that GSD provides support for LAPS software only if a prior agreement is made to that effect. Additionally, questions concerning LAPS must be asked in reference to the latest released tar file we cannot support older versions of LAPS code. It is also recommended that LAPS users try to take advantage of the latest LAPS updates by periodically importing a fresh tar file every few months or so. Please check the LAPS Software Page at laps. noaa. govcgiLAPSSOFTWARE. cgi for information about recent releases. A flow chart for the LAPS software can be found at: laps. noaa. govdocSlide1.png 1.1 LAPS Software Disclaimer Open Source LicenseDisclaimer, Forecast Systems Laboratory NOAAOARGSD, 325 Broadway Boulder, CO 80305 This software is distributed under the Open Source Definition, which may be found at opensource. org. In particular, redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain this notice, this list of conditions and the following disclaimer. - Redistributions in binary form must provide access to this notice, this list of conditions and the following disclaimer, and the underlying source code. - All modifications to this software must be clearly documented, and are solely the responsibility of the agent making the modifications. - If significant modifications or enhancements are made to this software, the GSD Software Policy Manager (softwaremgr. fslnoaa. gov) should be notified. THIS SOFTWARE AND ITS DOCUMENTATION ARE IN THE PUBLIC DOMAIN AND ARE FURNISHED AS IS. THE AUTHORS, THE UNITED STATES GOVERNMENT, ITS INSTRUMENTALITIES, OFFICERS, EMPLOYEES, AND AGENTS MAKE NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE USEFULNESS OF THE SOFTWARE AND DOCUMENTATION FOR ANY PURPOSE. THEY ASSUME NO RESPONSIBILITY (1) FOR THE USE OF THE SOFTWARE AND DOCUMENTATION OR (2) TO PROVIDE TECHNICAL SUPPORT TO USERS. 2.0 Installing and running the LAPS IngestAnalysis code 2.1 UNIX System Requirements Supported UNIX platforms include. We are working on adding more supported platforms. We welcome suggestions on how to modify LAPS for other platformsversions. Note that we cannot guarantee the portability of LAPS to all of these other platforms (e. g. Windows NT). 2.1.1 NetCDF library The netCDF package is required for laps, we suggest using version 3.6.0 available here: Once netCDF is properly installed, check that the ncdump and ncgen programs are in your path (e. g. which ncdump), so that configure will find them and provide the laps package with the proper path. The path setting will also help LAPS programs to run properly. Note that this path specficiation will override anything supplied with the --netcdf command line argument. NetCDF is a general format structure. The detailed format of each data file is self-describing (via ncdump), and is mirrored in a separate static file called the CDL. This CDL can be GSDs version or someone elses. If possible, check that your netCDF library is built to be compatible with the same FORTRAN compiler that you are using. The netCDF library contains C routines that are to be linked with the LAPS FORTRAN routines. Please see the discussion in section 2.2.2.1 for details on troubleshooting this. 2.1.2 Perl The perl package is also required for laps, it is available via internet at any perl site such as perl. Perl 5.003 or higher is required. Check that perl is in your path (e. g. which perl). 2.1.3 make Laps Makefiles work best by using gnu make (version 3.75 or higher). This is downloadable from gnu sites such as the following URL: gnu. orgsoftwaremakemake. html. You can check your version of gnu make by typing make - v. Some vendor provided make utilities may also work, however if you find you are having problems in this area please try obtaining and using gnu make. Check that make is in your path. 2.1.4 C Compiler In general, an ANSI compliant C compiler should be used. On some hardware ANSI compliance requires a compiler flag, if youre not sure check the documentation for your compiler. Some platforms such as Solaris and HPUX do not come with an ANSI compliant C compiler by default. If you have not purchased that additional product from the vendor, we recommend GNU C (gcc) available at gnu. orgsoftwaregccgcc. html. Check that the C compiler is in your path. With the pgf90 FORTRAN compiler, pgcc is recommended. With the Intel ifort FORTRAN compiler, icc is recommended. For AIX, Solaris, HPUX platforms, cc is recommended. 2.1.5 FORTRAN Compiler Please note that LAPS uses dynamic memory within the FORTRAN code in the form of automatic and allocatable arrays, as well as other FORTRAN 90 constructs. This implies that you will need an f90 compiler or the equivalent. LAPS will no longer work on most f77 compilers. Check that the FORTRAN compiler is in your path. For IBMAIX platforms xlf is recommended. For Solaris HP-UX platforms, f90 works well. For Linux platforms (i386,i686,x8664), pgf90 is suggested ifort (version 12.0.4 or later) is being tested gfortran is being tested For Linux platforms (Alpha chip), fort is suggested (normal serial use). 2.1.6 Disk Space The disk space requirements for LAPS vary depending on factors such as domain size and purge parameters. As a general guide, 10MB would be needed for source code. About 30MB are needed for executable binaries. 500MB to 1GB are typically needed for 12-24 hours worth of output data. A similar amount of space is needed for the raw input data. 2.1.7 Memory Etc. (ulimit) ulimit settings should be placed at unlimited if possible. Memory requirements vary for LAPS. As a general guide, 128MB is needed and 256MB is preferred. More is needed for large domains. For very large domains, a rough guide to the memory needed would be 100 x NX x NY x NZ bytes. 2.1.8 Plotting NCAR graphics library (optional) Lapsplot is an optional plotting program, thus NCAR graphics is optional. If you wish to build the lapsplot process, access to NCAR graphics libraries is needed so you will be able to run the ncargf77 command in the LAPS Makefiles. You can download the free NCAR graphics (NCL) software at the URL shown below. Note that NCAR graphics libraries should be built against the same FORTRAN compiler being used in LAPS. The lapsplot. exe executable is an interactive program that reads in the netCDF LAPS files and produces a gmeta file as output. The gmeta file can be displayed using other NCAR graphics utilities like ctrans and idt. Lapsplot is designed to work with version 3.2 (or higher) of NCAR graphics. The environment variable NCARGROOT should be set when configuring, compiling, or running lapsplot. exe. Before running configure, check that ncargf77 andor ncargf90 is in your path. If you are using a compiler other than f77, check after running configure to see that the right thing was done by inspecting NCARGFC and FC within srcincludemakefile. inc. NCARGFC should point to either the ncargf90 or ncargf77 script. If configure wants to use ncargf90 and you dont yet have one, then consider making a soft link called ncargf90 that points to the ncargf77 script, or copying ncargf77 to a new location and calling it ncargf90. If you only have an ncarg90 script (i. e. no ncargf77), you may want to also make a script called ncargf77 that lists the f77 compiler. This can help configure do its test for making the switch over from ncargf77 to ncargf90. Lapsplot is built as a special option to make, simply type make lapsplot or make installlapsplot. It is not built with a plain run of make. In order to get lapsplot to compile and link properly it may be necessary to edit your own version of ncargf90 or even the original ncargf77 script. Check that the proper FORTRAN compiler, load flags, and load libraries are set in the script. A possible alternative to fixing ncargf77ncargf90 is to edit srcincludemakefile. inc with the full path for NCARGFC, and appropriate compiler for FC (and possibly compiler flags) for your system (after running configure). At times the linking of lapsplot may show undefined references to library routines. This often represets a mismatch between NCAR graphics and various system libraries. Possible solutions for this include editing the library list within the ncargf77ncargf90 script or switching the - Bstatic flag on or off. Lapsplot can be modified to show political boundaries outside of the U. S. The following data files are relevant from the staticncarg directory: continentminusus. dat, statefromcounties. dat, and uscounty. dat. These political boundary files are stored in bigendian format. These would need to be converted manually prior to using lapsplot, if your machine is expecting littleendian. We will consider automating this in the future. To run lapsplot manually you can do the following. 1. setenv LAPSDATAROOT to the correct path 2. run LAPSINSTALLROOTbinlapsplot. exe (answer the questions it asks interactively) Please note that lapsplot is provided to help you check out how your LAPS implementation is working. Aside from the pre-generated and on-the-fly web products, we do not have any other plotting or visualization packages available for distribution with LAPS at this time. Many users have interfaced LAPS with their own display software (e. g. IDV, VIS5D, AVS, IDL, NCL, NCVIEW, GEMPAK). IDV is handy as it can read Grib-2 LAPS analysis output that can be generated via the laps2grib program. Feel free to post questions about the various plotting packages to the online LAPS forum. Another note of interest is that LAPS is visualized as an integral part of the AWIPS ALPS systems. If you have AWIPS (including either AWIPS-I or AWIPS-II), then LAPS should be running on it and you can view its output on the workstation. 2.1.8.1 Web Display The gmeta file can be converted into a GIFJPEG file for web display by using ctrans in conjunction with the netpbm package of image conversion programs that can be downloaded at the link just below. Within this package our web display scripts use the rastopnm and ppmtogif programs. We have the option of making pre-generated GIF images that can be displayed on the web by invoking the sched. pl - f dummy command line argument. Please see section 2.4 for more info on sched. pl. The web images appear as. gif files in the lapsprdwwwanal2d directory. The associated web related scripts (for analyses) such as etcwwwfollowupncarg. sh are in the repository. These wrapper scripts run lapsplot. exe and output the GIF images suitable for web display. The set of web image products are defined with configuration files in staticwwwlapsplot.. Color tables are specified in staticwww. lut. Other user definable plotting parameters are located in staticlapsplot. nl. A separate web related script is our on-the-fly page that is contained in etcwwwnph-laps. cgi. This CGIPERL script can be run via a web server. This also calls a set of scripts that wrap around lapsplot. exe. The file system(s) running LAPS should be made visible on your web server. After running configure the following steps will help in setting up this web page. 1) edit etcwwwnph-laps. cgi and set webroot to be the root directory of the web server (document root) 2) edit etcwwwlaps. cgi and set webroot to be the root directory of the web server 3) edit etcwwwnph-laps. cgi and set ncargroot to be the root directory of the NCLNCAR Graphics installation 4) mkdir - p webrootrequest 5) cd webrootrequest ln - s LAPSINSTALLROOTetcwwwnph-laps. cgi. 6) cd webrootrequest ln - s LAPSINSTALLROOTetcwwwlaps. cgi. 7) For each DOMAIN NAME (foo): a) mkdir - p webrootdomainsfoo b) cd webrootdomainsfoo ln - s LAPSDATAROOT privatedata 8) edit etcwwwnph-laps. cgi and set defaultdomain to be your favorite domain foo within the domain list established in step (7) At this point you should hopefully be able to use a web browser and run the on-the-fly page with something like this URL: 2.1.9 GRIB2 external libraries The background models read by the model first guess ingest program (LGA) include GRIB1 and GRIB2-formatted files. If you are reading model first guess data in GRIB2 format, then you will want to install these libraries. The external compression libraries required for processing GRIB2-formatted files are libjasper. a, libpng. a, and libz. a. They are usually found in usrlib or usrlib64. It is recommended to have a system administrator install these external libraries if they are not already on your system. (JPEG2000 and other image compression algorithms are built into GRIB2. Library support for JPEG2000 is provided via the JasPer library. The implementation of JPEG2000 compression reduces file sizes up to 80.) The configure script will determine if these libraries are present. If all are found, configure prepares the file srcincludemakefile. inc with DEGRIBLIBS, DEGRIBFLAGS and CDEGRIBFLAGS values allowing the lga software to build to read both GRIB1 and GRIB2-formatted files. Without these three specific compression libraries available, lga is built to read only GRIB1-formatted files in addition to netCDF-formatted files. There may be some occasions where the Jasper library isnt detected automatically by configure. For example, if the Jasper library is placed in a location other than the system area (usrlib) then one can set an environment variable CPPINCLUDEPATH for lga to build like this: setenv CPPINCLUDEPATH optjasper1.900.1include After running configure, the DEGRIBLIBS value in makefile. inc can be manually edited to include the path information for the Jasper library. Similarly the flags - DUSEJPEG2000 and - DUSEPNG can be added to the value of DEGRIBFLAGS. The unixlinux system command ldd command prints the shared library dependancies on an executable running ldd lga. exe is a helpful command in the situation when you download the LAPS precompiled binaries and need more information about shared libraries required by lga. exe. See source directory: LAPSSRCROOTsrclibdegribREADMELIBS file for additional information. 2.1.10 GNUPLOT ImageMagick for verification (optional) LAPS has a built in verification package and this needs installation of GNUPLOT and ImageMagick to run fully. 2.2 Installation Procedure Summary To introduce this section, here is a hierarchical listing of some primary directories and files in the laps tree. The default LAPS structure is shown in the first tree below. These directories are createdaddressed in various portions of section 2.2 and beyond. Various root directories are mentioned in the form of environment variables. These can optionally be set to make it easier to follow the instructions below more literally. The installation scripts can be run without setting these variables if youd like to enter the associated paths directly as command line input. LAPSSRCROOT - The full path that was created when the LAPS tar file was untarred. This contains the source code and other supporting software. LAPSSRCROOT is needed for building LAPS but is not needed at runtime. LAPSINSTALLROOT - The full path of installed binaries and scripts (bin and etc). This is where you build the executables, configure the scripts (converted the. pl. in to. pl), and configure LAPSSRCROOTsrcincludemakefile. inc. Note: LAPSSRCROOT and LAPSINSTALLROOT are in many cases the same but dont have to be. LAPSINSTALLROOT is needed at runtime. LAPSDATAROOT - The full path to the output data and namelists. This includes lapsprd subdirectories containing both LAPS output grids and intermediate data files. LAPSDATAROOT is needed at runtime and it contains all the files configured to run an analysis domain localized to a location on earth. The LAPSINSTALLROOT tree can drive several LAPSDATAROOTs. Input data in its raw form is stored outside the LAPSDATAROOT tree. Note: LAPSDATAROOT is usually (and recommended to be) different than LAPSSRCROOTdata and LAPSINSTALLROOTdata but they dont need to be. Also, LAPSSRCROOTdatacdl and LAPSSRCROOTdatastatic are the repository versions and should be kept pristine. Note: the namelists you get from the tar are configured for our Colorado domain. More on localizing a domain for your own area later on. To summarize, these three environment variables can either be part of one directory tree or split out into separate trees as further discussed at various times below. In many UNIX environments, large data files are stored on a data disk and the source code is stored on a smaller home disk. Below is a typical laps directory structure for that setup. We recommend using something like this setup for most LAPS users. This type of separation makes it easier to update the LAPS source code while maintaining your data intact. 2.2.1 Untarring the Source Code Place the tar file in the directory homedisk or homediskbuilds. Untar the laps source code using a command like. prompt gzcat laps-m-n-o. tgz tar xf - prompt gunzip laps-m-n-o. tgz prompt tar - xf laps-m-n-o. tar The LAPSSRCROOT directory will be set up one level below the tar file. If you are having trouble running gunzip, the problem could be that the laps-m-n-o. tgz file was corrupted during the download. In that case simply try downloading again. 2.2.2 Running Configure Go to the LAPSSRCROOT directory and run. prompt. configure configure supports many options, the most important is the --prefix option which tells make where to install the laps system (FORTRAN executables, Perl Scripts, etc.). The default (if you did not use --prefix) is to install whereever the source is. The use of the --prefix option is highly recommended to make it easier to update your source code (e. g. importing a new LAPS tar file), without disturbing the binaries, data, and runtime parameters that you are working with on-site. This goes along with the second directory tree diagram shown above in Section 2.0. For example, to install laps in directory usrlocallaps (i. e. LAPSINSTALLROOT) use. prompt. configure --prefixusrlocallaps One or more data directories for running laps can be specified at runtime, if desired. A single set of binaries can thus support several data directories as described below. Another configure option is --arch. Configure tries to get the architecture from a uname command, but this can be overridden by having an ARCH environment variable or by using --arch. The allowed values for arch include aix, hpux, etc. For more information on passing in command line flags to configure run. prompt. configure --help 2.2.2.1 Modifying Compiler Flags The configure script automatically modifies the compiler and compilation flags by modifying srcincludemakefile. inc according to what type of platform you are on. Hopefully the flags will work OK on your particular platform. If you want to change the flags from the default set, you can provide command line arguments to the configure script. Some examples based on our experience are as follows: Solaris. prompt. configure --cccc For IBMAIX platforms, you will want to override the default FORTRAN compiler with xlf using the command line option --fcxlf as follows. prompt. configure --fcxlf For SGI platforms, certain flags may be needed. - mips3 seems to help on IRIX64 v6.2. A second method of modifying the compiler flags is to edit srcincludemakefile. inc, after running configure. If you find that the default compiler flags dont work for your platform or that your platform has no default, youll need to experiment to find the right set of flags. Changes in srcincludemakefile. inc will automatically modify the flags used throughout laps. If you find flags that work for your platform and would like us to add them to the defaults in configure please let us know via e-mail. On Solaris for example, you may want to remove - C from the DBFLAGS with an edit of srcincludemakefile. inc to allow compiling FORTRAN debug versions of the software. On some platforms (e. g. Linux) the linking of FORTRAN programs to netCDF and other C library routines may need adjustment. This relates to the existence and number of underscores in the C routine names when called by FORTRAN routines. Fixes for this may include a combination of changing the number of underscores in the C routines, changing the CPPFLAGS for LAPS, or changing the FFLAGS for LAPS. As an example, with errors linking to netCDF nf routines, you might rebuild the netCDF C library with a different number of underscores andor adjust the FFLAGS according to the man page in your FORTRAN compiler. On a Linux-Intel machine the netCDF library can be rebuilt with the following flags. Errors linking to other LAPS C routines can be addressed with other adjustments to the CPPFLAGS (among FORTRANUNDERSCORE and FORTRANDOUBLEUNDERSCORE) or the FFLAGS. 2.2.3 Ingest Software changes In this file (mainly Sec 2.3), a number of potential manual changes to ingest code are outlined prior to running make and LAPSINSTALLROOTetclocalizedomain. pl, especially if one is using ingest data formats other than standard ones used at GSD. After becoming familiar with the changes needed for your implementation, it is recommended that you develop a method to save the hand edited files in a safe place outside of the laps directory structure, or by using a revision control system such as CVS. This strategy would make it easier to update your implementation of LAPS with the latest laps-m-n-o. tgz file from GSD, while minimizing the hassle involved with software modifications for your local implementation. 2.2.4 Running make The next step is to build and install the executables, this can be done by running the following (note the syntax might vary if the shell you are using is different from Bourne shell). prompt cd LAPSSRCROOT prompt make 1 make. out 21 prompt make install 1 makeinstall. out 21 prompt make installlapsplot 1 makeinstalllapsplot. out 21 Check that the executables have been placed into the LAPSINSTALLROOTbin directory. The total number should be the number of EXEDIRS in LAPSSRCROOTMakefile plus 2 this includes lapsplot. exe. Lapsplot can be installed only if you have NCAR graphics. We recommend using Gnu Make Version 3.75 or later available via ftp from any GNU site. There are many other targets within the Makefile that can be used for specialized purposes, such as cleaning things up to get a fresh start. In particular, note that a make distclean is recommended before running configure a second time so that things will run smoothly. 2.2.5 Geography databases Currently there are three mandatory geography databases required to localize a LAPS domain (with a fourth optional one). These are: 1) terrain elevation (required) 2) landuse category (required) 3) albedo climatology (required) 4) soil type bottomtop (optional) The other geography data paths listed in staticnest7grid. parms represent data that can be processed by the localization though are unneeded by the analyses. Hence it is unnecessary to download these and they arent available on our software download web page. The 30 terrain elevation data is found in the tar files for topo30s. The landuse data is global 30 data and required to compute a landwater mask. The mask is used during localization to force consistency between the other geography data at land-water boundaries. Land fraction is derived from the landuse data using the water category, with valid values ranging continuously between 0.0 and 1.0. The global albedo climatology database has less resolution than either the terrain or landuse data. The albedo is approximately 8.6 minutes (0.144 degs) and was obtained from the National Center for Environmental Prediction (NCEP). This data is used in the LAPS cloud analysis with visible imagery data. The geography data come in compressed tar files separate from the rest of the LAPS distribution. The data are used in process gridgenmodel which is the fortran code to process all the geography data as specified by the user (see section 2.7.4 for more information about gridgenmodel). Only one copy of the geography data is required no matter how many LAPS dataroot installations you are supporting. The paths to the geography data directories (topo30s, landuse30s, and albedoncep) are defined as runtime parameters within the nest7grid. parms file (Sec 2.2.6). The geography data is available on the LAPS Home Web page (software link). You will find the following global data sets at this webftp site. Some of the data have been subdivided into quartershperes for easier downloading. Select the files needed for your application or get all of them if you intend to generate localizations around the entire globe. 132446109 Aug 24 2001 topo30stopo30sNE. tar. gz 63435504 Aug 24 2001 topo30stopo30sNW. tar. gz 37194099 Aug 24 2001 topo30stopo30sSE. tar. gz 29204244 Aug 24 2001 topo30stopo30sSW. tar. gz 12324069 Aug 24 2001 landuse30slanduse30sNE. tar. gz 6118611 Aug 24 2001 landuse30slanduse30sNW. tar. gz 3355822 Aug 24 2001 landuse30slanduse30sSE. tar. gz 2808861 Aug 24 2001 landuse30slanduse30sSW. tar. gz albedoncepA90S000E albedoncepA90S000W albedoncepAHEADER We are currently working on a procedure to access higher resolution terrain and land use data from the USGS (at least to 1 arcsec). Soil Type and Other Optional Databases: The laps process gridgenmodel described below in section 3.0 can also process soil type, mean annual soil temperature, and greeness fraction but these are not mandatory data required in LAPS and therefore we do no describe them here. Soil Type can however be used in the soil moisture analysis. Youll see some reference to these data bases below and we have added paths to this data in our namelist file (nest7grid. parms) but you should enter dummy paths for these data in the event you do not have them available. The gridgenmodel process will warn that these data are not available but you should still see the localization run to completion (ie. static. nest7grid is generated). --- 2.2.5.1 High Resolution Terrain (sub-kilometer) --- High resolution terrain can be imported (experimentally) into LAPS via two methods, the WRF Wizard (see section 2.2.7), and Topograbber - see laps. noaa. govtopograbber The WRF Wizard can be used to generate a GEOGRID file on the same grid as the LAPS analysis. The terrain from this file can be imported during the LAPS localization by setting the nest7grid. parms namelist path parameter pathtotopt30s to contain the string wps in the directory name. Also, Topograbber is under development and this might be used with some further work. The tiles produced may need some modifications to the gridgenmodel. exe program so they can be read in. A second way to use Topograbber with LAPS is to generate a WPS GEOGRID terrain file, and then read that in during the LAPSSTMAS localization process (see above paragraph). 2.2.6 Localizing for single or multiple data domains Runtime parameter changes may be needed to tailor LAPS for your domain(s) this includes ingest and geography data path names, grid dimensions, grid location, and potentially other aspects of the data processing. The parameter files are datastaticnest7grid. parms, datastatic. nl, and datastatic. parms. The localization involves several operations. The parameter files are mergedupdated with the repository versions if needed. The dimensions in the cdl files are also adjusted. Then several executable programs are run including gridgenmodel. exe and gensfclut. exe as per section 3.1. Below are two mainly equivalent procedures for localizing LAPS to set up one or more domains. The first is a newer, more efficient (and highly recommended) method using domain template directories. The second is our original method for localization. Youll want to use either Method 1 or Method 2 but not both. 2.2.6.1 Localization Method 1 The first method is especially useful if you are using a separated data tree andor multiple domains. It is also recommended if you are doing repeated software updates. Once you learn this method it can save a lot of time and errors that may occur in the course of using Method 2. SETTING RUNTIME PARAMETERS If you are working in a separated data directory (e. g. using the second tree shown above), you can set up a copy of the runtime parameter files (for each window) in a new directory (called TEMPLATE) with a reduced parameter subset. The TEMPLATE directory namelist files should contain only those parameters that need to be changed for each of the domain(s) from the settings in the repository, LAPSSRCROOTdatastatic. The remaining unchanged parameters should be omitted from the TEMPLATE versions. Otherwise the template namelist looks exactly like the originally supplied namelist, except that the comment section should be omitted. The modified TEMPLATE parameters generally include map projection settings, data paths, etc. The remaining fixed parameters will later be automatically merged in from the LAPSSRCROOTdatastatic directory tree by the localization scripts (next step). Templates should be maintained in a location separate from the LAPS distribution and LAPSDATAROOT (e. g. see the template directory in the tree diagrams above). This avoids them being erased during software updates and relocalizations. Thus templates can be thought of as more permanent, since they contain parameters dependent on the local implementation and relatively independent of software updates. Once you set up the template directory youll be ready to run the windowdomainrt. pl script. Here is an idealized example illustrating the namelist merging process that is done during the localization. And here is an example of an actual template for the nest7grid. parms file. LOCALIZING with windowdomainrt. pl Generating new localizations, reconfiguring existing localizations, and reconfiguring existing localizations without removing lapsprd or log information is made easier with the perl script LAPSINSTALLROOTetcwindowdomainrt. pl (window hereafter). The window script makes use of namelist domain templates that specifically define a users localizations. The window script uses environment variables LAPSSRCROOT, LAPSINSTALLROOT, and LAPSDATAROOT, however, - s, - i, and - d command-line inputs override those environment variables as necessary depending on user needs. The - t command-line input specifies the domain template directory and the script saves the loglapsprd history if command line switch - c is not used or, completely removes LAPSDATAROOT, then does a mkdir LAPSDATAROOT if - c is supplied. The - w laps is always required. The window script can be run manually when configuring or reconfiguring localizations. Window copies the domain template namelists (partial nest7grid. parms or. nls) into a new static subdirectory which, in turn, are merged with the full namelists by script localizedomain. pl. Recall that LAPSINSTALLROOT contains bin and etc while LAPSSRCROOT contains the untarred full namelists from the repository. In the event that LAPSSRCROOT does not exist, a data subdirectory containing static and cdl must be available for use by localizedomain. pl (i. e. LAPSSRCROOT LAPSINSTALLROOT). Even though it is possible to have LAPSSRCROOTdata LAPSINSTALLROOTdata LAPSDATAROOT, this is not recommended since it does not allow multiple localizations. Templates will ensure that specific namelist modifications are merged with the untarred full namelists. Templates also ensure that specifics to a localization are merged into new software ports and new namelist variables (available with new software) are merged into existing localizations. If you decide to manually change any parameters in LAPSDATAROOTstatic after running the localization, it is suggested to make the same change in the TEMPLATE directory as well. This will help preserve your local changes in the future if you install an updated version of LAPS. 2.2.6.2 Localization Method 2 This method is included partly for historical reasons and can be useful if you havent yet learned how to use template directories andor the separated LAPSDATAROOT (see method 1). This procedure provides a result equivalent to that from Localization Method 1 and provides an alternative method (even if not recommended) of modifying the parameters. For each domain you wish to create, run. prompt cd LAPSINSTALLROOTetc prompt perl makedatadirs. pl --srcrootLAPSSRCROOT --installrootLAPSINSTALLROOT --datarootLAPSDATAROOT --systemtypelaps where the path name LAPSDATAROOT must be named differently for each data domain if there is more than one. Recall that each domain can be set up in a separate subdirectory under datadisklaps. Next, follow the setup and localization steps below. The order of the command line arguments is important, but only the first one is required. If for example a LAPSDATAROOT is not supplied, the dataroot tree location will default to where the LAPS binaries are installed via configure. Thus, the default value of LAPSDATAROOT is LAPSINSTALLROOTdata. The runtime parameters should be emplaced andor modified within each LAPSDATAROOT directory tree prior to running the localization. More details on nest7grid. parms and other parameter files are discussed in subsequent parts of Section 2. As one option you can edit the parameter files that are in LAPSSRCROOTdatastatic and tailor them for your domain. If you have LAPSDATAROOT different from LAPSSRCROOTdatastatic, then a good alternative may be to copy any parameter files you need to edit into LAPSDATAROOTstatic from LAPSSRCROOTdatastatic. Finally, you can create the static data files and look up tables specific to the domain(s) you have defined in datastaticnest7grid. parms and other runtime parameter files. Shown below is an example of running the localization for a particular laps domain. This should be repeated (with a unique dataroot) for each domain if there is more than one. prompt cd LAPSINSTALLROOTetc prompt perl localizedomain. pl --srcrootLAPSSRCROOT --installrootLAPSINSTALLROOT --datarootLAPSDATAROOT --whichtype laps 2.2.6.3 Localization with LAPS GUI LAPS has a GUI interface under development that can be used to localize the domain. This can be found in the LAPSSRCROOTgui directory. There it can installed using the installgui. pl PERL script as outlined in the local README file. 2.2.7 WRF Domain Wizard LAPS Support The WRF Domain Wizard can be used to help specify correctly navigated LAPS domain map parameters. When the Wizard is run it will write out a nest7grid. parms file for each nest that can be used as input templates for LAPS localization. 2.2.8 MPI support for LAPS wind analysis There is capability to compile and run the wind analysis (wind. exe) using MPI. We do this by doing a separate software build with mpif90 and then sched. pl runs the serial versions of most things while running the parallelized version of the wind analysis. To build LAPS using mpif90 edit the makefile. inc file, between running configure and make, adding - DUSEMPI into the CPPFLAGS. The sched script presently submits multiple processor jobs using the SGE queueing environment. We may consider adding an option to sched. pl to runsubmit directly with mpirun if that would be useful. 2.3 Raw data ingest There is a layer of raw data ingest code that may have to be modified for the individual location depending on data formats. Its purpose is to reformat and preprocess the various types of raw data into simple common formats used by the subsequent analyses. It also helps to modularize the software. Working with the ingest code is usually the largest task within the porting of LAPS. The supported component of the LAPS code is the analysis section. Ingest code is supported only if your raw data looks has the same configuration and format as GSDs raw data. It is the reponsibility of the LAPS user to modify the LAPS ingest code if necessary to generate the intermediate data files that are inputs to the analysis code. A flow chart for the ingest processes may be found at this URL: laps. noaa. govdocslide1v3.gif The default LAPS ingest code obtains raw data, generally from the GSD NIMBUS system. The raw data can either be in ASCII, netCDF (as point data), or netCDF (as gridded data - generally not on the LAPS grid). Note that the ingest code is also generally compatable with raw SBNNOAAPORT data as stored in netCDF files on the WFO-Advanced system. The ingest code processes the raw data and outputs the LAPS intermediate data files. The intermediate files are generally in ASCII for point data and netCDF format for gridded data that have now been remapped onto the LAPS grid. Most ingest code is located under the srcingest directory. When netCDf format is used for the raw data, a cdl file for the raw data is sometimes included in the source code directory. Depending on the data source, you may generally prefer one of three choices: 1) Convert your raw data to appropriate netCDF formats then run the LAPS ingest code as is. The CDLs and sample rawNIMBUS netCDF files supplied with our test dataset can serve as a guide to writing the software to do this. If the CDL is unavailable, doing ncdump - h on the actual data file will yield equivalent information. We generally do not maintain or support any software for writing raw netCDF files as this is done external to LAPS. Sometimes by posting a message to laps-users you can obtain information from other LAPS users as to how they may have implemented this step. 2) Run a process independent of the LAPS ingest code that creates the intermedate data file. 3) Modify LAPS ingest code to accept your own raw data format. This often entails writing a subroutine that reads the data and linking this routine into the existing ingest process. That process then writes out the LAPS intermediate file. Note that generating an GSD style raw data file is not here needed - all that really counts is producing an intermediate data file. Recommended only for advanced users or those who believe their modifications have enough general interest for inclusion in the baseline LAPS repository. For the model background and in-situ observations generally (1) is the best option. For gridded data (satellite or radar) options (1) or (2) usually work best. Most external users should avoid option (3) unless it is done in close consultation with LAPS staff. A key consideration is how easy it will be to update your version of LAPS and have it work with your local data. You may note the following data sources used at GSD. These data sources are what the GSD ingest code is tailored to for producing intermediate data files. Note that LAPS will still run even if some of the data sources are withheld, albeit in degraded fashion. A minimum dataset of model background and surface observations is generally needed to get reasonable results. The pathnames for the ingest data sources are assigned within the. datastaticnest7grid. parms and other. nl files and can be set accordingly at runtime. Doing a grep for path in these files will give you a quick listing of the relevant parameters. Unless otherwise specified, the time window for data in the intermediate data files should be - lapscycletime. The time window for data in the raw data files is more variable and is generally specified within the raw data (e. g. in the CDL). Further information on specific LAPS ingest processes for the various data sources is found in Section 3 of this README. 2.3.1 Model Background (lgalgb) The model first guess (background) is generally on a larger-scale grid than LAPS and is run independently. The model data is interpolated to the LAPS grid by the LAPS ingest to produce lgalgb files. The interpolation is done in time, in space, and can be from one map projection to another. This lgalgb output is distinct from the fuafsf files that are first guess files of similar format generated by the LAPS forecast model using an intermittent 4dda mode. The nest7grid. parms namelist variable fddamodelsource controls the background used in the analysis, including lga. A list of fdda backgrounds that are available with this release are specified in file etclapstools. pm - module mkdatadirs. Even though fdda subdirectories are populated with current backgrounds, the analysis can be forced to override this by making the first entry of fddamodelsource lga. The acceptable models and formats for the background model are listed in datastaticbackground. nl. Many models can be accepted in netCDF format. A new capability in LAPS is to process GRIB input without first converting to netCDF format. For Grib data to be decoded an associated Vtable. XXX needs to be found in directory datastaticVariableTables. The Vtable can be configured for either GRIB-1 or GRIB-2. However we are unable to guarentee that any model specified in background. nl will work without some software modification. Rapid Refresh (RR) grids are ftped from NCEP to GSD, then converted at GSD from GRIB to netCDF. This netCDF file is the input for the LAPS ingest process that writes lga. For more information on RR check the following URL for more info: rapidrefresh. noaa. gov Note that we often read these into LAPS as RUC (Rapid Update Cycle) look alike files. RR is also available from UNIDATA and distributed to universities through private companies like Alden. The conversion from GRIB to netCDF is done outside of LAPS by GSDs Information and Technology Services (ITS) group (in the NIMBUS system). Having the CDL should mostly be sufficient along with general knowledge of netCDF for writing out the data. Beyond that, you may wish to contact the ITS group for more info (see the reference to them in section 3.2.1). The Atlanta, Sterling, and Seattle WFOs have followed a more direct route, going from the RREta to the intermediate lga file, bypassing the netCDF file on the model grid. This includes RR on isobaric surfaces. 2.3.1.1 Acquiring Model Background Data GRIB-formatted background model files are now supported and can be directly read into lga. --- Where Can Users Find GRIB Data --- At the NCEP ftp server for real time data sets located at ftp:ftpprd. ncep. noaa. govpubdatanccfcom. These products can be downloaded from the web or via anonymous ftp. The following is a discussion for locating and acquiring NAM, GFS, and RUC model backgrounds for use with lga. The models are available in grib1 and grib2 formats as indicated. NAM Model: NAM 221 High Resolution North American grid, 32-km can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomnamprod with the directory and filenames as follows nam. nam. t.awip32.tm00 where YYYYMMDD is the current date, CC is the model cycle time (00, 06, 12, or 18) and FF is the forecast hour (00-84). awip32 indicates the 32 km North America (NCEP grid 221). GFS Models: GFS global longitude-latitude grid (360x181) 1.0 deg (fh 00-180) can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomgfsprod gfs. gfs. t z. pgrbf , and GFS global longitude-latitude grid (720x361) 0.5 deg (fh 00-180) can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomgfsprod gfs. gfs. t z. pgrb2f where CC is the model cycle time (i. e. 00, 06, 12, 18) and XXX is the forecast hour of product from 00 - 180. The 1.0 degree GFS uses file identifier pgrb (pressure-based grib) and is now available in grib2 as well when. grib2 is present. The 0.5 degree GFS uses pgrb2 (pressure-based) and is only available in grib2. RUC Model: RUC Rapid Update Cycle 40km and 20km pressure data sets can be found at ftp:ftpprd. ncep. noaa. govpubdatanccfcomrucprod ruc2a. ruc2.t z. pgrb where CC is the model cycle time (i. e. 00, 06, 12, 18) and XXX is the forecast hour of product from 00 - 12 (or more). File identifier pgrb is used for the 40km resolution and pgrb20 is used for the 20km. Additional description of NCEP products can be found at nco. ncep. noaa. govpmbproducts. A master list of NCEP GRIDS ID numbers (e. g. 211) and other specifications can be found at nco. ncep. noaa. govpmbdocson388tableb. html --- How Do Users Name The GRIB Data Files --- For LAPS ingest at NOAAESRL, we have a process that automatically downloads GRIB files to a designated directory. For example, datagridgfsglobal0p5deg, datagridgfsglobal1p0deg, and datagridgfsconus211 are three directories for the GFS global 0.5 degree, global 1.0 degree and CONUS 211 domains. The files within these directories are renamed from the complex patterns listed above to filenames with the following pattern: YYJJJHHMMhhhh. Here the hhhh part represents the number of hours into the forecast. Thus a file for GFS CONUS 211 initialized on Jul 23 2008 at 1200 UTC, with a 6 hour forecast would be named datagridgfsconus211grib0820512000006. The HRRR model follows a slightly different convention of YYJJJHHMMhhmm, so that forecasts of under one hour can be represented. --- How Does lga. exe Know Where To Find The Data --- For lga. exe, the acceptable models, directory paths and file formats are identified in datastaticbackground. nl. In the example above if we wanted to use the US-scaled data, we would set bgpathdatagridgfsconus211grib, bgmodel13 (for GRIB), and cmodelGFS. 2.3.2 Radar ingest The following are intermediate files for various forms of radar data. These may have already been pre-processed (remapped) from raw data, and at this stage are in Cartesian format on the LAPS grid. A description and flow chart showing polar radar data usage in LAPS is on the Web at: laps. noaa. govalbersremapperraw. html. with some additional text details for various types of radar data in: laps. noaa. govalbersradardecisiontree. txt. These include information on which types of radar data are processed via the various intermediate data files. Further information on using individual radar ingest processes is in Section 3. Specifically we should establish whether your raw data is in polar or Cartesian form. If polar, please take a look at Polar Radar Data in section 3.2.3. NOWRAD WSI (Cartesian) data is covered separately within Section 3.2.4. 2.3.3 Surface Data Sfc Obs (lso): GSD uses surface observations as input with the default being GSDs NIMBUS netCDF format. These are generally used when running LAPS within ESRLGSD using data from public, and is only available within GSD unless one is working with the supplied test data case. Surface observations of various types, covering much of the world are available in realtime from GSDs MADIS system (with some restrictions). This data, generally in WFOAWIPS netCDF format, are distributed via the MADIS server at madis. noaa. gov. Thus MADIS is available both inside and outside ESRLGSD. The MADIS netCDF has additional variables (such as QC flags) that go beyond what is in the NIMBUS format. The supported MADIS surface observation datasets include metar (METARSYNOP), maritime (BuoyShip), mesonet, urbanet, and others. This is an excellent source of surface observations for most users outside of ESRLGSD to start with. To request a real-time data stream please go to the MADIS data application page at this link: madis. noaa. govdataapplication. html A few other METARSYNOP formats are now being supported in LAPS software as listed in the staticobsdriver. nl namelist. The GSD code is in the . srcingestsao directory, and includes routines to read and reformat various surface data types (METARSYNOP, mesonet or localLDAD, buoyship or maritime, and GPSprofiler surface obs). There is a subroutine tree outline in the srcingestsaoREADME file including information on the supported data formats for each observation type. Paths to the datasets are specified in the obsdriver. nl file. In most cases users should be able to convert their surface observations into the NIMBUS or MADIS NetCDF formats. Note that the parameters and variable names in each NetCDF dataset or directory will vary. Only observations reasonably near the standard shelter height (2 meters, except 10 meters for wind) should be included in the LSO file. Tower mounted instruments should instead be placed in the SND file using TOWER for the observation type. 2.3.4 Wind Profiler RASS ProfilersRASS (prolrs) - The raw data are obtained from GSDs NIMBUS database andor AWIPS in netCDF format where they are stored in four different directories. The data originally come from GSDs Demonstration Branch (DB) from two main networks. The 30 NPN (National Profiler Network - NOAAnet) profiler network is located mostly in the central U. S. The second network supplies boundary layer profilers for both wind and temperature, with formats including NIMBUS, MADIS Multi-Agency Profilers (LDAD), and RSA (LDAD) format. The profiler data for wind goes into the pro intermediate file, and RASS temperature profiles go into the lrs intermediate file. Note that the cdls associated with each data source indicate the time frequency of the data that our ingest code can process. The path names for the profiler data are all set in nest7grid. parms. The NPN wind profiler data is available via another route from GSD with some restrictions. This data, in WFOAWIPS netCDF format, is distributed via GSDs MADIS project at madis. noaa. gov 2.3.5 PIREPS ACARS from aircraft PIREPS (pin) - We are ingesting GSD NIMBUS and WFOAWIPS (netCDF) pirep files to translate the cloud layers from voice pilot reports into intermediate PIN files. ACARS (pin) - We are ingesting GSD NIMBUS, WFOAWIPS (netCDF) and AFWA databases for ACARS data to translate the automated aircraft observations. The wind, temperature and humidity obs are appended to our intermediate PIN file. A NIMBUS equivalent netCDF database is available (with some restrictions) on the Web via MADIS at madis. noaa. gov Note the TAMDAR is presently being screened out from the NIMBUS database while this data source is being validated. 2.3.6 RAOB Dropsonde Radiometer RAOBs (snd): GSD NIMBUS, WFOAWIPS, CWB, or AFWA databases. These are available in real-time from GSD with some restrictions. RAOB data in WFOAWIPS netCDF format is distributed via GSDs MADIS project at madis. noaa. gov Dropsondes (snd): A Dropsonde ingest module has been developed for the CWB database. An ingest module has also been developed for AVAPS. We now allow the SND format to be used as input (so far just for the AIRDROP project). For the SND input option, the ingest program simply does a time windowing of the raw data. We may include modules for other (e. g. netCDF) databases in the future, such as NIMBUS or WFOAWIPS. Radiometers (snd): A radiometer ingest module has been developed for the MADIS database - madis. noaa. gov 2.3.7 Satellite Satellite Image Ingest (lvd): GOES data ingest. Data is acquired at GSDs ground station and stored in netCDF. We also obtain AWIPSNOAAPORTSBN data (stored in netCDF). Ingest of Air Force Weather Agency (AFWA) satellite data is also possible. Raw GVAR satellite data can be ingested and navigated using GIMLOC routines. These files are in NetCDF. Further details can be found in the file srcingestsatellitelvdREADME. The ITS group at ESRLGSD has put together a converter from McIDAS AREA files to the GVAR netCDF format (lvd input). These files are similar to the raw GVAR, except they have latlon arrays added to make the files self navigating. The AREA files can be obtained from sources such as the NESDIS ADDE server. The Java based converter package can be found online at this URL: Note that the NESDIS ADDE server can also supply worldwide geosynchronous satellite data. Some tweaking of satellite coordinate and image dimensions may be needed when setting up the McIDAS package, as can be seen in the sample illustration (link below). Programs like ncview can be helpful to check if the window is navigated properly in the GVAR netCDF files prior to running the LAPS satellite ingest. Other work has been done in Italy to ingest Meteosat Second Generation data into LAPS, for example at ISAC. Another option under development is to use flat files (ascii files generated by RAMSDIS or binary data) as input. The flat file ingest was still under development as of 3-11-98. Generally it is best to convert your data into either GVAR NetCDF or remap it to create the intermediate LVD files. Satellite Sounder Ingest (lsr): GOES satellite sounder data ingest. Program lsrdriver. exe processes data from both satellites. Product files are yyjjjhhmm. lsr and stored in subdirectories lapsprdlsrsatid. Nineteen channels. Output is Radiance. The namelist datastaticsatsounder. nl defines the appropriate parameters for this ingest process. Only the moisture analysis is using this product. Currently GSD public sounder files in netCDF format are processed. This data is useful only when GOES Vapor (GVAP) is unavailable. Satellite derived soundings (snd): We have interfaces to GOES binary and MADIS POES (Polar Orbiter) formats. AFWA database format was previously used at GSD though not currently. The output represents derived profiles of temperature and moisture. For other formats you may wish to supply your own routine to convert your raw data into the snd format. Cloud Drift Winds (cdw): We are ingesting the ASCII satellite cloud-drift wind files for use in the wind analysis. These come from NESDIS (via NIMBUS) as well as from CWB and AFWA. We can also utilize netCDF files from MADIS. Both NESDIS and MADIS files are included in our sample data set. GPS: LAPS uses GPS data from NIMBUS netCDF files. The precipitable water is used in the humidity analysis. STMAS is being designed to use the signal delay directly instead of the PW. The netCDF files are available online at ftp:gpsftp. fsl. noaa. gov where they are named according to GPSIPWCDFYYDDDHHMM0030o. nc. The leading GPSIPWCDF of the names would have to be stripped off to be used in LAPSSTMAS. There are plans to make files similar to the NIMBUS ones available in AWIPS-II, though again filenaming conventions may need to be addressed. MADIS (LDAD) mesonet files also carry the GPS PW and related data, including surface obs. However there may be some questions about the latency of this data feed for GPS. Based on tests conducted in 2011, with a LAPS cycle that begins at about 20min past the top of the hour, one can generally expect only 5-10 of the GPS data to be avaliable via MADIS when the code is configured to seek the data. 2.3.9 Other Data Sources Radar VAD Algorithm winds (pro) GSD NIMBUS netCDF database, from WSR-88D algorithm output. GSD obtains this from NCEP and does not presently redistribute it. SODAR data (pro) - This is treated in a similar manner to wind profilers and can be processed by LAPS ingest to appear in the PRO file. This is available as part of the RSA project at Kennedy and Vandenberg Space Centers and comes into netCDF format via AWIPSLDAD. Met Tower data (snd) - This is treated in a similar manner to RAOBs and can be processed by LAPS ingest to appear in the SND file. This is available as part of the RSA project at Kennedy and Vandenberg Space Centers and comes into netCDF format via AWIPSLDAD. Radiometric Profiler (snd): We have an interface to radiometric profilers (in netCDF via NIMBUS) that can be used for the temperature and humidity analyses. Lightning Data: Although the LAPS repository doesnt yet have any lightning data ingest it is being considered to do this in terms of a simulated 2-D reflectivity that is one of the components of the VRC intermediate file. 2.4 Running LAPS Analyses LAPS runs in real-time under cron there is a sample cron script in LAPSINSTALLROOTutilcronfile. Referring to this cron, you can see that once each hour (or other cycle time), the main. etcsched. pl runs. As an example at ESRL, we run the sched. pl hourly at :20 after the top of the hour. By inspecting the sched. pl file you can see the various executables that are run in a certain order. Various command line arguments are documented within sched. pl (such as - d 0.25 that is useful for a 15-min cycle when the latency is 20 minutes). You might want to modify the sched. pl file for your needs. In the sample cron script several ingest processes are run separately from the sched. pl. For example the satellite ingest (lvd) is run several times per hour and utilizes. etclapsdriver. pl. NOWRAD Radar ingest (vrc) is also run at more frequent intervals. You might also choose to run remappolarnetcdf. exe for radar ingest in this manner. On many unix systems jobs that run in cron do not have access to the environment defined by the user. They instead use a system default environment defined in etcprofile thus perl may not be in the PATH. The cron file uses the full path to perl to ensure that this will not be a problem. If the path to ncgen is not in etcprofile, then you may want to add this to your own. profile file. Each script in the cron requires the path to laps as a command line argument. A second optional argument specifies the path to the laps data directory structure this path defaults to fullpathtolapsdata if not provided. The utilcronfile is created by the configure step. Much of the needed editing has already been done in the creation of this file. You might see some remaining . constructs though that can be edited either manually or by running the cronfile. pl (next paragraph). The lapsdataroot can be replaced with your path to LAPSDATAROOT and the optional followup can be replaced with anything you wish to run after the sched. pl has completed (using a semicolon to separate the two commands). There is also a script called etccronfile. pl that creates a modified version of utilcronfile tailored to a given domain. This script can be run manually and the output location of the cronfile is located in LAPSDATAROOTcronfile. 2.4.1 Cron timing considerations The frequency of the cron entries for running sched. pl is defined to be the LAPS cycle time. This should correspond to the value of the lapscycletime parameter within the nest7grid. parms file. The best timing of the cron is often related to the arrival time of the raw surface observations. For example, if most of the surface data arrives within 20 minutes of the observation time, then running the cron 20 minutes after the systime would be optimum. The time window for acceptance of surface stations in the LSO file can be controlled by runtime parameters in obsdriver. nl. In most cases, the data cutoff time window for 3D observations is - lapscycletime2 or - lapscycletime. For example an hourly LAPS cycle accepts RAOB data from a -60 minute time window and ACARS from a -30 minute window. 2.4.2 Purging Output Files The script etcpurger. pl purges the lapsprd output files and is in turn run by the sched. pl. There are default settings in place for the number of files and age of files to be kept. These can be overridden in three ways. 1) The sched. pl command line options - r - m N, where N is the (default) maximum number of files to be kept in each product directory by the purger 2) Overrides can be read in from datastaticpurger. dat. This file can be modified by the user to optimize the purging in various domains. One can review the purger. pl script to see how the purger. dat information is used. 2.4.3 STMAS and other configurations Within the LAPS cron the call to sched. pl can have some optional command line arguments that adjust the runtime options. The default is to run both surface and 3-D analyses from the traditional version of LAPS. Here are examples of some other alternatives: 1) STMAS-2D surface analysis only prompt perl sched. pl - M stmasmg. x other regular options Note that when running STMAS-2D analyses, the lgbonly parameter in the background. nl namelist can be set to. true. for improved runtime efficiency. 2) traditional LAPS surface analysis only prompt perl sched. pl - M lapssfc. x other regular options prompt perl sched. pl - V STMAS3D other regular options 2.5 Test data case Tar files containing test data (called lapsdata) are available that contain a snapshot of several hours worth of laps data from the Colorado domain using namelist settings taken from the repository. The tar files include intermediate files from the ingest code plus outputs from the analysis code. Several consecutive analysis cycles are posted with one file per cycle. Included are the contents of the lapsprd, time, static, and log subdirectories under data or LAPSDATAROOT. The log files are useful for diagnosing any differences in output you may observe. The contents of the various directories are outlined elsewhere in this README file. The data was created using the latest software release. Our users can download this data at this URL: It is suggested here to test the localization procedure to ensure that all the static files needed to run LAPS are present. To do this, check that the paths to the geography data are correct in TEMPLATEnest7grid. parms andor LAPSDATAROOTstaticnest7grid. parms. When running LAPS as a whole for the archived data, the etcsched. pl script will accept a - A command line argument. This forces the script to run for the time you are inputting instead of the current time. An example call is shown as follows. prompt perl sched. pl - A dd-mmm-yyyy-hhmm LAPSINSTALLROOT LAPSDATAROOT where the inputted dd-mmm-yyyy-hhmm value is the date (for example 28-Aug-2007-1500). This date can be inferred from the contents of LAPSDATAROOTtimesystime. dat. Best results are obtained when using a time just prior to the latest raw data tarfile time. One can also initiate individual executables (bin directory) listed in the sched. pl to run on the test data. This often helps in getting a better match between your output and ours. Note that LAPSDATAROOT needs to be set as an environment variable when executables are run individually. The time of the run is specified in LAPSDATAROOTtimesystime. dat. This can be modified if needed if you want to try a slightly different time from the one supplied. To do this, interactively run the script LAPSINSTALLROOTetcsystime. pl and write the standard output to LAPSDATAROOTtimesystime. dat. Note that for any given process or set of processes, deviations from the GSD output may be caused by differences in the inputs as well as machine roundoff error. Most, but perhaps not all of the input data is supplied. One main area to check would be differences in available raw background data files. Having all of the data history from lapsprd may also be an issue this may be less of a problem if you run laps for the latest hour of data that is supplied. The history is then supplied from earlier lapsdatalapsprd output. Output differences can be tracked down by recompiling specific analyses with the - g option. This can be done by typing make debug in the appropriate src directories. Various debuggers can then be used such as dbx. Examination of the log files again is helpful. We have a new script (in 2004) called casererun. pl that can be used for archive data runs. We have yet to try it on the supplied test data case though it could prove to be useful. 2.5.1 Analysis Only Test You may want to check that any analysis outputs from this time are not present, leaving only the ingest outputs in place. This may improve the results of comparisons of your own output with GSD analysis output, though this step is not always necessary. You might consider adding the - T command line option when you run sched. pl so that we run the analysis executables only thus skipping the ingest processes. This can be done if the ingest outputs (i. e. analysis inputs) are already present in the various lapsprd subdirectories. One way to supply the analysis inputs is as follows for each input (taken from a list of ingest outputs, see section 3.2): prompt cp testdatalapsprdinputlist LAPSDATAROOTlapsprdinputlist prompt cd LAPSDATAROOTlapsprd prompt ln - s testdatalapsprdinputlist. 2.5.2 Ingest Analysis Test For this type of test, you will want to download the rawdata tar files into your rawdata directory to start the processing of LAPS. Recall that the rawdata directory is on a separate tree than LAPSDATAROOT. Raw data formats and filename conventions are consistent with the default namelist settings taken from the repository. This is generally in NIMBUS (self describing netCDF) format with associated file naming conventions. A typical filename on NIMBUS looks like this: 0606701000100o meaning yydddhhmmHHMM where ddd is the day of year, hhmm is the time of day and HHMM is the file recurrence interval. The o at the end means that observations are binned into files according to observation time (instead of r for receipt time) More about NIMBUS is detailed in publications on the web at this URL: fsl. noaa. govitspapersjbams94.html Note that with the RUC grib data there are two directories. The one with soft links (and without the. grib at the end of the filenames) is the one to use. Time information will be needed in the form of datatimesystime. dat this can be extracted from the lapsdata tar file. The rawdata directory is a convenient place to store test data. User supplied raw data for operational runs can be stored anywhere on your system, often outside of the LAPS trees. Note that the lapsdata tar files contain intermediate plus analysis output files only. The rawdata tar files supply much of the raw data that are inputted to the ingest processes. The times for the raw data match the lapsdata output approximately but not always exactly (one example being the raw background data files). As a hint with the background data check that the available raw files bracket the systime of interest. If needed one can change the useanalysis flag in background. nl to get lga. exe to work better. In many cases, a user could independently generate the intermediate data files (ingest output) and then compare them with ours. If other raw files are needed as they appear on GSDs NIMBUS MADIS systems, please let us know and we can try to add them to our test data case or send them separately. 2.6 IO of LAPS gridded files Once the laps library is compiled (as outlined above), laps grids can be read. There are three levels of software that can access the data. To link to the reading routines, you will want to link to: 2.7 CHANGING THE HORIZONTAL DOMAIN Laps will allow you to change the horizontal domain after compilation and before the running of the localization scripts. Below is a list of the relevant changes. The dimensions and location of the horizontal domain can be changed at run time. Prior to running windowdomainrt. pl, set the following parameters in datastaticnest7grid. parms or in the corresponding template directory (needed only if you are outside the default Colorado domain). This script in turn runs gridgenmodel. exe and other programs. 2.7.1 Number of Grid Points Adjust the horizontal dimensions in terms of the number of grid points (NXL, NYL) in. datastaticnest7grid. parms. NOTE: Various files in the. datacdl directory are automatically edited by. etclocalizedomain. pl using the values found in. datastaticnest7grid. parms. 2.7.2 Location of Analysis Domain (Map projections) When you run. etclocalizedomain. pl, the netCDF static file static. nest7grid will be automatically generated by process gridgenmodel. exe. This contains grids of latitude, longitude, elevation, and land (vs. water) fraction. The following output message, topo30s file U50N119W does not exist, does not necessarily mean there is a problem. It may signify that your domain runs outside the available 30 data, and should still be covered by the 10 worldwide data, if you are using the topo30s dataset. Other WARNINGs or ERRORs may be more significant. 2.7.2.1 MAP PROJECTION FUNCTIONALITYLIMITATIONS LAPS runs with the polar stereographic, lambert, and mercator projections. Please let us know if you encounter any problems. The polar stereographic projection has a pole that may be set to either earths north or south geographic poles. Setting the pole to an arbitrary latlon (local stereographic) is a possible future enhancement. A test local stereographic domain gave an error of 2km in the grid points the test code works in cases where the projection pole coincides with the center of the domain. Further improvement of this may include more fully converting library subroutines GETOPS and (possibly) PSTOGE to double precision. The projection rotation routine projrotlaps also has some approximations when local stereographic is used. These need to be checked for their validity and refined if needed. Cases of interest include a projection pole point at the domain center, as well as offset from the center. The local stereographic projection also ignores standardlatitude from the namelist so this is internally assumed to be 90. This means that the grid spacing is valid at the projection pole location, regardless of both where on the earth the pole is and the poles latitude. The map projection calculations are performed with a spherical earth assumption. 2.7.3 Domain Resolution The default value of the gridspacingm parameter is 10000m. This is one of the parameters used in constructing the static file (as mentioned above). To date, we have run LAPS with resolutions ranging from 1000m to 48000m. 2.7.4 Terrain SmoothingFiltering Edit the file datastaticnest7grid. parms. 2.8 CHANGING THE VERTICAL DOMAIN PRESSURE OF THE LEVELS (and vertical resolution): To do this, perform the following between untarring the tar file and localizing LAPS 1. Copy datastaticpressures. nl to your TEMPLATE directory, then edit it with to have the new set of levels. Update the list of pressures that go in sequence from higher to lower pressures (bottom to top) Note that the default vertical grid uses constant pressure coordinates and that the vertical pressure interval can vary between levels. For example one might want to use higher density in the boundary layer ( 100Pa interval) and make it coarser higher up ( Of course the top pressure should be greater than zero mb. The bottom level should extend below the terrain and below the observations. The pressure values must be in multiples of 100 pascals, corresponding to an integer number of millibars. NUMBER OF LEVELS: 1. The default value of nklaps is set to 21 levels in datastaticnest7grid. parms and will automatically be reset during the localization (based on the contents of pressures. nl). 2. Note that compatibility with model background data will depend of the vertical extent of that data source. Note: If you are feeding LAPS output into an AWIPS workstation, then additional workstation related changes may be needed. 2.8.1 Sigma Height Grid UNDER DEVELOPMENT - mainly for STMAS-3D Similar to 2.8 except that one changes the verticalgrid parameter in nest7grid. parms. Also the heights. nl namelist is used instead of pressures. n l. Note the heights in this namelist are scaled sigma values where the namelist (idealized) height sigma (heighttop - heightbottom) Presently the heighttop and heightbottom values are hard wired to 20000. and 0. meters, respectively. 2.8.2 Sigma Pressure Grid UNDER DEVELOPMENT - mainly for STMAS-3D Similar to 2.8 except that one changes the verticalgrid parameter in nest7grid. parms. Also the sigmas. nl namelist is used instead of pressures. nl. 2.9 CHANGING THE CYCLE TIME The default cycle time is 60 minutes. To change this, do as follows. 1. Edit runtime parameter file datastaticnest7grid. parms to change the value of lapscycletime. 2.10 LQ3 (HUMIDITY ANALYSIS) CHANGES Recent changes as of February 26, 2006 NAMELIST The namelist file. lapsstaticmoistureswitch. nl controls the data assimilation within the moisture analysis. This file is self-documented, refer to it for details. This file has not changed in this latest update however, one of its controlling aspects is GVAP or GOES vapor (total precipitable water, product data) and the application of this data has changed since a major implementation change March 2005. The NESDIS Community Radiative Transmittance Model (CRTM) and forward radiance model called OPTRAN is incorporated into the current release of LAPS. Details of OPTRAN are available from: Tom Kleespies NOAANESDIS Thomas. J.Kleespiesnoaa. gov Also OPTRAN can be used by any U. S. Government or U. S. Military entity without problem. ALL other users need to contact NESDIS (Tom Kleespies) and receive authorization to use this software. Generally a simple acknowledgement to give full credit to the program author is all that is required. GSD assumes no obligation or responsibility in integrating this software as part of LAPS. To disable the use of OPTRAN in LAPS, simply assign the GOES option in the moistureswitch. nl namelist file to zero. The version of OPTRAN in LAPS is configured to work with GOES-8 and -10 sounder or imager at this time. Note also that GOES imager channel 5 (water vapor split window) is currently not available on GOES 11, 12 and future satellites since it was replaced with a different band. Therefore, the GOES imager data should not be used in the moisture algorithm for any GOES satellite 11 and beyond. There are simply not enough moisture channels available to offer any useful information about moisture depth due to this change. Furthermore sounder radiances for GOES-10 are deemed about 98 reliable, they are regarded to be 100 reliable for GOES-8. NaN values have been observed being generated from the GOES-10 sounder coefficients that currently accompany this software. At this time there are only basic provisions to handle the NaN state conditions. They have not been observed to crash the moisture analysis and seem to be handled gracefully to date. Any observation otherwise needs to be communicated to: Dan Birkenheuer NOAAGSD Daniel. L.Birkenheuernoaa. gov To model the atmosphere with OPTRAN, an atmosphere is formulated that extends to 0.1 hPa. This is a composite of the normal LAPS analyzed vertical domain (nominally extending to 100 hPa), spliced together with a climatological atmosphere of 20 levels that extends to 0.1 hPa. The joining of the two vertical coordinate systems is computed automatically and is continuous. This will automatically take place even if the nominal LAPS levels are extended beyond 100 hPa. In this upper region, temperature, and mixing ratio are functions of latitude and Julian day. Ozone is based on the U. S. Standard Atmosphere. ADDENDUM: routine RAOBSTEP. F It should be noted that some users have had to modify the parameter that defines dimensions in routine raobstep. f due to the fact that this can overflow array limits on some machines. The current parameter sndtot is set to 1000. The primary reason for this is to accommodate satellite soundings of which there can be many in even a small area. This parameter ties in to the dimensions of the weight matrix (ii, jj, sndtot). If a large horizontal domain is defined, and you dont have a lot of RAOB data and are not using satellite processed soundings, you may have better success at compiling this routine by reducing the value of sndtot to a smaller value. GVAP data are GOES sounder total precipitable water data acquired from the sounding retrieval process. These data were added to LAPS under a grant from NOAA NESDIS. The analysis for GVAP data has recently changed from the prior application. Up until the March 2005 release, GVAP data were used as a direct total moisture data source in that the integrated state variable in the moisture routine (q) was compared to GVAP totals and part of the minimization procedure was to improve this match through variational techniques. It was learned during the IHOP 2002 experiment that the GVAP data were badly biased, especially at asynoptic times. (see laps. fsl. noaa. govcgibirk. pubs. cgi for all publications, and specifically laps. fsl. noaa. govbirkpapersBirkenheuer2005aj. pdf for the article about IHOP, or it can be located in the literature at: Birkenheuer, D. and S. Gutman, 2005: A comparison of the GOES moisture-derived product and GPS-IPW during IHOP. J. Atmos. Oceanic Tech. 22, 1840-1847.) As a result, the algorithm was modified to use GVAP gradients and to compute gradients in the solution field and match these gradients to those from GVAP. The advantage to using gradients in this procedure was that it eliminates bias and improves data structure. There is not a Tech Memo that has been published and is also available on line that describes this new technique. (refer to: laps. fsl. noaa. govbirkpaperstechmemosGSDTechMemo32.pdf or a copy can be gotten directly from GSD) 2.11 OTHER RUNTIME PARAMETERS It is worthwhile to check the nest7grid. parms and other namelist files in datastatic to make sure all the runtime parameters are correct. Some parameters worth noting are: 2.12 Detecting and Reporting Installation Errors To determine how well LAPS was installed, verify that all (31 at last check) executables were built OK (bin directory) with no errors in the output of make. Similarly, check the output of the localization script. If you have any problems during the configure, install and localization process, there are several things to check. For certain platforms, you can compare your build output with ours by clicking on Results of Latest LAPS Builds on the LAPS Software page. Also double check that youve followed all the installation steps in this section of the README. There is also a FAQ available at laps. noaa. govbirkLAPSFACTS. htm Finally, check the release notes at the laps. noaa. govsoftwarereleasenotes. html URL. If you dont find the answer in these documents, send mail to oplapb. gsdnoaa. gov Include in your mail: 2.12.1 Runtime Monitoring To see how well LAPS is running, check if output files are being placed in the various lapsprd subdirectories. A graphical product monitor that can help with this is available in etclapsmonitor. pl. This script may need some simple editing to suit your needs (e. g. to specify the LAPSDATAROOTs). The monitor script writes HTML output to stdout. This HTML output, if routed to a file or hooked up to a Web server, can be viewed with a browser. You can click on laps. noaa. govmonitorsLapsMonitor. cgi to see an example of the monitor output. Green means optimum product continuity, red means the product is failing to generate, yellow means it is generating OK now but has failed in the past. The numbers in the columns indicate the number of files in each directory, as well as the youngest and oldest file ages in hours. The data flow is generally from top to bottom on the product list, starting with analyses and ending with forecast model (fuafsf) output being listed at the very bottom. In general the root cause of missing products would be the first one that is missing along the data flow. To check what model background and observational data were used in the analyses as well as some QC and error (verification) statistics, you can view the log file summaries in the files LAPSDATAROOTlog. wgi. yydddhhmm. Generally each named wgi file corresponds to the name of an analysis process, except that sfc. wgi. is generated by one of several executables than can provide the LAPS surface analysis depending on the runtime configuration. For more details, check the various log files in the LAPSDATAROOTlog directory for occurrences of the string error and warning. The errors are generally more significant. If any core dumps occur they can usually be flagged by searching for the sh: string in sched. log.. If you are reporting runtime errors it can be useful to tar up your entire LAPSDATAROOT and make it available on your web or FTP server as a compressed tgz file. If the data set is very large you might consider mailing us a CD or DVD. Alternatively if you have the untarred LAPSDATAROOT files on your web server we can browse through the directories for the log and product files as needed to help diagnose the run. If the LAPSDATAROOT is large it can be pared down as there is a script called etctarlapstime. sh that works by just tarring up the current hours worth of files. If you need to narrow this down further just the inputs to the particular analysis would be needed as shown in section 3 of the README. Also, things like the cdl, time and static subdirectories should be included. 3.0 DESCRIPTION OF LAPS PROCESSES The following section contains information on which LAPS processes generate which LAPS output products. Static data (like lat and lon grids) are included in section 3.1. These are the processes contained within the LAPS tar file and built with the localization script. Inter data is an ascii file containing non-gridded data (intermediate data files). Examples of this are surface obs, profiler obs, etc. This list contains all outputs generated by LAPS processes. The products listed under each process are the outputs produced by that process. Inputs are listed here for some analyses. If the cron including sched. pl (see section 2.4) is run according to the flow therein, the necessary inputs will be available. 3.1 Localization Processes 3.1.1 Gridgenmodel (static. nest7grid generation) Package: gridgenmodel. exe - Writes static file, run by localization script. Contact: Steve Albers - Steve. Albersnoaa. gov Inputs: Geography databases (topography, land fraction, landuse, soiltype topbot) greenness fraction, mean annual soil temperature, and albedo. Files are typically in 10, 30, or 180 deg tiles. See section 2.2.5 for details on the geography data. staticnest7grid. parms Source directory: lapssrcgrid Sample Output: Should be available in the test data case. The grids start with gridpoint (1,1) in southwest corner of the domain and end with gridpoint (ni, nj) in the northeast corner. The bottom (southernmost) row of the domain is written first (I increases with consecutive grid points, then J increases). I increases as youre moving east on the grid, J increases as youre moving north. 3.1.2 Surface Lookup Tables (gensfclut. exe) Package: gensfclut. exe - Writes surface lookup tables, run by localization script. (contact: John McGinley Steve Albers) Source directory: lapssrcsfctable In gensfclut. exe, the friction parameter has been configured by automatically producing a scaling factor based on the range of elevations across the domain. This factor can be changed in the dragcoef section of buildsfcstatic. f, if so desired. 3.1.3 Satellite Lookup Tables (genlvdlut. exe) Package: genlvdlut. exe - Writes satellite lookup tables, run by localization script. (contact: John Smart) Source directory: lapssrcingestsatellitelvdtable Additional information on the lookup tables can be found in the file lapssrcingestsatelliteREADME. 3.2 Ingest Processes As mentioned above, a flow chart for the ingest processes may be found at laps. noaa. govdocslide1v3.gif. 3.2.1 LGA Model Background Package: lga. exe - ingest background model data (contact: Steve Albers - Steve. Albersnoaa. gov). LGA LAPS analysis grids from RUC or other analysisforecast grids. Inputs: Raw model data on the models native grid. The acceptable models and formats for the background model are listed in datastaticbackground. nl. We have recently added support for the background models to include GRIB-formatted files. See source directory: LAPSSRCROOTsrclibdegribREADMELIBS file for detailed information. For some models you might want to do a separate conversion of GRIB to netCDF prior to running LGA. One software option for this is available from the GSDITS group as described in section 3 of this web document at the following URL: Tropical cyclone bogusing information is also an input in the form of the tcbogus. nl namelists. These are generated independently of LAPS as raw data, yet are placed in the LAPSDATAROOTlapsprdtcbogus subdirectory. The filename convention should be yydddhhmmtcbogus. nl. To see the format check the sample file located in datastatictcbogus. nl. Outputs: (Feeds various analyses) Source directory: The source code for this is in srcbackground. Library directory: Associated library modules are in srclibbgdata. Parameter namelist file: staticbackground. nl Sample InputOutput: May be available in the test data case. This software currently supports nearly 10 different models. If additional models are required, then software mods may be needed, potentially a new source file added to srclibbgdataread. f. A key variable that relates to which model youre using is bgmodel. Note that time interpolation is used if the required LAPS analysis time(s) are between the valid forecast times for two of the set of input files. In this context output files are produced for the LAPS analysis time as well as - one LAPS analysis cycle time. Input data for LGA should thus be available over an appropriate time span. 3.2.2 Surface Data Ingest 3.2.2.1 obsdriver. x LSO process - obsdriver. x - Ingest surface data (author: Pete StamusSteve Albers) Source directory: LAPSSRCROOTsrcingestsao (contains a README file) Parameter file (specifies input data paths and formats): staticobsdriver. nl The LSO file is fairly self explanatory. The easiest way to see what goes where is to look at the routine readsurfacedata in the file srclibreadsurfaceobs. f, and the corresponding format statements in the file srcincludelsoformats. inc. The routines are pretty well commented, and should be enough to tell you what you need to know if you want to make a decoder that outputs an LSO-type formatted file directly. This direct route would allow you to bypass the step of producing raw netCDF surface observation data. Here are a few recommended settings for the observation type variables (reportType and autoStationType) if you are constructing your own LSO file: The expected accuracies are based on offical NWS numbers where possible. For LDAD observations, theyre just a best guess, since no one really knows how good the obs are. These expected accuracies will be used in the quality control routines sometime in the future. The latlons are in decimal degrees. Gross climatological QC error checks are applied to several variables including temperature, wind, and pressure. MADIS QC flags are checked as can be controlled via namelist. 3.2.2.2 How to Blacklist stations (author: Steve AlbersPete Stamus) As part of the obsdriver code, a Blacklisting function has been added. This allows users to tell LAPS to skip stations with known bad variables (one or several), or to skip a station completely. As of this writing, the user will have to edit a Blacklist. dat file. in the future we hope to include this function in the LAPS GUI. An example file, called Blacklist. example has been included in the same directory as this README file. It shows the format that must be followed for the Blacklist to work properly. An error in the format will either allow the bad station(s) through, or crash the program completely. Lets decode the Blacklist. example file: The first line is the number of obs to blacklist. in this case, 5. Each station goes on a new line. The number of variables to blacklist for that station is next, then the codes for the variable(s) follow. For the first station (KFCS), we are blacklisting the 3 pressure variables. To blacklist the entire station (KDTW) use 1 for the number of variables, and ALL as the variable. All the stations from a particular provider can be blacklisted by adding 100 to the number of variables (third example). The last two examples show 1 and 2 individual variables, respectively. These are the valid codes for variables to blacklist: You might keep in mind that some variables act as a group. For example both HUM and DEW variables feed into the LAPS dewpoint analysis so consideration should be given as to whether to blacklist one or both of these variables. ALT, STP and MSL are a similar group of pressure variables. An incorrect variable code generates a warning message, and the code should hopefully continue without acting on the station in question. Note that when a station is blacklisted, its name, latitude, longitude, elevation, and time, will still be stored in the LSO file. However, the selected variables (up to ALL of them) will be set to the badflag value and skipped in the analyses. To actually get this stuff working, edit the file called Blacklist. dat in the datastatic (or template) directory. The Blacklist. dat being used at GSD is supplied in this directory as a default, and this provides additional examples. Format the file exactly as the Blacklist. example file (using your station information, of course). Save the file, and the next time obsdriver runs, it will use the blacklist information. This will be noted in the obsdriver. log file. You may eliminate element specific or ALL data from a particular provider by replacing the leading 0 with a 1 in the second column. See the WXforYou example in the Blacklist. example file. To ensure the elimination of the data by provider, care must be taken to make certain the correct provider is listed in the Blacklist. dat file. Primarily, offending datasets are from stations received through LDAD. To find the provider for a given station you can look in the logsfc. wgi. files or in the input LDAD netCDF files. For AWIPS users a list of these stations are kept in ldaddata on your AWIPS system. Each. txt file in ldaddata will have a. desc file associated with it which describes the data being ingested etc. by that provider. Look in a particular. desc file of interest. Go to the 3rd word of the 1st line which is not commented out (e. g. aprswxnet. -9999.00 APRSWXNET). For this example, the APRSWXNET (3rd word) is the provider name and should be the entry used if utilizing the elimination by provider feature of the Blacklist. 3.2.3 Polar Radar Data (e. g. WSR 88D Level II, Level III) Author: Steve Albers (Steve. Albers AT noaa. gov) Every volume scan Initiation: Completion of volume scan Inputs: Wideband Radar Data (reflectivity and velocity in polar coordinates, in netCDF format) These have one tilt per file and at least 4 tilts per volume scan (all with the same volume timestamp in the filenames). This data can be obtained from a WSR 88-D Level-II data feed or the equivalent. A description of how we obtain these Polar netCDF files for Level-II is at laps. noaa. govalbersremapperraw. html. Note that narrowband reflectivity data (e. g. WSR 88D Level-III RPG) can also be used as long as it is converted to the required polar coordinate, netCDF format. This is in fact being done for the AWIPS implementation of LAPS for a low-level tilt from a single radar, via the etcLapsRadar. pl script running in the AWIPS environment. The comment section at the top of this script explains how this 4 bit processing of reflectivity data works. etcLapsRadar. pl runs two executables. The first executable tfrNarrowband2netCDF from AWIPS, writes out the polar netCDF files in the directory LAPSDATAROOTlapsprdrdr. raw where. is the radar number. The second executable remappolarnetcdf. exe is run as part of LAPS. We havent been using Level-III velocity data since it is of limited 4-bit resolution and were running only with the lowest tilt at present. For both Level-II and Level-III the polar netCDF files are named according to yydddhhmmelevxx where xx is the tilt number. Sample polar netCDF files including a CDL may be found at: laps. noaa. govsoftwareradarwideband Outputs (LAPS intermediate files - depending on input parameters): The outputs from this process, on the Cartesian LAPS grid, are used by the LAPS wind analysis, and also potentially by cloud and precip accumulation analyses. One output file is written per volume scan. When running the remapper, files such as v01, v02, vrc, etc. are produced depending on which radar is being used and on the input parameters. A further description of how the remapper software functions may be found on the World Wide Web at laps. noaa. govalbersremapperlaps. html. Also recall the flow chart showing the inputs and outputs for remappolarnetcdf. exe at laps. noaa. govalberslapsradarlapsradaringest. html. Source directory: The source code for this is in srcingestradarremap. Compile time parameters: srcincluderemapdims. inc Runtime parameter namelist file: staticremap. nl Sample InputOutput: May be available in the test data case. 3.2.4 WSI NOWRAD RADAR PREPROCESSING (VRC) Process: VRC (vrcdriver. x) Author Steve Albers (Steve. Albersnoaa. gov) Parameter namelist file: staticvrc. nl The WSI data are decoded externally to LAPS and written as netCDF files in NIMBUS format. The vrcdriver. x process reads these netCDF files. WSI sends out many types of radar data. We use the files that are labeled hd (15 min freq). They also send out an hf (5 min freq) file. We use hd because WSI hand edits these for ground clutter. The hf files are not edited. The hd and hf files are composites of low-level elevation scans from the 88Ds around the country. The vrcdriver. x also maps from conus to laps domain for the wfo data set. The map transformation software is found in libgridconv, libnav, and libradarwsiingest. The switch to use wsi versus wfo in variable craddattype in the nest7grid. parms namelist. Pathway to data is variable pathtowsi2dradar in vrc. nl. The output reflectivity is used by the cloud and precip accumulation analyses. 3.2.5 Radar Mosaic Author Steve Albers (Steve. Albers AT noaa. gov) This program runs once per LAPS cycle in the sched. pl. The default is to write just one mosaic file for the cycle valid at systime. A namelist option allows this program to produce multiple mosaic outputs within a given LAPS cycle. The multiple mosaics are all run at the same wall clock time, while the valid mosaic times are spaced throughout the previous LAPS cycle. The nearest radar with valid data is the one chosen to contribute at each grid-point. The output reflectivity mosaic is used by the cloud and precip accumulation analyses. Further QC is done within these analyses. Parameter namelist file: staticradarmosaic. nl 3.2.6 PROFILERVADSODAR (PRO) Ingest Process: PRO (ingestpro. exe) LAPS Wind Profile Ingest Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: lapssrcingestprofiler Parameter namelist files: staticnest7grid. parms, staticvad. nl Sample InputOutput: Should be available in the test data case. For the pro output, each profile starts with an ASCII header and the formatted entries are defined in sequence. After the header, the data entered for each level is as follows. 3.2.7 RASSs (LRS) Ingest Process: (ingestlrs. exe) LAPS local data RASS ingest Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: lapssrcingestrass Sample InputOutput: Should be available in the test data case. 3.2.8 PIREPSACARS Ingest Process: (ingestaircraft. exe) LAPS Pireps ACARS Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: The source code for this is in srcingestacars. Parameter namelist file (for data paths): staticnest7grid. parms Sample InputOutput: Should be available in the test data case 3.2.9 Sounding (RAOBDropsondeSatRadiometer) (SND) Ingest Process: (ingestsounding. exe) LAPS Soundings Author: Steve Albers (Steve. Albers AT noaa. gov) Source directory: lapssrcingestraob (contains a README file) Parameter namelist file (for data paths): staticsnd. nl Sample InputOutput: May be available in the test data case. If not, the README in the source directory contains a description of the snd file. Note: Sounding data is used if the observations lie in the time window of - lapscycletime centered on the analysis time. There are flags to toggle usage of the sounding (i. e. snd) data in wind. nl, temp. nl and moistureswitch. nl. 3.2.10 LVD (Satellite Image Cloud Top Pressure) LVD process - lvdsatingest. exe - takes raw sat. data and puts it on LAPS grid. (author: John Smart, contact Kirk Holub - Kirk. L.Holub AT noaa. gov) Input: GOES or other satellite data Parameter namelist file: staticsatellitelvd. nl Source directory: lapssrcingestsatellitelvd (contains a README file) 3.2.11 Cloud Drift Wind (CDW) Ingest Process: (ingestclouddrift. exe) LAPS Cloud Drift Winds Author: Steve Albers (Steve. Albers AT noaa. gov) Parameter namelist file: staticclouddrift. nl Source directory: lapssrcingestsatelliteclouddrift Note: Sounding data is used if the observations lie in the time window of - lapscycletime centered on the analysis time. 3.3 ANALYSIS PROCESSES A flow chart for the analysis processes may be found at this URL: laps. noaa. govdocLAPSflowv02.png Listed below is a summary of each analysis process in the order it is typically run by the sched. pl script. 3.3.1 WIND Process: wind. exe - WIND analysis and related fields Author: Steve Albers (Steve. Albers AT noaa. gov) Generate a wind analysis using surface observations, profiler, cloud drift wind, and aircraft reports. VAD and SODAR can also be read in. Background model grids are used as a first guess and to do quality control on new observations. Time tendencies from the background model are applied to the aircraftcloud-drift wind reports when they are taken before or after the nominal analysis time. The quality control rejects any observations deviating from the background by more than a threshold depending on observation type as in the following table. The wind analysis is done in three steps. The first step analyzes the non-radar data with the background wind field using a multiple iteration successive correction technique. For the second step, the first step results are used as the background. The data used includes non-radar data any grid-points with multiple - Doppler radial velocities are also mixed in. Radial velocities are taken from the Doppler radars after dealiasing and other quality control steps are done. If two or more radars illuminate a given grid-point, a full wind-vector is constructed from a combination of the radial velocities and the preliminary non-radar analysis. This is done via a successive insertion process, beginning with the background (non-radar analysis), then followed with the radial velocity from each radar in sequence. For the final step the background field comes from the result of the second step. All point data is now used, including grid-points illuminated by only a single radar. The tangential component for each radar observation is estimated by using the background from the previous step (i. e. non-radar data andor multi-radar data). The omega field is calculated by kinematically integrating the horizontal wind divergence. The lower boundary condition is specified by the surface wind and terrain gradient. Source directory: lapssrcwind (contains a README file) Parameter namelist files: staticwind. nl, staticnest7grid. parms Further description and reference is at: 3.3.2 SFC (LSX) Surface processing - lapssfc. x (LSX) (authors: John McGinley Pete Stamus Steve Albers) The surface package collects surface data from the LSO intermediate data file (METARs, local mesonets via LDAD, buoyship obs), IR brightness temperatures, and fields from selected background models. Places surface data on LAPS grid and performs a simple quality control of the obs (climo standard deviation checks). The quality control is described in the section below at (3.3.2.2). A flow chart can be seen at this URL: laps. noaa. govalberslapstalkssfcSfcanal. gif The background fields come from the locally-run LAPS model (FSF file), other large-scale models (RUC, ETA, AVN - via the LGB file), or a previous analysis (if all else fails). If the background model terrain is on a coarser grid than LAPS, this is accounted for so that the LGB fields have the fine-scale terrain related structure. For wind fields, the background comes from the 3-D wind interpolated to the surface or LWM file. Prior to analysis of each field, another quality control step is done that rejects observations that deviate from the background by more than a threshold. This threshold is proportional to the standard deviation of the observation increments. The proportionality constant is set depending on the field. The next step in the analyses is done with a successive correction technique similar to the 3-D wind and temperature analyses (see those sections and their web references). Observation increments are used for T, Td, U, V, MSL, P and straight observations are used for visibility. The temperature and dewpoint observations are also corrected for deviations of the station elevation from the LAPS terrain. Standard lapse rates are applied to this elevation difference. The analysis innovation is constrained to vary from the background by no more than the magnitude of the observation rejection threshold discussed above. This helps prevent overshooting (ballooning) of gradients into data sparse areas. For relative humidity, the RH observations are converted into dew point using the station temperature (if the dew point isnt directly reported). The analyzed variable for moisture is dew point. After the analysis is performed the gridded dew point field is converted back into relative humidity using the analyzed temperature. A land fraction term is factored into the weighting whenever the observation and grid point are on either sides of a 0.01 land fraction threshold. This helps prevent situations such as heating over the land having undue effects over the water areas. This weight is applied mainly to the T, Td, U, and V fields. For pressure analysis, three fields are computed including reduced pressure (P) at reference height redplvl, surface pressure (PS), and mean sea level pressure (MSL). Background pressure fields come from the LGB or FSF files. The MSL background is used as read in upon input. The (PS) background is converted from the background model terrain to the LAPS terrain within the LGBFSF file. The (P) background is generated by reducing the (PS) background to the reference analysis height redplvl using Poissons equation. This reference height should be approximately equal to the mean elevation of stations reporting surface pressure or station pressure. Continuing the pressure analysis the altimeter setting observations are converted and added to the set of station pressures using the standard atmosphere. Station pressure observations are in turn converted to reduced pressure using Poissons equation. The (P) analysis uses the (P) background plus the reduced pressure observation increments. The (P) analysis then uses variational techniques to constrain the surface winds and reduced pressures (P) to the full equations on motion. In contrast, mean sea level pressure (MSL) is a direct analysis of the MSLP observation increments together with the model background MSL field. The station pressure analysis (PS) is calculated using the model background gridded PS field, multiplied by the ratio of the (P) analysis to the (P) background. Visibility is arrived at by first analyzing the surface visibility observations. A second step is applied to decrease the visibility in areas that have high RH and are near the cloud base that is given by the cloud analysis (in the previous time cycle). Several derived variables are calculated before the LSX file is written. Also, a dependent data validation is done by interpolating several variables back to the observation locations and comparing the analysis to the obs. Output from this check is written to files located in LAPSDATAROOTlogqclapssfc. ver. hhmm, where hhmm is the analysis systime. Source directory: lapssrcsfc Parameter namelist file: staticsurfaceanalysis. nl 3.3.2.1 SURFACE ANALYSIS RUNTIME PARAMETERS You will need to select an elevation for the reduced pressure analysis. The reduced pressure is the only one really used in the variational portion of LAPS, and the idea is to select an elevation that is representative of the domain (or portion of the domain) you are interested in. For example, the Colorado LAPS domain includes 4000m high mountains over the western 13, and plains that slope below 1000m at the eastern boundary. We use 1500m as the Colorado LAPS reduced pressure. This is close to the elevations over the eastern 23s of the domain, and requires a smaller reduction over the mountains compared to MSL, for example. Change the namelist variable in datastaticnest7grid. parms when you localize LAPS. 3.3.2.2 SURFACE ANALYSIS QUALITY CONTROL LAPS has a layered QC approach that gives us several opportunities to flag erroneous observations. To start with, a variety of gross climo checks are applied to the observations in the obsdriver. x ingest program. The next steps in quality control are encountered in lapssfc. x. This first checks the observations against climatologically reasonable ranges. Next, the observations (most fields except wind) are checked to see which ones are outliers (at 5 sigma) relative to the average observation value in the domain. As a further check, the Temperatures, Dewpoints and MSL pressures are checked to see if they deviate from the background field by more than a threshold absolute amount. The output from these checks is in both lapssfc. log and sfcqc. log. The sfcqc. log file contains the rely (positiveretain, negativereject) values designated as follows: If you wish to skip over these steps, you can change the surfaceanalysis. nl namelist file. A new check looks at the temporal history of the obs where a 24 hour bias check flags temperature observations. Winds that arent changing in speed or direction over the 24 period are also flagged. There is an additional check for all analyzed fields (except visibility) within the spline routine that rejects stations deviating from the background by more than a threshold number of standard deviations of the observation increments. This threshold can be independently adjusted (i. e. tightened or loosened) for each field via the surfaceanalysis. nl namelist. If you see any bulls-eyes in the surface analysis that you dont believe, try contacting Steve Albers at GSD for more information on making these quality control namelist adjustments. 3.3.2.3 SURFACE ANALYSIS VERIFICATION Verification statistics for the surface analyses are written to the logqclapssfc. ver. hhmm files. These contain information of obs differences relative to the background and the analysis. The obs listed have had most of the QC checks already applied, though an ob may have been rejected in the analysis by the final spline standard deviation check yet still have a non-missing value listed in the QC files. Source directory: lapssrcmesowavestmasmg Author: Yuanfu Xie (Yuanfu. Xie AT noaa. gov) Parameter namelist files: staticstmas3d. nl, staticnest7grid. parms 3.3.3 TEMP Process: temp. exe - Temperature-Height analysis Generate a temperature analysis using model background, sfc temp analysis, and RASS data. Quality control is applied to the temperature soundings. If any level in a sounding differs from the model background by more than a threshold ( 10 deg), the entire sounding is rejected. Source directory: lapssrctemp Further description and reference is at: 3.3.4 CLOUD Process: cloud. exe - Cloud analysis package Author: Steve Albers (Steve. Albers AT noaa. gov) Several input analyses are combined with METARs of cloud layers. These input analyses are the 3D temperature analysis, a three-dimensional LAPS radar reflectivity analysis derived from full volumetric radar data, and a cloud top analysis derived from GOES IR band eight data. Vertical cloud soundings from METARs and pilot reports are analyzed horizontally to generate a preliminary three-dimensional analysis. This step provides information on the vertical location and approximate horizontal distribution of cloud layers. The satellite cloud-top temperature field is converted to a cloud-top height field using the three-dimensional temperature analysis. The cloud-top height field is then inserted into the preliminary cloud analysis to better define the cloud-top heights as well as to increase the horizontal spatial information content of the cloud analysis. A set of rules is employed to resolve conflicts between METAR and satellite data. Finally, the three-dimensional radar reflectivity field is inserted to provide additional detail in the analysis. Source directory: lapssrccloud Parameter namelist files: staticcloud. nl, staticnest7grid. parms Further description and reference is at: 3.3.5 WATER VAPOR (HUMIDITY PROCESSING) Last updated: 2242006 by Daniel Birkenheuer The moisture code is coordinated by the LQ3 modules all of which (with the exception of libraries) exist under. srchumid. The main driver, lq3driver. x contains only one subroutine call at this time. is the primary moisture processing module that sequences the various subroutines. There is a second routine that formerly was used for HSM satellite processing it is currently deactivated: Now, using the CRTM forward radiance model and more advanced techniques, the satellite inclusion takes place in the above 1a module. Treat the 1b module as orphan code. Furthermore, a FORTRAN 90 compiler is required to fully compile the forward model along with the rest of the moisture analysis system. An ASCII file intended for easy editing and control of the moisture modules activities. The first record controls usage of RAOB data (0off, 1on). The second record controls usage of satellite data (LVD files) and again (0off 8on, use GOES-8, 9on, use GOES-9). This module is exported with the RAOB feature OFF and the satellite feature ON and SET FOR GOES-8. The third switch enables (1) or disables (0) saturating air in cloudy areas. The fourth now enables using sounder data in lieu of imager data (GOES only). This should be set to (0) for the current time. A switch has been added to enable cloud data use to saturate air in cloudy areas. This is included as the last item in the moistureswitch. nl file that is maintained under the static area. To enable cloud data for saturating the air this is (1) to disable the feature, set the character to (0). You might wonder why we need such a switch. During October (1996), we experienced problems with the cloud analysis. This was inadvertently causing problems in the moisture analysis through the cloud saturation adjustment. The incorrect moisture was in turn causing the models runs to fail. Hence we added this switch so that we could easily reactivate the feature once the cloud analysis was repaired without having to worry about recompiling any code. The capability to ingest RAOB data into the moisture module has been available since 1996. There are two important items to know about: 1) The RAOB data are contained in lapsprdsnd. snd files. The moisture module will automatically use. snd data if present. If you do not wish to use sounding data there are 2 ways to exclude these data, the most obvious is to not provide. snd files. 2) In the event that you wish to exclude the use of sounding data and want them to be present in the data directory (possibly for some other application) you can avoid using them in the moisture code by modifying the file. datastaticmoistureswitch. nl The first record of this ASCII file is used for the RAOB data inclusion. The file itself is documented internally following the second record. If the first record is 1 (nominal case), the use of sounding data will be on, and. snd files will be processed if present. If this character is 0, the moisture code will not process sounding data. Inputs (status as of August 1996) (grid designates LAPS netCDF grid file unless otherwise stated): PRIMARY ALGORITHM SUMMARIES The RAOB data are added to the analysis via a second pass Barnes analysis. Normally, a Barnes analysis consists of two parts. The first fills the entire domain with values weighted by the distance to the neighboring points. In the second pass, a difference field (derived from the difference of the first pass and the observations) is added to the result from the first pass with adjusted weights to better tune to the scale of interest. In this application we skip the first pass using instead the background analysis in place of the result of the first pass Barnes result. The difference field is then generated and applied using a set of weights appropriate for the LAPS domain resolution and density of observations. An essential ingredient of the variational method is a satellite forward radiance model. The forward model produces a simulated radiance based on temperature, moisture, and ozone profiles along with the temperature of the surface or cloud top, and the pressure of that radiating surface (i. e. surface pressure or cloud top pressure whichever applies). Also needed are the zenith angle, used to determine the air mass path and optical depth between the radiator and the satellite. The forward model used for this work was obtained from NESDIS. The forward model coefficients used for this study were vintage late 1995. In order to apply the forward model appropriately, a determination of clear and cloudy fields-of-view (FOV) need to be determined. The LAPS cloud analysis is used to identify clear and cloudy LAPS grid points. The analysis as presented here is only working from FOVs classified as clear. Cloudy FOVs probably can be used, but this is an early attempt at this technique, so a conservative approach was chosen. Later research may focus on using a combination of both clear and cloudy FOVs in the algorithm. The first step in the algorithm is to assure all the data needed for proper execution are present. These include channel radiances derived from AWIPS imagery, the LAPS cloud analysis output, the LAPS surface temperature output, and LAPS 3-D temperatures. The forward model also requires an ozone profile along with moisture and temperature profiles above 100 hPa. These are gotten from climatology since LAPS extends only to 100 hPa. The entire ozone profile is provided by the forward model since LAPS does not analyze this parameter. Next, the forward model is run to verify clear LAPS gridpoints, where clear is defined as those points in which both the modeled and measured GOES image radiances in channel 4 (11 micron) agree to with 2K. This step uses the LAPS thermal and as yet unmodified moisture profiles. Disparity in the channel 4 brightness temperature comparison indicates that the LAPS thermal profile is too far off or perhaps it is really cloudy where the LAPS cloud analysis is indicating it is clear. (It doesnt have to be totally cloudy for a disparity to exist, it can be partially cloudy and this will still be detectable in this difference test.) This is a conservative test it really goes beyond simple cloud detection though that is a likely cause of differences, the forward model check is very sensitive and in many ways eliminates any thermal profiles that subsequent variational technique will find difficult to deal with. We are basically saying that we will not worry about moisture adjustment unless the thermal profiles are reasonable. The current LAPS system uses an older forward radiance model named OPTRAN and this is now being switched to CRTM. However, this test is not that satellite specific and the older OPTRAN model can be used by stating that newer satellite data is of the vintage that OPTRAN uses. For this reason, the user should not be that concerned with the exact satellite specified for this process. At this point, all gridpoints offering promise of moisture adjustment have been identified. If the domain is totally cloudy, the GOES adjustment is discontinued and returns unmodified moisture values which are passed to the final QC step. Assuming some gridpoints have been classified as clear, the next step is a variational adjustment at those locations. The functional evaluated at each gridpoint has and is best described in the literature (see articles under laps. fsl. noaa. govcgibirk. pubs. cgi. Basically a funcational is minimized that differences the perturbed solution against observation. The best perturbation is accepted as the answer. The first term in the functional maximizes agreement between the forward model and observed radiance at the expense of only modifying the water vapor profile. The second term adds stability and gives more weight to solutions in which the coefficients departure from unity (no change to the initial profile) is minimized. The stability term was discovered to be necessary since without it some very good radiance matches were solved but with unreasonable coefficients. Note that differences in all three channels are minimized in this technique, not only the moisture channel. Thus, any improvement in the dirty window, channel 5, will also contribute to the solution. A variational technique is used to minimize this function and typically requires three to 10 iterations to converge. A limit of 50 iterations was set as the maximum number to attempt. If limit was reached, that particular gridpoint was excluded and treated as cloudy. Once the coefficients are determined, Laplaces equation is solved for interior points for which coefficients have not been determined. Then the entire domain is averaged using a spatial invariant filter simply averaging the values in a 3x3 gridpoint window, assigning that average to the windows central grid location. When the coefficients have been determined, they are applied to the specific humidity field at each pressure level for which they are designated. The modified specific humidity field is then advanced to the final analysis step. As a final note it should be mentioned that owing to the unknown bias in radiance data. If it is available, it is far better to use water vapor gradient fields derived from satellite, than to assimilate satellite radiances directly. If the GVAP option is turned on, it is recommended that the direct assimilation is disabled in moistureswitch. nl. This is one reason why direct radiance assimilation has been slow in development with CRTM. Its value still can be reasonably questioned given the unknown bias. It is far more straight forward to rid the system of bias by using the first derivative structure of the radiance or PW field that to try to acceptdeal with the bias. GPS ASSIMILATION ALGORITHM: One of many terms in the humidity variational minimization step, the GPS total water is used to constrain the integrated water computed every iteration. Like the other terms in the functional used in the variational minimization, this term will reach a relative minimum when the state variables and specifically Q, best match this and other observations in a simultaneous manner (simultaneous here is respect to heterogeneous observational fit and not the more traditional state variable multi-variate solution sense). The GPS algorithm traditionally read internal GSD netCDF files for input. It now has the capability (122010) to read MADIS surface data files for GPS data. The MADIS data are typically built every 5 minutes, so to read GPS data from these files, one should look back to the prior hours MADIS file for the most recent GPS data. This is due to the fact that typically the GPS data are not ready for use until about an hour after acquisition time. So for a typical 20-min after the hour LAPS run, the current hours MADIS file will not contain any GPS data. The software is currently tuned to open the prior hours MADIS file and seek the latest GPS data that can be found in that file. This step is required since the MADIS file will be adding GPS data to it as it arrives and by the end of a given hour, MADIS files will contain 2 different GPS ingests. Therefore the user, should be aware that if a LAPS start time other than 20-min past the hour is chosen, the software may have to be changed to acquire the most recent data. Right now things should be pretty stable in this regard. If one starts LAPS at the top of the hour, say 16 UT, this module will read the 15UT MADIS file for GPS data. It will likely find the latest data in that file to have been written about 15:20 UT. This is what the traditional read of internal GPS files would have returned. Furthermore, if the LAPS system starts at 20-min after the hour, the same 15UT MADIS file will be opened and the GPS data read will be from about 15:45UT. Again, the routine will find the same that the traditional GPS file read would acquire. On the other hand, if one were to run at 15:50UT, there is a chance to miss the latest GPS data. The code as now written will open the 14UT MADIS file for data, when in fact the 15UT MADIS file may at this time contain data from 15:20UT. On the other hand, if this mistake is made, the data obtained will likely be nearly within the nearest hour of analysis time (14:50UT) and depending on the cycle time, may or may not be a critical issue. The user will have to determine whether this can be tolerated. Cautions for STMAS: When reading GPS data in a 4DVAR context, GPS data reading will have to spend more time concerned with the actual data time associated with the GPS data. In this regard, multiple MADIS files will likely need to be opened, their contents matched with their respective observation times, and then the data will need to be temporarily stored, sorted, and processed according to the needs of 4DVAR. 3.3.6 DERIV Process: deriv. exe - Derived products Author: Steve Albers (Steve. Albers AT noaa. gov) These derived products are cloud, wind, stability, and fireweather related. Source directory: lapssrcderiv Further description and references are at: 3.3.7 ACCUM Process: accum. exe - SnowfallLiquid Equivalent Precipitation Author: Steve Albers (Steve. Albers AT noaa. gov) LAPS incrementalstorm total snowfallliquid equivalent accumulation. Source directory: lapssrcaccum Parameter namelist file: staticnest7grid. parms The precipitation analysis uses radar estimated precip rates as the primary dataset. The radar reflectiivty can be obtained from any combination of NOWRAD 2-D (Section 3.2.4) or low-level reflectivity from mosaiced 2-D or 3-D radar reflectivity data. The source can be narrowband or wideband radar (section 3.2.3). The mosaics can be performed with either 2-D or 3-D inputs (section 3.2.5). We presently use a Marshall Palmer Z-R relationship to obtain liquid equivalent precipitation. Snow is also estimated using a snowrain ratio derived as a function of column maximum temperature. More on the basic accumulation processing is in Albers et. Al. 1996. In the present LAPS version, areas without radar coverage switch over to a gauge only analysis of 1-hr precipitation - using a background or model first guess field (if available) or zero field as a first guess. Areas having both radar and rain gauges present can be bias adjusted. An algorithm is presently be tested that determines this bias as a function of reflectivity. Reference: Albers S. J. Mcginley, D. Birkenheuer, and J. Smart 1996: The Local Analysis and Prediction System (LAPS): Analyses of clouds, precipitation, and temperature. Weather and Forecasting, 11, 273-287. 3.3.8 SOIL MOISTURE Process: lsm5.exe - Soil Moisture Author: John Smart (John. R.Smart AT noaa. gov) LAPS soil moisture and snow cover This program is in the early stages of development and provides a three layer analysis of soil conditions. The three layers are as follows: A snow cover analysis is included. The fractional snow cover is a composite over time of information from the cloud analysis (visible and IR satellite), and snow accumulation (derived mainly from radar). More documentation can be found within the source code (e. g. soilmoisture5.f, calcevap. f). Note that a soil temperature analysis is not included at this time. The closest thing we have to this is a single layer ground temperature analysis in the LSX surface output file. Source directory: lapssrcsoil 3.3.9 BALANCE Process: qbalpe. exe - Quasi-geostrophic balance of height, wind and clouds. authors: John McGinleyJohn SmartJohn SnookEd Tollerud contact: Edward. Tollerud AT noaa. gov LAPS quasi-geostrophic balance of height and wind with temp adjustment. Cloud fields are now balanced with the other fields. Source directory: lapssrcbalance Parameter namelist file: staticbalance. nl The balance package starts by inputting the results from a simple, offline cloud model which retrieves liquid and ice partitioning and an estimate of vertical motion from the observed clouds (lwclco). The variational scheme is designed to accept cloud vertical motion estimates and ice and water content as observations. The cloud observations are fully coupled to the three dimensional mass and momentum field using dynamical constraints which minimize the local tendency in the velocities and ensure continuity is satisfied everywhere. The scheme performs the analysis on the difference from an input model background with the benefit that existing background model balances need not be recreated each model cycle and that background model error daily compiled is input explicitly on a gridpoint by gridpoint basis. Reference: McGinley, J. A. and J. R. Smart, 2001: On providing a cloud-balanced initial condition for diabatic initialization. Preprints, 18th Conf. on Weather Analysis and Forecasting, Ft. Lauderdale, FL, Amer. Meteor. Soc. 3.3.10 STMAS3D Process: STMAS3D. exe - Space-Time Mesoscale Analysis System in 3D This analysis can be run with the other appropriate executables by using the - V STMAS3D option in sched. pl 3.4 Model Initialization Postprocessing LAPS analyses are used to initialize various mesoscale models (e. g. WRF, MM5, HIRLAM, BOLAM) to accomplish the prediction component. The forecast models themselves are obtained separately from the LAPS analysis tar file. There is some documentation for the model interfacing (for MM5) at this URL: For the WRF model we have a flow chart that illustrates an example of the initialization process: laps. noaa. govdocHMT-m1.png 3.4.1 LAPSPREP Process: lapsprep. exe - Post-processes LAPS analysis files into formats that can be used to initialize a local forecast model (e. g. MM5, RAMS, WRF) This process reformats LAPS data into files suitable for initializing a mesoscale forecast model. The output format is controlled by the outputformat entry in lapsprep. nl and can be set to one of the following: outputformat wps This causes the program to output a file in the WPS format (as needed for WRF version 3). Note that WPS has a constraint that the vertical levels of the initial condition (LAPS) be matched with those from the lateral boundary condition. This matching can be done either when running LAPS or in the WPS processing steps by three methods. 1) In an example with the GFS as a lateral boundary condition one can reduce the levels in the LAPS staticpressures. nl namelist as in this example: laps. noaa. govwpspressures. nl. gfs 2) In an example with the NAM as a lateral boundary condition and if LAPS has more analysis levels than the NAM one can use the WPS utility modlevs. exe. It uses the namelist. wps to rip out the NAM levels not in the namelist. The NAM data has levels from 1000 to 100 at a 25 mb interval plus a surface level. 3) The third method is the most desirable option that we recommend. We first run metgrid. exe for the boundary conditions (e. g. NAM), starting at the initial time and proceeding through the forecast times. We then run real. exe for the boundary conditions over the entire period. This will produce wrfbdyd01 and wrfinputd01 files. We next run metgrid. exe for LAPS, followed by running real. exe for LAPS only at the initial time. In this way the wrfinputd01 (initial time file) will be overwritten by the LAPS initial condition. outputformat cdf Writes a NetCDF file of the output outputformat wrf This causes the program to output a file in the WRF Standard Initialization gribprep format. These files can be read by the WRF SI hinterp process. outputformat mm5 This causes the program to output a file in the MM5v3 pregrid (v4) format that can be read in by MM5 the regridder pre-processor. See the NCAR MM5 REGRID documentation for the format specification of this output file. outputformat rams This causes the program to output a file in the RAMS 4.x RALPH2 format. These files can be read in by the RAMS ISAN pressure stage process. Note that RALPH2 files are in ASCII, so these files are actually human-readable. See the RAMS RALPH2 format specification for documentation. There are three other namelist entries in the lapsprep. nl file: hotstart: Set to. true. if you wish to include the cloud species from the cloud analysis in the output files. This currently only applies when outputformat is equal to mm5 or wrf. balance: Set to. true. if you wish to use the wind and temperature, height, and surface analysis files from the balance package. This will only work if LAPS is running the balance package. adjustrh: Set to. true. if you wish to use the adjusted RH analysis from the balance directory. This program essentially replaces part of the dprep. exe functionality, in that it produces initial conditions files for your local forecast model. If running a forecast model in real time, then this program should be executed immediately following the LAPS analysis during the hours in which the model will be initialized. It can simply be run as the last entry in sched. pl, which means you will always have an initial condition file avaialble immediately following your LAPS analysis. To actually initialize a forecast model, you will still need to run the appropriate program to build the lateral boundary condition files, as LAPSPREP does not provide this function. Parameter namelist file: staticlapsprep. nl Source directory: lapssrclapsprep 3.4.2 LAPS2GRIB Process: laps2grib. exe - Converts LAPS analysis output into a single GRIB2 file located in the lapsprdgr2 subdirectory. The parameters to convert are entered into a configuration file the choice of parameters and the scaling of the parameters is controllable. (author: Brent Shaw) Parameter namelist file: staticlaps2grib. nl lrunlaps2grib. false. (default) or. true. (to create grib2 lapsprdgr2 files) Data file: staticlaps2grib. vtab Source directory: lapssrclaps2grib E. g. parameters in data file: staticlaps2grib. vtab 3d 0,lt1,t3 , 1000.,110000. 1. 0,0, 0, 0 3d 0,lt1,ht , 1000.,110000. 1. 0,0, 3, 5 2d l1s, r01,1000.,4, 1, 0, 0,255,255,255,0, 1, 8 There are two numbers in the laps2grib. vtab file that immediately follow the file name extension and variable name: the conversion factor and the scale factor. The conversion factor will be multiplied by the LAPS variable coming out of the file in order to make the units conform to WMO specs (e. g. like cloud cover, which WMO defines as a percent from 0-100 whereas LAPS uses a fraction of 0-1. so we set the conversion factor to 100). In the case of precipitation, the units need to be in mm for GRIB, so if LAPS has precip specified in meters, then your conversion factor needs to be 1000 so you can get the data into mm. The scale factor specifies how many digits of precision to preserve after the decimal. It can be negative (for example, -1 would have precision to the nearest 10, 0 would give you to the nearest, and 1 gives you 110th, and so forth). So, if you have something that is typically very small (say, mixing ratio which in kgkg ranges from 0.0001 to about 0.01, you might use a scale factor of 4 to preserve 4 digits after the decimal. On the other hand, with cloud cover you may only need the nearest integer value from 1-100, so you could use 0. See lapssrclaps2griblaps2grib. doc for more detailed information. 3.4.3 WFOPREP Process: wfoprep. exe - Processes AWIPSWFO large-scale model forecast files into formats that can be used as lateral boundary conditions to initialize a local forecast model (e. g. MM5, RAMS SMF, WRF). The input files come from the SBN and are in netCDF format. (author: Brent Shaw) This an optional program that can be used in the AWIPSWFO environment. In other environments youll want to use a different program to generate lateral boundary conditions. Parameter namelist file: staticwfoprep. nl Source directory: lapssrcwfoprep 3.4.4 LFMPOST Process: lfmpost. exe - Post-processes WRFMM5 model forecast files into formats that can be used to feed back into LAPS analysis or plotting software. authors: Linda Wharton, Brent Shaw, John Snook, Steve Albers, Isidora Jankov contacts: Linda Wharton Steve Albers Parameter namelist file: staticlfmpost. nl Source directory: lapssrcnewlfmp (new default version) lapssrclfmpost (old version) The default (newer) version of the lfmpost program consists of a Fortran executable: LAPSINSTALLROOTbinlfmpost. exe This has been tested so far with WRF version 3. There is also an old version of lfmpost. To build this version run make and make install in the srclfmpost directory. Then in LAPSDATAROOTstatic (or the template) copy lfmpostold. nl to lfmpost. nl. LFMPOST is used to post-process raw model output files from the following models: 1. MM5 (Version 3 binary output format) 2. WRF (NCAR EM core, Version 1.3 netCDF output format) old lfmpost. exe 3. WRF (NCAR EM core, Version 2 netCDF output format) old lfmpost. exe 3. WRF (Version 3) new lfmpost. exe It performs the following functions: 1. Read in model output for each time 2. Destagger variables to LAPS grid points 3. Vertically interpolation to isobaric levels 4. Output various formats, including LAPS fuafsf netcdf format, Vis5D format, GRIB-1, and tabular text point forecast files. It is controlled by the namelist file lfmpost. nl. If processing point forecasts, you also need to set up lfmpostpoints. txt. Samples of these two files can be found in your LAPSSRCROOTdatastatic directory. To use lfmpost, you will need to copy these two files into MM5DATAROOTstatic or MOADDATAROOTstatic (for MM5 or WRF, respectively) and edit them to your liking. If you are going to output LAPS fuafsf files with lfmpost, you will need a valid LAPSDATAROOT for the same model domain, and your pressure levels selected in lfmpost. nl must be the same levels selected in LAPSDATAROOTstaticpressures. nl. Note that for this option, lfmpost expects the horizontal domain (dimensions, projection, etc.) to identically match for LAPS and the model being used. To execute lfmpost, you should set the following environment variables as necessary: MM5DATAROOT (if running MM5) MOADDATAROOT (if running WRF) LAPSDATAROOT (if fuafsf output is desired) LFMPOST expects to find the raw output files in: MM5DATAROOTmm5prdraw (MM5) MOADDATAROOTwrfprd (WRF v1 and v2) Output from lfmpost goes into: MM5DATAROOTmm5prdd (for MM5) MOADDATAROOTwrfprdd (for WRF) Within the output directories, the following subdirectories need to exist to contain the specific output formats: fsf - For LAPS fsf files (2d and surface fields) fua - For LAPS fua files (3d isobaric output) grib - GRIB data old lfmpost. exe points - Tabular text point forecasts v5d - Vis5D files After setting the appropriate environment variables and ensuring your namelists are configured properly, the syntax (old lfmpost. exe) is: lfmpost. exe NAME DOMNUM where NAME is one of mm5, wrf, or wrf2 for MM5, WRFv1.3, or WRFv2, respectively. DOMNUM is the nest to process. Additional arguments are needed for the new (default) version of lfmpost. exe. lfmpost. exe NAME WRFOUT NEST RCTIME FCSTTIME LAPSDATAROOT NAME - one of mm5, wrf, or wrf2 for MM5, WRFv1.3, or WRFv2, respectively. WRFOUT - full filename of WRFout file NEST - nest number (1 is outer) RCTIME - CTIME in seconds of model initialization FCSTTIME - number of seconds into the forecast LAPSDATAROOT - LAPSDATAROOT where static files are set up (or the equivalent in the WRF directory) LFMPOST is designed to operate on incremental raw model output data, so when you run WRF, be sure to output each time period to a separate file. When running lfmpost in real-time for WRF output there is a Perl script that can be used: LAPSINSTALLROOTetclfmpost. pl (use wrfpost. pl for older lfmpost. exe) There is also a driver script located in etcmodelslfmposttest. csh, often used for non-realtime case runs, that can be executed as in this example: lfmposttest. csh LAPSINSTALLROOT LAPSDATAROOT RUNTIME mvoutput RUNTIME is model initialization time with format yyyymmddhh 3.4.5 FORECAST GRAPHICS A script can be run in cron (after the FUAFSF files are created) to make GIF images of various forecast fields. This is located in etcfollowupfcst. pl. Output images will appear in lapsprdwwwfcst2d. 3.4.6 VERIFICATION LAPS has a built-in verification package. This can be run after a model is run and the verifying observations and analyses are available. The driver script is in etcverifveriffcstdriver. csh. For real time runs it can be run via cron once for each model cycle. The script has several command line arguments that are described in comments at the top. The script will produce stats files and PNGGIF image output in the lapsprdverif directory tree. To help in setting this up or troubleshooting the results please note the input data that are being used: 1) FUAFSF forecast files should be located in LAPSDATAROOTlapsprdfmodel. f 2) Observation and analysis files should be located in various other lapsprd subdirectories. Some examples are as follows: 3) Several parameters are relevant in staticnest7grid. parms including: modelcycletime, modelfcstintvl, modelfcstlen, fddamodelsrc 4) Log files are in LAPSDATAROOTlogfcstverif 5) Animated montages are an option that will work if followupfcst. pl is run prior to the verification (see previous sub-section 3.4.5). 4.0 Porting code mods from LAPS users back to GSD We would like to encourage suggestions from LAPS users on how to improve LAPS, both scientifically and in the software itself. The changes should be made by downloading the most recent source code tree. Edit your changes in the source files, and then retar part or all of the source tree to send back to us. Please state the LAPS version number you had used. Any documentation pertaining to the reasoning behind the changes would be appreciated. In some cases, a less formal process may be easier to go by. Here, the user can provide documentation of suggested mods either in descriptive form, or in terms of before and after code. The code author can then implement the changes in the GSD version. This can be useful in the event the mods are simple, or if the user has been working with a relatively old version of the software andor there have been significant recent GSD mods to the software. This can also be useful if the user has an idea of a desired functionality within LAPS, but has not actually looked at the software details associated with implementing the functionality. 5.0 LAPS Output Variables and netCDF File Organization LAPS Variables and netCDF File Organization LAPS output is written in netCDF format as summarized below. Each file extension contains a set of variables that goes into a separate directory under LAPSDATAROOTlapsprd. This directory includes so-called pre-balanced files, while the final balanced output is in the lapsprdbalance subdirectory. For example the LT1 temperature grid is written with the pre-balanced version in lapsprdlt1 and the balanced version in lapsprdbalancelt1. Map projection attributes are specified in the NetCDF files. Here are some of their definitions: Lat1: latitude of lower left corner grid point Lon1: longitude of lower left corner grid point Lov: longitude on map projection where grid is oriented along true north-south Note that netCDF information on the units of the fields, etc. is contained in the LAPSDATAROOTcdl. cdl files. At the bottom of the list is a section on the intermediate files that are computed while the ingest is running. File LAPS CDF Num Ext Var Var Lvl Field Process surface:LSX U su 1 Surface (10m) wind u (grid north) V sv 1 Surface (10m) wind v (grid east) P fp 1 Reduced Pressure (constant height sfc) PP pp 1 Perturbation Pressure (if available) T st 1 Temp (2m) TD std 1 Dewpt Temp TGD tgd 1 Ground Temp (land surfaceSST) VV vv 1 Vertical Velocity RH srh 1 Relative Humidity MSL mp 1 MSL Pressure TAD ta 1 Temp Advection TH pot 1 Potential Temp THE ept 1 Equivalent Potential Temp PS sp 1 Station Pressure (terrain following) VOR vor 1 Vorticity MR mr 1 Mixing Ratio MRC mc 1 Moisture Flux Convergence DIV d 1 Divergence THA pta 1 Potential Temp Advection MRA ma 1 Moisture Advection SPD spd 1 Surface Wind Speed CSS cssi 1 CSSI VIS vis 1 Surface Visibility FWX fwx 1 Fire Danger (LAPS Kelsch) HI hi 1 Heat Index Process temp: LT1 T3 t 21 Temperature HT z 21 Height (geopotential meters) PBL PTP ptp 1 Boundary Layer Top (pressure) PDM pdm 1 Boundary Layer Depth (in meters) Process accum: L1S S01 s1hr 1 Snow Ac cum Cycle STO stot 1 Snow Accum Storm Tot R01 pc 1 Liq Accum Cycle RTO pt 1 Liq Accum Storm Tot Process humid: LQ3 SH sh 21 Specific Humidity LH3 RH3 rh 21 Relative Humidity RHL rhl 21 Relative Humidity with resp to liquid LH4 TPW tpw 1 Integrated Total Precipitable Water Vapor Process wind: LW3 U3 u 21 Wind u (wrt GRID NORTH) V3 v 21 Wind v (wrt GRID EAST) OM om 21 Wind omega LWM SU u 1 Surface wind u (wrt GRID NORTH) SV v 1 Surface wind v (wrt GRID EAST) Process cloud: LC3 LC3 camt 42 Fractional Cloud Cover (levels 1-42) LCB LCB cbas 1 Cloud base LCT ctop 1 Cloud Top CCE cce 1 Cloud Ceiling LCV LCV ccov 1 Cloud Cover CSC csc 1 Cloud Analysis Implied Snow Cover ALB 1 LAPS derived albedo S3A 1 3.9u satellite data S8A 1 11u satellite data RQC 1 Radar QC information (2D vs 3D) SWI 1 Downward Shortwave Radiation LPS REF ref 21 LAPS Radar Reflectivity Process deriv: LCP LCP ccpc 21 Fractional Cloud Cover Pressure Coord LWC LWC lwc 21 Cloud Liquid Water ICE ice 21 Cloud Ice PCN pcn 21 Hydro meteor Concentration RAI rai 21 Rain Concentration SNO sno 21 Snow Concentration PIC pic 21 Precipitating Ice Concentration LIL LIL lil 1 Integrated Liquid Water lic 1 Cloud Ice cod 1 Cloud Optical Depth cla 1 Cloud Albedo vis 1 Visibility LCT PTY spt 1 Sfc Precip Type PTT ptt 1 LAPS Sfc Precip Type SCT sct 1 Sfc Cloud Type LMD LMD mcd 21 Mean Cloud Drop Diameter LCO COM cw 21 Cloud omega LRP LRP icg 21 Icing Index CTY CTY ctyp 21 Cloud Type PTY PTY ptyp 21 Precip Type LMT LMT etop 1 Max Echo Tops LLR llr 1 Low Level Reflectivity LST LI li 1 Lifted Index PBE pbe 1 Positive Bouyant Energy NBE nbe 1 Negative Bouyant Energy SI si 1 Showalter Index TT tt 1 Total Totals Index K k 1 K Index LCL lcl 1 Lifted Condensation Level WB0 wb0 1 Wet-Bulb Zero LWM SU u 1 Surface wind u (grid north) SV v 1 Surface wind v (grid east) LHE LHE hel 1 Helicity MU mu 1 Mean wind u (grid north) MV mv 1 Mean wind v (grid east) LIW LIW liw 1 log(LIomega) UMF umf 1 Upslope Component of Moisture Flux LMR R mxrf 1 Column Max (Composite) Radar Reflectivity LFR HAH hah 1 High Level Haines Index HAM ham 1 Mid Level Haines Index FWI fwi 1 Fosberg Fireweather Index VNT vnt 1 Ventilation Index UPB upb 1 PBL Mean Wind U-component (grid north) VPB vpb 1 PBL Mean Wind V-component (grid east) CWI cwi 1 Critical Fire Weather Index Process soil: LM1 LSM lsm 3 Soil Moisture LM2 CIV civ 1 Cumulative Infiltration Volume DWF dwf 1 Depth to wetting front WX wx 1 WetDry grid point EVP evp 1 Evaporation Data SC sc 1 Snow cover SM sm 1 Snow melt MWF mwf 1 Soil Moisture content Wetting Front LAPS Fcst Model: FUA U3 ru 21 Fcst Model Wind u (grid north) V3 rv 21 Fcst Model Wind v (grid east) HT rz 21 Fcst Model Height (geopotential meters) T3 rt 21 Fcst Model Temperature SH rsh 21 Fcst Model Specific Humidity FSF USF usf 1 Fcst Model Surface wind u (grid north) VSF vsf 1 Fcst Model Surface wind v (grid east) TSF tsf 1 Fcst Model Surface Temperature DSF dsf 1 Fcst Model Dewpoint RH rh 1 Fcst Model Relative humidity LCB lcb 1 Fcst Model Cloud base LCT lct 1 Fcst Model Cloud top P p 1 Fcst Model 1500m pressure SLP slp 1 Fcst Model MSL pressure PSF psf 1 Fcst Model Surface pressure LIL lil 1 Fcst Model Integrated cloud liquid water TPW tpw 1 Fcst Model Total precipitable water vapor R01 r01 1 Fcst Model Liquid accum cycle RTO rto 1 Fcst Model Liquid accum storm total S01 s01 1 Fcst Model Snow accum cycle STO sto 1 Fcst Model Snow accum storm total TH th 1 Fcst Model Potential temperature THE the 1 Fcst Model Equivalent potential temp PBE pbe 1 Fcst Model Positive buoyant energy NBE nbe 1 Fcst Model Negative buoyant energy PS ps 1 Fcst Model Surface pressure CCE cce 1 Fcst Model Cloud ceiling VIS vis 1 Fcst Model Visibility LCV lcv 1 Fcst Model Cloud cover LMT lmt 1 Fcst Model Max echo tops SPT spt 1 Fcst Model Sfc precip type LHE lhe 1 Fcst Model Helicity LI li 1 Fcst Model Lifted index HI hi 1 Fcst Model Heat index SWI swi 1 Downward Shortwave Radiation SWO swo 1 Fcst Model Outgoing Shortwave Radiatio n LWO lwo 1 Fcst Model Outgoing Longwave Radiation FWI fwi 1 Fcst Model Fosberg fire weather index FWX fwx 1 Fcst Model Kelsch fire weather index RSM LSM lsm 11 Fcst Model Soil Moisture Intermediate LAPS files: Process vrcdriver: VRC REF ref 1 NOWRAD 2D radar reflectivity Process mosaicradar: VRZ 21 (3D reflectivity mosaic) Process remap: V01 REF refd 21 Radar reflectivity VEL veld 21 Radial Velocity NYQ nyqd 21 Nyquist velocity files V02, V03, V04, V05, V06, V07, V08, V09, V10, V11, V12, V13, V14, V15, V16, V17, V18, V19, V20 same format Process lga. exe (background model): LGA HT ht 21 Model isentrop height interp to LAPS isobaric (geopotential meters) T3 t 21 Model isentrop temp interp to LAPS isobaric SH sh 21 Model specific humidity U3 u 21 Model u wind component (grid north) V3 v 21 Model v wind component (grid east) OM om 21 Model vertical velocity (Pascalssecond) LGB USF usf 1 Model Surface wind u (grid north) VSF vsf 1 Model Surface wind v (grid east) TSF tsf 1 Model Surface Te mperature TGD tgd 1 Model Ground Temperature DSF dsf 1 Model Dewpoint SLP slp 1 Model MSL pressure PSF psf 1 Model Surface pressure RSF rsf 1 Model Specific Humidity P p 1 Model reduced pressure PCP pcp 1 Model Precipitation Process lvdsatingest: LVD S8W s8w 1 GOES IR band-8 bright temp warmest pixel S8C s8c 1 GOES IR band-8 bright temp coldest pixel SVS svs 1 GOES visible satellite - raw SVN svn 1 GOES visible satellite - normalized ALB alb 1 albedo S3A s3a 1 GOES IR band-3 bright temp averaged S3C s3c 1 GOES IR band-3 bright temp filtered S4A s4a 1 GOES IR band-4 bright temp averaged S4C s4c 1 GOES IR band-4 bright temp filtered S5A s5a 1 GOES IR band-5 bright temp averaged S5C s5c 1 GOES IR band-5 bright temp filtered S8A s8a 1 GOES IR band-8 bright temp averaged SCA sca 1 GOES IR band-12 bright temp averaged SCC scc 1 GOES IR band-12 bright temp averaged Note: band-8 is approx 11.2 microns. Static LAPS file - run by localization: gridgenmodel. exe: creates file static. nest7grid LAT 1 Latitude (degrees) LON 1 Longitude (degrees) AVG 1 Mean elevation MSL (m) STD 1 Unused ENV 1 Unused ZIN 1 Z coordinate - used for plotting in AVS LDF 1 Land Fraction (0water,1land) USE 1 Landuse
No comments:
Post a Comment