Herezh++

ok. J'ai tenu compte de ça en excluant le fichier Algo_Integ1D_2.cc dans le makefile. Et donc en gardant le #define dans le .h

J'ai fini par remporter la bataille avec un premier HZppfast64 compilé avec succès. Un seul vrai souci dans ce que je vais raconter ci-dessous.

1) concernant la norme C++ (option gcc : -std)

J'ai fini par trouver ce qui coinçait. Dans les makefile proposés sur Herezh_dev/, il y a l'option : -D__cplusplus=1
Il faut absolument la supprimer. Cette variable revient à indiquer un -std égal à 1. Cette variable est utilisée dans des lib standard du C++. A cause d'elle, mon option -std n'était pas prise en compte partout. A la place, certaines libs considéraient un équivalent : -std=1. Or certaines requièrent au minimum c++11.

Après suppression de cette option, j'ai pu compiler en prenant simplement le standard par défaut de gcc (c++17 dans mon cas).

2) Dans mon makefile, j'ai voulu éviter de lister un à un les répertoires à include -I et également éviter de lister un à un les fichiers .cc à compiler.
J'ai mis une instruction qui récupère automatiquement tous les répertoires de Herezh_dev/ à include + quelques rép ciblés pour les lib exterieures (muParser, etc...). Et ensuite j'y récupère automatiquement les fichiers .cc.

Je voulais plus de lisibilité dans mon makefile et éviter de passer à côté de certains fichiers si la liste n'est pas up-to-date. Mais le problème est que certains .cc ne sont pas nécessaires à Herezh et surtout certains d'entre-eux ne sont pas compilables (erreurs diverses).

Donc j'ai résolu en excluant les fichiers problématiques et en vérifiant qu'ils n'étaient pas nécessaires d'après la liste de .cc indiquée dans le makefile : Herezh_dev/fichiers_makefile/makefile_HZppfast_MPI (j'ai supposé que c'était le makefile le plus récent que tu avais archivé sur git).

J'en arrive à cette liste d'exclusion :
SRC_CC_EXCLUDE = $(SRC_DIR)/Util/Algo_Integ1D_2.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/ResRaid_MPI.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/Mecanique/Triangle/Met_triaMemb.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/Mecanique/Hexaedre/HexaLMemb.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/Mecanique/SFE/PoutSfe3.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/Mecanique/SFE/Sfeg.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/Mecanique/SFE/Met_Sfe2s2.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Elements/Mecanique/Biellette/PoutTimo.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Lecture/LectBloc_T.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Algo/GalerkinContinu/AlgoMixte/AlgoriMixte.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Util/externe/quartic.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/References/Lect_reference.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Resolin/Resolution_Condi/resol.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/Tableaux/Tableau_double.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/General/Distribution_CPU.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/comportement/Hyper_elastique/Hyper10.cc
SRC_CC_EXCLUDE += $(SRC_DIR)/comportement/Hyper_elastique/HyperDN.cc
SRC_CC_EXCLUDE += lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/qsort_type.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/icpre.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/diagpre.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/ilupre.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/ilupre_1.5.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/ilupre_double_1.5.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/ilupre_double.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/diagpre_double.cc
SRC_CC_EXCLUDE = lib_ex_pour_HZpp/Partie_2/algebre_lineaire/sparselib+/sp1_5c/src/icpre_double.cc

A noter que le fichier Elements/Mecanique/Triangle/Met_triaMemb.cc est très bizarre. On dirait un fichier venant de Windows avec des retour chariot <CR>. Le plus bizarre est qu'il est impossible de le lire avec un programme Perl.

3) Pour compléter le point 2), j'exclue également le répertoire Herezh_dev/Util/suites/.

Cette fois, je le fais de manière plus brutale. J'efface tout simplement (rm -rf) ce répertoire de Herezh_dev/ avant de lancer make.
En attendant de modifier mon makefile pour juste l'exclure.

Je suis également obligé de dupliquer le fichier Herezh_dev/Enumeration/Enum_suite.h en Herezh_dev/Enumeration/Enum_Suite.h. En fait, selon les endroits du code, il est parfois demandé sous la forme d'un #include Enum_Suite.h et parfois #include Enum_suite.h. Il faut donc une version avec et sans S majuscules.

4) J'en arrive à la vraie erreur qui me pose problème venant du fichier Herezh_dev/Elements/Mecanique/Deformation_gene/Deformation_2.cc

La compilation de ce fichier se déroule a priori correctement. Mais au moment de générer l'exécutable, j'ai une erreur avec le .o généré depuis ce .cc :

