avançoes da semana passada / planos para a semana 2008.09.15

avançoes da semana passada / planos para a semana 2008.09.15

por Alexandre Roma -
Número de respostas: 4
Pessoal -
Segue um pouco do que fizemos e o que planejamos fazer no SAMRAI. Espero que isto ajude para entrarmos em fase logo.

PROGRESSOS DA SEMANA PASSADA:
[1] Identificamos onde alterar as condições iniciais do exemplo
LinAdv, tendo mudado com sucesso para um exemplo de função constante
por partes (um degrau).
[2] Identificamos com sucesso a subrotina em fortran responsável
pela marcação de células para refinamento (detecção de gradiente de
propriedade). Os níveis de refinamento, atualmente, estão sendo
criados de baixo para cima (do nível zero ao nível mais fino).

O objetivo ainda esta semana é entender a geração da malha composta em
t=0 visando ao início de um código nosso que resolve o mesmo problema
(equação linear de advecção).

PLANOS PARA ESTA SEMANA:
[1] Ler e entender o critério de marcação dado pela "extrapolação
de Richardson" (pela abordagem descrita em Berger e Colella)
[2] Ordenar os heading files de acordo com uma lógica que nós
entendamos: ou por namespaces (mesh, hier, xfer, ...) ou por suas
funções específicas (e.g. entrada/saída, restart, visualização,
descrição da malha composta, interpolações, geometria, ...).
Particularmente, eu sugiro classificar por namespace e por um monte de
comentários (em Inglês) do que o conjunto de classes daquele bloco
faz. O objetivo aqui é verificar se tudo o que foi incluido era
realmente necessário ou se foi deixado lá por "preguiça" de quem fez o
exemplo. Vai ser um exercício que vai forçar a gente entender mais
fundo a construção e uso das classes.
[3] Aprofundar o entendimento sobre "tagging" das células computacionais e criação da malha composta (manuseio das listas de tagged cells, criação de boxes - BergerRigoutsos e patch levels)
[4] Iniciar de level os estudos e o entendimento sobre o laço temporal com dt
mantido constante na malha composta (depois usaremos dt com
refinamentos).


Detalhes do que foi feito na semana passada podem ser obtidos com
Catalina (localização e paths dos arquivos, como alterar o Makefile,
etc.).

Aguardo input. 5a. feira vamos falar mais sobre os artigos... confirmado?
[]s Alexandre

PS: Copio abaixo de um outro e-mail os comentários sobre o trabalho da semana passada específico de Catalina - dúvidas devem ser postadas neste fórum e dirigidas a ela.

"...
Eu segui a iniciação da primeira malha chamada pelo método initializeHierarchy(), esto foi o que achei.

O objeto que o chama é time_integrator que pertence à classe TimeRefinementIntegrator, segundo o comentário feito para doxygen o método initializeHierarchy define e inicializa o nível grosso, depois o estimativo de erro é realizado para determinar se e quando fazer refinamento; sucessivamente vão se criando e inicializando os níveis finos até alcançar o número máximo de níveis ou até que o refinamento já não seja necessário.

No construtor do time_integrator foi passado como argumento o objeto gridding_algorithm da classe como o nome disse GriddingAlgorithm, o cual inicializa ao objeto privado d_gridding_algorithm do tipo BaseGriddingAlgorithm (paẽ) que herda o GriddingAlgorithm (filho).

Esta anotação é importante pois uma das primeiras alterações na criação da hierarquia do AMR com o nível 0, é disser, o nível grosso é chamado pelo d_gridding_algorithm com o metodo makeCoarsetLevel do GriddingAlgorithm. Creando toda a estructura impotante tamanho dos patches e informação de células fantasmas necesarias para crear niveis de refinamientos, teniendo em cuenta o limite da fronteira (restrinções nas proximidades com a fronteira) usando o GridGeometry, tem o balanceamento de carga para os Boxes com o LoadBalanceBoxes, a creação do hierarquia de patches com o makeNewPatchLevel com o PatchHierarchy e a inicialização da data com o initializaLevelData da classe TagAndInitialirStrategy(pãe) que é heredada e iniciada desde o main com o objeto erro_detector da classe StandardTagAndInitialize (filho). Retornando ao TimeRefinementIntegrator.

Agora vai a criação de níveis mais finos, tomando os métodos que eu considerei mais importantes se tem:
No TimeRefinementIntegrator é chamado o método initializeRefinedTimesteppingL
evelData o qual com uma estimativa do erro determina no caso em que o refinamento pode ser feito, se é ou não necessário. O d_gridding_algorithm encarga-se de chamar para o erro, EstimationUsesTimeIntegrator e depois o makeFinerLevel também no GriddingAlgorithm, aqui inicializa o "nesting" das células e o d_tag_init_Strategy que é iniciazado com o error_detector do main e chama o tagCellsforRefinement do StandardTagAndInitialize.

Dentro do StandardTagAndInitialize tem-se o d_tag_Strategy que é inicializado com o objeto hyp_level_integrator do main que é da classe HyperbolicLevelIntegrator e é quem chama o applyGradientDetector; agora é chamado o tagGradientDetectorCells por o objeto privado d_patch_strategy que foi inicializado com o linear_advection_model do main que é um objeto da classe LinAdv (implementada propiamente por o usuario, neste caso é o exemplo do SAMRAI).

