OpenLLM-France/wikimedia huggingface dataset:
# HydroGeoSphere/Adaptive Timesteps

If required, HydroGeoSphere can modify timestep values as the solution proceeds, based on the transient behaviour of the system (see Equation 3.102). The following instructions can be used to activate this feature, and set targets for specific variables (e.g. pressure head, saturation etc.). These targers are used to modify timestep size as the solution proceeds.

## Head control

* dhead_allowed Maximum allowed absolute change in nodal head during any time step [L].

## Water depth control

* ddepth_allowed Maximum allowed absolute change in nodal surface water depth during any time step [L].

## Saturation control

* dsat_allowed Maximum allowed absolute change in nodal saturation during any time step [L].

## Newton iteration control

* nnri_allowed Maximum allowed number of Newton-Raphson iterations during any time step [L].

## Concentration control

* dconc_allowed Maximum allowed absolute change in nodal concentration during any time step [L].

## Mass change control

* dmass_change_allowed Maximum allowed absolute change in mass during any time step [L].

## Mass error control

* dmass_error_allowed Maximum allowed absolute mass error during any time step [L].
The following controls are used to generate a timestep multiplier according to Equation 3.102. There are limits to how large or small the multiplier can be, and these are set by default to be in the range of 0.5 to 2 respectively. If you want to modify these limits you can do so using the following instructions:

## Maximum timestep multiplier

* val Maximum timestep multiplier value.
Assigns a new value for the maximum timestep multiplier, which defaults to 2.

## Minimum timestep multiplier

* val Minimum timestep multiplier value.
Assigns a new value for the minimum timestep multiplier, which defaults to 0.5. Currently, HydroGeoSphere ignores this parameter and allows any non-zero minimum, no matter how small.
# HydroGeoSphere/Adding a New Layer

For each layer in the domain, you should include a single instance of the following instruction:

## New layer...End

Causes grok to begin reading a group of new layer instructions until it encounters an End instruction.
By default, the top elevation of the layer will be set to zero by assigning all nodes in the lowermost 2-D slice to have a z-coordinate value of zero. You can change the layer top elevation using the instructions described in Section 5.3.5.4.
The following instructions are all optional:

## Layer name

* layer_name Layer name.
Changes the layer name, which defaults to Layer n, where n is the current layer number.

## Minimum layer thickness

* z_added Minimum thickness value[L].
This instruction causes grok to enforce a minimum thickness constraint for the current layer. At nodes where the computed layer top elevation is less than or equal to the current base elevation, z_added will be added to the current base elevation to get the top elevation.
If this constraint is not enforced, grok will stop and issue a warning message if the computed top elevation is less than or equal to the current base elevation.
By default, a new layer will not be subdivided vertically unless one of the following two instructions is issued:

## Uniform sublayering

* nsublayer Number of sublayers.
This instruction divides the layer vertically into nsublayer elements, which will each have the same height, equal to the top elevation minus the current base elevation divided by nsublayer.

## Proportional sublayering

* nsublayer Number of proportional sublayers.
* sub_thick(i),i=1,nsublayer Proportional thicknesses in order from top to bottom.
This instruction can be used if you want to refine the mesh vertically, for example in the subsurface near the surface flow domain or a fracture.
It is important to understand that the variable sub_thick is not a true thickness, but is instead a relative thickness, which is used along with the layer thickness to determine the element heights in the current column.
For example, these instructions would subdivide the current layer vertically into three elements, between the current base and top elevation, with element height proportions of .1, 1 and 10 from top to bottom:

## Offset top

* value Thickness value (L) by which to offset the layer top elevation.
This instruction causes the elevation of the top layer to be offset vertically by the given value. This can be used to create a surface a given distance below another surface.
For example, these instructions create a layer with a top elevation 1 metre below the elevation defined in the raster file gs.asc:
# HydroGeoSphere/Channel Flow

Channel domains, can be set up using the following instructions, as outlined in Section 2.3.2.4 and in Equation 2.65.

## Default Channel Properties

