O czym nie napisaliśmy

Jest jeszcze kilka modułów w PETSc, które można wykorzystać w programowaniu solverów równań cząstkowych.
Oprócz SLESu i SNESu, mamy także moduł TS (ang. time stepping), z implementacją metod różnicowych rozwiązywania wielkich układów równań różniczkowych zwyczajnych powstałych na przykład po dyskretyzacji (względem zmiennej przestrzennej) równania parabolicznego. Dodajmy, że PETSc ma możliwość wykorzystywania w tym celu także biblioteki zewnętrznej PVODE autorstwa A.Hindmarsha i in., będącej równoległą wersją biblioteki CVODE (dość wyrafinowanych metod wielokrokowych).

PETSc posiada wiele opcji profilowania kodu. Jedną z nich można uruchomić dodając do linii komend -petsc_log. Użytkownik ma wtedy możliwość sprawdzenia, ile czasu CPU (lub jaki procent obliczeń) pochłania wybrany fragment kodu. Można też śledzić sposób wykorzystywania pamięci, obciążenie poszczególnych procesorów, itp. Poza wydrukiem tekstowym, jest także możliwość obejrzenia przebiegu pracy programu w okienku graficznym. Przyznajemy, że trochę żałujemy, iż do tej pory nie zaczęliśmy w pełni wykorzystywać tych opcji.

Dodatkowo, dla prawdziwych i porządnych programistów-profesjonalistów, PETSc daje możliwość podłączenia debuggera - zarówno dopiero po wystąpieniu błędu, jak też od początku pracy programu. Debugger może się podłączać na każdym procesorze w osobnym okienku - każdy, kto doświadczył koszmaru programowania równoległego, wie, jakie to może być ważne. I znów, jako nieprofesjonaliści, nie korzystamy z tej sposobności, gorzej, nawet nie bardzo wiemy jak obsługiwać dbx. Powód jest prozaiczny: po prostu do tego stopnia zepsuci jesteśmy pięknymi, przyjaznymi i naprawdę porządnymi debuggerami ze środowiska MS Windows (a nawet DOS!), że uczenie się topornego, tekstowego dbx'a wydaje się nam niepotrzebną męką: porównanie dbx'a i debuggera dla (powiedzmy) Visual C++ wypada tak, jak porównanie edytora vi z (powiedzmy) MS Word. Dlatego wolimy poczekać, aż pojawią się porządne debuggery także w Unix'ie (albo, o zgrozo, Windows wyprze i ten system...). Niemniej, osoby chętne, a tym bardziej pragnące pisać duże aplikacje, zachęcamy do wykorzystywania dostępnych debuggerów: jest to inwestycja, która prędzej, czy później, sowicie się opłaci!

Dalej, PETSc dysponuje pewnymi możliwościami graficznymi, ale szczerze powiedziawszy, lepiej nie używać procedur PETSc do wizualizacji: sensowniej jest wykorzystać zewnętrzne programy wizualizacji danych, na przykład AVS, Vigie, czy nawet Matlab. Warto natomiast skorzystać z grafiki PETSc dla obserwacji zachowania własnych obiektów lub procedur. Można w szczególności napisać własne - lepsze! - przeglądarki obiektów itp.

PETSc jest tworzone jako biblioteka otwarta. Jak już wspominaliśmy, PETSc może korzystać z zewnętrznej biblioteki PVODE; jest też port do kilku innych. Między innymi, do bibliotek równoległych BlockSolve95 i SPAI, z dodatkowymi solverami równań liniowych oraz do biblioteki matematycznej IBM ESSL; do Matlaba - dla wizualizacji i ewentualnego postprocessingu numerycznego; do narzędzia wizualizacji trójwymiarowych obiektów przy użyciu VRML (virtual reality), itd.

Najistotniejszą cechą PETSc, która czyni z niej naprawdę poważne narzędzie, jest przejście na programowanie równoległe na wyższym poziomie. To właśnie, w połączeniu z dostępnością podstawowych solverów i narzędzi numerycznych, stanowi prawdziwą smakowitość PETSc! Dlatego zamierzamy w ewentualnej drugiej części tego podręcznika przystępnie wyłożyć generalne zasady programowania równoległego oraz wykorzystania PETSc do (w miarę bezbolesnego) pisania efektywnych aplikacji równoległych, służących rozwiązywaniu równań różniczkowych cząstkowych. Na razie zachęcamy do własnego eksperymentowania z programami równoległymi, wykorzystującymi MPI do uruchamiania jednej aplikacji na kilku stacjach roboczych, co może pozwolić przede wszystkim na rozwiązywanie dużo większych zadań dyskretnych.

Zachęcamy do uczenia się PETSc. To naprawdę szybsze, niż kodowanie wszystkiego od zera...
Podsumowanie SNESu
Spis treści
Bibliografia
 


Copyright (C) Marcin Bojko i Piotr Krzyzanowski, 1998.
Ostatnia modyfikacja: 12.X.98.