/usr/bin/ld : Herezh_dev/Elements/Mecanique/Deformation_gene/Deformation_2.o : dans la fonction « Deformation::Mise_a_jour_def_log(int, TenseurBB const&, TenseurHH const&, TenseurBB const&, TenseurHH const&) » :
Deformation_2.cc:(.text+0x353e) : référence indéfinie vers « Deformation::Cal_var_Logarithmique(TenseurBB const&, TenseurHH const&, TenseurBB const&, TenseurHH const&) »
/usr/bin/ld : Deformation_2.cc:(.text+0x355e) : référence indéfinie vers « Deformation::Cal_var_Logarithmique(TenseurBB const&, TenseurHH const&, TenseurBB const&, TenseurHH const&) »

Donc, un pb avec la méthode Cal_var_Logarithmique qui est utilisée à la fin du fichier Deformation_2.cc :

       switch (inter_pour_def_log->situation)
        { case 0:
            Cal_Logarithmique(gijBB_0,gijHH_0,gijBB,gijHH,variation_epsBB);
            if (!variation_epsBB) {inter_pour_def_log->situation = 1;}
            else                  {inter_pour_def_log->situation = 3;}
              break;
          case 1:
            // calcul éventuelle d'uniquement de la variation
            if (variation_epsBB)
              {Cal_var_Logarithmique (gijBB_0,gijHH_0,gijBB,gijHH);
               inter_pour_def_log->situation = 3;
              };
            break;
          case 2:
            // calcul éventuelle d'uniquement de la variation
            if (variation_epsBB)
              {Cal_var_Logarithmique (gijBB_0,gijHH_0,gijBB,gijHH);
               inter_pour_def_log->situation = 4;
              };
            break;
        };

Cette méthode est présente Herezh_dev/Elements/Mecanique/Deformation_gene/Deformation_2.h :

   // méthode qui calcule uniquement la variation du  tenseur logarithmique  par rapport aux déformations d'Almansi eps_{mn}
   // dHHHH_eHH_epsBB = d_e^{ij}/d_eps_{mn}
   // le calcul du tenseur lui-même doit déjà avoir été fait
   void Cal_var_Logarithmique (const TenseurBB & gijBB_0,const TenseurHH& gijHH_0
                           ,const TenseurBB& gijBB,const TenseurHH& gijHH);

Mais elle est seulement déclarée là sans être implémentée dans Deformation.cc.

J'ai réussi à supprimer cette erreur de compilation en commentant l'appel à Cal_var_Logarithmique dans Deformation_2.cc.
J'obtiens donc un exécutable HZppfast, mais on dirait qu'il manque quelque chose dans ces fichiers Deformation*.h et .cc

Autre point curieux :
La méthode Cal_Logarithmique est également appelée dans Deformation_2.cc (cf extrait du code dans le "case 0"). Il n'y a pas de pb de compilation mais je trouve étrange car on se retrouve dans la même config que Cal_var_Logarithmique.
Cette méthode est simplement déclarée dans le .h :

                      
   // méthode qui calcule le tenseur logarithmique "e" et sa variation éventuelle par rapport aux déformations d'Almansi eps_{mn}
   // dHHHH_eHH_epsBB = d_e^{ij}/d_eps_{mn}
   void Cal_Logarithmique (const TenseurBB & gijBB_0,const TenseurHH& gijHH_0
                           ,const TenseurBB& gijBB,const TenseurHH& gijHH
                           ,const bool variation_epsBB);

et n'est pas implémentée dans le .cc. Et pourtant pas d'erreur de compilation. Si je cherche cette fonction dans les sources d'Herezh, il se trouve qu'elle existe également dans Herezh_dev/Elements/Mecanique/Deformation_gene/Deformation_log.cc :

    // fonction qui calcule le tenseur logarithmique et sa variation éventuelle
    // par rapport aux ddl
