C ++ hoặc Python để phát triển thư viện CFD


13

Bạn sẽ nói gì sẽ là ưu điểm / nhược điểm của hai cách tiếp cận để mã hóa thư viện chung (khối lượng hữu hạn, nữ, dg) cho Cơ học liên tục tính toán? Đây là cách tôi nhìn thấy mọi thứ ngay bây giờ, vì vậy vui lòng cung cấp trải nghiệm của riêng bạn và đừng truyền lửa cho tôi :):

1) C ++:

  • lập trình chung, chức năng ảo, quá tải, tốc độ ...: tất cả các công cụ thể loại + OOP có sẵn để xây dựng bất cứ điều gì bạn muốn

  • Thư viện cấp thấp hầu hết có sẵn (không phát triển thư viện khoa học & kỹ thuật trải rộng như thư viện cho Python)

2) Các hàm bao Python + cho tính toán song song (pyOpenCL và các hàm khác)

  • số lượng lớn các lib hỗ trợ các loại

  • mã những gì bạn nghĩ: việc thực hiện được thực hiện rất nhanh

  • thời gian thực hiện chậm hơn

Nếu bạn muốn mã hóa một khung công tác hỗ trợ các phương thức khác nhau, làm việc với các vấn đề và hình học phức tạp, bạn sẽ chọn cái gì và tại sao?


1
Tôi không quen thuộc lắm với pyOpenCL, nhưng nói chung Python sẽ quá chậm đối với các vấn đề có kích thước vừa phải trong 2D hoặc 3D, trừ khi các "hạt nhân" tính toán của bạn được triển khai bằng ngôn ngữ cấp thấp (Fortran, C, v.v. )
David Ketcheson

Câu trả lời:


14

Tôi sẽ nhắm đến việc tận dụng tốt nhất cả hai thế giới và mã hóa "giao diện người dùng" (nghĩa là khung chức năng mà người dùng thư viện của bạn sẽ gọi để mô tả hình học và các thuộc tính khác của vấn đề) trong Python để nhanh chóng thời gian quay vòng, sau đó viết thời gian chạy mô phỏng trong C ++.

Trên thực tế, tôi có thể sẽ chế giễu ngay cả thời gian chạy mô phỏng trong Python trước, sau đó thay thế nó bằng từng đoạn mã C ++. Cuối cùng, bạn có thể xem xét việc mã Python của bạn tạo nguồn C ++, được biên dịch và liên kết với thời gian chạy trực tuyến của bạn, để mô phỏng thực tế không cần phải gọi vào Python - chỉ trả về kết quả cuối cùng. Điều thú vị về thiết lập này là nó vốn đã nhanh nhẹn: bạn bắt đầu với giải pháp làm việc nhanh nhất và dễ dàng nhất, bạn sẽ tìm ra nhanh chóng những gì hoạt động và không hoạt động, và khi bạn có thứ gì đó bạn muốn, bạn có thể bắt đầu tăng tốc.

(Đây là cách trình giải ODE / DAE của Maple hoạt động, ngoại trừ sử dụng Maple thay vì Python. Tiết lộ đầy đủ: Tôi làm việc cho họ.)


1
+1. Một trong những điều tuyệt vời của Python là khả năng tránh xa "Pure Python" nếu cần.
Fomite

3

Bạn cũng có thể sử dụng Cython cho các thuật toán của bạn. Về cơ bản, Python có thêm thông tin loại cho một số biến cần "nhanh". Nó dịch mã Python thành mã C, sau đó có thể được biên dịch bởi trình biên dịch C yêu thích của bạn. Thêm cẩn thận thông tin loại này có thể làm cho mã của bạn nhanh hơn tới 150 lần so với mã Python ngây thơ.


2

Tôi nghĩ rằng có nhiều hơn cho câu hỏi này. Đầu tiên và trước hết, một nhà phát triển thường thích những gì anh ta / cô ta quen thuộc trừ khi có những lợi thế đáng kể (ví dụ như về năng suất, thời gian phát triển và các công cụ). Cá nhân, tôi ưu tiên làm việc hiệu quả (thời gian thường là nguồn lực khan hiếm nhất!) Và điều này ủng hộ các lựa chọn gần với cơ sở kinh nghiệm của tôi.

