Last edited Timestamp?

Author : Christian Ethé

ticket : #972

Branch : dev_r3436_LOCEAN15_PISLOB

---

Description

Motivations

• System simplification : Merge of PISCES & LOBSTER biogeochemical models.
• System development : Improvment of PISCES model

Strategy

(1) Merge of PISCES & LOBSTER

• Include the 2 SMS models within the same framework PISCES
• Creation of 2 sub-directory : PISCES/P4Z for PISCES ( 4 nutrients + iron ) and PISCES/P2Z for LOBSTER ( 2 nutrients )
• merge the interfaces for initialisation, output, restart, namelist read etc..., i.e :
  • suppression of directory LOBSTER and modules par_lobster.F90 sms_lobster.F90 trcini_lobster.F90 trcnam_lobster.F90 trcrst_lobster.F90 trcsms_lobster.F90
  • rename module trcbio.F90 to p2zbio.F90, trcexp.F90 to p2zexp.F90,... and the main routine is now called p2zsms.F90
• rename key_lobster to key_pisces_reduced

(2) Improvment of PISCES ( Done by Olivier Aumont )

• debbuging/tuning procedure

Kriest code was not so buggy and so the debugging was pretty short. The problem was more that the results I got with this version were more or less crap ... So I did some tuning, which is by no means over. During this debuging/tuning procedure, I found some problems in the standard code which explains why there are not only changes concerning Kriest but also some other changes. I should say that these changes include also some bugs/inappropriate codings I changed some months ago.

Here is a list of all the routines that have been modified. No major parameterizations have been changed. It's only debugging/slight changes :

• denitrification in the sediments
• iron from seaice
• Al's iron model following their paper his paper with Christof (Al can you send me your code if possible ?)
• The new river package

List of the changes/bugfixes (alphabetical order) :

• p4zbio.F90 : correction made on the update of trn to avoid marginal negative concentrations which happened with the previous coding.
• p4zlim.F90 : slight change on the minimum iron concentration small changes on the half-saturation constants for N limitation (x3 instead of x2). Bug correction on xlimbac. zlim1 should be limitation by N and not only by NH4 (bacteria can use both nh4 and NO3).
• p4zmicro : the multiplication by 2 in zrespz has been removed. Changes in the threshold computation for grazing. Grazing is now possible even for very small values of food which avoids loosing microzooplankton when food is very scarce.
• p4zmeso (ok I know, it is before p4zmicro but it was easier for the comments ) : same change as in p4zmicro for the threshold.
• p4zprod.F90 : various bug corrections (nothing serious).
• p4zrem.F90 : zbactfer has been completely rewritten
• p4zsed.F90 : P deposition has been added and is computed from dust.

7.6 has been changed to 7.625 ( rno3 parameter ) The computation of the total supply by the different sources has been corrected to compute the real average. So the sums should be divided by the number of timesteps of the input file. There was no problem for the standard version but when the number of timesteps are changed in the input files (for instance monthly fields for rivers), then the budget is wrong !

• p4zsink.F90 : bug corrections for Kriest, I have added a new xkr_nmicro for the number of elementary particles in micro end products for the kriest parameterization. This means that the namelist has changed. doc aggregation for Kriest has been changed Computation of the standard sinking speed has been changed. For this point, in fact, the correct parameterization is commented out in the standard code. I changed that to uncomment the appropriate lines.

trcnam_pisces, trcsms_pisces, ... : 7.6 -> 7.625 and perhaps some corrections. Furthermore, trcnam_pisces.F90 includes a new parameter that should be read in the namelist which is the N content of the aggregate.

I think everything is in the list. It compiles and runs smoothly. Kriest is almost tuned (i'll send the namelist when I consider this step is over which will include the changes in the namelist made for kriest).

• improvment/ new parametrization

• New Al's iron model following his paper with Christof. New module p4zfechem.F90, enabled with a namelist parameter ln_fechem
• Introduction of a PAR variable at the ocean surface, activated by a namelist parameter ln_varpar
• Introduction of a potential time-spitting for vertical sedimentation
• Solubility of dust deposition of iron, activated by a namelist parameter ln_solub
• Revisit of the half-saturation constants ( the variation )

1) refonte des apports de rivières comme décrit pendant la réunion mercator vert.

6) Ajoût d'une variable dust qui représente la concentration de dust dans l'océan. Ca sert pour le scavenging du fer. 7) retouche de quelques paramètres du modèle 8) refonte de la variation des constantes de demi-saturation avec refonte de la namelist correspondante.

---

Testing

Testing could consider (where appropriate) other configurations in addition to NVTK].

NVTK Tested	'''YES/NO'''
Other model configurations	'''YES/NO'''
Processor configurations tested	[ Enter processor configs tested here ]
If adding new functionality please confirm that the New code doesn't change results when it is switched off and ''works'' when switched on	'''YES/NO/NA'''

(Answering UNSURE is likely to generate further questions from reviewers.)

'Please add further summary details here'

• Processor configurations tested
• etc----

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ?	'''YES/NO '''
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)	'''YES/NO'''
Is this change expected to preserve answers in all possible model configurations?	'''YES/NO'''
Is this change expected to preserve all diagnostics? ,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. ''	'''YES/NO'''

If you answered '''NO''' to any of the above, please provide further details:

• Which routine(s) are causing the difference?
• Why the changes are not protected by a logical switch or new section-version
• 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.
• What do you expect to see occur in the test harness jobs?
• Which diagnostics have you altered and why have they changed?Please add details here........

---

System Changes

Does your change alter namelists?	'''YES/NO '''
Does your change require a change in compiler options?	'''YES/NO '''

If any of these apply, please document the changes required here.......

---

Resources

''Please ''summarize'' any changes in runtime or memory use caused by this change......''

---

IPR issues

Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO?

'''YES/ NO '''

If No:

• Identify the collaboration agreement details
• Ensure the code routine header is in accordance with the agreement, (Copyright/Redistribution? etc).Add further details here if required..........