void Deformation::Cal_Logarithmique 
                     (const TenseurBB & gijBB_0,const TenseurHH& _gijHH_0,Tableau <TenseurBB *> & d_epsBB
                      ,const TenseurBB& _gijBB,const TenseurHH& _gijHH,TenseurBB & _epsBB
                      ,const Tableau <TenseurBB *>& _d_gijBB,bool variation)
{// dimensions                                                     
 int dima = gijBB_0.Dimension(); // dimension des tenseurs
etc...

donc a priori, c'est là qu'il va la chercher. Je ne comprends pas le fonctionnement des divers fichiers Deformation* du répertoire Elements/Mecanique/Deformation. Le fichier Deformation_log.cc n'a pas de .h et il définit une fonction Deformation::Cal_Logarithmique que Deformation_2.cc est capable de trouver malgré aucun appel à quelque chose du genre #include Deformation_log.h en début de fichier Deformation_2.cc.

Au final, comme je compile chaque objet avec tous les rép -I dans gcc, j'ai l'impression que Deformation_2.o arrive quand même à trouver une référence vers Deformation::Cal_Logarithmique car elle existe dans Deformation_log.cc tout en étant déclarée dans Deformation.h.

Mais ce n'est pas le cas de Cal_var_Logarithmique qui est une méthode qui n'apparait nulle part ailleurs que Deformation.h.

dernière info :

j'arrive à compiler un exécutable qui fonctionne sur un exemple. Mais le calcul se termine systématiquement par un segmentation fault. Aucune idée de comment résoudre ça. J'ai retenter une compilation en ne gardant que les fichiers .cc présent dans un makefile de Herezh_dev. Sans amélioration

oui, j'ai un .CVisu. J'ai réessayé en prenant une version antérieure aux modifs de sortie différenciées. J'ai compilé une version 7.058 mais toujours la même erreur à la fin :

======================================================================
INCREMENT DE CHARGE : 119  intensite 1.00000000  t= 1.00000000 dt= 0.00040202
======================================================================
       >>>> temps fin (1.00000000) atteint <<<<< 1.00000000

 temps_user:0/00:00:00.90 system:0/00:00:00.29 reel:0/00:00:00.78

 =============================================================
 |                     fin HEREZH++                          |
 =============================================================
Incident de segmentation (core dumped)

J'ai bien peur que le problème vienne de mon côté.

Je vais faire d'autres tentatives en reprenant plus fidèlement ton makefile. Notamment, je n'ai repris exactement la fin (que je ne comprends pas trop) :

# partie pour fabriquer les dependances "http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/" 

DEPDIR := $(REP_OBJET)/.d
$(shell mkdir -p $(DEPDIR) >/dev/null)
DEPFLAGS = -MT $@ -MMD -MP -MF $(DEPDIR)/$*.Td
COMPILE.cc = $(CC) $(DEPFLAGS) $(CC_OPTIONS)  -c
POSTCOMPILE = mv -f $(DEPDIR)/$*.Td $(DEPDIR)/$*.d

%.o: %.cc    $(DEPDIR)/%.d
                                $(CC) $(DEPFLAGS) $(CC_OPTIONS) $(INCLUDE) -o $(REP_OBJET)/$@ -c $< 
                                $(POSTCOMPILE)

listes_SRC:
    echo $(LISTE_DE_CC) $(SRC) $(LISTE_DE_DEPEND) $(VPATH)

listes_path:
    $(VPATH) $(vpath)    

liste_INCLUDE:
    echo $(INCLUDE) 

#total_dependance = $(patsubst %,$(DEPDIR)/%,$(dependance))    
liste_total_depend:
    @echo  $(patsubst %,$(DEPDIR)/%.d,$(basename $(SRC))) 
    #$(total_dependance) 

liste_objet:
    @echo $(OBJ)    

liste_objet_pre:
    @echo $(P_OBJ)

# .PRECIOUS: suivi d'une cible, indique que la cible ne doit pas être détruite
# si le make plante !, cela permet de concerver les dépendances déjà construite
$(DEPDIR)/%.d: ;
.PRECIOUS: $(DEPDIR)/%.d

# -include : veut dire d'inclure la suite, avec le moins cela indique que si la suite
# n'existe pas, il n'y a pas de pb généré
# patsubst -> veut dire substituer : l'expression régulière qui suit
# $(basename $(SRCS)) : le nom de base sans le .quelquechose c-a-d ici sans le .cc
# %,$(DEPDIR)/%.d, $(chose)  -> remplace un nom de $(chose) par $(DEPDIR)/<le nom>.d
# donc si je comprends bien la ligne
# on inclue tous les fichiers  makefile situés en  $(DEPDIR)/
# normalement le make fait toutes ses inclusions à la fin de sa lecture
-include $(patsubst %,$(DEPDIR)/%.d,$(basename $(SRC)))

J'utilise une version allégée de tes DEPFLAGS en ne prenant que les options -MMD -MP dans ma compilation gcc. Mais en vrai, je ne pense pas que le problème vienne de là. Si ma méthode posait problème, j'aurais plutôt des pb au moment de la compilation.