[Dune] Re: HAVE_MPI_CC

[Andreas Dedner]

Hallo,
es gibt ein kleines Missverstaendniss mit dem define HAVE_MPI,
welcher zu Problemen mit ALUGrid fuehrt. Hier sind die
Gruende, warum wir das so gemacht haben, wie es jetzt drin ist:
1) yaspgrid:
   Angenommen man will nix mit parallel machen, sondern nur
   seriell rechnen, wobei auf dem System ein mpi existiert,
   d.h. HAVE_MPI ist 1.
   Dann muss ich im Konstruktur als erstes Argument ein
   MPI_COMM_WORLD reinschreiben (ohne zu wissen was das ist).
   Zusaetzlich muss ich auch die MPI_LIBS einbinden, sonst
   gibts (zumindest bei uns) Linkerfehler.
2) alugrid:
   In der alu-lib sind sowohl ein parallel wie auch ein
   serielles Gitter enthalten (von einander abgeleitet).
   Um overhead zu vermeiden, wollen wir fuer serielle Laeufe auch
   nur ein serielles Gitter anlegen. Also muss im Konstruktor
   unterscheiden werden, ob MPI benutzt wird, oder nicht.
   Wir koennten das wohl auch ueber die size() Methode der
   CollectiveComm. Klasse zur Runtime entscheiden -
   bei der jetzigen Version muss die Unterscheidung zur Compile-Zeit
   passieren. Also das geht. Bleibt (wie bei Yaspgrid) der Konstruktor,
   wo wir fuer serielle Lauefe nix mit mpi drin haben wollen.

Im DGFParser hab ich versucht (mit einem als Hack ausgewiesenen Hack!)
MPI_Comm und MPI_COMM_WORLD auf irgentwas zu setzen, falls
mpi nicht benutzt wird - hier ist es sicherlich falsch
MPI_Comm = int anzunehmen, also brauch ich noch ein
typdef int MPI_Comm, falls mpi nicht benutzt wird.
Dann hat der Konstruktor einen default
Parameter und wenn mir MPI_COMM_WORLD reicht, brauch ich
im meinem Hauptprogramm nirgens zu unterscheiden, ob parellel oder
seriell gearbeitet werden soll - wenn der Communicator was anderes
sein soll, weiss man offenbar, was man tut, und packt rein was man
braucht. Allerdings reicht HAVE_MPI zur Unterscheidung nicht aus.

Ist alles nicht toll; aber zu verlangen, dass der Anwedner eines
seriellen Codes irgentwelche MPI Sachen einsetzen muss - im
Konstruktor und beim Compilieren/Linken, fanden wir hier
irgentwie auch unbefriedigend.

Unsere Loesung war HAVE_MPI_CC zu benutzen, welches aber offenbar
nur von mpich gesetzt wird...
Vorschlag:
Koennte man beim Setzen der mpi Flags im configure nicht einfach so
was wie USING_MPI=1 zu den MPICCFLAGS hinzunehmen -
unabhaengig von der MPI Version? Dann wuerden
die MPI Sachen nur benutzt werden, wenn die FLAGS auch benutzt
werden.

Gruss Andreas


