Source type on active or passive tracers

[tony1230]

Hi Roms users
as we know,we can specify a mesh grid with active or passive point-sources at the river where the sources can be carried
into our simulating system.we can do this without effort.And recently,i was attempting to setup an application with plane-
or area-sources at intertidal area,in order to discuss the behavior on absorb and interchange of N and P on the interface.
But now i run into the trouble that i dont know how can these sources be set.Anyone who have done or been doing some work
relative to this, be so kind as to give me a reply.
ps: who have paper or material on this subject can send me a copy or tell me where can i refer to.

Tkanks for reply.

[tony1230]

I have found for papers on web of science、science direct and etc,accounts for non-point sources.
But hardly did i find some papers.For simplicity, i can specify number of cells of grid that gathering together
as so-called non-point, indeed it's not.

[kate]

You can simulate a plane source by using some number of individual sources. We did this in one version of the Northeast Pacific, to account for drainage from rain on the coastal mountains into the ocean, using 204 point sources. I wrote a script to create the NetCDF sources file in Perl/PDL, though I'd probably use a different scripting language now.

[tony1230]

Thanks kate for your reply

I konw, for common use, i can specify some more individual points connected together instead of the role as plane-source. That can be done, but actually the non-point source is not the gathering of individuals so simple.Between every two single point, there must exists some actions just as interchange, etc. Frankly speaking, i don't profoundly comprehend what would happen between them, its trick.

Kate you said using 204 individual points as plane source, you treated them just as "individual point" or took some inter-actions between them into account?

Hope for more more reply ...

best regards

tony

[kate]

They were 204 independent sources, one per grid segment along the SE Alaska coast. Each one pumped flow from land to a water cell. Some water cells could have two walls pumping flow into them. Each grid face pumped the same amount, but there was a seasonal cycle to the flow.

I'm not sure exactly what it is you are looking for, what with interactions between the fluxes.

[tony1230]

Hi kate

Thanks very much.I want to use non-point source for Nitrate, Phosphate, etc. But till now, im not sure whether equivalent to non-point model if i use much individual points. That is to say, what's different between the two concepts "non-point source" and "source by putting much single points together". Anyway, i should konw what would happen to both of the situation, and understand the differences.Then i can go on next step.Am i confused you or are there something irrational that i have post?

Weiwei Shou

[kate]

What we mean by point source is a source of fluid through the face of a grid box. You say you are looking for a way to add nitrate and phosphate to the model. This is rather different, also different from what I thought you wanted in the first post.

Some options:

1. provide a boundary condition of the external values so some can be advected in on inflow.

2. provide a climatology and nudge to it - be careful to only nudge these tracers and not all tracers. This has been done for iron by at least one group.

3. if you think it is coming in with the coastal runoff, add an iron (or whatever) source to the runoff code.

What you decide to do will depend on your exact problem. Do you have open boundary conditions? Why is it non-conservative and needing to be replenished?

[NiallBroekhuizen]

I joined the ROMS community about a month ago, and have been following the thread on point sources and diffuse sources with interest. I have decided that it is time for me to chip in. I am doing so, partly to let others know what I am doing, and partly to elicit opinions as to the approach I have adopted.

I am developing code for 'diffuse sources'. It focusses on 'biological processes' rather than those that will modify hydrodynamics (ie no addition/subtraction of water, momentum, heat or salinity, and ignoring influence upon drag; ultimately, the "actions" of the diffuse-srcs will be applied within subroutine Biology_tile()). In particular, the applications that I have in mind are: fish farms (in most cases these are small enough that they occupy only one water-column, so could, perhaps be implemented as a point source) and suspended rope mussel farms (New Zealand's largest farming zone is over 1000 ha, so encloses lots of water-columns at the grid-resolution we are aiming for).

I did consider manually creating lots of adjacent point sources to synthesize the diffuse source, but ended up rejecting that approach. My reasons were:
a) (most important, and more true for shellfish farms than fish farms), the magnitude of the instantaneous source/sink rates are, in part, dependent upon instantaneous realized water-column properties (water temperture, salinity, phytoplankton abundance) etc, so are better described by incorporating a '(partial) shellfish growth model that yields source/sink fluxes as a dynamic/emergent output' than by prescribing time-series of source/sink fluxes.

b) I wanted to have the flexibility to change grid-resolution w/o having to also synthesize new 'diffuse source' forcing files each time I did so.

Thus, the approach I have taken is as follows:

a) Design a generic header section for a Diffuse Source File. This header specifies things like:
i. nature of diffuse source (fish farm, shellfish farm etc)
ii. location of diffuse src (by means of three or more horizontal coordinate perimeter points ([xi,eta] or [Longitude,Latitude]).
iii. Vertical extent of the diffuse source (upper and lower interface depths expressed in m above sea-bed, or m below sea surface, or in sigma system)

b) Write a module to read this header info (Subroutine DiffuseSrc_init() and work out which water columns are wholly, or partially occupied by the diffuse src (Subroutine DiffuseSrc_map_onto_grid()). These water columns are inserted into the farm's vector of 'enclosed water-columns' (along with an estimate (0 <x<=1) of the horizontal fraction of the column's surface area that is enclosed).

