]> https://gitweb.dealii.org/ - dealii-svn.git/commit
Join two loops, which is actually necessary, since we need some
authorwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 17 Sep 2002 19:12:56 +0000 (19:12 +0000)
committerwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 17 Sep 2002 19:12:56 +0000 (19:12 +0000)
commit770dd881af645d694123a67c472f587aec7b906d
tree6bc0f84b0b8bacbd76c1a6efd01e9366a1d92d86
parent41827d93893c568cad9a7ca6b8f5debaf610f056
Join two loops, which is actually necessary, since we need some
information from the start of the loop in the second loop.

The mail that explains this is (sorry, only german):

---------------------------------
der shapes-Test geht bei mir fehl, und der Grund ist dass in einem
FESystem die _Werte_ nicht von den Basiselementen kopiert werden. Jetzt
habe ich diesen Teil gestern geaendert, so dass das wohl an mir liegt,
aber ich weiss nicht, warum es vorher funktioniert hat.

Also, wie haben ein Q2xQ3 FESystem. Fuer beide muss update_values nicht
in update_each gesetzt werden, weil sich die Funktionswerte ja nicht
aendern. Aber: irgendwann muss es halt mal ins FESystem kopiert werden.
Wo/wann passiert das?

Wenn ich naemlich das erste Mal in FESystem::compute_fill lande (von
FESystem::reinit auf der ersten Zelle), dann habe ich hier (das ist der
alte Code, der neue ist etwas anders, aber im wesentlichen der selbe):

      for (unsigned int base_no=0, comp=0; base_no<n_base_elements(); ++base_no)
        {
          const FiniteElement<dim> &base_fe=base_element(base_no);
          typename FiniteElementBase<dim>::InternalDataBase &
            base_fe_data = fe_data.get_fe_data(base_no);
          const UpdateFlags base_flags(dim_1==dim ?
                                       base_fe_data.current_update_flags() :
                                       base_fe_data.update_flags);
[da FEValues ist hier dim_1==dim]

[... und weiter unten beim kopieren:]
                  if (base_flags & update_values)
                    data.shape_values(system_index, point)=
                      base_data.shape_values(k,point);

Hier enthaelt base_flags kein update_values mehr, so dass die Werte nicht
kopiert werden.

Da das die einzige Stelle in fe_system ist, wo data.shape_values gesetzt
werden, macht mich das ganze ein bisschen stutzig: da kann doch nur was
kopiert werden, wenn die base_flags fuer diese Zelle update_values
enthalten. Also, nachgeschaut:  base_fe_data.update_once hat
update_values, aber base_fe_data.first_cell==false...

Ah, jetzt sehe ich auch was passiert: vorher hatten wir nur eine einzige
Schleife ueber die Basiselement, und in der haben wir die Flags geholt,
das Element aufgefordert sich zu initialisieren, und gleich kopiert.

Jetzt haben wir zwei Schleifen: einmal initialisieren, dann kopieren. Ich
weiss damit auch, wie ich das Problem loesen kann (allerdings erst nach
dem Mittagessen), aber deshalb mal die Frage: ob wir auf dem ersten
Element sitzen, ist eigentlich nicht damit abgehakt, dass sich das
Basiselement initialisiert hat. Trotzdem machen alle Elemente das am Ende
des ersten Aufrufs von fill_fe_*_values. Ist das der richtige Platz?

Und: ganz kurios macht das das FESystem, naemlich irgendwo in der Mitte
der compute_fill-Funktion (die von den fill_fe_*_values Funktionen
aufgerufen wird), und zwar  *im Innern eines Blocks, der in
  if (flags & (update_values | update_gradients))
steht*!! Das will mir eigentlich nicht ganz richtig scheinen...

Ich werde nachher mal einen vorlaeufigen Fix einchecken, damit es
wenigstens wieder geht, aber wuerde trotzdem gerne Eure Meinung dazu
hoeren!
-------------------------------------

...and...

-------------------------------------
Zu ersterer: die update_flags werden auf eine absolut undurchschaubare Art
und Weise gesetzt, geaendert, von irgendwelchen Funktionen zurueckgegeben,
etc. Ich habe bis heute nicht verstanden, welche Funktion ich denn wann
aufrufen muesste, und dass Flags wie first_cell waehrend einer laufenden
(aeusseren) Funktion beeinflussen, was man von current_flags
zurueckbekommt, passt da sehr gut ins Bild.

Ich meine, mal ehrlich: ist es logisch, dass wenn ich current_update_flags
aufrufe, dann fill_fe_values, dann noch mal current_update_flags, dass das
Ergebnis dann ein anderes ist? fill_fe_values ist eigentlich ein typisches
Beispiel einer Funktion, die _Daten_, nicht den _Zustand_ eines Objektes
aendert/aendern sollte! Ich glaube, die Funktion hat bisher eigentlich nur
aus Zufall funktioniert, weil eine lokale Variable oben in einem Block
deklariert und definiert wurde, waehrend sie erst unten benutzt wurde.
Haette man die Deklaration dahin getan, wo die Variable das erste Mal
benutzt wird, dann haette das schon nicht mehr funktioniert.....
--------------------------------

git-svn-id: https://svn.dealii.org/trunk@6443 0785d39b-7218-0410-832d-ea1e28bc413d
deal.II/deal.II/source/fe/fe_system.cc

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.