Message Boards

Back

Erroneous spikes in BLOOM-related parameters in morning and evening

Rudy Schueder, modified 3 Years ago.

Erroneous spikes in BLOOM-related parameters in morning and evening

Padawan Posts: 52 Join Date: 10/8/13 Recent Posts
Hello!

I am encountering an odd phenomenon in BLOOM. It seems near the end and at the beginning of the modeled day, I observe erroneous spikes in BLOOM-related parameters. I have attached DO, alkalinity, PO4 and ammonium plots for example. Spikes occur simultaneously for all substances at the following times: 18:55, 07:30, 18:25, 06:20. If I run the simulation longer the spikes occur at similar but not identical times on the days that follow (19:40, 07:05, 18:45, 08:00, 17:30....) I have been using bloom for about 4 months now and only in the past 2 weeks have I seen this problem...

there is no spike in the parameter GREENS, but there is a spike in GREENS_P and GREENS_E at the aforementioned times. The spike is downwards in terms of concentration, which I believe accounts for the increase in NH4 and PO4.

So really the problem is there seems to be a quick decay of biomass at the beginning and end of each day. there are no continuity errors and the time step is 30 seconds. initial conditions for the nutrients are scalar fields.

some relevant parameter settings:

time of model start: 09:00
DayL = 0.58
Beginning Max PP= 09:00
End Max PP = 17:00
SWVarOXY = ON = 1
Greens_E = 0.5 gC/m3
Greens_N = 0 gC/m3
Greens_P = 0 gC/m3

RadSurf =
Time Irradiance (W/m2)
2014/09/16-09:00:00 102.0728988
2014/09/16-10:00:00 116.2038991
2014/09/16-11:00:00 123.1768825
2014/09/16-12:00:00 126.3266638
2014/09/16-13:00:00 127.22243
2014/09/16-14:00:00 126.3266638
2014/09/16-15:00:00 123.1768825
2014/09/16-16:00:00 116.2038991
2014/09/16-17:00:00 102.0728988
2014/09/16-18:00:00 74.19761943
2014/09/16-19:00:00 3.800272047
2014/09/16-20:00:00 0
2014/09/16-21:00:00 0
2014/09/16-22:00:00 0
2014/09/16-23:00:00 0
2014/09/17-00:00:00 0
2014/09/17-01:00:00 0
2014/09/17-02:00:00 0
2014/09/17-03:00:00 0
2014/09/17-04:00:00 0
2014/09/17-05:00:00 0
2014/09/17-06:00:00 0
2014/09/17-07:00:00 2.993094689
2014/09/17-08:00:00 21.99489201
2014/09/17-09:00:00 28.92529478
2014/09/17-10:00:00 30.5025462
2014/09/17-11:00:00 30.10454846
2014/09/17-12:00:00 29.36807419
2014/09/17-13:00:00 29.04833084
2014/09/17-14:00:00 29.36807419
2014/09/17-15:00:00 30.10454846
2014/09/17-16:00:00 30.5025462
2014/09/17-17:00:00 28.92529478
2014/09/17-18:00:00 21.99489201
2014/09/17-19:00:00 2.993094689
2014/09/17-20:00:00 0
2014/09/17-21:00:00 0
2014/09/17-22:00:00 0
2014/09/17-23:00:00 0
2014/09/18-00:00:00 0
[.....]

I have also attached my .inp file. It is more simplified than the full model in an attempt to try and isolate the problem. Any hints as to where the trouble may lie?

Thank you,

Rudy
numerical bloom diurnal
Christophe Thiange, modified 3 Years ago.

RE: Erroneous spikes in BLOOM-related parameters in morning and evening

Jedi Knight Posts: 125 Join Date: 11/15/12 Recent Posts
On behalf of Hans Los:

BLOOM implicitly assumes a 24 hour time step, although technically it can be run on a shorter time step (and occasionally it should). However even when BLOOM runs at the same as transport and other processes, which is the case here, its main forcings should be specified at a diurnal bases. This means:

1. RADSURF must always be specified per day (or even per week) because internally BLOOM distributes the irradiance over time intervals of half an hour. Specifying RADSURF per hour as is done here is therefore not advisable: conceptually this is incorrect and numerically its results are unpredictable.
2. VTRANS which is used by the 3D simulation of available light should normally be 24 hours; here its value is 5 minutes.

