Paralel Sonlu Elemanlar Hesaplamasında Kafes Yönetimi için En İyi Yöntemler?


11

Şu anda saçılma probleminin çözümü için bir alan ayrıştırma yöntemi geliştiriyorum. Temel olarak tekrar tekrar bir Helmholtz BVP sistemi çözüyorum. Üçgensel veya dört yüzlü ağlar üzerinde sonlu elemanlar yöntemi kullanarak denklemleri ayırıyorum. Doktora tezimin kodunu geliştiriyorum. Orada deal.ii veya DUNE gibi mevcut sonlu eleman kütüphanelerinden bazılarının farkındayım ve ilham verici tasarım ve API ile harika olduklarını düşünmeme rağmen, öğrenme amacıyla kendi küçük uygulamamı sıfırdan geliştirmek istedim.

Seri sürümlerimin çalıştığı bir noktadayım ve şimdi bunları paralelleştirmek istiyorum. Sonuçta, en azından prensipte, paralel hale getirilmesi kolay algoritmalar formüle etmek, alan ayrıştırma çerçevesinin güçlü yönlerinden biridir. Ancak uygulamada, dikkate alınması gereken birçok detay vardır. Mesh yönetimi bunlardan biridir. Uygulamalar birçok CPU'ya iyi ölçeklendirilirken yüksek çözünürlük elde edilecekse, tüm CPU'ların tamamının çoğaltılması verimsizdir.

Yüksek performanslı bilgi işlem ortamlarında benzer uygulamalar üzerinde çalışan geliştiricilere bu sorunla nasıl başa çıktıklarını sormak istedim.

Dağıtılmış ağ yönetimi için p4est kütüphanesi vardır. AMR'ye ihtiyacım yok, bu yüzden sadece üniforma kafesleri kullanmakla ilgileniyorum ve üçgen kafesleri rafine edip edemeyeceğinden emin değilim. Ayrıca, tek tip bir ağ oluşturabilir ve daha sonra ağ bölmelerinden birine besleyebilir ve çıktının sonradan işlenmesini yapabilirim.

En basit yaklaşım, her bir bölüm için yalnızca söz konusu bölümle ilgili ağ bilgilerini içeren ayrı bir dosya oluşturuyor gibi görünmektedir. Bu dosya, ayrık sistemin ağın o kısmına montajından sorumlu olacak tek bir CPU tarafından okunacaktır. Tabii ki, bazı küresel bölüm bağlantısı / mahalle bilgilerinin süreçler arası iletişim için tüm CPU'lar tarafından okunan bir dosyada saklanması gerekir.

Orada başka hangi yaklaşımlar var? Bazılarınız paylaşabildiyse, sektörde ya da devlet araştırma kurumlarında bu sorunun ele alınmasıyla ilgili yaygın olarak kullanılan yöntemlerden bazıları nelerdir? Paralel bir sonlu eleman çözücü programlamakta oldukça yeniyim ve bu problemi doğru düşünüp düşünmediğimi ve başkalarının ona nasıl yaklaştığını düşünmek istedim. İlgili araştırma makalelerine yönelik herhangi bir tavsiye veya işaretçi çok takdir edilecektir!

Şimdiden teşekkürler!


Mesh partitioner arıyorsanız - METIS iyi bir seçim olacaktır. Ayrıca ParMETIS'i de kontrol edin. Kafesleri yönetmek farklı bir hikaye, ITAPS iMesh sizin için bir çözüm olabilir. Lütfen bu soruya verilen yanıtları da kontrol edin: scicomp.stackexchange.com/questions/4750/…
Krzysztof Bzowski 12:13

@KrzysztofBzowski: Belki de Scotch kütüphanesini kullandınız mı? Sonlu elemanlar söz konusu olduğunda Scotch ve Metis arasındaki farkın ne olduğunu merak ediyordum. İMesh projesi çok ilginç görünüyor. Önümüzdeki birkaç gün içinde bunun hakkında daha fazla bilgi vereceğim. Anlaşmayı biliyorum. II ve DUNE. Bir süre önce openMesh'e baktığımı hatırlıyorum, ancak ihtiyacım olan işlevselliği sıfırdan uygulamanın daha kolay olacağını düşündüm. Sıralı ağlar için, temelde bu kağıt bağlantıda sunulan yarım kenar / yüz veri yapısını uyarladım Teşekkürler!
midurad

Yanıtlar:


7

