Çok fazla veriyle nasıl başa çıkılır?


14

Plazma dinamiği simülasyonlarımız genellikle çok fazla bilgi üretir. Simülasyonlar sırasında en az 10 özellik için (8192x1024x1024x1500) kadar büyük bir ızgaraya (x, y, z, t) çeşitli fiziksel özellikler kaydederiz. Bu bilgi simülasyon tamamlandıktan sonra işlenir. Onunla biz

  1. mülklerin filmlerini yapmak,
  2. Fourier analizi yapabilir,
  3. ortalama özellikleri hesaplar.

Bu kadar basit bilgi dökümü, daha küçük sistemleri incelediğimizde işe yaradı. Bu bize sonuçlarla etkileşim kurma ve daha sonra bununla ne yapmak istediğimize karar verme esnekliği verdi. Ayrıca, hesaplama kaynaklarımızı (CPU zamanı) simülasyonları çalıştırmak için ayırmamıza izin verdi.

Fourier analizini anında yapma ve yalnızca belirli bir uzunluk ölçeği aralığı için filtreleme sürecine başladık. Sayısal nedenlerden dolayı, bazen gerçekten ilgilendiğimizden daha küçük uzunluk ölçeklerini çözmemiz gerekir, bu nedenle bu filtre çok yardımcı olur. Paralel G / Ç seçenekleri, özellikle paralel HDF5 gibi çeşitli paralel G / Ç kütüphanelerini de araştırıyoruz .

Veri işleme verimliliğini en üst düzeye çıkarmak için hangi stratejiler mevcut?

Tüm analizleri (örneğin post proses, ör. Filmler ve araziler dahil) anında gerçekleştirmenin herhangi bir faydası var mı?

Bu konunun diğer araştırma alanlarında ortaya çıktığını hayal edebiliyorum. Örneğin, uzun bir süre gelişmesi gereken bir moleküler dinamik simülasyonuna sahip olabilirsiniz, ancak ilginç bir şeyin gerçekleştiği kısa anla ilgileniyorsunuz. Veya CFD'de erken dönem gelişimi yavaş olabilir, ancak türbülans ortaya çıktığında, dinamikleri izlemek için daha yüksek bir zaman çözünürlüğüne ihtiyacınız olabilir.

Simülasyonlardan karmaşık sonuçlar toplama konusunda serbestçe örnekler var mı?


Bu geniş bir soru gibi görünebilir. Bu şekilde hissediyorsanız, lütfen nasıl daha spesifik olabileceğim konusunda önerilerde bulunun.
Yann

1
Ayrıca bazı deney gruplarının bu sorunla nasıl başa çıktıklarına bakın. Yüksek enerji fiziği (al CERN) ve astrofizik, depolanması (veya depolanmadan önce filtrelenmesi gerektiğinden daha fazla veri ölçeğine sahip olabilir) çünkü veriler herhangi bir depoya yazılabileceğinden daha hızlı gelir), dağıtılır ve analiz edilir.
Brian Diggs

Yanıtlar:


10

Bence çıktılarınızı hedeflerinize uyacak şekilde bölmeniz gerekebilir:

  1. özelliklerin filmleri için büyük olasılıkla tam uzamsal çözünürlüğe ve tüm değişkenlere ihtiyacınız yoktur. Neyi göstermek istediğinizi dikkatlice seçin ve göstereceğiniz filmin son çözünürlüğünü düşünün, muhtemelen 8 milyar piksele sahip olmayacak.
  2. Fourier analizleri (veya POD gibi şeyler) için zamansalsa, muhtemelen alan adınızda akıllıca seçilmiş birkaç yüz noktayı örnekleyebilirsiniz. Mekansallarsa, muhtemelen 1500'e değil, sadece birkaç anlık görüntüye ihtiyacınız vardır. Ve yine, tüm özelliklerden değil.
  3. Zaman ortalaması için, aynı alana eklemeye devam edebilirsiniz ve zaman boyutu hakkında endişelenmenize gerek yok değil mi? Uzamsal ortalama, özellikle zaman içindeki evrimine bakmak istiyorsanız acı vericidir. Ancak verileri boşaltmadan önce daha fazla çevrimiçi işlem, verilerin boyutunu azaltabilir ...

Bu, büyük bir jenerik yerine özel çıktılara sahip olmak için biraz çalışma anlamına gelir, ancak bu, maliyeti ve boyutu düşürmeye yardımcı olacaktır. Bu yardımcı olur umarım !

