CFD 라이브러리 개발을위한 C ++ 또는 Python


13

Computtional Continuum Mechanics를위한 일반 (finite volume, fem, dg) 라이브러리를 코딩하는 두 가지 접근 방식의 장점 / 단점은 무엇입니까? 이것은 내가 지금 상황을 보는 방법이므로, 나만의 경험을 제공하고 나를 위해 화를 내지 마십시오 :) :

1) C ++ :

  • 일반 프로그래밍, 가상 기능, 과부하, 속도 ... : 원하는 모든 것을 구축 할 수있는 모든 장르 + OOP 도구

  • 주로 사용 가능한 저수준 라이브러리 (Python 용과 같은 광범위한 과학 및 엔지니어링 라이브러리 개발 없음)

2) 병렬 컴퓨팅을위한 Python + 래퍼 (pyOpenCL 및 기타)

  • 다양한 종류의 지원 라이브러리

  • 당신이 생각하는 것을 코딩하십시오 : 구현은 정말 빠릅니다.

  • 느린 실행 시간

다양한 방법을 지원하는 프레임 워크를 코딩하려면 복잡한 형상 및 문제를 다루십시오. 무엇을 선택하고 이유는 무엇입니까?


1
나는 pyOpenCL에 익숙하지 않지만, 계산 "커널"이 저수준 언어 (Fortran, C 등)로 구현되지 않으면 일반적으로 파이썬은 2D 또는 3D에서 중간 크기의 문제조차도 너무 느릴 것입니다 )
David Ketcheson

답변:


14

저는 두 가지 이점을 최대한 활용하고 파이썬에서 "사용자 인터페이스"(즉, 라이브러리 사용자가 문제의 지오메트리 및 기타 속성을 설명하기 위해 호출 할 함수의 프레임 워크)를 코딩하는 것을 목표로합니다. 처리 시간을 설정 한 다음 시뮬레이션 런타임을 C ++로 작성하십시오.

사실, 파이썬에서 시뮬레이션 실행 시간을 먼저 조롱 한 다음 C ++ 코드로 교체합니다. 결국 파이썬 코드가 C ++ 소스를 생성하고 온라인으로 런타임에 컴파일되고 링크되도록 고려할 수 있으므로 실제 시뮬레이션은 전혀 파이썬을 호출 할 필요가 없습니다. 결과는 결국에만 반환됩니다. 이 설정의 좋은 점은 본질적으로 민첩하다는 것입니다. 가장 빠르고 쉬운 작업 솔루션으로 시작하여 작동하는 것과 작동하지 않는 것을 신속하게 찾아 내고, 원하는 것이 있으면 속도를 높일 수 있습니다.

(이것은 Python 대신 Maple을 사용하는 것을 제외하고 Maple의 ODE / DAE 솔버가 작동하는 방식입니다. 전체 공개 : 나는 그것들을 위해 일합니다.)


1
+1. 파이썬 의 좋은 점 중 하나는 필요한 경우 "Pure Python"에서 벗어날 수 있다는 것입니다.
Fomite

3

Cython 을 알고리즘에 사용할 수도 있습니다 . 기본적으로 "빠른"일부 변수에 대한 유형 정보가 추가 된 Python입니다. 파이썬 코드를 C 코드로 변환하고, 나중에 좋아하는 C 컴파일러로 컴파일 할 수 있습니다. 이 유형 정보를주의해서 추가하면 코드가 순진한 Python 코드보다 최대 150 배 빠릅니다.


2

이 질문에 더 많은 것이 있다고 생각합니다. 무엇보다도 개발자는 일반적으로 상당한 이점 (예 : 생산성, 개발 시간 및 도구)이 없다면 익숙한 것을 선호합니다. 개인적으로, 나는 생산성을 높이는 데 우선 순위를 두며 (시간은 일반적으로 가장 희소 한 자원입니다!) 이것은 내 경험 기반에 가까운 선택을 선호합니다.

