ticket summary __group__ version milestone type reporter status created _changetime _description 2692 Update of AGRIF reference configuration AGRIF trunk Defect jchanut new 2021-06-17T11:36:31+02:00 2021-06-21T12:09:32+02:00 "==== Context Update the reference configuration to demonstrate and test AGRIF capabilities, e.g. ""AGRIF_DEMO"" ==== Analysis AGRIF_DEMO is based on ORCA2 in which 3 nested grids are embedded: - The first zoom is a 1:1 refinement of ORCA2 to detect trivial errors in the implementation - The second zoom is 1:4 refinement spanning a part of the Arctic Ocean. The positioning of this grid close to the North Fold was ill posed and generates reproducibility issues. - The third zoom is nested in zoom 2, over the Svalbard archipelago. Since new functionalities in the upcoming NEMO 4.2 need to be tested (vertical refinement, nested grids crossing the North Fold, etc...), and because constrains on grid matching have evolved since NEMO 4.0x, a new configuration needs to be created. " 2509 AGRIF_DEMO: strange salinity in parent grid close to the coast if ln_linssh=F AGRIF v4.0.* Defect andrea.gierisch new 2020-08-04T20:51:45+02:00 2022-02-04T18:33:17+01:00 "==== Context I'm running AGRIF_DEMO with release-4.0.2. The salinity in the first nest (2_Nordic) looks weird around the coast in those areas, which are covered by the second nest (3_Nordic). The values in 3_Nordic however look fine. The effect disappears if I set `ln_linssh=T` for all nests. I use: Code and namelists etc.: https://forge.ipsl.jussieu.fr/nemo/svn/NEMO/releases/r4.0/r4.0.2 revision r13375 Input data: https://zenodo.org/record/1472245/files/AGRIF_DEMO_v4.0.tar?download=1 https://zenodo.org/record/1472245/files/ORCA2_ICE_v4.0.tar?download=1 Output frequency set to 1-daily. ==== Analysis The effect happens for those ocean grid cells in the parent grid whose corresponding child-grid cells are mostly covered by land. The salinity at these parent grid cells is unexpectedly high if the sea level (`zos`) is <0 and unexpectedly low if `zos>0`. As `zos` is connected to `e3t` if `ln_linssh=F`, I suspect that AGRIF does something wrong when updating the salinity from the child to the parent. Maybe `e3t` is not taken into account correctly? It's too fresh when the cells are thick and too salty when the cells are shallow. This effect is more pronounced in my own setup (a nest around Greenland from an Arctic setup - I'll attach some plots) but as it is also visible in AGRIF_DEMO, I think it could be a general problem and not only related to deficiencies in my own setup...? ==== Recommendation Work-around: set `ln_linssh=T`, but this is not really a solution... I'd be happy if someone has a better idea how to fix this. " 2505 NESTING tools: Bathymetry at bdy of AGRIF-nest is not consistent with parent bathymetry AGRIF v4.0.* Defect andrea.gierisch new 2020-07-28T22:25:13+02:00 2022-02-04T18:33:17+01:00 "==== Context I use release4.0.2/tools/NESTING (revision 12273) to create an AGRIF nest. When running NEMO4.0.2 with the resulting `1_domain_cfg.nc` and `domain_cfg_updated.nc`, an error message says that the bathymetry at the boundary is not consistent between child and parent: {{{ ERROR bathymetry merge at the southern border ji,jj,jk 44 2 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 45 2 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 46 2 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 44 3 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 45 3 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 46 3 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 44 4 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 45 4 37 6.70534153693853 34.8481484050435 ERROR bathymetry merge at the southern border ji,jj,jk 46 4 37 6.70534153693853 34.8481484050435 }}} ==== Analysis Reason for the error message: `e3t_0` differs for 1 coarse grid cell and the according 9 fine grid cells. The same grid cell was mentioned in the output of `agrif_create_bathy.exe` saying that an isolated ocean grid cell had been removed at level 37. I suspected that something goes wrong when removing the isolated ocean grid cells in combination with updating the parent grid, and therefore I commented out the respective calls to `bathymetry_control`: {{{#!diff Index: src/agrif_create_bathy.f90 =================================================================== --- src/agrif_create_bathy.f90 (revision 12273) +++ src/agrif_create_bathy.f90 (working copy) @@ -326,7 +326,7 @@ ! compute G0%gdepw_ps and G1%gdepw_ps CALL get_partial_steps(G0) CALL get_partial_steps(G1) - CALL bathymetry_control(G0%Bathy_level) + ! CALL bathymetry_control(G0%Bathy_level) ! --------------------------------------- ! Bathymetry at the boundaries (npt_copy) Index: src/agrif_partial_steps.f90 =================================================================== --- src/agrif_partial_steps.f90 (revision 12273) +++ src/agrif_partial_steps.f90 (working copy) @@ -210,7 +210,7 @@ !!$ !!$ ENDIF - CALL bathymetry_control(grid%bathy_level) + ! CALL bathymetry_control(grid%bathy_level) ! ! initialization to the reference z-coordinate ! }}} This work-around fixes the inconsistency between `1_domain_cfg.nc` and `domain_cfg_updated.nc`. However, I don't know what bad side-effect my crude ""fix"" introduces. Hence, I hope that someone with more insight into NESTING can suggest a better fix. If it helps, I can share my namelists etc. and a screenshot of the faulty e3t_0 variable. ==== Recommendation Just some guesses/ideas: * Update the parent/child bathymetry after having removed isolated ocean cells from the child/parent grid? * Or restrict `bathymetry_control` to run only in the inner domain of the child and not on those grid cells along the boundary which should have the exact same bathymetry as the parent? " 2663 VLD-10_Mueller_generic_SETTE CI trunk Unscheduled Task smueller new 2021-05-05T13:47:51+02:00 2022-01-14T12:04:58+01:00 "==== Workplan action Wikipage: wiki:2021WP/VLD-10_Mueller_generic_SETTE " 2452 integrate ABL in SETTE ORCA2_ICE_PISCES cfg CI trunk Unscheduled Defect gsamson new 2020-04-27T09:56:13+02:00 2020-06-26T10:36:28+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context ABL component not yet tested in SETTE ==== Analysis ABL can be easly tested with ORCA2_ICE_PISCES cfg ==== Recommendation Add ABL atmospheric forcing to Zenodo ""NEMO Reference configurations inputs"" webpage and activate ABL with ORCA2_ICE_PISCES cfg in SETTE test branch available here: https://forge.ipsl.jussieu.fr/nemo/browser/utils/CI/sette_ticket2452 ABL forcing here: ftp://ftp.mercator-ocean.fr/download/users/gsamson/ORCA2_ABL_v4.0.tar" 2303 What is still missing in SETTE ? CI trunk Request mathiot new 2019-06-25T12:26:33+02:00 2020-03-28T12:31:50+01:00 " ==== Context after last commit on SETTE, SETTE is better and more reliable, but it is still not perfect, here a list of idea to be discuss to improve SETTE further. Feel free to comment or update the list. The order do not reflect the amount of work or any kind of priority. ==== Proposal - Find a way to have only one SETTE directory to manage various branches (at this stage, you need one SETTE directory per branch) - Clean sette_reference_config.sh (former sette.sh) and sette_test_cases.sh (~1500 lines). - Ease the process to include new configs for personal testing (ideally one NEWCFG repo in cfgs/., one input file NEWCFG_input.cfg and ./sette.st -t NEWCFG and that's it) - Add an input_CFG.cfg namelist variable used by SETTE related to the configuration setup as 'set_namelist namelist_pisces_cfg ln_solub .false.' for exemple, processor decomposition, time step you want to run ... ; if namelist_cfg of sette configuration different to the reference configuration, we could add the namelist_cfg file into the tar file. These points should allow to build a function in sette_*_config.sh and ease previous points. - Decrease the number of configurations to test (not the amount of options tested) by merging some configuration (ORCA2_ICE_PISCES + ORCA2_ICE_OBS + SAS for example). - Decrease the number of run (use the LONG run as reference also for the reproducibility). Instead of 4 run: LONG/SHORT and REPRO_XX/REPRO_YY, could 3 run be enough: REF (ie the long run), RST (the short run)and REPRO (one of the REPRO_XX runs) - Compilation of SETTE in parallel. - Is sette_test_cases.sh is the script to run all the test cases of a specific config (based on the list of namelist_*_cfg) in addition of the standard SETTE tests? Should it be in an other script ? - Do we need a 2nd pass for the report ? - Check timing of SETTE runs in the report? Memory usage? - Enable the configurability of the revision-number suffix used to indicate local modification of the working copy - Save the svn status or even svn diff related to the src/ and cfgs/CFG directory in the directory RRRRx/WCFG/. . - Is someone has a list of all the options tested in SETTE compare to the amount of option available in the namelist ? - Remove variable ADD_NOSIGNEDZERO and the associated mechanism to add preprocessor key key_nosignedzero from SETTE (see ticket:2302#comment:1) DONE: - Need to check consistency between CFG_ST and CFG directory (in case CFG change during a revision, change will not propagate to CFG_ST using SETTE, you need to clean_config CFG_ST before and recompile from scratch). => ticket #2304" 2753 """ztime"" value shifted by one time step in diaharm.F90" DIA v4.0.* Defect nicolas_gonzalez new 2022-01-14T19:38:02+01:00 2022-01-14T19:38:02+01:00 "==== Context The tidal phase estimated by diaharm routine is shifted by one time step. ==== Analysis The time variable ""ztime"" at L.183 in the dia_harm subroutine is not consistent with the surface elevation and velocity variables used. It is defined as ""ztime = (kt-nit000+1) * rdt"" corresponding to ""after"" time step, however, it is used with the ""now"" time step sea surface elevation and velocity variables (L.194-196). ==== Recommendation Replace the L.183 of diaharm.F90 by the following: ztime = (kt-nit000) * rdt " 2662 HPC-11_mcastril_HPDAonline DiagGPU DIA trunk Unscheduled Task mcastril new 2021-04-30T13:08:46+02:00 2022-01-14T12:05:56+01:00 "High performance data analytics solutions aiming at tackling the online diagnostics of the NEMO model will be explored as complementary components in the model diagnostics software eco-system. Online techniques leveraging fast (low latency and real-time) data analytics approaches (e.g. on fat nodes) will be evaluated in real cluster environments. In particular, an interface of NEMO to the High Performance Data Analitics (HPDA) framework will be designed and implemented for online diagnostics. The rationale of this activity is to improve the NEMO computational performance by executing the computations for diagnostics on GPU. Workplan action Wikipage: wiki:2021WP/HPC-11_mcastril_HPDAonlineDiagGPU Follow up of #2368 " 2582 Error in the diagnostic bottom pressure DIA trunk Defect Robin_Waldman new 2020-11-25T11:19:48+01:00 2020-11-25T12:43:35+01:00 "==== Context Within DIA/diaar5.F90, the routine dia_ar5 computes wrongly the bottom pressure (variable zbotpres) ==== Analysis The bottom pressure formulation in L.185 of diaar5.F90 has a dimensional error. Indeed, the hydrostatic part is multiplied twice by density, once in the zbotpres computation of L.164-179, and a second time within the constant coefficient zztmp computed in L.184. ==== Recommendation 1. For already existing model outputs with the variable zbotpres (pbo in the CMIP nomenclature): the bottom pressure can be retrieved offline by combining zbtotpres and sshn as follows: {{{#!f true_zbotpres(:,:) = zbotpres(:,:)/rau0 + (sshn(:,:) + thick0(:,:)) * g * (rau0 - 1) }}} 2. The correction to diaar5.F90 to retrieve the true bottom pressure is: {{{#!f 184 zztmp = grav * 1.e-4_wp ! recover pressure from pressure anomaly and cover to dbar = 1.e4 Pa 185 zbotpres(:,:) = zztmp * ( zbotpres(:,:) + rho0 * (ssh(:,:,Kmm) + thick0(:,:)) ) }}} ..." 2579 PGI compiler does allow read values from namelist using buffers DIA trunk Unscheduled Defect mcastril new 2020-11-23T20:05:40+01:00 2020-12-16T15:43:11+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Compiler arch: {{{#!perl %NCDF_HOME /apps/NETCDF/4.4.1.1/PGI/OPENMPI %HDF5_HOME /apps/HDF5/1.8.20/PGI/OPENMPI %XIOS_HOME /home/bsc99/bsc99214/trunk/xios-2.5.pw9 %NCDF_INC -I%NCDF_HOME/include %NCDF_LIB -L%NCDF_HOME/lib -lnetcdff -lnetcdf -L%HDF5_HOME/lib -lhdf5_hl -lhdf5 -lhdf5 %XIOS_INC -I%XIOS_HOME/inc %XIOS_LIB -L%XIOS_HOME/lib -lxios -lstdc++ -L/apps/GCC/8.1.0/lib/gcc/ppc64le-redhat-linux/lib64/ %OASIS_INC %OASIS_LIB %CPP cpp -P -traditional -Dkey_nosignedzero %FC mpif90 %FCFLAGS -i4 -r8 -g -fast %FFLAGS %FCFLAGS %LD mpif90 %LDFLAGS -i4 -r8 -g -fast %FPPFLAGS -P -Uvector %AR ar %ARFLAGS rs %MK gmake %USER_INC %XIOS_INC %OASIS_INC %NCDF_INC %USER_LIB %XIOS_LIB %OASIS_LIB %NCDF_LIB %CC cc %CFLAGS -O0 -g }}} The bug activates a warning: {{{ ===>>> : W A R N I N G =============== end of record or file while reading namelist nammpp in reference namelist iostat = -1 }}} ==== Analysis investigating further there is a error in reading values from namelist files: {{{ FIO-F-228/namelist read/internal file/end of file reached without finding group. }}} Sample code to identify the problem: {{{#!f integer :: jpni,jpnj CHARACTER(LEN=104) :: buff namelist/nammpp/ jpni,jpnj buff = ' /&nammpp jpni = 10 jpnj = 4 /&namctl /&namsto / EOF ' read(buff,nml=nammpp) print *, jpni end }}} ==== Recommendation Example of workaround we implement to manage trunk {{{#!f integer :: i,j, a, b, pos CHARACTER(LEN=80) :: buff namelist/nammpp/ i,j namelist/namctl/ a,b buff=' / &nammpp i = 10 j = 4 $ / &namctl a = 5 b = 3 / ' pos=index(buff,'&nammpp') read(buff(pos:),nammpp) print *, i, j pos=index(buff,'&namctl') read(buff(pos:),namctl) print *, a,b end }}} " 2559 dia_prt optimisation... DIA trunk Defect smasson new 2020-11-02T18:35:26+01:00 2020-12-04T12:13:59+01:00 " ==== Context Several bugs/issues/optimisations should be done in dia_prt (in addition of #2529) ==== Analysis There is a set of points Amy, Daley, and I noted (more or less in random order...) 1) the same array must not be used in input and in output of with ptr_* functions. This bug occurs in 2 lines: source:browser/NEMO/trunk/src/OCE/DIA/diaptr.F90:208 {{{#!fortran zmask(1,:,:) = ptr_sjk( zmask(:,:,:), btmsk(:,:,jn) ) }}} source:browser/NEMO/trunk/src/OCE/DIA/diaptr.F90:319 {{{#!fortran z2d(:,:) = ptr_ci_2d( z2d(:,:) ) }}} I guess for zmask, we should simply do as for the other variables: {{{#!fortran DO jn = 1, nptr z4d1(1,:,:,jn) = ptr_sjk( zmask(:,:,:), btmsk(:,:,jn) ) DO ji = 2, jpi z4d1(:,:,:,jn) = z4d1(1,:,:,jn) ENDDO ENDDO }}} 2) the following loops could/should start at 2 and not 1 {{{#!fortran DO ji = 2, jpi xxx(ji,:,:,jn) = xxx(1,:,:,jn) ENDDO }}} 3) we should not write the above loops with the “:” notation as they will be extended as with the ji loop outside of the jj and jk loops… we should with explicitly {{{#!fortran DO jk = 1, jpk DO jj = 1, jpj DO ji = 2, jpi xxx(ji,jj,jk,jn) = xxx(1,jj,jk,jn) ENDDO ENDDO ENDDO }}} '''4) Note that we have 3D arrays (jj,jk,jn) that we duplicate jpi times into 4D arrays (ji,jj,jk,jn). The only motivation of this waist of memory is that we will extract only one unique slice (jj,jk,jn) of this 4D array when writing the data with iol_put (see set_grid_znl in iom.F90)…''' 5) dia_prt uses useless target and pointers : {{{#!fortran REAL(wp), TARGET, ALLOCATABLE, SAVE, DIMENSION(:) :: p_fval1d REAL(wp), TARGET, ALLOCATABLE, SAVE, DIMENSION(:,:) :: p_fval2d }}} in ptr_sj_2d, one can simply define {{{#!fortran REAL(wp), DIMENSION(jpj) :: p_fval }}} and in ptr_sjk, one can simply define {{{#!fortran REAL(wp), DIMENSION(jpj,jpk) :: p_fval }}} 6) ptr_ci_2d is not working when land-only MPI subdomains are suppressed. This can be fixed my creating a North-South communication between subdomains that are separated by suppressed subdomains along the j direction (modification of mppini as it was done for cmpi6). 7) I am not completely sure that the trick for uocetr_vsum_cumul is effectively working... maybe... 8) ijpj variable should be suppressed and replaced everywhere byjpj ==== Fix ==== Recommendation this version of dia_prt originates from the first implementation of XIOS at that time we did not take care of the memory footprint... Instead of porting dia_prt on GPU we could maybe think a little bit more to avoid the array duplication and the waist of memory in this routine… " 2153 HPC-03_HPDAonlineDiag DIA trunk Unscheduled Task epico new 2018-11-01T12:32:34+01:00 2021-04-14T12:57:45+02:00 "== Context Design of the NEMO interface to HPDA framework for online diagnostics " 2463 Updating the online quickstart guide doc v4.0.* Defect clevy new 2020-05-12T16:31:11+02:00 2020-05-12T16:37:26+02:00 " ==== Context Online quickstart guide is here https://forge.ipsl.jussieu.fr/nemo/chrome/site/doc/NEMO/guide/html/NEMO_guide.html and need updates. ==== Analysis Using the donc/rst files, compile them (make html) to generate html files from the rst ones, and place these updated html directory in place on NEMO forge. ==== Recommendations and questions * Do you agree to do it from the rst files from the trunk? * Which rst files need update? Who is willing to do these updates? * Do you have any idea on how to deal with the warning (see below)? Warnings: /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/acro.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/cite.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/contrib.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/da.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/diags.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/guide.rst:16: WARNING: toctree contains reference to excluded document 'todos' /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/guide.rst:23: WARNING: toctree glob pattern 'unpub/*' didn't match any documents source/readme.rst:1: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/install.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/setup.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/tests.rst:: WARNING: image file not readable: _static/CANAL_image.gif /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/tools.rst:45: WARNING: download file not readable: /Users/clelod/Documents/WORK/TEX/trunk/tools/DOMAINcfg/README /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/tracers.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/zooms.rst:5: WARNING: Content block expected for the ""todo"" directive; none found. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/zooms.rst:13: WARNING: duplicate label overview, other instance in /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/guide.rst /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/zooms.rst:26: WARNING: duplicate label compilation, other instance in /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/tests.rst looking for now-outdated files... none found pickling environment... done checking consistency... /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/tests.rst: WARNING: Citation [Brodeau_al_2017] is not referenced. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/zooms.rst: WARNING: Citation [a-DEBREU2012] is not referenced. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/zooms.rst: WARNING: Citation [a-PENVEN2006] is not referenced. /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/zooms.rst: WARNING: Citation [a-SPALL1991] is not referenced. done preparing documents... done writing output... [100%] zooms /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/install.rst:135: WARNING: unknown document: doc /Users/clelod/Documents/WORK/TEX/trunk/doc/rst/source/install.rst:142: WARNING: unknown document: src generating indices... genindexdone writing additional pages... searchdone copying images... [100%] _static/agrif_grid_position.jpg copying downloadable files... [100%] ../../../tools/WEIGHTS/README copying static files... ... done copying extra files... done dumping search index in English (code: en)... done dumping object inventory... done build succeeded, 22 warnings. The HTML pages are in build/html. Build finished. The HTML pages are in build/html. " 2754 closed seas: mass conservation issue DOM v4.0.* Bug clem new 2022-01-18T16:18:11+01:00 2022-02-01T17:47:00+01:00 "The way to deal with the empmr budget in closed seas is not always conservative. For instance, if there is no region defined by (closea_mask_empmr/=0 and closea_mask=0), then a part of empmr budget in closed seas just vanishes because of these lines: {{{#!fortran ! The following if avoids the redistribution of the round off IF ( ABS( zfwfe(jce) / surf(jncs+1) ) > rsmall ) THEN ! ! Add residuals to runoff points and subtract from total to be added globally zfwf_total = zfwf_total - zfwfe(jce) zcoef = zfwfe(jce) / surfe(jce) zcoef1 = rcp * zcoef WHERE( closea_mask_empmr(:,:) == jce .and. closea_mask(:,:) == 0.0) emp(:,:) = emp(:,:) + zcoef qns(:,:) = qns(:,:) - zcoef1 * sst_m(:,:) ENDWHERE ENDIF }}} In addition, a parameter rsmall is used but I do not understand the purpose of it and it overwrites the rsmall parameter defined in phycst.F90. I recommand to remove the IF statement above and rewrite this part, so that zfwfe is not removed from zfwf_total when there is no region where (closea_mask_empmr/=0 and closea_mask=0)" 2574 ssh initialization by dom_init routines when non linear DOM trunk Defect techene new 2020-11-19T14:13:03+01:00 2020-11-30T11:58:37+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context When ssh is non linear (ln_linssh = F) ssh is initialized by both istate (set to 0 or rst_read or usr_def_istate) and dom_init (dom_vvl_init -> dom_vvl_rst -> set to 0 or read ) subroutines. ==== Analysis (ln_linssh = F) Because ssh is initialized to zero in most cases by dom_vvl_rst, test cases such as CANAL or VORTEX have to duplicate domvvl module and call usr_def_istate instead of ssh = 0 and update scale factors accordingly. usr_def_istate call also initializes unexpected variables such as speeds or active tracers. Then ssh is deeply related to scale factors so it makes more sense to initialize it in dom_init. ==== Recommendation In order to avoid duplication and unexpected initialization we 1) write a dedicated ssh initialization and remove ssh from usr_def_istate => usr_def_istate_ssh 2) tidy up ssh initialization - when ssh is linear (ln_linssh = T) in restart mode ssh is read in istate_init by rst_read in classic mode ssh is set up by istate as well - when ssh is non linear (ln_linssh = F) in restart mode ssh is read in dom_init by dom_vvl_rst exclusively so we remove ssh from istate_init" 2542 Specify slip conditions from 2d file DOM trunk Request mathiot new 2020-10-06T15:47:37+02:00 2020-12-04T11:41:41+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Some users (DRAKKAR and UKMO at least) add to the NEMO based code an option to specify the slip condition (rn_shlat) via a 2d file instead of a single float defined in the namelist_cfg. Adding this option will: - increase flexibility in the slip condition set up - remove the need of the usr_def_fmask module as it could be managed via an input file. ==== Materials - code to do it in a NEMO4 based branch (not yet updated to the trunk) is available at this commit (https://forge.ipsl.jussieu.fr/nemo/changeset/10904) - DRAKKAR code available here: https://github.com/meom-group/DCM/blob/master/DCMTOOLS/DRAKKAR/NEMO4/src/OCE/DOM/dommsk.F90 " 2390 ticket for KERNEL-03_Storkey_Coward_RK3_stage2 WP2020 action DOM trunk Unscheduled Task davestorkey new 2020-02-28T15:13:43+01:00 2021-04-14T13:04:08+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2020WP/KERNEL-03_Storkey_Coward_RK3_stage2" 2385 KERNEL-06_techene_better_e3_management DOM trunk Unscheduled Task techene new 2020-02-24T18:44:54+01:00 2021-11-26T15:39:01+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action KERNEL-06 Better and faster implementation of quasi eulerian coordinate (star coordinates : z* et s*) Wikipage: wiki:2020WP/KERNEL-06_techene_better_e3_management ==== starting point In NEMO r12377 scale factors (e3*) at u-v-w-uw-vw-f-points are interpolated from e3t at Kbb, Kmm, and Kaa. The module in charge of scale factor management is src/OCE/DOM/domvvl.F90. domvvl.F90 interpolation routine is called : - at initialisation or restart at u-v-w-uw-vw-f-points {{{ nemogcm --> nemo_init --> dom_init --> dom_vvl_init --> dom_vvl_rst --> dom_vvl_zgr --> dom_vvl_interpol }}} - at each time step for ""after"" scale factor at u-v-points each time ssh[Naa] is computed {{{ nemogcm --> stp --> dom_vvl_sf_nxt --> e3t[Kaa] --> dom_vvl_interpol }}} - at each time step for ""now"" scale factor at u-v-points e3t is directly filtered {{{ nemogcm --> stp --> tra_atf --> e3t[Kmm] --> dyn_atf --> e3t[Kmm] --> dom_vvl_interpol }}} - at each time step after time swapping for ""now"" at f-point and ""before"" scale factor both at w-uw-vw-points {{{ nemogcm --> stp --> dom_vvl_sf_update --> dom_vvl_interpol }}} ==== developments In version 1 of source:/NEMO/branches/2020/dev_r12377_KERNEL-06_techene_e3 we implement changes progressively and validate step by step regarding GYRE_PISCES test case. We remove all the vvl routines usage thus we replace e3t/u/v/w/uw/vw at 3 time step + e3f (19) 3d tables storage and twice e3u/v ""after"" + e3u/v ""now"" + e3f/w/uw/vw ""now"" + e3w/uw/vw ""before"" (13) 3d tables interpolation at each step and e3u/v/f/w/uw/vw ""now"" + e3u/v/w/uw/vw ""before"" (11) 3d tables interpolation at initialisation or restart by r3t/u/v at 3 time steps and r3f i.e. (10) 2d table storage and on the fly light computation. For backward compatibility we introduce a cpp key key_qco in order to isolate new scale factor implementation from former vvl version. qco stand for for ""quasi eulerian coordinate"". - new variables added in dom_oce and domain {{{ r3P with P = [t,u,v,f] are 2d in space ssh/hP0 }}} - new module in DOM : dom_qco {{{ -- dom_qco_r3c ! compute ssh/ht0 at t-point and interpolate ssh/h.0 at u-v-f-points from ssh -- dom_qco_zgr ! set ssh/ht0 at t-u-v-f-points for Kmm and at t-u-v-points for Kbb --> dom_qco_r3c[Kmm] at t-u-v-f-points --> dom_qco_r3c[Kbb] at t-u-v -points }}} - new substitute in DOM : domzgr_substitute When key_qco is active e3. is no longer a variable but an expression. Each time e3. appears in a routine an include domzgr_substitute in the module enables to replace it by a (e3._0 ( 1 + r3. ) * mask.) like expression. {{{ # define e3t(i,j,k,t) (e3t_0(i,j,k)*(1._wp+r3t(i,j,t)*tmask(i,j,k))) # define e3u(i,j,k,t) (e3u_0(i,j,k)*(1._wp+r3u(i,j,t)*umask(i,j,k))) # define e3v(i,j,k,t) (e3v_0(i,j,k)*(1._wp+r3v(i,j,t)*vmask(i,j,k))) # define e3f(i,j,k) (e3f_0(i,j,k)*(1._wp+r3f(i,j)*fmask(i,j,k))) # define e3w(i,j,k,t) (e3w_0(i,j,k)*(1._wp+r3t(i,j,t))) # define e3uw(i,j,k,t) (e3uw_0(i,j,k)*(1._wp+r3u(i,j,t))) # define e3vw(i,j,k,t) (e3vw_0(i,j,k)*(1._wp+r3v(i,j,t))) }}} - finally we extended the e3. modification to h. r1_h. and gde.. {{{ # define ht(i,j) (ht_0(i,j)+ssh(i,j,Kmm)) # define hu(i,j,t) (hu_0(i,j)*(1._wp+r3u(i,j,t))) # define hv(i,j,t) (hv_0(i,j)*(1._wp+r3v(i,j,t))) # define r1_hu(i,j,t) (r1_hu_0(i,j)/(1._wp+r3u(i,j,t))) # define r1_hv(i,j,t) (r1_hv_0(i,j)/(1._wp+r3v(i,j,t))) # define gdept(i,j,k,t) (gdept_0(i,j,k)*(1._wp+r3t(i,j,t))) # define gdepw(i,j,k,t) (gdepw_0(i,j,k)*(1._wp+r3t(i,j,t))) # define gde3w(i,j,k) (gdept_0(i,j,k)*(1._wp+r3t(i,j,Kmm))-ssh(i,j,Kmm)) }}} Step 1 : Check the error for e3t, e3w between the current way to compute e3 at T-, W-point and the proposed way to compute e3 at T-, W-point. - prints added with no change in the results Step 2 : First we change only the core routine in domvvl which should be changed into domQE. - add new variables, duplicate step into steplf and domvvl into domQE - change interpolation routines into scaling routines in domQE Step 3 : Then we change the Asselin filtering routine indeed because water forcing are applied locally. - change Asselin routines (maybe not required since e3 scale with vertical with JC modif) Step 4 : Finally we remove the interpol routine in the whole code - remove interpolating routine in all the code (AGRIF, OFF,...) - use a SUBSTITUTE when there are e3 CALL - make some changes in step and domQE to have the whole thing consistent == Tests {{{#!box width=50em info [[Include(wiki:Developers/DevProcess#tests)]] }}} ''...'' We want to track and maybe explain the differences observed at every steps. Reference set up : For that we produce a reference data set with the trunk -r 12377 using the GYRE_PISCES configuration where top cpp_key has been removed. We run it on 120 time steps. The drag coefficient is zero. We XIOS output an averaged field every 5 days. Step 1 : We print MAXVAL of error between both way to compute the vertical scale factors at each time step, note that we cancelled forcing (in the r12377 revision it should not change anything since water forcings such as run off and emp scale with the vertical). error between proposed and former way to compute vertical scale factors at time kt = 1, 120, 85 e3t (1) 0.0000000000000000 3999.6591076268369 4.54747350886E-013 e3t (2) 5.68434188608E-014 5.11590769747E-013 4.54747350886E-013 e3w '''4.64477238892E-007 6.13657050507E-006 5.27333801869E-006''' gde3w 1.81898940354E-012 2.72848410531E-012 2.72848410531E-012 QUESTION : Why do we have such an error on the e3w scale factors ? It is not consistent with machine accuracy error. It seems to be related to the e3w_0 computation. How do we compute e3w_0 ? OK SOLVED ! THIS IS A KIND OF ERROR IN THE CODE !!! DUE TO THE FACT THAT E3W_0(jk) != 0.5 * ( E3T_0(jk) + E3T_0(jk-1) )... Step 2 : Change the code in domvvl turn into domqe. Duplicate step.F90 into steplf.F90 and call domqe routines inside. We observe small errors but not errors at the truncature level as expected with the curent trunk version. This is due to the differences spotted above. WE CAN NO LONGER USE THE TRUNK PRODUCTION AS A REFERENCE... == Bug list - bad location of after r3 coefficient with no time splitting - some silly allocating memory bugs found - not that silly bug in implicit mode triggering for SPITZ12 configuration (Dt instead of 2Dt required) due to update BUG 1 : dom_qco_init.F90 dom_init is called before dyn_adv_init, then default value of ln_dynadv_vec is at false. r3P coefficients computation is not the same if we use flux of vector form. GYRE_PISCES runs in vector form so at the restart r3P are initialised with their flux form instead of their vector from. RESOLUTION : cpp key added key_qcoTest_FluxForm performance tests have to be done if performances are not relevant the flux from qco switch will be removed. Note that a switch as been added in dynspg_ts to compute surface average consistently with qco flux form. En gros soit on fait la distinction a chaque interpolation lineaire de la ssh soit pas du tout, il faut juste être consistent. Si les performances flux form (il y a moins de calcul) ne sont pas significatives, on pourra abandonner le calcul sinon il faudra ajouter une option de restart. Routines from domqco.F90 and dynapg_ts.F90 havs to be modified. BUG 2.1 : in dynatf_qco.F90 barotrope uub and vvb are compute with the un-filtrered scale factor BUG 2.2 : the way to compute uub and vvb with e3 from ssh/h0 is not exactly the same as the implementation of e3 filtered RESOLUTION : use filtered r3P_f and be carefull the computation has to be done exactly as in domzgr_substitute i.e. including mask and parenthesis otherwise the restartability fails in dynatf_qco.F90. BUG 3: when time splitting is not active ssh/h0 at f-points after the dynamic was not computed RESOLUTION : an extra dom_qco_r3c after dyn_spg_ts in case ln_dynspg_ts = F in stpMLF.F90 - non linear version of GYRE_PISCES shows restartability issue due to BUG 1 - ORCA2_ICE_PISCES WARNING in debug mode restartability fails it is the case even for the trunk @ 13327 need to be confirmed running tests on the current trunk when it will run... problem un PISCES/TOP solved by Christian ! " 2366 HPC-08_epico_Extra_Halo DOM trunk Unscheduled Task epico new 2020-01-07T18:01:42+01:00 2022-02-04T10:16:36+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} The task concerns the development of the extra halo management which aims at using different halo sizes in different kernels in the code ==== Workplan action Wikipage: wiki:2020WP/HPC-08_epico_Extra_Halo" 2695 ISF & key_qco compatibility + BUG in hpg_isf DYN trunk Defect gm new 2021-06-18T12:49:25+02:00 2021-11-26T15:39:01+01:00 "— 1 — ISF & key_qco compatibility There is not fundamental incompatibility between iceshelf and key_qco. Indeed, the potential issues was related to the variation of depth and e3 scale factors inside the ice-shelf. For e3 scale factors, there is no issue, since they are masked when used on ice-shelf points. For gdept, gdepw and gde3w their definition must be modified in domzgr_substitute.h90: {{{ # if defined key_isf # define gdept(i,j,k,t) ((gdept_0(i,j,k)-risfdep(i,j))*(1._wp+r3t(i,j,t))+risfdep(i,j)) # define gdepw(i,j,k,t) ((gdepw_0(i,j,k)-risfdep(i,j))*(1._wp+r3t(i,j,t))+risfdep(i,j)) # else # define gdept(i,j,k,t) (gdept_0(i,j,k)*(1._wp+r3t(i,j,t))) # define gdepw(i,j,k,t) (gdepw_0(i,j,k)*(1._wp+r3t(i,j,t))) # endif }}} NB: gdept(Kmm) has not a proper value inside the ice shelve (i.e. k < mikt) which is not an issue since gdept is masked when used inside the ice shelve. Furthermore gdept_0 should have a proper value. Indeed currently gdept_0 is computed from a call to e3_to_depth routine. This lead to an error on gdept_0 in isf case since e3w_0(mikt) /= gdept_0(mikt) - gdept_0(mikt-1). Therefore, in domzgr:zgr_read we add : {{{ #if defined key_qco && key_isf ! ! QCO & ISF: adjust the calculation of T-point depth done in e3_to_depth subroutine DO_3D( 1, 1, 1, 1, 2, jpk ) ! vertical sum at partial cell xxxx other level IF( jk == (ji,jj) ) THEN ! first ocean point : partial cell gdept_0(ji,jj,jk) = gdepw_0(ji,jj,jk ) + 0.5_wp * e3w_0(ji,jj,jk) ! = risfdep + 1/2 e3w_0(mikt) ELSE ! other level gdept_0(ji,jj,jk) = gdept_0(ji,jj,jk-1) + e3w_0(ji,jj,jk) ENDIF END_3D #endif }}} — 2 — small BUG in hpg_isf (vvl case) There is a bug in dynhpg:hpg_isf for open ocean grid point. The density anomaly (zrhdtop_oce) used to compute the pressure gradient at level jk=1 (ocean point without an ice shelf above) is risfdep which is equal to zero for a surface ocean point. It should be equal to gdept(:,:,1). Bug Fix : replace CALL eos( zts_top, risfdep, zrhdtop_oce ) by : DO ji = 1, jpi DO jj = 1, jpj ikt = mikt(ji,jj) zdep_top(ji,jj) = MAX( risfdep(ji,jj) , gdept(ji,jj,1,Kmm) ) END DO END DO CALL eos( zts_top, zdep_top, zrhdtop_oce ) " 2651 KNL-03_Young_Bell_HPG_Schemes DYN trunk Unscheduled Task ayoung new 2021-04-07T15:46:33+02:00 2022-01-14T12:05:56+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2021WP/KNL-03_Young_Bell_HPG_Schemes " 2619 u/tau misisng from outputs with key_qco DYN trunk Bug smasson new 2021-02-08T11:19:52+01:00 2021-02-17T17:19:33+01:00 " ==== Context u/vtau variables in output files are flagged to the missing value everywhere when using key_qco ==== Analysis The call to iomput of u/vtau is missing in the new routine dynatf_qco called by stpmlf when using key_qco... I don't know why... Is this just a missing piece or there is another idea? ==== Fix but it back if this is just a missing piece " 2546 Double count of runoffs in the variable volume (vvl) case DYN trunk Defect Robin_Waldman new 2020-10-13T09:45:22+02:00 2020-10-13T09:45:22+02:00 " ==== Context I am diagnosing the 3D salinity trend in NEMO v3.6 with variable volume (z star coordinate), time splitting, with a runoff depth specification (ln_rnf_depth_ini = .true. and rn_dep_max = 10.). ==== Analysis In the case of a river runoff with no salt content, the runoff causes a negative salinity trend through the divergence of the vertical velocity which causes a dilution of salt. This dilution effect is applied over the depth controlled by rn_dep_max in the routine dom_vvl_sf_nxt which is called in the routine div_cur updating the divergence hdivn. However, the runoff dilution effect is accounted for a second time in the update of the vertical scale factor fse3t_a performed in the routine dom_vvl_sf_nxt. Indeed, the fse3t_a update is proportional to the sea surface height variation, itself accounting for the net volume flux at the surface (runoff plus emp). In the end, the vertical velocity update of routine wzv counts emp once through the fse3t_a update, but it counts the runoff twice through both the hdivn and fse3t_a updates. ==== Recommendation Unless I am missing something, there seems to be a double count of the dilution effect induced by runoff in the variable volume case. If this is the case, my recommendation is to remove the runoff effect from the sea surface height variation in the update of vertical velocities (e.g. computing a temporary after vertical scale factor that removes the effect of runoff on sea surface height variations). If I have missed something, I would be very happy to have a clearer explanation than section 7.9 of the NEMO user book which I found confusing. Thanks a lot! ... " 2485 Add an Shallow Water Eq. (SWE) based on NEMO ocean kernel + associated test case DYN v4.0.* Unscheduled Task gm new 2020-06-10T11:58:56+02:00 2021-04-14T13:05:07+02:00 " ==== Workplan action Create a Shallow Water Eqs. model based on the OCEan kernel. Usage : teaching purposes as well as developments of numerical schemes (e.g. RK3.) Wikipage: wiki:2020WP/KERNEL-07_Gurvan_ShallowWater" 2755 Wrong use of fs_2/fs_jpim1 indexes env v4.0.* Bug emalod new 2022-01-28T10:59:13+01:00 2022-01-28T10:59:13+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context The key_vectopt_loop cpp key forces some spatial loops to perform computations in the halos (fs_2/fs_jpim1 indexes). This is supposed to have an effect on vectorisation. Recent tests (2021) have shown rather limited effect on NEC SX-Aurora-TSUBASA machines ==== Analysis Some loops are wrongly bounded by fs_2/fs_jpim1 indexes, which lead to array overflow (e.g. dommsk : umask(ji,jj,jk) = tmask(ji,jj ,jk) * tmask(ji+1,jj ,jk) ) ==== Fix Check where fs_2/fs_jpim1 are used and make correction (or remove the key_vectopt_loop cpp key) " 2603 False positives from search patterns in makenemo can lead to corruption of work_cfgs.txt env Bug dlivings new 2021-01-22T20:51:53+01:00 2021-01-22T20:51:53+01:00 In the current version of makenemo (last changed at [14198]), there are grep statements at lines 254, 264, and 273 and a sed statement at line 281 that search the file work_cfgs.txt for the configurations specified by the -r or -n options. Because of the way the search patterns are implemented, these searches can return multiple matches if one configuration name ends in the name of another. For example, I have a configuration DML_ORCA2_SAS_ICE that is my modification of the reference configuration ORCA2_SAS_ICE. These multiple matches can lead to corruption of work_cfgs.txt (as I have experienced). The simplest fix is to insert a caret (!^) at the start of each search pattern to anchor it at the beginning of the line. 2436 VALID-12_clevy_Trusting_ContinuousIntegration env v4.0.* Unscheduled Task clevy new 2020-04-07T09:35:15+02:00 2021-04-14T13:05:07+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2020WP/VALID-12_clevy_Trusting_ContinuousIntegration === Related tickets: #1640 #1644" 2580 Missing iceberg restart in default configurations ICB trunk Defect smueller new 2020-11-24T11:07:26+01:00 2020-11-24T12:44:02+01:00 "==== Context Default configurations with enabled icebergs (`ln_icebergs = .true.` in namelist `&namberg`) initially generate ""test icebergs"" as `nn_test_icebergs=10` in file `namelist_ref`. Such configurations, however, do not seem to restart icebergs. In order to enable the restart mechanism of the ICB component, `nn_test_icebergs` can be set to a value of less than '1' in restart configurations. This behaviour is not intuitive and can lead to the incorrect assumption of active ICB restarting in long model runs. ==== Analysis When ""test icebergs"" are enabled (`ln_test_icebergs > 0`), a reset of the iceberg distribution is triggered during the model restart (source:/NEMO/trunk/src/OCE/ICB/icbini.F90@13295#L282). ==== Recommendation The conditional at source:NEMO/trunk/src/OCE/ICB/icbini.F90@13295#L282 appears to be superfluous and could be removed to enable ICB restarts in default configurations (this would also permit the removal of the `ln_test_icebergs` modification in the `SHORT` configuration for the SETTE `ORCA2_ICE_PISCES` restartability test at source:/utils/CI/sette/sette_reference-configurations.sh@13790#L406). Alternatively, the default value of `nn_test_icebergs` could be changed to `0` in source:/NEMO/trunk/cfgs/SHARED/namelist_ref (in which case, the `ORCA2_ICE_PISCES` SETTE tests would have to be adjusted to enable an ICB initialisation that is appropriate for the tests). " 2493 Out-of-bounds error in ORCA2-based mono-processor configuration ICB trunk Bug smueller new 2020-06-24T14:04:24+02:00 2020-07-08T12:23:43+02:00 "==== Context The out-of-bounds array access in mono-processor configurations and the use of incorrect grid types in `lbc_lnk_icb` calles described in ticket #2492 are also present in the current trunk version of NEMO. ==== Analysis See ticket #2492. ==== Fix See ticket #2492. " 2467 ICB namelist confusing ICB trunk Unscheduled Defect mathiot new 2020-05-15T18:37:40+02:00 2021-03-22T17:03:26+01:00 "==== Context By looking at SETTE, Seb spotted that ORCA2 LONG/SHORT have different icb settings and magically gave the same answer. After looking at it in more detailed, this was normal but I found it very confusing. ==== Analysis Namelist ref controlling the icb initiialisation: {{{#!f nn_test_icebergs = 10 ! Create test icebergs of this class (-1 = no) ! ! Put a test iceberg at each gridpoint in box (lon1,lon2,lat1,lat2) rn_test_box = 108.0, 116.0, -66.0, -58.0 ln_use_calving = .false. ! Use calving data even when nn_test_icebergs > 0 }}} So by default if you switch of the iceberg, you use the test functionality and you don't read a calving file. In icbini, nn_test_icebergs = -1 and ln_use_calving have a similar effect => trigger the reading of the calving file: {{{#!f ! when not generating test icebergs we need to setup calving file IF( nn_test_icebergs < 0 .OR. ln_use_calving ) THEN }}} In icbini, if we want to read the icb restart, we need to set nn_test_icebergs <= 0. {{{#!f IF( .NOT.ln_rstart ) THEN IF( nn_test_icebergs > 0 ) CALL icb_ini_gen() ELSE IF( nn_test_icebergs > 0 ) THEN CALL icb_ini_gen() ELSE CALL icb_rst_read() l_restarted_bergs = .TRUE. ENDIF ENDIF }}} And if you want to initialized with icebergs (test), and let the model go using restart without a calving file defined it seems you need to set nn_test_icebergs = 0. Extra suggestion: being able to read an initial file (basically an old restart even is NEMO does not start using restart), this will decrease the spinup time of the icebergs ==== Suggestion All of this looks very confusing and possible source of unwanted behavior. I suggest to change the namelist_ref (and the code will need to be change accordingly): {{{#!f ln_use_test = .false. ! use the testing capacity nn_test_icebergs = 0 ! Create test icebergs of this class (need to be larger than 1) rn_test_box = 0.0, 0.0, -90.0, -90.0 ! Put a test iceberg at each gridpoint in box (lon1,lon2,lat1,lat2) ln_test_rst = .false. ! do not read a restart file when ln_use_test = .true., seed icb in the testing box instead. ln_use_calving = .false. ! read a calving file sn_icb = '', '', ... ! calving file definition ln_icb_init = .false. ! read icb from a previous restart (only used when the master flag ln_rstart is false) cn_icbini= 'icbinit.nc' ! icb restart name }}} By default both flag ln_use_test and ln_use_calving are false and NEMO should STOP. Then you choose what you want, and if you activate both, you initialized the icb as defined by the test and read a calving file" 2566 excessive memory use in iom_def IOM trunk Defect smasson new 2020-11-10T16:05:31+01:00 2020-11-10T16:05:31+01:00 " ==== Context In iom_def, we define the structures that will be used to read/write NetCDF files. To do so, we use some parameter that are hard coded : {{{#!fortran INTEGER, PARAMETER, PUBLIC :: jpmax_files = 100 !: maximum number of simultaneously opened file INTEGER, PARAMETER, PUBLIC :: jpmax_vars = 1200 !: maximum number of variables in one file INTEGER, PARAMETER, PUBLIC :: jpmax_dims = 4 !: maximum number of dimensions for one variable }}} We use them to define a structure, called “file_descriptor”, that will contain some of the NetCDF header informations. Among them we have several arrays: {{{#!fortran CHARACTER(LEN=32), DIMENSION(jpmax_vars) :: cn_var !: names of the variables INTEGER, DIMENSION(jpmax_vars) :: nvid !: id of the variables INTEGER, DIMENSION(jpmax_vars) :: ndims !: number of dimensions of the variables LOGICAL, DIMENSION(jpmax_vars) :: luld !: variable using the unlimited dimension INTEGER, DIMENSION(jpmax_dims,jpmax_vars) :: dimsz !: size of variables dimensions REAL(kind=wp), DIMENSION(jpmax_vars) :: scf !: scale_factor of the variables REAL(kind=wp), DIMENSION(jpmax_vars) :: ofs !: add_offset of the variables }}} ==== Analysis In i4r8 precision, this represents ~(jpmax_dims/2+3) real arrays of jpmax_vars points. We next define an array of this structure: {{{#!fortran TYPE(file_descriptor), DIMENSION(jpmax_files), PUBLIC :: iom_file !: array containing the info for all opened files }}} This is equivalent to a total number of real8 points of ~ (jpmax_dims/2+3) * jpmax_vars * jpmax_files = 5 * 1200 * 100 If I made no mistakes, '''this is the equivalent of:''' - '''1 3D array with jpi = 90, jpj = 90 and jpk = 75''' - '''9 3D arrays with jpi = 30, jpj = 30 and jpk = 75''' - '''81 3D arrays with jpi = 10, jpj = 10 and jpk = 75''' ==== Recommendation We should review the way we define this structure array... - I think the large value for jpmax_vars comes from the 4D arrays that are written/read as different 3D arrays. => we could accept 4D arrays definition to avoid this. - jpmax_files = 100 looks a large number to me... - use allocatable variables would be better, adapting jpmax_vars to each file (easy in read mode, more difficult in write mode?) " 2543 More flexibility in the restart name numbering ? IOM trunk Request mathiot new 2020-10-06T16:25:46+02:00 2020-12-04T11:41:35+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Default NEMO restart numbering is time-step based: {{{#!f clname = TRIM(cexper)//""_""//TRIM(ADJUSTL(clkt))//""_""//TRIM(cn_ocerst_out) }}} Some users (UKMO at least) need a date based numbering (ln_rstdate): {{{#!f ! beware of the format used to write kt (default is i8.8, that should be large enough...) IF ( ln_rstdate ) THEN zfjulday = fjulday + rdt / rday IF( ABS(zfjulday - REAL(NINT(zfjulday),wp)) < 0.1 / rday ) zfjulday = REAL(NINT(zfjulday),wp) ! avoid truncation error CALL ju2ymds( zfjulday, iyear, imonth, iday, zsec ) WRITE(clkt, '(i4.4,2i2.2)') iyear, imonth, iday ELSE IF( nitrst > 999999999 ) THEN ; WRITE(clkt, * ) nitrst ELSE ; WRITE(clkt, '(i8.8)') nitrst ENDIF ENDIF ! create the file clname = TRIM(cexper)//""_""//TRIM(ADJUSTL(clkt))//""_""//TRIM(cn_ocerst_out) }}} Other prefer a numbering nn_no based (DRAKKAR): {{{#!f !{ DRAKKAR modification : NEMO reads restart files : ! .<>/-<>_.nc ! Add extension (job number to the restart dir. Differ for restart input and restart output WRITE(cl_no,*) nn_no-1 ; cl_no = TRIM(ADJUSTL(cl_no) ) cn_ocerst_indir=TRIM(cn_ocerst_indir)//'.'//TRIM(cl_no) cn_ocerst_in= TRIM(cn_ocerst_in)//'-'//TRIM(cl_no) ! DRAKKAR modification : NEMO writes restart files : ! .<>/-<>_.nc WRITE(cl_no,*) nn_no ; cl_no = TRIM(ADJUSTL(cl_no) ) cn_ocerst_outdir=TRIM(cn_ocerst_outdir)//'.'//TRIM(cl_no) cn_ocerst_out= TRIM(cn_ocerst_out)//'-'//TRIM(cl_no) !} }}} These 3 possibilities cover time-step, date and leg number. I think with this we cover a lot of the possible choice. Maybe a fourth one is needed: - namelist only (ie the user manages the entire name within the namelist via its submission script). ==== Analysis - More flexibility in the restart name numbering could ease the user life when coming the time to upgrade to a new version (less file NEMO source file to manage) " 2423 ln_mskland=T mask the under ice shelf seas in model ouput IOM v4.0.* Bug cbricaud new 2020-03-28T06:52:33+01:00 2020-12-11T16:45:41+01:00 " ==== Context I run EORCA025 with with ISF. Under ice shelf seas are masked in model outputs when ln_mskland=T. I created the meshmask.nc. tmask is ok: under ice shelf seas are not masked. ==== Analysis I had a look in NEMO. In iom.F90 routine/ set_grid subroutine, tmask is sent to xios for land masking. Is there something else in XIOS? ==== Fix ... " 2722 Branch to import 3rd party GEOMETRIC development LDF v4.0.* Unscheduled Task acc new 2021-09-14T15:50:55+02:00 2021-09-15T19:04:53+02:00 " Plan: Create a branch of 4.0-HEAD (initially equivalent to r4.0.6) to incorporate Julian Mak's GEOMETRIC code. GEOMETRIC is an approach to representing the unresolved turbulent eddies in ocean climate models. and is well introduced here: https://nemo-related.readthedocs.io/en/latest/GEOMETRIC/geometric.html Once fully tested, this code will be ported to in a 2021 or 2022 development branch for a future trunk release." 2601 MOI-01_MOI-GRIFFIESTRIADSMOOTHING LDF trunk Unscheduled Task cbricaud new 2021-01-20T10:07:31+01:00 2022-01-14T12:04:58+01:00 " ==== Workplan action Wikipage: wiki:2021WP//MOI-01_MOI-GRIFFIESTRIADSMOOTHING " 2739 diurnal cycle in TOP MULTIPLE Bug cperruche new 2021-11-04T16:45:39+01:00 2021-12-22T10:38:31+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Boolean l_trcdm2dc depends on boolean ln_dm2dc defined in namelist. It aims at averaging qsr for biogeochemical tracers if there is a diurnal cycle. ==== Analysis (1) The name of the boolean ""l_trcdm2dc"" is confusing because it has the opposite function to the boolean ln_dm2dc. I suggest to call it ""l_trcdc2dm"" instead. (2) Currently, the daily mean on qsr for biogeochemical purposes only works if ln_dm2dc=T that is to say if there is an analytical diurnal cycle. It does not work if there is a natural diurnal cycle with hourly atmospherical forcings for example. I suggest to define a new boolean in namelist_top ""ln_trcdc2dm"" (instead of the internal boolean l_trcdc2dm) to specify if you want to average qsr or not for biogeochemical tracers => modify trcnam.F90 to read a new parameter (3) If the analytical diurnal cycle is used (ln_dm2dc=T and ln_trcdc2dm=T), we should keep the mean value in qsr_mean (no need to call subroutine trc_mean_qsr) => modifications in sbcblk.F90 and trcstp.F90 ==== Fix In trcstp:F90: No need anymore of this part of the code {{{#!f SUBROUTINE trc_stp_ctl !!---------------------------------------------------------------------- !! *** ROUTINE trc_stp_ctl *** !! ** Purpose : Control + ocean volume !!---------------------------------------------------------------------- ! ! Define logical parameter to control diurnal cycle in PISCES l_trcdm2dc = ( l_trcdm2dc .AND. .NOT. ln_dm2dc ) .OR. ( ln_cpl .AND. ncpl_qsr_freq /= 1 .AND. ncpl_qsr_freq /= 0 ) l_trcdm2dc = l_trcdm2dc .AND. .NOT. l_offline .AND. ln_pisces ! IF( l_trcdm2dc .AND. lwp ) CALL ctl_warn( 'Coupling with passive tracers and diurnal cycle of shortwave radiation.', & & 'Computation of a daily mean shortwave for PISCES biogeochemical model ' ) ! END SUBROUTINE trc_stp_ctl }}} and we call trc_mean_qsr only if (ln_dm2dc=F and ln_trcdc2dm=T) {{{#!f IF( ln_trcdc2dm .AND. .NOT. ln_dm2dc ) CALL trc_mean_qsr( kt ) }}} In sbcblk.F90, I would add: {{{#!f #if defined key_top USE trc #endif }}} and {{{#!f #if defined key_top IF( ln_dm2dc .AND. ln_trcdc2dm ) THEN qsr_mean(:,:) = zztmp * pdqsr(:,:) * tmask(:,:,1) ENDIF #endif }}} " 2711 KNL-04_ONeill_2D_mode MULTIPLE trunk Unscheduled Task clne new 2021-07-23T16:34:14+02:00 2022-01-14T12:04:58+01:00 "2D mode for applications such as surge modelling ==== Workplan action Wikipage: wiki:2021WP/KNL-04_ONeill_2D_mode " 2691 Weighted interpolation for the initiale conditions and the bdy MULTIPLE v4.0.* Request lambertn new 2021-06-16T21:46:05+02:00 2021-06-22T19:55:00+02:00 "==== Context I change the code in NEMO4.0 so it is now possible to use the weight files to do an interpolation ""on-the-fly"" for the initial conditions and the bdy values (3D fields). It was already possible to use this feature for the atmospherics forcing but the operation was not available for those inputs. The land/sea mask and the vector pairing options were implemented as well. To pair u2d and u3d separately, simply used different keyword starting with U and V (e.g., U_2d <=> V_2d ; U_3d <=> V_3d ). To activate, simply add the relevant key words in the last 3 available slots when defining the input parameters (same way as the atm. conditions). IMPORTANT : for the bdy, the weight files need to cover the entire domain. The simplest way to do it is to use the same weight files as the initial conditions. And I made the vertical interpolation available for the initial conditions (via ln_zinterp) and it works like for the bdy (gdep[tuv] and e3[tuv] need to be present in the inputs files). Both options, the weight files and the vertical interpolation, can be activated at the same time so inputs fields with a different horizontal grid and different vertical divisions and be automatically integrated in the simulation. But in that case, the land/sea mask and nn_lsm>0 are almost mandatory to avoid using dry cells in both horizontal or vertical interpolation. ==== Proposal I had some variables in the namelist as follows : {{{#!diff &namtsd ! Temperature & Salinity Data (init/dmp) (default: OFF) +++ nn_lsm = 0 +++ ln_zinterp = .false. / }}} {{{#!diff &nambdy_dta +++ nn_lsm = 0 / }}} Those variables are used in other groups of the namelist (e.g. &namsbc) but they need to be specified again for the istate and the bdy so values can be different. ----------------- I made changes in those files to integrate the new functionality (files coming soon in a tar) : minor changes : bdydta.F90, dtatsd.F90, istate.F90, sbcblk.F90, sbcflx.F90 major changes : fldread.F90 Some comments : This functionality is working well but some rough edges could be smoother. Particularly the way the fldread routine deals with the 2D fields that could have a z dimension of ""one"". And the land/sea mask need to be the same dimension as the variable (u2d => 2D, u3d => 3D) and this could be changed to use the 3D mask for all the variables (2D => only take the top layer). And overall, there can be more ""diagnostic message"" around this feature so the user will be advice when the option are misaligned. " 2682 Failing SETTE tests with debug flags and `nn_hls = 1` MULTIPLE trunk 2021 WP Bug hadcv new 2021-05-28T12:35:17+02:00 2022-02-04T10:16:59+01:00 "Four configurations fail in SETTE when using debug flags (XC40_METO_IFORT with `%FCFLAGS` from X64_IRENE_DEBUG) and `nn_hls = 1`: * `ICE_AGRIF` (r14820 and r14903) XIOS floating point exception when calling `iom_put` on ""icesalt"" in [http://forge.ipsl.jussieu.fr/nemo/browser/NEMO/trunk/src/ICE/icewri.F90?rev=14903#L119 icewri.F90]. All points in the array have value 1e20, so I suspect this is related to using `detect_missing_values=""true""` in the field_def.xml, which converts values equal to `default_value` (= 1e20 here) to NaN. Amy Young encountered this issue with the Cray compiler for various SETTE configurations using SI3. XIOS either has to be compiled with -O1 or `detect_missing_values=""false""` must be set. This suggests that XIOS is not masking NaN data prior to output. This might also explain #2668. Possibly this is related to XIOS ticket [http://forge.ipsl.jussieu.fr/ioserver/ticket/136 #136]. **FIX**: Compile XIOS with -O1 * `SWG` (r14820 and r14903) Floating point exception due to`r1_s0` being undefined in `eos_pt_from_ct` when called from [http://forge.ipsl.jussieu.fr/nemo/browser/NEMO/trunk/src/OCE/SBC/sbcssm.F90?rev=14903#L243 sbc_ssm_init]. This is because `eos_init` is not called in [http://forge.ipsl.jussieu.fr/nemo/browser/NEMO/trunk/src/SWE/nemogcm.F90?rev=14903#L300 SWE/nemogcm.F90]. **FIX**: ??? * `AMM12` (r14903) Floating point exception due to `ustar2_surf` being undefined on halo points in [http://forge.ipsl.jussieu.fr/nemo/browser/NEMO/trunk/src/OCE/ZDF/zdfgls.F90?rev=14903#L209 zdfgls.F90]. **FIX**: Replace the inline `A2D` with a `DO_2D( nn_hls-1, nn_hls-1, nn_hls-1, nn_hls-1 )` * `AGRIF_DEMO` (r14903) Floating point exception due to `pW` being undefined on halo points in [http://forge.ipsl.jussieu.fr/nemo/browser/NEMO/trunk/src/OCE/TRA/traadv_ubs.F90?rev=14903#L205 traadv_ubs.F90]. **FIX**: Reduce the bounds of DO loops involved in the calculation of `ztw` from `(1, 1, 1, 1)` to `(0, 0, 0, 0)`. " 2650 VLD-07_Bricaud_Samson_ORCA4-12-36 MULTIPLE trunk Unscheduled Task gsamson new 2021-04-06T16:07:59+02:00 2022-01-14T12:04:58+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2021WP/VLD-07_Bricaud_Samson_ORCA4-12-36 " 2634 KNL-02_Jerome_RK3_stage1_tsplit MULTIPLE trunk Unscheduled Task jchanut new 2021-03-02T15:32:02+01:00 2022-01-14T12:05:56+01:00 "Re-factorize split-explicit free surface to ease the integration of RK3 (and AGRIF) ==== Workplan action Wikipage: wiki:2021WP/KNL-02_Jerome_RK3_stage1_tsplit " 2611 NEC SX Aurora porting MULTIPLE trunk Defect emalod new 2021-01-28T15:04:27+01:00 2021-01-28T15:04:27+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context 2 compilation or runtime errors pop up when using Vector Engine compiler on NEC SX Aurora ==== Analysis 1- in nemogcm.F90, the instruction : CALL ctl_opn(numnul, '/dev/null', 'REPLACE', 'FORMATTED', 'SEQUENTIAL', -1, -1, .FALSE. ) leads to a runtime error because the FORTRAN norm for 'REPLACE' option implies to remove the file before beeing rewritten, and it is impossible to remove /dev/null 2- in stpctl.F90, the ISNAN function is not identified by the compiler. ==== Recommendation 1. none 2. may be replaced by ieee_is_nan but I am not sure of the portability " 2605 KNL-01_Sibylle_RK3_stage1 MULTIPLE trunk Unscheduled Task techene new 2021-01-27T15:55:02+01:00 2022-01-14T12:05:56+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2021WP/KNL-01_Sibylle_RK3_stage1 " 2596 VLD-01_ClaireLevy_ORCA2_ICE_PISCES MULTIPLE trunk Unscheduled Task clevy new 2021-01-13T09:41:32+01:00 2022-01-14T12:04:58+01:00 " ==== Workplan action Wikipage: wiki:2021WP/VLD-01_ClaireLevy_ORCA2_ICE_PISCES " 2541 management of usr_*.F90 MULTIPLE trunk Defect mathiot new 2020-10-06T12:11:07+02:00 2020-10-06T12:11:07+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context and suggestions After the ticket #2515, I realised, that: - usr_def_fmask code cannot be switch off/on in the namelist. So it is always 'on'. => it means it is not a 'usr' code but a 'compulsory' code. Probably a namelist logical flag to activate it 'on' or 'off' could be useful. (I didn't check the call to the other 'usr' code). {{{#!f 227 ! User defined alteration of fmask (use to reduce ocean transport in specified straits) 228 ! -------------------------------- 229 ! 230 CALL usr_def_fmask( cn_cfg, nn_cfg, fmask ) 231 ! 232 END SUBROUTINE dom_msk }}} - in general, 'usr' modules are doing something by default. Should the default be: the usr code is doing stoping the model (everything commented to not loose code with a ctl_stop (STOP,'empty usr routine: something is not right. please check namelist_cfg or usr_xxxx routines') and always activated it in namelist_ref. This will enforce the user to decide (switch on the read of domain_cfg file in namelist_ctl for example) or write in the 'usr' module what he really wants. A bit like in the namelist_ref where option are set to OFF or .false. ? " 2536 MY_SRC of ISOMIP+ MULTIPLE trunk Defect smasson new 2020-10-02T11:07:57+02:00 2020-10-09T14:04:16+02:00 " ==== Context The MY_SRC of ISOMIP+ contains many duplicated routines that have not been correctly phased with their src equivalent. For example, the Current version is not compliant with the new definition of gdept in domzgr_substitute. It does not pass sette tests in debug mode. ==== Analysis The duplication of routines has been introduced in NEMO with the MY_SRC directories and the use of different src/* directories but this is ALWAYS a bad solution. I am spending days phasing duplicated routines that are always forgotten either by the developers or during the svn merge procedure... ==== Recommendation We must avoid duplicated routines. For example in this case I don't understand why there is duplicated eosbn2, why proper nameliste parameters of ln_seos cannot give the same results as ln_eos? Why istate, dtatsd are duplicated? We should adapt the original routines instead of duplicating routines. " 2508 TOP-05_Ethe_Agrif MULTIPLE trunk Unscheduled Task cetlod new 2020-08-03T10:54:38+02:00 2021-04-14T13:04:08+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2020WP/TOP-05_Ethe_Agrif" 2511 New developments of PISCES PISCES trunk Unscheduled Task aumont new 2020-08-17T15:24:18+02:00 2022-01-14T12:04:58+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} This branch includes the new developments planned to be included in the standard version of PISCES." 2319 Create dev branch for PISCES-QUOTA improvments PISCES trunk Unscheduled Task cetlod new 2019-10-17T11:48:30+02:00 2020-03-28T12:30:31+01:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Context ... ==== Proposal ... " 2524 sao_read not compiling SAO trunk Bug smasson new 2020-09-16T12:46:45+02:00 2020-09-16T12:46:45+02:00 " ==== Context sao_read not compiling ==== Analysis sao_read is using tsn that is no more existing... ==== Fix ... " 2756 wrong stress in sbcflx.F90 SBC v4.0.* Bug clem new 2022-02-01T11:25:24+01:00 2022-02-01T17:46:52+01:00 "In sbcflx.F90, the module of the stress is half what it should be (following a bug fix in version 4.2) This line: {{{#!fortran zmod = 0.5_wp * SQRT( ztx * ztx + zty * zty ) * tmask(ji,jj,1) }}} should be: {{{#!fortran zmod = SQRT( ztx * ztx + zty * zty ) * tmask(ji,jj,1) }}} " 2667 improve fld_read time management SBC trunk Request gsamson new 2021-05-07T17:25:17+02:00 2022-02-17T18:58:04+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context ""fld_read"" routine always considers that the field timestep is centred on the middle of the time window separating two successive fld_read calls. This is usually true when the field is a time-averaged variable valid at the middle of the corresponding time bounds. But in the case of instantaneous fields, they are valid at the exact timestep of the fld_read call. Consequently, fld_read shifts the field valid timestep by half its frequency, which is wrong and can significantly offset atmospheric forcings for example. ==== Proposal introduce a new argument in fld_read structure to specify whether the field read by fld_read is (time-)averaged or instantaneous, and shift field valid timestep accordingly in fld_read. " 2632 new expression to compute air and surface potential temperatures in bulk formulae SBC trunk Bug gsamson new 2021-02-26T18:22:15+01:00 2021-11-30T12:25:21+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context & Analysis The actual ""gamma_moist"" function used to convert air absolute temperature to potential temperature can be replaced by the ""Exner"" function, which takes into account air pressure variations and is commonly employed in atmospheric models, as well as the ABL model. This potential temperature is used in the turbulent sensible heat flux calculation, as well as the atmospheric bulk Richardson number. ==== Fix replace ""gamma_moist"" function by a ""Exner"" function in sbc_phy.F90 and introduce a new function to compute air pressure from other available atmospheric variables. " 2630 VLD-04_Mueller_Tides SBC trunk Unscheduled Task smueller new 2021-02-19T19:46:12+01:00 2022-01-14T12:04:58+01:00 "==== Workplan action Wikipage: wiki:2021WP/VLD-04_Mueller_Tides " 2540 add a fwb scheme without any bouyancy flux ? SBC trunk Request mathiot new 2020-10-05T17:52:27+02:00 2020-12-04T11:38:49+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context NEMO is able to check and correct the fresh water budget. The correction of the fw budget is done via the 'emp' variable. This leads to creation of a bouyancy flux. For some applications, it could be handy to simply get rid of the unbalance in the fw budget without creation of a bouyancy flux (to avoid spurious convection for example). This can simply be done by adding a corrective salt content flux (similar to what is done for the heat) in sbcfwb.F90. An example is available in ISOMIP+/MY_SRC ==== Analysis If the option of having this extra choice in sbcfwb retained, how to do it: - adding a fourth choice in nn_fwb (namsb namelist block) => the easiest (as in ISOMIP+) - adding a flag ln_fwb in namsbc (maybe more in the philosophy of namsbc) and a namelist block namsbc_fwb with nn_fwb and a logical flag ln_nobouy (?) to remove any bouyancy flux due to the fwb correction. " 2379 VALID-11_clevy_OASIS_TESTCASE SBC trunk Unscheduled Task clevy new 2020-02-11T10:34:12+01:00 2021-04-14T13:04:08+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2020WP/VALID-11_clevy_OASIS_TESTCASE" 2363 VALID-08_gsamson_ORCA-ABL-BLK SBC trunk Unscheduled Task gsamson new 2020-01-06T14:56:01+01:00 2021-04-14T13:05:07+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2020WP/VALID-08_gsamson_ORCA-ABL-BLK" 2158 ASINTER-03_laurent_bulk_and_wave SBC trunk Unscheduled Task laurent new 2018-11-07T15:51:30+01:00 2021-04-14T13:05:07+02:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Context ... ==== Proposal ... " 2757 Adding an lbc_lnk changes results in NEMO4.0.4 at ORCA025 SI3 v4.0.* Bug timgraham new 2022-02-14T09:38:58+01:00 2022-02-22T15:50:17+01:00 "==== Context While investigating a restartability issue in our coupled model at NEMO4.0.4 I discovered some unexpected behaviour, where adding an extra lbc_lnk on ub and vn at the end of dynnxt changed the results of the model. As the difference originates along the north fold, I suspect that this is only a problem on the ORCA025 and ORCA12 grids. ==== Analysis In SBC {{{ssu_m=ub(:,:,1)}}} and in SI3 {{{u_oce=ssu_m}}}. The change in the results occurs in ice_dyn_rhg_evp where the variable u_oce is used. u_oceV is calculated as: {{{u_oceV(ji,jj) = 0.25_wp * ( u_oce(ji,jj) + u_oce(ji-1,jj) + u_oce(ji,jj+1) + u_oce(ji-1,jj+1) ) * vmask(ji,jj,1)}}} in a do loop from {{{j=2,jpjm1}}}. At at least one grid point along the north fold (in processors on the right hand side of the grid) I found that the value of u_oce(ji,jj+1) changes if an lbc_lnk is added on ub. ==== Recommendation If it is confirmed that this is a general problem and not caused by a Met Office branch then an lbc_lnk call needs to be included. Longer term, I wonder if it would be possible to test both types of north fold setup in routine testing. " 2668 "SI3 + nn_hls>1 crashes with ""-init=arrays,snan,huge"" compil options" SI3 trunk Bug gsamson new 2021-05-10T17:12:04+02:00 2021-06-16T08:44:03+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context run SETTE ORCA2_ICE_PISCES config with ""-init=arrays,snan,huge"" as compilation option on recent trunk revision ==== Analysis SI3 uses some array operations instead of do-loops (at least in ""icedyn_adv_pra"" and ""icedyn_rhg_*"" routines), which causes floating errors due to unitialized halos values operations ==== Fix replace array operations by do-loops dealing properly with variable halos sizes " 2627 sea-ice bug when using conduction flux instead of solar/non-solar SI3 v4.0.* Bug clem new 2021-02-18T14:19:52+01:00 2021-03-05T23:36:53+01:00 " ==== Context There is a series of bugs related to sea-ice when using conduction flux as an input instead of regular solar and non-solar fluxes. It is only tested without really being used in NEMO forced setup. It affects simulations using Jules interface as done by the Met-Office ==== Analysis 1) In forced mode, when emulating the conduction flux, one should calculate this flux by calling the routine blk_ice_qcn. It is not the case. 2) The heat budget is not designed for dealing with conduction fluxes. So, in iceupdate.F90 it is wrong to state that qt_atm_oi = qns_tot + qsr_tot ==== Fix -- 1) -- In icesbc.F90, replace these lines: {{{#!fortran IF( ln_cndflx .AND. .NOT.ln_cndemulate ) & & CALL blk_ice_qcn ( ln_virtual_itd, t_su, t_bo, h_s, h_i ) }}} by {{{#!fortran IF( ln_cndflx .AND. ln_cndemulate ) & & CALL blk_ice_qcn ( ln_virtual_itd, t_su, t_bo, h_s, h_i ) }}} Also, in icethd_dh.F90, replace these lines: {{{#!fortran IF( ln_cndflx .AND. .NOT.ln_cndemulate ) THEN ! DO ji = 1, npti zq_top(ji) = MAX( 0._wp, qml_ice_1d(ji) * rdt_ice ) END DO }}} by {{{#!fortran IF( ln_cndflx ) THEN ! DO ji = 1, npti zq_top(ji) = MAX( 0._wp, qml_ice_1d(ji) * rdt_ice ) END DO }}} And finally, I do not see why we need to pass 2 times in icethd_zdf_bl99 when conduction flux is emulated. I would suppose that once conduction flux has been evaluated in blk_ice_qcn, it is not necessary to go through the bl99 routine 2 times. But I need some input from Martin on that. Should we replace: {{{#!fortran ELSEIF( ln_cndflx .AND. ln_cndemulate ) THEN ! Conduction flux is emulated CALL ice_thd_zdf_BL99( np_cnd_EMU ) CALL ice_thd_zdf_BL99( np_cnd_ON ) }}} by {{{#!fortran ELSEIF( ln_cndflx .AND. ln_cndemulate ) THEN ! Conduction flux is emulated CALL ice_thd_zdf_BL99( np_cnd_ON ) }}} -- 2) -- qns_ice and qsr_ice made no sense when forcing with conduction fluxes. There is 2 solutions and I am still unsure whether we should change the surface heat budget in the ice code to concur with the ""conductive flux"" formulation or to simulate a qns_ice+qsr_ice from qcn and qml. I think the final solution is to change the ice code. I guess the right solution for qt_atm_oi is something like (though I am not sure): {{{#!fortran qt_atm_oi = ( 1 - a ) * ( qns_oce + qsr_oce ) + qemp_oce & & + a * ( qcn_ice + qml_ice + qtr_ice_top ) + qemp_ice }}} " 2590 How to shift ice properties among categories SI3 Task vancop new 2020-12-03T14:10:07+01:00 2021-04-30T11:23:10+02:00 "itd_shift ice in iceitd.F90 shifts ice volume and area upwards or downwards among categories. State variables are also exchanged, in proportion of change in ice volume or area. For some variables, it is not clear in proportion of what this should be done (ponds, snow). We have to rethink if what we have is sufficient, and coherent for all state variables. To be discussed" 2325 add EAP rheology to SI3 SI3 trunk Request stefryn new 2019-11-01T15:09:20+01:00 2020-03-28T12:29:39+01:00 " ==== Context Current EVP rheology assumes ice is isotropic, but observations show linear kinematic features (LKF) which are sign of anisotropic behaviour. Elasitc anisotropic plastic (EAP) rheology has been developed by UCL to address this shortcoming. It is routinely used in CICE simulations and shows more realistic LKF patterns. The IMMERSE project has a milestone and deliverable to implement EAP rheology in SI3. ==== Proposal Add new module icedyn_rhg_eap.F90 with similar structure to the existing icedyn_rhg_evp.F90 module to include EAP rheology as an option in SI3. " 2629 IOM-01_Mueller_DIAMLR tools trunk Unscheduled Task smueller new 2021-02-19T13:44:29+01:00 2022-01-14T12:04:58+01:00 "==== Workplan action Wikipage: wiki:2021WP/IOM-01_Mueller_DIAMLR " 2584 Link TOYATM tool with OASIS library tools trunk Defect emalod new 2020-11-27T17:26:31+01:00 2020-11-27T17:26:31+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context A fake atmosphere model is provided in the tools/TOYATM subdirectory in order to check the validity of the OASIS interface as provided in the CPL_OASIS NEMO test. Some information is missing to be able to create the TOYATM executable ==== Analysis OASIS library names provided in the arch file can not be taken into account when building the corresponding Makefile ==== Recommendation To create a cpp_TOYATM.fcm file in TOYATM subdirectory, which contains: bld::tool::fppkeys key_oasis3 " 2583 add the possibility to run SETTE tests outside NEMO cfgs directory tools trunk Bug gsamson new 2020-11-26T11:17:57+01:00 2020-11-26T11:17:57+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context on new Meteo-France HPC, new storage quotas are very limited on the backed-up partition where NEMO code is usually stored ==== Analysis it is not possible to run SETTE tests on the same partition as the one where NEMO code is stored because there is not enough space and performances of the saved partition are bad ==== Fix allow to run SETTE test in a custom directory outside of cfgs directory " 2503 DOMcfg: careful review/cleaning needed after r13204 tools trunk Unscheduled Bug mathiot new 2020-07-27T11:51:07+02:00 2020-08-24T12:03:19+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Work to have DOMcfg compatible with Agrif has been added in r13204. In the mean time: - useless files came up with (MODEL.*, Makefile*, make.inc, sfmakedepend and maybe some other). This files are no more needed even with Agrif as a preprocessing step has been added last year. (cosmetic as long as you don't try to use it, I didn't test these files) - in dom_oce : variable allocation removed last year as part of acleaning came up as commented fields. If they are useless they should be removed. (cosmetic) - dom_clo has been commented and moved up (before dommsk). So even if uncommented, it will not work because ssmask is not known yet and why commented it ? If the option is not work, we should fix it not comment it. '''(functionality broken)''' - others ? (I didn't do an extensive check of all the changes in the non-agrif part) ==== Analysis It looks to me difficulties to merge a work baed on an old revision of the tools to the new version (commit r13024 in a branch) and then it propagate to the trunk of tools. ==== Suggestion There is still work on-going with AGRIF, so it could be worth : - waiting this to be done and then do a proper cleaning. - adding a testing strategy for tools to avoid broken functionality for tools: especially REBUILD_NEMO and DOMAINcfg (need to test also reproducibility across various decomposition too). - in the mean time maybe implement #2500 or part of it. " 2500 Memory usage of DOMAINcfg tools trunk Unscheduled Request mathiot new 2020-07-24T11:52:48+02:00 2020-07-24T11:52:48+02:00 "BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. After last year dev on DOMAINcfg tools, memory imprint has been reduced drastically by removing all the useless 3d variables. For eORCA12, it still requires 2 full nodes on a cluster to build it. I think we can go further. '''1:''' All the variables are allocated at the same time, but I don't see why we cannot allocate only the variable needed for the horizontal grid, compute the horizontal grid, write it and deallocated them, the same for the vertical grid and the mask and only keep a limited number of variable allocated all along the script. The work identified to do it is: - split dom_alloc in 3 : mshhgr_alloc, mshzgr_alloc, msk_alloc and build the associated dealloc funtion - split the domain_write subroutine in 2 (horizontal and vertical). Mask is already managed by domwri. '''2:''' Some variables looks to me still useless (need to be properly checked): - r1_* - *e1e2* - miku/v/f et mbku/v Au final ca fait prés de 25 variables 2d" 2457 Bug domcfg with isf tools trunk Bug mathiot new 2020-05-04T20:06:01+02:00 2020-05-18T16:10:45+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Under some condition domisf leads to negative vertical scale factor: case where isolated grid point in bathymetry where ice shelf almost grounded. ==== Analysis This comes from the position of the modification of the bathy because of isolated grid point in the bathymetry. It has been included before the computation of misfdep (zgr_isf_kspace) but it should be done at the very beginning in zgr_isf_zspace when compatibility between isf draft and bathy is done. ==== Fix in domisf.F90, move the bloc: {{{#!f ! 0.0 fill isolated grid point in the bathymetry ! will be done again later on in zgr_bat_ctl, but need to be done here to adjust risfdep/misfdep respectively icompt = 0 DO jj = 2, jpjm1 DO ji = 2, jpim1 ibtest = MAX( mbathy(ji-1,jj), mbathy(ji+1,jj), & & mbathy(ji,jj-1), mbathy(ji,jj+1) ) IF( ibtest < mbathy(ji,jj) ) THEN mbathy(ji,jj) = ibtest bathy(ji,jj) = gdepw_1d(ibtest+1) icompt = icompt + 1 END IF END DO END DO ! ! ensure halo correct zdummy(:,:) = FLOAT( mbathy(:,:) ) ; CALL lbc_lnk('domisf', zdummy, 'T', 1._wp ) ; mbathy(:,:) = INT( zdummy(:,:) ) ! IF( lk_mpp ) CALL mpp_sum('domisf', icompt ) IF( icompt == 0 ) THEN IF(lwp) WRITE(numout,*)' no isolated ocean grid points' ELSE IF(lwp) WRITE(numout,*)' ',icompt,' ocean grid points suppressed' ENDIF }}} out of zgr_isf_kspace in zgr_isf_zspace at the top as 0.0 to be sure mbathy and bathy not modify before starting to compute the isfdraft. And in domzgr, move the call to zgr_isf_zspace after the computation of mbathy and before the call to zgr_isf_kspace: {{{#!diff --- domzgr.F90 (revision 12864) +++ domzgr.F90 (working copy) @@ -894,10 +894,6 @@ IF(lwp) WRITE(numout,*) ' ~~~~~~~ ' IF(lwp) WRITE(numout,*) ' mbathy is recomputed : bathy_level file is NOT used' - ! compute position of the ice shelf grounding line - ! set bathy and isfdraft to 0 where grounded - IF ( ln_isfcav ) CALL zgr_isf_zspace - ! bathymetry in level (from bathy_meter) ! =================== zmax = gdepw_1d(jpk) + e3t_1d(jpk) ! maximum depth (i.e. the last ocean level thickness <= 2*e3t_1d(jpkm1) ) @@ -915,10 +911,13 @@ WHERE( 0._wp < bathy(:,:) .AND. bathy(:,:) <= zdepth ) mbathy(:,:) = jk-1 END DO - ! Check compatibility between bathy and iceshelf draft - ! insure at least 2 wet level on the vertical under an ice shelf - ! compute misfdep and adjust isf draft if needed - IF ( ln_isfcav ) CALL zgr_isf_kspace + ! if under ice shelf cavities, compute misfdep for ocean point (i.e. the top level) + IF ( ln_isfcav ) THEN + ! compute position of the ice shelf grounding line + CALL zgr_isf_zspace + ! compute misfdep and adjust isf draft if needed + CALL zgr_isf_kspace + END IF }}} " 2338 DATAINT-01_sciliberti_IMMERSE_Interfaces tools trunk Unscheduled Task sciliberti new 2019-11-21T14:16:03+01:00 2021-04-14T13:05:07+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:20XXWP/STREAM-NB_pi(s)_keyword(s)" 2227 local modification of the Gib strait, Danish strait and other no more in DOMAINcfg ? tools v4.0.* Defect mathiot new 2019-02-04T15:45:02+01:00 2020-03-28T13:11:13+01:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Context ORCA2 e1 and e2 used for SETTE is locally different to the one used in 3.6. At the Met Office we spot this also in our test with ORCA1 (large change in Med Sea and Black Sea). ==== Analysis All the local modifications of e1 and e2 at some specific straits present in version 3.6 in domhgr.F90 are not present in the DOMAINcfg source code. It affects ORCA2, ORCA1 and ORCA05. Here is the king of block I am talking about. {{{#!f ! ! ===================== IF( cp_cfg == ""orca"" .AND. jp_cfg == 2 ) THEN ! ORCA R2 configuration ! ! ===================== IF( nn_cla == 0 ) THEN ! ii0 = 139 ; ii1 = 140 ! Gibraltar Strait (e2u = 20 km) ij0 = 102 ; ij1 = 102 ; e2u( mi0(ii0):mi1(ii1) , mj0(ij0):mj1(ij1) ) = 20.e3 IF(lwp) WRITE(numout,*) IF(lwp) WRITE(numout,*) ' orca_r2: Gibraltar : e2u reduced to 20 km' ! ii0 = 160 ; ii1 = 160 ! Bab el Mandeb (e2u = 18 km) ij0 = 88 ; ij1 = 88 ; e1v( mi0(ii0):mi1(ii1) , mj0(ij0):mj1(ij1) ) = 18.e3 e2u( mi0(ii0):mi1(ii1) , mj0(ij0):mj1(ij1) ) = 30.e3 IF(lwp) WRITE(numout,*) IF(lwp) WRITE(numout,*) ' orca_r2: Bab el Mandeb: e2u reduced to 30 km' IF(lwp) WRITE(numout,*) ' e1v reduced to 18 km' ENDIF ii0 = 145 ; ii1 = 146 ! Danish Straits (e2u = 10 km) ij0 = 116 ; ij1 = 116 ; e2u( mi0(ii0):mi1(ii1) , mj0(ij0):mj1(ij1) ) = 10.e3 IF(lwp) WRITE(numout,*) IF(lwp) WRITE(numout,*) ' orca_r2: Danish Straits : e2u reduced to 10 km' ! ENDIF }}} Furthermore the README is a bit missleading on this: {{{ 2) copy in DOMAINcfg directory same input files (of related configuration) required in v3.6_stable. DOMAINcfg package is EXACTLY what does exist in NEMO version 3.6 to define a model domain (both domain related namelist and initialization). }}} ==== Recommendation * If it is a deliberate action to remove this code from DOMAINcfg, I suggest to update the README and maybe update the ORCA2 input file distributed with the corrected e1 and e2 for Gibraltar, Bab el Mandeb and Danish straits. * If it is NOT a deliberate action to remove this code from DOMAINcfg, I suggest to put it in DOMAINcdf." 2140 DMP_TOOL modification tools Unscheduled Request jenniewaters new 2018-10-17T13:38:57+02:00 2020-03-28T12:21:35+01:00 "== Context The current DMP_TOOL for calculating the restoration coefficients for use with the tra_dmp module in NEMO calculates the distance to coast (using the surface only) for every vertical level. Subsequently the tool is very inefficient for large model domains. == Proposal * Include functionality to allow the distance to coast to be read in rather than calculated * Only perform the distance to coast calculation once. " 2715 RK3 time-stepping for TOP TOP v4.0.* Task techene new 2021-08-13T11:36:09+02:00 2021-12-29T10:51:01+01:00 "==== Workplan action Wikipage: wiki:2021WP/KNL-01_Sibylle_RK3_stage1 === TOP & key_RK3 Some restructuration is needed in order to use RK3 time-stepping for passive tracer. Indeed, RK3 time stepping is a 3 stages algorithm going from ""before"" time level to ""after"" time level using ""middle"" estimated of advected momentum, active tracers and passive tracers. Intermediary stages build estimated of advected quantities using advective velocities. * Advective velocities have to be passed to tracer advection routine. * Remove time filtering required for Modified Leap Frog only. * Split passive tracers time stepping into 3 stages for RK3. * Restart routines also need updates. ==== AGE passive tracer " 2606 improve initalization with data ( dtatsd.F90) TOP trunk 2021 WP Request cbricaud new 2021-01-28T09:49:25+01:00 2021-02-01T22:35:03+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context dtatst is used to read T&S data. These data can be used to initialize the model and/or make damping ==== Analysis It implies that the same data are used for initialization and damping: a second dtatsd routine could be add to allow initialization and damping with 2 differents data sets. U&V&SSh could also be initialized. dtauvd.F90 should be refresh and generalized to all configurations ( not only for 1D) ==== Recommendation ... " 2550 TOP-02_rlod_SeaIce_Fe_Source TOP trunk Unscheduled Task rlod new 2020-10-14T17:29:31+02:00 2021-04-14T13:04:08+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:20XXWP/STREAM-NB_pi(s)_keyword(s)" 2570 compatibility between isf and tramle TRA v4.0.* Defect mathiot new 2020-11-13T12:20:20+01:00 2020-12-18T11:04:19+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context After testing eORCA1 with tramle activated and , I found it more instable. By looking at the code, I am not convinced at all, tramle.F90 is compatible with ice shelf cavities. ==== Analysis - nlb10 is computed like this: {{{#!f ! ! deepest/shallowest W level Above/Below ~10m !!gm BUG in s-coordinate this does not work! zrefdep = 10._wp - 0.1_wp * MINVAL( e3w_1d ) ! ref. depth with tolerance (10% of minimum layer thickness) nlb10 = MINLOC( gdepw_1d, mask = gdepw_1d > zrefdep, dim = 1 ) ! shallowest W level Below ~10m nla10 = nlb10 - 1 ! deepest W level Above ~10m !!gm end bug }}} - With this definition of nla10, this definition of mld used for MLE under an ice shelf does not make sense to me (because rhop(ji,jj,nla10) is on land): {{{#!f ! !== MLD used for MLE ==! ! ! compute from the 10m density to deal with the diurnal cycle inml_mle(:,:) = mbkt(:,:) + 1 ! init. to number of ocean w-level (T-level + 1) IF ( nla10 > 0 ) THEN ! avoid case where first level is thicker than 10m DO jk = jpkm1, nlb10, -1 ! from the bottom to nlb10 (10m) DO jj = 1, jpj DO ji = 1, jpi ! index of the w-level at the ML based IF( rhop(ji,jj,jk) > rhop(ji,jj,nla10) + rn_rho_c_mle ) inml_mle(ji,jj) = jk ! Mixed layer END DO END DO END DO ENDIF ikmax = MIN( MAXVAL( inml_mle(:,:) ), jpkm1 ) ! max level of the computation }}} - Based on the name of the variables, I am not sure if the masking is right, should it be uwmask instead of umask ? {{{#!f zpsi_uw(ji,jj,jk) = zpsim_u(ji,jj) * zmuw * umask(ji,jj,jk) zpsi_vw(ji,jj,jk) = zpsim_v(ji,jj) * zmvw * vmask(ji,jj,jk) }}} - There is also some gdepw here and there in tramle, are they adapted under an isf (with respect to the definition of the mld under an isf) ?. - it affects NEMO4 and trunk ==== Recommendation - advices are needed from someone who know this part of code. - as a temporary fix before it is fixed, probably this should do the job: multiply zpsi_u/vw by u/vmask(:,:,1) should do the trick to set it to 0 inside a cavity. " 2539 Better management of T/S file used for tradmp. TRA trunk Request mathiot new 2020-10-05T15:51:09+02:00 2020-12-04T11:40:29+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Some users feel the need to have more flexibility in the choice of TS file used for tradmp. As it is, the same T/S data file is used for tradmp and intialisation and there is no possibility to specify a file for intialisation and an other file for tradmp. DRAKKAR has done something to enable this. ISOMIP+ has also in MY_SRC some code to do it. For information, there are also some comments in the code about it in tradmp.F90: {{{ 200 !!TG: Initialisation of dtatsd - Would it be better to have dmpdta routine 201 ! so can damp to something other than intitial conditions files? 202 !!gm: In principle yes. Nevertheless, we can't anticipate demands that have never been formulated. }}} ==== Analysis Code change by DRAKKAR available here: https://github.com/meom-group/DCM/tree/master/DCMTOOLS/DRAKKAR/NEMO4/src Code change by ISOMIP+ in tests/ISOMIP+/MY_SRC Comments on both solutions: - they don't get rid of ln_tsd_dmp defined in namtsd. - tradmp TS file still defined in namtsd file. Suggestion of a third solution: - dta_tsd_init (ie print and definition/allocation of sf_tsdini or sf_tsddmp) split in tradmp_init and istate_init => no more *dmp* namelist variable in dtatsd and no more dta_tsd_init subroutine - dta_tsd with a new argument which is the sf_tsd structure (dmp one or init one) and the deallocation of T & S arrays used for the intialisation done at the end of dta_tsd moved to istate. => dta_tsd with this change should be universal as all reference to dmp case of ini case are removed. - rename namelist namtsd and associated variable to be clear it is intialisation ? ==== Benefits - more flexibility in NEMO configuration and behaviour in phase with other part of NEMO like namsbc_ssr for example (ie data used defined in the corresponding block). - tradmp variables are all in namtra_dmp block and initialisation variable in namtsd (or a new name) block. - dtatsd, istate and tradmp files out of ISOMIP+/MY_SRC (see #2536). " 2538 Tref and Sref used in simplified eos hard coded TRA trunk Defect mathiot new 2020-10-05T15:05:14+02:00 2020-10-05T15:05:14+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context The simplified eos (ln_seos) is based on : {{{ rd(T,S,Z)*rho0 = -a0*(1+.5*lambda*dT+mu*Z+nu*dS)*dT+b0*dS }}} It need a reference T and S hard coded into eosbn2 (respectively, 10 and 35) to compute dt and ds. All the other coefficients (thermal expension, cabbeling and thermobaric) are defined in the namelist. ==== Recommendation Add the definition of the reference T and S used in the simplified eos in the namelist (default being the current value). Other benefits: - more flexibility of the seos. - no more eosbn2.F90 in ISOMIP+/MY_SRC (see #2536) " 2162 Tiling for TRA and ZDF routines TRA trunk Unscheduled Task mikebell new 2018-11-15T15:26:53+01:00 2021-04-14T12:57:23+02:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Context 3D NEMO routines are typically memory bound. Tiling the most memory bound routines can reduce data transfers in & out of cache and improve OpenMP performance ==== Proposal Uses derived types to make the code more readable " 2348 2D vorticity trend diagnostics need to updated to use XIOS TRD trunk Unscheduled Defect davestorkey new 2019-12-06T12:10:24+01:00 2022-01-07T13:35:17+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context The 2D vorticity trends diagnostics (ln_trd_vor=T) are currently disabled because they have not been updated to use XIOS. I propose to fix this as a WP2020 action. At the same time I may expand the list of available diagnostics to include all curl(depth-integral)/depth fields. (Currently most of the available diagnostics are curl(depth-average) fields). ==== Analysis ... ==== Recommendation ... " 2344 issues with 3D momentum trends diagnostics and split-explicit time-stepping TRD trunk Unscheduled Defect davestorkey new 2019-12-04T12:52:49+01:00 2022-01-07T13:34:49+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context There are various issues with the 3D momentum trends diagnostics (ln_dyn_trd=T) when using the split-explicit solution of the momentum equation (dynspg_ts - default from NEMO 4.0 onwards): 1. The ""SPG"" trend is not the trend due to the surface pressure gradient. It is the change in the velocities due to the solution of the barotropic part of the equations in dyn_spg_ts. 2. More generally, for trends which are allowed to vary over the barotropic subcycling (PVO, BFR), there is a small inaccuracy because currently this variation is not taken into account. 3. At various points in the code the barotropic part of the velocities is subtracted or added back in (eg. at the beginning of dyn_spg_ts, or at the beginning of dyn_zdf for the implicit bottom friction option). This subtraction/addition of the barotropic component is sometimes incorrectly included in the trend associated with that module. These problems mean that it is currently not possible to close the momentum budget, as already noted in tickets #1584 and #1984. The 3D momentum trends are used to calculate various other diagnostics such as 2D vorticity trends (ln_vor_trd=T) or kinetic energy trends (ln_KE_trd=T) so the problems also affect these derived diagnostics. ==== Analysis ... ==== Recommendation 1. Momentum trends diagnostics should correspond to terms in the primitive equations (rather than NEMO modules). 2. We should have a small number of 3D trends which are sufficient to close the budget: a. Each 3D trend should include the barotropic and baroclinic part. (We can output the barotropic part separately if we want). Where the barotropic part of the trend varies over the subcycling this part can be calculated accurately using the time-averaging weights already available in dynspg_ts.F90. b. The horizontal pressure gradient trend (HPG) should include the surface pressure gradient (SPG). The SPG trend can be output as an extra diagnostics not required to close the budget. c. The vertical diffusion trend (ZDF) already includes the contribution of the wind stress, top stress (in ice shelf cavities) and implicit bottom stress, but it should also include the contribution from the explicit bottom stress terms. The explicit bottom stress can still be output as an extra diagnostic not required to close the budget. 3. We should make sure that the subtraction or addition of the barotropic component of velocities or velocity trends is not included in the momentum trend diagnostics. This particularly applies to the ZDF trend. (This is similar to a fix proposed but not implemented by Christoph in ticket #1584). " 2678 Proposed development of zdfiwm.F90 routine ZDF v4.0.* Request cdllod new 2021-05-24T16:45:58+02:00 2021-05-24T16:45:58+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context The current zdfiwm.F90 (internal wave driven mixing) routine was coded prior to the CMIP6 exercise, as documented in chapter 5 of my PhD thesis (https://tel.archives-ouvertes.fr/tel-01592475). A refined version has been published since (https://doi.org/10.1029/2020MS002065). This refined version is simpler and has been thoroughly validated against observations. ==== Proposal I propose to update the routine to match that recently published. The updated routine is already coded and used by several NEMO users (Camille Lique, Dorotea Iovino, Casimir de Lavergne), but isn't public yet. The updated routine is also simpler and computationally more efficient. " 2666 Unstable cases treatment in zdfiwm (formerly zdftmx) ZDF trunk Request gsamson new 2021-05-07T12:42:25+02:00 2021-05-07T12:42:25+02:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context By default, the unstable cases (bn2 < 0) leads to an estimation of zav_wave of 100 cm2/s. This treatment is useless in the case of using the TKE standard turbulent scheme as evd will specify a value of 10 or 100 m2/s. However, this specific treatment can induce some troubles in the case of using a convective model such as the EDMF schemes recently introduced. Indeed, this scheme works in case of instabilities, so they should not not be removed by mixing. ==== Proposal The suggestion is to set zav_wave to the background value in unstables cases and let evd, gls or a convective model to deal with. " 2723 Compiler-specific compilation failures in NST component related to dummy procedures of AGRIF subroutines AGRIF v4.0.* Defect smueller assigned 2021-09-15T13:52:01+02:00 2022-01-07T15:21:14+01:00 "==== Context Not all commonly used compilers succeed in compiling the calls of AGRIF subroutines `Agrif_Bc_variable` and `Agrif_Update_variable` in component `NST`. ==== Analysis The AGRIF subroutines `Agrif_Bc_variable` and `Agrif_Update_variable` use a dummy procedure argument with an implicit interface (argument name `procname`). Currently, the respective calls in the `NST` component (e.g., source:/NEMO/releases/r4.0/r4.0.6/src/NST/agrif_ice_update.F90#L67) refer to a procedure name as argument value, which not all commonly used compilers seem to accept. ==== Recommendation The `procname` argument values in the `Agrif_Bc_variable` and `Agrif_Update_variable` calls included in the `NST` component could be replaced by explicitly assigned procedure pointers with implicit interface, such as {{{#!diff Index: src/NST/agrif_ice_update.F90 =================================================================== --- src/NST/agrif_ice_update.F90 (revision 15240) +++ src/NST/agrif_ice_update.F90 (working copy) @@ -48,6 +48,10 @@ !! !! ** Action : - Update (u_ice,v_ice) and ice tracers !!---------------------------------------------------------------------- +!$AGRIF_DO_NOT_TREAT + PROCEDURE(), POINTER :: zp_update_tra_ice, zp_update_u_ice, zp_update_v_ice +!$AGRIF_END_DO_NOT_TREAT + !!---------------------------------------------------------------------- ! IF( Agrif_Root() .OR. nn_ice == 0 ) RETURN ! do not update if inside Parent Grid or if child domain does not have ice ! @@ -62,18 +66,21 @@ Agrif_SpecialValueFineGrid = -9999. Agrif_UseSpecialValueInUpdate = .TRUE. + zp_update_tra_ice => update_tra_ice + zp_update_u_ice => update_u_ice + zp_update_v_ice => update_v_ice # if defined TWO_WAY # if ! defined DECAL_FEEDBACK - CALL Agrif_Update_Variable( tra_ice_id , procname = update_tra_ice ) + CALL Agrif_Update_Variable( tra_ice_id , procname=zp_update_tra_ice ) #else - CALL Agrif_Update_Variable( tra_ice_id , locupdate=(/1,0/), procname = update_tra_ice ) + CALL Agrif_Update_Variable( tra_ice_id , locupdate=(/1,0/), procname=zp_update_tra_ice ) #endif # if ! defined DECAL_FEEDBACK - CALL Agrif_Update_Variable( u_ice_id , procname = update_u_ice ) - CALL Agrif_Update_Variable( v_ice_id , procname = update_v_ice ) + CALL Agrif_Update_Variable( u_ice_id , procname=zp_update_u_ice ) + CALL Agrif_Update_Variable( v_ice_id , procname=zp_update_v_ice ) #else - CALL Agrif_Update_Variable( u_ice_id , locupdate1=(/0,-1/),locupdate2=(/1,-2/),procname=update_u_ice) - CALL Agrif_Update_Variable( v_ice_id , locupdate1=(/1,-2/),locupdate2=(/0,-1/),procname=update_v_ice) + CALL Agrif_Update_Variable( u_ice_id , locupdate1=(/0,-1/), locupdate2=(/1,-2/), procname=zp_update_u_ice ) + CALL Agrif_Update_Variable( v_ice_id , locupdate1=(/1,-2/), locupdate2=(/0,-1/), procname=zp_update_v_ice ) #endif ! CALL Agrif_Update_Variable( tra_ice_id , locupdate=(/0,2/), procname = update_tra_ice ) ! CALL Agrif_Update_Variable( u_ice_id , locupdate=(/0,1/), procname = update_u_ice ) }}} to improve the compiler compatibility of the `NST` component. " 2638 AGF-01_Debreu_domcfg AGRIF trunk Unscheduled Task smasson assigned 2021-03-15T16:33:35+01:00 2022-01-14T12:04:58+01:00 " ==== Workplan action AGRIF / Configuration domain generation tool refactoring & Agrif friendly Wikipage: wiki:2021WP/AGF-01_Debreu_domcfg " 2336 AGRIF-01_mathiot_multigrid_load_balancing AGRIF trunk Unscheduled Task mathiot assigned 2019-11-21T13:19:44+01:00 2022-01-14T12:05:56+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context ... ==== Proposal ... " 2051 Implementation of fresh water budget control for AGRIF configurations (here nn_fwb = 3 only) AGRIF trunk Unscheduled Defect fschwarzkopf assigned 2018-02-26T14:59:50+01:00 2021-03-09T18:14:48+01:00 " == Context In AGRIF configurations (TWO-WAY), fresh water budget control does not work correctly: If nn_fwb /= 0 in host and nn_fwb = 0 in nest --> corrections applied to the host within the nested region are ""reversed"" by AGRIF-update. If nn_fwb /= 0 in host and nn_fwb /= 0 in nest --> for nest, fwb from nest itself is used for correction instead of global budget. Both versions do not correctly close the fresh water budget. == Proposal Idea: Correct fwb in nest based on global budget. Changes in sbcmod.F90: Apply fwb correction in nest at every host-nn_fsbc-time-step coinciding with Agrif_Update-time-step. NO consistency-check implemented yet. (in test case: host: nn_fsbc = 6; nest: rhot = nn_fsbc = nn_cln_update = 3) Changes in sbcfwb.F90: Transfer global budget from host to nest. Apply portion of budget correction to nest depending on erp-fraction (relative to global erp) done in nest. These changes (marked by FUS) seem to technically work (the correct numbers are transferred from the host to the nest and used by the nest at the correct timing), however, '''closing the budget still fails'''. {{{#!diff Index: sbcmod.F90 =================================================================== --- sbcmod.F90 (revision 9356) +++ sbcmod.F90 (working copy) @@ -54,6 +54,9 @@ USE sbcwave ! Wave module USE bdy_par ! Require lk_bdy + USE agrif_oce ! FUS: get nbcline and nbclineupdate for fwb-call timing + USE agrif_util ! FUS: get Agrif_Parent* for fwb-call timing + IMPLICIT NONE PRIVATE @@ -411,7 +414,25 @@ IF( ln_ssr ) CALL sbc_ssr( kt ) ! add SST/SSS damping term +! FUS: start control fwb timing in AGRIF case - here for nn_fwb=3 only +#if defined key_agrif + + IF( nn_fwb /= 0 .AND. nn_fwb /= 3 ) CALL sbc_fwb( kt, nn_fwb, nn_fsbc ) ! control the freshwater budget + + IF( nn_fwb == 3 ) THEN + IF(Agrif_Root()) THEN + CALL sbc_fwb( kt, nn_fwb, nn_fsbc ) ! control the freshwater budget + ELSE +!FUS: do fwb correction in nest at nn_fsbc in host and Update time-step (make sure, nn_fsbc (nest and host) and nn_cln_update choice is suitable - NO consistency-check implemented yet) + IF ( MOD(nbcline,nbclineupdate) == 0 .AND. MOD( Agrif_Parent_Nb_Step()-1, Agrif_Parent(nn_fsbc) ) == 0 ) THEN + CALL sbc_fwb( kt, nn_fwb, nn_fsbc ) ! control the freshwater budget + ENDIF + ENDIF + ENDIF +#else IF( nn_fwb /= 0 ) CALL sbc_fwb( kt, nn_fwb, nn_fsbc ) ! control the freshwater budget +#endif +! FUS: end control fwb timing in AGRIF case - here for nn_fwb=3 only IF( nn_closea == 1 ) CALL sbc_clo( kt ) ! treatment of closed sea in the model domain ! ! (update freshwater fluxes) Index: sbcfwb.F90 =================================================================== --- sbcfwb.F90 (revision 9356) +++ sbcfwb.F90 (working copy) @@ -27,7 +27,8 @@ USE timing ! Timing USE lbclnk ! ocean lateral boundary conditions USE lib_fortran - + USE Agrif_Util ! FUS: get Agrif_Parent + USE agrif_types ! FUS: needed for POINTER to Agrif_Parent (?) IMPLICIT NONE PRIVATE @@ -37,7 +38,8 @@ REAL(wp) :: a_fwb ! for 2 year before (_b) and before year. REAL(wp) :: fwfold ! fwfold to be suppressed REAL(wp) :: area ! global mean ocean surface (interior domain) - + REAL(wp),PUBLIC :: z_fwf, z_fwf_nsrf, zsum_fwf, zsum_erp, zsurf_tospread ! FUS: variables transfered from the parent to child via Agrif_Parent need to be PUBLIC! + ! FUS: variable names are still in local nomenclature - adjustments needed !! * Substitutions # include ""domzgr_substitute.h90"" # include ""vectopt_loop_substitute.h90"" @@ -67,10 +69,16 @@ INTEGER, INTENT( in ) :: kn_fwb ! ocean time-step index ! INTEGER :: inum, ikty, iyear ! local integers - REAL(wp) :: z_fwf, z_fwf_nsrf, zsum_fwf, zsum_erp ! local scalars - REAL(wp) :: zsurf_neg, zsurf_pos, zsurf_tospread, zcoef ! - - +! REAL(wp) :: z_fwf, z_fwf_nsrf, zsum_fwf, zsum_erp ! local scalars ! FUS: now defined public +! REAL(wp) :: zsurf_neg, zsurf_pos, zsurf_tospread, zcoef ! - - ! FUS: zsurf_tospread now defined public + REAL(wp) :: zsurf_neg, zsurf_pos, zcoef ! - - ! FUS: zsurf_tospread now defined public REAL(wp), POINTER, DIMENSION(:,:) :: ztmsk_neg, ztmsk_pos, z_wgt ! 2D workspaces REAL(wp), POINTER, DIMENSION(:,:) :: ztmsk_tospread, zerp_cor ! - - +! FUS: define pointer for parent-variables transfered through Agrif_Parent +#if defined key_agrif + REAL(wp),POINTER :: parent_z_fwf, parent_z_fwf_nsrf, parent_zsum_erp, parent_zsum_fwf, parent_zsurf_tospread +#endif + !!---------------------------------------------------------------------- ! IF( nn_timing == 1 ) CALL timing_start('sbc_fwb') @@ -160,6 +168,12 @@ ! zsurf_neg = glob_sum( e1e2t(:,:)*ztmsk_neg(:,:) ) ! Area filled by <0 and >0 erp zsurf_pos = glob_sum( e1e2t(:,:)*ztmsk_pos(:,:) ) + +! FUS: differentiate between host and nest in AGRIF case +#if defined key_agrif +IF ( Agrif_Root() ) THEN +#endif + ! ! fwf global mean (excluding ocean to ice/snow exchanges) z_fwf = glob_sum( e1e2t(:,:) * ( emp(:,:) - rnf(:,:) + fwfisf(:,:) - snwice_fmass(:,:) ) ) / area ! @@ -171,9 +185,9 @@ ztmsk_tospread(:,:) = ztmsk_neg(:,:) ENDIF ! - zsum_fwf = glob_sum( e1e2t(:,:) * z_fwf ) ! fwf global mean over <0 or >0 erp area + zsum_fwf = glob_sum( e1e2t(:,:) * z_fwf ) ! fwf global mean over <0 or >0 erp area ! FUS: this is erp-independent global mean! !!gm : zsum_fwf = z_fwf * area ??? it is right? I think so.... - z_fwf_nsrf = zsum_fwf / ( zsurf_tospread + rsmall ) + z_fwf_nsrf = zsum_fwf / ( zsurf_tospread + rsmall ) ! FUS: is this necessary? could use zsum_fwf for zerp_cor instead ! ! weight to respect erp field 2D structure zsum_erp = glob_sum( ztmsk_tospread(:,:) * erp(:,:) * e1e2t(:,:) ) z_wgt(:,:) = ztmsk_tospread(:,:) * erp(:,:) / ( zsum_erp + rsmall ) @@ -187,7 +201,45 @@ qns(:,:) = qns(:,:) - zerp_cor(:,:) * rcp * sst_m(:,:) ! account for change to the heat budget due to fw correction erp(:,:) = erp(:,:) + zerp_cor(:,:) ! + +! FUS: differentiate between host and nest in AGRIF case +#if defined key_agrif +ELSE ! FUS: start special treatment for nest + parent_z_fwf => Agrif_Parent(z_fwf) ! FUS: add pointer to Parent value + parent_zsum_fwf => Agrif_Parent(zsum_fwf) ! FUS: add pointer to Parent value - might replace parent_z_fwf_nsrf and parent_zsurf_tospread + parent_z_fwf_nsrf => Agrif_Parent(z_fwf_nsrf) ! FUS: add pointer to Parent value + parent_zsum_erp => Agrif_Parent(zsum_erp) ! FUS: add pointer to Parent value + parent_zsurf_tospread => Agrif_Parent(zsurf_tospread) ! FUS: add pointer to Parent value + + IF( parent_z_fwf < 0._wp ) THEN ! FUS: keep fwf-sign from parent (nest might differ) + zsurf_tospread = zsurf_pos + ztmsk_tospread(:,:) = ztmsk_pos(:,:) + ELSE + zsurf_tospread = zsurf_neg + ztmsk_tospread(:,:) = ztmsk_neg(:,:) + ENDIF + + ! ! weight to respect erp field 2D structure + ! ! FUS: scale by zsum_erp in parent + z_wgt(:,:) = ztmsk_tospread(:,:) * erp(:,:) / ( parent_zsum_erp + rsmall ) + ! ! final correction term to apply + ! ! FUS: spread parent_zsum_fwf = parent_z_fwf_nsrf * parent_zsurf_tospread + zerp_cor(:,:) = -1. * parent_z_fwf_nsrf * parent_zsurf_tospread * z_wgt(:,:) + ! + CALL lbc_lnk( zerp_cor, 'T', 1. ) + ! + emp(:,:) = emp(:,:) + zerp_cor(:,:) + qns(:,:) = qns(:,:) - zerp_cor(:,:) * rcp * sst_m(:,:) ! account for change to the heat budget due to fw correction + erp(:,:) = erp(:,:) + zerp_cor(:,:) + ! +ENDIF ! FUS: end special treatment for nest +#endif + IF( nprint == 1 .AND. lwp ) THEN ! control print + +! FUS: nest specific prints +#if defined key_agrif +IF ( Agrif_Root()) THEN IF( z_fwf < 0._wp ) THEN WRITE(numout,*)' z_fwf < 0' WRITE(numout,*)' SUM(erp+) = ', SUM( ztmsk_tospread(:,:)*erp(:,:)*e1e2t(:,:) )*1.e-9,' Sv' @@ -198,8 +250,37 @@ WRITE(numout,*)' SUM(empG) = ', SUM( z_fwf*e1e2t(:,:) )*1.e-9,' Sv' WRITE(numout,*)' z_fwf = ', z_fwf ,' Kg/m2/s' WRITE(numout,*)' z_fwf_nsrf = ', z_fwf_nsrf ,' Kg/m2/s' - WRITE(numout,*)' MIN(zerp_cor) = ', MINVAL(zerp_cor) - WRITE(numout,*)' MAX(zerp_cor) = ', MAXVAL(zerp_cor) +ELSE + IF( parent_z_fwf < 0._wp ) THEN + WRITE(numout,*)' z_fwf < 0' + WRITE(numout,*)' SUM(erp+) = ', SUM( ztmsk_tospread(:,:)*erp(:,:)*e1e2t(:,:) )*1.e-9,' Sv' + ELSE + WRITE(numout,*)' z_fwf >= 0' + WRITE(numout,*)' SUM(erp-) = ', SUM( ztmsk_tospread(:,:)*erp(:,:)*e1e2t(:,:) )*1.e-9,' Sv' + ENDIF + WRITE(numout,*)' SUM(empG) = ', SUM( z_fwf*e1e2t(:,:) )*1.e-9,' Sv' + WRITE(numout,*)' z_fwf = ', z_fwf ,' Kg/m2/s' + WRITE(numout,*)' z_fwf_nsrf = ', z_fwf_nsrf ,' Kg/m2/s' + WRITE(numout,*)' parent_z_fwf_nsrf = ', parent_z_fwf_nsrf ,' Kg/m2/s' + WRITE(numout,*)' parent_zsurf_tospread = ', parent_zsurf_tospread ,' Kg/m2/s' + WRITE(numout,*)' parent_zsum_fwf = ', parent_zsum_fwf ,' Kg/m2/s' + WRITE(numout,*)' parent_z_fwf_nsrf * parent_zsurf_tospread should be parent_zsum_fwf = ', parent_z_fwf_nsrf * parent_zsurf_tospread + WRITE(numout,*)' parent_zsum_erp = ', parent_zsum_erp ,' Kg/m2/s' +ENDIF +#else + IF( z_fwf < 0._wp ) THEN + WRITE(numout,*)' z_fwf < 0' + WRITE(numout,*)' SUM(erp+) = ', SUM( ztmsk_tospread(:,:)*erp(:,:)*e1e2t(:,:) )*1.e-9,' Sv' + ELSE + WRITE(numout,*)' z_fwf >= 0' + WRITE(numout,*)' SUM(erp-) = ', SUM( ztmsk_tospread(:,:)*erp(:,:)*e1e2t(:,:) )*1.e-9,' Sv' + ENDIF + WRITE(numout,*)' SUM(empG) = ', SUM( z_fwf*e1e2t(:,:) )*1.e-9,' Sv' + WRITE(numout,*)' z_fwf = ', z_fwf ,' Kg/m2/s' + WRITE(numout,*)' z_fwf_nsrf = ', z_fwf_nsrf ,' Kg/m2/s' + WRITE(numout,*)' MIN(zerp_cor) = ', MINVAL(zerp_cor) ! FUS: in mpp-case, this is not the expected value glob_min fails + WRITE(numout,*)' MAX(zerp_cor) = ', MAXVAL(zerp_cor) ! FUS: in mpp-case, this is not the expected value glob_max fails +#endif ENDIF ENDIF ! }}} " 1902 Agrif with timing control AGRIF trunk Unscheduled Bug clem assigned 2017-05-17T10:32:51+02:00 2021-03-09T18:15:35+01:00 "= Context \\ when timing control (nn_timing=1) is activated with AGRIF (for both parent and child domains), simulations crash with segmentation fault message during initialization. I guess it is somewhat related to ticket #1836 but I haven't checked this out." 2676 assimilation and ice thickness ASM trunk Bug clem assigned 2021-05-18T17:49:28+02:00 2022-01-07T15:21:14+01:00 " ==== Context In assimilation there is an attempt to change ice thickness but hm_i is a diagnostic and is not used in the ice code. I wonder whether the authors of this part really wanted to change the thickness or were just making a test. It concerns both the trunk and 4.0-HEAD {{{#!fortran ! Nudge sea ice depth to bring it up to a required minimum depth WHERE( zseaicendg(:,:) > 0.0_wp .AND. hm_i(:,:) < zhicifmin ) zhicifinc(:,:) = zhicifmin - hm_i(:,:) ELSEWHERE zhicifinc(:,:) = 0.0_wp END WHERE ! ! nudge ice depth hm_i (:,:) = hm_i (:,:) + zhicifinc(:,:) }}}" 2697 include ref config C1D_PAPA in SETTE tests C1D Defect gsamson assigned 2021-06-18T17:09:51+02:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context C1D_PAPA reference configuration is broken at each new Nemo release due to the lack of testing this config, and it requires a significant amount of work which could be avoided easily if the config was included in SETTE ==== Recommendation incude C1D_PAPA in SETTE tests " 2175 ENHANCE-05_SimonM-Harmonic_Analysis DIA trunk Unscheduled Task acc assigned 2018-12-04T13:28:57+01:00 2021-04-14T12:58:51+02:00 "==== Summary ||=Action || ''ENHANCE-05_SimonM-Harmonic_Analysis'' || ||=PI(S) || ''Simon Müller, Nicolas Bruneau'' || ||=Digest || ''This action will enhance the tidal harmonic-analysis diagnostics available in the NEMO framework: the replacement of the current implementation by a facility for generic multiple linear regression will enable tidal harmonic analyses of three-dimensional fields, make harmonic analyses across model restarts possible, and improve the computational efficiency of the analysis, as well as facilitate a wide range of non-tidal regression analyses.'' || ||=Dependencies || || ||=Branch || ''[source:/NEMO/branches/2019/dev_r11879_ENHANCE-05_SimonM-Harmonic_Analysis/], [source:/utils/tools_dev_r11751_ENHANCE-05_SimonM-Harmonic_Analysis/]'' || ||=Previewer(s) || ''Jérôme Chanut'' || ||=Reviewer(s) || ''Jérôme Chanut'' || ||=Wiki || ''wiki:2019WP/ENHANCE-05_SimonM-Harmonic_Analysis'' || ==== Abstract This action will enhance the tidal harmonic-analysis diagnostics available in the NEMO framework: the replacement of the current implementation by a facility for generic multiple linear regression will enable tidal harmonic analyses of three-dimensional fields, make harmonic analyses across model restarts possible, and improve the computational efficiency of the analysis, as well as facilitate a wide range of non-tidal regression analyses. ===== Description The harmonic-analysis diagnostics available in the current reference code is limited to two-dimensional fields (surface only), is activated via a preprocessor key, uses unconventional namelist parameter names, uses a mixture of dynamic and static allocation for large arrays, and appears to be computationally inefficient. Further, while being based on multiple linear regression, the current implementation does not provide for regressions on harmonic components other than tidal constituents. This action will replace the current tidal harmonic-analysis diagnostics with a generic implementation for multiple linear regression analysis that can be utilised for both tidal harmonic and non-tidal regression analyses. This implementation will provide harmonic-analysis diagnostics enhancements previously tested in a pre-4.0beta NEMO version by N. Bruneau: the analysis of three-dimensional fields, analysis across model restarts, and improved computational efficiency. In contrast to both the existing harmonic analysis diagnostics in the reference NEMO code and the enhanced pre-4.0beta version by N. Bruneau, the new implementation will make extensive use of XIOS and an off-line tool. This approach should make it possible to simplify the regression analysis-related Fortran module in the core NEMO code, to relocate the regression-analysis configuration to XIOS configuration files, and to enable the selection of any model field handled by XIOS for analysis. ===== Implementation See [wiki:2019WP/ENHANCE-05_SimonM-Harmonic_Analysis#Preview] ===== Reference manual and web pages updates See [wiki:2019WP/ENHANCE-05_SimonM-Harmonic_Analysis#Documentation] {{{#!comment ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks. }}}" 2736 vertical scale facors not recalculated when ssh/=0 DOM v4.0.* Bug clem assigned 2021-10-27T18:28:38+02:00 2022-01-07T15:21:14+01:00 "I think there is a problem with vertical scale factors in istate.F90 when ssh/=0 and linssh=false (either with wetting and drying or with user defined ssh). Gurvan wrote a comment in the code also. Vertical scale factors must be recalculated in these cases and they are not. Solution: simply call dom_vvl_zgr I am not sure it applies to the trunk because I do not know where ssh is initialized wrt vertical scale factors" 2732 Use of non-standard intrinsic function ISNAN env trunk Defect smueller assigned 2021-10-14T14:22:46+02:00 2022-01-07T15:21:14+01:00 "==== Context The defect described in ticket #2720 is also present in the current trunk version of NEMO. ==== Analysis See ticket #2720. ==== Recommendation The modification recommended in ticket #2720 would also be suitable to resolve this defect in the trunk version of NEMO. " 2105 Phasing FCM version in vendors with a tag release from metomi Github repository env trunk Request nicolasmartin assigned 2018-06-19T15:35:53+02:00 2020-03-28T12:36:57+01:00 "== Context The FCM source code included with NEMO looks quite outdated. The last commit by Seb goes back 5 years ago and the last overall import has 8 eight years old: browser:/vendors/FCM@9621 Few weeks ago, I ran a basic and simple test by replacing the content of the FCM directory with a import of the last release from [https://github.com/metomi/fcm the official repository] and I did not encounter any issue at compilation. == Proposal Actually, the upgrade seems to be straightforward by replacing the current release (labelled as 1-5 release) with the last one (2017.10.0) but the Met Office staff would certainly have more information and an informed opinion on what it is safe to do here. " 2016 ENHANCE-11 Trusting-SETTE cooperation (previously 2018WP) env trunk Unscheduled Task nicolasmartin assigned 2018-02-19T17:28:50+01:00 2019-09-04T14:55:29+02:00 "== Context The SETTE and Trusting tools are more or less doing the same kind of things so it is clear that at some point the two will become one. \\ With Trusting as a building block, the most likely is that SETTE evolve to a kind of Trusting manager that will launch several Trusting instances to validate a development branch. == Implementation plan This action should be a first step towards the tools merge by sharing some files/scripts to ease further development. " 2015 ENHANCE-06 Repository cleaning (previously 2018WP) env trunk Unscheduled Task nicolasmartin assigned 2018-02-19T14:43:00+01:00 2021-02-02T15:12:15+01:00 "== Context The way we use the repository has getting worse over years as we have stopped to follow the best practices. A repository should constantly evolved and would just reflect the ongoing work, then it should be easy to find inside the official releases without difficulties. Instead we have one which is full of all developments done since the code has been put under version control, even the official releases are hidden in the middle of the development branches. In addition to not deleting dev branches after merging, we have lost in particularly a clever organisation of the repository. Each branch newly created add 1 Go to the repository and the vast majority of the duplicate code will not be modified (outside `CONFIG` and `NEMO`). As a result, the repository has grown to a huge size (~130 Go !) that prevents the developers to be able to work with a entire working copy (~ 1 hour for downloading and endless updates). == Implementation plan The goal is to recover a proper state of the repository along with a new trunk structure, that tends to minimize the unnecessary copies by taking out the dependencies development. It will not delete the history of the repository but the tree structure of the repository for further revisions starting from this cleaning. Each item could be recovered by updating/downloading selected revision. The first part of the action could be lead quickly, it is mainly a cleaning of '[source:/branches /branches]' and '[source:/tags /tags]' repository paths with a move of the official releases to '/tags' and several additions of files at the trunk root. The second part is much more intrusive with a vast reorganisation of the trunk which includes many moves to [source:/vendors/ '/vendors'] path, mergers and renaming of directories. The best moment for doing this would be between the release of 4.0 and the beginning of the new developments in order to have the same organisation in every development branch." 1644 Few bugs in Trusting process env trunk Defect nicolasmartin assigned 2015-12-02T16:45:43+01:00 2020-04-23T09:55:07+02:00 "No automatic conflict resolution when updating the working copy of NEMO => Add option '--accept=theirs-conflict' or '--accept=theirs-full' in the only case of updating to the head of the trunk Simple gzip command not fitting all possibles cases when uncompressing forcing archive => Restore find command with exec option to descend in the directory hierarchy of the forcing folder" 1640 Wiki page for Trusting env trunk Documentation Request nicolasmartin assigned 2015-11-27T16:54:37+01:00 2022-02-04T18:12:12+01:00 2677 unit of the icb calving file ICB trunk Defect mathiot assigned 2021-05-19T14:28:23+02:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context Unit of the icb calving file is not described in the namelist and in the documentation. The unit is in km3 of iceberg / y, icebergs being at a density of rn_rho_bergs and not km3 weq / y as mentioned in some comments in icbclv and icbstp. This makes the input file somehow dependent of the NEMO namelist as the user most of the time want to prescribe a flux in Gt/y or any derived unit as kg/s and derived a calving file from this (using rn_rho_bergs). ==== Recommendation Easiest: - add a description of sn_icb in the doc and mention the unit in the namelist. - correct comments mentioning units is in km3 weq / y To be discussed by ST: - Should the unit of the input file changed from km3 of iceberg / y to kg / s (icbclv) ? " 2647 Derived data type component name shadowing FORTRAN keyword #mixedprecision ICB trunk Request sparonuz assigned 2021-03-30T18:26:08+02:00 2022-01-07T15:21:14+01:00 "==== Context In file OCE/ICB/icblbc.f90 is declared the following {{{ TYPE, PUBLIC :: buffer INTEGER :: size = 0 REAL(wp), DIMENSION(:,:), POINTER :: data END TYPE buffer }}} Both components have a name that shadows an intrinsic statement. Specifically - this intrinsic procedure [https://gcc.gnu.org/onlinedocs/gfortran/SIZE.html#SIZE] and - this statement [https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn85/index.html] ==== Analysis Even if the compiler does not complain, it is not a good practice and a possible source of error or confusion. It is also a source of disturbance during the parsing part of the mixed precision implementation's workflow. Even though the second is a Fortran 77 statement, and in some usage is obsolescent, as explained on page 140 of'' Modern Fortran Explained'' (Metcalf, Cohen & Reid) in some cases is still needed: > ''We recommend using the type declaration statement rather than the data statement, but the data statement must be employed when only part of a variable is to be initialised. '' (I mentioned this because the authors are members of the WG5, which is responsible for the development of Fortran) ==== Recommendation I would rather change the data type to {{{ TYPE, PUBLIC :: buffer INTEGER :: buffer_size = 0 REAL(wp), DIMENSION(:,:), POINTER :: buffer_data END TYPE buffer }}} And coherently in the whole file icblbc.f90 (it is the only file where this DS is used). " 2657 groups in field_def.xml IOM v4.0.* Defect clem assigned 2021-04-16T16:40:05+02:00 2022-01-07T15:21:14+01:00 " ==== Context Creating a group of variables in field_def.xml when variables are not of the same type is problematic. I just did it for outputing conservation diagnostics (the one called OCE_BUDGET in field_def_oce.xml). When this group is called in file_def_oce.xml (instead of calling each variable), then the last output (in time) is not written properly in the netcdf file (NaN values). ==== Analysis I think it occurs when mixing up SBC variables (nn_fsbc/=1) with other variables in the same group, though I do not understand why calling a group is different from calling each variable directly in the file_def.xml. Setting nn_fsbc=1 resolves the issue but this is not a good solution. In conclusion, one must be aware of that issue and this is why I opened a ticket. I did not check for the trunk but I suppose this is the same thing ==== Recommendation Ask Yann Meuredesoif... " 2427 DATAINT-02_smueller_IOM_revision IOM trunk Unscheduled Task smueller assigned 2020-03-31T20:08:45+02:00 2021-04-14T13:04:08+02:00 "==== Workplan action Wikipage: wiki:2020WP/DATAINT-02_smueller_IOM_revision" 2714 ln_nnogather option not working for nn_hls=2 LBC trunk Defect acc assigned 2021-07-30T14:03:07+02:00 2022-01-07T15:21:14+01:00 " ==== Context Default ORCA2 based SETTE tests are still failing SETTE tests with nn_hls=2. There appear to be two issues (at least): one is associated with tiling and the other with the ln_nnogather option. Setting ln_nnogather=.false. allows a full set of SETTE passes if the -t option is used with sette.sh. Even without tiling, ORCA2_ICE_PISCES reproducibility fails when ln_nnogather=.true.. This ticket addresses the ln_nnogather issues first. ==== Analysis Adding the following code to stpmlf.F90 provides evidence of a change in results simply arising from the choice of ln_nnogather: {{{#!diff Index: OCE/stpmlf.F90 =================================================================== --- OCE/stpmlf.F90 (revision 15160) +++ OCE/stpmlf.F90 (working copy) @@ -93,6 +93,9 @@ !!---------------------------------------------------------------------- INTEGER :: ji, jj, jk, jtile ! dummy loop indice REAL(wp), ALLOCATABLE, DIMENSION(:,:,:) :: zgdept + REAL(wp), DIMENSION(jpi,jpj) :: try1, try2 + INTEGER :: jtyp + CHARACTER(LEN=1), DIMENSION(4) :: ctyp = (/'T','U','V','W'/) !! --------------------------------------------------------------------- #if defined key_agrif IF( nstop > 0 ) RETURN ! avoid to go further if an error was detected during previous time step (child grid) @@ -128,6 +131,19 @@ IF( lk_diamlr ) CALL dia_mlr_iom_init ! with additional setup for multiple-linear-regression analysis CALL iom_init_closedef IF( ln_crs ) CALL iom_init( TRIM(cxios_context)//""_crs"" ) ! for coarse grid + DO jtyp=1,4 + DO_2D(nn_hls, nn_hls, nn_hls, nn_hls ) + try1(ji,jj) = mig(ji) + (mjg(jj)-1)*jpiglo + try2(ji,jj) = mig(ji) + (mjg(jj)-1)*jpiglo + END_2D + ln_nnogather=.false. ; CALL lbc_lnk('tryme', try1, ctyp(jtyp), 1._wp) + ln_nnogather=.true. ; CALL lbc_lnk('tryme', try2, ctyp(jtyp), 1._wp) + DO_2D(nn_hls, nn_hls, nn_hls, nn_hls ) + IF(ABS(try1(ji,jj) - try2(ji,jj)) .gt. 0._wp ) THEN + write(*,*) 'NAREA:'//ctyp(jtyp)//' ',narea,ji,jj,try1(ji,jj),try2(ji,jj) + ENDIF + END_2D + END DO ENDIF IF( kstp == nitrst .AND. lwxios ) THEN CALL iom_swap( cw_ocerst_cxt ) }}} which, when run, produces this from the restartability test: {{{ NAREA slurm-421072.out NAREA:T 29, 1, 17, 27421., 27597. NAREA:T 29, 2, 17, 27420., 27598. NAREA:U 29, 1, 17, 27420., 27597. NAREA:U 29, 2, 17, 27419., 27598. NAREA:V 29, 1, 17, 27237., 27597. NAREA:V 29, 2, 17, 27236., 27598. NAREA:V 29, 1, 18, 27053., 27237. NAREA:V 29, 2, 18, 27052., 27236. NAREA:V 29, 1, 19, 26869., 27053. NAREA:V 29, 2, 19, 26868., 27052. NAREA:W 29, 1, 17, 27421., 27597. NAREA:W 29, 2, 17, 27420., 27598. NAREA:U 30, 47, 17, 27508., 27509. NAREA:U 30, 48, 17, 27508., 27509. NAREA:U 31, 2, 17, 27508., 27509. NAREA:U 31, 3, 17, 27508., 27509. NAREA:T 32, 49, 17, 27420., 27598. NAREA:U 32, 1, 17, 27465., 27552. NAREA:W 32, 49, 17, 27420., 27598. }}} ==== Recommendation None. I do not recognise the current implementation of the ln_nnogather option. Hopefully someone in the team will have a better idea where to start digging. Secondary recommendation would be to add this test, or something similar, to a permanent testing suite. " 2624 HPC-07_Irrmann_try_new_pt2pt_comm LBC trunk Unscheduled Task smasson assigned 2021-02-12T11:51:14+01:00 2022-01-14T12:04:58+01:00 " ==== Workplan action Wikipage: wiki:2021WP/HPC-07_Irrmann_try_new_pt2pt_comm " 2138 key_nemocice_decomp still needed? LBC trunk Unscheduled Defect smasson assigned 2018-10-14T12:08:52+02:00 2022-02-17T15:59:08+01:00 " == Context Do we still need key_nemocice_decomp in v4.0? == Proposal ... " 2135 Memory Bug requries compilation flag to zero all arrays to overcome in AMM15 LDF trunk Bug deazer assigned 2018-10-04T19:12:12+02:00 2019-12-13T09:31:37+01:00 " == Context AMM15 cannot be run in NEMO4 Beta on a large number of nodes without the use of a flag to initialize all arrays to 0. e.g. -ez on cray == Analysis AMM15 will not restart if using a certain number of nodes. Below tis number it will run but wil not be reproducible across different domain decompositions without the -ez flag. Initial analysis isolated the arrays ahmt, ahmf in ldfdyn.F90 these can be set directly to zero, e.g. {{{#!f ahmt(:,:,:) = 0._wp ahmf(:,:,:) = 0._wp }}} and the model will at least run but remains not reproducible Further analysis is required to isolate remaining uninitialized data that is causing the reproducibility problem in AMM15 Note the default configurations do not appear to be affected by this bug. == Fix ... " 2752 Undefined variable in timing.F90 MULTIPLE v4.0.* Bug emmafiedler assigned 2021-12-13T17:58:06+01:00 2022-01-07T15:21:14+01:00 "==== Context zperc is undefined in src/OCE/timing.F90 when ztot == 0 ==== Analysis This is unlikely to be of particular importance but causes a compiler error when using debugging flags. ==== Fix Initialise zperc to 0 to avoid this issue " 2694 iom_put without halos MULTIPLE trunk Defect smasson assigned 2021-06-18T12:08:51+02:00 2022-01-07T15:21:14+01:00 " ==== Context In the actual version of the code, in iom_put (and because of the way we defined our interface with xios): - we give to xios arrays defined over the full domain (jpi,jpi) - we say to xios to write data only over the inner domain (Ni_0, Nj_0) The problem is that in many cases (in most of cases?), output variables are diagnostics that could be computed only over the inner domain. Having to use full domain arrays forces us to do more computation, to call lbc_lbk (that is incompatible with a proper use of the tiles) or to use arrays with uninitialized halos which prevents to use the debug options. The ideal solution would be to be able to use iom_put (and therefore xios) for variables defined over the full domain or over the inner domain only. Unfortunately this is something which is not possible easily with the actual version of xios. ==== Analysis I had a discussion with Yann Meurdesoif to try to find the best way to sort this out. He proposed 2 “solutions"": 1) the simplest solution is to setup xios so it is expecting is inner domain arrays and to “cut” the full domain into inner domain arrays before calling xios. This is the solution I coded last year but it generates arrays copies and slow down the code significantly. We decided to remove it. see #2563 and changeset [13747] 2) the second solution is good for performances but bad for users and maintenance: The idea is to define 2 set of grids: gridT/U/V/F over the full domain and gridT/U/V/F over the inner domain. The modifications are quite easy to do in the code. The problem is that we would have to modify the xml files: - We would need to duplicated the contain of grid_def_nemo.xml to have for example grid_T_2D_full and grid_T_2D_inner instead than a simple grid_T_2D - next in all the field_def_nemo-*.xml files, we sould make sure that the grid linked to the variable is the proper one… there is more than 1200 variables... ==== Recommendation we decide to go for solution (2)" 2654 VLD-08_CEthe_IPSL_Coupled_Model MULTIPLE trunk Unscheduled Task cetlod assigned 2021-04-08T14:17:03+02:00 2022-01-14T12:04:58+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2021WP/VLD-08_CEthe_IPSL_Coupled_Model " 2742 Bug: OBStools does not compile OBS trunk Bug mathiot assigned 2021-11-18T12:16:37+01:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context OBStools from the trunk does not compile. ==== Analysis OBStools, have some how the same 'issue' as DOMAINcfg, it is dependant of NEMO source file. In DOMAINcfg, the choice has been made to duplicate the part of NEMO needed. In OBStools, the part of the code needed are based on symbolic link. With the 'recent' change of the code. For exemple in OBStools src directory some links are broken and some file are missing (for exemple do_loop_substitute.h90). ==== Fix - update OBStools to be compatible with recent NEMO changes ==== Suggestion - in SETTE, add a test on compilation of all the tools " 2700 IOM-02_Ford_OBS OBS trunk Unscheduled Task dford assigned 2021-06-23T15:44:22+02:00 2022-01-14T12:04:58+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Make OBS interface more generic, add observation operator for SI3 and surface currents, improve SLA observation operator Wikipage: wiki:2021WP/IOM-02_Ford_OBS " 2683 File OCE/OBS/obs_fbm.F90 custom precision #mixedprecision OBS v4.0.* Request sparonuz assigned 2021-05-31T17:34:32+02:00 2022-01-07T15:21:14+01:00 "==== Context In file File OCE/OBS/obs_fbm.F90 there are the following lines {{{ IMPLICIT NONE PUBLIC ! Type kinds for feedback data. INTEGER, PARAMETER :: fbsp = SELECTED_REAL_KIND( 6, 37) !: single precision INTEGER, PARAMETER :: fbdp = SELECTED_REAL_KIND(12,307) !: double precision }}} These are basically redefining the same precision (singe/double) already defined (publicly) in file OCE/par_kind.F90 {{{ INTEGER, PUBLIC, PARAMETER :: sp = SELECTED_REAL_KIND( 6, 37) !: single precision (real 4) INTEGER, PUBLIC, PARAMETER :: dp = SELECTED_REAL_KIND(12,307) !: double precision (real 8) }}} If this was not made for a matter of flexibility, the definition should be removed and the global parameter should be used instead. ==== Proposal I propose to add a {{{ use par_kind }}} at the beginning of the file and change all the variables defined as {{{ REAL(KIND=fbdp), DIMENSION [...] :: my_var1 REAL(KIND=fbsp), DIMENSION [...] :: my_var2 }}} to {{{ REAL(KIND=dp), DIMENSION [...] :: my_var1 REAL(KIND=sp), DIMENSION [...] :: my_var2 }}} ... " 2298 Bug fixes to OBS and ASM found when reviewing the documentation OBS v4.0.* Bug djlea assigned 2019-06-14T20:17:47+02:00 2020-06-24T10:12:14+02:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Context The OBS and ASM documentation will be updated as discussed in ticket #2297. This is likely to highlight some bugs to fix. These will be detailed in this ticket. ==== Analysis One change I would like to make is that the OBS grid search outputs some debugging values histx etc. These are confusing and not useful. I propose removing this output. ==== Fix ... " 2297 Updates to ASM and OBS documentation OBS v4.0.* Task djlea assigned 2019-06-14T20:13:06+02:00 2022-02-04T18:05:08+01:00 "==== Context The documentation for OBS and ASM needs reviewing as it is likely out of date with respect to NEMO release 4. ==== Proposal * I propose to review the OBS and ASM chapters for errors and anything out of date. * I will also test the examples given to ensure the instructions are correct There will be an associated ticket which will include any (small) bug fixes which are found to be necessary. " 2068 Wrong namelist double diffusion mixing parameter name OCE Unscheduled Defect Robin_Waldman assigned 2018-03-26T15:38:31+02:00 2020-12-11T17:31:33+01:00 "== Context I am currently checking the activation of the EVD scheme in the case of differential T-S mixing, either due to the double-diffusion mixing parametrization or to the new De Lavergne tidal mixing parametrization. Tests are done with NEMOMED12 configuration in the Mediterranean Sea. == Analysis - The double diffusion mixing parametrization has 2 namelist parameters, one of which is wrongly named. rn_hsbfr is actually not the buoyancy flux ratio (constant=0.7 in zdfddm.F90) but the critical density ratio Rc, above which double diffusion rapidly decays. - Also, the activation of key_zdftmx_new imposes the activation of the double diffusion mixing parametrization, which is not necessarily desired. == Recommendation - Rename rn_hsbfr as rn_cdr for critical density ratio, and if useful introduce a new namelist parameter rn_hsbfr with default value 0.7. - Introduce a logical in the namzdf_ddm section to activate or not double diffusion mixing when key_zdfddm is activated. ... " 2055 ENHANCE-14_cethe_PISCES_LBC OCE trunk Unscheduled Task clevy assigned 2018-02-26T18:52:09+01:00 2019-02-27T21:37:47+01:00 "== Context ... == Implementation plan ... " 2054 ENHANCE-07_crousset_LIM3adv_valorisation OCE trunk Unscheduled Task clevy assigned 2018-02-26T18:49:49+01:00 2019-02-27T21:37:47+01:00 "== Context ... == Implementation plan ... " 2052 ENHANCE-09(2018WP)_rbourdal_massfluxconvection OCE trunk Unscheduled Task rbourdal assigned 2018-02-26T15:37:18+01:00 2021-04-14T13:04:08+02:00 "== Context Implementation of a mass flux scheme for convection. Resolution of the convection as in atmospheric model. Improvement of the deep convection and vertical velocity associated (up and down). Alternative at evd or npc formulation. == Proposal implementation in NEMO1D (January-June) Then test in 3D" 2046 PUBLI-03_SFlavoni-advectionscheme-analysis OCE trunk Unscheduled Task flavoni assigned 2018-02-26T11:13:07+01:00 2019-02-27T21:37:47+01:00 "== Context ... == Implementation plan ... " 2044 ENHANCE-09_Gurvan-GEOMETRIC OCE trunk Unscheduled Task gm assigned 2018-02-26T08:43:20+01:00 2019-02-27T21:37:47+01:00 "== Context introduction of the GEOMETRIC parameterization of unresolved eddies (Marshall al. 2017, Mak et al. 2017) == Implementation plan ..." 2036 SEAICE-05_crousset_coupled_interface OCE trunk Unscheduled Task clevy assigned 2018-02-23T17:58:12+01:00 2019-02-27T21:37:47+01:00 "== Context ... == Implementation plan ... " 1967 Noise on vertical velocities when using UBS momemtum advection scheme OCE Unscheduled Defect ctlod assigned 2017-10-18T16:57:39+02:00 2020-12-11T17:31:33+01:00 "Context Under few circumstances, that have to be clarified, noise on vertical velocities arises when using the UBS momentum advection scheme. It has been observed in several configurations with various horizontal resolution (1/4°, 1/12°). This noise seems to develop close to sharp shelves and then expands offshore along either i or/and j grid direction. The attached figure illustrates this behavior in a regional configuration over the Arctic basin. It represents a monthly mean vertical velocity field around 700m depth. The noise emerges clearly in the Arctic area and is less visible within the north Atlantic region. [[Image(UBS_Wnoise_z735m.png)]] Analysis The origin of this noise is not yet identified and may also not be systematic. It looks like the implicit viscosity associated to this scheme is not working or is not strong enough; yet the algorithm itself may not be the source of the problem since 2 configurations using exactly the same module dynadv_ubs.F90 have different behavior: one with noise while the other without. Below, a list of options that may not be responsible for this noise (deduced from an inter-comparison of 4 configurations namelist and CPP keys) : * the non linear free surface (VVL) or linear free surface * Partial or full steps * ln_logyer * ln_bfrimp * advective and/or diffusve BBL * GLS or TKE * Non Penetrative Convection (NPC) or Enhenced Vertical Diffusion (EVD) Fix No fix for the moment." 1959 ENHANCE-09_Jerome_freesurface(2017WP) OCE trunk Unscheduled Task cbricaud assigned 2017-10-12T09:48:36+02:00 2019-12-18T10:44:55+01:00 "== Summary #summary || '''Action''' || ENHANCE-09_Jerome_freesurface || || '''PI(S)''' || Jérôme Chanut || {{{#!td '''Digest''' }}} {{{#!td Improve split-explicit free surface: \\ 1) Tracer conservation issues (all time splitting options do not ensure global and local tracer conservation): '''DONE''' \\ 2) Missing correction terms in the barotropic equations relative to internal pressure gradients. This would reduce mode splitting error, hence improve stability \\ 3) Work on the stability of barotropic time stepping (based on INRIA's work) to possibly remove time filtering of barotropic variables. This would limit the temporal dissipation and greatly ease online coupling of nested domains at barotropic level (with AGRIF). '''DONE''' }}} |- || '''Dependencies''' || '' '' || || '''Target''' || ''2019 WP'' || || '''Trac Ticket''' || #1959 || || '''SVN branch''' || [source:/branches/2019/dev_r10951_ENHANCE-09_Jerome_freesurface] || || '''Previewer(s)''' || ''Gurvan Madec'' || || '''Reviewer(s)''' || ''Gurvan Madec'' || || '''Link''' || ""wiki:2019WP/ENHANCE-09_Jerome_freesurface"" || || " 1918 ENHANCE-17(2017WP) — Multi-Column Ocean scheme (MCO) OCE trunk Unscheduled Task gm assigned 2017-07-03T16:10:26+02:00 2018-09-25T15:08:34+02:00 "= Context \\ Introduction of the Multi-Column Ocean scheme (MCO) developed by Barthélemy et al. (Ocean Modelling 2016), i.e. a subgrid-scale representation of ice-ocean interactions. \\ = Implementation \\ LIM3 includes an ice thickness distribution, which provides heterogeneous surface buoyancy fluxes and stresses. The MCO scheme take them explicitly into account, by computing convection and turbulent vertical mixing separately in the open water/lead fraction of grid cells and below each ice thickness category. The resulting distinct temperature and salinity profiles of the ocean columns are allowed to be maintained over several time steps." 1911 ENHANCE-04(2017WP) — MLF and RK3 time stepping OCE trunk Unscheduled Task gm assigned 2017-06-15T09:12:42+02:00 2019-04-04T18:52:29+02:00 "= Context \\ Introduce an optional RK3 time-stepping scheme. The scheme will: 0. be a valuable alternative to the current Modified Leap-Frog (MLF, Leclair and Madec OM2009) scheme, 1. prepare the futur introduction of a compensated time-space scheme, 2. allow AGRIF to be exactly conservative, and 3. make much more easier to use time coarsening of TRC and OFF-line variable volume calculation \\ = Implementation \\ Chosen strategy : keep both MLF and RK3 time-stepping in the code. This means : first transform the LF scheme to be consistent with a 2-level time-stepping environment, and then introduce the RK3 scheme. \\" 1908 ROMS wetting and drying scheme OCE trunk Unscheduled Task mikebell assigned 2017-06-05T09:27:59+02:00 2018-06-21T18:39:11+02:00 "= Context Implement ROMS wetting and drying scheme as an alternative to the NOC scheme \\ ... \\ = Implementation Involves changes only to dyn_spg_ts \\ ..." 1894 mass and heat budgets in NEMO OCE trunk Task clem assigned 2017-04-28T12:25:22+02:00 2019-12-05T11:53:59+01:00 "= Context Mass and heat fluxes in NEMO are a bit messy and should be cleaned at some point. Therefore this ticket is a reminder for what should be done (or discussed) for the next NEMO release As far as I understand, the mass budget of the ocean+ice/snow is written: $Doce + Dice + Dsnow = - emp_oce - emp_ice + rnf - fwfisf$ - emp_ice is E-P over sea ice - emp_oce includes calving (""calving_cea"") in addition to E-P over ocean - runoffs include icerbergs (""iceberg_cea"") in addition to river runoff - fwfisf is the ice-shelf melting (<0 = melting) This interleaving of variables makes things complicated when it comes to define a heat budget. - calving => we suppose Tcal = 0degC (i.e. no sensible flux) and latent heat is removed from qns to take into account the ocean heat uptake to melt the ice (in sbccpl.F90) - river runoff => we suppose Trnf = SST (in sbcrnf.F90) - iceberg => latent heat is removed from qns (in sbccpl.F90) but since we treat iceberg as a runoff, its temperature is also at the SST (in sbcrnf.F90) - ice-shelf => latent heat is removed from the ocean directly as a temperature change and the sensible flux is taken into account with a melting temperature fixed at -1.9 degC (in sbcisf.F90) Note that in coupled mode you generally have: - iceberg = half of the Antarctic fresh water flux is distributed in the ocean according to a climatology of icebergs distribution - iceshelf = half of the Antarctic fresh water flux is distributed along the coast where there is iceshelf - calving = Greenland fresh water is uniformly distributed = Fix - separate calving from emp_oce? - separate river runoff from icerbegs? - change temperature of the ice-shelf when melting? - change temperature for calving? - fwfisf does not follow the convention for runoff (>0 = input for the ocean) - other things?" 1829 Changes to C06 for climate simulation and reanalysis OCE Unscheduled Task hadjt assigned 2017-01-16T18:37:26+01:00 2020-12-11T17:31:33+01:00 "= Context = Changes to C06 for climate simulation and reanalysis = Changes = ..." 1796 CICE interface modification for initial CICE output OCE Bug dupontf assigned 2016-11-18T19:11:35+01:00 2020-12-11T17:25:04+01:00 "= Context the NEMO-CICE interface (tag 5516) is missing a correct initialization for the CICE initial output. Some impact as well on the initial ice temperature profile. Some cleanup and consistency between CICE4 and CICE5 = Analysis CICE does an initialization based on default fields (exception: CICE5 is passed the correct sst) which could be based on NEMO fields. This can impact the initial ice temperature profile and the initial CICE output. CICE4.0 takes default values for sss,sst,potT,Tair fields. CICE5 takes values for sss,potT,Tair fields (sst is passed before the start of CICE init phase) = Fix add a second init and CICE output after the correct sss,sst,Tf,potT,Tair fields are passed. (See attached file) some other minor cosmetic changes such as: 1. the array ztmp is useless between 396 and 416 [[IncludeSource(branches/2015/nemo_v3_6_STABLE/NEMOGCM/NEMO/OPA_SRC/SBC/sbcice_cice.F90, start=390, end=420, rev=8572)]] 2. mass ice embedding has lines redundant with dom_vvl_init. Since those could useful as well in case of hot initialization, I suggest moving them in a distinct routine in domvvl.F90 so that they can be called anytime needed. The only difference is dom_vll_init has {{{#!f fse3t_a(:,:,jpk) = e3t_0(:,:,jpk) }}} whereas sbcice_cice has {{{#!f fse3t_a(:,:,:) = fse3t_b(:,:,:) }}} the latter being more consistent to my opinion and has no impact when ssh=0 (which is assumed when calling dom_vvl_init) additional comment: could be merged with #1428 of Tim Graham, since I also believe that a consistent calculation of the freezing temperature is needed in NEMO and CICE." 1646 pit falls of choosing parameters in the F-S sigma code OCE v4.0.* Defect jamesharle assigned 2015-12-03T11:44:22+01:00 2020-03-28T13:12:52+01:00 "Having had a look at the NOCL set up of a high resolution AMM60 configuraton I've come across a possible pit fall concerning the choice of parameters in the Furner-Siddorn vertical coordinates. See the attached figures of the top grid box depth (e3t) using the Siddorn-Furner sigma coords for hc=150 and hc=50 (50 being the default shipped with NEMO for the AMM12 domain). Spot the discontinuity! {{{#!div style='text-align: center' [[Image(fs_hc_150.png)]][[Image(fs_hc_50.png)]] }}} From reading the code - it looks like the fixed surface grid box depth (rn_zs=1m in AMM60) and stretched coordinates come into play at depths > hc. Anything less than the hc depth and we're in pure sigma - so as AMM60 has only 50 wet vertical levels - top grid box (e3t) is going to just under 3m at depths approaching 150m (i.e. hc=150). And that's why hc = 50 looks as it should! If hc < jpk you'd have the reverse scenario: a very sudden shallowing of the depth of the top grid box. So I guess the guidance for this is to make hc = jpk (for rn_zs=1m)! Or more generally hc = jpk * rn_zs To avoid users selecting inappropriate combinations of these parameters, perhaps 'hc' should be set in the furner-siddorn subroutine and a WARNING issued if it differs from the one in the namelist? " 1601 Add code for flux adjustment runs OCE trunk Unscheduled Task kuniko assigned 2015-09-24T12:33:01+02:00 2020-06-24T10:06:16+02:00 "Met Office internal work (not in workplan but may go back to trunk at some point) Add a module to SBC to read in flux adjustment fields and add to surface fluxes branch: https://forge.ipsl.jussieu.fr/nemo/browser/branches/UKMO/dev_r5518_flux_adjust" 1579 Assumption initial conditions are on z-levels when ln_sco = .true. OCE trunk Request jamesharle assigned 2015-07-17T10:28:22+02:00 2020-03-28T12:39:53+01:00 "The initial conditions for runs ln_sco = .true. are assumed to be on z-levels based on gdept_1d. This is not immediately apparent from reading the manual. A few options would be to either: - modify code such that depth information is required in the initial condition file. This would allow an initial condition file, comprising a different number of levels and/or gird type, to be read in and interpolated onto gdept_0. - remove the interpolation loop completely (bearing in mind the on-going simplification process) and impose that the initial conditions read in have to be on gdept_0, requiring a pre-processing step." 1463 CNRS-13(2015WP) - Subduction diagnostics OCE trunk Unscheduled Task cetlod assigned 2015-02-04T12:23:59+01:00 2018-09-25T15:09:06+02:00 "Add useful diagnostics of subduction of water masses Already coded/tested in v3.4 ; adapt to the current version" 2659 TOP-01_CEthe_PISCES_NEWDEV PISCES trunk Unscheduled Task cetlod assigned 2021-04-29T11:03:04+02:00 2022-01-14T12:04:58+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Improvments of PISCES biogeochemical model Wikipage: wiki:2021WP/TOP-01_CEthe_PISCES_NEWDEV " 2741 bug: SAO does not compile SAO trunk Bug mathiot assigned 2021-11-17T15:03:07+01:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context I tried to use SAO in the trunk and it does not compile. ==== Analysis SAO is still using old name and dimension like tsn. ==== Recommendation - Fix compilation error. - Test SAO." 2750 Coupled mslp in inverse barometer ssh SBC v4.0.* 2021 WP Defect jcastill assigned 2021-11-25T10:46:01+01:00 2021-12-09T12:54:12+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context The inverse barometer ssh is calculated from the mean sea level pressure as read for a netcdf forcing file. When coupling to an atmospheric model it is possible that the mslp field is received via coupling, but the inverse barometer ssh still requires an external file to read mslp. ==== Analysis The routines that calculate the inverse barometer ssh read by default the mslp from a netcdf file without taking into account the fields received via coupling. ==== Recommendation It would be advisable to use mslp as read from coupling when it is available in all calculations for consistency. " 2749 Wave coupling only: diurnal cycle reconstruction error SBC trunk 2021 WP Defect jcastill assigned 2021-11-25T10:15:44+01:00 2021-12-08T16:08:28+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context When running in coupled mode but not coupling to an atmospheric model, and when using diurnal cycle reconstruction (ln_dm2dc=.true.), NEMO will stop with an error: sbc_cpl_rcv: diurnal cycle reconstruction (ln_dm2dc) needs daily couping for solar radiation ==== Analysis Here NEMO still assumes that when it is running in coupled mode it is coupled to an atmosphere model. In coupling mode the diurnal cycle frequency (ncpl_qsr_frq) is calculated as the sum of the coupling frequency of the atmospheric radiation terms, and this value is required to be equal to one day. If there is no atmospheric coupling, which is something perfectly valid to do (for example when coupling only to a wave model), this frequency is equal to zero and the code throws an error. ==== Recommendation Throw the error mentioned above only if the frequency is not equal to one day and if atmosphere coupling is taking place (ln_cpl=.true.) " 2740 For better management of ln_rnf_icb SBC trunk Request mathiot assigned 2021-11-17T10:49:26+01:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context ln_rnf_icb is an option to add a climatology of icb melt. This option is embedded within the rnf module. Here are some points we realised. As it is, using this option in a regional configuration like WED025 (ie no liquid river runoff) is not possible without adding an river runoff file full of 0. ==== Proposal To fix the issue mentioned above and ease the setting of icb in the namelist, I suggest to have all the icb related variables inside the namberg namelist bloc with a something similar to what is done for the isf with explicit cavities and parametrised cavities : - a master flag ln_berg to activate the icebergs module * ln_icb_clim to trigger the use of an iceberg climatology * ln_icb_lagr to trigger the icb lagrangian model. " 2709 SI3-01_Copsey_coupled_penetrating_radiation SBC trunk Unscheduled Task dancopsey assigned 2021-07-12T18:53:18+02:00 2021-12-01T16:15:58+01:00 "Add solar penetrating radiation (into sea ice) into the coupler so that it can be passed from the atmospheric component. ==== Workplan action Wikipage: wiki:2021WP/SI3-01_Copsey_coupled_penetrating_radiation " 2708 IOM-04_Copsey_0D_icesheet_mass_coupling SBC trunk Unscheduled Task dancopsey assigned 2021-07-12T18:51:20+02:00 2021-12-01T16:15:34+01:00 "Alter NEMO to accept two scalar quantities from the coupler: Greenland icesheet mass and Antarctic icesheet mass. This is used to modify iceberg calving and iceshelf melt rates. ==== Workplan action Wikipage: wiki:2021WP/IOM-04_Copsey_0D_icesheet_mass_coupling " 2707 IOM-03_Copsey_1D_river_coupling SBC trunk Unscheduled Task dancopsey assigned 2021-07-12T18:48:30+02:00 2021-12-01T16:15:18+01:00 "Alter NEMO to accept a 1D array of river runoff from the coupler and then redistribute that runoff over predefined runoff points as defined by a new NEMO netcdf ancillary file. ==== Workplan action Wikipage: wiki:2021WP/IOM-03_Copsey_1D_river_coupling " 2674 Allow cdgw if ln_NCAR SBC trunk Bug emanuelaclementi assigned 2021-05-17T11:07:22+02:00 2022-01-07T15:21:14+01:00 "Modification to allow the use of neutral drag coefficient from wave model if ln_NCAR ==== Context ... ==== Analysis ... ==== Recommendation Modify sbcwave.F90 IF( ln_cdgw .AND. .NOT. ln_NCAR ) & & CALL ctl_stop( 'drag coefficient read from wave model NOT available yet with aerobulk package except for NCAR bulk') " 2612 VLD-02_Aimie_Moulin_Med_Wave_Coupling SBC trunk Unscheduled Task sciliberti assigned 2021-02-01T17:19:19+01:00 2022-01-14T12:05:56+01:00 Validation of the NEMO-Wave coupling in the Mediterranean Sea 2488 Inflexible calendar year and approximate conversion in option 2 of the freshwater-budget adjustment mechanism SBC trunk Defect smueller assigned 2020-06-11T20:28:45+02:00 2020-12-04T11:03:05+01:00 "==== Context The defect described in ticket #2487 is also present in the current trunk version of NEMO. ==== Analysis See ticket #2487. ==== Recommendation After substitution of `rdt` by `rn_Dt` and `rau0` by `rho0`, the modifications recommended in ticket #2487 should be suitable for removing this defect from the current trunk version of NEMO. " 2487 Inflexible calendar year and approximate conversion in option 2 of the freshwater-budget adjustment mechanism SBC v4.0.* Defect smueller assigned 2020-06-11T19:54:56+02:00 2021-10-27T16:46:32+02:00 "==== Context Option 2 of the freshwater-budget adjustment mechanism (`nn_fwb = 2`, module `sbcfwb`) uses a fixed calendar year of 365 days rather than that of the selected model calendar to time annual updates of the adjustment flux; this issue has previously been reported in the form of source-code comments (source:/NEMO/releases/r4.0/r4.0-HEAD/src/OCE/SBC/sbcfwb.F90@12578#L129 and source:/NEMO/releases/r4.0/r4.0-HEAD/src/OCE/SBC/sbcfwb.F90@12578#L135). Further, the conversion of the combined sea-level, sea-ice, and snow anomaly into an equivalent freshwater flux is approximate and not in line with corresponding conversions used elsewhere in the model. ==== Analysis In option 2 of the freshwater-budget adjustment mechanism, year boundaries are identified whenever the reminder of the division of the time step counter by `365 * 86400 / rdt` equals zero (source:/NEMO/releases/r4.0/r4.0-HEAD/src/OCE/SBC/sbcfwb.F90@12578#L130). This i) fixes the adjustment interval to 365 days, ii) sets the date for annual adjustment-flux updates to the date of `nit000 - 1` rather than the start of 1 January, and iii) leads to an update of the adjustment flux near the start of the final time step of each year (i.e., before completion of that model year). Line source:/NEMO/releases/r4.0/r4.0-HEAD/src/OCE/SBC/sbcfwb.F90@12578#L134 implements the conversion of a combined sea-level, sea ice, and snow anomaly into an equivalent annual-average freshwater flux using a literal value of 1000.0 for the density of sea water and 365 for the number of days in a year rather than variables `rau0` and `nyear_len(1)`, respectively. The impact of these approximations can be demonstrated using reference configuration `GYRE_PISCES` (which uses calendar years of 360 days) after replacing source:/NEMO/releases/r4.0/r4.0-HEAD/src/OCE/USR/usrdef_sbc.F90@12578#L134 by `zsumemp = 0.0_wp` and activation of the freshwater-budget adjustment by setting namelist parameter `nn_fwb = 2`. ==== Recommendation The annual average freshwater adjustment based on the sea-level and sea-ice anomaly at the end of the preceding model year should be computed using `daymod` variable `nyear_len` (i.e., the calendar year during which the adjustment will be applied) and using the reference sea-water density `rau0` rather than the literal values 365 and 1000.0, respectively. Further, it would be useful for interpretability of the effect of the freshwater-adjustment mechanism to exactly align the annual computation of the freshwater-budget adjustment with the model calendar. Therefore, adjustment-flux updates could occur in the first time step of each new year, which should be identified using variables updated by module `daymod` such as through the conditional `( ( nday_year == 1 ) .AND. ( nsec_day == NINT( 0.5_wp * rdt ) ) )`. " 2194 ENHANCE-12_SimonM-Tides SBC trunk Unscheduled Task smueller assigned 2018-12-20T13:12:53+01:00 2021-04-14T12:59:12+02:00 "==== Summary ||=Action || ''ENHANCE-12_SimonM-Tides'' || ||=PI(S) || ''Simon Müller, Nicolas Bruneau'' || ||=Digest || ''This action aims to enhance the implementation of tidal forcing with the addition of an optional, alternative parameter set for the harmonic expansion of the tide potential, by somewhat simplifying the existing code, and by converting a currently fixed coefficient into a namelist parameter.'' || ||=Dependencies || || ||=Branches || ''[source:/NEMO/branches/2019/dev_r11879_ENHANCE-05_SimonM-Harmonic_Analysis], has superseded [source:/NEMO/branches/2019/dev_r10742_ENHANCE-12_SimonM-Tides]; [source:/NEMO/branches/2019/dev_r13813_ENHANCE-12_SimonM-Tides_doc]'' || ||=Previewer(s) || ''Jérôme Chanut'' || ||=Reviewer(s) || ''Jérôme Chanut'' || ||=Wiki || ''[wiki:2019WP/ENHANCE-12_SimonM-Tides]'' || ==== Abstract This action aims to enhance the implementation of tidal forcing with the addition of an optional, alternative parameter set for the harmonic expansion of the tide potential, by somewhat simplifying the existing code, and by converting a currently fixed coefficient into a namelist parameter. ===== Description This action aims to enhance the implementation of tidal forcing with the addition of an optional, alternative parameter set for the harmonic expansion of the tide potential and by converting a currently fixed coefficient into a configurable namelist parameter; this work has previously been implemented and tested by Nicolas Bruneau in a pre-4.0beta version of NEMO. Further, this action aims to reduce the total number of modules related to tides (the current implementation comprises the modules sbctide, tideini, tide_mod, updtide, and bdytide) and to thereby somewhat simplify the current implementation of tidal forcing. ===== Implementation See [wiki:2019WP/ENHANCE-12_SimonM-Tides#Preview] {{{#!comment ''Describe flow chart of the changes in the code. \\ List the .F90 files and modules to be changed. \\ Detailed list of new variables (including namelists) to be defined, give for each the chosen name (following coding rules) and definition.'' }}} ===== Reference manual update See [wiki:2019WP/ENHANCE-12_SimonM-Tides#Documentation] {{{#!comment ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks. }}}" 2737 mass of the ice+ocean system depends on the init of ice SI3 v4.0.* Defect clem assigned 2021-10-29T16:05:47+02:00 2022-01-07T15:21:14+01:00 " ==== Analysis The mass of the ""ocean + ice"" system depends on the initialization of the ice cover. I think it should not. For instance, a simulation initialized with 1m of ice contains less mass than a simulation initialized with 2m of ice. This solely concerns levitating sea ice (the default). For embedded sea ice, ssh is depleted below the ice cover. This dependency problem has already been raised in ticket #2487 but not yet adressed. ==== Recommendation For embedded sea ice, the ssh is depleted below the ice cover so that the mass of the ""ocean+ice"" system does not depend on the ice initialization. I propose to do similar thing for levitating sea ice, except that the depletion is spread over the whole basin (including ice shelves). Here is the new piece of code I adapted from Simon to be added in iceistate.F90 (note that a special treatment for agrif is necessary): {{{#!fortran IF( ln_ice_embd ) THEN ! embedded sea-ice: deplete the initial ssh below sea-ice area ! ! ---------------- ssh(:,:,Kmm) = ssh(:,:,Kmm) - snwice_mass(:,:) * r1_rho0 ssh(:,:,Kbb) = ssh(:,:,Kbb) - snwice_mass(:,:) * r1_rho0 ! ELSE ! levitating sea-ice: deplete the initial ssh over the whole domain ! ! ------------------ area = glob_sum( 'iceistate', e1e2t(:,:) * ssmask(:,:) ) zsshadj = glob_sum( 'iceistate', snwice_mass(:,:) * r1_rho0 * e1e2t(:,:) ) / area #if defined key_agrif ! Override ssh adjustment in nested domains by the root-domain ssh adjustment; ! store the adjustment value in a global module variable to make it retrievable in nested domains IF( .NOT.Agrif_Root() ) THEN zsshadj = Agrif_Parent(rsshadj) ELSE rsshadj = zsshadj ENDIF #endif IF(lwp) WRITE(numout,'(A23,F10.6,A20)') ' sea level adjusted by ', -zsshadj, ' m to compensate for' IF(lwp) WRITE(numout,*) ' the initial snow+ice mass' ! WHERE( ssmask(:,:) == 1._wp ) ssh(:,:,Kmm) = ssh(:,:,Kmm) - zsshadj ssh(:,:,Kbb) = ssh(:,:,Kbb) - zsshadj ENDWHERE ! ENDIF }}} This change at the init makes the ssh to drop globally of about 10cm, but simulations with and without are very similar, though I do not have a simulation with open ice shelf cavities to test it. Of course, sette tests are fine. I think it needs to be implemented in both 4.0-HEAD and the trunk but '''I need the agreement of the system team before moving forward'''" 2191 PUB-03_NDS_CHAPTER SI3 trunk Unscheduled Task vancop assigned 2018-12-20T08:59:31+01:00 2021-04-14T13:04:08+02:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Summary ||=Action || ''${ACTION_NAME} Subject'' || ||=PI(S) || ''M. Vancoppenolle, Ed Blockley'' || ||=Digest || ''Brief description with motivations and main tasks'' || ||=Dependencies || || ||=Branch || ''[source:/NEMO/branches/$YEAR/dev_r{REV}_{ACTION_NAME}]'' || ||=Previewer(s) || || ||=Reviewer(s) || || ||=Wiki || ''wiki:`${YEAR}WP/...`'' || ==== Abstract NDS Ice chapter must be rewritten. ===== Description NDS ice chapter is dragging behind other NDS chapters. THis is because the sea ice unified model has become a bit late when writing the previous NDS document. This year, there is a scheduled workshop to provide elements to start rewriting this document. ===== Implementation ''Describe flow chart of the changes in the code. \\ List the .F90 files and modules to be changed. \\ Detailed list of new variables (including namelists) to be defined, give for each the chosen name (following coding rules) and definition.'' ===== Reference manual and web pages updates ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks." 2189 PUB-05_SI3_documentation SI3 trunk Unscheduled Task vancop assigned 2018-12-20T08:57:19+01:00 2021-04-14T13:04:08+02:00 "''SI3 documentation must be continued and reviewed'' ==== Summary ||=Action || ''${ACTION_NAME} Subject'' || ||=PI(S) || ''M. Vancoppenolle'' || ||=Digest || ''Brief description with motivations and main tasks'' || ||=Dependencies || || ||=Branch || ''[source:/NEMO/branches/$YEAR/dev_r{REV}_{ACTION_NAME}]'' || ||=Previewer(s) || || ||=Reviewer(s) || || ||=Wiki || ''wiki:`${YEAR}WP/...`'' || ==== Abstract Write and revise documentation. ===== Description Progress should be made on the documentation. There are a few missing chapters left, and progress should be done. ===== Implementation ''Describe flow chart of the changes in the code. \\ List the .F90 files and modules to be changed. \\ Detailed list of new variables (including namelists) to be defined, give for each the chosen name (following coding rules) and definition.'' ===== Reference manual and web pages updates ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks." 2186 SI3-03_VP_rheology SI3 trunk Unscheduled Task vancop assigned 2018-12-20T08:50:49+01:00 2021-04-14T13:04:08+02:00 "''BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading.'' ==== Summary ||=Action || ''${ACTION_NAME} Subject'' || ||=PI(S) || ''M. Vancoppenolle '' || ||=Digest || ''Brief description with motivations and main tasks'' || ||=Dependencies || || ||=Branch || ''[source:/NEMO/branches/$YEAR/dev_r{REV}_{ACTION_NAME}]'' || ||=Previewer(s) || || ||=Reviewer(s) || || ||=Wiki || ''wiki:`${YEAR}WP/...`'' || ==== Abstract Reintroduce a C-Grid VP Rheology ===== Description ''Reintroduce a C-Grid VP Rheology. Code available from MITgcm should form the basis (Zhang and Hilber 1997). \\ ===== Implementation ''Describe flow chart of the changes in the code. \\ List the .F90 files and modules to be changed. \\ Detailed list of new variables (including namelists) to be defined, give for each the chosen name (following coding rules) and definition.'' ===== Reference manual and web pages updates ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks." 2643 DOMAINcfg: bugs re-introduced tools trunk Bug mathiot assigned 2021-03-29T17:49:54+02:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context I had a look at the recent changes in DOMAINcfg and it appeared the fixes I did as part of #2588 at r14199 are gone at revision r14623. ==== Analysis The root causes of this issue are probably the same as the one described in ticket #2503: conflicts/troubles/issues during a merge. ==== Recommendation - Implement some of the suggestion made in ticket #2503 - For major changes in DOMAINcfg and other tools (REBUILD_NEMO, WEIGHTS ...) which are a critical tools for the users, apply the same development steps as for major changes in NEMO trunk." 2417 SETTE: Make sette universal tools trunk Unscheduled Task mathiot assigned 2020-03-18T17:19:25+01:00 2021-04-14T13:04:08+02:00 "==== Context As presented in ST meeting, SETTE need to be independant of the configuration itself (ie more universal). This will be easier to add a configuration and SETTE itself will move more slowly (and so more convenient as it is an external). ==== Proposal Step 1 and 2 presented in the attachment: - All the hard coded information should go in input_CFG file - Run 3 configurations (REF/RST/MPP) instead of 4 (LONG+SHORT/REPRO_48/REPRO_84) - build a generic function to run this 3 run - adapt the report generation accordingly. [https://forge.ipsl.jussieu.fr/nemo/attachment/wiki/SystemTeam/Agenda/2020-02-27/ST_sette.pdf] " 2743 Bug: OBS does not seem to take into account the eos used in NEMO TOP trunk Bug mathiot assigned 2021-11-18T15:17:32+01:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context OBS interpolates NEMO T and S onto the obs location. It works from the EN4 data converted into feedback files. These observations are in potential temperature and practical salinity. After looking at the model data interpolated and the code I think the data are not converted to the observations eos and the netcdf attributes of the _Hx variables are missleading. ==== Analysis I see different possible answer to improve this: - convert model T and S to observation expected T and S based on model eos and observation eos (function for conversion available in eosbn2 I think) - do not convert the model T and S but adapt the netcdf attributes of _Hx variables (not convinced it is in the spirit of the OBS operator) ==== Fix For solution 1, a call to eos_pt_from_ct can do the job for temperature. For salinity, a function eos_ps_from_sa need to be implemented. " 2730 Confusing coupling order - oasis send TOP v4.0.* Defect jcastill assigned 2021-10-11T11:12:36+02:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context In the file sbccp.F90, each field that can be exchanged via coupling has its own index. The order in which the fields are received via coupling is the same as fields index, but this is not true for the sent fields, as the order is hard coded in the routine sbc_cpl_snd. This can cause some confusion for users, which can easily create a deadlock condition, in particular in cases where several models are coupled to NEMO. ==== Analysis The index order of the oasis sent fields should be the same as the order in which the fields are coupled to increase clarity. ==== Recommendation The index order and the coupling order should be rearranged so that fields being sent to the same model component are grouped together to avoid potential deadlocks and to increase clarity and usability. The proposed order is: atmosphere, atmosphere ice, waves, wave ice. The addition of new coupling fields should take this order into account. " 2656 VLD-09_RPerson_Antarctic_ice_Sheet_Fe_Source TOP trunk Unscheduled Task rlod assigned 2021-04-16T14:13:55+02:00 2022-01-14T12:04:58+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Workplan action Wikipage: wiki:2021WP/VLD-09_RPerson_Antarctic_ice_Sheet_Fe_Source " 2653 Namelist quirks with Cray compilers (trunk only) TOP trunk Defect acc assigned 2021-04-08T14:06:33+02:00 2021-04-12T09:18:31+02:00 " ==== Context The behaviour of internal file based namelists differs in codes compiled with or without MPI using recent Cray compilers. Expected behaviour can be obtained if, and only if, every .true. or .false. stand-alone assignment is followed by a comma. These commas should not be necessary and are not necessary with intel or gfortran compilers (or even Crayftn without MPI??). This has been reported to Cray. Meanwhile, some simple scripts (see below) can be used to add commas. Details follow, including a simple program that reproduces the behaviour. ==== Analysis ===== The background The current development version of NEMO uses internal files for its namelists. This is to avoid filesystem accesses; instead rank zero reads the entire namelist, strips comments and broadcasts the entire character buffer to everyone else. This is working on a variety of systems (including ARCHER). On Archer2, I've been encountering errors which the model assumes are misspelt variables in the namelist but the input namelists are fine. It turns out I can replicate these errors with a simple namelist; but, strangely, only in an MPI environment. ===== The example program The program: errornml_mpi.F90 (listed below) defines a simple namelist (as a character string) and broadcasts this to other ranks. The program can also be compiled without mpi. Two different namelists can be used, decided by a command-line argument: g (for good) or b (for bad). The two namelists differ only by the addition of commas immediately after .true. or .false. settings. This is my work-around because it works with the commas but not without them. Commas should not be necessary (and aren't necessary for all the real, integer and character variables in the full namelist). Currently Loaded compiler: ftn -V Cray Fortran : Version 10.0.4 In non-mpi mode, I find no difference in behaviour between the two namelists: {{{ ftn -o errornml -O1 errornml_mpi.F90 ./errornml g The whole internal file: &namctl sn_cfctl%l_trcstat=.true., sn_cfctl%l_runstat=.true., / ---- namctl in namelist_cfg: &NAMCTL SN_CFCTL = T, T, F, F, F, F, F, 0, 1000000, 1, 1, LN_TIMING = F, LN_DIACFL = F, NN_ISPLT = 0, NN_JSPLT = 0, NN_ICTLS = 0, NN_ICTLE = 0, NN_JCTLS = 0, NN_JCTLE = 0 / ---- STOP ./errornml b The whole internal file: &namctl sn_cfctl%l_trcstat=.true. sn_cfctl%l_runstat=.true. / ---- namctl in namelist_cfg: &NAMCTL SN_CFCTL = T, T, F, F, F, F, F, 0, 1000000, 1, 1, LN_TIMING = F, LN_DIACFL = F, NN_ISPLT = 0, NN_JSPLT = 0, NN_ICTLS = 0, NN_ICTLE = 0, NN_JCTLS = 0, NN_JCTLE = 0 / ---- STOP }}} With MPI and srun (even with just 1 rank) the behaviour changes: {{{ ftn -o errornml_mpi -DUSE_MPI -O1 errornml_mpi.F90 srun -n 1 ./errornml_mpi g The whole internal file: &namctl sn_cfctl%l_trcstat=.true., sn_cfctl%l_runstat=.true., / ---- namctl in namelist_cfg: &NAMCTL SN_CFCTL = T, T, F, F, F, F, F, 0, 1000000, 1, 1, LN_TIMING = F, LN_DIACFL = F, NN_ISPLT = 0, NN_JSPLT = 0, NN_ICTLS = 0, NN_ICTLE = 0, NN_JCTLS = 0, NN_JCTLE = 0 / ---- STOP srun -n 1 ./errornml_mpi b The whole internal file: &namctl sn_cfctl%l_trcstat=.true. sn_cfctl%l_runstat=.true. / ---- namctl in namelist_cfg: Not found or bad Not found or bad MPICH ERROR [Rank 0] [job id 42135.24] [Sat Nov 7 13:28:42 2020] [unknown] [nid001114] - Abort(25) (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 25) - process 0 }}} and just to prove the MPI is working: {{{ srun -n 2 ./errornml_mpi g The whole internal file: &namctl sn_cfctl%l_trcstat=.true., sn_cfctl%l_runstat=.true., / ---- namctl in namelist_cfg: &NAMCTL SN_CFCTL = T, T, F, F, F, F, F, 0, 1000000, 1, 1, LN_TIMING = F, LN_DIACFL = F, NN_ISPLT = 0, NN_JSPLT = 0, NN_ICTLS = 0, NN_ICTLE = 0, NN_JCTLS = 0, NN_JCTLE = 0 / ---- STOP ---- namctl in namelist_cfg: 1 The whole internal file: &namctl sn_cfctl%l_trcstat=.true., sn_cfctl%l_runstat=.true., / ---- &NAMCTL SN_CFCTL = T, T, F, F, F, F, F, 0, 1000000, 1, 1, LN_TIMING = F, LN_DIACFL = F, NN_ISPLT = 0, NN_JSPLT = 0, NN_ICTLS = 0, NN_ICTLE = 0, NN_JCTLS = 0, NN_JCTLE = 0 / ---- STOP }}} I can't explain this so I'm assuming it is a compiler bug but it is odd that it seems impossible to replicate without the mpi environment. The work-around is to add commas (see scripts below) but it is tedious to have to maintain different namelists for different systems and Cray compilers are alone in this behaviour. The actual namelists are some 38k characters but it is only logical variables that need these commas appended. ==== Recommendation Wait for Cray to fix their compiler. Meanwhile, run the edit_nmls script in the directory above tests and cfgs on each new checkout before building any configurations with Cray compilers. reverse_edit_nmls should reverse changes before any check-ins. Permanently adding the commas is an option but it is difficult to ensure they are maintained. ==== errornml_mpi.F90 {{{#!fortran PROGRAM errornml #if defined USE_MPI USE MPI #endif CHARACTER(LEN=:), ALLOCATABLE :: cdnambuff CHARACTER(LEN=100) :: this_works='&namctl sn_cfctl%l_trcstat=.true., sn_cfctl%l_runstat=.true., /' CHARACTER(LEN=100) :: this_breaks='&namctl sn_cfctl%l_trcstat=.true. sn_cfctl%l_runstat=.true. /' CHARACTER(LEN=100) :: use_this INTEGER :: kout = 6 LOGICAL :: ldwp =.FALSE. !: .true. only for the root broadcaster INTEGER :: itot, ierr, mpprank, mppsize TYPE :: sn_ctl LOGICAL :: l_runstat = .FALSE. LOGICAL :: l_trcstat = .FALSE. LOGICAL :: l_oceout = .FALSE. LOGICAL :: l_layout = .FALSE. LOGICAL :: l_prtctl = .FALSE. LOGICAL :: l_prttrc = .FALSE. LOGICAL :: l_oasout = .FALSE. INTEGER :: procmin = 0 INTEGER :: procmax = 1000000 INTEGER :: procincr = 1 INTEGER :: ptimincr = 1 END TYPE TYPE(sn_ctl), SAVE :: sn_cfctl LOGICAL :: ln_timing LOGICAL :: ln_diacfl INTEGER :: nn_ictls INTEGER :: nn_ictle INTEGER :: nn_jctls INTEGER :: nn_jctle INTEGER :: nn_isplt INTEGER :: nn_jsplt NAMELIST/namctl/ sn_cfctl, ln_timing, ln_diacfl, & & nn_isplt, nn_jsplt, nn_ictls, nn_ictle, nn_jctls, nn_jctle character(len=32) :: arg integer :: iarg use_this=this_works do iarg = 1, command_argument_count() call get_command_argument(iarg, arg) select case (arg) case ('g', 'good') use_this = this_works case ('b', 'bad') use_this = this_breaks end select end do ! # if defined USE_MPI CALL mpi_init( ierr ) CALL mpi_comm_size( MPI_COMM_WORLD, mppsize, ierr ) CALL mpi_comm_rank( MPI_COMM_WORLD, mpprank, ierr ) if( mpprank .eq. 0 ) ldwp = .true. if(ldwp) THEN #endif ! ! Test the contents of the internal file ! ! Write it all out: ! hand-crafted substitute for the load_nml subroutine which reads whole namelists and ! condenses them into a character string itot=len_trim(use_this) IF ( .NOT. ALLOCATED(cdnambuff) ) ALLOCATE( CHARACTER(LEN=itot) :: cdnambuff ) cdnambuff=TRIM(use_this) ! write(6,'(a)') 'The whole internal file: ' write(6,'(32A)') cdnambuff write(6,'(a)')'----' # if defined USE_MPI call mpp_bcast_nml( cdnambuff , itot ) #endif write(6,'(a)') 'namctl in namelist_cfg: ' read(cdnambuff, namctl, iostat=ios, end=99, err=99) write(6,namctl) write(6,'(a)')'----' goto 101 ! 99 write(6,'(a)') 'Not found or bad ',ios goto 98 ! 101 CONTINUE # if defined USE_MPI ELSE call mpp_bcast_nml( cdnambuff , itot ) write(*,'(a)')'----' write(*,'(a,i5)') 'namctl in namelist_cfg: ',mpprank write(6,'(a)') 'The whole internal file: ' write(6,'(32A)') cdnambuff write(6,'(a)')'----' read(cdnambuff, namctl, iostat=ios, end=98, err=98) write(*,namctl) write(*,'(a)')'----' ENDIF call MPI_BARRIER(MPI_COMM_WORLD, ierr) call MPI_FINALIZE(ierr) #endif STOP 98 write(6,'(a)') 'Not found or bad ',ios # if defined USE_MPI CALL MPI_ABORT(MPI_COMM_WORLD, ios, ierr) CONTAINS SUBROUTINE mpp_bcast_nml( cdnambuff , kleng ) CHARACTER(LEN=:) , ALLOCATABLE, INTENT(INOUT) :: cdnambuff INTEGER , INTENT(INOUT) :: kleng !!---------------------------------------------------------------------- !! *** routine mpp_bcast_nml *** !! !! ** Purpose : broadcast namelist character buffer !! !!---------------------------------------------------------------------- !! INTEGER :: iflag !!---------------------------------------------------------------------- ! call MPI_BCAST(kleng, 1, MPI_INT, 0, MPI_COMM_WORLD, iflag) call MPI_BARRIER(MPI_COMM_WORLD, iflag) IF ( .NOT. ALLOCATED(cdnambuff) ) ALLOCATE( CHARACTER(LEN=kleng) :: cdnambuff ) call MPI_BCAST(cdnambuff, kleng, MPI_CHARACTER, 0, MPI_COMM_WORLD, iflag) call MPI_BARRIER(MPI_COMM_WORLD, iflag) ! END SUBROUTINE mpp_bcast_nml #endif END PROGRAM errornml }}} edit_nmls (better suggestions are welcome): {{{ #!/bin/bash for d in cfgs tests do cd $d for nml in `find ./ -name '*namelist_*'` do chk=$(grep -c -i -e""= *.false.,"" -e""= *.true.,"" $nml) if test $chk -eq 0 ; then echo ""Changing : ""$nml ed - $nml << EOF %s/=\( *\).false./=\1.false.,/ w q EOF ed - $nml << EOF %s/=\( *\).FALSE./=\1.FALSE.,/ w q EOF ed - $nml << EOF %s/=\( *\).true./=\1.true.,/ w q EOF ed - $nml << EOF %s/=\( *\).TRUE./=\1.TRUE.,/ w q EOF else echo $nml "" may have already been processed: ""$chk"" lines already correct"" fi done cd ../ done }}} reverse_edit_nmls: {{{ cat reverse_edit_nmls #!/bin/bash for d in cfgs tests do cd $d for nml in `find ./ -name '*namelist_*'` do chk=$(grep -c -i -e""= *.false.,"" -e""= *.true.,"" $nml) if test $chk -ne 0 ; then echo ""Changing : ""$nml ed - $nml << EOF %s/=\( *\).false.,/=\1.false./ w q EOF ed - $nml << EOF %s/=\( *\).FALSE.,/=\1.FALSE./ w q EOF ed - $nml << EOF %s/=\( *\).true.,/=\1.true./ w q EOF ed - $nml << EOF %s/=\( *\).TRUE.,/=\1.TRUE./ w q EOF else echo $nml "" may have already been processed: ""$chk"" lines already reverted"" fi done cd ../ done }}} " 2604 MOI-02_MOI-GLS-ICE TOP trunk Unscheduled Task cbricaud assigned 2021-01-25T11:31:38+01:00 2022-01-14T12:04:58+01:00 " - branch to improve scaling of mixing under sea-ice ( do as it is in TKE) - add limit condition under ice shelves ==== Workplan action Wikipage: wiki:2021WP/MOI-02_MOI-GLS-ICE " 2491 output time step in istate TOP trunk Unscheduled Defect rblod assigned 2020-06-22T13:56:44+02:00 2020-06-22T16:31:22+02:00 "==== Context When outputting the initial state (nn_istate=1), the velocities doesn't correspond to the initial state (easy to see when starting from rest, velocities in output.ini.nc are not zero) ==== Analysis diawri_state is called inside dia_wri so writes the now time step (Nnn). Velocities at time step now are corrected in dynspg_ts so doesn't correspond to the initial state anymore ==== Recommendation Inside dia_wri, call diawri_state with before time step as argument : mod(kmm+1,3)+1 should do it If assigned to me, I can do it ... " 2269 OBSTOOLS/sla2fb: old altimetry format TOP v4.0.* Defect cbricaud assigned 2019-04-05T15:14:53+02:00 2020-03-28T13:09:04+01:00 " ==== Context OBSTOOLS/sla2fb is used to convert aviso sla netfiles to feedback format, read by the Observation operator in NEMO obssla_io.h90 read the aviso files, but it needs to read aviso sla files with ""old format"" ( Tracks, Cycles, Data dimensions) ==== Analysis Someone should have the good routine ==== Recommendation ... " 2187 SI3-04_lagrangian_drifters TOP trunk Unscheduled Task vancop assigned 2018-12-20T08:52:21+01:00 2021-04-14T13:04:08+02:00 "''Implement lagrangian drifters in sea ice for immerse'' ==== Summary ||=Action || ''${ACTION_NAME} Subject'' || ||=PI(S) || ''M. Vancoppenolle'' || ||=Digest || ''Brief description with motivations and main tasks'' || ||=Dependencies || || ||=Branch || ''[source:/NEMO/branches/$YEAR/dev_r{REV}_{ACTION_NAME}]'' || ||=Previewer(s) || || ||=Reviewer(s) || || ||=Wiki || ''wiki:`${YEAR}WP/...`'' || ==== Abstract Introduce lagrangian drifters in sea ice for IMMERSE sea ice evaluation. ===== Description Lagrangian drifters should be introduced to be able to compare with lagrangian sea ice deformation. There are two options. Either follow icebergs. Or use the corresponding ocean package. ===== Implementation ''Describe flow chart of the changes in the code. \\ List the .F90 files and modules to be changed. \\ Detailed list of new variables (including namelists) to be defined, give for each the chosen name (following coding rules) and definition.'' ===== Reference manual and web pages updates ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks." 2150 TOP-06_emalod_OASIS_interface_between_TOP_and_NEMO TOP trunk Unscheduled Task emalod assigned 2018-10-30T09:03:43+01:00 2021-04-14T13:05:07+02:00 "OASIS coupling interface between TOP and NEMO == Context IMMERSE project: Increase modularity of NEMO components - macro-task parallelism == Proposal We propose to shape the existing ocean/sea-ice interface to an ocean/biogeochemistry coupling, to make possible the computing of TOP/Pisces equations (Aumont et al. 2015) in a separate executable and its coupling to the rest of the NEMO model. This modularity is supposed to enhance the overall computing performances by allowing (i) to reduce the TOP/Pisces module horizontal resolution and (ii) to choose the best suited parallel decomposition for both components. Regardless to result modifications that have to be evaluated, computation of the two modules can be performed concurrently, reducing time to solution even more. The OASIS coupling library (Craig at al., 2017), basis of the existing ocean/sea-ice interface, will ensure the efficient (parallel) communication of 3D fields, the easy switch between sequential and concurrent modes and, possibly, the coupling field interpolation. " 2057 ROBUST-03_cethe_TOP_doc TOP trunk Documentation Task clevy assigned 2018-02-26T18:57:49+01:00 2022-02-04T18:12:12+01:00 "== Context ... == Implementation plan ... " 1933 passive tracers trends TOP v4.0.* Bug jpalmier assigned 2017-08-23T18:43:24+02:00 2020-03-28T13:11:49+01:00 "= Context \\ Working with the UKMO version of NEMO, i got some difficulties to get the trends working proprely. * one reason for this is that new trends have been added by UKMO people that are not expected by the final/""outputing"" part of trdtrc. the way this final part is written, if an non expected trend arrives here to be written out by XIOS, breaks the model: {{{ #!f IF( lk_trdtrc .AND. ln_trdtrc( kjn ) ) THEN ! SELECT CASE( ktrd ) CASE( jptra_xad ) ; WRITE (cltra,'(""XAD_"",4a)') CASE( jptra_yad ) ; WRITE (cltra,'(""YAD_"",4a)') CASE( jptra_zad ) ; WRITE (cltra,'(""ZAD_"",4a)') CASE( jptra_ldf ) ; WRITE (cltra,'(""LDF_"",4a)') CASE( jptra_bbl ) ; WRITE (cltra,'(""BBL_"",4a)') CASE( jptra_nsr ) ; WRITE (cltra,'(""FOR_"",4a)') CASE( jptra_zdf ) ; WRITE (cltra,'(""ZDF_"",4a)') CASE( jptra_dmp ) ; WRITE (cltra,'(""DMP_"",4a)') CASE( jptra_sms ) ; WRITE (cltra,'(""SMS_"",4a)') CASE( jptra_atf ) ; WRITE (cltra,'(""ATF_"",4a)') CASE( jptra_radb ) ; WRITE (cltra,'(""RDB_"",4a)') CASE( jptra_radn ) ; WRITE (cltra,'(""RDN_"",4a)') END SELECT cltra = TRIM(cltra)//TRIM(ctrcnm(kjn)) CALL iom_put( cltra, ptrtrd(:,:,:) ) ! END IF }}} For example, the JPTRA_TOTAD case has been added by the UKMO team. with a call to trd_trc(..., jptra_totad,...) \\ This call will arrive in the foreseen piece of code, cltra will not be defined, and the iom_put call will fail without variable name to look after. * A second problem is that these trends still do not take into account the vvl correction from ticket [ticket:1877]. * Some trends we might need for CMIP6 are missing from the list above. * the namtrc_trd namelist is looking for ln_trdmxl_trc_restart and ln_trdmxl_trc_instant when namelist_top_ref has ln_trdmld_trc_restart, ln_trdmld_trc_instant instead. * the place where namtrc_trd is read in namtrc starts to be problematic as namtrc_dia includes mainly the namelists read if XIOS is not available. * Finally the trends are not defined in the field_def.xml file. \\ = Analysis \\ * The output problem, once seen is easy to fix, it needs to move the `cltra = TRIM(cltra)//TRIM(ctrcnm(kjn)); CALL iom_put( cltra, ptrtrd(:,:,:) )` sentences inside each CASE. * I went to talk to George for the vvl problem. the solution is to copy what have been done for the dynamic. * I am not sure about the full list of trends we want for the passive tracers, but at least we want the JPTRA_SMS and the total trend. Is there a definitive list of the passive tracer trends required for CMIP6 ? in the while i have added all the dynamical trends that were missing in the passive tracers, and have added a iom_use call before iom_put. * namtrc_dia should be protected under a `IF( .NOT. lk_iomput )` test, and move the namtrc_trd namelist reading in the main routine (might be better to move it in a specific trd routine as for the ice with trc_nam_ice) * the field_def file needs to be completed. \\ = Fix \\ A NEMO_3.6 branch has been created: [https://forge.ipsl.jussieu.fr/nemo/browser/branches/2017/nemo_v3_6_STABLE_trdtrc nemo_v3_6_STABLE_trdtrc] first changes can be seen [https://forge.ipsl.jussieu.fr/nemo/changeset?reponame=&new=8472%40branches%2F2017%2Fnemo_v3_6_STABLE_trdtrc&old=8421%40branches%2F2015%2Fnemo_v3_6_STABLE here] === Still missing: === -------------------- * Some of the trends are still not working on my MEDUSA testing branch. Once corrected, i'll import the changes. * i am looking for adding the trends vertical inventory through XIOS. It is feasible, i kind of see how, but would be better with an example It would avoid writing tons of 3D fields when we really want 2D. * Need to be tested from outside MetOffice branch version. I removed everything from MEDUSA in this branch, but i cannot test it yet. have to check with Andrew how to test this. " 1984 Error in the online momentum trend diagnostic TRD Unscheduled Bug Robin_Waldman assigned 2017-11-28T10:21:26+01:00 2020-12-11T17:31:33+01:00 "== Context I am using the online 3D momentum trend diagnostic (ln_dyn_trd = .true.) to compute offline vorticity budgets. The model version is NEMO v3.6, downloaded a few months ago from NEMO website. I am working on a Mediterranean configuration (NEMOMED12). == Analysis I have first checked on 1 month of simulation that the total trend stored (utrd_tot and vtrd_tot) corresponded to the sum of individual trend terms (which is the case) and was equal to the actual trend deduced from restart files (un, vn in the restart of the end minus beginning of month). This latter point is not verified. The error is typically low (a few percents) but it can reach very high [[Image(Ztrend_tot_test_LION.png)]]values at localized points on the map, especially at intermediate depths (~70-300m). The error is even larger when computing the curl of the momentum trend in order to retreive the vertical relative vorticity trend. == Fix Changeset r8102 (by Dave Storkey) has recently debugued the online tracer trend diagnostic, in particular by separating between trend contributions in even and odd timesteps. I am thinking that maybe the error on the momentum trend diagnostic also comes from that. " 1723 diags KE with time_splitting TRD trunk Bug julienjouanno assigned 2016-05-02T12:33:26+02:00 2019-12-04T16:47:55+01:00 "The computation of the momentum or KE trends (key_trddyn or key_trdken) does not return a closed balance in the current stable version (rev 6478) when using time_splitted free surface and implicit diffusion. Please find a few suggestions to close the balance in the specific case with ""ln_bt_fw=False"" and ""explicit bottom friction"": * Calculation of zdf trend should be moved in dynzdf_imp.F90 (instead of dynzdf.F90) after iteration ""ua = ub + 2dt * ua"". [In rev6478, the trend calculated in dynzdf.F90 when using implicit ZDF returns the difference between a velocity and a trend] * In dynspg_ts, instead of sending the total barotropic trend (ua_b-ub_b) / 2dt in ua, the surface and bottom stress contributions are subtracted. We also impose a constant bottom stress during the barotropic integration, which is calculated with a drag coefficient limited by the constraint on the CFL as in the 3d mode. By doing so, the bottom and wind stress experienced by the barotropic and baroclinic mode are strictly the same and enter only once in the 3d mode (in dynbfr and dynzdf_imp). It also results that the barotropic correction performed at the beginning of dynxt.F90 becomes null (facilitating the interpretation of the balance) Julien (with J.C. help) PS : I attached a tar file with the routines that have been modified
" 1584 utrd_zdf and vtrd_zdf are velocities minus momentum trends TRD Bug chrenkl assigned 2015-07-28T15:19:19+02:00 2019-12-04T16:49:57+01:00 "In the subroutine for vertical diffusion using a implicit time-stepping (dyn_zdf_imp in dynzdf_imp.F90), the momentum trends ua and va are integrated in time and become the after velocities (lines 122-136). Thus, in lines 90-95 of dynzdf.F90, when the momentum trend diagnostics are supposed to be computed, momentum trends (ztrdu, ztrdv) are subtracted from velocities (ua, va). Therefore, {{{#!f 90 IF( l_trddyn ) THEN ! save the vertical diffusive trends for further diagnostics 91 ztrdu(:,:,:) = ua(:,:,:) - ztrdu(:,:,:) 92 ztrdv(:,:,:) = va(:,:,:) - ztrdv(:,:,:) 93 CALL trd_dyn( ztrdu, ztrdv, jpdyn_zdf, kt ) 94 CALL wrk_dealloc( jpi, jpj, jpk, ztrdu, ztrdv ) 95 ENDIF }}} should be changed to {{{#!f 90 IF( l_trddyn ) THEN ! save the vertical diffusive trends for further diagnostics 91 ztrdu(:,:,:) = ( ua(:,:,:) - ub(:,:,:) ) / r2dt - ztrdu(:,:,:) 92 ztrdv(:,:,:) = ( va(:,:,:) - vb(:,:,:) ) / r2dt - ztrdu(:,:,:) 93 CALL trd_dyn( ztrdu, ztrdv, jpdyn_zdf, kt ) 94 CALL wrk_dealloc( jpi, jpj, jpk, ztrdu, ztrdv ) 95 ENDIF }}} as it is done in dynspg.F90. I have not checked whether this is also the case for vertical diffusion with explicit time-stepping. " 2748 Physical significance of TKE penetration not scaled by the model time step ? ZDF trunk Request jchanut assigned 2021-11-22T18:28:46+01:00 2022-01-07T15:21:14+01:00 "==== Context On TKE additional source term (e.g. nn_etau>0 in namzdf_tke) ==== Analysis The additional TKE source term in zdftke is not scaled by the model time step: {{{ IF( nn_etau == 1 ) THEN !* penetration below the mixed layer (rn_efr fraction) DO_3D_OVR( nn_hls-1, nn_hls-1, nn_hls-1, nn_hls-1, 2, jpkm1 ) en(ji,jj,jk) = en(ji,jj,jk) + rn_efr * en(ji,jj,1) * EXP( -gdepw(ji,jj,jk,Kmm) / htau(ji,jj) ) & & * MAX( 0._wp, 1._wp - zice_fra(ji,jj) ) * wmask(ji,jj,jk) * tmask(ji,jj,1) }}} As expected, this leads to a dependency of the tke profiles, hence of viscosities/diffusivities on the chosen time step. This may well be on purpose, but I have trouble to see the physical motivation behind that. I would rather have seen a kind of time scale associated with that process (in place of the surface tke fraction) and then multiplied by the time step. ==== Recommendation At this point, I would like to be convinced :) " 2745 zdfric not compatible with p_sh2 calculation ZDF trunk Bug amoulin assigned 2021-11-18T20:13:00+01:00 2022-01-07T15:21:14+01:00 "{{{#!comment BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below. If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it. Remove these lines after reading. }}} ==== Context ... ==== Analysis Richardson number vertical mixing is not compatible with the shear production term (p_sh2) calculated in zdfsh2 (using the before and after velocities) (Simulation in the MEDSEA gave really high RMSE in the temperature and salinity fields) ==== Fix We propose to reintroduce the calculation of the shear production term as it was in the past version (using only before velocities) zdku = 0.5 / e3uw(ji,jj,jk,Kbb) * ( uu(ji-1,jj,jk-1,Kbb) + uu(ji,jj,jk-1,Kbb) & & - uu(ji-1,jj,jk,Kbb) - uu(ji,jj,jk,Kbb) )* wumask(ji,jj,jk) zdkv = 0.5 / e3vw(ji,jj,jk,Kbb) * ( vv(ji,jj-1,jk-1,Kbb) + vv(ji,jj,jk-1,Kbb) & & - vv(ji,jj-1,jk,Kbb) - vv(ji,jj,jk,Kbb) )* wvmask(ji,jj,jk) zwx = zdku*zdku + zdkv*zdkv zcfRi = 1._wp / ( 1._wp + rn_alp * MAX( 0._wp , rn2(ji,jj,jk) / ( zwx + 1.e-20 ) ) ) " 2661 missing diags for turbulence ZDF trunk Task clem assigned 2021-04-30T11:56:33+02:00 2022-01-07T15:21:14+01:00 "I propose to add a couple of diags for turbulence. They can be outputed for any of the turbulent schemes available in the code except for the Kolmogorov energy of dissipation which I solely coded for tke (don't know how to do for the other schemes). Here they are: In field_def_oce.xml: {{{#!xml }}} In zdfphy.F90: {{{#!fortran IF( iom_use('avt_k') .OR. iom_use('avm_k') .OR. iom_use('eshear_k') .OR. iom_use('estrat_k') ) THEN IF( l_zdfsh2 ) THEN zsh2(:,:,1 ) = 0._wp zsh2(:,:,jpk) = 0._wp CALL lbc_lnk( 'zdfphy', zsh2, 'W', 1. ) CALL iom_put( 'avt_k' , avt_k * wmask ) CALL iom_put( 'avm_k' , avm_k * wmask ) CALL iom_put( 'eshear_k', zsh2 * wmask ) CALL iom_put( 'estrat_k', - avt_k * rn2 * wmask ) ENDIF ENDIF }}} In zdftke.F90: {{{#!fortran ! Kolmogorov energy of dissipation (W/kg) ! ediss = Ce*sqrt(en)/L*en ! dissl = sqrt(en)/L IF( iom_use('ediss_k') ) THEN ztmp(:,:,:) = zfact3 * dissl * en * wmask CALL lbc_lnk( 'zdftke', ztmp, 'W', 1. ) CALL iom_put( 'ediss_k', ztmp ) ENDIF }}} " 1180 Bottom grid points with unrealistically cold temperature in ORCA2_LIM OCE Unscheduled Bug fabien.roquet reopened 2013-11-15T17:02:41+01:00 2020-12-11T17:30:00+01:00 "I just realized that ORCA2 features a few bottom grid points with unrealistically cold properties (<-2degC). I checked outputs from nemo trunk (v3_5) revision 3856 (in http://dodsp.idris.fr/rfry154/reference_trunk_v35_Output/) to verify that the problem is not due to my own setup, and I indeed found bottom grid point colder than -2degC in several year-mean output files: - ORL2PISV35_00000101_00001231_1Y_grid_T.nc : no problem - ORL2PISV35_01000101_01001231_1Y_grid_T.nc : no problem - ORL2PISV35_02000101_02001231_1Y_grid_T.nc : -2.03845 - ORL2PISV35_03000101_03001231_1Y_grid_T.nc : -2.57319 - ORL2PISV35_04000101_04001231_1Y_grid_T.nc : -2.7857 - ORL2PISV35_05000101_05001231_1Y_grid_T.nc : -2.88635 From my limited analysis, it seems that this situation always happens only in partial cell grid points, and can happen at around any depth. There is a clear tendency of cold drift through time, + spatial spreading of the phenomenon. I have checked quickly on ORCA1, and didn't find any such anomalous cold grid points, but that doesn't mean that the problem does not exist for other configurations than ORCA2. I did a run without bbl (namelist nn_bbl_ldf and nn_bbl_adv set to 0), and the problem still persists so it seems bbl is not the source of this problem. Does anyone know what is going on?" 2195 HPC-08_XXX_fldread_with_XIOS SBC trunk Unscheduled Task smasson reopened 2018-12-20T16:23:31+01:00 2021-04-14T12:59:37+02:00 "==== Summary ||=Action || ''Fldread with XIOS'' || ||=PI(S) || ''to be decided...'' || ||=Digest || ''use XIOS in fldread'' || ||=Dependencies || || ||=Branch || ''[source:/NEMO/branches/2019/dev_r11351_fldread_with_XIOS]'' || ||=Previewer(s) || || ||=Reviewer(s) || || ||=Wiki || ''wiki:2019WP/HPC-08_XXX_fldread_with_XIOS'' || ==== Abstract Use XIOS in fldread to read input files.[[BR]] I suspect, for example, that when a few thousand cores are trying to access the same file every few time steps (at least for ORCA1) it is not very good for the performances... ===== Description Open question on the usage of the interpolation schemes included in XIOS. Should it replace the on the fly interpolation?[[BR]] Open question on the possibility to read the file without XIOS? Should we keep it or not? ===== Implementation ''Describe flow chart of the changes in the code. \\ List the .F90 files and modules to be changed. \\ Detailed list of new variables (including namelists) to be defined, give for each the chosen name (following coding rules) and definition.'' ===== Reference manual and web pages updates ''Using part 1 and 2, define the summary of changes to be done in reference manuals (tex files), guide (rst files) and in the content of web pages.'' Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks." 2156 ASINTER-05_Masson_CurrentFeedback SBC trunk Unscheduled Task smasson reopened 2018-11-06T18:06:21+01:00 2021-04-14T13:04:08+02:00 "==== Context Create a simple parameterization of the current feedback, following the paper of Renault et al. 2019 ==== Proposal ... "