Unless the user modifies the default values, all channel zones in the domain will be assigned the default properties. The default values, Table 5.10, can be and are recommended to be modified to fit the model application.
Table 5.10: Default Values for Channel Properties :
| Parameter | Value | Unit |
| Shape | Rectangle | m |
| Width | 1 | m |
| Manning’s Friction Coefficient | 0.0548 | m$^{−1/3}$ s |
| River Bank Height | 1 | m |
| Streambed Thickness | 0.001 | m |
| Steambed Conductivity | 1 × 10$^{−4}$ | m |

## Example Channel Flow Instructions

As an example, the following set of instructions, with prefix.cprops file Figure 5.14, could be inserted into the prefix.grok file to produce a channel:
The channel domain example opens the property file prefix.cprops, shown in Figure 5.14, and creates a 1 m wide channel. The channel one properties are read into grok.
    Figure 5.14: Sample channel domain property file prefix.cprops

## Dual nodes for channel flow

Scope: .grok
This instruction causes the channel flow scheme to use dual node approach.

## Type rectangle

Scope: .grok .cprops
* ChanWidth Channel Width [L].
The width of the rectangular channel.

## Type trapezoid

Scope: .grok .cprops
* ChanWidth Channel Width [L].
* ChanTrapBankAngle Channel Bank Angle [degree].
The width of the bottom of the trapezoidal channel and the angle of the bank from the vertical line.

## Type circle

Scope: .grok .cprops
* ChanRadius Channel Radius [L].
The radius of the circular channel.

## Type general

Scope: .grok .cprops
* nChanTab The number of water depth values in the table.
* i=1, nChanTab, ChanTabD, ChanTabAF, ChanTabWP, ChanTabTW Tables for water depth, area of flow, wetted perimeter, and top width.
A tabular form of data can be used to specify the area of flow, wetted perimeter, and top width for given depth values.

## Friction

Scope: .grok .cprops
* ChanFrictn Manning friction for the channel.
Manning friction coefficient for the zone chosen.

## Rill storage height

Scope: .grok .cprops
* ChanRillStor Channel rill storage height.
A minimum water depth required for flow.

## Obstruction storage height

Scope: .grok .cprops
* ChanOnstructStor Channel obstruction storage height.
Obstruction storage height.

## Streambed thickness

Scope: .grok .cprops
* ChanStrmBedThick Thickness of streambed.
Streambed thickness that defines the coupling between channel and subsurface.

## Streambed conductivity

Scope: .grok .cprops
* ChanStrmBedK Hydraulic conductivity of streambed.
Streambed hyarulic conductivity together with thickness to define the coupling conductance between channel and subsurface.

## Bank height

Scope: .grok .cprops
* ChanBankHeight Height of river bank.
River bank height to define the interaction between the channel and overland flow domains.
# HydroGeoSphere/Constraints and Tecplot Options

* Nodal Flux Head Constraints
* Tecplot Output
# Game Creation with XNA/Networking/Split-Screen
## Split-Screen

The simplest way to create a multiplayer game is the split screen. For two players that means that the screen (TV) is split in half (vertically or horizontally) and one displays the view for player one, and the other the view for player two. Since you can connect up to four gamepads to an XBox, hypothetically, up to four players could play this way.

### Authors

none
# Game Creation with XNA/Other/Introduction
## Introduction

Some topics did not quite fit into the other headings, so we put them here. One of them is level editors.

### More Details

Lore ipsum ...
# Game Creation with XNA/Preface
## Preface

To start writing games for Microsoft's XBox360, one usually has to read many books, web pages and tutorials. This class project tries to introduce the major subjects, get you started and if needed point you into the right direction for finding additional material.
The idea behind this class project came from a colleague who suggested that most class projects produce really nice results, but usually disappear in some instructors' drawers. After reading on the possibility of using Wikibooks for class projects, we just had to give it a try.

### Getting Started

If you are new to Wikibooks, you might first want to look at Using Wikibooks. Details for creating a class project can be found at Class_Project_Guidelines.

### Other Wikibooks

There are also other wikibooks on subjects related that are quite useful:
* Creating a Simple 3D Game with XNA
* Video Game Design
* Blender 3D: Noob to Pro
* C Sharp Programming
* Introduction to Software Engineering
* Game Creation with the Unity Game Engine