Eklemek istediğim bir şey daha var, genel olarak, verilerin tam çözünürlüğü yalnızca dosyaları yeniden başlatmak için, yani simülasyonunuzu yeniden başlatmak için dosyalar için gereklidir. Belirli bir simülasyon için bunlardan çoğuna ihtiyacınız yoktur (diyelim ki 100 diyelim, böylece 2 yeniden başlatma arasında bir şey olursa, hesaplamanızın en fazla% 1'ini kaybedersiniz), ancak muhtemelen filmleri. Ve bunu örneğin çözünürlüğün sadece 1 / 64'ünde yapabilirsiniz (her yönde 4 noktada 1).


Mekansal ortalama neden ağrılı? Sadece anında yapın ve küçük olması gereken sonucu yazın.
David Ketcheson

@DavidKetcheson Uzamsal ortalama acı verici çünkü çok fazla iletişim gerektiriyor ve potansiyel olarak alan adınızın topolojisinden etkileniyor hayır? Tabii ki referans çerçevenizle hizalanmış saf bir dikey ızgara varsa çok kötü değil, ama yine de akıllıca bir hesaplama ve MPI_REDUCE kombinasyonu yapmanız gerekiyor, çünkü bu boyuttaki bir ızgara ile, sadece ALL_REDUCE yapamazsınız 1 işlemci düşünürdüm ...
FrenchKheldar

1
Tamam, şimdi yorumunu anlıyorum. Ancak iletişim genellikle çok kötü değildir, çünkü her bir işlemi yerel olarak ortalayabilir ve daha sonra işlem başına tek bir şamandırayı azaltabilirsiniz. Deneyimlerime göre (65K çekirdekli BlueGene / P'de), bunun maliyeti özellikle G / Ç maliyetleriyle karşılaştırıldığında önemsizdir. Aslında, her zaman adımında tüm 65K çekirdekler üzerinde ALL_REDUCE yapıyoruz ve çok hızlı.
David Ketcheson

@DavidKetcheson Aslında şimdi ben de senin fikrini yanlış anladığımı düşünüyorum, ve ben de veri azaltma maliyetini fazla tahmin ediyorum. Aklımda ne vardı hesaplama / ızgara ile aynı ızgara üzerinde olabilir veya olmayabilir tam 2D ​​veri depolamak / çıktı olurdu bir spanwise / azimuthal ortalama gibi bir şey oldu. Ama haklısın, MPI_ALL_REDUCE'ın gerçek maliyeti kendi başına bir sorun değil.
FrenchKheldar

8

Bu sanatın şu anki ustaları büyük parçacık fiziği deneyleridir ( CDF ve D0'a çok aşinayım çünkü yaşlıyım ve Chicago Üniversitesi'nde çalışıyorum). Yılda petabaytları (veya daha fazlasını) atayan donanım tetikleyicileri vardır. Bununla birlikte, bu, nicemleme / ayrıklaştırma ya da “sadece ihtiyacınız olmayanları atma” konusudur. Genel olarak mantıklı bir cevap verebileceğinizden emin değilim. Sorunu "Şu şekilde ayrıklaştırılmış bir PDE simülasyonum var ve verimli bir şekilde küçültmek istiyorum" gibi bir şeye daraltmak daha iyi olurdu.


3

Peter LePage, kafes-QCD çevrelerinde, kısa menzilli iyi analitik çözümler bularak ve uygulanarak mümkün olmayan büyük kafes ızgaralarının azaltılabileceği bir yöntem önerdiği için oldukça ünlüdür.

Bu kabaca, iyi seçilmiş bir dizi yivin yamuk yönteminden daha az düğüm ile doğru entegrasyona izin verebileceğini fark etmekle eşdeğerdir (durumunuzda olduğu gibi bir kerede dört boyuttan faydalanabilmeniz dışında).

Sonuç olarak, düğüm başına adım başına daha fazla hesaplama için veri kümesinin ham boyutunu alıp vermeniz, ancak sorununuzun yüksek boyutsallığı nedeniyle en sonunda ortaya çıkmanızdır .

İyi bir ipucu verecek kadar iyi bildiğim bir konu değilim, ama geçmişte bazı alanlarda çalıştı.


3

Soru biraz geniş, bu yüzden bu gibi durumlarda olası teknikleri öneren belirsiz bir cevap vereceğim.

1) Üzerinde çalıştığınız anında işleme. Anında işlem yapmanın ve bunu veri oluşturma adımından ayırmanın bir yolu, her zaman son N adımlarını içeren ve analizin ayrı bir işlemde çalıştırılmasını sağlayan döngüsel bir çıktı dosyası oluşturmaktır. Bir yarış durumunu önlemek için ikisini senkronize etmeniz gerektiği açıktır.

2) Saklanan verileri daha dikkatli seçmek. Bu maalesef yüksek oranda duruma özgüdür.

3) Kaydetmeden önce verilerinizi sıkıştırın veya HDF5 gibi entegre sıkıştırma seçeneklerine sahip bir depolama kitaplığı kullanın.

4) Tam çıkış yerine düzenli kontrol noktalarını saklayın. Her N adımda tam bir kontrol noktası depolarsanız, yani simülasyonu oradan yeniden başlatmak için yeterli veri depolarsanız, eksik verileri gerektiğinde ve gerektiğinde oldukça paralel bir şekilde yeniden yapılandırabilirsiniz. Monte-Carlo yöntemleri söz konusu olduğunda, kontrol noktasının rasgele sayı üreteçlerinin durumunu içermesi gerektiğini unutmayın. Aslında bunu oldukça uygulamaya özgü bir sıkıştırma tekniği olarak düşünebilirsiniz.

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.