AMR kullanmıyorsanız ve 1K-4K çekirdeklerin ötesine geçmek istemiyorsanız, bunu yapmanız yeterlidir.

  1. Derece 0, tüm ağı okur ve METIS / Scotch vb. Kullanarak bölümlere ayırır. (Not: Bu bir seri işlemdir).

  2. Derece 0, eleman / düğüm bölümleme bilgisini diğer tüm kademelere yayınlar ve hafızayı boşaltır (ağı saklamak için kullanılır)

  3. Tüm sıralamalar aynı giriş dosyasından sahip oldukları düğümleri / öğeleri (hayalet düğümleri dahil) okur (Not: Aynı girdi dosyasına erişen 2000 sıralaması yavaş gelebilir, ancak dosya sistemi için kötü olabilir, ancak daha sonra sadece bir kez yapıyoruz).

  4. Tüm sıralamaların, BC'lerin uygulanması ve matrislerin birleştirilmesi ve düğümlerin yeniden numaralandırılması için yerelden global düğüme / element / dof eşleştirmeleri oluşturması gerekir.

Her şey söyledikten ve yapıldıktan sonra, bir sıralamadaki tüm veriler yerel olacaktır, böylece iyi ölçeklendirebilmeniz gerekir (bellek açısından). Ben 100 hakkında hatları (çizgiler 35-132 bakınız tüm Bunu burada benim bir küçük kodunda).

Eğer ağınız METIS kullanarak tek bir düğümde bölümleyemeyeceğiniz ve ParMETIS / PT-Scotch'a ihtiyaç duyamayacağınız çok büyükse (örneğin,> 100-250 milyon eleman), tüm çekirdeklerden / rütbeleri okuyabilir. Böyle bir senaryoda, lojistik nedenlerle bölümleme aşamasını ana koddan ayrı tutmak daha kolay olabilir.

Btw AMR libs genellikle tets yapmaz. Ayrıca PETSc kodunuzun paralelleştirilmesi için de iyi bir seçimdir.

Düzenleme: Ayrıca buraya ve buraya bakın .


Kodunuzu paylaştığınız için teşekkürler! Büyük olasılıkla yukarıda özetlediğiniz rotayı alacağım. En az karmaşık gibi görünüyor ve zaten nasıl gideceğime dair bir fikrim var. Ayrıca MPI programlamasında iyi bir alıştırma olacaktır. AMR kütüphanelerinin genellikle evcil hayvanlara dokunmadığını söylemiştiniz. Üçgen ağlardan oluşan dörtlü bir ağacın kötü kalitede ağlara yol açabileceğini söylemek saf bir arındırma olabilir mi? Dörtlü rafine etmek kolay gözüküyor, ancak kaliteyi korumak istiyorsa bir tetü dörde bölmek zor görünüyor. Belki de PETSc için bir C ++ sarıcı var mı? C kullanabilirsiniz, ancak C ++ daha iyi olurdu.
13'te midurad

@midurad C ++ 'ı C yerine tercih ederseniz, PETSc ile karşılaştırılabilir bir C ++ kütüphanesi olan Trilinos'u düşünmelisiniz. Ayrıca, Trilinos, mesh bölümleme yapmak için kullanabileceğiniz bir pakete (Zoltan) sahiptir.
Dr_Sam

@midurad PETSc kullanıyorsanız yalnızca çok az sayıda MPI çağrısına ihtiyacınız vardır. Testleri düzeltmek kolay olmalı, ancak ilişkili dinamik veri yapılarıyla (verimli bir şekilde) ilgilenmek biraz düşünmeyi ve çalışmayı gerektirebilir. PETSc'yi C ++ ile kullanabilmelisiniz, ancak gereksinimleriniz göz önüne alındığında libmesh uygun bir seçenek olabilir (AMR ve tets'i desteklediğini düşünüyorum).
stali

Bilgi için hepinize teşekkürler. Bu çok yardımcı oldu.
Haziran'da midurad

2

Anlaşma geliştirdiğim göz önüne alındığında bu sizin için sürpriz olmayabilir. II, ama işte benim bakış açım: Öğrencilerle konuşurken tipik olarak başlangıçta kendi prototiplerini geliştirmelerini söylerim, böylece nasıl yapıldığını görebilirler. Ama sonra, küçük bir şeyleri koştuktan sonra, çok daha ileri gitmelerine izin veren bir kütüphane kullanmalarını sağladım, çünkü teker teker attıkları her adımda tekerleği yeniden icat etmek zorunda değiller.

