Os arquivos “namelist” contém valores de variáveis fundamentais para o sistema de modelagem numérica para previsão de tempo WRF. Elas são lidas durante a execução do programa, o que permite alterar sua configuração sem a necessidade de recompilar o código fonte. O WRF trabalha com parâmetros dentro de três arquivos de texto: namelist.wps (pré-processamento), namelist.input (processamento) e namelist.ARWpost (pós-processamento).
Atualização: o WRF Domain Wizard original foi desativado, mas existe a seguinte opção: https://jiririchter.github.io/WRFDomainWizard/.
O WRF Domain Wizard é uma interface gráfica do usuário (GUI) para o WRF Preprocessing System (WPS) e um componente interno do WRF Portal. Permite aos usuários definir e localizar facilmente domínios (casos) selecionando uma região da Terra e escolhendo uma projeção de mapa. Os usuários também podem definir “nests” (grades aninhadas, ou seja, mais de um domínio para o mesmo estudo), editar os arquivos namelist.input e namelist.wps, executar os programas WPS (geogrid, ungrib e metgrid) através da GUI e visualizar a saída NetCDF.
Existem duas maneiras de usar a versão autônoma do WRF Domain Wizard: Java Web Start ou baixando o aplicativo e descompactando-o, conforme segue:
wget https://esrl.noaa.gov/gsd/wrfportal/domainwizard/WRFDomainWizard.zip mkdir WRFDomainWizard unzip WRFDomainWizard.zip -d WRFDomainWizard cd WRFDomainWizard chmod +x run_DomainWizard ./run_DomainWizard
Precisa da máquina Java instalada – veja mais clicando no link. O roteiro a seguir foi baseado no tutorial do dtcenter e no vídeo Adding a new domain to be used by WRF4G. Eles seguem também para rodar o WPS, mas aqui o foco é montar as namelists: primeiro o “.input”, depois o “.wps” e então o “.ARWpost”.
Exemplo de roteiro para montar namelists
- (opcional, caso não vá rodar o WPS) Escolha os diretórios onde estão o WPS, dados de terreno e domínios
- Escolha “New domain” e clique em “next”
- Escreva um nome e descrição e clique em “next”
- Clique em um ponto do mapa e arraste o curso para formar um retângulo abrangendo a área desejada, soltando para finalizar a marcação
- Em “projection option”, escolha “type -> Mercator”
- Ajuste a posição do centro para um ponto específico, aproveitando para personalizar as variáveis “centerpoint lon” e “centerpoint lat”, copiando os mesmos valores para “standard lon” e “true lat1” (manter “true lat 2” = 0); guarde esses valores para montar o arquivo namelists.wps!
- Clique em “update map” e aguarde para gerar um “zoom” sobre a região
- Para fazer uma grade de 15 km, altere a variável “grid points distance (km)” para 15, de modo que as outras variáveis de “grid options” (“horizontal dimensions” X e Y) são automaticamente calculadas quando você readequar o retângulo do mapa com o mouse (dica: reduza a área do retângulo diretamente no mapa antes, para os contronos não saírem do zoom); altere a “geographic data resolution” se for o caso (guarde esse valor para montar o arquivo namelists.wps)
- (opcional, caso faça um subdomínio) Para criar um subdomínio (grade aninhada ou “nest”), clique na aba “nests” e então em “new”; altere a “data geographical resolution” se for o caso; no mapa, clique no centro e arraste para soltar em uma nova posição e refaça o traçado para cobrir a área de interesse; altere a “geographic data resolution” se for o caso (guarde esse valor para montar o arquivo namelists.wps)
- Clique em “next” e “yes” (se pedir para refazer o arquivo “namelist”); a aba “text editor” contém o arquivo “namelist.input” para você usar no WRF
Montar dois ou mais domínios (ou grades aninhadas, do inglês “nested”) permite aumentar a resolução (espacial e temporal) de um sub-domínio sem a necessidade de usar uma alta resolução para toda a grade – muito caro computacionalmente. O sub-domínio sempre deve estar plenamente contido no domínio pai, sem um subdomínio sobrescrever apenas parte de outro eventual sub-domínio. É recomendada uma razão de 3:1 ou 5:1 entre os tamanhos de cada um (parent_grid_ratio).
Veja esse exemplo de saída, considerando latitude e longitude do centro do domínio 1 (área maior) como -22.070 e -48.434 (centro geométrico do estado de São Paulo) e um domínio 2 centrado na região metropolitana – a descrição das variáveis está disponível no link:
&time_control run_days = 0, run_hours = 12, run_minutes = 0, run_seconds = 0, start_year = 2000, 2000, start_month = 01, 01, start_day = 24, 24, start_hour = 12, 12, start_minute = 00, 00, start_second = 00, 00, end_year = 2000, 2000, end_month = 01, 01, end_day = 25, 25, end_hour = 12, 12, end_minute = 00, 00, end_second = 00, 00, interval_seconds = 21600, input_from_file = .true., .true., history_interval = 60, 60, frames_per_outfile = 1, 1, restart = .false., restart_interval = 5000, io_form_history = 2, io_form_restart = 2, io_form_input = 2, io_form_boundary = 2, debug_level = 0, / &domains time_step = 90, time_step_fract_num = 0, time_step_fract_den = 1, max_dom = 2, s_we = 1, 1, e_we = 82, 28, s_sn = 1, 1, e_sn = 61, 22, s_vert = 1, 1, e_vert = 30, 30, p_top_requested = 5000, num_metgrid_levels = 32, dx = 15000, 5000, dy = 15000, 5000, grid_id = 1, 2, parent_id = 1, 1, i_parent_start = 1, 50, j_parent_start = 1, 16, parent_grid_ratio = 1, 3, parent_time_step_ratio = 1, 3, feedback = 1, smooth_option = 0, / &physics mp_physics = 3, 3, ra_lw_physics = 1, 1, ra_sw_physics = 1, 1, radt = 30, 30, sf_sfclay_physics = 1, 1, sf_surface_physics = 2, 2, bl_pbl_physics = 1, 1, bldt = 0, 0, cu_physics = 1, 1, cudt = 5, 5, isfflx = 1, ifsnow = 0, icloud = 1, surface_input_source = 1, num_soil_layers = 5, sf_urban_physics = 0, 0, / &fdda / &dynamics dyn_opt = 2, rk_ord = 3, w_damping = 0, diff_opt = 0, km_opt = 1, damp_opt = 0, base_temp = 290., zdamp = 5000., 5000., dampcoef = 0.01, 0.01, khdif = 0, 0, kvdif = 0, 0, smdiv = 0.1, 0.1, emdiv = 0.01, 0.01, epssm = 0.1, 0.1, non_hydrostatic = .true., .true., time_step_sound = 4, 4, h_mom_adv_order = 5, 5, v_mom_adv_order = 3, 3, h_sca_adv_order = 3, 5, v_sca_adv_order = 2, 3, moist_adv_opt = 1, 1, scalar_adv_opt = 1, 1, / &bdy_control spec_bdy_width = 5, spec_zone = 1, relax_zone = 4, specified = .true., .false., periodic_x = .false., .false., symmetric_xs = .false., .false., symmetric_xe = .false., .false., open_xs = .false., .false., open_xe = .false., .false., periodic_y = .false., .false., symmetric_ys = .false., .false., symmetric_ye = .false., .false., open_ys = .false., .false., open_ye = .false., .false., nested = .false., .true., / &grib2 / &namelist_quilt nio_tasks_per_group = 0, nio_groups = 1, /
A variável “frames_per_outfile” indica o número de times que devem ter cada arquivo. Usando 1, serão gerados vários arquivos; usando um número igual ou maior que o número de times total (variável “history_interval”), todos os times serão guardados em um arquivo no final do processamento.
Para a variável “time_step”, use o valor da sua resolução (em km), multiplique por 6 e tire uns 10%. Por exemplo: dx = dy = 9000, então usar 9 x 6 = 54 -10% ~ 50 segundos. Recomenda-se realizar as integrações com passo de tempo equivalente até seis vezes o valor do espaçamento de grade. Se tiver um descompasso muito grande entre essas variáveis, podem aparecer erros do tipo “points exceeded cfl=2 in domain d01 at time…”, “Flerchinger USEd in NEW version” e “Program received signal SIGSEGV: Segmentation fault – invalid memory reference”.
Basta editar algumas das variáveis de “time_control” (principalmente run_days, start_*, end_*) e o que mais for de seu interesse (por exemplo, se não usar o módulo de química, cortar as variáveis pd_* na parte “dynamics”). Aqui, também foram alteradas as variáveis “e_vert” para 30, “p_top_requested” para 5000 e “num_metgrid_levels” para 32.
Essas informações podem ser usadas para montar o arquivo “namelist.wps” de pré-processamento. Considerando o arquivo original padrão, edite as variáveis temporais (“start_date”, “end_date” e “interval_seconds”), acerte a localização do arquivo de terreno (geog_data_path), inclua o segundo domínio (max_dom = 2) e copie as variáveis em comum do “namelist.input” (de “domains” para “geogrid”).
Importante: as variáveis dx e dy (em metros) devem conter apenas os valores do domínio maior (ou seja, têm só uma “coluna”). As variáveis map_proj, ref_lat, ref_lon, truelat1, truelat2 e stand_lon devem ser preenchidas com as informações no início (passo 6), e geog_data_res deve conter os valores de resolução dos domínios preenchidos anteriormente (passos 8 e 9; por exemplo: “geog_data_res = ’10m’, ‘5m’,”).
Por fim, o arquivo “namelist.ARWpost” para o pós-processamento segue um padrão onde só é necessário editar os intervalos de tempo e nomes/locais dos arquivos de entrada e saída. Caso use 2 domínios, a variável “input_root_name” deve ter o nome “d02” para pegar a saída da grade menor. Mais informações sobre as variáveis desse arquivo estão no manual da UCAR (capítulo 9 – Post-Processing Programs).
Versões dos arquivos podem ser vistos no GitHub/install_wrf, disponível no link.
Olá, teria dicas ao usar outras projeções? estou tendo problema pra usar Lambert e Lat-lon
Oi Robson, o que sei é que pode usar a variável map_proj = ‘lambert’ ou ‘lat-lon’ mas nunca fiz testes para comparar as duas opções. Imagino que tenha mais diferença de projeções quanto maior for a latitude. Dá uma olhada no fórum WRF & MPAS-A: https://forum.mmm.ucar.edu . Espero que ajude.