Christian Engwer wrote:
> Hallo Andreas,
> 
> 
>>ich dachte ich schreib dir mal direkt eine Konzeptanfrage
>>zu den defines wie etwa HAVE_MPI:
>>der Grund warum wir bei ALU inzwischen HAVE_MPI_CC
>>abfragen und nicht HAVE_MPI, ist der folgende:
>>HAVE_MPI wird auf 1 gesetzt im config.h, falls
>>mpi gefunden wird unabhaengig davon, ob mpiCC
>>benutzt wird und noch wichtiger,
>>unabhaengig davon, ob die MPI_CPPFLAGS eingebunden werden.
>>Dadurch bricht das compilieren staendig ab auch wenn man
>>das Parallele Interface von ALU gar nicht benutzt.
>>HAVE_MPI_CC wird in den MPI_CPPFLAGS gesetzt und garantiert
>>dadurch wenigstens, dass etwa mpi.h gefunden wird
> 
> 
> Genau das eben nicht. Ich habe bei mir MPI, aber es wird kein
> HAVE_MPI_CC gesetzt.
> 
> 
>>- und
>>wahrscheinlich auch die libs gelinkt werden.
>>Auch YASPGRID ist schwer zu benutzen, wenn bei configure
>>CXX=mpiCC nicht angegeben wird.
> 
> 
> So wolltet Ihr Dune sowieso nicht kompilieren müssen.  Es gibt extra
> die Unterscheidung zwischen mpi Headern/Libs und dem Compiler. Es
> gibt die Compiler CC und CXX und es gibt die MPI Header/Libs
> MPI_CPPFLAGS, MPI_LDFLAGS und MPI_LIBS.
> 
> Als Compiler gibt man sowas wie CC=gcc und CXX=g++ an. Das configure
> sucht dann die passenden Compiler parameter und Libs für MPI raus.
> 
> Bei MPI wird _extra_ nicht das C++ Interface verwendet, da man sonst
> für verschiedene Compiler imer eine extra MPI Installation
> braucht. Das macht die Benutzung sehr aufwendig, ohne dass man einen
> nennenswerten Vorteil hätte.
> 
> Es geht dann noch weiter... HAVE_MPI_CC ist ein internes define einer
> speziellen MPI Implementierung. Auf sowas sollte also man sowieso
> nicht setzen. Un es ist ja auch nicht aus der Luft gegriffen, dass es
> das Probleme gibt, sondern es compiliert bei mir ja definitiv nicht.
> 
> 
>>Das selbe Problem tritt bei den anderen Packages auch auf:
>>HAVE_GRAPE ist 1 falls grape gefunden wird, in den Makefile
>>muss ich dann unbedingt dran denken die entsprechenden
>>CCFLAGS einzuhaengen.
> 
> 
> Das stimmt nicht ganz. Die Situation ist hier eine andere, da man sich
> explizit für Grape entscheidet. Du weißt, ob dein Programm die grape
> header inkludiert oder nicht.
> 
> 
>>Das loest man vermutlich mit
>>den ALL_PKG_CPPFLAGS ganz elegant. Da sind allerdings die
>>MPI Flags nicht dabei und das ist auch sinnvoll. ALU erzeugt
>>etwas Overhead, wenn man die Paralleleversion verwendet auch
>>im Seriellen, daher wollten wir einen Unterscheid machen zwischen
>>seriellem Gitter und parallelem.
> 
> 
> Wieso macht Ihr es nicht so, dass Ihr im configure Test überprüft, ob
> Alu parallel, oder sequentiell übersetzt wurde? Dann könntet Ihr
> einfach ein HAVE_ALU_PARALLEL setzen oder eben nicht und damit alles
> machen, was Ihr im Moment mit dem kruden Hack versucht.
> 
> 
>>Erklarst du mir noch mal
>>genauer, was gegen HAVE_MPI_CC spricht?
> 
> Siehe oben... es klappt halt einfach nicht.
> 
> Wo wir gerade schon bei kruden Hacks sind... mir ist da noch was im
> Gridreader aufgefallen... Ihr habt dort ein 
> #define MPI_COMM_WORLD -1
> Und geht davon aus, dass MPI_COMM ein int ist. Das ist nicht
> portabel. Es ist nirgendwo festgelegt, dass MPI_COMM ein int ist und
> ist es auch nicht immer. Es gibt schon in common eine MPI Abstraktion
> im mpicollectivecommunication.hh, so dass man das YaspGrid z.B. mti
> und ohne MPI verwenden kann. Wäre das nicht eine geschickte Sache, um
> des Parser von diese mdefine Wust zu befreien? Sollten noch Methoden
> in der Communicate Klasse fehlen, könnte man diese ja auch noch
> nachziehen.
> 
> Eine Sache verstehe ich sowieso nicht! In dgfparser/gridtype.hh setzt
> Ihr typedefs für GridType. Wieso? Verstehe ich das richtig und es nicht
> möglich z.B. ein YaspGrid _und_ ein AlbertaGrid zu instantieren?
> Die MacroGrid::Impl ist ja schon Template parametrisiert. Dann sollte
> es doch eine Kleinigkeit sein das GridType typedef loszuwerden. Oder
> übersehe ich da etwas?
> 
> Ich hoffe das klärt deine Fragen,
> tschüß Christian
> 
> PS: Eigentlich finde ich es besser solche Sachen auf der Liste oder im
> Flyspray zu klären, dann habe alle etwas davon und man kann nachlesen,
> was das Problem, die Argumente, etc. waren.