MohidWiki - User contributions [en]

Setup a MOHID simulation using MPI

2008-11-17T17:54:42Z

192.168.20.148: /* Requirements */

== Windows ==

=== Requirements ===

In order to run a simulation using MPI in MOHID you must fulfill the following requirements:
# These instructions are specific of a MOHID application running under the MS Windows.
# Remember this can only be applied if you have at least one nested domain.
# Make sure you have an executable file which was compiled together with MPI libraries and is able to be run in parallel. Learn more on [[compiling Mohid with MPI]].
# In order to take advantage of the [[parallel processing]] features make sure you have one processor available for each domain and sub-domains coupled in your simulation.
# Make sure that you have installed [[MPICH]] 2.0.x (download [http://www.mcs.anl.gov/research/projects/mpich2/ here])in each PC available for the simulation. To make sure MPICH is installed correctly and working properly, go to MS Windows Task Manager and look for a service called '''mdm.exe'''. In addition you should also follow all the instructions provided during the MPICH installation. Make sure that you've added MPICH installation folder to the PATH environmental variable. Just go to Control Panel -> System -> Advanced -> Environmental Variables. In the "System Variables" select the PATH variable and press Edit. Then add to the end of the string "C:\Program Files\MPICH2\bin", which is the path to where the mpirun.exe is installed. You need to install MPICH in every computer that you which to use. You may need to restart the computers after the installation, in order to get everything running.

==== Setup the simulation ====
# Setup the simulation with nested domains exactly the same way as in a normal simulation. Use [[MOHID GUI]] for an easier setup. No other specific configuration is necessary at this point
# Test the simulation by executing the model in a single machine
# Go to the '''\exe''' folder in the ''father'' domain. There you must find at least 2 files.
## [[nomfich.dat]]
## [[Tree.dat]]

==== MPI command line ====
The command line shown bellow is the simplest way to run Mohid using MPI:
>mpiexec -np 2 -localonly M:\aplica\MPI\FATHER\exe\MohidWater.MPI.exe
In the above example MohidWater is running with 2 processes, using only local machine's resources.

To run MohidWater using multiple computers use something like this:
>mpiexec -hosts 2 RICARDOM-VM 1 FRANK-FIXO 2 -map M:\\RICARDOM-VM\projects
M:\aplica\MPI\FATHER\exe\MohidWater.MPI.exe
Both machines are required to have the same executable. Here a explicit map is made so that both machines know where the executable is.

===Requirements===
# Remember this can only be applied if you have at least one nested domain.
# Make sure you have an executable file which was compiled together with MPI libraries and is able to be run in parallel. Learn more on [[compiling Mohid with MPI]].
# In order to take advantage of the [[parallel processing]] features make sure you have one processor available for each domain and sub-domains coupled in your simulation.
# Make sure that you have installed an mpd daemon. Refer to the linux instructions in [[compiling Mohid with MPI]].

Mohid PostProcessor

2008-05-09T16:18:30Z

192.168.20.148: /* ROI */

== Overview ==

[[Image:PostProcessorSample.jpg|200px|thumb|right|'''Example of plots made with MOHID PostProcessor''']]

Mohid Postprocessor is a graphical user interface which displays data stored in HDF5 files as animation on the screen. Mohid Postprocessor is written in FORTRAN and uses OpenGL to display the results. This tool allows you to visualize the temporal evolution and spatial distribution of any property as a continuous animation.

The data can be displayed in several ways like, color maps, isolines, vector plots and particle (for the lagrangian model). The display can be done in different views: XY slice, XZ slice, YZ slice, TZ slice or 3D cube.