아마도 고려할만한 관련성이 있습니다.

3) 개발 시간

  • 개발에 소요되는 시간
  • 작업 결과는 언제 전달됩니까? 그리고 어떻게?
  • 작업을 수행 할 수있는 코드가 이미 존재합니까? (고유?)

4) 유지 보수

  • 유지 보수에 얼마나 많은 (인력) 자원이 투입됩니까?
  • 코드를 작성하는 사람은 몇 명입니까?
  • 코드가 언젠가 릴리스 될까요? (기준?)
  • 코드가 타사 라이브러리에 의존합니까?

5) 라이센스 문제

  • 연구 코드는 무엇입니까?
  • 상용 응용 프로그램을위한 코드입니까?

6) 생산성과 재미있는 요소 (종종 간과!)

  • 가장 생산적인 곳은 어디입니까?
  • 가장 재미있게 개발할 수있는 곳은 어디입니까?
  • (소셜) 네트워크의 일부가 될 수있는 기회가 있습니까?

2

코드를 다음과 같이 작성할 수 있는지 여부에 따라 다릅니다.

some_library_specific_type grid;

for t=0 to T do
    library_function_1(grid,...);
    library_function_2(grid,...);
end

또는 다음과 같이 작성 해야합니다 .

some_home_made_mixture_of_native_types grid;

for t=0 to T do
    for all grid elements as g do
        some_function(g,...);
        library_function(g,...);
    end
end

첫 번째 경우 가장 코딩하려는 것을 선택하십시오. 두 번째 경우에는 스크립팅 언어를 사용하지 않거나 실행 시간으로 고통받을 준비를하십시오.


2

Allan의 답변에 대한 추론으로 (자신의 개발자 시간이 가장 소중한 자원이라는 점) : 다른 사람들이 이미 한 일을 사용하십시오. 당신은 계산 연속체 역학을위한 라이브러리를 개발하고 싶다고 말하지만 이미 너무 커서 이미 필요한 모든 것을 가지고있을 것입니다. 유한 요소 문제, 유체 역학의 경우 OpenFOAM, 쌍곡선 문제의 경우 PyCLAW / CLAWPACK으로 쓸 수있는 모든 항목에 대해서는 deal.II를 살펴보십시오. 예를 들어 deal.II는 C ++로 프로그래밍하도록 요청하지만 실제로는 프로그래밍 수준이 너무 높아서 C ++ 구문을 사용하는 FEM 코드의 도메인 별 언어와 비슷하다고 말할 수 있습니다.


2
나는 필요한 모든 것을 갖춘 도서관을 본 적이 없다 .
Jack Poulson

글쎄,하지만 당신은 내가 생각하는 포인트를 얻습니다. 일부 라이브러리에는 "거의 모든 것"이 필요할 수 있습니다. deal.II 및 PETSc 126 코드 라인을 사용하여 10,000 개 이상의 프로세서에서 실행되는 완전 자체 적응 형 3D 메시의 유한 요소 솔버에 대해 특히 익숙한 예를 들었습니다. 분명히 0보다 크지 만 실제로는 매우 복잡한 문제를 감안할 때 매우 적은 수입니다.
Wolfgang Bangerth

악마의 옹호자를 플레이하려면 10,000 코어에서 코드를 실행하는 것이 쉽지 않지만 확장 가능하게 만드는 것은 완전히 다른 문제입니다. 비타 원 방정식에 대한 병렬 전제 조건이 많지 않아 300 코어에서 효율적으로 실행될 수 있습니다.
잭 폴슨

확실한. 그러나 내가 인용 한 예 확장 가능합니다 : math.tamu.edu/~bangerth/publications/2010-distributed.pdf .
Wolfgang Bangerth

완전한 공개를 위해 : 나는 일반적으로 deal.II 라이브러리뿐만 아니라 위에서 언급 한 논문과 코드의 저자 중 하나입니다.
Wolfgang Bangerth
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.