CAPÍTULO 3. CASO ESTUDO
3.2. Modelo tridimensional do estuário do rio Lima
Uma das fases mais importantes e mais morosa foi a criação do modelo, não só pela aprendizagem necessária sobre o funcionamento do software mas também pela necessidade de usar outras ferramentas externas ao Delf3D para conseguir realizar as tarefas de pré- processamento. Desta forma, e com o intuito de criar a grelha necessária para as simulações, foi utilizado o Google Earth (2015), através da ferramenta “adicionar caminho”, para obter os contornos do estuário em formato *kml desde a zona de Ponte de Lima até ao oceano em Viana do Castelo (figura 8). Numa fase inicial, e com o objetivo de verificar a grelha obtida através deste método, foi apenas utilizado o contorno do leito menor do rio. Após uma verificação visual da qualidade do mesmo foi elaborado o contorno do leito de cheia. Dadas as dificuldades em perceber o seu contorno, foi utilizada a linha de vegetação e a funcionalidade do Google
Earth que permite obter uma estimativa da cota da zona onde se encontra o cursor. Assim
considerou-se uma distância desde do eixo do rio até um limite onde a cota seja superior à cota do leito 4 m. Foi utilizada esta distância de 4 metros devido á variação da amplitude da maré e com o conhecimento que as zonas do leito de cheia não ficam submersas em maré viva.
Figura 8 - Contornos do estuário do Rio Lima utilizados na construção da grelha (modificada, Google Earth, 2015)
O programa Defl3D não reconhece o tipo de ficheiro *.kml. Para transformar o contorno num formato compatível com o software utilizado e para a transformação de coordenadas para o mesmo datum de referência utilizado na batimetria, que será abordado na secção seguinte, foi utilizado o ArcMap 10.1. Através deste programa, e utilizando as suas ferramentas foi possível criar um layer para cada ficheiro *kml obtendo- se assim quatro layers que representam o contorno do estuário, dois relativos ao leito menor e dois correspondentes ao leito de cheia (um para cada margem). Posteriormente, foi utilizado o comando merge, criando assim um só layer para se proceder à conversão do sistema de coordenadas UTM para
Datum_73_Hayford_Gauss_IGeoE. A finalizar a utilização do ArcMap o ficheiro foi exportado
como shapefile (*.shp). Contudo, o Defl3D ainda não reconhece este ficheiro, este tem de ser convertido para landboundarie ou spline. Optou-se por converter para spline, pois assim facilita a criação das linhas de apoio para a criação da grelha. Assim, e agora já utilizando o software
Delf3D, foi usada a funcionalidade QUICKPLOT , apesar de esta ser uma ferramenta para
exportar resultados permite que os ficheiros shapefile sejam abertos, sendo depois exportados com o formato de spline (*.spl) (figura 9) (Anexo 3 – figura 54)
Figura 9 – Ambiente Delf3D linhas de apoio - splines
Para a criação da grelha necessária ao modelo do estuário, é indispensável haver a criação de um conjunto de linhas de apoio, splines. Estas linhas de apoio servem para haver uma divisão da grelha num número de espaços desejado, logo é possível manipular o número ou posição das linhas para aumentar o número de pontos da grelha numa determinada zona (figura 9). Assim, usando a funcionalidade RGFGRID do DElf3D, foram acrescentadas splines verticais às splines do ficheiro exportado do Google Earth (Anexo 3 – figura 55.A). Após várias tentativas e a sua avaliação visual (figura 10), foi obtida uma grelha ortogonal, requerida para máxima fiabilidade
de resultados. As maiores dificuldades foram as zonas de ligação estuário-oceano e as curvas mais acentuadas existentes que faziam com que a grelha deixasse de ser ortogonal. Para as zonas que o refinamento não resultou como esperado foi optado por serem apagadas células, sendo depois manualmente ajustadas as restantes. No caso da foz, foram eliminadas as secções da malha que não representavam a morfologia do estuário.
Figura 10 - Diferentes grelhas geradas no programa RGFGRID
Para se conseguir obter resultados mais fiáveis é necessário fazer o refinamento da grelha (figura11a), que acarreta uma consequência importante, o aumento do tempo de computação (Anexo 5.4 – figura 3.B). Assim, optou-se por fazer um refinamento local do leito menor do rio (figura11b.1) (Anexo 5.4 – figura 3.C) e depois um refinamento global de toda a grelha (figura 11b.2). As características finais da grelha estão presentes na figura 11c. Desta forma, obteve-se maior resolução na zona de maior interesse (foz) sem comprometer o tempo de computação (figura12) para cada simulação que foi aproximadamente de três horas para a versão bidimensional num computador com processador Intel Core i7 1.73GHz.
Figura 11 - Refinamento da grelha
Figura 12 - Grelha final
O refinamento visível na grelha final a jusante da embocadura do rio não foi propositado e só existe devido a incapacidade de ser feito um refinamento mais localizado.
Com o objetivo de incluir os molhes da embocadura, foi utilizada a função thin dams, dentro do módulo Flow input, permitindo assim delimitar as zonas em que se encontram os molhes e
Sem refinamento 1º Refinamento – Local
2º Refinamento - Global
(a) (b.1)
condicionando desta forma o escoamento e fluxo hidrodinâmico (figura 13) (Anexo 3 – figura 56).
Figura 13 - Obras marítimas na foz Google Earth (esquerda) e no Deld3D (direita)
3.2.1.Batimetria
Após a criação da grelha, o próximo passo foi utilizar a funcionalidade QUICKIN para atribuir a cada nó da grelha um valor de cota. Para isto, foi necessário obter ficheiros batimétricos da extensão da zona em estudo. Através do sítio na internet do instituto hidrográfico obteve-se a batimetria da zona costeira adjacente; sendo a batimetria da zona da embocadura disponibilizada pela Administração do Porto de Viana do Castelo. Para a zona de leito de cheia foi criado um ficheiro batimétrico com as coordenadas da zona de cheia do rio. Foi criada uma malha de pontos no Autocad atribuindo-se a cota a cada ponto de forma aproximada, sendo de seguida exportado através do comando EATTEXT como ficheiro excel e convertido com Bloco
de Notas para ficheiro tipo “depth” com extensão *xyz. As cotas foram atribuídas
acrescentando-se à cota do leito um valor correspondente ao desnível aproximado em cada secção entre o leito do estuário e as margens planas inundáveis, após reconhecimento de campo no local. Finalmente para o sector de montante do estuário foi criada também no Autocad uma malha de pontos que resultaram de uma medição no local da cota do açude, com um aparelho DGPS, e assumindo uma variação aproximadamente linear desde o açude até ao início do levantamento batimétrico. Esta aproximação foi utilizada de modo a simular o perfil existente e para suavizar o desnível evitando problemas de convergência nas simulações.
Todos os ficheiros foram convertidos para o sistema de coordenadas “Datum_73_Hayford_Gauss_IGeoE”. Com a importação de todos os ficheiros, batimétricos e
grelha, para a ferramenta do Delf3D QUICKIN, foi utilizado o comando triangular
interpolation para se atribuir os valores das cotas aos pontos da grelha (Anexo 3– figura 57).
No final, foram necessários alguns ajustes manuais em zonas onde não tinha sido atribuída qualquer cota no procedimento automático.
Figura 14 - Batimetria final importada para o ambiente Delf3D