### Other Class Projects

Inspiration from successful class projects can be drawn here, which by themselves are also quite interesting and maybe helpful for this project:
* Basic Writing
* Geometry
* Handbook for Doctoral Students in Education
# Game Creation with XNA/Programming/Introduction
## Introduction

Game development needs good programming skills. Here we introduce you to Visual Studio, and how to get Git and Subversion working, as well as some other skills required. Also we want to give a list of good reusable components and where to find more, as well as a brief introduction to some existing frameworks, supposedly making the life of the developer easier.

### More Details

Lore ipsum ...
to be edited by iSteffi
# Fire Simulation for Engineers/FDS/Parking Lot
## A simple car parking
### Description

In Figure [fig:Car-parking-plan] a simple case of a fire in a car parking is proposed. The data are for demonstration only, and the proposed solution is only one of the many possible solutions.
The objectives of the analysis are:
* Study the critical times for evacuation and rescue operations from fire brigade of the car parking.
* Obtain adiabatic surface temperature to predict the mechanical response of the structure.
The following input file is called car_parking.fds, and it is deeply commented.
# Extra gas species

Third, some properties are set up, as the properties of extra gas species (SPEC).

## Defining extra gas species, SPEC

Gases that are introduced into the domain that are neither reactants nor products of combustion, like carbon dioxide from an extinguisher, are tracked separately from the mixture fraction model for gas phase combustion via an additional scalar transport equation. In fact, there does not need to be any fire at all, as FDS can be used to transport a mixture of non-reacting ideal gases.
The namelist group SPEC is used to specify each additional species. Each SPEC line should include at the very least the name of the species via a character string called ID.
The following gases are predefined in FDS and do not need any property to be set up:
* Predefined extra species
* AIR, ARGON, CARBON DIOXIDE, CARBON MONOXIDE, HELIUM, HYDROGEN, METHANE, NITROGEN, OXYGEN, PROPANE, WATER VAPOR.
For example:
adds the predefined HELIUM gas as an additional specie that can be injected in the domain.
To specify a gas not included in the list, the user should input several chemical properties. See [FDS5 user's guide] for broader description.
If the ambient initial mass fraction of an extra gas specie is something other than 0, then the parameter MASS_FRACTION_0 is used to specify it. For example, the line:
specifies that 10% in mass of ARGON is to be included in the calculation, in addition to the 90% unlisted default ambient specie named AIR.
The following table summarizes some SPEC parameters:
| Parameter | Type | Description | Unit | Default |
| ID | String | Identifier | | |
| MASS_FRACTION_0 | Real | Initial mass fraction | | 0 |

## CARBON DIOXIDE and carbon dioxide

These extra gas species are identified by an uppercase name, and are not to be confused with the lowercase species implicitly defined by FDS when doing a mixture fraction calculation for gas phase combustion, as fuel, oxygen, nitrogen, water vapor, carbon dioxide... See Section [sec:Modeling-gas-phase-comb-REAC] for reference.
If the user introduces an extra gas in the calculation that is the same as a product of combustion, as in:
&SPEC ID='CARBON DIOXIDE' /
FDS will take into account two different gases: the implicitly defined carbon dioxide and the extra gas species CARBON DIOXIDE, injected for example to simulate a CO$_2$ extinguisher.
The first is a product of combustion, while the second is just another gas: it does not participate to combustion, but it can dilute oxygen and contribute to fire suppression.
The two gases are tracked separately: carbon dioxide is tracked via the mixture fraction variable and CARBON DIOXIDE is tracked via its own transport equation.
# Lagrangian particles

Third, some properties are set up, as the properties of Lagrangian particles (PART).

## Defining Lagrangian particles, PART

Lagrangian particles are used in FDS as water or liquid fuel droplets, flow tracers, and various other objects that are not defined or confined by the numerical mesh. Sometimes the particles have mass, sometimes they do not. Some evaporate, absorb radiation, etc. PART is the namelist group that is used to prescribe parameters associated with Lagrangian particles.
All Lagrangian particles must be explicitly defined via the PART namelist group.
Once a particular type of particle or droplet has been described using a PART line, then the name of that particle or droplet type is invoked elsewhere in the input file via the parameter PART_ID.
There are no reserved PART_ID, all must be defined. For example, an input file may have several PART lines that include the properties of different types of Lagrangian particles:
Then these Lagrangian particles can be introduced in the fluid flow from a solid surface via a boundary condition as explained in Section [sec:Injecting-Lagrangian-particles].
The following table summarizes some PART parameters:
| Parameter | Type | Description | Unit | Default |
| ID | String | Identifier | | |
| MASSLESS | Logical | Massless particles | | .FALSE. |
| WATER | Logical | Water droplets | | .FALSE. |
| AGE | Real | Droplet lifetime | s | 100000 |
| COLOR | String | Color | | |
| RGB(3) | Integer | Color | | |
| DT_INSERT | Real | Time between insertions | s | 0.01 |
| XB(6) | Real | Volume, initial particle location | m | |

## Massless particles

The simplest use of Lagrangian particles is for visualization, in which case the particles are considered massless tracers. In this case, the particles are defined via the line:
&PART ID='my tracer', MASSLESS=.TRUE. /

## Water droplets

WATER=.TRUE. declares that the liquid droplets evaporate into WATER VAPOR, a separate gas phase specie that is automatically added to the calculation by this command. By default, WATER=.FALSE., even though the default properties of droplets are that of water. Setting WATER=.TRUE. instructs FDS to add WATER VAPOR as an explicitly defined specie, and it also invokes appropriate constants related to the absorption of thermal radiation by the water droplets. It also causes the droplets to be colored blue in Smokeview.
For example:
When a droplet strikes a solid surface, it sticks and is reassigned a new speed and direction. If the surface is horizontal, the direction is randomly chosen. If vertical, the direction is downwards.
# Fire Simulation for Engineers/FDS/Ethanol pan
## A pan filled of ethanol

Here is an example of a steel pan filled with a thin layer of ethanol:
# Fire Simulation for Engineers/FDS/Features

A brief description of the major features of FDS follows.

## Hydrodynamic model

FDS solves numerically a form of the Navier-Stokes equations appropriate for low- speed, thermally-driven flow with an emphasis on smoke and heat transport from fires. The core algorithm is an explicit predictor-corrector scheme, second order accurate in space and time. Turbulence is treated by means of the Smagorinsky form of Large Eddy Simulation (LES). It is possible to perform a Direct Numerical Simulation (DNS) if the underlying numerical mesh is fine enough. LES is the default mode of operation.

## Combustion model

For most applications, FDS uses a single step, mixing-controlled chemical reaction which uses three lumped species (a species representing a group of species). These lumped species are air, fuel, and products. By default the last two lumped species are explicitly computed. Options are available to include multiple reactions and reactions that are not necessarily mixing-controlled.

## Radiation transport

Radiative heat transfer is included in the model via the solution of the radiation transport equation for a gray gas, and in some limited cases using a wide band model.
The equation is solved using a technique similar to finite volume methods for convective transport, thus the name given to it is the Finite Volume Method (FVM). Using approximately 100 discrete angles, the finite volume solver requires about 20% of the total CPU time of a calculation, a modest cost given the complexity of radiation heat transfer.
The absorption coefficients of the gas-soot mixtures are computed using [Grosshandler 1993] narrow-band model. Liquid droplets can absorb and scatter thermal radiation. This is important in cases involving mist sprinklers, but also plays a role in all sprinkler cases.

## Geometry and multiple meshes

FDS approximates the governing equations on a rectilinear mesh. Rectangular obstructions are forced to conform with the underlying mesh.
It is possible to prescribe more than one rectangular mesh to handle cases where the computational domain is not easily embedded within a single mesh.

## Parallel processing

FDS employs OpenMP, a programming interface that exploits multiple processing units on a single computer. For clusters of computers, FDS employs Message Passing Interface (MPI).

## Boundary conditions

All solid surfaces are assigned thermal boundary conditions, plus information about the burning behavior of the material. Heat and mass transfer to and from solid surfaces is usually handled with empirical correlations, although it is possible to compute directly the heat and mass transfer when performing a Direct Numerical Simulation (DNS).
# Fire Simulation for Engineers/FDS/General Configuration

First, general configuration is performed.
The case receives a name via the HEAD namelist group, the simulation time is set via the TIME namelist group. Other miscellaneous parameters are prescribed via the MISC namelist group.

## Naming the job, HEAD

The first thing to do when setting up an input file is to give the job a name. The name of the job is important because often a project involves numerous simulations in which case the names of the individual simulations can help organize the effort. The namelist group HEAD contains two parameters, as in this example:
CHID is a string of 30 characters or less used to name the output files created by FDS. No periods or spaces are allowed. TITLE is a string of 60 characters or less that describes the simulation. It is simply a descriptive text that is passed to various output files.
It is always convenient to exactly use the same string for the name of the input file and the CHID. For example, if you name mycase.fds the input file, then set CHID='mycase' in the HEAD namelist group.
Only one HEAD line can be entered in the input file. The following table summarizes some of the most used HEAD parameters.
| Parameter | Type | Description | Unit | Default |
| CHID | String | Job identifier | | 'output' |
| TITLE | String | Short description of the job | | |

## Simulation time, TIME

TIME is the namelist group that define the time duration of the simulation. Usually, only the duration of the simulation is required on this line, via the parameter T_END. The default is 1 s.
For example, the following line will instruct FDS to run the simulation for 5400 s:
If T_END is set to zero, only the set-up work is performed, allowing you to quickly check the geometry in Smokeview.
Only one TIME line can be entered in the input file. The following table summarizes some of the most used TIME parameters.
| Parameter | Type | Description | Unit | Default |
| T_BEGIN | Real | Starting time for calculation | s | 0. |
| T_END | Real | Ending time for calculation | s | 1. |

## Miscellaneous, MISC

MISC is the namelist group of global miscellaneous input parameters. Many parameters for MISC exist, some of them are explained later in this manual.
For example:
establishes that all bounding surfaces are to be made of steel unless otherwise specified.
Only one MISC line can be entered in the input file. The following table summarizes some of the most used MISC parameters.
| Parameter | Type | Description | Unit | Default |
| SURF_DEFAULT | String | Default boundary condition | | 'INERT' |
| TMPA | Real | Ambient temperature | °C | 20. |
| U0, V0, W0 | Real | Initial prevailing velocity field | m/s | 0. |
| GVEC(3) | Real | Gravity vector | m/s$^2$ | 0.,0.,-9.81 |
| RESTART | Logical | Restart previous calculation | | .FALSE. |
# Internet Fundamentals/Search engines

Search engines are used to find specific content on the World Wide Web.
Common search engines as of 2023 include:
* Google
* Bing

## Read More

* The Wikibook How To Search
# Internet Governance/APDIP
## APDIP

The Asia-Pacific Development Information Programme (APDIP) is an initiative of the United Nations Development Programme (UNDP) that aims to promote the development and application of new Information and Communication Technologies (ICTs) for poverty alleviation and sustainable human development in the Asia-Pacific region. It does so through three core programme areas, namely, Policy Development and Dialogue; Access; and Content Development and Knowledge Management.
In collaboration with national governments, APDIP seeks to assist national and regional institutions in the Asia-Pacific through activities that involve awareness-raising and advocacy, building capacities, promoting ICT policies and dialogue, promoting equitable access to tools and technologies, knowledge sharing, and networking. Strategic public-private sector partnerships and opportunities for technical cooperation among developing countries are APDIP’s key building blocks in implementing each programme activity.
# Internet Governance/About the Author
## About the Author

Akash Kapur (www.akashkapur.com) is a consultant and writer based in South India and New York. He has written on technology, politics, literature and other topics for The Atlantic Monthly, The Economist, The New York Times, The New Yorker, Slate, Wired and several other publications. He has consulted on technology and development related issues for The Markle Foundation, UNDP, the US Trade and Development Agency (USTDA), and other organizations. Akash has a BA (summa cum laude) in Anthropology from Harvard University, and a DPhil (Law, specialized in technology law) from Oxford University, where he attended as a Rhodes Scholar.
# Internet Fundamentals
## Table of contents

* Introduction
* Web browsers
* Search engines
* Culture