| 1 | [[PageOutline]] |
| 2 | Last edited [[Timestamp]] |
| 3 | |
| 4 | [[BR]] |
| 5 | |
| 6 | '''Author''' : Rachid BEnshila |
| 7 | |
| 8 | '''ticket''' : #1380 |
| 9 | |
| 10 | '''Branch''' : [https://forge.ipsl.jussieu.fr/nemo/browser/branches/2014/dev_r4765_CNRS_agrif ] |
| 11 | ---- |
| 12 | |
| 13 | === Description === |
| 14 | |
| 15 | Update AGRIF to new version, this should allow :[[BR]] |
| 16 | - to run multiple grid in parallel[[BR]][[BR]] |
| 17 | - call the subgrids recursively [[BR]] |
| 18 | - to use procname in interpolation routines (NST_SRC), in the same way than update[[BR]] |
| 19 | - potentially introduce higher order interpolations[[BR]] |
| 20 | The core routines and conv EXTERNAL/AGRIF are changed but this implies several changes in NST_SRC. [[BR]] |
| 21 | [[BR]] |
| 22 | Step 1: update the dynamics only[[BR]] |
| 23 | Changes in OPA_SRC :[[BR]] |
| 24 | - OPA_SRC/DOM/domhgr.F90 : lines too long for the conv[[BR]] |
| 25 | - OPA_SRC/TRD/trdtra.F90 : lines too long for the conv[[BR]] |
| 26 | - OPA_SRC/TRD/trdtra.F90 : lines too long for the conv[[BR]] |
| 27 | - OPA_SRC/LBC/lib_mpp.F90 : call to mpi repartitio function[[BR]] |
| 28 | - OPA_SRC/TRA/tranxt.F90 : move the call to agrif interpolation (not sure why)[[BR]] |
| 29 | - OPA_SRC/nemogcm.F90: some declarations for the conv and change call to step, sub grids are no called from step[[BR]] |
| 30 | - OPA_SRC/step.F90 : recursive call[[BR]] |
| 31 | - OPA_SRC/zdftke.F90 : copy values at the boundaries[[BR]] |
| 32 | |
| 33 | [[BR]] |
| 34 | Changes in NST_SRC :[[BR]] |
| 35 | - a lot, main change is the use of procname in agrif_opa_interp[[BR]] |
| 36 | - add key DECAL_FEEDBACK in agrif_opa_update (not activated by default)[[BR]] |
| 37 | [[BR]] |
| 38 | Config:[[BR]] |
| 39 | as always a lot of stuff are missing in 1_namelist and iodef ... |
| 40 | [[BR]] |
| 41 | Tested in ORCA2_LIM with key_dynspg_flt and key_dynspg_ts. Not a very relevant test, but at this stage it looks ok. |
| 42 | |
| 43 | |
| 44 | ---- |
| 45 | === Testing === |
| 46 | Testing could consider (where appropriate) other configurations in addition to NVTK]. |
| 47 | |
| 48 | ||NVTK Tested||!'''YES/NO!'''|| |
| 49 | ||Other model configurations||!'''YES/NO!'''|| |
| 50 | ||Processor configurations tested||[ Enter processor configs tested here ]|| |
| 51 | ||If adding new functionality please confirm that the [[BR]]New code doesn't change results when it is switched off [[BR]]and !''works!'' when switched on||!'''YES/NO/NA!'''|| |
| 52 | |
| 53 | (Answering UNSURE is likely to generate further questions from reviewers.) |
| 54 | |
| 55 | 'Please add further summary details here' |
| 56 | |
| 57 | * Processor configurations tested |
| 58 | * etc---- |
| 59 | |
| 60 | === Bit Comparability === |
| 61 | ||Does this change preserve answers in your tested standard configurations (to the last bit) ?||!'''YES/NO !'''|| |
| 62 | ||Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)||!'''YES/NO!'''|| |
| 63 | ||Is this change expected to preserve answers in all possible model configurations?||!'''YES/NO!'''|| |
| 64 | ||Is this change expected to preserve all diagnostics? [[BR]]!,,!''Preserving answers in model runs does not necessarily imply preserved diagnostics. !''||!'''YES/NO!'''|| |
| 65 | |
| 66 | If you answered !'''NO!''' to any of the above, please provide further details: |
| 67 | |
| 68 | * Which routine(s) are causing the difference? |
| 69 | * Why the changes are not protected by a logical switch or new section-version |
| 70 | * What is needed to achieve regression with the previous model release (e.g. a regression branch, hand-edits etc). If this is not possible, explain why not. |
| 71 | * What do you expect to see occur in the test harness jobs? |
| 72 | * Which diagnostics have you altered and why have they changed?Please add details here........ |
| 73 | |
| 74 | ---- |
| 75 | === System Changes === |
| 76 | ||Does your change alter namelists?||!'''YES/NO !'''|| |
| 77 | ||Does your change require a change in compiler options?||!'''YES/NO !'''|| |
| 78 | |
| 79 | If any of these apply, please document the changes required here....... |
| 80 | |
| 81 | ---- |
| 82 | === Resources === |
| 83 | !''Please !''summarize!'' any changes in runtime or memory use caused by this change......!'' |
| 84 | |
| 85 | ---- |
| 86 | === IPR issues === |
| 87 | ||Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO?||!'''YES/ NO !'''|| |
| 88 | |
| 89 | If No: |
| 90 | |
| 91 | * Identify the collaboration agreement details |
| 92 | * Ensure the code routine header is in accordance with the agreement, (Copyright/Redistribution etc).Add further details here if required.......... |