c) Another module that is a vector whose elements are individual diffuse sources. Vector operations include things like insertion/deletion of individual point sources, and marching over the elements of the vector to apply the source's "activities" into the system

d) Design Data fields to express farming-system specific parameters of the diffuse source. eg, for fish farms these are things like:
time-series of median fish length, kg of total fish biomass, kg feed/crop/d together with scalar values for things like stoichiometry of the fish feed, and of the fish flesh, size & temperature dependent fish feeding and respiration rates etc.

e) Write a module that reads in said fish (or mussel) farm parameters. (Subroutine DiffuseSrc_read_farm_params() which calls either DiffuseSrc_fish_farm_read_params() or DiffuseSrc_mussel_farm_read_params)

f) code to load new blocks of time-series data (when required to maintain time-centering in the interpolation) and do the time-series interpolation(I like Fritsch-Butland splines cos they local (fast) and put any turning points at the knots, so I know that I wont get any impossible (negative) interpolated values provided input values are >= zero.

g) [yet to do]. Write code to actually apply the instantaneous source-sink processes.

DiffuseSrc_init() is called from read_BioPar() (and itself, calls DiffuseSrc_read_farm_params()).

Unfortunately, it transpires that read_BioPar() is called before the coordinates of the water-columns are known. Thus, DiffuseSrc_map_onto_grid() cannot be called until later. I chose to place the call inside an
If(is_geolocated) THEN loop within subroutine biology_tile(). (is_geolocated is a static/persistent logical value initially set to false, and then set to true when the loop is entered for the first time)

DiffuseSrc_apply_activities() will be called from within subroutine biology_tile() (outside of the 'for each water-column' loop). Instead it will be called inside a loop that looks something like:

SUBROUTINE vector_DiffuseSrc_apply_activities(....)
USE mod_diffuse_src
IMPLICIT NONE
for each diffuse_src{
for each water column enclosed by the diffuse src{
DiffuseSrc_apply_activities(the_src,...)
}
}
END SUBROUTINE
--------
Unresolved issues:
a) DiffuseSrc_map_onto_grid() is written for single-grid applications. It will need to be made smater to deal with multi-grid applications (presumably by breaking those diffuse srcs which straddle grid-boundaries into adjacent sub-sources that share an interface at the grid boundary

b) Do I want to go to the effort of writing the code to deal with the fact that the fraction of a control-volume (cf water-column) that is occupied by a farm may change as sea surface elevation changes (dep upon nature of vertical scheme, and whether the farm is floating, or anchored at a fixed depth etc etc)? My present thinking is that this is a tertiary issue that I may never tackle. I have bigger fish to fry (pun intended)

c) I have no experience with parallel programming. It remains to be seen whether my code will 'play nicely' in parallel environments [From my almost-nil understanding of these things, I think the pitfall is that, as things stand, my vector of diffuse srcs needs to be available to all processors].

d) wrt to (c), I guess I could have created a pair of global 3D logical arrays 'contains_fish_farm' and 'contains_mussel_farm', and used an IF THEN test within the 'for each water-column' loop inside biology_tile, but:
i. since diffuse-srcs will be scarce, this seems a bit wasteful memory wise and perhaps also runtime wise (lots of IF(is_occupied) THEN calls that are avoided in my chosen design)
ii. That would restrict me to having only one diffuse-src (of each time) in a water-column. From the point of view of numerics, I recognise that is really all that I have (cos that IS the grid resolution), but from a practical point of view, I think it is more intuitive to ask the model user merely to specify farm characteristics for each genuine (ie unique physical) farms than it is to ask the user to take responsibility for synthesizing an artificial 'compound farm' (I know, I could provide a spreadsheet for them to populate with individual genuine farms, and a button linked to a macro 'create_compound_farms', but (to my eyes at least) even that seems to add an additional level of complexity).

e) Coming from a C/C++ background, I would have liked to have been able to create a generic Diffuse-Source base-class with virtual methods tailored to fish-farms, mussel farms etc. etc. Unfortunately, this doesn't seem to be possible in F95. I think it may be doable in F2003, but since ROMS uses F95 at present, I rejected that approach. The 'ROMS way' seems to be #ifdef.... #endif, but since I need to be able to have both fish arms and mussel farms in the one application, I cann't use that approach. Thus, I am left with (for example)

Subroutine DiffuseSrc_apply_activities(this,...)
SELECT CASE (this%diffuse_src_type)
CASE (diffuse_src_fish_farm)
CALL DiffuseSrc_fishfarm_apply_activities(this,...)
CASE (diffuse_src_mussel_farm)
CALL DiffuseSrc_musselfarm_apply_activities(this,...)
CASE DEFAULT
'Stop DiffuseSrc_apply_activities(): unexpected type of source'
END SELECT
End Subroutine

e) It is unfortunate that DiffuseSrc_musselfarm_apply_activities() and DiffuseSrc_fishfarm_apply_activities() will themselves likely have to forward onto different functions depending upon which biological model is used (ie NEMURO, SWAMCO (which I have coded up) or one of the various Fasham derivatives etc etc).


-------------------
It will be a while yet before I have confidence in my code. Ultimately, I would like to be able to make the code available to others, but I will need to get permission from my employer before I can commit to doing so.

best wishes, and thanks for any feedback.

Niall