Actualmente estoy desarrollando un método de descomposición de dominio para la solución del problema de dispersión. Básicamente estoy resolviendo un sistema de Helmholtz BVP de forma iterativa. Discreto las ecuaciones usando el método de elementos finitos sobre mallas triangulares o tetraédricas. Estoy desarrollando el código para mi tesis doctoral. Soy consciente de algunas de las bibliotecas de elementos finitos existentes, como deal.ii o DUNE, y aunque creo que son geniales, con un diseño inspirador y API, para fines de aprendizaje, quería desarrollar mi propia pequeña aplicación desde cero.
Estoy en un punto en el que tengo mis versiones en serie ejecutándose y ahora quiero paralelizarlas. Después de todo, uno de los puntos fuertes del marco de descomposición de dominio es formular algoritmos que sean fáciles de paralelizar, al menos en principio. En la práctica, sin embargo, hay muchos detalles que uno debe considerar. La gestión de la malla es una de ellas. Si las aplicaciones van a lograr una alta resolución mientras se escala bien a muchas CPU, la replicación de una malla completa en cada CPU es ineficiente.
Quería preguntar a los desarrolladores que trabajan en aplicaciones similares en entornos informáticos de alto rendimiento cómo abordan este problema.
Hay una biblioteca p4est para la gestión de mallas distribuidas. No necesito AMR, por lo que podría ser una exageración ya que solo estoy interesado en usar mallas uniformes y no estoy seguro de si puede refinar mallas triangulares. También podría simplemente crear una malla uniforme, luego alimentarla en uno de los divisores de malla y hacer un procesamiento posterior de la salida.
El enfoque más simple parece crear un archivo separado para cada partición que contiene información de malla relevante solo para esa partición en particular. Este archivo sería leído por una sola CPU que sería responsable del ensamblaje del sistema discreto en esa parte de la malla. Por supuesto, alguna información de vecindad / conectividad de partición global también necesitaría ser almacenada en un archivo leído por todas las CPU para la comunicación entre procesos.
¿Qué otros enfoques hay por ahí? Si algunos de ustedes pudieran compartir, ¿cuáles son algunas de las metodologías comúnmente utilizadas en la industria o las instituciones gubernamentales de investigación relacionadas con el manejo de este problema? Soy bastante nuevo en la programación de un solucionador de elementos finitos paralelos y quería tener una idea de si estoy pensando o no en este problema correctamente y cómo otros lo están abordando. Cualquier consejo o sugerencia para artículos de investigación relevantes sería muy apreciado.
¡Gracias por adelantado!
Respuestas:
Si no está utilizando AMR y no desea escalar más allá de los núcleos 1K-4K, simplemente haga esto.
El rango 0 lee toda la malla y la divide usando METIS / Scotch, etc. (Nota: Esta es una operación en serie).
El rango 0 difunde la información de partición del elemento / nodo a todos los demás rangos y libera la memoria (utilizada para almacenar la malla)
Todos los rangos leen los nodos / elementos que poseen (incluidos los nodos fantasmas) del mismo archivo de entrada (Nota: 2000 rangos que acceden al mismo archivo de entrada pueden sonar lentos pero no son prácticos, aunque puede ser malo para el sistema de archivos, pero luego lo están haciendo solo una vez).
Todos los rangos deben crear las asignaciones locales / globales de nodo / elemento / dof para la aplicación de BC y el ensamblaje de matrices y renumerar los nodos.
Después de que todo esté dicho y hecho, todos los datos en un rango serán locales, por lo que debería poder escalar bien (en cuanto a memoria). Hago todo esto en aproximadamente 100 líneas (ver líneas 35-132 aquí ) en un pequeño código mío.
Ahora, si su malla es demasiado grande (por ejemplo,> 100-250 millones de elementos) que no puede particionar usando METIS en un solo nodo y necesita ParMETIS / PT-Scotch, entonces tiene el trabajo adicional de particionarlo en paralelo antes de todos los núcleos / los rangos pueden leerlo. En tal escenario, podría ser más fácil mantener la fase de partición separada del código principal por razones logísticas.
Por cierto, las bibliotecas de AMR generalmente no hacen pruebas. También PETSc es una buena opción para la paralelización de su código.
Editar: También vea aquí y aquí .
fuente
Puede que esto no te sorprenda dado que desarrollo el acuerdo. II, pero aquí está mi perspectiva: cuando hablo con los estudiantes, generalmente les digo que desarrollen su propio prototipo al principio para que puedan ver cómo se hace. Pero luego, una vez que tienen algo pequeño funcionando, les hago usar una biblioteca que les permite ir mucho más lejos porque no tienen que reinventar la rueda básicamente con cada paso que dan.
En su caso, ya ha visto cómo implementar un solucionador Helmholtz simple. Pero pasará los próximos 6 meses escribiendo el código necesario para hacerlo en paralelo, pasará otros 3 meses si desea usar geometrías más complicadas. Luego pasará 6 meses más si desea un solucionador eficiente. Y todo este tiempo estás escribiendo código que ya ha sido escrito por otra persona y que, en cierto sentido, no te acerca más a lo que realmente necesitas hacer para tu doctorado: desarrollar algo nuevo que no haya sido hecho antes. Si sigue este camino, pasará 2-3 años de su tiempo de doctorado rehaciendo lo que otros han hecho, y tal vez 1 año haciendo algo nuevo.
La alternativa es que ahora pasa 6 meses aprendiendo una de las bibliotecas existentes, pero después de eso tendrá 2-3 años donde realmente hace cosas nuevas, cosas en las que cada dos semanas puede ingresar a la oficina de su asesor y mostrarle / ella es algo realmente nuevo, que se ejecuta en escalas masivamente grandes, o simplemente es muy bueno en otros aspectos. Creo que probablemente ya ve a dónde voy con esto.
fuente
Esta no es una respuesta completa.
Para la implementación de métodos de descomposición de dominio paralelo, encontré algunas complicaciones. Primero, uno puede usar muchos procesadores para un subdominio o alimentar un procesador con muchos subdominios y uno puede implementar ambos paradigmas. En segundo lugar, la forma subestructurada de los métodos de descomposición del dominio requiere separar las caras, aristas y vértices de los subdominios (no los elementos). No creo que estas complicaciones se incluyan fácilmente en el manejo de la malla paralela. La situación se vuelve más simple si considera un procesador para un subdominio y utiliza el método superpuesto RAS / RASHO. Incluso en este caso, será mejor que gestiones tu diseño paralelo tú mismo,
fuente