Comments (9)
I also think it's best to go with option (b). Scientifically, it'd be more logical when comparing different simulations or when merging code versions.
from blom.
With the new coordinates the upper 2 layers of the model are quite thin, i.e. the volume for N-fixation is small und thus PP will be reduced somewhat. So in this regard, the change belongs to the new vertical coordinates.
from blom.
If PR #154 is accepted, the N-fixation should take place over the entire mixed layer depth (defined by the kOBL index). This will hopefully solve the issue with the 2 top layers being very thin, at least for the first implementation. It has the advantage that the code change should be "minimal", in the sense that the vertical coordinate change will not coincide with another conceptual code change.
from blom.
I thought the idea is to limit N2 fixation to the euphotic zone, and not the whole MLD. According to this, N2-fixation requires lights: https://www.sciencedirect.com/science/article/pii/S1385110104000930, though probably during deep MLD, temperature limitation come into effect.
from blom.
I agree that we should have N2 fixation in the euphotic zone, but in the first instance I would like to have a version that is mostly backwards compatible with CMIP6 simulations, so that we can evaluate "pure" coordinate changes. Perhaps this will only be a short-lived intermediate step, but I think it is safer to do it one step at a time.
from blom.
Maybe it's worth thinking about another 2D field similar to kmle
in #154 to indicate the depth of the euphotic zone? - so making it possible to differentiate between MLD and euphotic zone depth - then one has the possibility to switch between the two cases during run time for the cyanobacteria by initializing the field either via i) the current MLD or ii) a constant value (or iii) potentially even a value based on light intensity).
from blom.
The depth of the euphotic zone is currently set to a fixed value dp_ez = 100.0
, but the k-index kwrbioz
corresponding to this depth is already a 2D field. It should be fairly straight forward to extend the set_vgrid
routine to change the calculation for kwrbioz
. I suppose it could have a significant effect in ocprod
if we decide to change the definition of this field.
from blom.
Hi Tomas, I wouldn't touch ocprod
here (since, as you pointed out, setting kwrbioz
differently would change a lot in ocprod
) and was more thinking about an analogue of kwrbioz
for the cyanobacteria only (e.g. kwrcyaz
or similar) - which you then can use as described earlier.
from blom.
As a starting point, we could just use kwrbioz
as it is, also for the nitrogen fixation? If the process needs enough light(?), then this would be more justifiable than using mld. But since this would break backwards-compatibility we should probably introduce this at a well defined point...
from blom.
Related Issues (20)
- iHAMOCC structure for reading climatology input data from files HOT 2
- Add pause-resume function HOT 3
- Change last remaining fixed form .F files to free form .F90 files in iHAMOCC HOT 3
- Differences between current master and reference norESM2.0.5 run HOT 3
- Recode mapping between pore water and ocean tracers HOT 23
- iHAMOCC: Bugfix for sediment alkalinity needed? HOT 10
- Fix required for spatially variable porosity for case `sedbypass=true` HOT 4
- Correct unit of diagnostic variable "dp_trc"
- Make budget calculations selectable by namelist option
- Fix pnetcdf issues in recent iHAMOCC updates HOT 5
- Potential bug in `sedshi.F90` HOT 5
- Units of dust/clay in iHAMOCC output HOT 2
- iHAMOCC: convert to SI units (CGS -> MKS) HOT 3
- Fix `'` in ncout_hamocc.F90 needed
- Units in iHAMOCC restart file HOT 3
- MESON - Single column model setup/simulation for debugging purposes HOT 3
- BLOM density calculation CGS versus MKS at initialization
- simplified output choices for BLOM HOT 2
- BLOM is not compiling in DEBUG mode HOT 4
- default PE layout for compset NOINYOC at T62_tn14 hangs on betzy HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blom.