So my advice is to first make a simulation based on these suggestions.
Rudy Schueder, modified 3 Years ago.

RE: Erroneous spikes in BLOOM-related parameters in morning and evening

Padawan Posts: 52 Join Date: 10/8/13 Recent Posts
Hi Christophe/Hans,

I have tried what has been suggested, perhaps not well, but I am still having some troubles.

I set PeriodVTRA = 24 hr

and if I specify RadSurf as daily averages (W/m2):

2014/09/16-09:00:00 103.7073645
2014/09/17-09:00:00 24.37117165
2014/09/18-09:00:00 545.8085622
2014/09/19-09:00:00 187.4294318
2014/09/20-09:00:00 31.27999062
2014/09/21-09:00:00 112.2087285
2014/09/22-09:00:00 312.9382165
[...]

then algae grow continuously throughout the simulation (even at night) with no diurnal variation. Needless to say this is not correct. How do I correctly specify a daily average for RadSurf? My methodology was based on the tutorial example for E. Coli in the friesian tidal inlet, where RadSurf was specified once a day at the model start time. I have attached my .inp once again.

Thank you for all of your help,

Rudy
HL
Hans Los, modified 3 Years ago.

RE: Erroneous spikes in BLOOM-related parameters in morning and evening (Answer)

Youngling Posts: 1 Join Date: 4/1/11 Recent Posts
Hi Rudy,

Sorry but why do you say 'needless to say this is incorrect?'

The essence of my previous reply is that you should distinguish between primary production: carbon fixation so the energy machinery and growth so increase in biomass which is the result of primary production and uptake of nutrients and other substances. Indeed primary production is limited to the day light period, but growth is not: if sufficient amounts of sugars are stored, cells continue to take up nutrients, increase their biomass and ultimately divide. As a matter of fact: many species of phytoplankton divide during the night.

Because exactly simulating all these processes is beyond the scope of BLOOM, you should only consider BLOOM's results once a day. Modelling the diurnal cycle is a whole different ball game.

Because in some cases the diurnal cycle of Oxygen is relevant, we have made a provision in Delwaq to redistribute the computed daily average primary production flux over the day but this is actually a post processing option, not the results of running BLOOM with short time intervals. This is the Varoxy option which you have activated. Varoxy assumes that BLOOM is run with a 24 hour time step, however. So using Varoxy in combination with shorter BLOOM time steps is actually incorrect! To explain this, consider a simple example where BLOOM is run with a 12 hour time step and a day length period of 12 hours. In this example Varoxy will produce O2 from primary production between 3 and 9 and between 15 and 21 hours, not between 6 and 18 hours.

So if you want to use Varoxy, you should also set the constant "TIMMULTBL' to such a value that TIMMULTBL * time step of transport = 24 hours.


Regards,

Hans
Rudy Schueder, modified 3 Years ago.

RE: Erroneous spikes in BLOOM-related parameters in morning and evening

Padawan Posts: 52 Join Date: 10/8/13 Recent Posts
Hi Hans,

Such a detailed answer, it is much appreciated. Indeed it seems I did not fully understand the mechanics of BLOOM but you have made it much clearer for me, especially with the example you provided.

Diurnal fluctuations are quite important in my case, and it may be that DYNAMO is more a more appropriate model than BLOOM for my purpose here. The benefit that BLOOM offers over DYNAMO as far as I can tell is a CO2 limitation (KCO2). My simulation focuses on elevated pH levels (9.4-10.2) in an environment where nutrients are in great abundance, and so currently algae under DYNAMO consume all of the CO2 and the pH >> 14 after a short while. In reality, I would imagine that growth would decline at those pH levels. BLOOM is able to simulate limitations as pH rises, I know now that it does not work best at a time step equal to that of DELWAQ. I would prefer to model the algae on DELWAQ time scales, which think is possible with DYNAMO.

I will think on your words for a while, and maybe look to see if I can edit DYNAMO to include a pH limitation as I described here in this post I have yet to resolve myself http://oss.deltares.nl/web/delft3d/delwaq/-/message_boards/view_message/573555

I will also make the changes you describe in my simulation using BLOOM and see how the results compare to my observations.

My thanks once again,

Rudy