Sizin durumunuzda, basit bir Helmholtz çözücüsünün nasıl uygulanacağını zaten gördünüz. Ancak önümüzdeki 6 ayı paralel olarak yapmak için gerekli kodu yazacaksınız, daha karmaşık geometriler kullanmak isterseniz 3 ay daha harcayacaksınız. Daha sonra verimli bir çözümleyici istiyorsanız 6 ay daha harcayacaksınız. Ve tüm bu zaman boyunca zaten başka biri tarafından yazılmış olan kod yazıyorsunuz ve bir anlamda doktora için gerçekten yapmanız gerekenlere daha da yaklaşmıyor: henüz yapılmamış yeni bir şey geliştirin önceden yapıldı. Bu yoldan giderseniz, doktora zamanınızın 2-3 yılını başkalarının yaptıklarını yeniden yaparak ve belki de 1 yılını yeni bir şey yaparak geçireceksiniz.

Alternatif olarak, şu anda mevcut kütüphanelerden birini öğrenmek için 6 ay geçiriyorsunuz, ancak bundan sonra gerçekten yeni şeyler yaptığınız 2-3 yıl sürecek, her hafta danışmanınızın ofisine girip ona gösterebileceğiniz şeyler / Ona gerçekten yeni, büyük ölçeklerde çalışan ya da başka açıdan çok havalı bir şey. Sanırım şimdiye kadar bununla nereye gittiğimi görüyorsun.


3
Bu konuda açıkça bir otorite olduğunuz için dürüst bir soru: doktora öğrencilerinin şu anki ürünlerinde kimse böyle problemlerle başa çıkmazsa, deal.ii gibi yeni nesil çerçeveleri kim yazacak? Zaten bir programı derlememiş olan doktora öğrencilerinin sorunlu bir eğilimini zaten görüyoruz. Ortalama kod geliştirme becerilerinin hesaplama bilimcilerinde sürekli bir düşüşte olduğu beni biraz rahatsız ediyor.
Aurelius

1
Bu adil bir soru. Benim gibi kemik kafalı ve inatçı olan lisansüstü öğrencilere ihtiyacın var :-) Ama cevabım, muhtemelen bunu yapan birkaç kişiye ihtiyacımız olduğu için, bu da herkesi yıllarca hayatlarını tekrar tekrar geçirmeye teşvik etmemiz gerektiği anlamına gelmez. başkalarının zaten uyguladığı şey.
Wolfgang Bangerth

2
Evet, yeterince adil. CFD araştırma dünyasını son 20 yıldır geride tutan tek büyük şey, yazılım mühendisliği yeteneğinin eksikliği ve modern yazılım uygulamalarının greybudlar tarafından reddedilmesi oldu. Çerçeveler bir yana, pek çok doktora öğrencisi eski miras kodu ve modern donanımda modern sayısal yöntemler için gerekli olan karmaşık yazılım parçalarını hızlı bir şekilde inşa edememe ile geri tutulur.
Aurelius

Greybeards hakkındaki ifadeye katılmıyorum (bu günlerde benimki de griye dönüyor ...). Ancak, yeni bir mezun öğrenciniz olduğunda acımasız eski kodlar veya tekerleği yeniden keşfetme arasında seçim yapmanız gerektiğini de görüyorlar. Çok az kişi yazdıkları yazılımla başarı elde etmenin tadını çıkarır (mevcut yazar dayanamaz) ve eğer kariyer yapacaklarını bilmiyorsanız, bu yolda umut verici bir mezun öğrenci göndermek istemezsiniz.
Wolfgang Bangerth

0

Bu tam bir cevap değil.

Paralel alan ayrıştırma yöntemlerinin uygulanması için bazı komplikasyonlarla karşılaştım. Birincisi, bir alt alan için birçok işlemci kullanabilir veya bir işlemciyi birçok alt alanla besleyebilir ve her iki paradigmayı da uygulamak isteyebilirsiniz. İkincisi, etki alanı ayrıştırma yöntemlerinin alt yapılandırılmış şekli, alt alanların (öğenin değil) yüzlerinin, kenarlarının, köşelerinin ayrılmasını gerektirir. Bu komplikasyonların paralel ağ yönetimine kolayca dahil olduğunu düşünmüyorum. Bir alt etki alanı için bir işlemci düşünürseniz ve çakışan RAS / RASHO yöntemini kullanırsanız durum daha kolay hale gelir. Bu durumda bile, paralel düzeninizi kendiniz daha iyi yönetirsiniz,

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.