story ================================================================================ en vue de la VERSION 1.3 Stable : ================================================================================ Vérifier que 2/ Certains des bugfix croco qu'on traine depuis 2 ans ont été corrigés par croco dans cette branche OCEAN/wetdry.F OCEAN/zoombc_2D.F OCEAN/set_nudgcof.F Error si agrif sans pisces dans AWA sur IRENE et IRENE-AMD avec intel 19 et 20 : the_array_USPONGE_has_value_-2_which_is_less_than_the_lower_bound_of_-1/ Après MERGE: - close issue 64 - close branch croco_piscesv2 (Rachid 16 Mars 2020) Liste des commits dans Bilan annuel ================================================================================ Sur BENGUELA_VHR ================================================================================ -------------------------------------------------------------------------------- bug AVERAGES -------------------------------------------------------------------------------- sedstp.F90 -#if ! defined XIOS +#if ! defined XIOS && defined AVERAGES CALL set_avg_sed ilc = 1+iic-ntstart ! number of time step since restart IF ( iic > ntstart .AND. mod(ilc-1,nwrtsedpis_avg) == 0 .AND. wrtavg(indxTime) ) THEN clés AVERAGES mais pas HISTORY? OUI! le HISTORY n'a pas de clé car il est activé par défaut. on peut débrancher ou c'est le T/F dans croco.in? ... mais surtout XIOS qui affrachi de tout ça. -------------------------------------------------------------------------------- Si undef MPI => MPI_COMM_WORLD?? -------------------------------------------------------------------------------- cd /home3/datawork/chourdin/CVTK/ln_ironsed_False/gfortran/BRYPISCES22 vimdiff serial_BRYPISCES22.log mpi_4_BRYPISCES22.log Pas forcément normal mais le principe: MPI_COMM_WORLD se charge de la communication entre les procs pour croco. Mais quand XIOS ou OASIS ou WRF... alors XIOS prend en charge la répartition des procs. => MPI_COMM_WORLD devient ocean_grid_comm ou quelque chose comme ça. Pas de quoi s'inquiéter à priori -------------------------------------------------------------------------------- AGRIF_2_WAY imposé à false si AGRIF false (dans cppdefs_dev.h) -------------------------------------------------------------------------------- Bug fix in wetdry.F : test AGRIF is missing for AGRIF_2WAY case Par défaut AGRIF_2_WAY est à false. Donc pas besoin de l'imposer à false dans cppdefs_dev.h si AGRIF est false. C'est en fait qu'avec l'environnement pulsation je laisse AGRIF_2_WAY à true si je mets AGRIFZ=0 Ajouter donc un if AGRIFZ=0, AGRIF_2_WAY=false -------------------------------------------------------------------------------- diagnostic.h -------------------------------------------------------------------------------- common OK? common /diag_TXadv/TXadv - & /diag_TYadv/TYadv - & /diag_TVadv/TVadv - & /diag_THmix/THmix - & /diag_TVmix/TVmix + common /diag_TYadv/TYadv + common /diag_TVadv/TVadv + common /diag_THmix/THmix + common /diag_TVmix/TVmix #ifdef DIAGNOSTICS_TSVAR - & /diag_TVmixt/TVmixt + common /diag_TVmixt/TVmixt # endif - & /diag_TForc/TForc - & /diag_Trate/Trate + common /diag_TForc/TForc + common /diag_Trate/Trate Rachid ne sait pas trop car pas très pro du fortran 77 mais pas de problème pour le commiter. segmentation fault de pierre sur char length? Mais pas même routine. test sur AWA mais laisser si probleme de depassement de tableau!!! ... cf ci dessous. -------------------------------------------------------------------------------- listing x 4 en monoproc -------------------------------------------------------------------------------- si NP_XI=1, & NP_ETA=4 en mon proc, listing x 4 dans read_inf.F ! Title ! if (keyword(1:kwlen).eq.'title') then call cancel_kwd (keyword(1:kwlen), ierr) read(input,'(A)',err=95) title lstr=lenstr(title) MPI_master_only write(stdout,'(/1x,A)') title(1:lstr) Pourquoi NPP à 1? dans test SERIAL CVTK diff param.h.MPI param.h.SERIAL 221c221 < parameter (NP_XI=1, NP_ETA=4, NNODES=NP_XI*NP_ETA) --- > parameter (NP_XI=1, NP_ETA=4, NNODES=NP_XI*NP_ETA) 229c229 < parameter (NSUB_X=1, NSUB_E=NPP) --- > parameter (NSUB_X=1, NSUB_E=1) 236c236 < parameter (NSUB_X=1, NSUB_E=NPP) --- Rachid a déja eu ce problème. Sans doute en lançant le monoproc avec mpirun ... OUI !! Pulsation lance le monoproc avec le même EXEC (mpirun croco.exe au lieu de ./croco.exe) -------------------------------------------------------------------------------- TESTS CVTK: mono = 2x2 mais pourtant volume d'eau différent? -------------------------------------------------------------------------------- cd /home3/datawork/chourdin/CVTK/ln_ironsed_False/gfortran/BRYPISCES22 vimdiff serial_BRYPISCES22.log mpi_4_BRYPISCES22.log Ca n'est qu'un diag. Différence liée sans doute à la façon de faire la somme. Mais ça n'est qu'un diag donc pas d'inquiétude à priori. -------------------------------------------------------------------------------- TESTS CVTK: différence ifort / gfortran? Simple et double précision? -------------------------------------------------------------------------------- grfortran : "-O0 -g -fdefault-real-8 -fdefault-double-8 -fbacktrace -fbounds-check" # debug jobcomp CVTK Oct 2022 ifort : "-check bounds -fpe0 -traceback -g -O0 -ftrapuv -72 -fno-alias -i4 -r8 -fp-model precise -mcmodel=medium" # debug Steph Mars 2021 cd /home3/datawork/chourdin/CVTK/ln_ironsed_False vimdiff gfortran/BRYPISCES22/serial_BRYPISCES22.log ifort/BRYPISCES22/ Rachid pense que les options sont les mêmes . Mais personne n'a regardé ça dans croco pour l'instant. On devrait quand même avoir les mêmes résultats... -------------------------------------------------------------------------------- TESTS CVTK: perfrst PISCES ... fonctionnement? -------------------------------------------------------------------------------- Plante mais lignes identiques! BUGBIN = t step3d 0 1 1 1 1 1 0.231496541185E+04 0.231496541740E+04 0.554832467969E-05 res=BUGBIN = t step3d 0 1 1 1 1 1 0.231496541185E+04 0.231496541740E+04 0.554832467969E-05 check [Restartability failed] Fonctionnement? une simu d'un coup et une autre avec un restart au milieu? En 2x2 procs? # Not needed # FLAG_OPENMP=1 ; FLAG_MPI=1 # NBPROCS_X=2 # NBPROCS_Y=2 # NBPROCS=$(( $NBPROCS_X * $NBPROCS_Y )) En fait les tests PERFRST sont très récents. Pas certain même qu'il fonctionne bien. Pour CVTK c'est vraiment Gildas et Rachid. Mais pour PERFRST c'est vraiment Gildas. Voir avec lui. Pas prioritaire parce que plus important de s'occuper de la reproductibilité MPI d'agrif/pisces Mais ça vaut le coup de voir si ça n'est pas juste un problème de script puisqu'il s'arrête sur les mêmes valeurs. Le principe est bien: Une simu Puis une deuxième avec un restart intermédiaire. CVTK compare les tableaux comme pour la reproductibilité MPI et ils peuvent diverger après le second restart (si la repro MPI est OK au préalable) -------------------------------------------------------------------------------- TESTS CVTK: PISCES AGRIF -------------------------------------------------------------------------------- - test BRYPISCESAGRIFF22 BUGBIN = t prestep3d 0 0 0 0 0 1 NaN NaN NaN res_mpi=BUGBIN = t prestep3d 0 0 0 0 0 1 NaN NaN NaN check mpi [Parallel reproducibility failed] Est ce que Les options de compilation initialisent à NaN? Non. Ni dans CVTK ni en général. Ils avaient essayé comme dans NEMO mais trop dur à faire. Laissé pour l'instant. Est ce que CVTK s'arrête s'il détecte un Nan? Il ne sait pas s'il s'arrête à cause du Nan ou parce que les valeurs ne peuvent être comparées. Mais à priori c'est bien que CVTK prévient s'il y a des NaN Si oui, ça veut dire qu'il n'y a aucun Nan dans le test AGRIF1W22 et AGRIF2W22 Oui c'est ça à priori. remarque: les test croco agrif sans pisces 1 way et 2 way passent (AGRIF2W22 AGRIF1W22) et en plus il passe avec FLAG_OPENMP=1 -------------------------------------------------------------------------------- ATLAS et sorties graphiques -------------------------------------------------------------------------------- J'ai cru comprendre que tu avais fait des choses à ce sujet. Pour CVTK? En python? En ligne sur gitlab croco? Oui mais en matlab. Il y a un plot pour chaque cas analytique. C'est dans TEST_CASES du tronc croco. Par exemple plot_basin.m pour le test croco.in.Basin Mais ni plot ni croco.in pour BENGUELA ================================================================================ EST CE QU'ON MERGE MAINTENANT? ================================================================================ sur master? Oui tout de suite. Et puis on essaie d'avancer encore et on ajooute après tant que la release 1.3 n'est pas faite. Puis sur release? Non. On laisse faire. Ils vont voir avec Swen Ou est ce qu'on continue à nettoyer? Si on merge maintenant, quid des tests? BRYPISCES22 & BRYPISCES14 OK OUI Mais perfrst PISCES Fail!! Si problème de script et résolu, oui, sinon non. BRYPISCESAGRIF22 ... pour plus tard. C'est quoi les milestones PISCES? Normalement c'est pour des notions de temps. Mais ils s'en servent comme des items (MUSTANG, PISCES...) squash message : repro MPI OK for PISCES and PISCES AGRIF ================================================================================ Listing aux espaces aléatoires qui gènent les vimdiff entre 2 output.txt de simus ================================================================================ p4z_opt_init : ~~~~~~~~~~~~ Namelist : nampisopt Default value for the PAR fraction parlux = 0.430000000000000 trc_oce_rgb_read : optical look-up table read in kRGB61.txt file ~~~~~~~~~~~~~~~~ Il ne sait pas d'où ça vient. A regarder. NEWS!!!!!!!!!!!!! Pas de problème de write avec gfortran!!!!! Ca serait le format libre qui pose problème avec ifort! Et pas le HPC. Les 2 tests sur DATARMOR avec ifort et gfortran sont explicites. vi serial_BRYPISCES22.log ================================================================================ CVTK en interractif sur HPC et DATARMOR: ================================================================================ Comment récupérer la sortie d'écran?? avec les couleurs. Quel format? sur INRIA : plusieurs machines. Comment gèrent ils les .gitlab-ci.yml ... si parametres différents... comme ifort/gfortran... Comme il faut commiter pour lancer gitlab-runner on perd la trace des modifs avec git status! Rachid voit très bien de quoi je parle. Il a été confronté au même problème pour les gens qui veulent tourner en local sur leur machine. Pas de solution. Comment faire l'équivalent des modules pour aller chercher FC MPIF90 et NETCDF ? Moi je mest les modules dans le ..gitlab-ci.yml ================================================================================ jobcomp ================================================================================ Options de compilation en fonction de la plateforme et du compilateur. - Faire des jobcomps spéciaux par Centre de calculs... comme des archs jobcomp.IRENE jobcomp.JEANZAY Avec les modules qui vont bien... (comme dans scripts pulsation) Même si pas tenu à jour tout le temps, que l'utilisateur puisse partir d'un jeu d'option déjà utilisé pour la machine... Rachid dit que le jobcomp est pourri mais que Marchesiello trouve ça génial. Rachid avait ajouté une possibilité de mettre un ENV... mais comme environnement pulsation pour nous on laisse. ================================================================================ Bug DAIGNOSTIC_TS de Pierre ================================================================================ commit -m "bugfix in diagnostic.h : replacing & (carriage return) by common" Plante avec pisces Sur IRENE-Skl plante à la compilation =>. Modif sur les commons plante à l'exécution => motif longueur chaine une de caractère. Dans trc.F90 /ccc/work/cont005/gen1140/chabertp/wd/can11sen2_croco/exp/c11s2cp_idealwindruns_shading_longrelaxation_ensemble_diabio_budgetsSMS/compile/croco dans cppdefs.h, activer DIAGNOSTICS_TS & DIAGNOSTICS_TS_MLD (diagnostique intégré sur la couche de mélange). # define DIAGNOSTICS_TS # undef DIAGNOSTICS_UV # ifdef DIAGNOSTICS_TS # undef DIAGNOSTICS_TS_ADV # define DIAGNOSTICS_TS_MLD # endif sur IRENE et la config can11sen2 de Pierre: (mail de Pierre du 16/05/2022) Sans comprendre dans les détails, voilà ce que j'ai trouvé comme erreurs et solutions: (tu peux voir les routines modifiées et .ORIG ici: /ccc/work/cont005/gen1140/chabertp/wd/can11sen2_croco/exp/c11s2cp_idealwindruns_shading_ensemble_diabio_budgets/compile/croco) (i) il y avait une première erreur, qui disparait en modifiant OCEAN/diagnostics.h (4 blocs des lignes 58 à 94): je remplace les débuts de ligne "& /" en "common /" (erreur à la compilation qui ne passait pas) la compilation passait ensuite mais erreur de "segmentation fault" après le premier pas de temps (ii) puis en fouillant dans le code je suis tombé sur PISCES/trc.F90, qui a un "ifndef AGRIF [...] else" - suspect; et en modifiant: [chabertp@irene151 croco]$ diff trc.F90 trc.F90.ORIG 43,45c43,45 < CHARACTER(len = 20), PUBLIC, ALLOCATABLE, SAVE, DIMENSION(:) :: ctrcnm !: tracer name < CHARACTER(len = 80), PUBLIC, ALLOCATABLE, SAVE, DIMENSION(:) :: ctrcnl !: trccer field long name < CHARACTER(len = 20), PUBLIC, ALLOCATABLE, SAVE, DIMENSION(:) :: ctrcnu !: tracer unit --- > CHARACTER(len = *), PUBLIC, ALLOCATABLE, SAVE, DIMENSION(:) :: ctrcnm !: tracer name > CHARACTER(len = *), PUBLIC, ALLOCATABLE, SAVE, DIMENSION(:) :: ctrcnl !: trccer field long name > CHARACTER(len = *), PUBLIC, ALLOCATABLE, SAVE, DIMENSION(:) :: ctrcnu !: tracer unit ça tourne; donc il semblerait que les longueurs des chaînes de caractères des noms des traceurs bio n'étaient pas définies dans le cas d'agrif et entrainaient un dépassement de tableau (je ne comprends pas bien ce "len = *" et ce qu'il fait réellement dans le code). Je reprend le bug sur DATARMOR sur config BENGUELA_VHR sans agrif et avec PISCES. Je retrouve le bug sur les & des common dans diagnostic.h Le plantage à la compilation disparait pour planter plus loin dans sedwri.F90!!!! sedwri_.f90(2172): error #5560: Subscript #2 of the array VNAME has value 525 which is greater than the upper bound of 500 lvar=lenstr(vname(1,indxTime2)) ---------------------^ sedwri_.f90(2173): error #5560: Subscript #2 of the array VNAME has value 525 which is greater than the upper bound of 500 write(stdout,1) vname(1,indxTime2)(1:lvar), record, ierr -------------------------^ sedwri_.f90(4249): error #5560: Subscript #2 of the array VNAME has value 525 which is greater than the upper bound of 500 lvar = lenstr(vname(1,indxTime2)) ----------------------^ sedwri_.f90(4250): error #5560: Subscript #2 of the array VNAME has value 525 which is greater than the upper bound of 500 ierr = nf_def_var (ncid, vname(1,indxTime2)(1:lvar), & ---------------------------------^ sedwri_.f90(4252): error #5560: Subscript #2 of the array VNAME has value 525 which is greater than the upper bound of 500 text='avg'//vname(2,indxTime2) --------------------^ sedwri_.f90(4256): error #5560: Subscript #2 of the array VNAME has value 525 which is greater than the upper bound of 500 lvar=lenstr(vname(2,indxTime2)) penser encore à un problème de dépassement de tableau qui impacte complètement différemment en fonction de la config et de la machine! Mais pourquoi ça plante dans les SEDIMENTS de PISCES qui ne sont pas activés!?!?! A voir si Xavier veut concerver la possibilité de ces diagnostiques pour la suite, auquel cas il faut corriger et valider avant d'envoyer un bugfix sur croco!!! ================================================================================ - Bug fix step3d_t.F : set minimum stratification value if dRz=0 ================================================================================ > cff = min( 1./dRz,-1.E-14 ) ! minimum stratification imposed -- < cff = 1./min(dRz, -1.E-14) ! minimum stratification imposed Tester sur 1 mois ! Mail Marchessiello => issue? commit sur master? release? Patrick dit qu'ils ont eu beaucoup de mal avec Floriant pour cette partie et que d'un coup ça a fonctionné après un an. Il a donc peur d'aller changer là dedans. Il faut bien tester. Mais curieux parce que Patrick dit aussi que cette clé est très utilisée, pourtant jamais ils ne rencontrent de division par zéro. Or il semble que sur AWA et sur ASAP , sans la correction de Steph, on rencontre le problème dès le 1er pas de temps de la grille fille : EST CE ENCORE NOTRE SPECIFICITE croco+agrif+pisces "haute resolution"? ou HPC? et encore une fois, le problème rencontré n'a rien à voir ce sujet mais juste un autre effet de bord des dépassements de tableau qui trainent? Attendre d'avoir nettoyé le code sur BENGUELA VHR avant de se lancer dans une modif. Après la discussion rapide Xavier Patrick il y a quand même peut etre une amélioration à faire... STEP time[DAYS] NO3 DIA ZOO DOC trd 0 0.00001 2.1716502E+01 1.5158428E-02 1.1060670E-02 2.2635132E+00 0 STEP time[DAYS] NO3 DIA ZOO DOC trd 0 0.00001 2.5223867E+01 3.4736061E-02 1.9954398E-02 4.0170951E+00 0 Number of days per year in file year2daydta = 365.250000000000 [irene5577:149104:0:149104] Caught signal 8 (Floating point exception: floating-point divide by zero) [irene5577:149012:0:149012] Caught signal 8 (Floating point exception: floating-point divide by zero) [irene5577:149076:0:149076] Caught signal 8 (Floating point exception: floating-point divide by zero) [irene5577:149080:0:149080] Caught signal 8 (Floating point exception: floating-point divide by zero) [irene5577:149084:0:149084] Caught signal 8 (Floating point exception: floating-point divide by zero) /ccc/scratch/cont005/gen1140/hourdinc/croco_scratch_IRENE-AMD/step3d_t_.f: [ sub_loop_step3d_t_tile_() ] ... [irene5577:149088:0:149088] Caught signal 8 (Floating point exception: floating-point divide by zero) 2049 & +(qp1(i,j,k+1)- qp1(i,j,k)) 2050 & *dpth*(1.D0-2.D0*qp2*dpth) 2051 cff = min( 1.D0/dRz,-1.D-14 ) ==> 2052 cff1 = 1.D0/(z_r(i,j,k+1)-z_r(i,j,k)) 2053 hbltmp=10.D0 2054 gama = 1.D0 2055 sig = (z_w(i,j,N)-z_w(i,j,k))/max(hbltmp,10.D0) ================================================================================ - test ANA_DIURNAL_SW / PISCES dans cppdefs_dev.h. ================================================================================ FAUT IL AJOUTER un message pour dire qu'on ne peut pas activer les 2 ensemble? Après discussion avec Christian, problème de fond. Si on enlève le cycle diurne quand on fait tourner PISCES, alors on modifie la dynamique étudiée auparavant. Il faut donc faire en sorte que PISCES fasse une moyenne s'il y a un cycle diurne dans la dynamique ou lise la directement le champ si c'est une moyenne et qu'on active la clé ANA_DIURNAL_SW mail Christian du 23 Septembre 2022 Hello guys, Je confirme que cette histoire de cycle diurne dans PISCES est bien pris en compte dans le code - CROCO/PISCES/ocean2pisces.h90. Il suffit de rajouter dans le fichier de forçage - croco_blk.nc - le shortwave moyenné dans la journée via les croco_tools:add_swradbio_climato.m Cheers, Christian ================================================================================ PISCES/p4zlim.F90. limite en fer dans l'Austral à discuter avec Olivier ================================================================================ A voir avec Olivier. ================================================================================ PISCES/biology_pisces.F Garantie pas de valeurs <0 salinité pour grille mère quand y a AGRIF sur l'update. ================================================================================ Mais masque les salinité négatives de croco. Pas propre pour Patrick et Xavier. A rediscuter Rachid suggère qu'on hésite pas à faire une issue pour tous ces sujets. Même si c'est juste pour qu'ils soient discutés. ================================================================================ Blk Online passage des norot dans les boucles exchange_?2d_tile ? Selon préconnisations Stéphane ================================================================================ 1/ OCEAN/forces.h #### corrigé par Gildas dans master + release sur master : commit 5dcc6b6055f6680a56f4efbbe9dc9514fd4416cf sur release : commit 277138e77f0d2421d7b9f64483d3b16f8254bd29 Bug fix in force.h : AGRIF+ONLINE BULK with MPI was blowing up (serial and with OpenMP was OK) Add uwndg_norot and radswg_down arrays into common in case of ONLINE BULK # endif # ifdef ONLINE common /bulk_uwndg_norot/uwndg_norot common /bulk_radswg_down/radswg_down 2/ OCEAN/online_interpolate_bulk.F Pour croco : Faut il faire passer les 2 nouvelles variables intermediaires radswg_down & uwndg_norot comme les autres par la boucle : > call exchange_u2d_tile(1,Lm,1,Mm, > & uwndg_norot(START_2D_ARRAY,iblkrec)) Pour Steph spécifiquement qui lit le module au lieu de le calculer Faut il commenter le call pour wspdg et le mettre pour uwndg_norot? > ! Modif SPOUS ASAP > # ifdef MPI > call exchange_u2d_tile(1,Lm,1,Mm, > & uwndg_norot(START_2D_ARRAY,iblkrec)) > # endif > ! Modif SPOUS ASAP --- > ! Modif SPOUS ASAP > ! call exchange_r2d_tile(1,Lm,1,Mm, > ! & wspdg(START_2D_ARRAY,iblkrec)) > ! Modif SPOUS ASAP Rachid recommande de faire une issue en relation avec le bugfix sur forces.h pour suggérer ================================================================================ clé SHADING ================================================================================ pb de codage. Avec PISCES sans AGRIF plante! forrtl: severe (408): fort: (2): Subscript #1 of the array TMASK has value 57 which is greater than the upper bound of 56 Image PC Routine Line Source libifcoremt.so.5 000014907B2254C9 for_emit_diagnost Unknown Unknown croco_JEANZAY.exe 00000000005B321A p4zopt_mp_p4z_opt 461 p4zopt_.f90 croco_JEANZAY.exe 00000000009DA7C1 p4zbio_mp_p4z_bio 369 p4zbio_.f90 ... p4zopt_.f90 : IF( ln_qsr_bio ) THEN !* heat flux accros w-level (used in the dynamics) ! ! ------------------------ DO jj = Jstrp,Jendp DO ji = Istrp,Iendp zqsr_corr(ji,jj) = max(1.e-10,rho0*Cp*srflx(ji,jj)) END DO END DO CALL p4z_opt_par( kt, zqsr_corr, ze1, ze2, ze3, pe0=ze0 ) ! ===> etot3(:,:,1) = max(1.e-10,rho0*Cp*srflx(:,:)) * tmask(:,:,1) parce que Vincent modifie > LOGICAL :: ln_qsr_bio = .false. -- < LOGICAL :: ln_qsr_bio = .true. ================================================================================ - indentation des ifdefs!!!! Rachid avait commencé avec un shell.. - la non reproductibilité MPI de Vera est sans doute normale!!! Elle refait toutes ses simus pour rien! Faire un diag sur les DIA comme elle - CVTK valable pour nos configs LOCEAN: Intégrer les clés AWA ASAP2 dans BENGUELA_VHR CVTK comme bulk online! bulk_online rivières (Gildas dit qu'elles ne sont pas testées) Faire tourner ces tests BENGUELA_VHR sur HPC Faire tourner nos configs AWA et ASAP2 sur HPC (et sur INRIA mas trop grosses j'imagine) - PISCES compilé quoi qu'il arrive? à vérifier (ou juste cpp?) Rachid : non. cpp passe mais crée des routines _.f vide ou fausses. C'est pour ça qu'il y a plein de routines qui ne sont jamais compilées et donc jamais vérifiées!! -------------------------------------------------------------------------------- DEALLOCATE TENACE -------------------------------------------------------------------------------- - Le DEALLOCATE continue de trainer... même avec la v3.01 basée sur release et branch 63 bugfix pisces sur AWA sur IRENE-AMD si on lit frcbio.nc.1 pour dust : [irene5558:251472:0:251472] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x48) [irene5558:251471:0:251471] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x48) ==== backtrace (tid: 251472) ==== 0 0x0000000000053755 ucs_debug_print_backtrace() /tmp/ucx/1.9.0/system-system/ucx-1.9.0/src/ucs/debug/debug.c:656 1 0x0000000000129e88 rml::internal::LocalLOCImpl<8, 32>::put() /nfs/site/proj/openmp/promo/20190814/cet-enabled/tbbmalloc/build/linux_intel64_icc_cc4.4.6_libc2.12_kernel2.6.32_release/../../src/tbbmalloc/frontend.cpp:2201 2 0x0000000000129e88 rml::internal::MemoryPool::putToLLOCache() /nfs/site/proj/openmp/promo/20190814/cet-enabled/tbbmalloc/build/linux_intel64_icc_cc4.4.6_libc2.12_kernel2.6.32_release/../../src/tbbmalloc/frontend.cpp:2327 3 0x000000000099956d for_dealloc_allocatable() ???:0 4 0x00000000004b1155 p4zsed_mp_sub_loop_p4z_sed_() ???:0 5 0x00000000004a5f1d p4zsed_mp_p4z_sed_() ???:0 6 0x00000000004d1945 p4zsms_mp_p4z_sms_() ???:0 7 0x00000000007bf32d biology_tile_() ???:0 8 0x000000000064a692 sub_loop_step3d_t_tile_() ???:0 9 0x0000000000642597 step3d_t_() ???:0 10 0x00000000005a81bd step_() ???:0 11 0x000000000089aaf5 agrif_util_mp_agrif_integrate_() ???:0 12 0x0000000000898782 agrif_util_mp_agrif_step_() ???:0 13 0x000000000059615f MAIN__() ???:0 14 0x000000000040f8d2 main() ???:0 15 0x0000000000022555 __libc_start_main() ???:0 16 0x000000000040f7e9 _start() ???:0 si on ne le lit pas: ça passe. Et pas de problème sur IRENE skylake dans un cas comme dans l'autre Rachid me demande tout de suite si je suis sûr que la grille fille a bien lu le frcbio.nc.1 et non le frcbio.nc Qu'il a eu ce probème. Y a quand même quelque chose par là avec le Fer et sédiment... PISTE AVEC L'OPTION DE COMPILATION pour ifort sur la gestion de mémoire... Mail le 07 Oct 2022 Rachid : j’ai ajouté l’option -heap-array ce que je comprends de mes lectures, c’est que ifort alloue par défaut les tableaux locaux dans la zone mémoire stack. Avec cette option, c’est alloué dans la zone heap. Je n’ai jamais compris cette histoire de zone mémoire, mais l’important ici c’est que la zone stack est petite par exemple sans l'option j’arrivais à tourner le petit benguela en MPI 2x2 mais pas en mono, vu que les tableaux dans ce casMPI sont 4 fois plus petits et dans Pisces il y a bcp de tableaux locaux 3D ça me faisiat des plantages sur des lignes sans aucun rapport Après un exemple sur IRENE-AMD là où j'avais un DEALLOCATE, l'ajout de l'option -heap-array avec ifort a réglé le problème!!!!!!! -------------------------------------------------------------------------------- Probleme ancien des warnings du CONV AGRIF à la compilation. -------------------------------------------------------------------------------- WARNING : The dimension of the character Coptions is upper than 2400. You must change the dimension of carray0 in the file AGRIF/AGRIF_FILES/modtypes.F90 line 161. Replace 2400 with 4500. => Modif dans AGRIF/AGRIF_FILES/modtypes.F90 . 183,184c183,184 < character(500), dimension(:) , allocatable :: carray1 < character(500), dimension(:,:), allocatable :: carray2 --- > character(5000), dimension(:) , allocatable :: carray1 > character(5000), dimension(:,:), allocatable :: carray2 Mais les routines du CONV modifiées ne seraient pas prises en compte... Rachid dit qu'au contraire c'est pris en compte et que c'est bien de le corriger. Il se demande même si ça n'a pas des effets de bord!