Usually Mohid Postprocessor will be launched directly from [[Mohid GUI]], opening directly the file chosen by the user (see [[Mohid GUI#Switching to Post Processing Mode|Switching to Post Processing Mode]]).

== Main window ==
This window is divided into three main areas: (i) HDF Tree View on the left, (ii) Selection Buttons in the middle and (iii) Selection Lists on the right.

[[Image:PostProcessorMainWindow.png|300px|thumb|centre|'''MOHID PostProcessor main window''']]

=== HDF tree ===
The HDF Tree displays, in a hierarchical way, the contents of an [[HDF5 file]]. The tree consists of a file which has several groups which themselves have several datasets.

=== Selection Buttons ===
The selection buttons allow to transfer selected data items in the HDF Tree to the Selected Data Lists. For instance, to display temperature as color map, select the correspondent HDF item in the HDF Tree and then press the Color button (the first button of the selection buttons). The information will pass to the Selected Data Lists. By selecting a group of data items, all datasets in that group will pass to the Selected Data Lists.

=== Selected Data Lists ===
The Selected Data Lists display the data which is select to be displayed. To remove data from any of the lists, select the data items to remove and choose in the PostProcessor main menu, Action -> Delete.

== Step by Step ==

=== Open a HDF5 file ===
Open one or more HDF files.

=== Selecting Spatial Information ===
Select the grid over which to represent the data.

=== Selecting Information to Display ===
Select the data to represent.

=== Loading the Data ===
Load the data.

=== Image Settings ===
Adjust the settings of the data.

=== OpenGL Window ===
Display the data.

=== Save the Images ===
Save the images.

==ROI==
The ROI selects the region of interest to plot. You can plot maps (XY), sections (XZ and YZ), vertical profile time series (TZ) and in 3D.

When plotting sections or in 3D, the factor in the Z scale depends on the ratio between the size of the horizontal domain and the maximum depth of the water column at the specified section or, if when plotting in 3D, of the entire domain.

Take into account that the size of the horizontal domain depends on whether you load the metric coordinates (ConnectionX and ConnectionY) or the geographical coordinates (Latitude and Longitude). This is because the Post-Processor, when drawing the images, does not regard the units of the distances, but only its value.

For example, if you load ConnectionX and ConnectionY and your domain has 1000x1000km and 1000m of maximum depth, you have an horizontal plane which is 1000 times bigger than the vertical plane. Normally, to better understand the plot a ratio of 1:50 up to 1:100 is recommended, thus you should use a factor for Z of around 10 (1:100) to 20 (1:50).

If you load Latitude and Longitude, and you domain ranges from, e.g. 35º-45ºN and 16º-6ºW, thus a 10ºx10º domain and the same 1000m maximum depth, then your horizontal plane is 100 smaller than the vertical plane, because the ratio is computed based on the coordinates values not regarding the distance units. In this case you should use a Z factor of around 0.01 or 0.005.

[[Category:Graphical User Interfaces]]

Compiling Mohid with MPI

2008-05-07T14:22:03Z

192.168.20.148: /* Compile with CVF on Windows */

== Compile with Compaq Visual Fortran on Windows ==
To compile Mohid with Compaq Visual Fortran 6.6c using [[MPI]] (MPICH2) in Windows please follow this steps:

#Setup a Mohid Project to compile with Compaq Visual Fortran (CVF6.6c). See more on [[Compiling with CVF]].
#Make sure that in the same folder where the HDF5 libraries are placed you have the '''fmpich2s.lib''' file. If not, get it from SourceSafe.
#Create new configuration by going to "Build...Configurations".
#Click "Add".
#Name your new configuration e.g. "MPI".
#Select "Release" configuration from the "Copy settings from" dropdown box
#Press "OK", and then "Close".
#Go to "Project...Settings"
#Select the "Fortran" tab and "Preprocessor" in the "Category" dropdown box
#Include the '''_USE_MPI''' keyword in the "Predefined Preprocessor Symbols" text box
#Select the "Link" tab
#Select "General" in the "Category" dropdown box
#Add '''fmpich2s.lib''' at the "Object/library modules" text box

== Compile with Intel Fortran Compiler on Windows ==
To compile Mohid with Intel Fortran Compiler 9.x (IFC) using [[MPI]] in Windows please follow this steps:
# You must have installed MPICH2 in your PC (and in the ones you which to use).
# Setup a Mohid Project to compile with IFC. See more on [[Compiling with IFC]].
# Make sure that in the same folder where the HDF5 libraries are placed you have the '''fmpich2.lib''' file. If not, get it from [[SourceSafe]].
# Create new configuration by going to "Build...Configurations".
# Select "<New...>" from the "Active Solution Configuration" dropdown box
# Name your new configuration in the "Solution Configuration Name" text box (e.g. "MPI")
# Select "Release" configuration from the "Copy settings from" dropdown box
# Press "OK", and then "Close".
# Go to "Project...Properties"
# Select "Fortran" and then "Preprocessor" in the "Configuration Properties" tree view menu
# Include the '''_USE_MPI''' keyword in the "Preprocessor Definition" text box
# Select the "Linker" and then "Input"
# Add '''fmpich2.lib''' in the "Additional Dependencies" text box
# Press the "Apply" button and then "OK"
# Rebuild

== Compile with IFC on Linux ==
*Build the mpich libraries:
>./configure --enable-f90 --enable-romio
>make
>make testing
>make install
*Build the hdf5 libs with [[MPI]]:
CC=mpicc F9X=mpif90 ./configure --enable-fortran --disable-shared --prefix=/home/guillaume/Projects/hdf5/hdf5-1.6.5/hdf5_mpi
make
make install
*Build MohidWater with [[MPI]]
make nix_mpi
Basically ''nix_mpi'' uses ''mpif90'' instead of ''ifort'' and appends the argument ''-D_USE_MPI'' in the ''CCFLAGS'' environment variable.
[[Category:Programming]]
[[Category:Technology]]
[[Category:Linux]]
[[Category:Windows]]
[[Category:Compiling]]

Module EnterData

2008-03-13T15:21:51Z

192.168.20.148:

== Overview ==

In MOHID all input data is handled by a generic input data module, ModuleEnterData. This module is used by all the other modules in MOHID which need an input data file with the compute options definition.

The reading procedure used by ModuleEnterData is quite simple and works with a client/server methodology, being ModuleEnterData the server and the other modules the client.
Thus, a module that needs information from an input file requests ModuleEnterData to read it, having only to provide the filename. The file is then opened and given a unique identification number. Data is read line by line and all information is stored in memory, so that the client module can access it by means of specific query methods (e.g. [[GetData]]) for each type of information.
When all the data has been fully and successfully extracted, the file is closed and the allocated memory released.

This methodology using a generic interface module for input data has proven to be extremely efficient in terms of programming allowing reading new information in a straightforward way, reducing programming errors and allowing code developers to focus more on their expertise scientific area of the model rather then on complex input programming syntax and routines. Also it reduces input data errors as it standardizes the format of the input files and the methods to access data in those files.

== ASCII data files syntax ==

Input data in MOHID is based on ASCII files, enabling platform independency as the model is able to run without the use of a graphical user interface, normally designed specifically for each operating system.

Files are organized by keywords and information blocks, which can pile up to three hierarchical levels and aggregate groups of keywords. This format can be seen likewise a simple Mark-Up Language. File generation can be made manually, using a text editor, or, in some cases, by using MOHID graphical user interface ([[MOHID GUI]]).

The maximum number of characters per line is restricted to 256. As each line contains only one instruction, this restriction does not represent any practical limitation to the user. Files can have blank lines and keywords don’t have to follow any specific order. This reduces the effort of preparing input data files in a rigid format and reduces input data errors.
With exception to some cases, all the reading ([[keywords]], keyword values, [[blocks]] definition tags) is case sensitive, so caution is advised in the preparation of the files because recognition is only achieved by full correspondence of characters in the code and in the data files.

'''WARNING''': Comment lines can NOT have ":" character. For example if ":" character appears in the end of the sentence results in an error, because Module EnterData is expecting to read a value after the ":" character.

[[Category:Modules]]
[[Category:Input Data Formats]]
[[Category:MOHID Base 1]]

Module InterfaceSedimentWater

2008-02-07T15:23:33Z

192.168.20.148: /* Maps (HDF5 format) */

== Overview ==
The sediment-water interface module computes boundary conditions at the bottom of the water column. It computes shear stress as a boundary condition to the hydrodynamic and turbulence modules. It is also responsible for computing fluxes at the water-sediment interface, managing boundary conditions to both the water column properties and the sediment column properties.
Both in the water column or in the sediment column, properties can be either dissolved or particulate. The evolution of dissolved properties depends greatly on the water fluxes, both in the water column and in the sediment interstitial water. Particulate properties evolution in the water column depends also on the water fluxes and on settling velocity. Once deposited in the bottom they can either stay there or be ressuspended back to the water column. If they stay there for a determined period of time, they can become part of the sediment compartment by consolidation.

== Momentum fluxes ==

=== Bottom shear stress induced by currents ===

In the bottom boundary, advective fluxes are imposed as null and diffusive flux of momentum is estimated by means of a bottom stress. This shear stress can be calculated based on near-bed currents and also on stress induced by surface waves.

==== Manning formulation ====

==== Logarithmic law of the wall ====

Currents induced bottom shear stress is calculated by a non-slipping condition method with a quadratic law that depends on the near-bottom velocity. Thus, the diffusive term at the bottom is written as:

EQUATION 1

Where CD is the bottom drag coefficient that is calculated with the expression:

Where κ is von Karman constant and zb0 is the bottom roughness length. This quadratic law is derived from the logarithmic law of the wall near boundaries characteristic of boundary layers, as the bottom velocities are located half a grid box above the bottom. This term is calculated semi-implicitly following Backhaus [1985] for numerical stability reasons.

=== Bottom shear stress induced by surface waves ===

Surface waves exert friction forces at the bed during propagation. The bed shear stress is related to the friction coefficient by:

In which:
Instantaneous bed-shear stress [N/m2]
Friction coefficient [dimensionless]
Instantaneous fluid velocity just outside boundary layer [m/s]
Fluid density [kg/m3]
The friction factor fw is assumed to be constant over the wave cycle and is determined from the peak values as:

The time-average (over a wave cycle) bed shear stress is:

In the rough turbulent regime Jonsson (1966 in van Rijn, 1989) proposed:

fw,max=0.3for
Where ks stands for bed roughness [m]

== Mass fluxes ==

=== Particulate matter transport ===

==== Erosion ====

==== Deposition ====

=== Ecology and water quality ===

==== Benthos ====

==== BenthicCEQUALW2 ====

==== Detritus ====

== Outputs ==

=== Time series ===

=== Box integration ===

=== Maps (HDF5 format) ===
In InterfaceSedimentWater results, for the dissolved properties (e.g. ammonia) the concentration is always zero, because it is considered that all the dissolved mass is released to water column (e.g. ammonia as a product of organic matter mineralization).

In InterfaceSedimentWater results the flux to water for the dissolved properties ammonia, oxygen, inorganic phosphorus, particulate organic phosphorus and particulate organic nitrogen can sometimes present a negative value due to rounding errors in computing the fluxes. In these case the negatives value should be considered as zero.

=== Statistics ===

== References ==
*Krone, R., 1962, Flume Studies of the Transport in Estuaries Shoaling Processes, Hydr. Eng. Lab., University of Berkeley, California, USA
*Mehta, J., 1988, Laboratory Studies on Cohesive Sediment Deposition and Erosion, Physical Processes in Estuaries, Springer-Verlag, Berlin Heidelberg New York, Job Dronkers and Wim van Leussen (Editors)
*Partheniades, E., 1965, Erosion and Deposition of Cohesive Soils, J. Hydr. Div., ASCE, 91 (1), 105-139

[[Category:Modules]]
[[Category:MOHID Water]]

Module Benthos

2008-02-07T15:18:48Z

192.168.20.148: /* Useful notes */

== Overview ==

Module Benthos is a zero-dimensional biogeochemical model and was designed to compute, using simple model formulations, some of the main benthic biogeochemical processes occurring in an aquatic system:
(i) Algae mortality, if algae are considered as a particulate property that can sink and deposit, then if deposited a mortality rate is applied;
(ii) Particulate organic matter mineralization (nitrogen and phosphorus biogeochemical cycles);
(iii) Biogenic silica dissolution;
(iv) Oxygen depletion.

<blockquote style="background: white; border: 1px blue; padding: 1em;">
*algae mortality, if algae are considered as a particulate property that can sink and deposit, then if deposited a mortality rate is applied
*Particulate organic matter mineralization (nitrogen and phosphorus biogeochemical cycles)
*Biogenic silica dissolution
*Oxygen depletion
</blockquote>

Module Benthos is also ready to be coupled, in terms of organic matter mineralization, biogenic silica dissolution and oxygen depletion, with other pelagic biogeochemical models included in Mohid such as: [[Module WaterQuality]] and [[Module Life]].

== Algae Mortality ==
A mortality rate can be applied over algae deposited in the water-sediment interface. ModuleBenthos is ready to assume phytoplankton and diatoms as algae.

As this happens, the algae nitrogen and phosphorus internal pools are converted into particulate organic matter, and for the specific case of diatoms, its silica pool is transformed into dissolved silica.
Algae mortality is computed as described in (eq. 1).

<math>\frac{dM^{X}}{dt}= -k_{mortality}^{X} \cdot M^{X}</math>

Where is the algae (phytoplankton or diatoms) deposited mass (kg of carbon), is the algae mortality rate (s-1).

Hence, the algae mortality generates an input for the particulate organic matter pool, which can be accounted in particulate organic nitrogen (PON), (eq.2) and particulate organic phosphorus (POP) (eq.3).

<math>\frac{dM^{PON}}{dt}= -k_{mortality}^{X} \cdot M^{PON} \cdot \alpha_{N/C}^{X}</math>

Where is given in kg of Nitrogen and is the algae’s Nitrogen/Carbon ratio (which is different for phytoplankton and for diatoms).

<math>\frac{dM^{POP}}{dt}= -k_{mortality}^{X} \cdot M^{POP} \cdot \alpha_{P/C}^{X}</math>

Where is given in kg of Phosphorus and is the algae’s Phosphorus/Carbon ratio (which is different for phytoplankton and for diatoms).
For diatoms, the biogenic silica derived from its mortality, is computed as:

<math>\frac{dM^{BioSi}}{dt}= -k_{mortality}^{diatoms} \cdot M^{BioSi} \cdot \alpha_{Si/C}^{diatoms}</math>

Where is given in kg of Silica and is the algae’s Silica/Carbon ratio (in the case of diatoms simulation).

== Organic matter mineralization ==
Organic matter mineralization is computed over its nitrogen and phosphorus fractions, by means of a temperature dependent rate and considering that bacterial abundance is constant in time and its activity, as said, is temperature dependent.
This mineralization process is responsible for oxygen depletion, but it’s also regulated by oxygen availability. If oxygen levels reach anoxia ( ) conditions then, organic matter mineralization is stopped. This limitation is computed as in (eq.5).

<math>Lim_{O_{2}}=\frac{O_{2}}{O_{2}+0.5}</math>

Thus for the nitrogen fraction of organic matter, mineralization can be computed as in (eq.6) and (eq.7), for PON and ammonia, respectively.

<math>\frac{dM^{PON}}{dt} = -(k_{decay-N} \times \phi_{PON}^{(T-20C)}) \cdot M^{PON} \cdot Lim_{O_{2}} </math>

<math>\frac{dM^{NH_{4}^{+}}}{dt}= (k_{decay-N} \times \phi_{PON}^{(T-20C)}) \cdot M^{PON} \cdot Lim_{O_{2}}</math>

Where is given in kg of Nitrogen, is the reference mineralization rate for PON, is a temperature coefficient, and is the water temperature at the water-sediment interface (ºC).
Regarding the phosphorus budget:
(eq.8)

(eq.9)

Where is given in kg of Phosphorus, is the reference mineralization rate for POP, is a temperature coefficient, and is the water temperature at the water-sediment interface (ºC).
For more details on the oxygen budget, see chapter 2.4.

== Silica dissolution ==

Silica dissolution is simulated as a constant rate over the biogenic silica deposited in the water-sediment interface, acting as a source of dissolved silica.
(eq.10)

(eq.11)

Where is given in kg of biogenic silica, is given in kg of dissolved silica and is the dissolution rate for biogenic silica.

== Oxygen depletion ==

Oxygen depletion occurs due to organic matter mineralization, and is computed according to stoichiometric relations.
(eq.12)

(eq.13)

Where is given in kg of oxygen, and are the Nitrogen/Carbon and Phosphorus/Carbon ratios of particulate organic matter, and is the ratio between Oxygen and Carbon in CO2.

== Numerical scheme ==
Module Benthos solves the differential equations described above using an Euler forward scheme (explicit method), which was used in order to make the code organization as simple as possible. When using this numerical method there are, nevertheless, some restraints in terms of temporal discretization, which can cause numerical instabilities that can be solved, at some extent, by using a smaller time step.

Module Benthos has an independent time step in relation to the model’s main time step. Normally the time step to integrate the differential equations describing these kind of biogeochemical reactions is much higher than the time step used to solve hydrodynamic and transport equations, and as the set of equations in this module is quite simple, there is no significant increase in terms of computational costs when using a smaller time step.

== User guide ==

As described before, Module Benthos is directly connected with [[Module InterfaceSedimentWater]], therefore making it necessary to understand some of the options to be made in the [[InterfaceSedimentWater]] input data file.

All properties undergoing biogeochemical reactions in Module Benthos must be defined in [[Module InterfaceSedimentWater]], and keyword '''BENTHOS''' has to be activated in every one of it, including oxygen, which is mandatory to be computed.

'''BENTHOS : 1'''

Additionally, property temperature must be also defined, as it controls mineralization rates. Nevertheless, as temperature is not subject to any specific process in the bottom, the '''BENTHOS''' keyword value for this property must be set to 0.

Particulate properties, such as particulate organic nitrogen, particulate organic phosphorus, biogenic silica, phytoplankton (if desired) and diatoms (if desired) must be set as '''PARTICULATE'''.

'''PARTICULATE : 1'''

Dissolved properties such as ammonia, inorganic phosphorus, dissolved silica, oxygen and temperature, must be set to '''PARTICULATE : 0'''.

The properties defined in the [[Module InterfaceSedimentWater]] must be consistent with the [[Module WaterProperties]] input file, which means that every property important for the benthic model must be defined in both input files;With exception to temperature, all dissolved properties defined in the [[Module InterfaceSedimentWater]] input file, with option '''BENTHOS''' activated, must set keyword '''WATER_FLUXES : 1'''. Particulate properties also need this option activated in order to compute the fluxes between the water column and the bottom due to erosion and deposition.

Also as Module Benthos computes biogeochemical processes involving dissolved processes near the sediment-water interface (e.g. oxygen depletion), all these properties must be defined in the water column. In addition, and as referred above, temperature, as it influences the mineralization rates, is mandatory to be defined in the [[Module WaterProperties]] input data file.
With exception to temperature, all properties defined in the ModuleInterfaceSedimentWater input file with option BENTHOS activated, must set keyword to '''BOTTOM_FLUXES : 1''' in the [[Module WaterProperties]] input file. This keywords activates an option that computes a bottom boundary condition in the transport equations of the dissolved properties due to the biogeochemical processes computed in Module Benthos.

For more on Module Benthos keywords go to [http://www.mohid.com/IHS/ Mohid Keyword Online Database].

== Useful notes ==
The results from ModuleBenthos are handled by [[Module InterfaceSedimentWater]].

[[Category:Modules]]
[[Category:MOHID Base 1]]
[[Category:Biogeochemistry]]

Module MacroAlgae

2008-01-14T18:12:36Z

192.168.20.148: /* Performing outputs of biogeochemical rates */

== Overview ==

Module MacroAlgae is a zero-dimensional biogeochemical model and was designed to compute the main biogeochemical processes related with macroalgae in aquatic environments. This module simulates two types of macroalgae:

- '''Attached macroalgae''' - macroalgae attached to the bottom of the water column

- '''Drifting macroalgae''' - macroalgae dettached from the bottom drifting in the water column

The evolution of the two macroalgae types is computed in the exactly same way (although different parameters are allowed for each type). The main differences relate to the fact that attached macroalgae are not transported by flow and drifting macroalgae are. On top of the main primary production limiting factors (e.g. light, nutrients, temperature), attached macroalgae growth is also limited by salinity (optionally), by suspended particulate matter deposition fluxes and also by shear stress near the bottom, which dettaches these macroalgae which become drifting macroalgae.
Drifting macroalgae do not have this type of limitation (SPM deposition flux and obviously bottom shear stress) and when they reach the shore the only process computed is an increased mortality rate.

This module is independent of the pelagic and benthic biogeochemical model being used to compute other biogeochemical processes, thus it can be coupled with [[Module WaterQuality]], [[Module CEQUALW2]] or [[Module Life]], or even [[Module Benthos]].

One feature of this macroalgae model is that it is fully coupled with the 3D transport model, as macroalgae, although attached in the bottom, can influence water properties in the all water column and not only to the grid cell near the bottom (e.g. light attenuation, nutrients uptake, etc). This is the case when the macroalgae height is higher than the grid cell height. Basically, an occupation ratio is computed for each grid cell, based on the bottom distribution and macroalgae height.

== Equations ==
As mentioned before, attached macroalgae evolution, in terms of biogeochemical processes, is computed exactly the same way as drifting macroalgae, and can be written as:

<math>\frac{dM _x}{dt} = (\mu _x - r_x - e_x - m_x - G_x) \cdot M _x </math>

where,
*<math>x</math> is the type of macroalgae (attached or drifting)
*<math>M _x</math> is the macroalgae distribution
*<math>\mu _x</math> is the gross production rate (in <math>day^{-1}</math>)
*<math>r_x</math> is the respiration rate (in <math>day^{-1}</math>)
*<math>e_x</math> is the excretions rate (in <math>day^{-1}</math>)
*<math>m_x</math> is the natural mortality rate (in <math>day^{-1}</math>)
*<math>G_x</math> is the lost chain grazing rate (in <math>day^{-1}</math>)

=== Gross production rate ===
The gross production rate <math>\mu _x</math> is given by:

<math> \mu _x = \mu^{\max }_x \cdot \min \left[{\psi (N)_x ,\psi (P)_x} \right]\cdot \psi (E)_x \cdot \psi (T)_x \cdot \psi (S)_x</math>

where,
*<math>\mu^{\max }_x</math> is the macroalgae maximum growth rate (in <math>day^{-1}</math>)
*<math>\Psi (N)_x</math> is the nitrogen limiting factor
*<math>\psi (P)_x</math> is the phosphorus limiting factor
*<math>\psi (E)_x</math> is the light limiting factor
*<math>\psi (T)_x</math> is the temperature limiting factor
*<math>\psi (S)_x</math> is the salinity limiting factor

=== Limiting factors ===

==== Nutrients ====

The nitrogen limiting factor can be computed as:

<math> \psi (N)_x = \frac{{C_{NH_4} + C_{NO_3}}} {{K^N_x + C_{NH_4} + C_{NO_3}}} </math>

where,

*<math>C_{NH_4}</math> is the ammonia concentration in <math>mg_N \cdot l^{-1}</math>
*<math>C_{NO_3}</math> is the nitrate concentration in <math>mg_N \cdot l^{-1}</math>
*<math>K^N_x</math> is the nitrogen half-saturation constant in <math>mg_N \cdot l^{-1}</math>

The phosphorus limiting factor can be computed as:

<math> \psi (P)_x = \frac{{C_{PO_4}}} {{K^P_x + C_{PO_4}}} </math>

where,

*<math>C_{PO_4}</math> is the inorganic phosphorus concentration in <math>mg_P \cdot l^{-1}</math>
*<math>K^P_x</math> is the phosphorus half-saturation constant in <math>mg_P \cdot l^{-1}</math>

==== Light ====

==== Temperature ====
Macroalgae's temperature limiting factor is given by:

<math>\psi (T)_x = K_A (T)_x \cdot K_B (T)_x</math>

where,

<math> K_A (T)_x = \frac {K^1_x \cdot e^{\gamma^1_x \cdot \left( {T - T^{min}_x} \right)}} {{1 + K^1_x \cdot \left( {e^{\gamma^1_x \cdot \left({T - T^{min}_x } \right)} - 1} \right)}} </math>

<math> K_B (T)_x = \frac{K^4_x \cdot e^{\gamma^2_x \cdot \left( {T^{max}_x - T} \right)}} {{1 + K^4_x .\left( {e^{\gamma^2_x \cdot \left( {T^max_x - T} \right)} - 1} \right)}}</math>

==== Salinity ====

=== Respiration rate ===
The macroalgae respiration rate is given by:

<math>r_x = k^{re}_x \cdot e^{(0.069 \cdot T)} + k^{rp}_x \cdot \mu_x </math>

where,
*<math>k^{re}_x</math> is the macroalgae endogenous respiration (in <math>day^{-1}</math>)
*<math>T</math> is the water temperature (<math> in ^o C </math>)
*<math>k^{rp}_x</math> is the macroalgae photo respiration rate (in <math>day^{-1}</math>)

=== Excretion rate ===
The macroalgae excretion rate is given by:

<math>e_x = \varepsilon_x \cdot \mu_x \cdot (1 - \psi (E)_x )</math>

where,

*<math>\varepsilon_x</math> is the reference excretion rate (in <math>day^{-1}</math>)

=== Natural mortality rate ===
The macroalgae natural mortality rate is given by:

<math> m_x = m^{max}_x \cdot \frac{{\frac{{M_x}} {{\mu _x}}}} {{K^m_x + \frac{{M_x}} {{\mu_x}}}} </math>

where,

*<math>m^{max}_x</math> is the maximum natural mortality rate (in <math>day^{-1}</math>)
*<math>K^m_x</math> is the half-saturation constant

== Numerical scheme ==
Module MacroAlgae solves the differential equations described above using an Euler forward scheme (explicit method), which was used in order to make the code organization as simple as possible. When using this numerical method there are, nevertheless, some restraints in terms of temporal discretization, which can cause numerical instabilities that can be solved, at some extent, by using a smaller time step.

Only for a specific calculation (drifting macroalgae mortality when reaching the shore), an Euler backward scheme (implicit method) is used to insure numerical stability.

Module MacroAlgae has an independent time step in relation to the model’s main time step. Normally the time step to integrate the differential equations describing these kind of biogeochemical reactions is much higher than the time step used to solve hydrodynamic and transport equations, and as the set of equations in this module is quite simple, there is no significant increase in terms of computational costs when using a smaller time step.

== User guide ==

=== Waterproperties data file options ===

In order to activate this module, specify in [[Module WaterProperties]] input data file, in each property involved in macroalgae processes the following keyword:

MACROALGAE : 1

Here is the property list which has to be with the macroalgae processes keyword activated:

macroalgae
drifting macroalgae
oxygen
ammonia*
nitrate*
dissolved non-refractory organic nitrogen*
particulate organic nitrogen*
inorganic phosphorus**
dissolved non-refractory organic phosphorus**
particulate organic phosphorus**

<nowiki>*</nowiki>if computing the nitrogen cycle

<nowiki>**</nowiki>if computing the phosphorus cycle

The following step, still in [[Module WaterProperties]] input data file, in the header section, the following keywords:

MACROALGAE_MASS : 0.001 !macroalgae bottom distribution in gC/m2
MACROALGAE_HEIGHT : 0.25 !macroalgae reference height in meters

Ultimately one must parameterize the influence of macroalgae in [[light extincion]]. Thus, in the macroalgae property block the following keywords must be defined:

LIGHT_EXTINCTION : 1 !activates macroalgae influence on light extinction
EXTINCTION_PARAMETER : 0.01 !defines the extinction parameter for macroalgae

Remember that in property '''macroalgae''' advection-diffusion should be off:

ADVECTION_DIFFUSION : 0

Property '''drifting macroalgae''' advection-diffusion should be on.

=== Macroalgae data file options ===
Then, activate Module MacroAlgae in [[MOHID GUI]] as described [[Mohid_GUI#Insert_a_Run|here]], which enables to edit the MacroAlgae input data file. In this file, data is stored and organized in [[keywords]] and [[blocks]]. The main keywords are:

'''Keyword''' '''Default value''' '''Description'''
DT : 3600] !Time step compute biogeochemical processes
PELAGIC_MODEL : WaterQuality !Defines which pelagic biogeochemical model is coupled
NITROGEN : 0 !Compute the nitrogen cycle
PHOSPHORUS : 0 !Compute the phosphorus cycle

For each macroalgae type a [[block]] must be specified:

'''Attached macroalgae''' - <begin_macroalgae> ... <end_macroalgae>
'''Drifting macroalgae''' - <begin_driftingmacroalgae> ... <end_driftingmacroalgae>

Inside each block specific parameters are defined:

'''Keyword''' '''Default value''' '''Description'''
GROWMAX : 0.4 !maximum growth rate
TOPTMIN : 20. !optimum minimum temperature for growth
TOPTMAX : 25. !optimum maximum temperature for growth
TMIN : 5 !minimum temperature for growth
TMAX : 40. !maximum temperature for growth
TCONST1 : 0.05 !constant to control temperature response curve shape
TCONST2 : 0.98 !constant to control temperature response curve shape
TCONST3 : 0.98 !constant to control temperature response curve shape
TCONST4 : 0.02 !constant to control temperature response curve shape
PHOTOIN : 90. !optimum radiation value
ENDREPC : 0.009 !endogenous respiration rate
PHOTORES : 0.018 !photorespiration rate
EXCRCONS : 0.008 !excretion rate
MORTMAX : 0.003 !natural mortality rate
MORTCON : 0.03 !mortality half saturation constant
GRAZCONS : 0.00008 !grazing rate over macroalgae
SOLEXCR : 0.25 !fraction of soluble inorganic material excreted by macroalgae
DISSDON : 0.25 !fraction of dissolved organic material excreted by macroalgae
NSATCONS : 0.065 !nitrogen half-saturation constant for macroalgae
PSATCONS : 0.001 !phosphorus half-saturation constant for macroalgae
RATIONC : 0.18 !macroalgae nitrogen/carbon ratio
RATIOPC : 0.024 !macroalgae phosphorus/carbon ratio
MACROALGAE_MINCONC : 1e-12 !minimum residual value for macroalgae abundance
MIN_OXYGEN : 1e-8 !minimum oxygen concentration for macroalgae growth
DEPLIM : 5e-6 !maximum SPM deposition flux for macroalgae growth(kg m-2 s-1)*
EROCRITSS : 0.1 !critical shear stress to occur macroalgae dettachment (in Pa)*
SALT_EFFECT : 0 !include salinity limitation on macroalgae growth
SALTOPT : 20 !macroalgae optimum salinity for growth
SALTCRIT : 5. !macroalgae critical salinity limit growth
SALTMIN : 0. !macroalgae minimum salinity for growth
SALTMAX : 45. !macroalgae maximum salinity for growth
BEACHED_MORT_RATE : 0.01 !beached drifting macroalgae mortality rate**

<nowiki>*</nowiki>only for attached macroalgae

<nowiki>**</nowiki>only for drifting macroalgae

== Performing outputs of biogeochemical rates ==
In order to perform outputs of biogeochemical rates and other parameters of the MacroAlgae model, you can define in the [[WaterProperties]] input data file the following options.

BOXFLUXES : ..\..\GeneralData\Boxes.dat !path to a [[Boxes|boxes data file]]

The same keyword, referencing the same [[Boxes|boxes data file]] must be defined in the [[Module_Hydrodynamic|Hydrodynamic]] input data file. This insures the output of the [[water.BXM file]], which contains the spatial integration of the water volumes into the previously boxes defined.

Also '''at least one''' water property needs to have the following keyword activated:

BOX_TIME_SERIE : 1

Next step is to define the rates which the user wants to analyse. This is done similarly to the other biogeochemical modules. All exchange rates are available for output (e.g. macroalgae to ammonia, ammonia to macroalgae, oxygen to macroalgae, macroalgae to oxygen, etc...)

This can be done by defining in [[WaterProperties]] input data file, a [[block]] as the one presented below:

<beginwqrate>
NAME : macroalgae ammonia uptake
DESCRIPTION : what goes from ammonia to macroalgae
FIRSTPROP : ammonia
SECONDPROP : macroalgae
MODEL : MacroAlgae
<endwqrate>

<beginwqrate>
NAME : macroalgae ammonia excretions
DESCRIPTION : what goes from macroalgae to ammonia
FIRSTPROP : macroalgae
SECONDPROP : ammonia
MODEL : MacroAlgae
<endwqrate>

One can also analyse other parameters such as:
*macroalgae gross production
*macroalgae temperature limiting factor
*macroalgae light limiting factor
*macroalgae nutrients limiting factor
*macroalgae nitrogen limiting factor
*macroalgae phosphorus limiting factor
*macroalgae salinity limiting factor

In these cases, in the '''<beginwqrate>...<endwqrate>''' block, the FIRSTPROP keyword relates to the parameter to be analysed and the SECONDPROP relates to the type of macroalgae. For example, if one wishes to analyse the gross production of attached macroalgae and drifting macroalgae, the data file should look like this:

<beginwqrate>
NAME : macroalgae gross production
DESCRIPTION : macroalgae gross production
FIRSTPROP : grossprod
SECONDPROP : macroalgae
MODEL : MacroAlgae
<endwqrate>

<beginwqrate>
NAME : macroalgae gross production
DESCRIPTION : macroalgae gross production
FIRSTPROP : grossprod
SECONDPROP : drifting macroalgae
MODEL : MacroAlgae
<endwqrate>

In the end a [[time series file]] with an '''*.BXM''' extension and with the name of the rate (set by keyword 'NAME'), is written.

[[Category:Modules]]
[[Category:MOHID Base 1]]
[[Category:Biogeochemistry]]

Dumpbin

2007-12-18T18:22:54Z

192.168.20.148: /* HowTo */

Dumpbin is a great little utility provided in Windows XP that allows to dump binary files and view their content. It is particularly usefule to see the symbolic table.
==HowTo==
From a dos box
>dumpbin /SYMBOLS file > file_dump.log
Where <code>file</code> is the filename. This will list the local functions as well as the externals.

> dumpbin /EXPORTS library > lib_dump.log
where <code>library</code> is a library filename. This will list the library's exported symbols.

[[Category:Technology]]
[[Category:Windows]]

Module Model

2007-12-02T16:10:13Z

192.168.20.148:

== Overview ==
Module Model handles all the information of a single model (in [[Mohid Water]]). It is responsible for constructing, modifying and destructing each model and for controlling information fluxes between the different modules, and time and mapping evolution.

== See also ==
[[Choose the model time step]]

== References ==

[[Category:Modules]]
[[Category:MOHID Water]]

Module Hydrodynamic

2007-12-02T16:06:14Z

192.168.20.148: /* Discharges */

== Overview ==
The hydrodynamic model solves the primitive continuity and momentum equations for the surface elevation and 3D velocity field for incompressible flows, in orthogonal horizontal coordinates and generic vertical coordinates, assuming hydrostatic equilibrium and Boussinesq approximations.

Density is computed depending on salt, temperature and pressure, by the UNESCO equation of state (UNESCO, 1981). The model uses an ADI (Alternate Direction Implicit) time discretization scheme which minimizes stability restrictions, and is defined in an Arakawa-C type grid.
In the bottom, shear stress can be computed with the assumption of a logarithmic velocity gradient:

In the free surface, a momentum flux can also be imposed in the form of shear stress.

Momentum, mass and heat transport is computed using a generic 3D advection-diffusion library including various advection schemes namely: first, second and third order upwind, centred differences and TVD (Total Variation Diminishing). Advection is solved in the three directions as a one-dimensional case and various time discretizations can be combined: explicit, semi-implicit or fully implicit.

== Concepts ==

== Mass and Momentum equations ==

=== Momentum advection ===

=== Turbulent Diffusion ===

=== Pressure ===

==== Barotropic ====

==== Baroclinic ====

==== Atmospheric ====

=== Coriolis ===

=== Radiation stresses ===

== Discretization ==

=== Temporal ===

=== Spatial ===

==== Horizontal ====

==== Vertical ====

== Boundary conditions ==

=== Bottom ===
In the bottom, advective fluxes are imposed as null and diffusive flux of momentum is estimated by means of a [[Module InterfaceSedimentWater#Momentum fluxes|bottom stress]] that is calculated by a non-slip method with a quadratic law that depends on the near-bottom velocity. So, the diffusive term at the bottom is written as:

<math>C_{D}</math> is the bottom drag coefficient that is calculated with the expression:

where <math>k</math> is von Karman constant and <math>z^{b}_{0}</math> is the bottom roughness length. This quadratic law is derived from the logarithmic law of the wall near boundaries characteristic of boundary layers, as the bottom velocities are located half a grid box above the bottom. This term is calculated semi-implicitly following Backhaus (1985) for numerical stability reasons.

=== Surface ===

==== Momentum ====
Diffusive flux of momentum is imposed explicitly by means of a [[wind surface stress]], <math> \tau_{ w}</math>:

==== Mass ====
A water flux can be imposed (e.g. precipitation or evaporation) or computed (e.g. evaporation) at the surface of the water column.

=== Open boundaries ===

[[Blumberg-Kantha radiation scheme]] for the open boundary conditions (Blumberg and Kantha, 1985).

=== Moving boundaries (Drying and flooding) ===
Moving boundaries are closed boundaries that change position in time. If there are intertidal zones in the domain, some points can be alternatively covered or uncovered depending on tidal elevation. A stable algorithm is required for modeling these zones and their effect on hydrodynamics of estuaries.

=== Land boundaries ===
In these boundaries the domain is limited by land. For the resolution used, this lateral boundary layer is resolved, so a impermeable, free slip condition can be used:

<math>\frac{{\partial \overrightarrow{{v_H }} }} {{\partial \eta }} = 0</math>

<math>\overrightarrow{v} \cdot \overrightarrow{n} = 0</math>

In the finite volume formalism, these conditions are implemented straightforwardly by specifying zero normal water fluxes and zero momentum diffusive fluxes at the cell faces in contact with land.

A non-slipling condition can also be used in lateral land boundaries.

=== Discharges ===
See [[Module Discharges]].

== Other features ==

=== Data assimilation ===
See [[Relaxation]] and [[Module Assimilation]].

== Outputs ==

=== Time series ===

=== Box integration ===

=== Maps (HDF5 format) ===
To write 3D results use keyword [[OUTPUT_TIME]] and define keyword:

OUTPUT_HDF : 1

in each property that you whish to write results.

To write results only in the surface use keyword [[SURFACE_OUTPUT_TIME]] and define keyword:

OUTPUT_SURFACE_HDF : 1

in each property that you which to write results. Surface results can be written with a different frequency than the normal 3D maps.

=== Statistics ===

== References ==

[[Category:Modules]]
[[Category:MOHID Water]]

Module AdvectionDiffusion

2007-12-02T16:03:49Z

192.168.20.148:

== Overview ==

== Advection ==

=== First order upwind ===

=== Second order upwind ===

=== Third order upwind ===

=== Total Variation Diminishing (TVD) ===

=== Central differences ===

== Diffusion ==

== Other remarks ==

[[Category:Modules]]
[[Category:MOHID Base 2]]

Module WaterProperties

2007-12-02T16:00:29Z

192.168.20.148: /* Discharges */

== Overview ==
Module WaterProperties is the 3D eulerian transport module included in MOHID. Module WaterProperties is responsible for computing the properties evolution in the water column. To do so, this module uses other modules, responsible for specific processes like [[Module AdvectionDiffusion]], which computes properties transport, or [[Module WaterQuality]] which is one of the three available modules to compute biogeochemical processes, and so on. MOHID is prepared to simulate properties such temperature, salinity, cohesive sediments, phytoplankton, nutrients, contaminants, etc. These properties can either be dissolved in the water, therefore following the currents, or in a particulate phase or adsorbed on to particulate matter, thus being subjected to one more transport variable: the settling velocity.

== Concepts ==

=== Property ===
See the list of allowed [[properties names]]

== Main processes ==

=== Advection Diffusion ===

=== Density ===
Water density can be computed in MOHID through a variety of equations of state, depending on salt, temperature and pressure.

*Leendertse
*UNESCO (default option)
*Linear
*Mellor 1996
*JMD
*Constant
*Wang

=== Settling velocity ===
[[Settling velocity]] is computed in [[Module FreeVerticalMovement]].

=== Bottom fluxes ===

=== Heat fluxes ===

=== Surface fluxes ===

=== Discharges ===
[[Module Discharges]]

=== Ecology and water quality ===

==== Water Quality ====
[[Module WaterQuality]]

==== CEQUALW2 ====
[[Module CEQUALW2]]

==== Life ====
[[Module Life ]]

==== Macroalgae ====
[[Module MacroAlgae ]]

==== First order decayment ====

==== Simple filtration ====

==== Contaminants/Partition coefficients ====

== Other features ==

=== Read solution from file ===
The solution of a given property can be imposed/read from a file. It can be constant or variable in time or/and space. This feature works under the [[Module FillMatrix]] capabilities.

=== Set minimum concentration ===

=== Data assimilation ===
See [[Relaxation]] and [[Module Assimilation]].

== Outputs ==

=== Time series ===

=== Box integration ===

=== Maps (HDF5 format) ===
To write 3D results use keyword [[OUTPUT_TIME]] and define keyword:

OUTPUT_HDF : 1

in each property that you whish to write results.

To write results only in the surface use keyword [[SURFACE_OUTPUT_TIME]] and define keyword:

OUTPUT_SURFACE_HDF : 1

in each property that you which to write results. Surface results can be written with a different frequency than the normal 3D maps.

=== Statistics ===

== References ==

[[Category:Modules]]
[[Category:MOHID Water]]

XYZ points

2007-12-02T14:43:09Z

192.168.20.148: /* XYZ Points file */

== Overview ==
XYZ points are use do define discrete geo-referenced information. This information is stored associating X and Y coordinates to an attribute. Examples of applications of these items are: bathymetric or topographic surveys, water quality analysis results, etc.

== XYZ Points file ==
XYZ Points items are stored in an ASCII text file. The default extension for XYZ Points files in [[MohidGIS]] is '''*.xyz'''. This file is organized in [[blocks]], each containing the coordinates for a certain attribute. One block is defined by the following keywords: '''<begin_xyz>''' and '''<end_xyz>'''. Note that these keywords are case sensitive. One file can contain an infinite number of blocks. Inside each block there at least 3 columns. The left column represents the XX coordinates of the polygon vertices and the right one to the YY coordinates of the polygon vertices. The third column contains the attribute value. A fourth column can be optionally included and it is handled as a character string which can also be used as a legend for each point.

== Example ==
=== Three columns ===

<begin_xyz>
-9.138328 38.737320 292.
<end_xyz>

=== Four columns ===

<begin_xyz>
-9.138328 38.737320 292. MARETEC - IST (Lisbon)
<end_xyz>

[[Category:Input Data Formats]]

Mohid Water

2007-11-29T17:11:37Z

192.168.20.148: /* Others */

== Overview ==
MOHID Water consists of a three-dimensional numerical model to simulate surface water bodies such as rivers, reservoirs, estuaries, coastal areas or the ocean. It is one of the main programs in [[MOHID Water Modelling System]], written in FORTRAN 95 using an [[Object oriented programming in MOHID|object oriented programming]] phylosophy. It is composed of a series of [[Modules#Mohid Water|modules]] built on top of [[Mohid Base 1]] and [[Mohid Base 2]].
These modules are mainly responsible for computing physical or biogeochemical process, e.g. [[Module Hydrodynamic]], [[Module WaterProperties]], [[Module Turbulence]], [[Module Lagrangian]], etc.

MOHID Water was designed in order to be able to simulate aquatic systems dividing them into three compartments or media: air, water and land. Thus it was constructed assuming: one model consisting of two main interfaces: the water-sediment interface and the water-air interface, dividing three well defined compartments, the atmosphere, the water column and the sediment. The two interfaces should be able to communicate by handling the fluxes between the three compartments. To do this, two modules were created: [[Module InterfaceSedimentWater]] and [[Module InterfaceWaterAir]].

Thus, the model was set up in a way that each of the three compartments did not have access to another compartment, being all communications made by the interface modules. That is, with this organization, [[Module SedimentProperties]] and [[Module Consolidation]] (representative of the sediment column), communicate only with [[Module InterfaceSedimentWater]], as well as modules Hydrodynamic, WaterProperties, Turbulence and Lagrangian (representative of the water column). These modules also communicate with [[Module InterfaceWaterAir]] which provides the connection with [[Module Atmosphere]]. [[Module Model]] controls and manages all the information fluxes.

== Physics ==
[[Mohid Water Physics]]

== Biogeochemistry ==
[[Mohid Water Biogeochemistry]]

== Other features ==
[[Parallel processing]]

== Support Tools ==
[[Mohid Water support tools]]

== Others ==
[[MohidWater|Mohid Water software]]

[[Modeling waterproperties transport|Modeling the water properties transport - a step by step methodology]]

[[Relaxation]] - using [[Module Assimilation]]

[[Nesting models]]

[[Category:MOHID Water]]

Choose the model time step (dt):

2007-11-29T16:44:43Z

192.168.20.148:

#redirect [[Choose the model time step]]

Choose the model time step

2007-11-29T16:44:07Z

192.168.20.148:

==Model_x.dat==
In the model_x.dat input file is defined the model time step
DT : 30

Modeling waterproperties transport

2007-11-29T16:43:30Z

192.168.20.148:

'''The steps that should be followed for modeling water properties transport are enumerated bellow.'''

Check the [[bathymetry]]:
1. See if there are channels "closed" by intertidal or land cells

2. Filter the bathymetry at least for the intertidal area
a. Create the [[Filter.dat]] input file
b. Run the [http://maretec.mohid.com/PublicData/products/Software/filterbathymetry.zip FilterBathymetry.exe] program

Use [[Module FillMatrix]] specifications to initialize all water properties.
It is critical to know all the initialization options available.

Verify the options to compute transport processes:

1. [[Advection numerical scheme]]

2. [[Diffusion values]]

3. [[Open Boundary conditions]]

4. [[Atmospheric boundary condition]]

5. [[Land boundary condition]]

6. For particulate properties:
a. [[Settling velocity]]
b. [[Bottom boundary condition]]

7. Delete all the keywords that you aren't using.
Too many keywords make it difficult to read the input files and
to find errors.

[[Choose the model time step]]

1. In a 2D case [[choose a semi-implicit approach]] to compute the horizontal transport.
In the 3D case, an explicit one must be chosen due to stability problems;

2. By default the vertical transport is always implicit (don't change);

3. Identify in the horizontal grid the minimal horizontal spatial step (dx);

4. Identify an order of magnitude for the maximum velocity (Vel);

5. When the horizontal transport is computed explicitly, a first good approach is to
consider the Courant number(Cr) equal to 1:
<math>Cr=Vel*dt/dx</math>

6. For the 2D case, with a semi-implicit approach, a higher Courant number can be tested;

7. In reality the Courant is a concept that works well in schematic tests in channels with
constant depth and velocity. In this case, an explicit upwind discretization of the
advection term of a property P becomes, for a velocity greather than zero:
<math>P(i,t+dt)= P(i,t)*(1-Cr) + P(i-1,t)*Cr</math>

8. For real model applications, the Courant number based in the velocity is simplistic and
misleading. In reality the Courant number, in a conservative upwind discretization
of the advection term, is computed based in flows (Q) and volumes (V) in the 1D case is:
<math>Cr = Q outflow * dt / V </math>

Common errors
'''1. Type of errors''': Pontual instabilities in the mass balance
can occour usually in the wetting and drying process. These instabilities can have
several degrees. These degrees are enumerated in a descending order:
a) The most serious : the model crash in the transport of a conservative property
like salinity;
b) The model crash in computing the temperatura transport when the heat fluxes with
the atmosphere are computed;
c) The model crash when simulates properties with a settling velocity;
d) The model is able to compute the evolution of temperature (with heat fluxes)
and salinity but still persist some small instabilities that originate
i) wrong values of oxygen saturation and consequently wrong oxygen fluxes with the
atmosphere and the oxygen transport crash;
ii) Wrong biochemical rates that depend in the temperature and the transport
biochemical properties crash.

'''2. Possible solutions''':
a) Filter the bathymetry. A steep bathymetry means drastic variations between
adjacent controle volumes and this way are created the conditions to occour
high courant numbers. This is dramatic in intertidal areas because very easily
in the wetting and drying process adjacent controle volume can have volume relations
of several orders of magnitude;
b) Decrease the time step;
c) Use the magic but very dangerous keywords 'MIN_VALUE' and 'MAX_VALUE' for each
property. In extreme cases you need to guarantee that all properties > 0
(MIN_VALE : 0.). The upper limitation (MAX_VALUE) is only needed in the salinity
and temperature. These two properties are critical because there are a lot
of rates that depend on this two properties. These magic keywords are dangerous
because when the model correct the field properties so there is any value < MIN_VALUE
and > MAX_VALUE the model generate mass in the first case and destroys in the second.
After each run is necessary to verify in the '''WaterProperties_x.fin5''' hdf5 file the
mass_created and the mass_destroyed matrixes and verify the total mass created and
destroyed in the run. Be carefull in your analysis the values are
in Property x Volume.

[[Category:MOHID Water]]

Bottom boundary condition;

2007-11-29T16:43:00Z

192.168.20.148:

#redirect [[Bottom boundary condition]]

Bottom boundary condition

2007-11-29T16:42:40Z

192.168.20.148:

For each water property the user needs to define if it wants or not to impose sediment-water fluxes of particulate or dissolved matter. An example of a input file InterfaceWaterAir_x.dat where bottom boundary condition is defined is presented below.

==WaterProperties_x.dat==
For each property is possible to impose a bottom boundary
condition. By default no bottom boundary condition is imposed (BOTTOM_FLUXES : 0).
<beginproperty>
BOTTOM_FLUXES : 1
<endproperty>
==InterfaceSedimentWater_x.dat==
Bottom absolute rugosity in meters
<begin_rugosity>
DEFAULTVALUE : 0.0025
<end_rugosity>
Critical shear stress erosion in Pa
<begin_critical_shear_erosion>
INITIALIZATION_METHOD : CONSTANT
DEFAULTVALUE : 0.4
<end_critical_shear_erosion>
Critical shear stress deposition in Pa
<begin_critical_shear_deposition>
INITIALIZATION_METHOD : CONSTANT
DEFAULTVALUE : 0.2
<end_critical_shear_deposition>
Erosion rate in kg/m2/s
<begin_erosion_rate>
INITIALIZATION_METHOD : CONSTANT
DEFAULTVALUE : 0.00005
<end_erosion_rate>
Definition of the bottom boundary of the particulate property cohesive sediment
<beginproperty>
NAME : cohesive sediment
UNITS : kg/m2
DESCRIPTION : cohesive sediment mass
OLD : 1
PARTICULATE : 1
WATER_FLUXES : 1
EROSION : 1
DEPOSITION : 1
MASS_LIMITATION : 1
MASS_MIN : 1e-8
MIN_VALUE : 1e-4
FILE_IN_TIME : NONE
INITIALIZATION_METHOD : ASCII_FILE
FILENAME : ..\..\GeneralData\BottomSed\BottomSed.dat
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.01
TIME_SERIE : 0
BOX_TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>

[[Category:MOHID Water]]

Settling velocity;

2007-11-29T16:42:05Z

192.168.20.148:

#redirect [[Settling velocity]]

Settling velocity

2007-11-29T16:41:40Z

192.168.20.148:

The FreeVerticalMovement is used to add to the vertical flow a vertical
movement. Presently the module is prepared to impose a constant settling velocity
or a settling velocity function of salinity concentration and fine sediments concentration.
In the future other types of vertical movement will be computed like phytoplankton
up and down movements to optimize the nutrients uptake and/or to reduce mortality due to grazing.

== WaterProperties_x.dat==
For each particulate property it's possible to define a settling velocity
condition. By default no settling velocity is assumed.
<beginproperty>
VERTICAL_MOVEMENT : 1
<endproperty>
== FreeVerticalMovement_x.dat==
An example presented below defines for the cohesive sediment property a constant
settling velocity of 1e-5 m/s or 0.01 mm/s. For salinities below 3 psu the settling
velocity is zero. The advection transport associated with settling is computed implicitly.
<beginproperty>
NAME : cohesive sediment
WS_TYPE : 1
SALTINT : 1
SALTINTVALUE : 3
FREEVERT_IMPEXP_ADV : 0
WS_VALUE : 1e-5
DEPOSITION : 1
<endproperty>

Land boundary condition.

2007-11-29T16:40:50Z

192.168.20.148:

#redirect [[Land boundary condition]]

Land boundary condition

2007-11-29T16:40:27Z

192.168.20.148:

The land boundary presently in the MOHID system is imposed in the form
of water and mass fluxes.

== Hydrodynamic_x.dat==
In the hydrodynamic input data it's necessary to turn on the water discharge option. By default no water discharge is imposed (WATER_DISCHARGES : 0).
WATER_DISCHARGES : 1
== WaterProperties_x.dat==
For each property is possible to impose a mass discharge. By default no mass discharge is imposed (DISCHARGES : 0).
<beginproperty>
DISCHARGES : 1
<endproperty>
== Discharges_x.dat ==
Here's an example on how to define a river discharge. More than one river discharges can
be defined. For each discharge corresponds a <begindischarge> / <enddischarge> block.
<begindischarge>
NAME : Quilombo
DESCRIPTION : Discharge of Quilombo River (É necessário confirmar a localização)
I_CELL : 142
J_CELL : 92
K_CELL : 1
ALTERNATIVE_LOCATIONS : 0
DATA_BASE_FILE : ..\..\GeneralData\Discharges\Quilombo.txt
FLOW_COLUMN : 2
<<beginproperty>>
NAME : salinity
UNITS : psu
DESCRIPTION : salinity in santos
DEFAULTVALUE : 0.5
<<endproperty>>
<<beginproperty>>
NAME : cohesive sediment
UNITS : mg/l
DESCRIPTION : Coehsive Sediment discharge from Quilombo river
TIME_SERIE_COLUMN : 3
<<endproperty>>
<<beginproperty>>
NAME : temperature
UNITS : mg/l
DESCRIPTION : temperature discharge
TIME_SERIE_COLUMN : 4
<<endproperty>>
<enddischarge>

Atmospheric boundary condition.

2007-11-29T16:39:42Z

192.168.20.148:

#redirect [[Atmospheric boundary condition]]

Atmospheric boundary condition

2007-11-29T16:39:24Z

192.168.20.148:

For each water property the user needs to define if it want or not to impose atmospheric fluxes.
Here's an example of atmospheric properties that need to be defined -if the user
wants to compute heat fluxes with standard bulk formulas-. The atmospheric properties
are defined in the Atmospheric_x.dat input file. The heat (bulk formulas), mass and
momentum fluxes are defined in the InterfaceWaterAir_x.dat. The example of an input
file InterfaceWaterAir_x.dat is presented below.

== WaterProperties_x.dat==
For each property it's possible to impose an atmospheric (or surface) boundary
condition. By default no atmospheric boundary condition is imposed (SURFACE_FLUXES : 0).
<beginproperty>
SURFACE_FLUXES : 1
<endproperty>

== Atmospheric_x.dat==
It's important to have the output of the atmospheric properties fields so the user
can confirm what is being imposed
OUTPUT_TIME : 0. 86400
Wind zonal velocity
<beginproperty>
NAME : wind velocity X
UNITS : m/s
DESCRIPTION : wind velocity X
DEFAULTVALUE : 0.
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Wind meridional velocity
<beginproperty>
NAME : wind velocity Y
UNITS : m/s
DESCRIPTION : wind velocity Y
DEFAULTVALUE : 0.
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
OUTPUT_HDF : 1
<endproperty>
Atmospheric pressure
<beginproperty>
NAME : atmospheric pressure
UNITS : Pa
DESCRIPTION : NOAA reanalysis atmospheric pressure at sea level
DEFAULTVALUE : 0.
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
OUTPUT_HDF : 1
<endproperty>
Solar radiation
<beginproperty>
NAME : solar radiation
UNITS : W/m^2
DESCRIPTION : meteoIST Solar Radiation
ALBEDO : 0.05 ![%]
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
DEFAULTVALUE : 0.0
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Air temperature
<beginproperty>
NAME : air temperature
UNITS : ºC
DESCRIPTION : Temperature
DEFAULTVALUE : 0.
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Relative humidity
<beginproperty>
NAME : relative humidity
UNITS : fraction
DESCRIPTION : Humidity
DEFAULTVALUE : 0.
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Cloud cover
<beginproperty>
NAME : cloud cover
UNITS : fraction
DESCRIPTION : cloud cover
DEFAULTVALUE : 0.
FILE_IN_TIME : NONE
!FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>

== InterfaceWaterAir_x.dat==
Zonal wind stress
<beginproperty>
NAME : wind stress X
UNITS : N/m2
DESCRIPTION : calculated wind stress X
DEFAULTVALUE : 0
REMAIN_CONSTANT : 0
TYPE_ZUV : z
OUTPUT_HDF : 1
TIME_SERIE : 0
<endproperty>
Meridional wind stress
<beginproperty>
NAME : wind stress Y
UNITS : N/m2
DESCRIPTION : calculated wind stress Y
DEFAULTVALUE : 0
TYPE_ZUV : z
REMAIN_CONSTANT : 0
OUTPUT_HDF : 1
TIME_SERIE : 0
<endproperty>
Latent heat
<beginproperty>
NAME : latent heat
UNITS : W/m^2
DESCRIPTION : Calculated latent heat
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Sensible heat
<beginproperty>
NAME : sensible heat
UNITS : W/m^2
DESCRIPTION : Calculated sensible heat
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Solar radiation at sea level
<beginproperty>
NAME : surface radiation
UNITS : W/m^2
DESCRIPTION : Calculated infrared radiation
ALBEDO : 0.05 ![%]
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Net long wave radiation = (downward - upward) long wave radiation
<beginproperty>
NAME : net long wave radiation
UNITS : W/m^2
DESCRIPTION : Calculated net long wave radiation
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Downward long wave radiation
<beginproperty>
NAME : downward long wave radiation
UNITS : W/m^2
DESCRIPTION : Calculated downward long wave radiation
FILE_IN_TIME : HDF
FILENAME : D:\Aplica\AguasAlgarve\DadosBase\MM5\AlgarveCoast\MM5Out_D3D2_July2004.hdf5
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Upward long wave radiation
<beginproperty>
NAME : upward long wave radiation
UNITS : W/m^2
DESCRIPTION : Calculated upward long wave radiation
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>
Non solar flux = Net long wave radiation + Latent + Sensible
<beginproperty>
NAME : non solar flux
UNITS : W/m^2
DESCRIPTION : Calculated infrared radiation
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 0
DEFAULTVALUE : 0.
TIME_SERIE : 0
OUTPUT_HDF : 1
<endproperty>

[[Category:MOHID Water]]

Open Boundary conditions;

2007-11-29T16:38:51Z

192.168.20.148:

#redirect [[Open Boundary conditions]]

Open Boundary conditions

2007-11-29T16:38:17Z

192.168.20.148:

== WaterProperties_x.dat==

For each property it's possible to define a specific boundary condition.
The available options are:

1 - 1D horizontal mass balance normal to the boundary

2 - An imposed value

3 - 1D vertical diffusion is added to option 1

4 - Null gradient

5 - SubModel, a value interpolated directly from the father is imposed

6 - Orlanski type boundary condition

8 - Cyclic boundary condition

By default, option 1 is assumed.

<beginproperty>
BOUNDARY_CONDITION : 1
<endproperty>

By default the value assumed for the boundary is the one assumed in the intialization
process of the property field (INTERIOR) the user can also specify a value for the
boundary (EXTERIOR)

<beginproperty>
BOUNDARY_INITIALIZATION : EXTERIOR
DEFAULTBOUNDARY : 0.
<endproperty>

[[Category:MOHID Water]]

Diffusion values;

2007-11-29T16:37:37Z

192.168.20.148:

#redirect [[Diffusion values]]

Diffusion values

2007-11-29T16:35:54Z

192.168.20.148:

By default the horizontal turbulent viscosity is assumed equal to the horizontal
turbulent diffusion (or diffusivity). In the vertical, the same is assumed except
if the turbulent model (GOTM) option is on.

== Turbulence_x.dat ==

By default it is assume a constant turbulent horizontal viscosity (m2/s)

VISCOSITY_H : 10

By default it is assume a constant turbulent vertical viscosity (m2/s)

VISCOSITY_V : 1e-3

The user can activate the turbulence model (GOTM package). In this case the
user must look to the turbulence module output results to see the fields of
vertical turbulent viscosity and diffusivity.

MODTURB : turbulence_equation

[[Category:MOHID Water]]

Advection numerical scheme;

2007-11-29T16:35:03Z

192.168.20.148:

#redirect [[Advection numerical scheme]]

Advection numerical scheme

2007-11-29T16:33:49Z

192.168.20.148:

== WaterProperties_x.dat ==

1 - First order upwind is the more robust but the less precise;

2 - Second order upwind has good precision but is highly unstable;

3 - Third order upwind has excellent precision, more or less stable and not;

4 - The Transport Variation Diminishing method(TVD) is in fact a hydrid scheme between a first order and a third order method where a ponderation factor is computed so the method is able to insure positiveness. The method 4 is advised for experienced users. By default the method is 1 to increase robustness of the runs.

5 - Central differences has good precision but is highly unstable

Horizontal keyword option

ADV_METHOD_H : 4

Vertical keyword option

ADV_METHOD_V : 4

There are several methodologies to compute the TVD ponderation factor. MinMod = 1, VanLeer = 2, Muscl = 3, Superbee = 4, PDM = 5. By default the option admitted is SuperBee.

Horizontal keyword option

TVD_LIMIT_H : 4

Vertical keyword option

TVD_LIMIT_V : 4

[[Category:MOHID Water]]

Nesting models

2007-11-29T16:05:24Z

192.168.20.148:

Here is a guide on configuring [[MOHID Water]] with nested models.

==In MOHID GUI==
*Create a new project in [[MOHID GUI]],
*Create a Model by inserting a new Simulation,
**Setup your model
*Create a Submodel by inserting a new Simulation from the current Simulation. The new simulation should fold into the previous one.
**Setup the model

==Setting up the files==
The whole issue is how to define the open-boundary conditions for the submodel.
Basically we suggest to use a [[Flather radiation condition]] at the open boundaries that will radiate the water level and the barotropic flux in conjunction with a flow relaxation scheme spanning a few cells from the open-boundaries to the interior for the velocities (''u'' and ''v'').

===Keywords in Hydrodynamic.dat===
In the submodel hydrodynamic file

SUBMODEL : 1

!Flather radiation scheme using the father model as a reference solution.
RADIATION : 2
LOCAL_SOLUTION : 2

!Activate the Flow relaxation scheme
DATA_ASSIMILATION : 1

===Keywords in Assimilation.dat===
In the submodel assimilation file

<beginproperty>
NAME : velocity U
UNITS : m/s
DIMENSION : 3D
OUTPUT_HDF : 1

COLD_RELAX_PERIOD : 432000
COLD_ORDER : 5

<<begin_field>>
DEFAULTVALUE : 0
INITIALIZATION_METHOD : HDF
FILE_IN_TIME : HDF
FILENAME : ../../GeneralData/Reference_vel_U.hdf5
TYPE_ZUV : z
<<end_field>>

<<begin_coef>>
DEFAULTVALUE : 1e9
TYPE_ZUV : u
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 1
INITIALIZATION_METHOD : ASCII_FILE
FILENAME : ../../GeneralData/RelaxationCoefs_U.dat

<<end_coef>>

<endproperty>

<beginproperty>
NAME : velocity V
UNITS : m/s
DIMENSION : 3D
OUTPUT_HDF : 1

COLD_RELAX_PERIOD : 432000
COLD_ORDER : 5

<<begin_field>>
DEFAULTVALUE : 0
INITIALIZATION_METHOD : HDF
FILE_IN_TIME : HDF
FILENAME : ../../GeneralData/Reference_vel_V.hdf5
TYPE_ZUV : z
<<end_field>>

<<begin_coef>>
DEFAULTVALUE : 1e9
TYPE_ZUV : v
FILE_IN_TIME : NONE
REMAIN_CONSTANT : 1
INITIALIZATION_METHOD : ASCII_FILE
FILENAME : ../../GeneralData/RelaxationCoefs_V.dat

<<end_coef>>

<endproperty>

Residual

2007-08-09T10:36:43Z

192.168.20.148:

MohidWater may calculate time averages on certain hydrodynamic parameters at the end of each run.
The variables whose time averages are calculated are the '''Velocity''', '''Flux''', '''FluxVel''' and the '''Waterlevel''' and they appear in the hdf5 file under the group ''/Residual''.
In particular the residual flux is the mean between the cell's faces of the time averaged face flux divided by the face width.

== Definitions ==

*'''Velocity''' - time averaged velocity during the period of the simulation
*'''Flux''' - time averaged specific flow in m2/s which is the flow in m3/s divided by the width in meters of the grid cell) during the period of the simulation
*'''FluxVel''' - time averaged specific flow divided by the average grid cell thickness in m/s which is the specific flow (m2/s) divided by the average thickness of the grid cell in meters during the period of the simulation
*'''Waterlevel''' - time averaged water elevation during the period of the simulation

== Setup ==
Simply turn on the residual option in the ''Hydrodynamic.dat'' file:
RESIDUAL : 1

== Formulas ==

<math>/Residual/Flux/X = \frac{\left( \overline{U\;AreaU} / DYY \right)^{+1/2} + \left( \overline{U\;AreaU} / DYY \right)^{-1/2}}{2}</math>

<math>/Residual/FluxVel/X = \frac{\left( \overline{U\;AreaU} / DYY \right)^{+1/2} + \left( \overline{U\;AreaU} / DYY \right)^{-1/2}}{2}/\overline{DWZ}^{-1/2}</math>

Compiling with CVF

2007-07-27T15:09:55Z

192.168.20.148: /* Optional compilation settings */

Please follow these instructions step by step and until the end:

== Creating a new project ==
#Make sure you have installed in your computer Microsoft Visual Studio 6.0 (Compaq Visual Fortran 6 Developer Studio) and Compaq Visual Fortran 6.6c. If you don’t have both installed, please install them.
#Get your HDF5 libraries (*.libs) and modules (*.mod) files from Source Safe (folder named "\Libs").
#Open the Compaq Visual Fortran 6 Developer Studio.
#Select "File... New".
#Select the Projects tab.
#Create a '''Fortran Console Application'''. Name it "MohidWater" for example, and define a path to the folder where you want to place the project. Click OK.
#Get all FORTRAN code files from SourceSafe and add them to the project. Right-click in the Source Files folder (in the project tree), and select "Add Files To Folder...". Add all the files containing the [[modules]]. For example, to compile MohidWater, add all files in folders Mohid_Base_1, Mohid_Base_2 and MohidWater. Other projects may need modules from Mohid_Base_1, Mohid_Base_2.
#Note that the files '''mpif.f90''', '''GOTMVariables_in.f90''' and '''GOTMVariables_out.f90''' are '''NOT''' to be included in the project. These files are '''INCLUDE''' files which means they must be placed in the same folder as the rest of source code files.

== Release settings ==
Please follow the steps below and set them EXACTLY as they are presented. Do not make additional changes in the settings unless you’re testing some optimizations. Note that settings under "Debug" and "Release" configurations are slightly different. Please select "Release" configuration and apply this settings first.

#Select "Project...Settings"
#Select the "Fortran" tab
#Select "Compilation Diagnostics" in the dropdown box
#Check '''ALL''' the check boxes ("Argument Mismatch", "Data Alignment", etc)
#Set the "Fortran Standards Checking" to '''"Fortran 95"'''
#Select "Floating Point" in the dropdown box
#Set "Floating Point Exception Handling" to '''"3*"'''. NOTE: This will enable your executable to create and work with NaN. If you set the value to '''"0"''' the program will stop when NaN are created, but it will run slower.
#Select "PreProcessor" in the dropdown box
#Write the path to the HDF5 libraries in "INCLUDE and USE Paths" text box
#Check "Use FPP" check box
#Select the "Link" tab
#For the "General" and "Input" items in the "Category" dropdown box, add the following line in the “Object/library modules” text box:
'''kernel32.lib hdf5.lib hdf5_hl.lib hdf5_fortran.lib zlib.lib szlib.lib'''

== Debug settings ==
Use the default settings for a "Debug" application and perform the same steps as for the "Release" configuration, except in the following step:
# Select "Project...Settings...Fortran"
# Select "Floating Point" in the dropdown box
# Set "Floating Point Exception Handling" to '''"0"'''.

== Build ==
#Select "Build...Build [name of the executable]"

== Optional compilation settings ==
To perform optional compilation, just add the compilation pre-processor keywords in "Project...Settings...Fortran...PreProcessor", in the "Predefined Preprocessor Symbols" text box.

=== Exclude modules ===
Some modules can be completely excluded from compilation. If your simulations do not use these modules you can use this pre-processor keywords.

'''_LAGRANGIAN_''' excludes Modules Lagrangian + Jet + Oil
'''_AIR_''' excludes Modules InterfaceWaterAir + Atmosphere
'''_WAVES_''' excludes Module Waves
'''_SEDIMENT_''' excludes Modules SedimentProperties + Consolidation

=== Compile with MPI ===
In order to [[Compiling Mohid with MPI|compile Mohid with MPI]] you must include the following pre-processor keyword. See more on [[Compiling Mohid with MPI]]
'''_USE_MPI''' includes MPI code

=== Compile with OpenMP ===
See more on [[Compiling Mohid with OpenMP]].

=== Other options ===
Other keywords can also be used.

'''_SHORT_LINE_LENGTH''' sets line_length = 64 (default line_length is 256)
'''_LONG_LINE_LENGTH''' sets line_length = 1024(default line_length is 256)
'''_GUI_''' includes GUI code

== Stack reserve settings ==
This option enables you to reserve more RAM to your executable which is useful when running "heavy" simulations. You can normally find out you need this if you get an error in your simulation process saying '''"stack overflow"'''. To do this follow these steps:
#Select "Project...Settings"
#Select the "Link" tab
#Select "Output" in the "Category" dropdown box
#In the "Stack allocations" area, define e.g. '''64000000'''(or more) in the "Reserve" text box.

== Additional Developer Studio settings ==
#Select "Tools...Options"
#Select "Tabs" tab
#Select "Fortran" in the dropdown box
#Select "Insert spaces" radio button

[[Category:Programming]]
[[Category:Compiling]]

Compiling

2007-07-27T15:08:55Z

192.168.20.148: /* Compiling in Windows */

Mohid can be compiled using different compilers under different operative systems.

== Compiling in Windows ==
Currently, the Mohid developing team is working with two different FORTRAN 95 compilers:
#Compaq Visual Fortran 6.6c (CVF)
#Intel Fortran Compiler 9.0(IFC).

See more on [[compiling with CVF|compiling with Compaq Visual Fortran 6.6c ]] and [[compiling with IFC|Intel Fortran Compiler 9.0 or higher]].

A [[makefile]] can also be used to compile Mohid in Windows.

== Compiling in [[*NIX platforms]] ==
Use a [[*NIX platforms|makefile]].

Here are specific instructions to [[Compile MohidWater for Debian Linux|compile MOHID Water for Debian Linux]].

[[Category:Programming]]

[[Category:Compiling]]

Current events

2007-07-02T15:40:11Z

192.168.20.148:

Properties names

2007-07-02T15:38:36Z

192.168.20.148:

*temperature
*salinity
*density
*phytoplankton
*zooplankton
*dissolved refractory organic phosphorus
*dissolved non-refractory organic phosphorus
*dissolved refractory organic nitrogen
*dissolved non-refractory organic nitrogen
*inorganic phosphorus
*particulate organic carbon
*particulate organic phosphorus
*particulate organic nitrogen
*labile dissolved organic carbon
*labile dissolved organic phosphorus
*labile dissolved organic nitrogen
*semi-labile dissolved organic carbon
*semi-labile dissolved organic phosphorus
*semi-labile dissolved organic nitrogen
*ammonia
*nitrate
*silicate acid
*biogenic silica
*carbon dioxide
*oxygen
*dissolved oxygen percent saturation
*diatoms carbon
*diatoms nitrogen
*diatoms phosphorus
*diatoms silica
*diatoms chlorophyll
*autotrophic flagellates carbon
*autotrophic flagellates nitrogen
*autotrophic flagellates phosphorus
*autotrophic flagellates chlorophyll
*picoalgae carbon
*picoalgae nitrogen
*picoalgae phosphorus
*picoalgae chlorophyll
*flagellates carbon
*flagellates nitrogen
*flagellates phosphorus
*flagellates chlorophyll
*microzooplankton carbon
*microzooplankton nitrogen
*microzooplankton phosphorus
*heterotrophic nanoflagellate carbon
*heterotrophic nanoflagellate nitrogen
*heterotrophic nanoflagellate phosphorus
*mesozooplankton carbon
*mesozooplankton nitrogen
*mesozooplankton phosphorus
*heterotrophic bacteria carbon
*heterotrophic bacteria nitrogen
*heterotrophic bacteria phosphorus
*nitrite
*biochemical oxygen demand
*cohesive sediment
*fecal coliforms
*escherichia coli
*T90
*oil
*ciliate
*bacteria
*particulate arsenic
*dissolved arsenic
*larvae
*age
*fish
*fish food
*macroalgae
*drifting macroalgae
*microphytobenthos
*particulated ammonia
*particulated refractory organic nitrogen
*nitrogen gas
*heterotrophic microorganism nitrogen
*anaerobic microorganism nitrogen
*autotrophic microorganism nitrogen
*anaerobic microorganism carbon
*autotrophic microorganism carbon
*heterotrophic microorganism carbon
*particulate labile organic carbon
*particulated refractory organic carbon
*generic property
*grossprod
*netprod
*nutrientlim
*nitrogenlim
*phosphoruslim
*lightlim
*temperaturelim
*salinitylim
*diagrossprod
*dianutrientlim
*dianitrogenlim
*diaphosphoruslim
*diasilicalim
*dialightlim
*diatemperaturelim
*diatoms
*water level
*velocity modulus
*velocity direction
*flow modulus
*velocity U
*velocity V
*velocity W
*water flux X
*water flux Y
*coriolis X
*baroclinic force X
*horizontal transport X
*coriolis Y
*baroclinic force Y
*horizontal transport Y
*barotropic velocity U
*barotropic velocity V
*water level analyzed for altimetry
*temperature analyzed for altimetry
*salinity analyzed for altimetry
*water level for altimetry assimilation
*variance field for assimilation
*baroclinic velocity U
*baroclinic velocity V
*obstacle drag coefficient
*vorticity
*baroclinic KE
*Perturbation Potential Energy
*Kinetic Energy
*shear velocity
*vertical z
*particulate contaminant
*dissolved contaminant
*sediment
*dissolved sodium
*dissolved calcium
*particulate sodium
*particulate calcium
*latent heat
*sensible heat
*evaporation
*net long wave radiation
*upward long wave radiation
*downward long wave radiation
*short wave solar radiation
*long wave solar radiation
*short wave solar radiation extinction
*long wave solar radiation extinction
*oxygen flux
*wind shear velocity
*surface radiation
*wind stress X
*wind stress Y
*surface water flux
*non solar flux
*turbulent kinetic energy
*carbon dioxide flux
*albedo
*wind velocity X
*wind velocity Y
*solar radiation
*precipitation
*atmospheric pressure
*air temperature
*relative humidity
*wind modulos
*wind angle
*cloud cover
*irrigation
*sunshine hours
*atmospheric transmitivity
*mean sea level pressure
*wind modulus
*wind direction
*refractory particulate organic matter
*labile particulate organic matter
*labile dissolved organic matter
*refractory dissolved organic matter
*particulate silica
*dissolved silica
*inorganic carbon
*pH
*bicarbonate
*carbonate
*algae_1
*algae_2
*algae_3
*algae_4
*algae_5
*epiphyton_1
*epiphyton_2
*epiphyton_3
*epiphyton_4
*epiphyton_5
*alkalinity
*detritus
*ANLIM
*APLIM
*ASLIM
*ALIGHTLIM
*AOVERALLLIM
*ENLIM
*EPLIM
*ESLIM
*ELIGHTLIM
*EOVERALLLIM
*NH4D
*NO3D
*LDOMD
*RDOMD
*LPOMD
*RPOMD
*LRDOMD
*LRPOMD
*CBODD
*PO4ER
*PO4EG
*PO4AR
*PO4AG
*PO4OM
*PO4BOD
*NH4ER
*NH4EG
*NH4AR
*NH4AG
*NH4OM
*NH4BOD
*NO3AG
*NO3EG
*DSIAG
*DSIEG
*DSID
*PSIAM
*PSID
*LDOMAP
*LDOMEP
*LPOMAP
*DOAP
*DOEP
*DOAR
*DOER
*DOOM
*DONIT
*ICARBONAP
*ICARBONEP
*ICARBONBOD
*sand diameter
*sand percentage
*D35
*D50
*D90
*bed rock
*sand tau critic
*sand
*transport capacity
*transport capacity X
*transport capacity Y
*bottom evolution
*new bathymetry
*wave stress X
*wave stress Y
*Current X
*Current Y
*wave amplitude
*wave period
*wave direction
*significant wave height
*mean wave length
*mean wave period
*mean wave direction
*mean directional spread
*peak frequency
*peak direction
*wind sea peak frequency
*wind sea peak direction
*consolidation flux
*porosity
*shear stress
*reference evapotranspiration
*TSS
*cohesive sediment fine
*cohesive sediment medium
*cohesive sediment coarse

Module GlobalData

2007-07-02T15:36:30Z

192.168.20.148:

== Overview ==
Module GlobalData, is responsible for global variables such as [[properties names]] and ID numbers, error types ID, constants and parameters, classes registration numbers and some derived types used frequently in other classes (e.g. type T_Size, a derived type containing the matrixes bounds).

This is mainly static information needed and used equally by all classes. Some methods are also provided by this class, mainly related to checking properties names spelling and attributing ID numbers. It also handles error and used keywords logging and I/O units.

== Sub-routines ==

=== Internal names ===
*CheckPropertyName
*GetPropertyName
*GetPropertyIDNumber
*Check_Particulate_Property
*TranslateTypeZUV

=== I/O management ===
*UnitsManager

=== Errors and logs management ===
*SetError
*WriteErrorMessage
*LogKeyWord

=== Start/End management ===
*StartupMohid
*ShutdownMohid

=== Object oriented management routines ===

*RegisterNewInstance
*AssociateInstance
*DeassociateInstance
*RegisterModule
*ModuleIsRegistered
*Read_Lock
*Read_Unlock
*VerifyReadLock

[[Category:Modules]]
[[Category:MOHID Base 1]]

Changing the code

2007-06-15T14:15:59Z

192.168.20.148:

Mohid's source code is stored in a data base running under MS Source Safe 6.0.
If you are about to change code from MOHID always:
<blockquote style="background: white; border: 1px blue; padding: 1em;">
*'''keep in mind that you are not the only one who works with Mohid;'''
*'''don’t keep a file checked-out for a long time;'''
*'''keep in mind that the model should be easily usable;'''
</blockquote>

== Check list before making any changes ==
<blockquote style="background: white; border: 1px blue; padding: 1em;">
*Get the latest version of all the source files;
*Check-out the files which you are going to change;
*Proceed with the changes of the source code; Note that if you want to change a file and it is checked out you cannot proceed with the changes;
</blockquote>

== Check list before checking in a module ==
If you have made your changes in a source code file and believe they are finished, walk through this check list before checking in the source code file(s) you have edited.

<blockquote style="background: white; border: 1px blue; padding: 1em;">
*Get the latest version of all files from source safe except the ones that are checked out by you. Note that if a module is checked out by another user you must also get the latest version;
*Compile all the code;
*Verify that code compiles with zero warnings, zero info and zero errors.
*Verify that the code must compile either on single precision and double precision.
*Check-in the file(s)
</blockquote>

[[Category:Programming]]

HDF5 file

2007-06-01T10:07:36Z

192.168.20.148:

#redirect [[HDF file]]

Blocks

2007-05-31T17:40:23Z

192.168.20.148: /* Related links */

== Overview ==
Another way of defining options in a MOHID input data file is, as referred above, by using information blocks. These blocks are normally used so that advanced options can be defined through the combination of groups of keywords.

== Block definition ==
[[Image:block1.jpg|350px|thumb|right|'''Structure of a block''']]
Each block of information is delimited by a '''''begin block tag''''' and an '''''end block tag''''', each written in a different line. The '''''begin block''''' and '''''end block''''' tags are normally written between the following symbols '''<''' and '''>''' (e.g. <beginproperty> and “<endproperty>”).

== Reading procedure ==

[[Image:block2.jpg|350px|thumb|right|'''Reading procedure of a block''']]
The reading procedure is similar to the [[keywords]], but this time the 2 tags must be successfully found in order to define a block, identifying the line numbers where the block begins and ends. This allows a regular [[keyword]] search algorithm to work only between the 2 tags. A block can also be defined inside another block, therefore creating a hierarchical structure, in where up to three levels are allowed.

== Related links ==
*[http://www.mohid.com/IHS Mohid Keywords Online DataBase]
*[[Keywords]]
*[[New_Keyword]]
*[[Module EnterData]]

[[Category:Input Data Formats]]
[[Category:keywords]]

Actual state

2007-05-31T14:19:52Z

192.168.20.148:

Mohid Water Modelling System is organized in a hierarchical modular structure being, at the present time, constituted by over 60 [[modules]] which complete around 300000 source code lines. Each module is responsible to manage a certain kind of information handling a specific function or process. The information flux between modules is made in a client/server basis, assuring the information encapsulation in each module. Each module manages his associated memory, which is dynamically allocated.

In order to convert, programmatically, environmental systems into a numerical model, an analysis of processes included in the model and the environmental compartments in which they take place, had to be conducted. Environmental systems are assumed to be divided into three compartments or media: air, water and land. This was the approach followed to reach the actual structure of Mohid leading to six functional groups of modules:
<blockquote style="background: white; border: 1px blue; padding: 1em;">
*'''Global parameters modules''' – modules which handle global parameters like recognized property lists, time handling and functions, etc (e.g. [[Module GlobalData]], [[Module Time]]);
*'''Independent functions modules''' – modules that handle specific operations (e.g. [[Module Functions]] – various mathematical or scientific functions, [[Module Triangulation]] – performs advanced triangulation, [[Module LUD]] – equations systems solver);
*'''Structural modules''' - modules that handle geometry domain discretization, transformation and referentials, using variables like distances, areas, volumes, compute points, etc. (e.g. [[Module HorizontalGrid]] – handles the horizontal discretization, [[Module HorizontalMap]] – handles 2D horizontal mapping of grid cells like covered and uncovered cells, [[Module Map]] – handles 3D mapping of grid cells, [[Module Geometry]] - handles the vertical discretization and volumes);
*'''Data handling modules''' – modules that perform I/O operations (e.g. [[Module EnterData]] – reads and writes ASCII data files, [[Module HDF5]] – reads and writes matricial data into HDF5 format, [[Module TimeSerie]] – reads and writes formatted time series ASCII files);
*'''Specific functions modules''' – modules that perform specific operations that can only be used in MOHID (e.g. [[Module BoxDif]] - divides 2D and 3D domains into boxes and computes exchanges between boxes, total mass inside a box or process rates within a box, [[Module Statistics]] - computes basic statistic operations over space and time, [[Module Interface]] - interface between 3D and 0D models, [[Module WaterQuality]] – pelagic biochemical module);
*'''Processes modules''' - modules that correspond to the different processes taking place in the different environmental compartments ([[Module Hydrodynamic]], [[Module WaterProperties]], [[Module Turbulence]], [[Module Lagrangian]], [[Module InterfaceSedimentWater]], [[Module InterfaceWaterAir]], [[Module Atmosphere]]);
</blockquote>

All programs included in MOHID Water Modelling System are built on the top of one or more base libraries and the three core executables files can be found at the top of the pyramid:
<blockquote style="background: white; border: 1px blue; padding: 1em;">
*[[MOHID Water]] - Three-dimensional numerical program to simulate surface water bodies.
*[[MOHID Land]] - Watershed model. Numerical program to simulate hydrographic basin and aquifers;
</blockquote>

Smaller utility programs are easily built on the top of the libraries, which are usually designed for pre or post-processing results of the models. This support tools are normally managed by graphical user interfaces which allow management of input data, control of program execution, and output results analysis, along with other pre- and post-processsing operations.

The integration of MOHID’s different tools can be easily achieved since these tools are based on the same framework. This coupling can thus be used to study the water cycle and its associated processes in an integrated approach.

Mohid Graphical User Interfaces

2007-05-31T14:09:34Z

192.168.20.148:

The graphical user interfaces of the MOHID Water Modeling System are a set of programs to pre and post process the input and output data needed by the different numerical programs. This chapter describes how the user interfaces integrated in the MOHID Water Modeling System work and how they interact with the numerical code.

The core graphical user interfaces are:

* [[Mohid GUI]] - a graphical user interface to handle file structure organization of all files which are needed to set up a MOHID numerical simulation;
* [[Mohid GIS]] - a geographical information system which handles spatial and temporal variable data required or produced by MOHID numerical programs;
* [[Mohid PostProcessor]] - a graphical user interface which displays data stored in HDF files as animation on the screen;
* [[Mohid Time Series Editor]] – a graphical user interface which allows the user to visualize in a quick way time series data required or produced by MOHID numerical programs.
* [[Mohid Statistics Analyser]] - an application to perform statistical analysis of [[time series]].

Data exchange between MOHID Graphical User Interfaces and MOHID numerical programs is done by files. There are two types of files which are used: (i) ASCII text files which follow a proper formatting and [[HDF file|HDF files]]. See also [[Input Data Formats]].

[[Category:Graphical User Interfaces]]

HDF File

2007-05-31T14:05:18Z

192.168.20.148:

#redirect [[HDF file]]

Module HDF5

2007-05-31T14:04:42Z

192.168.20.148:

== Overview ==
Module HDF5 is an interface between [[Mohid Water Modelling System]] and [[HDF5]] library that reads and writes matricial data into HDF5 format.

The advantages of HDF5 are that the files can store much more data, the file access is much faster and the files can be read even if the run does not reach the end.

== Programming ==

'''Constructing phase'''

In the constructing phase the following routines must be called:
- [[GetHDF5FileAccess]]
- [[ConstructHDF5]]

In the /Grid group the following data should be stored:
- [[WaterPoints3D]]
- [[Bathymetry]]
- [[ConnectionX]]
- [[ConnectionY]]

'''Working Cycle'''

In the working cycle the following routines should be called:
- [[HDF5SetSize]]
- [[HDF5WriteData]] (for Time, ConnectionZ (SZZ), OpenPoints3D and for each property)
- [[HDF5FlushMemory]]

'''Destructor phase'''

In the destructing phase the files must be closed. To do so one should call:
- [[KillHDF5]]

== Errors ==
Frequent errors are found as:
HDF5-DIAG: Error detected in HDF5 library version: 1.6.4 thread 0. Back trace f
ollows.
#000: D:\muqun\hdf5164-release-fortran\hdf5\src\H5G.c line 297 in H5Gopen(): g
roup not found
major(10): Symbol table layer
minor(48): Object not found

== See also ==
[[HDF5 file]]

[[Category:Modules]]
[[Category:MOHID Base 1]]

Module FillMatrix

2007-05-31T13:42:52Z

192.168.20.148: /* HDF file */

== Overview ==

Throughout all MOHID modules, two-dimensional (e.g. water elevation, wave height, wind velocity, bottom roughness length, etc.) and three-dimensional (e.g. temperature, salinity, nitrate concentrations, etc) variables need to be initialized. Also in some simulations these variables have an imposed solution which needs to be read from a file. In order to reduce input data errors, increase programming efficiency and normalize input data files format a generic input data module (ModuleFillMatrix) was designed.

This module has a quite vast set of options to initialize and read 2D and 3D arrays, being these options defined in MOHID input data files.
The idea is quite simple, and is based on the fact that each 2D or 3D array to used/computed in MOHID is defined in the input data files in the form of a block.

ModuleFillMatrix works based on a client/server philosophy, where the client module (e.g. ModuleWaterProperties is responsible for property temperature) requests the server module (ModuleFillMatrix) to handle the initialization (or modification) of the array. Thus, the client module sends information to ModuleFillMatrix about the input data file, namely the identification number (ID) of the file and the ID of the [[block]] in the file where the options for property ''X'' are defined.

[[Image:FillMatrix.jpg|425px|thumb|center|'''ModuleFillMatrix input data scheme''']]

== Reading solution from a file ==
The first operation ModuleFillMatrix does is to check whether the array is only to be initialized or if it is to be modified during the simulation from information stored in a file.

This option is given by keyword [[FILE_IN_TIME]].

=== Time series file ===
Uses a [[Time Series]] file to initialize the property.

FILE_IN_TIME : TIMESERIE
FILENAME : ..\..\GeneralData\myTimeSeriesFile.dat
DATA_COLUMN : 2
DEFAULTVALUE : 0

=== HDF file ===
Reads the solution from an [[HDF file]].

FILE_IN_TIME : HDF
FILENAME : ..\..\GeneralData\myHDFfile.dat
VGROUP_PATH : \Results
MULTIPLYING_FACTOR : 1
HDF_FIELD_NAME : temperature
DEFAULTVALUE : 15

=== Time series profile file ===

FILE_IN_TIME : PROFILE_TIMESERIE
FILENAME : ..\..\GeneralData\myProfileTimeSeriesFile.dat
DEFAULTVALUE : 5

== Initialization methods ==

This option is given by keyword [[INITIALIZATION_METHOD]].

=== Constant ===
Assumes a constant value to initialize the property.

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : CONSTANT
DEFAULTVALUE : 20

=== ASCII Grid Data file ===
Uses a [[Grid Data]] file to initialize the property.

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : ASCII_FILE
FILENAME : ..\..\GeneralData\myGridDataFile.dat
DEFAULTVALUE : 0

=== Boxes ===
Uses a [[Boxes]] file to initialize the property. The default value is given to every grid point which is not inside any of the defined boxes.

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : BOXES
FILENAME : ..\..\GeneralData\myBoxesFile.dat
BOXES_VALUES : 12.3 15.2 12.7 13.4 14.1
DEFAULTVALUE : 0

=== Layers ===

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : LAYERS
LAYERS_VALUES : 35.4 35.2 36.1
DEFAULTVALUE : 35.5

=== Profile file ===
Uses a [[Profile]] file to initialize the property.

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : PROFILE
FILENAME : ..\..\GeneralData\myProfileFile.dat
DEFAULTVALUE : 15

=== Analytical profile ===
An analytical profile can be given with a linear or a exponential format.

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : ANALYTIC_PROFILE
DEFAULTVALUE : 20

For a linear profile (<math>Value = DefaultValue + CoefA * \frac{CellDepth} {CoefB}</math>) define:

PROFILE_TYPE : LINEAR

For a exponential profile (<math>Value = DefaultValue - CoefA^{- \frac{CellDepth} {CoefB}}</math>) define:

PROFILE_TYPE : EXPONENTIAL

The coefficients can be given by the following keywords:

CoefA : 0.1
CoefB : 4500

=== HDF file ===

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : HDF
VGROUP_PATH : \Results
MULTIPLYING_FACTOR : 1
HDF_FIELD_NAME : temperature
DEFAULTVALUE : 15

=== Time series file ===
Uses a [[Time Series]] file to initialize the property.

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : TIMESERIE
FILENAME : ..\..\GeneralData\myTimeSeriesFile.dat
DATA_COLUMN : 2
DEFAULTVALUE : 0

=== Time series profile file ===

FILE_IN_TIME : NONE
INITIALIZATION_METHOD : PROFILE_TIMESERIE
FILENAME : ..\..\GeneralData\myProfileTimeSeriesFile.dat
DEFAULTVALUE : 10

== Important notes ==
Keyword [[DEFAULTVALUE]] has '''always''' to be present. This insures that the user must be aware of the initialization option.

Keyword [[REMAIN_CONSTANT]] defines whether the property will remain unaltered during the simulation. By default this boolean keyword is FALSE, which means that the model will dynamically compute the property values (e.g. current velocities) or it will read them from a file (e.g. wind speed and direction). If it's TRUE this means that the property values will remain constant throughout the simulation (e.g. constant wind speed and direction in a scenario simulation).

== List of properties which are handled by Module FillMatrix ==

=== ModuleAtmosphere ===
All properties of this module are 2D arrays:
*wind modulos
*wind angle
*wind velocity X
*wind velocity Y
*air temperature
*relative humidity
*sun hours
*cloud cover
*irrigation
*precipitation
*solar radiation
*atmospheric pressure
*mean sea level pressure

=== ModuleAssimilation ===
All 2D/3D fields which can be used for any type of relaxation scheme or reference solution. This includes the reference fields and the decayment coefficients.

=== ModuleConsolidation ===
*porosity (3D)
*stationary porosity (3D)
*rosion critical shear stress( 3D)

=== ModuleHydrodynamic ===
*water level(2D)
*velocity U (3D)
*velocity V (3D)
*drag coefficient (3D) - used in when parameterizing obstacles

=== ModuleInterfaceWaterAir ===
*latent heat
*sensible heat
*net long wave radiation
*upward long wave radiation
*downward long wave radiation
*evaporation
*“non-solar” flux
*wind shear stress X
*wind shear stress Y
*Surface radiation
*Turbulent kinetic energy
*wind shear velocity
*carbon dioxide flux
*oxygen flux

=== ModuleInterfaceSedimentWater ===
*manning coefficient (2D)
*rugosity coefficient (2D)
*“wave” rugosity coefficient (2D)
*Erosion critical shear stress (2D)
*Deposition critical shear stress (2D)
*Erosion reference rate (2D)
*Diffusion coefficient (2D)
*Consolidation rate (2D)
*Other properties* (2D)

=== ModuleSand ===
*D35
*D50
*D90
*bed rock
*sand classes diameter
*sand classes percentage

=== ModuleSedimentProperties ===
*Other properties*
*Partition fraction
*Partition rate
*Sediment dry density
*Turbulent horizontal diffusion coefficient
*Turbulent vertical diffusion coefficient

=== ModuleTurbulence ===
*horizontal viscosity
*vertical viscosity

=== ModuleWaterProperties ===
*sigma-T (density)
*specific heat
*filtration rate
*other properties*

=== ModuleWaves ===
*wave height
*wave period
*wave direction
*radiation stress X
*radiation stress Y

== Links ==
Read the FillMatrix Module [http://maretec.mohid.com/PublicData/products/Manuals/FillMatrix.pdf manual]

[[Category:Modules]]
[[Category:MOHID Base 2]]
[[Category:Input Data Formats]]

Module Functions

2007-05-31T13:12:36Z

192.168.20.148:

== Overview ==
Module Functions is a set of scientific mathematical functions or routines that are used by various others classes but that did not fit as specific methods of a class. This way this class can be seen as a run-time mathematical library included in the model.

== List of functions ==

=== MOHID Utilities ===
*SetMatrixValue
*ReadTimeKeyWords
*ConstructPropertyID
*Check_Hydrodynamic_Property
*Check_Water_Property
*GetDataOnlineString
*IsOdd
*Chunk_K
*Chunk_J
*TimeToString
*ChangeSuffix
*SortNumerically_3D

=== Math & Solvers ===
*InvSingularDiagMatrix2D
*CholeskyFactorization
*CholLinSystemSolver
*TriangLinSystemSolver
*THOMAS_2D
*THOMAS_3D
*THOMASZ
*tridag
*tridag_cyclic
*CGS2D
*LISOLVE
*SIPSOL
*BICGSTAB2D
*Secant
*Normcrossprod
*SLPMIN
*SLPMIN2

=== Advection & Diffusion & Boundary Conditions ===
*ComputeAdvectionFace
*ComputeAdvection1D_V2
*ComputeAdvection1D
*ComputeAdvection3D
*ComputeDiffusion3D
*OrlanskiCelerity2D

=== Heat & Mass transfer ===
*SaturatedVaporPressure
*LongWaveDownward
*LongWaveUpward
*LatentHeat
*SensibleHeat
*AerationFlux

=== Oxygen Saturation ===
*OxygenSaturation
*OxygenSaturationHenry
*OxygenSaturationCeQualW2

=== Density & Specific heat ===
*Density
*Sigma
*SigmaWang
*SigmaUNESCO
*SigmaLeendertse
*SigmaUNESCOPressureCorrection
*SigmaJMD95PressureCorrection
*SigmaMel96PressureCorrection
*'''ConvertTemperature''' - converts in-situ temperature into potential temperature
*SpecificHeatUNESCO
*CalcPotentialEnergy

=== Grids & Coordinates ===
*RODAXY
*FromCartesianToGrid
*FromGridToCartesian
*ComputeGridZone
*GetLambda0
*GetEllipsoid
*LatLonToUTM
*UTMToLatLon
*LatLonToLambertSP2

=== Interpolation ===
*InterpolateValueInTime
*InterpolateMatrix2DInTime
*InterpolateMatrix3DInTime
*LinearInterpolation
*InterpolateLinearyMatrix2D
*InterpolateLinearyMatrix3D
*InterpolateProfile
*InterpolateProfileR8
*QuadraticInterpolation
*QuadraticInterpolProfile
*PolIntProfile
*polint

=== Biogeochemistry & Water quality ===
*PhytoLightLimitationFactor
*ComputeT90_Canteras
*ComputeT90_Chapra
*SettlingVelocity

[[Category:Modules]]
[[Category:MOHID Base 1]]

Mohid Input/Output

2007-05-31T12:55:07Z

192.168.20.148: /* Input */

In MOHID, input and output is made via ASCII and [[HDF5]] files. ASCII files are handled by [[Module EnterData]] and HDF5 files by [[Module HDF5]]. Both the ASCII files and HDF5 files have [[Input Data Formats|specific format conventions for MOHID]]. These conventions were defined in order to reduce [[Input Data Errors|input data errors]] and standardize the output formats so that [[Mohid Graphical User Interfaces]] can use them straightforwardly.

== Input ==
To input data into MOHID please see [[Module FillMatrix]] and [[Module EnterData]].

== Output ==

=== HDF outputs ===

*[[OUTPUT_TIME]]
*[[SURFACE_OUTPUT_TIME]]

=== Time series outputs ===

Grid

2007-05-31T10:43:54Z

192.168.20.148: /* Overview */

== Overview ==
A grid in Mohid is stored in an ASCII text file and is directly handled by [[Module HorizontalGrid]]. The organization of this file is divided into a header section, and a grid spacing section.

Mohid supports orthogonal horizontal grids, which can be [[rectangular]] or [[curvilinear]]. Grid files can be created manually or automatically via [[MohidGIS#Create_New_Data_Items|MOHID GIS]] or via the [[GenerateGrid]] tool. The default extension for Grid files in [[MohidGIS]] is '''*.grd'''.

[[Image:grids.png|425px|thumb|center|'''Types of grids supported by MOHID''']]

Note that in MOHID the '''i''' index refers to the YY axis and the '''j''' index to the XX axis. For example grid cell (5, 2) is the fifth grid cell in the YY axis and the second in the XX axis.

== Header Section ==

The header section contains information related to the grid global definitions, such as the number of cells, the type of coordinate used, the origin coordinates of the grid, etc. Below are shown the [[keywords]] supported in the header section of a Grid file.

<blockquote style="background: white; border: 1px blue; padding: 1em;">
*'''ILB_IUB''' - Two integer numbers defining the '''minimum''' and '''maximum''' '''I''' values along the Y-axis of the grid.
*'''JLB_JUB''' - Two integer numbers defining the '''minimum''' and '''maximum''' '''J''' values along the X-axis of the grid.
*'''COORD_TIP''' - A flag which indicates the used [[coordinates type]].
*'''ORIGIN''' - Two real values, which indicate the origin of the lower left corner of the grid.
*'''ZONE''' - Integer values defining the UTM Zone where the bathymetry is located.
*'''GRID_ANGLE''' - Counter-clock mesh rotation relative to the north. The base point is the origin of the grid.
*'''LATITUDE''' - Average latitude value used to compute [[Coriolis frequency]] and [[Module_Atmosphere#Solar_radiation|solar radiation]] when metric coordinates cannot be converted to WGS84 [[geographic coordinates]].
*'''LONGITUDE''' - Average longitude value used to compute [[Coriolis frequency]] and [[Module_Atmosphere#Solar_radiation|solar radiation]] when metric coordinates cannot be converted to WGS84 [[geographic coordinates]].
*'''CONSTANT_SPACING_X''' - Boolean defining if the spacing in the X axis is constant
*'''CONSTANT_SPACING_Y''' - Boolean defining if the spacing in the Y axis is constant
*'''DX''' - Constant spacing distance in XX axis
*'''DY''' - Constant spacing distance in XX axis
</blockquote>

== Grid Spacing Section ==
The grid spacing section contains information about the grid spacing in the XX and YY axis, if the spacing is not constant, namely through defining the grid cells corners coordinates.

=== Rectangular grids ===
The information is stored in [[blocks]], one for each direction. The data is stored inside a block defined by the following keywords: '''<BeginXX>''' and '''<EndXX>''' for the XX axis and '''<BeginYY>''' and '''<EndYY>''' for the YY axis. Note that these block definition tags are case sensitive. Each value must be stored in a single line.

Note that if, for example, a grid has 100x100 grid cells, there should be 101 XX values and 101 YY values.

The values are read from left to right corner in the XX axis and from bottom to top in the YY axis. The first value is always zero in both directions, being the following values cumulative.

=== Curvilinear grids ===
When defining a curvilinear grid, the information is stored in only one [[block]] defined by the following keywords: '''<CornersXY>''' and '''<\CornersXY> '''. This block contains two columns with the XX and YY coordinates of each grid cell corner. Each set of XX and YY values must be stored in a single line.

The values are read from left to right corner in the XX axis and from bottom to top in the YY axis. The first value is always zero in both directions, being the following values cumulative.

== Sample Grid File ==

ILB_IUB : 1 52
JLB_JUB : 1 19
ORIGIN : -9.0 39.0
GRID_ANGLE : 0.0
COORD_TIP : 5
<BeginXX>
0.0000000
0.1052632
0.2105263
0.3157895
0.4210526
0.5263158
0.6315790
0.7368422
0.8421053
0.9473685
1.052632
1.157895
1.263158
1.368421
1.473684
1.578947
1.684210
1.789473
1.894737
2.000000
<EndXX>
<BeginYY>
0.0000000
0.0996386
0.1945154
0.2848571
0.3708795
0.4527884
0.5307797
0.6050400
0.6757467
0.7430694
0.8071689
0.8681989
0.9263055
0.9816279
1.034299
1.084444
1.132185
1.177634
1.220903
1.262094
1.301306
1.338633
1.374166
1.407990
1.440186
1.470831
1.500000
1.529169
1.559814
1.592010
1.625834
1.661367
1.698694
1.737906
1.779097
1.822366
1.867815
1.915556
1.965701
2.018372
2.073694
2.131801
2.192831
2.256931
2.324253
2.394960
2.469220
2.547212
2.629121
2.715143
2.805485
2.900361
3.000000
<EndYY>

[[Category:Input Data Formats]]

Lines

2007-05-31T10:05:43Z

192.168.20.148: /* Lines file */

== Overview ==

Lines items are defined by the starting point and ending point. Lines items can be stored as a collection of lines. This type of items can be used to define, for example, reaches or a coast line.

== Lines file ==

Lines items are stored in an ASCII text file. The default extension for Lines files in [[MohidGIS]] is '''*.lin'''. This file is organized in [[blocks]], each containing the vertices for a determined polygon. One block is defined by the following [[keywords]]: '''<begin_line>''' and '''<end_line>'''. Note that these keywords are case sensitive. One file can contain an infinite number of blocks. Inside each block there are 2 columns and 2 rows: the first row is relative to the line starting point. The second row is relative to the line ending point. The left column relates to the XX coordinates of a point and the right one to the YY coordinates.

== Sample file ==

<begin_line>
-9.5190 38.8148
-9.4545 38.5699
-9.2612 38.4098
-9.0372 38.4686
-9.0550 38.7375
-9.1291 38.8921
-9.2644 38.8792
-9.4384 38.8438
-9.5254 38.8373
-9.5190 38.8148
<end_line>

[[Category:Input Data Formats]]