Có lẽ cũng có liên quan để đưa vào tài khoản là

3) Thời gian phát triển

  • bao nhiêu thời gian dành cho phát triển
  • khi nào kết quả của công việc sẽ được giao? và làm thế nào?
  • làm một mã đã tồn tại mà có thể thực hiện công việc? (tính độc đáo?)

4) Bảo trì

  • Có bao nhiêu (người) tài nguyên được dành cho bảo trì?
  • Có bao nhiêu người làm việc với mã?
  • Là mã được phát hành tại một số điểm? (tiêu chí?)
  • mã sẽ dựa vào các thư viện của bên thứ ba?

5) Vấn đề cấp phép

  • mã cho nghiên cứu là gì?
  • mã cho các ứng dụng thương mại?

6) Năng suất và yếu tố Vui vẻ (thường bị bỏ qua!)

  • Nơi nào có thể có năng suất cao nhất?
  • Nơi nào có thể có niềm vui phát triển nhất?
  • Bất kỳ cơ hội để trở thành một phần của mạng (xã hội)?

2

Điều này phụ thuộc vào việc mã của bạn có thể được viết dưới dạng:

some_library_specific_type grid;

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

hay đúng hơn phải được viết như một cái gì đó như thế này:

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

Trong trường hợp đầu tiên, chọn những gì bạn thích nhất để mã hóa; trong trường hợp thứ hai, không sử dụng bất kỳ ngôn ngữ kịch bản lệnh nào hoặc chuẩn bị chịu đựng thời gian thực hiện.


2

Như một hệ quả tất yếu cho câu trả lời của Allan (rằng thời gian dành cho nhà phát triển của bạn là tài nguyên quý giá nhất): Sử dụng những gì người khác đã làm. Bạn nói rằng bạn muốn phát triển một thư viện cho cơ học liên tục tính toán nhưng đã có một vài trong số đó lớn đến mức họ sẽ luôn có sẵn mọi thứ bạn cần. Hãy xem deal.II, ví dụ cho tất cả mọi thứ có thể được viết dưới dạng vấn đề phần tử hữu hạn, OpenFOAM cho động lực học chất lỏng hoặc PyCLAW / CLAWPACK cho các vấn đề hyperbol. deal.II, chẳng hạn, yêu cầu bạn lập trình trong C ++ nhưng trong thực tế, mức độ lập trình thường cao đến mức người ta có thể nói nó giống như một ngôn ngữ dành riêng cho tên miền cho mã FEM bằng cú pháp C ++.


2
Tôi chưa bao giờ bắt gặp một thư viện có mọi thứ tôi cần ...
Jack Poulson

Vâng, nhưng bạn có được điểm tôi cho là. Một số thư viện có "hầu hết mọi thứ" bạn có thể cần. Để chỉ trích dẫn một ví dụ mà tôi đặc biệt quen thuộc, một bộ giải phần tử hữu hạn trên các lưới 3d hoàn toàn tự thích ứng, chạy trên 10.000 bộ xử lý sử dụng các dòng mã deal.II và PETSc 126. Điều đó rõ ràng hơn không, nhưng thực tế nó là một con số rất nhỏ với sự phức tạp của những gì dưới mui xe.
Wolfgang Bangerth

Để chơi người ủng hộ của quỷ, việc chạy mã trên 10.000 lõi là chuyện nhỏ, nhưng việc làm cho nó có thể mở rộng là một vấn đề hoàn toàn khác. Không có nhiều điều kiện tiên quyết song song cho các phương trình không elip thậm chí có thể chạy hiệu quả trên 300 lõi.
Jack Poulson

Chắc chắn rồi. Nhưng ví dụ tôi trích dẫn thể mở rộng: math.tamu.edu/~bangerth/publications/2010-distribution.pdf .
Wolfgang Bangerth

Vì lợi ích của việc tiết lộ đầy đủ: Tôi là một trong những tác giả của cả bài báo và mã được tham chiếu ở trên, cũng như của thư viện deal.II nói chung.
Wolfgang Bangerth
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.