Finalmente no LinAdv o tagGradientDetectorCells, depende do detectgrad_ e detectshok_ implementadas por o usuário no arquivo grad.f (gerado do grad.m4 com o makefile), dependentes do UVAL_GRADIENT y UVAL_SHOCK respectivamente. Aqui pela restrição de parada feita por o professor a execução é detida. Ainda não sei que vai depois.

Da pra entender a seqüencia? desculpem o portunhol.

..."









Em resposta à Alexandre Roma

Re: avançoes da semana passada / planos para a semana 2008.09.15

por Márcio Ricardo Pivello -
"[2] Ordenar os heading files de acordo com uma lógica que nós
entendamos: ou por namespaces (mesh, hier, xfer, ...) ou por suas
funções específicas (e.g. entrada/saída, restart, visualização,
descrição da malha composta, interpolações, geometria, ...)."



Na documentação do SAMRAI já existe a ordenação por namespace.
Em resposta à Márcio Ricardo Pivello

Re: avançoes da semana passada / planos para a semana 2008.09.15

por Alexandre Roma -
Pivello -
Aqui, refiro-me ao LinAdv. No main.C temos

"...
#include "SAMRAI_config.h"

#include <stdio.h>
#include <stdlib.h>
#include <string>
#include <fstream>
using namespace std;

#ifndef _MSC_VER
#include <unistd.h>
#endif

#include <sys/stat.h>

// Headers for basic SAMRAI objects

#include "tbox/SAMRAIManager.h"
#include "tbox/Database.h"
#include "tbox/InputDatabase.h"
#include "tbox/InputManager.h"
#include "PatchLevel.h"
#include "tbox/Pointer.h"
#include "tbox/SAMRAI_MPI.h"
#include "tbox/PIO.h"
#include "tbox/RestartManager.h"
#include "tbox/Utilities.h"
#include "VariableDatabase.h"

// Headers for major algorithm/data structure objects

#include "BergerRigoutsos.h"
#include "CartesianGridGeometry.h"
#include "CartesianVizamraiDataWriter.h"
#include "GriddingAlgorithm.h"
#include "HyperbolicLevelIntegrator.h"
#include "LoadBalancer.h"
#include "PatchHierarchy.h"
#include "StandardTagAndInitialize.h"
#include "TimeRefinementIntegrator.h"
#include "TimeRefinementLevelStrategy.h"
#include "VisItDataWriter.h"

// Header for application-specific algorithm/data structure object

#include "LinAdv.h"

// Classes for run-time plotting and autotesting.

#if (TESTING == 1)
#include "AutoTester.h"
#endif

..."


Visando ao nosso tutorial, gostaria de melhorar estes includes: classificá-los primeiro qto às classes do SAMRAI (mesh, hier, xfer, ...) e, em segundo, subclassificá-los qto à utilização (e.g. "domain geometry", "input/output", "hierarchy", "restart", ...)

Tbm gostaria de ter certeza de que estão incluídos apenas os estritamente necessários para a aplicação (será que o exemplo não foi reciclado de alguma outra coisa e, por falta de tempo ou pragmatismo, tem coisa demais lá?) Se houver mais do que o necessário, vai dificultar sem razão o aprendizado dos outros.

Outra vantagem deste exercício é que seremos forçados a aprender com mais profundida a lógica da construção das classes e como nós a usaremos (que espero seja menos "fechada" do que no exemplo emais tipo "tripa" como, pelo menos eu, estou acostumado...).

Era isto que eu tinha em mente. Vamos tentar simultaneamente aprender e refletir como vamos transmitir adiante.

Espero não ter dito bobagem.
[]s Alexandre









Em resposta à Alexandre Roma

Re: avançoes da semana passada / planos para a semana 2008.09.15

por Márcio Ricardo Pivello -
"O objetivo ainda esta semana é entender a geração da malha composta em t=0 visando ao início de um código nosso que resolve o mesmo problema (equação linear de advecção)."


A geração da malha é feita na classe TimeRefinementIntegrator, no arquivo TimeRefinementIntegrator.C:


/*
*************************************************************************
* *
* Create patch level and patches for coarsest level in AMR hierarchy *
* at initial simulation time. Then, set time stepping data and set *
* initial patch data on the coarsest level. The actual level data *
* initialization process is invoked by the recursive private member *
* function initialize(). This function will create and initialize *
* successively finer hierarchy levels until either the maximum number *
* allowable level is reached or no further refinement is needed. *
* *
*************************************************************************
*/

template<int DIM> double TimeRefinementIntegrator<DIM>::initializeHierarchy(
const hier::BoxArray<DIM>& override_boxes,
const hier::ProcessorMapping& override_mapping)
{
Em resposta à Márcio Ricardo Pivello

Re: avançoes da semana passada / planos para a semana 2008.09.15

por Alexandre Roma -
É isto aí. Agora gostaria de entender a fundo a seqüência de operações que está lá e, a seguir, alterá-la ao nosso bel prazer. Estou acostumado a gerar a c-grid no sentido top->bot. Acho que seria um exercício interessante alterar isto e a inicialização dos níveis hierárquicos...

Mãos à massa!

[]s Alexandre